Hi,
On Thu, 8 Apr 2021, Takashi Iwai wrote:
OK, that's a messy problem, indeed. It's partly because of ASoC
referred resume that is completely independent from the rest resume
via HD-audio bus. More badly, this can't be managed via the device
link because the resume callback itself has been processed.
And, IIUC, another part of the problem is that i915 notifies the HPD
*after* the resume completion, right? Then indeed it can be racy.
yes, exactly.
Seems quite odd indeed, but I've now got reports of systems where this is
hit, and unfortunately it's very systematic on these systems. By adding
some arbitrary delay to soc_resume_deferred(), I could easily hit this
myself as well on the systems I have at hand.
Another possible fix would be to check dev->power.power_state instead
of the global card state. This is set in each PM callback in
hda_codec.c to indicate the current PM state of the codec. Something
like below. Let me know if this works, too.
Thanks, this works in my setup and is much cleaner. I think this is also
more robust. I realized that with snd_power_get_state() check, there is a
theoretical race still possible if notify comes before
soc_resume_deferred() gets scheduled (i.e. delay is not within
soc_resume_deferred() but in getting it scheduled to begin with). This
would seem really unlikely, but it's a possible race nevertheless.
I'll update the patch to use dev->power.power_state, ask people with
affected systems to double check, and I'll send a V2.
Br, Kai
