Hi David,
-----Original Message----- From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel-bounces@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@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@canonical.com] Sent: Friday, May 03, 2013 3:20 PM To: Lin, Mengdong Cc: Takashi Iwai; alsa-devel@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@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?
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.
Thanks Mengdong