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

[David Henningsson]

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.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ALSA-hda-fixup-D3-pin-and-right-channel-mute-on-Hasw.patch
Type: text/x-patch
Size: 2893 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20130417/9eb5fc95/attachment.bin>