-----Original Message----- From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel-bounces@alsa-project.org] On Behalf Of David Henningsson Sent: Tuesday, March 26, 2013 6:58 PM
Just a question: Is there a difference between real system S3 here, and just the normal idle power down? I e, I'm a little unsure myself, but it seems like this 300 ms delay would trigger in both cases, causing an (unnecessary?) 300 ms delay every time the codec is idle and you want to start playback. Is this correct, or did I get something wrong?
Hi David,
Thanks for your feedback! There will not be 300ms delay every time in normal idle power down case.
Only the system resume will delay resuming a codec and cause a waiting on first codec access (eg. 1st playback ) after a system resume. Snd_hda_resume(), called by azx_resume(), will check whether a codec can support delay resume, skip these codecs and set the flag "resume_delayed" on them. Normal idle power down will not touch this flag.
The Haswell codec set_power_state ops (intel_haswell_set_power_state) will only wait if this is a delayed resume and clear this flag after waiting. And actually, there is no waiting even in this case. Because when 1st user operation after system resume happens, Gfx already finishes resuming and audio initialization, so as long as intel_haswell_wait_ready_to_resume() enable the unsol event, the unsol event comes and so so waiting finishes. The 300ms time out is set for safety consideration in case unsol event is lost. I've not observed any unsol event lost till now.
BTW, would you please tell us how Ubuntu decides whether to enable the normal idle power down (parameter "power_save")? We found this bug on a Haswell mobile machine with "power_save" disabled, which means only system resume will program the codec back to D0. But on a another machine with "power_save" enabled, this bug is not visible because later runtime codec power up can program the codec to D0 and unmute the pin again.
Thanks Mengdong