- Are snd_power_change_state() calls needed for runtime PM?
I think this is needed. It's because HW is actually in D3 when it's runtime
suspended and need a delay for transition back to D0. And there are operations that need HW in D0, such as snd_pcm_prepare().
Well, first off, PCM prepare will be never reached during runtime PM suspend.
Secondly, you seem to misunderstand the concept of snd_power_change_state(). It's for blocking the whole operations until the resume finished. In the case of runtime PM, the resume itself is triggered by the operation. Thus if you call snd_power_change_state(D3) in the runtime suspend, it'd deadlock, since the wake-up operation itself is blocked by that.
Hi Takashi,
You're right. snd_power_change_state() calls should be removed before runtime suspend/resume. I've not met deadlock before just because I used aplay so PCM open triggers resume at first without waiting the sound card back to D0.
Please if ignore my patch v2 because snd_power_change_state() has not been removed. Sorry, I missed your mail yesterday.
Thanks Mengdong