[BUG][Chrome] Gen4.1 AIOC rt256 jack detection will fail if we connect in DSP runtime suspend state.

[Vamshigopal]

Describe the bug On ADL-P RVP we connected Gen4.1 AIOC to check ALC256 in HD-A mode. We found that headset jack detection is not working when DSP is in runtime suspend state. evtest also couldnt detect any event after jack plug. But headset jack detection is working fine when DSP is in active state.

To Reproduce connect headset when DSP is in runtime suspend state. cat /sys/bus/pci/devices/0000:00:1f.3/power/runtime_status suspended

Expected result Should detect headset when plugged in

Actual result Jack detection not working

Firmware https://github.com/thesofproject/sof/tree/cavs2.5-001-drop-stable top commit: f91af22e53ab6fc652713240dee38bec68b15c7e

Topology sof-hda-generic-2ch.tplg

Kernel https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/tags/v6.6.16

Reproduction Rate 100%

logs dmesg_jack_insert_in_active.log amixer_jack_insert_in_active.txt dmesg_jack_insert_in_suspend.log amixerdump_jack_insert_in_suspend.txt

[Vamshigopal]

@mengdonglin @plbossart @ujfalusi @bardliao @kv2019i @sathya-nujella

[plbossart]

are the patches from https://github.com/thesofproject/linux/pull/4769 in your kernel @Vamshigopal ?

[plbossart]

Also please clarify the expected behavior a) wake-up and resume when the headset is inserted, or b) detect the headset when the system resumes, e.g. by playing a sound.

Different code paths.

[Vamshigopal]

are the patches from #4769 in your kernel @Vamshigopal ?

I have taken this patch in kernel, still issue reproduces.

Also please clarify the expected behavior a) wake-up and resume when the headset is inserted, or b) detect the headset when the system resumes, e.g. by playing a sound.

a. Just the jack detection when headset is inserted when DSP is in runtime suspend state. b. Headset inserted during suspend detects when playing a sound.

[plbossart]

Also please clarify the expected behavior a) wake-up and resume when the headset is inserted, or b) detect the headset when the system resumes, e.g. by playing a sound.

a. Just the jack detection when headset is inserted when DSP is in runtime suspend state. b. Headset inserted during suspend detects when playing a sound.

I was asking an a) or b) question, you replied with both... I can't figure out what you are trying to say @Vamshigopal

[Vamshigopal]

I was asking an a) or b) question, you replied with both... I can't figure out what you are trying to say @Vamshigopal

@plbossart I meant b is already working, issue is with a.

[plbossart]

@Vamshigopal please double-check what the behavior is with the snd-hda-intel driver, I would bet a) is not handled as well with HDaudio codecs.

[Vamshigopal]

@plbossart , i double checked with snd_hda_intel driver , i wouldnt see DSP going runtime suspend state it always in active state. So my observation with snd_hda_intel is not valid. Changing in issue description.

[plbossart]

@Vamshigopal with snd-hda-intel there is no DSP enabled. So not sure what you are referring to. I believe the PCI device will go to runtime suspend state, doesn't it?

[kv2019i]

@Vamshigopal @plbossart But with runtime-pm enabled, snd-hda-intel is a good reference (CONFIG_SND_HDA_POWER_SAVE_DEFAULT=1). With audio controller+codec in runtime suspend, we should wake-up on jack-detect (but not if system is suspended)

[Vamshigopal]

I believe the PCI device will go to runtime suspend state, doesn't it?

@plbossart with snd-hda-intel driver PCI device is not going to runtime suspend.

localhost ~ # cat /sys/class/pci_bus/0000:00/device/0000:00:1f.3/power/runtime_enabled enabled localhost ~ # cat /sys/class/pci_bus/0000:00/device/0000:00:1f.3/power/runtime_status active

[Vamshigopal]

CONFIG_SND_HDA_POWER_SAVE_DEFAULT=1

with snd-hda-intel driver default value was 15 i changed it to 1 , still i see PCI device is active localhost ~ # cat /sys/class/pci_bus/0000:00/device/0000:00:1f.3/power/runtime_status active

[plbossart]

Well for any HDaudio problem the rule is that we want to see what happens without SOF.

Since without SOF there is no pm_runtime suspend, we have no means to compare or triangulate what happens.

So for now, it's just not possible to make any progress... You'll have to check WHY the snd-hda-intel keeps the device active and only then can we try to look at SOF issues.

[Vamshigopal]

@plbossart

So for now, it's just not possible to make any progress... You'll have to check WHY the snd-hda-intel keeps the device active and only then can we try to look at SOF issues.

I used options snd-sof-pci sof_pci_debug=0x01 to disable runtime PM with SOF driver , issue dont reproduce.

[ujfalusi]

I think this will enable rpm for the legacy stack:

options snd-hda-intel dyndbg=+pmf power_save=2 power_save_controller=1

This will cause rpm suspend after two seconds of inactivity.

[Vamshigopal]

options snd-hda-intel dyndbg=+pmf power_save=2 power_save_controller=1

This is not helping for rpm suspend.

[Vamshigopal]

After tested with latest chrome kernel ( https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/tags/v6.6.22), we observe that when we insert jack in rpm state it detects as headset playback device , it wont detect headset mic. Issue reproduces in 2/10 times.

[kv2019i]

I tested with today's sof-dev on a generic HDA system and jack detection works 10/10 with both legacy driver and SOF. Let's try to get snd-hda-intel driver going to suspend in your system, so we can exclude the DSP from this analysis. It is possible there's something in the kernel between sof-dev and 6.6.22, but that we can exclude by testing with snd-hda-intel.

[Vamshigopal]

options snd-hda-intel dyndbg=+pmf power_save=2 power_save_controller=1

This is not helping for rpm suspend.

Applied the above parameters in /etc/modprobe.d/*.conf and its not taking into effect , not sure on this.

But when we apply manually , its working

echo Y >/sys/module/snd_hda_intel/parameters/power_save_controller echo 2 >/sys/module/snd_hda_intel/parameters/power_save cat /sys/devices/pci0000:00/0000:00:1f.3/power/runtime_status suspended

Issue reproduces with legacy driver as well.

[plbossart]

I've lost the plot on this one @Vamshigopal @kv2019i @bardliao

Is this a case of missing verbs in CoreBoot?

[Vamshigopal]

Appologies for late update. After updating the verbs provided by realtek in coreboot. Issue is not reproducible.

Thanks @plbossart @kv2019i @ujfalusi for debug suggestions , I've learnt couple of new things from this bug.