| Message ID | 1427440204-49331-1-git-send-email-libin.yang@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
At Fri, 27 Mar 2015 15:10:04 +0800, libin.yang@intel.com wrote: > > From: Libin Yang <libin.yang@intel.com> > > HDMI/DP codec on SKL is in the power well. > The power well must be turned on before probing the > HDMI/DP codec. > > Signed-off-by: Libin Yang <libin.yang@intel.com> So, was the previous question clarified? This certainly sucks. It means that the powerwell is on even you don't use the HDMI/DP at all. If this is intended as a temporarily workaround, it should be mentioned so. Please give more comments and backgrounds. thanks, Takashi > --- > sound/pci/hda/hda_intel.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c > index 15a8299..4744a96 100644 > --- a/sound/pci/hda/hda_intel.c > +++ b/sound/pci/hda/hda_intel.c > @@ -298,7 +298,8 @@ enum { > AZX_DCAPS_SNOOP_TYPE(SCH)) > > #define AZX_DCAPS_INTEL_SKYLAKE \ > - (AZX_DCAPS_INTEL_PCH | AZX_DCAPS_SEPARATE_STREAM_TAG) > + (AZX_DCAPS_INTEL_PCH | AZX_DCAPS_SEPARATE_STREAM_TAG |\ > + AZX_DCAPS_I915_POWERWELL) > > /* quirks for ATI SB / AMD Hudson */ > #define AZX_DCAPS_PRESET_ATI_SB \ > -- > 1.9.1 >
Hi Takashi, > -----Original Message----- > From: Takashi Iwai [mailto:tiwai@suse.de] > Sent: Friday, March 27, 2015 3:57 PM > To: Yang, Libin > Cc: alsa-devel@alsa-project.org > Subject: Re: [PATCH] ALSA: hda_intel: add > AZX_DCAPS_I915_POWERWELL for skl > > At Fri, 27 Mar 2015 15:10:04 +0800, > libin.yang@intel.com wrote: > > > > From: Libin Yang <libin.yang@intel.com> > > > > HDMI/DP codec on SKL is in the power well. > > The power well must be turned on before probing the > > HDMI/DP codec. > > > > Signed-off-by: Libin Yang <libin.yang@intel.com> > > So, was the previous question clarified? Yes, I have confirmed with our silicon team. > > This certainly sucks. It means that the powerwell is on even you > don't use the HDMI/DP at all. If this is intended as a temporarily > workaround, it should be mentioned so. Please give more comments > and > backgrounds. Yes, as this is added in the skl audio controller, even there is no HDMI/DP codec, we should also add this flag. Otherwise the HDMI/DP codec may not be detected correctly. > > > thanks, > > Takashi Regards, Libin > > > --- > > sound/pci/hda/hda_intel.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c > > index 15a8299..4744a96 100644 > > --- a/sound/pci/hda/hda_intel.c > > +++ b/sound/pci/hda/hda_intel.c > > @@ -298,7 +298,8 @@ enum { > > AZX_DCAPS_SNOOP_TYPE(SCH)) > > > > #define AZX_DCAPS_INTEL_SKYLAKE \ > > - (AZX_DCAPS_INTEL_PCH | > AZX_DCAPS_SEPARATE_STREAM_TAG) > > + (AZX_DCAPS_INTEL_PCH | > AZX_DCAPS_SEPARATE_STREAM_TAG |\ > > + AZX_DCAPS_I915_POWERWELL) > > > > /* quirks for ATI SB / AMD Hudson */ > > #define AZX_DCAPS_PRESET_ATI_SB \ > > -- > > 1.9.1 > >
At Fri, 27 Mar 2015 08:02:54 +0000, Yang, Libin wrote: > > Hi Takashi, > > > > > -----Original Message----- > > From: Takashi Iwai [mailto:tiwai@suse.de] > > Sent: Friday, March 27, 2015 3:57 PM > > To: Yang, Libin > > Cc: alsa-devel@alsa-project.org > > Subject: Re: [PATCH] ALSA: hda_intel: add > > AZX_DCAPS_I915_POWERWELL for skl > > > > At Fri, 27 Mar 2015 15:10:04 +0800, > > libin.yang@intel.com wrote: > > > > > > From: Libin Yang <libin.yang@intel.com> > > > > > > HDMI/DP codec on SKL is in the power well. > > > The power well must be turned on before probing the > > > HDMI/DP codec. > > > > > > Signed-off-by: Libin Yang <libin.yang@intel.com> > > > > So, was the previous question clarified? > > Yes, I have confirmed with our silicon team. > > > > > This certainly sucks. It means that the powerwell is on even you > > don't use the HDMI/DP at all. If this is intended as a temporarily > > workaround, it should be mentioned so. Please give more comments > > and > > backgrounds. > > Yes, as this is added in the skl audio controller, even there is no HDMI/DP > codec, we should also add this flag. Otherwise the HDMI/DP codec > may not be detected correctly. But it's possible to do it only at probing, not permanently. If so, we'll have another patch in future. Please write more information in the changelog and resubmit. Takashi
Hi Takashi, > -----Original Message----- > From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel- > bounces@alsa-project.org] On Behalf Of Takashi Iwai > Sent: Friday, March 27, 2015 4:19 PM > To: Yang, Libin > Cc: alsa-devel@alsa-project.org > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > AZX_DCAPS_I915_POWERWELL for skl > > At Fri, 27 Mar 2015 08:02:54 +0000, > Yang, Libin wrote: > > > > Hi Takashi, > > > > > > > > > -----Original Message----- > > > From: Takashi Iwai [mailto:tiwai@suse.de] > > > Sent: Friday, March 27, 2015 3:57 PM > > > To: Yang, Libin > > > Cc: alsa-devel@alsa-project.org > > > Subject: Re: [PATCH] ALSA: hda_intel: add > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > At Fri, 27 Mar 2015 15:10:04 +0800, > > > libin.yang@intel.com wrote: > > > > > > > > From: Libin Yang <libin.yang@intel.com> > > > > > > > > HDMI/DP codec on SKL is in the power well. > > > > The power well must be turned on before probing the > > > > HDMI/DP codec. > > > > > > > > Signed-off-by: Libin Yang <libin.yang@intel.com> > > > > > > So, was the previous question clarified? > > > > Yes, I have confirmed with our silicon team. > > > > > > > > This certainly sucks. It means that the powerwell is on even you > > > don't use the HDMI/DP at all. If this is intended as a temporarily > > > workaround, it should be mentioned so. Please give more > comments > > > and > > > backgrounds. > > > > Yes, as this is added in the skl audio controller, even there is no > HDMI/DP > > codec, we should also add this flag. Otherwise the HDMI/DP codec > > may not be detected correctly. > > But it's possible to do it only at probing, not permanently. If so, > we'll have another patch in future. > > Please write more information in the changelog and resubmit. Do you mean to add more description in the patch comments? Regards, Libin > > > Takashi > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
At Fri, 27 Mar 2015 08:25:52 +0000, Yang, Libin wrote: > > Hi Takashi, > > > > -----Original Message----- > > From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel- > > bounces@alsa-project.org] On Behalf Of Takashi Iwai > > Sent: Friday, March 27, 2015 4:19 PM > > To: Yang, Libin > > Cc: alsa-devel@alsa-project.org > > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > > AZX_DCAPS_I915_POWERWELL for skl > > > > At Fri, 27 Mar 2015 08:02:54 +0000, > > Yang, Libin wrote: > > > > > > Hi Takashi, > > > > > > > > > > > > > -----Original Message----- > > > > From: Takashi Iwai [mailto:tiwai@suse.de] > > > > Sent: Friday, March 27, 2015 3:57 PM > > > > To: Yang, Libin > > > > Cc: alsa-devel@alsa-project.org > > > > Subject: Re: [PATCH] ALSA: hda_intel: add > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > At Fri, 27 Mar 2015 15:10:04 +0800, > > > > libin.yang@intel.com wrote: > > > > > > > > > > From: Libin Yang <libin.yang@intel.com> > > > > > > > > > > HDMI/DP codec on SKL is in the power well. > > > > > The power well must be turned on before probing the > > > > > HDMI/DP codec. > > > > > > > > > > Signed-off-by: Libin Yang <libin.yang@intel.com> > > > > > > > > So, was the previous question clarified? > > > > > > Yes, I have confirmed with our silicon team. > > > > > > > > > > > This certainly sucks. It means that the powerwell is on even you > > > > don't use the HDMI/DP at all. If this is intended as a temporarily > > > > workaround, it should be mentioned so. Please give more > > comments > > > > and > > > > backgrounds. > > > > > > Yes, as this is added in the skl audio controller, even there is no > > HDMI/DP > > > codec, we should also add this flag. Otherwise the HDMI/DP codec > > > may not be detected correctly. > > > > But it's possible to do it only at probing, not permanently. If so, > > we'll have another patch in future. > > > > Please write more information in the changelog and resubmit. > > Do you mean to add more description in the patch comments? Yes. The hardware design is different from HSW/BDW, thus applying this isn't straightforward but just a workaround. I don't know whether you think it's a temporary workaround or a permanent fix. Such information must be written there, too. Takashi
Hi Takashi, > -----Original Message----- > From: Takashi Iwai [mailto:tiwai@suse.de] > Sent: Friday, March 27, 2015 4:30 PM > To: Yang, Libin > Cc: alsa-devel@alsa-project.org > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > AZX_DCAPS_I915_POWERWELL for skl > > At Fri, 27 Mar 2015 08:25:52 +0000, > Yang, Libin wrote: > > > > Hi Takashi, > > > > > > > -----Original Message----- > > > From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel- > > > bounces@alsa-project.org] On Behalf Of Takashi Iwai > > > Sent: Friday, March 27, 2015 4:19 PM > > > To: Yang, Libin > > > Cc: alsa-devel@alsa-project.org > > > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > At Fri, 27 Mar 2015 08:02:54 +0000, > > > Yang, Libin wrote: > > > > > > > > Hi Takashi, > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Takashi Iwai [mailto:tiwai@suse.de] > > > > > Sent: Friday, March 27, 2015 3:57 PM > > > > > To: Yang, Libin > > > > > Cc: alsa-devel@alsa-project.org > > > > > Subject: Re: [PATCH] ALSA: hda_intel: add > > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > > > At Fri, 27 Mar 2015 15:10:04 +0800, > > > > > libin.yang@intel.com wrote: > > > > > > > > > > > > From: Libin Yang <libin.yang@intel.com> > > > > > > > > > > > > HDMI/DP codec on SKL is in the power well. > > > > > > The power well must be turned on before probing the > > > > > > HDMI/DP codec. > > > > > > > > > > > > Signed-off-by: Libin Yang <libin.yang@intel.com> > > > > > > > > > > So, was the previous question clarified? > > > > > > > > Yes, I have confirmed with our silicon team. > > > > > > > > > > > > > > This certainly sucks. It means that the powerwell is on even > you > > > > > don't use the HDMI/DP at all. If this is intended as a temporarily > > > > > workaround, it should be mentioned so. Please give more > > > comments > > > > > and > > > > > backgrounds. > > > > > > > > Yes, as this is added in the skl audio controller, even there is no > > > HDMI/DP > > > > codec, we should also add this flag. Otherwise the HDMI/DP > codec > > > > may not be detected correctly. > > > > > > But it's possible to do it only at probing, not permanently. If so, > > > we'll have another patch in future. > > > > > > Please write more information in the changelog and resubmit. > > > > Do you mean to add more description in the patch comments? > > Yes. The hardware design is different from HSW/BDW, thus applying > this isn't straightforward but just a workaround. I don't know > whether you think it's a temporary workaround or a permanent fix. > Such information must be written there, too. OK. I see. It seems we need more input from our silicon team for this issue. > > > Takashi Regards, Libin
Hi Takashi, > -----Original Message----- > From: Yang, Libin > Sent: Friday, March 27, 2015 4:34 PM > To: Takashi Iwai > Cc: alsa-devel@alsa-project.org > Subject: RE: [alsa-devel] [PATCH] ALSA: hda_intel: add > AZX_DCAPS_I915_POWERWELL for skl > > Hi Takashi, > > > > > -----Original Message----- > > From: Takashi Iwai [mailto:tiwai@suse.de] > > Sent: Friday, March 27, 2015 4:30 PM > > To: Yang, Libin > > Cc: alsa-devel@alsa-project.org > > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > > AZX_DCAPS_I915_POWERWELL for skl > > > > At Fri, 27 Mar 2015 08:25:52 +0000, > > Yang, Libin wrote: > > > > > > Hi Takashi, > > > > > > > > > > -----Original Message----- > > > > From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel- > > > > bounces@alsa-project.org] On Behalf Of Takashi Iwai > > > > Sent: Friday, March 27, 2015 4:19 PM > > > > To: Yang, Libin > > > > Cc: alsa-devel@alsa-project.org > > > > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > At Fri, 27 Mar 2015 08:02:54 +0000, > > > > Yang, Libin wrote: > > > > > > > > > > Hi Takashi, > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Takashi Iwai [mailto:tiwai@suse.de] > > > > > > Sent: Friday, March 27, 2015 3:57 PM > > > > > > To: Yang, Libin > > > > > > Cc: alsa-devel@alsa-project.org > > > > > > Subject: Re: [PATCH] ALSA: hda_intel: add > > > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > > > > > At Fri, 27 Mar 2015 15:10:04 +0800, > > > > > > libin.yang@intel.com wrote: > > > > > > > > > > > > > > From: Libin Yang <libin.yang@intel.com> > > > > > > > > > > > > > > HDMI/DP codec on SKL is in the power well. > > > > > > > The power well must be turned on before probing the > > > > > > > HDMI/DP codec. > > > > > > > > > > > > > > Signed-off-by: Libin Yang <libin.yang@intel.com> > > > > > > > > > > > > So, was the previous question clarified? > > > > > > > > > > Yes, I have confirmed with our silicon team. > > > > > > > > > > > > > > > > > This certainly sucks. It means that the powerwell is on even > > you > > > > > > don't use the HDMI/DP at all. If this is intended as a > temporarily > > > > > > workaround, it should be mentioned so. Please give more > > > > comments > > > > > > and > > > > > > backgrounds. > > > > > > > > > > Yes, as this is added in the skl audio controller, even there is no > > > > HDMI/DP > > > > > codec, we should also add this flag. Otherwise the HDMI/DP > > codec > > > > > may not be detected correctly. > > > > > > > > But it's possible to do it only at probing, not permanently. If so, > > > > we'll have another patch in future. > > > > > > > > Please write more information in the changelog and resubmit. > > > > > > Do you mean to add more description in the patch comments? > > > > Yes. The hardware design is different from HSW/BDW, thus applying > > this isn't straightforward but just a workaround. I don't know > > whether you think it's a temporary workaround or a permanent fix. > > Such information must be written there, too. > > OK. I see. It seems we need more input from our silicon team > for this issue. From our silicon team's comment, it seems we need power on the powerwell when detecting and probing the HDMI codec. For the skl case (HDMI codec is in powerwell, while controller not), my thinking is: 1. power on the power well 2. read STATESTS to determine the codec_mask 3. if codec is not present, power off the power well and remove the flag. (seems we need a new flag) 4. if codec is present, we will power on the power well when dealing with HDMI codec. What do you think? > > > > > > > Takashi > > Regards, > Libin Regards, Libin
On 2015-03-30 04:47, Yang, Libin wrote: > From our silicon team's comment, it seems we need power on > the powerwell when detecting and probing the HDMI codec. > > For the skl case (HDMI codec is in powerwell, while controller not), > my thinking is: > > 1. power on the power well > 2. read STATESTS to determine the codec_mask > 3. if codec is not present, power off the power well > and remove the flag. (seems we need a new flag) > 4. if codec is present, we will power on the power well > when dealing with HDMI codec. > > What do you think? Side question - do you know if it's the same for braswell? I e, the HDMI codec is in the powerwell but the controller is not?
Hi David, > -----Original Message----- > From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel- > bounces@alsa-project.org] On Behalf Of David Henningsson > Sent: Wednesday, April 01, 2015 3:31 PM > To: Yang, Libin; 'Takashi Iwai' > Cc: 'alsa-devel@alsa-project.org' > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > AZX_DCAPS_I915_POWERWELL for skl > > > > On 2015-03-30 04:47, Yang, Libin wrote: > > From our silicon team's comment, it seems we need power on > > the powerwell when detecting and probing the HDMI codec. > > > > For the skl case (HDMI codec is in powerwell, while controller not), > > my thinking is: > > > > 1. power on the power well > > 2. read STATESTS to determine the codec_mask > > 3. if codec is not present, power off the power well > > and remove the flag. (seems we need a new flag) > > 4. if codec is present, we will power on the power well > > when dealing with HDMI codec. > > > > What do you think? > > Side question - do you know if it's the same for braswell? I e, the HDMI > codec is in the powerwell but the controller is not? Yes, BSW has the same issue. At first, my thinking is: 1. define a new flag, power on the power well if flag is set 2. read STATESTS to determine the codec_mask 3. if codec is not present, power off the power well and remove the flag. 4. after initialization, power off the power well if new flag is set and AZX_DCAPS_I915_POWERWELL is not set 5. power on power well when pcm open 6. power off the power well when pcm close After a second thought, the method may have limitation: the codec may send the unsolicited responses. So my currently thinking is: If the codec is in powerwell, the behavior is like the flag AZX_DCAPS_I915_POWERWELL: always power on unless suspend. This method may cause power consumption. But consider normally audio will be in suspend state in most case. > > -- > David Henningsson, Canonical Ltd. > https://launchpad.net/~diwic > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On 2015-04-01 10:00, Yang, Libin wrote: > Hi David, > >> -----Original Message----- >> From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel- >> bounces@alsa-project.org] On Behalf Of David Henningsson >> Sent: Wednesday, April 01, 2015 3:31 PM >> To: Yang, Libin; 'Takashi Iwai' >> Cc: 'alsa-devel@alsa-project.org' >> Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add >> AZX_DCAPS_I915_POWERWELL for skl >> >> >> >> On 2015-03-30 04:47, Yang, Libin wrote: >>> From our silicon team's comment, it seems we need power on >>> the powerwell when detecting and probing the HDMI codec. >>> >>> For the skl case (HDMI codec is in powerwell, while controller not), >>> my thinking is: >>> >>> 1. power on the power well >>> 2. read STATESTS to determine the codec_mask >>> 3. if codec is not present, power off the power well >>> and remove the flag. (seems we need a new flag) >>> 4. if codec is present, we will power on the power well >>> when dealing with HDMI codec. >>> >>> What do you think? >> >> Side question - do you know if it's the same for braswell? I e, the HDMI >> codec is in the powerwell but the controller is not? > > Yes, BSW has the same issue. > > At first, my thinking is: > 1. define a new flag, power on the power well if flag is set > 2. read STATESTS to determine the codec_mask > 3. if codec is not present, power off the power well > and remove the flag. > 4. after initialization, power off the power well if new flag > is set and AZX_DCAPS_I915_POWERWELL is not set > 5. power on power well when pcm open > 6. power off the power well when pcm close ...and we're opening the right codec - in case of analog playback, the powerwell can still be off, right? > After a second thought, the method may have limitation: > the codec may send the unsolicited responses. > > So my currently thinking is: > If the codec is in powerwell, the behavior is like the flag > AZX_DCAPS_I915_POWERWELL: always power on unless > suspend. > This method may cause power consumption. But consider > normally audio will be in suspend state in most case. Ok, thanks for the clarification. I was wondering - the reason the codec might send unsol events is just due to hotplug events, right? And these unsol events are triggered by the i915 side by setting some registers, right? Is it then possible that i915, when it detects a video hotplug event, can increment the powerwell counter (so that the powerwell is turned on), trigger the hotplug event to the audio side, and then decrement the powerwell again (possibly with a few seconds delay if needed)? The idea is that once the audio side has got the hotplug event, it can turn on and off the powerwell itself. We just need the i915 driver to turn it on for us to get the hotplug event through.
Hi David, > -----Original Message----- > From: David Henningsson [mailto:david.henningsson@canonical.com] > Sent: Wednesday, April 01, 2015 4:12 PM > To: Yang, Libin; 'Takashi Iwai' > Cc: 'alsa-devel@alsa-project.org' > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > AZX_DCAPS_I915_POWERWELL for skl > > > > On 2015-04-01 10:00, Yang, Libin wrote: > > Hi David, > > > >> -----Original Message----- > >> From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel- > >> bounces@alsa-project.org] On Behalf Of David Henningsson > >> Sent: Wednesday, April 01, 2015 3:31 PM > >> To: Yang, Libin; 'Takashi Iwai' > >> Cc: 'alsa-devel@alsa-project.org' > >> Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > >> AZX_DCAPS_I915_POWERWELL for skl > >> > >> > >> > >> On 2015-03-30 04:47, Yang, Libin wrote: > >>> From our silicon team's comment, it seems we need power on > >>> the powerwell when detecting and probing the HDMI codec. > >>> > >>> For the skl case (HDMI codec is in powerwell, while controller not), > >>> my thinking is: > >>> > >>> 1. power on the power well > >>> 2. read STATESTS to determine the codec_mask > >>> 3. if codec is not present, power off the power well > >>> and remove the flag. (seems we need a new flag) > >>> 4. if codec is present, we will power on the power well > >>> when dealing with HDMI codec. > >>> > >>> What do you think? > >> > >> Side question - do you know if it's the same for braswell? I e, the > HDMI > >> codec is in the powerwell but the controller is not? > > > > Yes, BSW has the same issue. > > > > At first, my thinking is: > > 1. define a new flag, power on the power well if flag is set > > 2. read STATESTS to determine the codec_mask > > 3. if codec is not present, power off the power well > > and remove the flag. > > 4. after initialization, power off the power well if new flag > > is set and AZX_DCAPS_I915_POWERWELL is not set > > 5. power on power well when pcm open > > 6. power off the power well when pcm close > > ...and we're opening the right codec - in case of analog playback, the > powerwell can still be off, right? > > > After a second thought, the method may have limitation: > > the codec may send the unsolicited responses. > > > > So my currently thinking is: > > If the codec is in powerwell, the behavior is like the flag > > AZX_DCAPS_I915_POWERWELL: always power on unless > > suspend. > > This method may cause power consumption. But consider > > normally audio will be in suspend state in most case. > > Ok, thanks for the clarification. I was wondering - the reason the codec > might send unsol events is just due to hotplug events, right? > > And these unsol events are triggered by the i915 side by setting some > registers, right? > > Is it then possible that i915, when it detects a video hotplug event, > can increment the powerwell counter (so that the powerwell is turned > on), trigger the hotplug event to the audio side, and then decrement > the > powerwell again (possibly with a few seconds delay if needed)? > > The idea is that once the audio side has got the hotplug event, it can > turn on and off the powerwell itself. We just need the i915 driver to > turn it on for us to get the hotplug event through. Normally, it's the hotplug unsol event. But sometimes, I found on SKL, when suspending, there is some strange event sending from hdmi codec. And the controller will fallback to single cmd mode. Then the analog audio will be impacted after resume. BSW may also have this issue. But I didn't find it on our RVP board. I will test power on power well during unsol events. > > -- > David Henningsson, Canonical Ltd. > https://launchpad.net/~diwic Regards, Libin
On 2015-04-01 23:55, Yang, Libin wrote: > Hi David, > > > >> -----Original Message----- >> From: David Henningsson [mailto:david.henningsson@canonical.com] >> Sent: Wednesday, April 01, 2015 4:12 PM >> To: Yang, Libin; 'Takashi Iwai' >> Cc: 'alsa-devel@alsa-project.org' >> Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add >> AZX_DCAPS_I915_POWERWELL for skl >> >> >> >> On 2015-04-01 10:00, Yang, Libin wrote: >>> Hi David, >>> >>>> -----Original Message----- >>>> From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel- >>>> bounces@alsa-project.org] On Behalf Of David Henningsson >>>> Sent: Wednesday, April 01, 2015 3:31 PM >>>> To: Yang, Libin; 'Takashi Iwai' >>>> Cc: 'alsa-devel@alsa-project.org' >>>> Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add >>>> AZX_DCAPS_I915_POWERWELL for skl >>>> >>>> >>>> >>>> On 2015-03-30 04:47, Yang, Libin wrote: >>>>> From our silicon team's comment, it seems we need power on >>>>> the powerwell when detecting and probing the HDMI codec. >>>>> >>>>> For the skl case (HDMI codec is in powerwell, while controller not), >>>>> my thinking is: >>>>> >>>>> 1. power on the power well >>>>> 2. read STATESTS to determine the codec_mask >>>>> 3. if codec is not present, power off the power well >>>>> and remove the flag. (seems we need a new flag) >>>>> 4. if codec is present, we will power on the power well >>>>> when dealing with HDMI codec. >>>>> >>>>> What do you think? >>>> >>>> Side question - do you know if it's the same for braswell? I e, the >> HDMI >>>> codec is in the powerwell but the controller is not? >>> >>> Yes, BSW has the same issue. >>> >>> At first, my thinking is: >>> 1. define a new flag, power on the power well if flag is set >>> 2. read STATESTS to determine the codec_mask >>> 3. if codec is not present, power off the power well >>> and remove the flag. >>> 4. after initialization, power off the power well if new flag >>> is set and AZX_DCAPS_I915_POWERWELL is not set >>> 5. power on power well when pcm open >>> 6. power off the power well when pcm close >> >> ...and we're opening the right codec - in case of analog playback, the >> powerwell can still be off, right? >> >>> After a second thought, the method may have limitation: >>> the codec may send the unsolicited responses. >>> >>> So my currently thinking is: >>> If the codec is in powerwell, the behavior is like the flag >>> AZX_DCAPS_I915_POWERWELL: always power on unless >>> suspend. >>> This method may cause power consumption. But consider >>> normally audio will be in suspend state in most case. >> >> Ok, thanks for the clarification. I was wondering - the reason the codec >> might send unsol events is just due to hotplug events, right? >> >> And these unsol events are triggered by the i915 side by setting some >> registers, right? >> >> Is it then possible that i915, when it detects a video hotplug event, >> can increment the powerwell counter (so that the powerwell is turned >> on), trigger the hotplug event to the audio side, and then decrement >> the >> powerwell again (possibly with a few seconds delay if needed)? >> >> The idea is that once the audio side has got the hotplug event, it can >> turn on and off the powerwell itself. We just need the i915 driver to >> turn it on for us to get the hotplug event through. > > Normally, it's the hotplug unsol event. But sometimes, I found on > SKL, when suspending, there is some strange event sending > from hdmi codec. And the controller will fallback to single cmd > mode. Then the analog audio will be impacted after resume. > > BSW may also have this issue. But I didn't find it on our RVP board. > > I will test power on power well during unsol events. Ok. I wonder if it is possible to stop this "strange event", either because it's a hardware/firmware bug that could be fixed in later revisions of the hardware/firmware, or if there is some register we could write to (or even stop writing to!) on the i915 side that stops the unsol events. Or as a last resort, if we can't stop the "strange event", maybe there's some way the audio side could handle the "strange event" more gracefully so we don't fall back to single cmd mode when this happens. (I don't know much about this "strange event" so I'm just guessing here)
Hi David, > -----Original Message----- > From: David Henningsson [mailto:david.henningsson@canonical.com] > Sent: Thursday, April 02, 2015 2:52 PM > To: Yang, Libin; 'Takashi Iwai' > Cc: 'alsa-devel@alsa-project.org' > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > AZX_DCAPS_I915_POWERWELL for skl > > > > On 2015-04-01 23:55, Yang, Libin wrote: > > Hi David, > > > > > > > >> -----Original Message----- > >> From: David Henningsson > [mailto:david.henningsson@canonical.com] > >> Sent: Wednesday, April 01, 2015 4:12 PM > >> To: Yang, Libin; 'Takashi Iwai' > >> Cc: 'alsa-devel@alsa-project.org' > >> Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > >> AZX_DCAPS_I915_POWERWELL for skl > >> > >> > >> > >> On 2015-04-01 10:00, Yang, Libin wrote: > >>> Hi David, > >>> > >>>> -----Original Message----- > >>>> From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel- > >>>> bounces@alsa-project.org] On Behalf Of David Henningsson > >>>> Sent: Wednesday, April 01, 2015 3:31 PM > >>>> To: Yang, Libin; 'Takashi Iwai' > >>>> Cc: 'alsa-devel@alsa-project.org' > >>>> Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > >>>> AZX_DCAPS_I915_POWERWELL for skl > >>>> > >>>> > >>>> > >>>> On 2015-03-30 04:47, Yang, Libin wrote: > >>>>> From our silicon team's comment, it seems we need power on > >>>>> the powerwell when detecting and probing the HDMI codec. > >>>>> > >>>>> For the skl case (HDMI codec is in powerwell, while controller > not), > >>>>> my thinking is: > >>>>> > >>>>> 1. power on the power well > >>>>> 2. read STATESTS to determine the codec_mask > >>>>> 3. if codec is not present, power off the power well > >>>>> and remove the flag. (seems we need a new flag) > >>>>> 4. if codec is present, we will power on the power well > >>>>> when dealing with HDMI codec. > >>>>> > >>>>> What do you think? > >>>> > >>>> Side question - do you know if it's the same for braswell? I e, the > >> HDMI > >>>> codec is in the powerwell but the controller is not? > >>> > >>> Yes, BSW has the same issue. > >>> > >>> At first, my thinking is: > >>> 1. define a new flag, power on the power well if flag is set > >>> 2. read STATESTS to determine the codec_mask > >>> 3. if codec is not present, power off the power well > >>> and remove the flag. > >>> 4. after initialization, power off the power well if new flag > >>> is set and AZX_DCAPS_I915_POWERWELL is not set > >>> 5. power on power well when pcm open > >>> 6. power off the power well when pcm close > >> > >> ...and we're opening the right codec - in case of analog playback, > the > >> powerwell can still be off, right? > >> > >>> After a second thought, the method may have limitation: > >>> the codec may send the unsolicited responses. > >>> > >>> So my currently thinking is: > >>> If the codec is in powerwell, the behavior is like the flag > >>> AZX_DCAPS_I915_POWERWELL: always power on unless > >>> suspend. > >>> This method may cause power consumption. But consider > >>> normally audio will be in suspend state in most case. > >> > >> Ok, thanks for the clarification. I was wondering - the reason the > codec > >> might send unsol events is just due to hotplug events, right? > >> > >> And these unsol events are triggered by the i915 side by setting > some > >> registers, right? > >> > >> Is it then possible that i915, when it detects a video hotplug event, > >> can increment the powerwell counter (so that the powerwell is > turned > >> on), trigger the hotplug event to the audio side, and then > decrement > >> the > >> powerwell again (possibly with a few seconds delay if needed)? > >> > >> The idea is that once the audio side has got the hotplug event, it can > >> turn on and off the powerwell itself. We just need the i915 driver to > >> turn it on for us to get the hotplug event through. > > > > Normally, it's the hotplug unsol event. But sometimes, I found on > > SKL, when suspending, there is some strange event sending > > from hdmi codec. And the controller will fallback to single cmd > > mode. Then the analog audio will be impacted after resume. > > > > BSW may also have this issue. But I didn't find it on our RVP board. > > > > I will test power on power well during unsol events. > > Ok. I wonder if it is possible to stop this "strange event", either > because it's a hardware/firmware bug that could be fixed in later > revisions of the hardware/firmware, or if there is some register we > could write to (or even stop writing to!) on the i915 side that stops > the unsol events. > > Or as a last resort, if we can't stop the "strange event", maybe there's > some way the audio side could handle the "strange event" more > gracefully > so we don't fall back to single cmd mode when this happens. > > (I don't know much about this "strange event" so I'm just guessing > here) Yes, we should stop this unsol events. I will check with internal team later. This should be the real fix. On the other hand, for robustness, audio driver should be able to handle these events. > > -- > David Henningsson, Canonical Ltd. > https://launchpad.net/~diwic Regards, Libin
At Mon, 30 Mar 2015 02:47:45 +0000, Yang, Libin wrote: > > Hi Takashi, > > > > -----Original Message----- > > From: Yang, Libin > > Sent: Friday, March 27, 2015 4:34 PM > > To: Takashi Iwai > > Cc: alsa-devel@alsa-project.org > > Subject: RE: [alsa-devel] [PATCH] ALSA: hda_intel: add > > AZX_DCAPS_I915_POWERWELL for skl > > > > Hi Takashi, > > > > > > > > > -----Original Message----- > > > From: Takashi Iwai [mailto:tiwai@suse.de] > > > Sent: Friday, March 27, 2015 4:30 PM > > > To: Yang, Libin > > > Cc: alsa-devel@alsa-project.org > > > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > At Fri, 27 Mar 2015 08:25:52 +0000, > > > Yang, Libin wrote: > > > > > > > > Hi Takashi, > > > > > > > > > > > > > -----Original Message----- > > > > > From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel- > > > > > bounces@alsa-project.org] On Behalf Of Takashi Iwai > > > > > Sent: Friday, March 27, 2015 4:19 PM > > > > > To: Yang, Libin > > > > > Cc: alsa-devel@alsa-project.org > > > > > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > > > At Fri, 27 Mar 2015 08:02:54 +0000, > > > > > Yang, Libin wrote: > > > > > > > > > > > > Hi Takashi, > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Takashi Iwai [mailto:tiwai@suse.de] > > > > > > > Sent: Friday, March 27, 2015 3:57 PM > > > > > > > To: Yang, Libin > > > > > > > Cc: alsa-devel@alsa-project.org > > > > > > > Subject: Re: [PATCH] ALSA: hda_intel: add > > > > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > > > > > > > At Fri, 27 Mar 2015 15:10:04 +0800, > > > > > > > libin.yang@intel.com wrote: > > > > > > > > > > > > > > > > From: Libin Yang <libin.yang@intel.com> > > > > > > > > > > > > > > > > HDMI/DP codec on SKL is in the power well. > > > > > > > > The power well must be turned on before probing the > > > > > > > > HDMI/DP codec. > > > > > > > > > > > > > > > > Signed-off-by: Libin Yang <libin.yang@intel.com> > > > > > > > > > > > > > > So, was the previous question clarified? > > > > > > > > > > > > Yes, I have confirmed with our silicon team. > > > > > > > > > > > > > > > > > > > > This certainly sucks. It means that the powerwell is on even > > > you > > > > > > > don't use the HDMI/DP at all. If this is intended as a > > temporarily > > > > > > > workaround, it should be mentioned so. Please give more > > > > > comments > > > > > > > and > > > > > > > backgrounds. > > > > > > > > > > > > Yes, as this is added in the skl audio controller, even there is no > > > > > HDMI/DP > > > > > > codec, we should also add this flag. Otherwise the HDMI/DP > > > codec > > > > > > may not be detected correctly. > > > > > > > > > > But it's possible to do it only at probing, not permanently. If so, > > > > > we'll have another patch in future. > > > > > > > > > > Please write more information in the changelog and resubmit. > > > > > > > > Do you mean to add more description in the patch comments? > > > > > > Yes. The hardware design is different from HSW/BDW, thus applying > > > this isn't straightforward but just a workaround. I don't know > > > whether you think it's a temporary workaround or a permanent fix. > > > Such information must be written there, too. > > > > OK. I see. It seems we need more input from our silicon team > > for this issue. > > >From our silicon team's comment, it seems we need power on > the powerwell when detecting and probing the HDMI codec. > > For the skl case (HDMI codec is in powerwell, while controller not), > my thinking is: > > 1. power on the power well > 2. read STATESTS to determine the codec_mask > 3. if codec is not present, power off the power well > and remove the flag. (seems we need a new flag) > 4. if codec is present, we will power on the power well > when dealing with HDMI codec. > > What do you think? Yes, it's also similar to my plan. My plan has a bit more code changes for adapting to the new structure: - Move hda_i915.c code into sound/hda to be used for both legacy and new drivers - Add a reference counter to get/put, so that it can be called from both controller and codec drivers - Move the component from struct hda_intel to hdac_bus, but dynamically allocating. The helper code can check it like if (bus->audio_component) bus->audio_component->ops->get_power(...) (Or the NULL check can be in a helper function) - get_power() is called at probing as is now - put_power() is called at the end of azx_probe*() - There will be two DCAPS flags, one indicating for the old chips that need get_power() for runtime PM, and one indicating get_power() only for probing. Now an open question is how to make codec driver to call get_power / put_power. To be more clear, currently there is no solid way to allow the codec driver doing something special before / after hda_set_power_state(). One may implement a tricky set_power_state() ops in the codec driver. Or, we may reimplement pre_resume and post_suspend patch_ops again. Takashi
Hi Takashi, > -----Original Message----- > From: Takashi Iwai [mailto:tiwai@suse.de] > Sent: Saturday, April 04, 2015 6:44 PM > To: Yang, Libin > Cc: 'alsa-devel@alsa-project.org' > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > AZX_DCAPS_I915_POWERWELL for skl > > At Mon, 30 Mar 2015 02:47:45 +0000, > Yang, Libin wrote: > > > > Hi Takashi, > > > > > > > -----Original Message----- > > > From: Yang, Libin > > > Sent: Friday, March 27, 2015 4:34 PM > > > To: Takashi Iwai > > > Cc: alsa-devel@alsa-project.org > > > Subject: RE: [alsa-devel] [PATCH] ALSA: hda_intel: add > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > Hi Takashi, > > > > > > > > > > > > > -----Original Message----- > > > > From: Takashi Iwai [mailto:tiwai@suse.de] > > > > Sent: Friday, March 27, 2015 4:30 PM > > > > To: Yang, Libin > > > > Cc: alsa-devel@alsa-project.org > > > > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > At Fri, 27 Mar 2015 08:25:52 +0000, > > > > Yang, Libin wrote: > > > > > > > > > > Hi Takashi, > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: alsa-devel-bounces@alsa-project.org [mailto:alsa- > devel- > > > > > > bounces@alsa-project.org] On Behalf Of Takashi Iwai > > > > > > Sent: Friday, March 27, 2015 4:19 PM > > > > > > To: Yang, Libin > > > > > > Cc: alsa-devel@alsa-project.org > > > > > > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > > > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > > > > > At Fri, 27 Mar 2015 08:02:54 +0000, > > > > > > Yang, Libin wrote: > > > > > > > > > > > > > > Hi Takashi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Takashi Iwai [mailto:tiwai@suse.de] > > > > > > > > Sent: Friday, March 27, 2015 3:57 PM > > > > > > > > To: Yang, Libin > > > > > > > > Cc: alsa-devel@alsa-project.org > > > > > > > > Subject: Re: [PATCH] ALSA: hda_intel: add > > > > > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > > > > > > > > > At Fri, 27 Mar 2015 15:10:04 +0800, > > > > > > > > libin.yang@intel.com wrote: > > > > > > > > > > > > > > > > > > From: Libin Yang <libin.yang@intel.com> > > > > > > > > > > > > > > > > > > HDMI/DP codec on SKL is in the power well. > > > > > > > > > The power well must be turned on before probing the > > > > > > > > > HDMI/DP codec. > > > > > > > > > > > > > > > > > > Signed-off-by: Libin Yang <libin.yang@intel.com> > > > > > > > > > > > > > > > > So, was the previous question clarified? > > > > > > > > > > > > > > Yes, I have confirmed with our silicon team. > > > > > > > > > > > > > > > > > > > > > > > This certainly sucks. It means that the powerwell is on > even > > > > you > > > > > > > > don't use the HDMI/DP at all. If this is intended as a > > > temporarily > > > > > > > > workaround, it should be mentioned so. Please give more > > > > > > comments > > > > > > > > and > > > > > > > > backgrounds. > > > > > > > > > > > > > > Yes, as this is added in the skl audio controller, even there is > no > > > > > > HDMI/DP > > > > > > > codec, we should also add this flag. Otherwise the HDMI/DP > > > > codec > > > > > > > may not be detected correctly. > > > > > > > > > > > > But it's possible to do it only at probing, not permanently. If > so, > > > > > > we'll have another patch in future. > > > > > > > > > > > > Please write more information in the changelog and resubmit. > > > > > > > > > > Do you mean to add more description in the patch comments? > > > > > > > > Yes. The hardware design is different from HSW/BDW, thus > applying > > > > this isn't straightforward but just a workaround. I don't know > > > > whether you think it's a temporary workaround or a permanent > fix. > > > > Such information must be written there, too. > > > > > > OK. I see. It seems we need more input from our silicon team > > > for this issue. > > > > >From our silicon team's comment, it seems we need power on > > the powerwell when detecting and probing the HDMI codec. > > > > For the skl case (HDMI codec is in powerwell, while controller not), > > my thinking is: > > > > 1. power on the power well > > 2. read STATESTS to determine the codec_mask > > 3. if codec is not present, power off the power well > > and remove the flag. (seems we need a new flag) > > 4. if codec is present, we will power on the power well > > when dealing with HDMI codec. > > > > What do you think? > > Yes, it's also similar to my plan. My plan has a bit more code > changes for adapting to the new structure: Glad to know that :-) > > - Move hda_i915.c code into sound/hda to be used for both legacy and > new drivers > > - Add a reference counter to get/put, so that it can be called from > both controller and codec drivers > > - Move the component from struct hda_intel to hdac_bus, but > dynamically allocating. The helper code can check it like > > if (bus->audio_component) > bus->audio_component->ops->get_power(...) > > (Or the NULL check can be in a helper function) > > - get_power() is called at probing as is now > > - put_power() is called at the end of azx_probe*() > > - There will be two DCAPS flags, one indicating for the old chips that > need get_power() for runtime PM, and one indicating get_power() > only > for probing. Yes, we need separate these situations. Currently, we may consider such situations: 1. HDA controller and HDA(HDMI) codec are in power well. 2. HDA(HDMI) codec is in power well. 3. HDA controller is in power well while HDA codec not. 4. HDA controller and HDA code are not in power well. We currently don't have really boards which are the 3rd and 4th situations. For second situation, we need power on the power well for probing and each time we use the HDMI codec. As this may takes some time, what do you think I submit a temporary patch that using AZX_DCAPS_I915_POWERWELL for the second situation? After the restructure is finished, we can revert the patch. > > Now an open question is how to make codec driver to call get_power / > put_power. To be more clear, currently there is no solid way to allow > the codec driver doing something special before / after > hda_set_power_state(). One may implement a tricky > set_power_state() > ops in the codec driver. Or, we may reimplement pre_resume and > post_suspend patch_ops again. Yes, we need consider this situation. What about the suspend_late and resume_early in dev_pm_ops? > > > Takashi Regards, Libin
At Tue, 7 Apr 2015 05:47:50 +0000, Yang, Libin wrote: > > Hi Takashi, > > > -----Original Message----- > > From: Takashi Iwai [mailto:tiwai@suse.de] > > Sent: Saturday, April 04, 2015 6:44 PM > > To: Yang, Libin > > Cc: 'alsa-devel@alsa-project.org' > > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > > AZX_DCAPS_I915_POWERWELL for skl > > > > At Mon, 30 Mar 2015 02:47:45 +0000, > > Yang, Libin wrote: > > > > > > Hi Takashi, > > > > > > > > > > -----Original Message----- > > > > From: Yang, Libin > > > > Sent: Friday, March 27, 2015 4:34 PM > > > > To: Takashi Iwai > > > > Cc: alsa-devel@alsa-project.org > > > > Subject: RE: [alsa-devel] [PATCH] ALSA: hda_intel: add > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > Hi Takashi, > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Takashi Iwai [mailto:tiwai@suse.de] > > > > > Sent: Friday, March 27, 2015 4:30 PM > > > > > To: Yang, Libin > > > > > Cc: alsa-devel@alsa-project.org > > > > > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > > > At Fri, 27 Mar 2015 08:25:52 +0000, > > > > > Yang, Libin wrote: > > > > > > > > > > > > Hi Takashi, > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: alsa-devel-bounces@alsa-project.org [mailto:alsa- > > devel- > > > > > > > bounces@alsa-project.org] On Behalf Of Takashi Iwai > > > > > > > Sent: Friday, March 27, 2015 4:19 PM > > > > > > > To: Yang, Libin > > > > > > > Cc: alsa-devel@alsa-project.org > > > > > > > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > > > > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > > > > > > > At Fri, 27 Mar 2015 08:02:54 +0000, > > > > > > > Yang, Libin wrote: > > > > > > > > > > > > > > > > Hi Takashi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Takashi Iwai [mailto:tiwai@suse.de] > > > > > > > > > Sent: Friday, March 27, 2015 3:57 PM > > > > > > > > > To: Yang, Libin > > > > > > > > > Cc: alsa-devel@alsa-project.org > > > > > > > > > Subject: Re: [PATCH] ALSA: hda_intel: add > > > > > > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > > > > > > > > > > > At Fri, 27 Mar 2015 15:10:04 +0800, > > > > > > > > > libin.yang@intel.com wrote: > > > > > > > > > > > > > > > > > > > > From: Libin Yang <libin.yang@intel.com> > > > > > > > > > > > > > > > > > > > > HDMI/DP codec on SKL is in the power well. > > > > > > > > > > The power well must be turned on before probing the > > > > > > > > > > HDMI/DP codec. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Libin Yang <libin.yang@intel.com> > > > > > > > > > > > > > > > > > > So, was the previous question clarified? > > > > > > > > > > > > > > > > Yes, I have confirmed with our silicon team. > > > > > > > > > > > > > > > > > > > > > > > > > > This certainly sucks. It means that the powerwell is on > > even > > > > > you > > > > > > > > > don't use the HDMI/DP at all. If this is intended as a > > > > temporarily > > > > > > > > > workaround, it should be mentioned so. Please give more > > > > > > > comments > > > > > > > > > and > > > > > > > > > backgrounds. > > > > > > > > > > > > > > > > Yes, as this is added in the skl audio controller, even there is > > no > > > > > > > HDMI/DP > > > > > > > > codec, we should also add this flag. Otherwise the HDMI/DP > > > > > codec > > > > > > > > may not be detected correctly. > > > > > > > > > > > > > > But it's possible to do it only at probing, not permanently. If > > so, > > > > > > > we'll have another patch in future. > > > > > > > > > > > > > > Please write more information in the changelog and resubmit. > > > > > > > > > > > > Do you mean to add more description in the patch comments? > > > > > > > > > > Yes. The hardware design is different from HSW/BDW, thus > > applying > > > > > this isn't straightforward but just a workaround. I don't know > > > > > whether you think it's a temporary workaround or a permanent > > fix. > > > > > Such information must be written there, too. > > > > > > > > OK. I see. It seems we need more input from our silicon team > > > > for this issue. > > > > > > >From our silicon team's comment, it seems we need power on > > > the powerwell when detecting and probing the HDMI codec. > > > > > > For the skl case (HDMI codec is in powerwell, while controller not), > > > my thinking is: > > > > > > 1. power on the power well > > > 2. read STATESTS to determine the codec_mask > > > 3. if codec is not present, power off the power well > > > and remove the flag. (seems we need a new flag) > > > 4. if codec is present, we will power on the power well > > > when dealing with HDMI codec. > > > > > > What do you think? > > > > Yes, it's also similar to my plan. My plan has a bit more code > > changes for adapting to the new structure: > > Glad to know that :-) > > > > > - Move hda_i915.c code into sound/hda to be used for both legacy and > > new drivers > > > > - Add a reference counter to get/put, so that it can be called from > > both controller and codec drivers > > > > - Move the component from struct hda_intel to hdac_bus, but > > dynamically allocating. The helper code can check it like > > > > if (bus->audio_component) > > bus->audio_component->ops->get_power(...) > > > > (Or the NULL check can be in a helper function) > > > > - get_power() is called at probing as is now > > > > - put_power() is called at the end of azx_probe*() > > > > - There will be two DCAPS flags, one indicating for the old chips that > > need get_power() for runtime PM, and one indicating get_power() > > only > > for probing. > > Yes, we need separate these situations. Currently, > we may consider such situations: > 1. HDA controller and HDA(HDMI) codec are in power well. > 2. HDA(HDMI) codec is in power well. > 3. HDA controller is in power well while HDA codec not. > 4. HDA controller and HDA code are not in power well. > > We currently don't have really boards which are > the 3rd and 4th situations. > > For second situation, we need power on the power > well for probing and each time we use the HDMI codec. > > As this may takes some time, what do you think I submit > a temporary patch that using AZX_DCAPS_I915_POWERWELL > for the second situation? > After the restructure is finished, we can revert the patch. Yes, it makes sense, but please describe it in the changelog more clearly. > > Now an open question is how to make codec driver to call get_power / > > put_power. To be more clear, currently there is no solid way to allow > > the codec driver doing something special before / after > > hda_set_power_state(). One may implement a tricky > > set_power_state() > > ops in the codec driver. Or, we may reimplement pre_resume and > > post_suspend patch_ops again. > > Yes, we need consider this situation. What about the suspend_late and > resume_early in dev_pm_ops? It's a good alternative, too. Maybe we should clean up the codec driver code to use driver and pm ops directly at first. Takashi
Hi Takashi, > > > -----Original Message----- > > > From: Takashi Iwai [mailto:tiwai@suse.de] > > > Sent: Saturday, April 04, 2015 6:44 PM > > > To: Yang, Libin > > > Cc: 'alsa-devel@alsa-project.org' > > > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > At Mon, 30 Mar 2015 02:47:45 +0000, > > > Yang, Libin wrote: > > > > > > > > Hi Takashi, > > > > > > > > > > > > > -----Original Message----- > > > > > From: Yang, Libin > > > > > Sent: Friday, March 27, 2015 4:34 PM > > > > > To: Takashi Iwai > > > > > Cc: alsa-devel@alsa-project.org > > > > > Subject: RE: [alsa-devel] [PATCH] ALSA: hda_intel: add > > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > > > Hi Takashi, > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Takashi Iwai [mailto:tiwai@suse.de] > > > > > > Sent: Friday, March 27, 2015 4:30 PM > > > > > > To: Yang, Libin > > > > > > Cc: alsa-devel@alsa-project.org > > > > > > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > > > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > > > > > At Fri, 27 Mar 2015 08:25:52 +0000, > > > > > > Yang, Libin wrote: > > > > > > > > > > > > > > Hi Takashi, > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: alsa-devel-bounces@alsa-project.org [mailto:alsa- > > > devel- > > > > > > > > bounces@alsa-project.org] On Behalf Of Takashi Iwai > > > > > > > > Sent: Friday, March 27, 2015 4:19 PM > > > > > > > > To: Yang, Libin > > > > > > > > Cc: alsa-devel@alsa-project.org > > > > > > > > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > > > > > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > > > > > > > > > At Fri, 27 Mar 2015 08:02:54 +0000, > > > > > > > > Yang, Libin wrote: > > > > > > > > > > > > > > > > > > Hi Takashi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Takashi Iwai [mailto:tiwai@suse.de] > > > > > > > > > > Sent: Friday, March 27, 2015 3:57 PM > > > > > > > > > > To: Yang, Libin > > > > > > > > > > Cc: alsa-devel@alsa-project.org > > > > > > > > > > Subject: Re: [PATCH] ALSA: hda_intel: add > > > > > > > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > > > > > > > > > > > > > At Fri, 27 Mar 2015 15:10:04 +0800, > > > > > > > > > > libin.yang@intel.com wrote: > > > > > > > > > > > > > > > > > > > > > > From: Libin Yang <libin.yang@intel.com> > > > > > > > > > > > > > > > > > > > > > > HDMI/DP codec on SKL is in the power well. > > > > > > > > > > > The power well must be turned on before probing > the > > > > > > > > > > > HDMI/DP codec. > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Libin Yang <libin.yang@intel.com> > > > > > > > > > > > > > > > > > > > > So, was the previous question clarified? > > > > > > > > > > > > > > > > > > Yes, I have confirmed with our silicon team. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This certainly sucks. It means that the powerwell is on > > > even > > > > > > you > > > > > > > > > > don't use the HDMI/DP at all. If this is intended as a > > > > > temporarily > > > > > > > > > > workaround, it should be mentioned so. Please give > more > > > > > > > > comments > > > > > > > > > > and > > > > > > > > > > backgrounds. > > > > > > > > > > > > > > > > > > Yes, as this is added in the skl audio controller, even > there is > > > no > > > > > > > > HDMI/DP > > > > > > > > > codec, we should also add this flag. Otherwise the > HDMI/DP > > > > > > codec > > > > > > > > > may not be detected correctly. > > > > > > > > > > > > > > > > But it's possible to do it only at probing, not permanently. > If > > > so, > > > > > > > > we'll have another patch in future. > > > > > > > > > > > > > > > > Please write more information in the changelog and > resubmit. > > > > > > > > > > > > > > Do you mean to add more description in the patch > comments? > > > > > > > > > > > > Yes. The hardware design is different from HSW/BDW, thus > > > applying > > > > > > this isn't straightforward but just a workaround. I don't know > > > > > > whether you think it's a temporary workaround or a > permanent > > > fix. > > > > > > Such information must be written there, too. > > > > > > > > > > OK. I see. It seems we need more input from our silicon team > > > > > for this issue. > > > > > > > > >From our silicon team's comment, it seems we need power on > > > > the powerwell when detecting and probing the HDMI codec. > > > > > > > > For the skl case (HDMI codec is in powerwell, while controller > not), > > > > my thinking is: > > > > > > > > 1. power on the power well > > > > 2. read STATESTS to determine the codec_mask > > > > 3. if codec is not present, power off the power well > > > > and remove the flag. (seems we need a new flag) > > > > 4. if codec is present, we will power on the power well > > > > when dealing with HDMI codec. > > > > > > > > What do you think? > > > > > > Yes, it's also similar to my plan. My plan has a bit more code > > > changes for adapting to the new structure: > > > > Glad to know that :-) > > > > > > > > - Move hda_i915.c code into sound/hda to be used for both legacy > and > > > new drivers > > > > > > - Add a reference counter to get/put, so that it can be called from > > > both controller and codec drivers > > > > > > - Move the component from struct hda_intel to hdac_bus, but > > > dynamically allocating. The helper code can check it like > > > > > > if (bus->audio_component) > > > bus->audio_component->ops->get_power(...) > > > > > > (Or the NULL check can be in a helper function) > > > > > > - get_power() is called at probing as is now > > > > > > - put_power() is called at the end of azx_probe*() > > > > > > - There will be two DCAPS flags, one indicating for the old chips that > > > need get_power() for runtime PM, and one indicating get_power() > > > only > > > for probing. > > > > Yes, we need separate these situations. Currently, > > we may consider such situations: > > 1. HDA controller and HDA(HDMI) codec are in power well. > > 2. HDA(HDMI) codec is in power well. > > 3. HDA controller is in power well while HDA codec not. > > 4. HDA controller and HDA code are not in power well. > > > > We currently don't have really boards which are > > the 3rd and 4th situations. > > > > For second situation, we need power on the power > > well for probing and each time we use the HDMI codec. > > > > As this may takes some time, what do you think I submit > > a temporary patch that using AZX_DCAPS_I915_POWERWELL > > for the second situation? > > After the restructure is finished, we can revert the patch. > > Yes, it makes sense, but please describe it in the changelog more > clearly. Got it. Thanks. > > > > > Now an open question is how to make codec driver to call > get_power / > > > put_power. To be more clear, currently there is no solid way to > allow > > > the codec driver doing something special before / after > > > hda_set_power_state(). One may implement a tricky > > > set_power_state() > > > ops in the codec driver. Or, we may reimplement pre_resume and > > > post_suspend patch_ops again. > > > > Yes, we need consider this situation. What about the suspend_late > and > > resume_early in dev_pm_ops? > > It's a good alternative, too. Maybe we should clean up the codec > driver code to use driver and pm ops directly at first. Yes, use pm ops is a good idea :-) Besides suspend/resume, I'm still wondering how to handling the unsol event. Is it possible that codec is power off, but it still send the events. Especially for HDMI codec, I met such situation, we didn't get power for HDMI codec, but when S4, BSW and SKL will get unsol event (maybe gfx driver has power on the power well), and HDA controller can handle this event correctly, and it will fallback. > > > Takashi Regards, Libin
At Tue, 7 Apr 2015 06:12:00 +0000, Yang, Libin wrote: > > Hi Takashi, > > > > > -----Original Message----- > > > > From: Takashi Iwai [mailto:tiwai@suse.de] > > > > Sent: Saturday, April 04, 2015 6:44 PM > > > > To: Yang, Libin > > > > Cc: 'alsa-devel@alsa-project.org' > > > > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > At Mon, 30 Mar 2015 02:47:45 +0000, > > > > Yang, Libin wrote: > > > > > > > > > > Hi Takashi, > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Yang, Libin > > > > > > Sent: Friday, March 27, 2015 4:34 PM > > > > > > To: Takashi Iwai > > > > > > Cc: alsa-devel@alsa-project.org > > > > > > Subject: RE: [alsa-devel] [PATCH] ALSA: hda_intel: add > > > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > > > > > Hi Takashi, > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Takashi Iwai [mailto:tiwai@suse.de] > > > > > > > Sent: Friday, March 27, 2015 4:30 PM > > > > > > > To: Yang, Libin > > > > > > > Cc: alsa-devel@alsa-project.org > > > > > > > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > > > > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > > > > > > > At Fri, 27 Mar 2015 08:25:52 +0000, > > > > > > > Yang, Libin wrote: > > > > > > > > > > > > > > > > Hi Takashi, > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: alsa-devel-bounces@alsa-project.org [mailto:alsa- > > > > devel- > > > > > > > > > bounces@alsa-project.org] On Behalf Of Takashi Iwai > > > > > > > > > Sent: Friday, March 27, 2015 4:19 PM > > > > > > > > > To: Yang, Libin > > > > > > > > > Cc: alsa-devel@alsa-project.org > > > > > > > > > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > > > > > > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > > > > > > > > > > > At Fri, 27 Mar 2015 08:02:54 +0000, > > > > > > > > > Yang, Libin wrote: > > > > > > > > > > > > > > > > > > > > Hi Takashi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Takashi Iwai [mailto:tiwai@suse.de] > > > > > > > > > > > Sent: Friday, March 27, 2015 3:57 PM > > > > > > > > > > > To: Yang, Libin > > > > > > > > > > > Cc: alsa-devel@alsa-project.org > > > > > > > > > > > Subject: Re: [PATCH] ALSA: hda_intel: add > > > > > > > > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > > > > > > > > > > > > > > > At Fri, 27 Mar 2015 15:10:04 +0800, > > > > > > > > > > > libin.yang@intel.com wrote: > > > > > > > > > > > > > > > > > > > > > > > > From: Libin Yang <libin.yang@intel.com> > > > > > > > > > > > > > > > > > > > > > > > > HDMI/DP codec on SKL is in the power well. > > > > > > > > > > > > The power well must be turned on before probing > > the > > > > > > > > > > > > HDMI/DP codec. > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Libin Yang <libin.yang@intel.com> > > > > > > > > > > > > > > > > > > > > > > So, was the previous question clarified? > > > > > > > > > > > > > > > > > > > > Yes, I have confirmed with our silicon team. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This certainly sucks. It means that the powerwell is on > > > > even > > > > > > > you > > > > > > > > > > > don't use the HDMI/DP at all. If this is intended as a > > > > > > temporarily > > > > > > > > > > > workaround, it should be mentioned so. Please give > > more > > > > > > > > > comments > > > > > > > > > > > and > > > > > > > > > > > backgrounds. > > > > > > > > > > > > > > > > > > > > Yes, as this is added in the skl audio controller, even > > there is > > > > no > > > > > > > > > HDMI/DP > > > > > > > > > > codec, we should also add this flag. Otherwise the > > HDMI/DP > > > > > > > codec > > > > > > > > > > may not be detected correctly. > > > > > > > > > > > > > > > > > > But it's possible to do it only at probing, not permanently. > > If > > > > so, > > > > > > > > > we'll have another patch in future. > > > > > > > > > > > > > > > > > > Please write more information in the changelog and > > resubmit. > > > > > > > > > > > > > > > > Do you mean to add more description in the patch > > comments? > > > > > > > > > > > > > > Yes. The hardware design is different from HSW/BDW, thus > > > > applying > > > > > > > this isn't straightforward but just a workaround. I don't know > > > > > > > whether you think it's a temporary workaround or a > > permanent > > > > fix. > > > > > > > Such information must be written there, too. > > > > > > > > > > > > OK. I see. It seems we need more input from our silicon team > > > > > > for this issue. > > > > > > > > > > >From our silicon team's comment, it seems we need power on > > > > > the powerwell when detecting and probing the HDMI codec. > > > > > > > > > > For the skl case (HDMI codec is in powerwell, while controller > > not), > > > > > my thinking is: > > > > > > > > > > 1. power on the power well > > > > > 2. read STATESTS to determine the codec_mask > > > > > 3. if codec is not present, power off the power well > > > > > and remove the flag. (seems we need a new flag) > > > > > 4. if codec is present, we will power on the power well > > > > > when dealing with HDMI codec. > > > > > > > > > > What do you think? > > > > > > > > Yes, it's also similar to my plan. My plan has a bit more code > > > > changes for adapting to the new structure: > > > > > > Glad to know that :-) > > > > > > > > > > > - Move hda_i915.c code into sound/hda to be used for both legacy > > and > > > > new drivers > > > > > > > > - Add a reference counter to get/put, so that it can be called from > > > > both controller and codec drivers > > > > > > > > - Move the component from struct hda_intel to hdac_bus, but > > > > dynamically allocating. The helper code can check it like > > > > > > > > if (bus->audio_component) > > > > bus->audio_component->ops->get_power(...) > > > > > > > > (Or the NULL check can be in a helper function) > > > > > > > > - get_power() is called at probing as is now > > > > > > > > - put_power() is called at the end of azx_probe*() > > > > > > > > - There will be two DCAPS flags, one indicating for the old chips that > > > > need get_power() for runtime PM, and one indicating get_power() > > > > only > > > > for probing. > > > > > > Yes, we need separate these situations. Currently, > > > we may consider such situations: > > > 1. HDA controller and HDA(HDMI) codec are in power well. > > > 2. HDA(HDMI) codec is in power well. > > > 3. HDA controller is in power well while HDA codec not. > > > 4. HDA controller and HDA code are not in power well. > > > > > > We currently don't have really boards which are > > > the 3rd and 4th situations. > > > > > > For second situation, we need power on the power > > > well for probing and each time we use the HDMI codec. > > > > > > As this may takes some time, what do you think I submit > > > a temporary patch that using AZX_DCAPS_I915_POWERWELL > > > for the second situation? > > > After the restructure is finished, we can revert the patch. > > > > Yes, it makes sense, but please describe it in the changelog more > > clearly. > > Got it. Thanks. > > > > > > > > > Now an open question is how to make codec driver to call > > get_power / > > > > put_power. To be more clear, currently there is no solid way to > > allow > > > > the codec driver doing something special before / after > > > > hda_set_power_state(). One may implement a tricky > > > > set_power_state() > > > > ops in the codec driver. Or, we may reimplement pre_resume and > > > > post_suspend patch_ops again. > > > > > > Yes, we need consider this situation. What about the suspend_late > > and > > > resume_early in dev_pm_ops? > > > > It's a good alternative, too. Maybe we should clean up the codec > > driver code to use driver and pm ops directly at first. > > Yes, use pm ops is a good idea :-) > > Besides suspend/resume, I'm still wondering how to handling the > unsol event. Is it possible that codec is power off, but it still send > the events. Especially for HDMI codec, I met such situation, > we didn't get power for HDMI codec, but when S4, BSW and SKL > will get unsol event (maybe gfx driver has power on the > power well), and HDA controller can handle this event correctly, > and it will fallback. The unsol events aren't handled usually while the device is not in use (thus in power save mode). We thought that the unsol event could be delivered even in D3 when EPSS is available, but it didn't work as expected in the end. Upon power-save resume, the driver checks the jack state. It's mostly OK, the only problem is that any GUI won't be notified at the moment the jack state changed but only at the moment the power-saving state changed. So I don't think we need anything special for SKL. Takashi
Hi Takashi, > -----Original Message----- > From: Takashi Iwai [mailto:tiwai@suse.de] > Sent: Tuesday, April 07, 2015 2:24 PM > To: Yang, Libin > Cc: 'alsa-devel@alsa-project.org' > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > AZX_DCAPS_I915_POWERWELL for skl > > At Tue, 7 Apr 2015 06:12:00 +0000, > Yang, Libin wrote: > > > > Hi Takashi, > > > > > > > -----Original Message----- > > > > > From: Takashi Iwai [mailto:tiwai@suse.de] > > > > > Sent: Saturday, April 04, 2015 6:44 PM > > > > > To: Yang, Libin > > > > > Cc: 'alsa-devel@alsa-project.org' > > > > > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > > > At Mon, 30 Mar 2015 02:47:45 +0000, > > > > > Yang, Libin wrote: > > > > > > > > > > > > Hi Takashi, > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Yang, Libin > > > > > > > Sent: Friday, March 27, 2015 4:34 PM > > > > > > > To: Takashi Iwai > > > > > > > Cc: alsa-devel@alsa-project.org > > > > > > > Subject: RE: [alsa-devel] [PATCH] ALSA: hda_intel: add > > > > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > > > > > > > Hi Takashi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Takashi Iwai [mailto:tiwai@suse.de] > > > > > > > > Sent: Friday, March 27, 2015 4:30 PM > > > > > > > > To: Yang, Libin > > > > > > > > Cc: alsa-devel@alsa-project.org > > > > > > > > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > > > > > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > > > > > > > > > At Fri, 27 Mar 2015 08:25:52 +0000, > > > > > > > > Yang, Libin wrote: > > > > > > > > > > > > > > > > > > Hi Takashi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: alsa-devel-bounces@alsa-project.org > [mailto:alsa- > > > > > devel- > > > > > > > > > > bounces@alsa-project.org] On Behalf Of Takashi Iwai > > > > > > > > > > Sent: Friday, March 27, 2015 4:19 PM > > > > > > > > > > To: Yang, Libin > > > > > > > > > > Cc: alsa-devel@alsa-project.org > > > > > > > > > > Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add > > > > > > > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > > > > > > > > > > > > > At Fri, 27 Mar 2015 08:02:54 +0000, > > > > > > > > > > Yang, Libin wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Takashi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Takashi Iwai [mailto:tiwai@suse.de] > > > > > > > > > > > > Sent: Friday, March 27, 2015 3:57 PM > > > > > > > > > > > > To: Yang, Libin > > > > > > > > > > > > Cc: alsa-devel@alsa-project.org > > > > > > > > > > > > Subject: Re: [PATCH] ALSA: hda_intel: add > > > > > > > > > > > > AZX_DCAPS_I915_POWERWELL for skl > > > > > > > > > > > > > > > > > > > > > > > > At Fri, 27 Mar 2015 15:10:04 +0800, > > > > > > > > > > > > libin.yang@intel.com wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > From: Libin Yang <libin.yang@intel.com> > > > > > > > > > > > > > > > > > > > > > > > > > > HDMI/DP codec on SKL is in the power well. > > > > > > > > > > > > > The power well must be turned on before > probing > > > the > > > > > > > > > > > > > HDMI/DP codec. > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Libin Yang <libin.yang@intel.com> > > > > > > > > > > > > > > > > > > > > > > > > So, was the previous question clarified? > > > > > > > > > > > > > > > > > > > > > > Yes, I have confirmed with our silicon team. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This certainly sucks. It means that the powerwell is > on > > > > > even > > > > > > > > you > > > > > > > > > > > > don't use the HDMI/DP at all. If this is intended as > a > > > > > > > temporarily > > > > > > > > > > > > workaround, it should be mentioned so. Please > give > > > more > > > > > > > > > > comments > > > > > > > > > > > > and > > > > > > > > > > > > backgrounds. > > > > > > > > > > > > > > > > > > > > > > Yes, as this is added in the skl audio controller, even > > > there is > > > > > no > > > > > > > > > > HDMI/DP > > > > > > > > > > > codec, we should also add this flag. Otherwise the > > > HDMI/DP > > > > > > > > codec > > > > > > > > > > > may not be detected correctly. > > > > > > > > > > > > > > > > > > > > But it's possible to do it only at probing, not > permanently. > > > If > > > > > so, > > > > > > > > > > we'll have another patch in future. > > > > > > > > > > > > > > > > > > > > Please write more information in the changelog and > > > resubmit. > > > > > > > > > > > > > > > > > > Do you mean to add more description in the patch > > > comments? > > > > > > > > > > > > > > > > Yes. The hardware design is different from HSW/BDW, > thus > > > > > applying > > > > > > > > this isn't straightforward but just a workaround. I don't > know > > > > > > > > whether you think it's a temporary workaround or a > > > permanent > > > > > fix. > > > > > > > > Such information must be written there, too. > > > > > > > > > > > > > > OK. I see. It seems we need more input from our silicon > team > > > > > > > for this issue. > > > > > > > > > > > > >From our silicon team's comment, it seems we need power > on > > > > > > the powerwell when detecting and probing the HDMI codec. > > > > > > > > > > > > For the skl case (HDMI codec is in powerwell, while controller > > > not), > > > > > > my thinking is: > > > > > > > > > > > > 1. power on the power well > > > > > > 2. read STATESTS to determine the codec_mask > > > > > > 3. if codec is not present, power off the power well > > > > > > and remove the flag. (seems we need a new flag) > > > > > > 4. if codec is present, we will power on the power well > > > > > > when dealing with HDMI codec. > > > > > > > > > > > > What do you think? > > > > > > > > > > Yes, it's also similar to my plan. My plan has a bit more code > > > > > changes for adapting to the new structure: > > > > > > > > Glad to know that :-) > > > > > > > > > > > > > > - Move hda_i915.c code into sound/hda to be used for both > legacy > > > and > > > > > new drivers > > > > > > > > > > - Add a reference counter to get/put, so that it can be called > from > > > > > both controller and codec drivers > > > > > > > > > > - Move the component from struct hda_intel to hdac_bus, but > > > > > dynamically allocating. The helper code can check it like > > > > > > > > > > if (bus->audio_component) > > > > > bus->audio_component->ops->get_power(...) > > > > > > > > > > (Or the NULL check can be in a helper function) > > > > > > > > > > - get_power() is called at probing as is now > > > > > > > > > > - put_power() is called at the end of azx_probe*() > > > > > > > > > > - There will be two DCAPS flags, one indicating for the old chips > that > > > > > need get_power() for runtime PM, and one indicating > get_power() > > > > > only > > > > > for probing. > > > > > > > > Yes, we need separate these situations. Currently, > > > > we may consider such situations: > > > > 1. HDA controller and HDA(HDMI) codec are in power well. > > > > 2. HDA(HDMI) codec is in power well. > > > > 3. HDA controller is in power well while HDA codec not. > > > > 4. HDA controller and HDA code are not in power well. > > > > > > > > We currently don't have really boards which are > > > > the 3rd and 4th situations. > > > > > > > > For second situation, we need power on the power > > > > well for probing and each time we use the HDMI codec. > > > > > > > > As this may takes some time, what do you think I submit > > > > a temporary patch that using AZX_DCAPS_I915_POWERWELL > > > > for the second situation? > > > > After the restructure is finished, we can revert the patch. > > > > > > Yes, it makes sense, but please describe it in the changelog more > > > clearly. > > > > Got it. Thanks. > > > > > > > > > > > > > Now an open question is how to make codec driver to call > > > get_power / > > > > > put_power. To be more clear, currently there is no solid way to > > > allow > > > > > the codec driver doing something special before / after > > > > > hda_set_power_state(). One may implement a tricky > > > > > set_power_state() > > > > > ops in the codec driver. Or, we may reimplement pre_resume > and > > > > > post_suspend patch_ops again. > > > > > > > > Yes, we need consider this situation. What about the > suspend_late > > > and > > > > resume_early in dev_pm_ops? > > > > > > It's a good alternative, too. Maybe we should clean up the codec > > > driver code to use driver and pm ops directly at first. > > > > Yes, use pm ops is a good idea :-) > > > > Besides suspend/resume, I'm still wondering how to handling the > > unsol event. Is it possible that codec is power off, but it still send > > the events. Especially for HDMI codec, I met such situation, > > we didn't get power for HDMI codec, but when S4, BSW and SKL > > will get unsol event (maybe gfx driver has power on the > > power well), and HDA controller can handle this event correctly, > > and it will fallback. > > The unsol events aren't handled usually while the device is not in > use (thus in power save mode). We thought that the unsol event > could > be delivered even in D3 when EPSS is available, but it didn't work as > expected in the end. > > Upon power-save resume, the driver checks the jack state. It's mostly > OK, the only problem is that any GUI won't be notified at the moment > the jack state changed but only at the moment the power-saving state > changed. So I don't think we need anything special for SKL. Got it. Thanks a lot. > > > Takashi Regards, Libin
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 15a8299..4744a96 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -298,7 +298,8 @@ enum { AZX_DCAPS_SNOOP_TYPE(SCH)) #define AZX_DCAPS_INTEL_SKYLAKE \ - (AZX_DCAPS_INTEL_PCH | AZX_DCAPS_SEPARATE_STREAM_TAG) + (AZX_DCAPS_INTEL_PCH | AZX_DCAPS_SEPARATE_STREAM_TAG |\ + AZX_DCAPS_I915_POWERWELL) /* quirks for ATI SB / AMD Hudson */ #define AZX_DCAPS_PRESET_ATI_SB \