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

[Lin, Mengdong]

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. 

Thanks
Mengdong