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

[Takashi Iwai]

At Wed, 17 Apr 2013 07:51:47 +0200,
David Henningsson wrote:
> 
> On 04/15/2013 09:48 AM, Lin, Mengdong wrote:
> >> -----Original Message-----
> >> From: David Henningsson [mailto:david.henningsson at canonical.com]
> >> Sent: Monday, April 15, 2013 3:03 PM
> >> To: Lin, Mengdong
> >> Cc: Takashi Iwai; alsa-devel at alsa-project.org; Girdwood, Liam R
> >> Subject: Re: [alsa-devel] [PATCH] ALSA: hda - delay resume haswell hdmi codec
> >> in system resume
> >>
> >> On 04/14/2013 03:48 PM, Lin, Mengdong wrote:
> >>> Hi David and Takashi,
> >>>
> >>> I'm sorry for the late response. I was assigned other tasks this week
> >>>
> >>> We don't have a better solution for this issue now, still trying.
> >>> The delay_resume() ops for a codec can help not delaying the unsol event. So
> >> our patch can solve the problem after system suspend/resume if the cable is
> >> connected.
> >>> But I'm afraid that if the HDMI/DP cable removed during system suspend
> >>> and connected again sometime after system is resumed, and if the codec
> >> access happens before the cable is connected, waiting for unsol event can be
> >> time out and codec cannot be properly resumed.
> >>> And if runtime power saving is also disabled, the audio driver has no chance to
> >> resume the codec again. I cannot verify such hot-plug case during
> >> system/suspend now because my Haswell machines cannot reach a stable S3
> >> and then resume.
> >>> But we do observed a similar bug: if cable is connected after boot, the pin is in
> >> D3 with right channel muted, as the codec is initialized before unsol event
> >> comes.
> >>> Audio driver cannot find a suitable time out to wait for the usnsol event as we
> >> don't know when the cable will be connected.
> >>
> >> Takashi's latest suggestion was to enable unsol events, and nothing else,
> >> directly on S3 resume. See suggested patch below.
> >>
> >> Will that not help here? Then we would at least get some unsol events on
> >> hotplug I assume?
> >
> > I think Takashi's patch can help when cable is connected during suspend/resume cycles.
> > This patch enables unsol event, so make sure unsol event won't be delayed.
> >
> > So shall I improve the patch as Takashi suggested, to solve current suspend/resume issue?
> 
> If you do, in what scenarios will this not be enough? I e, what will 
> still require more advanced synchronisation between gfx and audio driver 
> (as outlined below)?
> 
> >
> >
> >>> We'll try if we can fix this dependency issue in Gfx driver side, and by sync Gfx
> >> and audio driver processing.
> >>>
> >>> And we cannot implement pm domain atm. Last Thursday, we have a meeting
> >> with Gfx team, for Gfx power well support and audio dependency on Gfx.
> >>> Linux PM maintainer Rafael also attended the meeting. He suggested us not
> >> use pm domain now because it cannot fully support PCI devices (PM domains
> >> ops will override PCI bus ops). We will use and extend the existing private gfx
> >> driver API to control the powerwell and sequence the
> >> initialization/suspend/resume events between gfx and audio for internal
> >> releases. Once this is working well with the private API, we will then look at
> >> either implementing this functionality as PM domain or PM runtime depending
> >> on the best fit and upstream.
> >>>
> >>> I'm working on HD-A RTD3 for legacy audio in one or two weeks. After that,
> >> I'll continue to work on this issue.
> >>
> >> The dependency on the Gfx driver, is it both codec-wide and per pin? It seems to
> >> be at least per pin, which means that whenever we plug something in, we need
> >> to redo our initialization of that pin after the Gfx driver has finished, is that
> >> correct?
> >
> > We're still investigating the Gfx driver sequence.
> > In fact, not every hot plug will cause trouble. If the system is booted with cable connected, later hot-plug does not cause error, including switch between DP and HDMI cable.
> > The dependency issue only happens on boot and resume.
> > Since the hot-plug will also make Gfx reconfig the display pipeline, so we want to compare the difference and locate the accurate dependency.
> 
> It looks like this will take some time to implement, and the 3.10 merge 
> window will soon open. It also sounds like the complexity makes it 
> possible that a full fix can not be applied later during 3.10 rc cycle.
> 
> Takashi, may I ask you to apply the attached workaround in the mean 
> time? I've confirmed it to resolve the problem on at least two different 
> machines.

Yeah, looking through the development, I'm inclined to postpone the
delayed resume scheme for 3.10.  As a bandaid fix, I'm going to apply
David's patch for now.

IMO, the biggest concern in the current delayed resume implementation
is that we don't know how reliable the unsol event generation and
handling.  In other words, if the graphics driver can _always_ sets
and/or wakes up for the hardware readiness state, it'd be a much
better way to control; it's more deterministic.

Then we can implement, e.g. a platform device shared by both graphics
and audio drivers and let pm operations sync there, as Liam once
suggested.  This would work even w/o pm domain implementation (it's a
kind of own pm domain implementation, after all).


Takashi