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

[David Henningsson]

On 05/06/2013 08:27 AM, Lin, Mengdong wrote:
> Hi David,
>
>> -----Original Message-----
>> From: alsa-devel-bounces at alsa-project.org
>> [mailto:alsa-devel-bounces at alsa-project.org] On Behalf Of Lin, Mengdong
>> Sent: Friday, May 03, 2013 3:30 PM
>> To: David Henningsson
>> Cc: Takashi Iwai; Li, Jocelyn; alsa-devel at alsa-project.org; Wang, Xingchao;
>> Girdwood, Liam R
>> Subject: Re: [alsa-devel] [PATCH] ALSA: hda - delay resume haswell hdmi codec
>> in system resume
>>
>>> -----Original Message-----
>>> From: David Henningsson [mailto:david.henningsson at canonical.com]
>>> Sent: Friday, May 03, 2013 3:20 PM
>>> To: Lin, Mengdong
>>> Cc: Takashi Iwai; alsa-devel at alsa-project.org; Girdwood, Liam R; Wang,
>>> Xingchao; Li, Jocelyn
>>> Subject: Re: [alsa-devel] [PATCH] ALSA: hda - delay resume haswell
>>> hdmi codec in system resume
>>>
>>> On 05/03/2013 08:56 AM, Lin, Mengdong wrote:
>>>> Hi Takashi and David,
>>>>
>>>>> -----Original Message-----
>>>>> From: Takashi Iwai [mailto:tiwai at suse.de]
>>>>> Sent: Wednesday, April 17, 2013 2:13 PM
>>>>> To: David Henningsson
>>>>> Cc: Lin, Mengdong; alsa-devel at 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?
>>
>> I think the pin configuration default should not be affected, as it's for BIOS
>> programming.
>>
>> The DDI port is bound to a HDMI or DP connector on the board.
>> And although the transcoder can be changed at runtime, the pin report the eld
>> info does not change.
>>
>> Anyway, we'll double check this issue.
>
> The pin configuration default will not change after the DDI port is connected to a different transcoder.
> I verified this on my haswell machine.

The core of the problem is that the DDI port can sometimes be connected 
to a transcoder that in turn is connected to an audio codec pin which 
default pin config is set to "not connected". In this case, audio will 
not work correctly. (It might sometimes work by accident.)

The solution is that DDI to transcoder connection cannot change, it must 
always be connected to the audio codec pin which is marked as "jack".

Btw, even if all audio codec pins are marked as "jack", it would be a 
bad habit to change the connection, because people will be confused when 
we show these pins to the user as e g "HDMI 1", "HDMI 2" and "HDMI 3", 
and which one is corresponding to the physical output is varying.

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