Re: [PATCH] ALSA: hda - delay resume haswell hdmi codec in system resume

[David Henningsson <david.henningsson@canonical.com>]

On 03/27/2013 03:03 AM, Lin, Mengdong wrote:
>> -----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.

Right.

> 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.
https://launchpad.net/~diwic