[alsa-devel] [PATCH] ALSA: hda - PCH HDA controller not controlled by i915 power

[Yang, Libin]

+ Mengdong

Hi Takashi & David,

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai at suse.de]
> Sent: Tuesday, June 09, 2015 5:06 PM
> To: David Henningsson
> Cc: Yang, Libin; alsa-devel at alsa-project.org
> Subject: Re: [alsa-devel] [PATCH] ALSA: hda - PCH HDA controller not
> controlled by i915 power
> 
> At Tue, 09 Jun 2015 10:51:19 +0200,
> David Henningsson wrote:
> >
> >
> >
> > On 2015-06-09 10:30, Takashi Iwai wrote:
> > > At Tue, 09 Jun 2015 08:46:35 +0200,
> > > David Henningsson wrote:
> > >>
> > >>
> > >>
> > >> On 2015-06-09 08:31, Takashi Iwai wrote:
> > >>> At Tue,  9 Jun 2015 14:05:18 +0800,
> > >>> libin.yang at intel.com wrote:
> > >>>>
> > >>>> From: Libin Yang <libin.yang at intel.com>
> > >>>>
> > >>>> On some Intel platforms, the HDMI codec is connected to PCH
> HDA
> > >>>> controller. In this case, AZX_DCAPS_I915_POWERWELL is set
> and
> > >>>> the i915 power well failure should not block the hda controller
> > >>>> initialization.
> > >>>>
> > >>>> Signed-off-by: Libin Yang <libin.yang at intel.com>
> > >>>
> > >>> Is this fix needed for 4.1, or it's only for 4.2?
> > >>
> > >> It's a bug fix, and as such should go to all kernels, even with cc to
> > >> stable. That said, it mainly concerns Skylake, so kernels that don't
> > >> support Skylake would not need a backport.
> > >
> > > The patch can't be applied even to 4.1 as is because of the code
> > > structure change.  So, Cc to stable doesn't work, in anyway.
> > >
> > >>> I vaguely remember of a bug report.  If there is any relevant bug
> > >>> report, please give the link, too.
> > >>
> > >> I think this was raised to Intel by us. The use case is when the
> > >> integrated GPU is disabled and a discrete GPU is used. In this case
> the
> > >> i915 module fails to load. If then the HDMI and analog codec are
> both on
> > >> the same controller, the entire controller fails instead of just the
> > >> HDMI codec.
> > >>
> > >> I'll see if I can get the patch tested ASAP.
> > >
> > > OK, the bug seems needed for 4.1 and earlier.  But Libin's patch is
> > > only for 4.2.  And even worse, backporting this isn't
> > > straightforward due to the lack of need_i915_power field.  Hmm.
> > >
> > > I think we can make it easier by just allowing to continue the probe.
> > > A totally untested patch for 4.1 is below.
> >
> > As part of the wider discussion, I think we could continue instead of
> > failing also on Haswell and Broadwell. This is to some degree
> > hypothetical, but if the i915 module does not load for some reason,
> then
> > the i915 module would not turn the power well off either, so it
> remains
> > on the entire time (and then audio could potentially work).
> 
> Without graphics HDMI/DP never works, so practically it's useless.
> The problem can be reproduced easily by passing nomodeset boot
> option.
> 
> OTOH, it'd simplify the change, and this was indeed my initial patch
> before posting.  Then I thought this might lead to a regression; a
> non-working HDMI/DP sound card appears while it wasn't before.  So I
> added the check of HSW/BDW.
> 
> Meanwhile, nomodeset or failing i915 is a more or less special
> situation, so we might not consider about this behavior change so
> much, and take rather for the code simplicity.
> 
> Comments?

Yes, HDMI/DP depends on gfx.

BDW/HSW has 2 controllers: one is in power well, the other is not.
The one in powerwell connects HDMI/DP codec.
The one in PCH connects analog codec.

SKL/BSW/BYT has one controller and it connects both HDMI/DP codec
and analog codec.

So we get the conclusion:
1. whatever power well is turned on, BDW/HSW PCH HDA controller
will work.
2. If power well is turned off, BDW/HSW HDA controller in gfx will not
work.
3. if power well is turned off, SKL/BSW/BYT controller will work (analog
audio will use it), but HDMI/DP audio will not work.



> 
> 
> Takashi