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

[Takashi Iwai]

At Mon, 08 Apr 2013 13:35:25 +0200,
David Henningsson wrote:
> 
> On 04/08/2013 01:06 PM, Lin, Mengdong wrote:
> >> -----Original Message-----
> >> From: Takashi Iwai [mailto:tiwai at suse.de]
> >> Sent: Monday, April 08, 2013 6:24 PM
> >> To: David Henningsson
> >> Cc: Lin, Mengdong; alsa-devel at alsa-project.org
> >> Subject: Re: [alsa-devel] [PATCH] ALSA: hda - delay resume haswell hdmi codec
> >> in system resume
> >>
> >> At Mon, 08 Apr 2013 11:49:09 +0200,
> >> David Henningsson wrote:
> >>>
> >>> I'm still not understanding this patch.
> >>>
> >>> We of course cannot have a situation where HDMI jack detection is not
> >>> correctly working after S3, which looks like would be the case here?
> >>
> >> No.  The patch itself has nothing to do with the HDMI jack detection at all.
> >> This intrinsic unsol event is (according to Intel) guaranteed to be issued once at
> >> the audio codec initialization, at least for Haswell.
> 
> Well, if no process is using the HDMI codec actively, nothing will 
> initialize the resume, and the HDMI codec will not initialized at all, i 
> e, no unsol events enabled in the first place?

No, the intrinsic unsol event that is issued for this seems irrelevant
from the jack state (i.e. active usage).

> (The counter argument would be; if nobody uses HDMI codec, does it 
> matter that it is not initialized, but I'm unsure if e g "amixer 
> contents" or listeners on legacy /dev/input actually powers up the chip.)

The problem is that the codec resume is always performed no matter
whether the device is used or not.  This was different in the past but
it's been changed in that way because there are cases where you need
to initialize the hardware properly once (e.g. mute-LED toggling).


> >>> Second, I just saw on a machine we're working on, the symptoms: one of
> >>> the pins in D3 and the right channel muted. And this was on a clean
> >>> boot, not after S3 suspend/resume cycle.
> >>
> >> Maybe another problem.  Maybe not.  Does the problem persist if you reload
> >> the driver (without invocation of alsactl via udev)?
> >
> > Hi Takashi and David,
> >
> > This is the same dependency issue as after system suspend/resume cycles, with same phenomenon.
> > I duplicated this error if I boot without an HDMI/DP cable connected and connect the cable later.
> > Maybe we need to delay codec operations on initialization like in resume case.
> 
> So it's a problem both on hotplug and S3...

In the case of hotplug, you don't hit the inconsistent power sate
we're trying to solve.  The graphics has been already powered up.


> >>> To look at the problem again: If the problem is that something must be
> >>> done on the graphics driver side first and then on the audio side,
> >>> wouldn't the solution be for the video driver and audio driver to
> >>> communicate somehow?
> >>
> >> Yes, the pm domain support is necessary sooner or later, as I already discussed
> >> shortly with Dave Airlie.  However...
> >
> > Liam will propose Gfx driver team to implement a pm domain.
> >
> >>> And resume (and possibly init?) would not complete until first the
> >>> graphics driver has done its resume, and after that, the audio driver.
> >>> I e, userspace will remain frozen until both drivers have completed a
> >>> correct resume.
> >>
> >> ... the resume problem can't be fixed only by the usual pm domain serialization.
> >> The graphics initialization for the audio bit is done asynchronously, thus we
> >> can't guarantee the audio codec is really ready after the graphics driver returns
> >> from the resume callback.
> >> It shows as if it's ready (you can turn it to D0) but actually it doesn't change on
> >> the hardware.  Thus, the serialization with an unsol event wait seems
> >> mandatory for the time being.
> >>
> > It seems so. We have not found better solution now :-(
> > I've revised the patch for system suspend/resume case. Please review.
> 
> If this problem can be detected by looking at the pin and finding that 
> it is in D3,

No, you can't see that it's D3.  The controller chip _shows_ it's in
D0 while it's actually in D3.  That's the problem.

So, this is actually a hardware design bug.  But we need to live with
that.


Takashi

> can we extend the "try to set the pin 10 times" algorithm 
> in hda_set_power_state to check all the pins for haswell HDMI?