Repository navigation
[BUG][CML]Can't detect Mic jack of combo headset #1798
Description
Describe the bug
Plug in headset, the headphone jack can be detected, but the mic jack can seldom to be detected.
If prohibit the codec runtime auto-suspend, the headphone and mic jack can be detected normally.
If change to hda driver, the headphone jack and mic jack can be detected normally.
To Reproduce
Plugin headset
Reproduction Rate
Almost near to 100%
Expected behavior
Both headphone and mic jack can be detected.
Impact
Cannot record sound if plugin headset
Environment
- Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
- Kernel: a55aa89 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Tag: 5.3-rc6
- SOF: fcf6c8c https://github.com/thesofproject/sof.git Tag: v.1.4.1
- Name of the topology file
- Topology: sof-hda-generic-2ch.tplg
- Name of the platform(s) on which the bug is observed.
- Platform: A notebook with CometLake LP, codec ALC3247 and combo headset
Activity
juimonen commentedon Jan 14, 2020
@qinwan-hp #1689, this is probably the same...(?)
lgirdwood commentedon Jan 14, 2020
@qinwan-hp any chance you could try #1689 and see if it fixes the issue for you. I think Its a duplicate.
qinwan-hp commentedon Jan 15, 2020
@lgirdwood @juimonen I tried this method before and I still have chance without mic detected.
When wait dsp and codec suspended, plugin headset can duplicate this issue sometimes.
There is only unsol event for headphone jack, no unsol event for mic jack.
That's why I disable auto-suspend.
But if I disable auto-suspend, we found the DSP panic when kill/run pulseaudio several times.
I upload the dsp panic kernel log and sof trace.
dsp_firmware_panic.txt
sof_trace.txt
sof_etrace.txt
lgirdwood commentedon Jan 15, 2020
@qinwan-hp thanks for the info, this now looks like 2 issues :-
kv2019i commentedon Jan 15, 2020
@lgirdwood wrote:
I'm pretty certain this is fixed by #1689 . We have the fix candidate (but no agreement how this should be fixed in upstream yet). @qinwan-hp testing feedback on that pull-request is welcome. FYI @juimonen
qinwan-hp commentedon Jan 16, 2020
@juimonen Original we have hda with CONFIG_SND_HDA_POWER_SAVE_DEFAULT =0 on our platform, so hda is OK. Change config to CONFIG_SND_HDA_POWER_SAVE_DEFAULT = 2, I did see the same issue happend. But the failure rate is very low and can be igonored.
qinwan-hp commentedon Jan 16, 2020
juimonen commentedon Jan 16, 2020
@qinwan-hp so the value 0 for suspend disables the PM altogether, so the codec never goes to sleep -> detect works. I guess with certain values, like you mentioned 2s the detection might still fail occasionally. if pm_autosuspend is set, legacy HDA will set 3s suspend delay, so even longer than 2s.
There is a blacklist in legacy HDA for certain platforms that will never use PM, so they will be always on. So this platform looks/sounds like a candidate for a quirk, if it fails even with 2s delay.
Now with SOF we are currently not calling at all the suspend delay setting, so codec will go to suspend immediately/asap. I think this is a bug and we need to fix it in SOF. What value to set from SOF is a good question (so should we have quirks for platforms which don't work with 2s etc.).
qinwan-hp commentedon Jan 17, 2020
@juimonen I tried the kernel v5.4.1. The mic jack detction can work and still has failure but hard to reproduce. Our current kernel is v5.3.6.
juimonen commentedon Jan 17, 2020
@qinwan-hp ok thanks, did you test the new kernel with thesofproject/sof#1689 or without it?
qinwan-hp commentedon Jan 17, 2020
@juimonen With thesofproject/sof#1689. But I cannot figure out what's the difference between v5.3.6 and v5.4.1 that may lead to this issue. Do you have any comment ?
juimonen commentedon Jan 17, 2020
@qinwan-hp hmm ok, I can't think anything from top of my head... maybe we have some changes in the power management, but not sure... @ranj063 any idea?
slawblauciak commentedon Jan 21, 2020
@bkokoszx mind taking a look at it?
bkokoszx commentedon Jan 22, 2020
@lgirdwood @juimonen
I have a questions, as I'm not kernel expert. Is it correct that we have here in logs things like:
skl_hda_dsp_generic,snd_hda_codec_realtek. It seemed to me that we usually blacklist them during kernel building. Why does skylake appear in dmesg logs:Digital mics found on Skylake+ platform, using SOF driver? Also there appear some topology mismatches:Topology: ABI 3:12:0 Kernel ABI 3:8:0warn: topology ABI is more recent than kernellgirdwood commentedon Jan 22, 2020
@slawblauciak @bkokoszx this does not look like a FW issue so best let @juimonen look at it.
lgirdwood commentedon Jan 27, 2020
@juimonen @kv2019i any insights here on this one ? This looks like a kernel issue to me.
juimonen commentedon Jan 28, 2020
@lgirdwood @slawblauciak basically it seems that this issue is the same we have when not setting the PM suspend delay to HDA from SOF: #1689. In that PR we are setting suspend delay to 2s, but for example legacy HDA might set it even to 3s if not defined.
So if there is no suspend delay, HDA codec will suspend really fast, and in some codecs the mic detection takes time -> hence no mic detection.
I'm not sure if it is worth to start bisecting differences in kernel's if it works with the latest/greatest. There has been reports that with #1689 there can be detection issues at boot, otherwise it seems to work. The boot thing should be investigated and fixed separately, because I really think not setting suspend delay from SOF is a bug.
lgirdwood commentedon Jan 28, 2020
@juimonen ok, can you take care of this, I guess it all falls into userspace/kernel integration.
mengdonglin commentedon Feb 23, 2020
@qinwan-hp Can you please share your email here or on GitHub personal profile? We want to understand if this is a HP device and who can support from codec driver side. Thanks!
qinwan-hp commentedon Mar 20, 2020
We still do not enable runtime control to make jack detection work normally.
And the crash of FW can be fixed with latest version.