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