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

[David Henningsson <david.henningsson@canonical.com>]

On 05/03/2013 08:56 AM, Lin, Mengdong wrote:
> Hi Takashi and David,
>
>> -----Original Message-----
>> From: Takashi Iwai [mailto:tiwai@suse.de]
>> Sent: Wednesday, April 17, 2013 2:13 PM
>> To: David Henningsson
>> Cc: Lin, Mengdong; alsa-devel@alsa-project.org; Girdwood, Liam R
>> Subject: Re: [alsa-devel] [PATCH] ALSA: hda - delay resume haswell hdmi codec
>> in system resume
>>
>> At Wed, 17 Apr 2013 07:51:47 +0200,
>> David Henningsson wrote:
>>>>> 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?
>
> It was confirmed that this a per pin dependency, not codec-wide.
>
> For Haswell, every pin is in D3 with amplifier muted by default.
> The audio driver must program the pin to D0 and unmute the pin, after the gfx driver connect the GPU pipe and port, and enable the transcoder
> (The transcoder is the component where audio is mixed with video).
> Otherwise, the pin's default power and mute state will not change, by checking the Gfx side audio register, although audio codec does not report error.
>
> In addition, HDMI/DP cable hot plug will trigger Gfx driver to disconnect/connect the pipeline, and port may be connected to a new transcoder.
> If the transcoder has changed, the pin can return to D3 and muted again. There are 3 pipelines in GPU, a pipe/port connection only affects one pin, not the other pins and convertors.
> So our previous patch to delay powering up the whole codec once is not enough and not suitable.

This makes me a bit worried actually. If the transcoder to port 
connection can be changed at runtime, how does this affect the default 
pin config on the audio codec pin node?

E g, if the machine only has one physical HDMI output, it would be a 
good thing to mark only one of the pin nodes as a "jack" and the other 
two as "not connected".

Now, if the transcoder used for this HDMI output is varying, it can be 
sometimes not matching the audio codec pin node set to "jack", and then 
we have a problem...!

Or is the gfx engine taking the default pin config of the audio codec 
into account somehow?

>
> Since audio driver does not and should not have any knowledge how GfX maniplute the display pipeline.
> The unsolicited event can be used to as flag that the pin widget is ready to power up.
>
> And because the unsol event can happen at D3 and it not necessarily to power up the pin at once on the unsol event,
> we prefer to check and fix the pin state when a PCM stream is setting up. This can also avoid race in PM.
>
> We also checked the info frame. Current mechanism to check and refresh audio info frame works well.
>
> So David's patch is a reliable fix to solve the display audio dependency issue. There is no need to write a new patch atm.
>
> Thanks
> Mengdong
>
>>> 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).
>
>
>
>



-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic