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

[Lin, Mengdong]

> -----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?


> > 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.

Thanks
Mengdong