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

[Takashi Iwai]

At Tue, 02 Apr 2013 13:53:16 +0200,
David Henningsson wrote:
> 
> On 03/27/2013 11:01 AM, Lin, Mengdong wrote:
> >> -----Original Message-----
> >> From: David Henningsson [mailto:david.henningsson at canonical.com]
> >> Sent: Wednesday, March 27, 2013 4:19 PM
> >
> >>> 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.
> >
> > Hi David,
> >
> > The new added "resume_wq" for hdmi codec is a wait queue, not a work queue like codec->bus->workq.
> > It's expected to wake up as soon as the unsol event is got.
> 
> Sure; but I don't see why you need a wait queue for that? Why don't you 
> just call the resume path from the unsol event handler 
> (hdmi_present_sense, or its caller), and then also cancel the timeout 
> handler (which can then be in the normal workq)?

Because the delayed resume actually fakes as if the resume is done.
This is necessary not to block other device's resume operation.

Since it looks as if ready, user-space might restart things soon again
before the delayed resume is really finished.  So, some serialization
is required there.


Takashi