[alsa-devel] [PATCH] ALSA: hda - delay resume haswell hdmi codec in system resume
david.henningsson at canonical.com
Wed Mar 27 09:19:29 CET 2013
On 03/27/2013 03:03 AM, Lin, Mengdong wrote:
>> -----Original Message-----
>> From: alsa-devel-bounces at alsa-project.org
>> [mailto:alsa-devel-bounces at 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.
As for the timeout, I suggest you use the codec->bus->workq instead of
creating a new workq. I think that will also give us some serialisation,
i e, protection against race conditions if the timeout happen at the
same time as the unsol event.
> 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.
Hmm. I don't think there is any difference between the upstream default
and Ubuntu in this case. I remember we had to turn off power_save for
Pantherpoint once, before keep_power_link_on for PantherPoint was
discovered and upstreamed. But that was quite a while ago.
Then there is of course people playing with powertop and other tools, to
override the defaults.
David Henningsson, Canonical Ltd.
More information about the Alsa-devel