[PATCH] ALSA: hda - Set intel hda controller power at freeze() and thaw()

[PATCH] ALSA: hda - Set intel hda controller power at freeze() and thaw()

[Xiong Zhang]

It takes three minutes to enter into hibernation on some OEM SKL
machines and we see many codec spurious response after thaw() opertion.
This is because HDA is still in D0 state after freeze() call and
pci_pm_freeze/pci_pm_freeze_noirq() don't set D3 hot in pci_bus driver.
It seems bios still access HDA when system enter into freeze state,
HDA will receive codec response interrupt immediately after thaw() call.
Because of this unexpected interrupt, HDA enter into a abnormal
state and slow down the system enter into hibernation.

In this patch, we put HDA into D3 hot state in azx_freeze_noirq() and
put HDA into D0 state in azx_thaw_noirq().

Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
---
 sound/pci/hda/hda_intel.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index c38c68f..3ba7cbc 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -890,6 +890,16 @@ static int azx_suspend(struct device *dev)
 	return 0;
 }
 
+static int azx_freeze_noirq(struct device *dev)
+{
+	struct pci_dev *pci = to_pci_dev(dev);
+
+	if (pci->vendor == PCI_VENDOR_ID_INTEL)
+		pci_set_power_state(pci, PCI_D3hot);
+
+	return 0;
+}
+
 static int azx_resume(struct device *dev)
 {
 	struct pci_dev *pci = to_pci_dev(dev);
@@ -924,6 +934,14 @@ static int azx_resume(struct device *dev)
 	trace_azx_resume(chip);
 	return 0;
 }
+
+static int azx_thaw_noirq(struct device *dev)
+{
+	struct pci_dev *pci = to_pci_dev(dev);
+
+	if (pci->vendor == PCI_VENDOR_ID_INTEL)
+		pci_set_power_state(pci, PCI_D0);
+}
 #endif /* CONFIG_PM_SLEEP || SUPPORT_VGA_SWITCHEROO */
 
 #ifdef CONFIG_PM
@@ -1035,6 +1053,8 @@ static int azx_runtime_idle(struct device *dev)
 
 static const struct dev_pm_ops azx_pm = {
 	SET_SYSTEM_SLEEP_PM_OPS(azx_suspend, azx_resume)
+	.freeze_noirq = azx_freeze_noirq,
+	.thaw_noirq = azx_thaw_noirq,
 	SET_RUNTIME_PM_OPS(azx_runtime_suspend, azx_runtime_resume, azx_runtime_idle)
 };
 
-- 
1.8.2.1

Re: [PATCH] ALSA: hda - Set intel hda controller power at freeze() and thaw()

[Takashi Iwai]

On Thu, 17 Dec 2015 07:58:44 +0100,
Xiong Zhang wrote:
> 
> It takes three minutes to enter into hibernation on some OEM SKL
> machines and we see many codec spurious response after thaw() opertion.
> This is because HDA is still in D0 state after freeze() call and
> pci_pm_freeze/pci_pm_freeze_noirq() don't set D3 hot in pci_bus driver.
> It seems bios still access HDA when system enter into freeze state,
> HDA will receive codec response interrupt immediately after thaw() call.
> Because of this unexpected interrupt, HDA enter into a abnormal
> state and slow down the system enter into hibernation.
> 
> In this patch, we put HDA into D3 hot state in azx_freeze_noirq() and
> put HDA into D0 state in azx_thaw_noirq().

A slight concern is whether this would cause any impact on older
chipsets.  I don't believe it would, but BIOSen are often crazy
sensitive about such a detail.

Maybe safer to limit this to SKL+?  I guess Broxton should be covered
as well?


thanks,

Takashi

> 
> Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
> ---
>  sound/pci/hda/hda_intel.c | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> index c38c68f..3ba7cbc 100644
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -890,6 +890,16 @@ static int azx_suspend(struct device *dev)
>  	return 0;
>  }
>  
> +static int azx_freeze_noirq(struct device *dev)
> +{
> +	struct pci_dev *pci = to_pci_dev(dev);
> +
> +	if (pci->vendor == PCI_VENDOR_ID_INTEL)
> +		pci_set_power_state(pci, PCI_D3hot);
> +
> +	return 0;
> +}
> +
>  static int azx_resume(struct device *dev)
>  {
>  	struct pci_dev *pci = to_pci_dev(dev);
> @@ -924,6 +934,14 @@ static int azx_resume(struct device *dev)
>  	trace_azx_resume(chip);
>  	return 0;
>  }
> +
> +static int azx_thaw_noirq(struct device *dev)
> +{
> +	struct pci_dev *pci = to_pci_dev(dev);
> +
> +	if (pci->vendor == PCI_VENDOR_ID_INTEL)
> +		pci_set_power_state(pci, PCI_D0);
> +}
>  #endif /* CONFIG_PM_SLEEP || SUPPORT_VGA_SWITCHEROO */
>  
>  #ifdef CONFIG_PM
> @@ -1035,6 +1053,8 @@ static int azx_runtime_idle(struct device *dev)
>  
>  static const struct dev_pm_ops azx_pm = {
>  	SET_SYSTEM_SLEEP_PM_OPS(azx_suspend, azx_resume)
> +	.freeze_noirq = azx_freeze_noirq,
> +	.thaw_noirq = azx_thaw_noirq,
>  	SET_RUNTIME_PM_OPS(azx_runtime_suspend, azx_runtime_resume, azx_runtime_idle)
>  };
>  
> -- 
> 1.8.2.1
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 

Re: [PATCH] ALSA: hda - Set intel hda controller power at freeze() and thaw()

[Yang, Libin]

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de]
> Sent: Thursday, December 17, 2015 3:44 PM
> To: Zhang, Xiong Y
> Cc: alsa-devel@alsa-project.org; Yang, Libin; Lu, Han
> Subject: Re: [alsa-devel] [PATCH] ALSA: hda - Set intel hda controller
> power at freeze() and thaw()
> 
> On Thu, 17 Dec 2015 07:58:44 +0100,
> Xiong Zhang wrote:
> >
> > It takes three minutes to enter into hibernation on some OEM SKL
> > machines and we see many codec spurious response after thaw()
> opertion.
> > This is because HDA is still in D0 state after freeze() call and
> > pci_pm_freeze/pci_pm_freeze_noirq() don't set D3 hot in pci_bus
> driver.
> > It seems bios still access HDA when system enter into freeze state,
> > HDA will receive codec response interrupt immediately after thaw() call.
> > Because of this unexpected interrupt, HDA enter into a abnormal
> > state and slow down the system enter into hibernation.
> >
> > In this patch, we put HDA into D3 hot state in azx_freeze_noirq() and
> > put HDA into D0 state in azx_thaw_noirq().
> 
> A slight concern is whether this would cause any impact on older
> chipsets.  I don't believe it would, but BIOSen are often crazy
> sensitive about such a detail.
> 
> Maybe safer to limit this to SKL+?  I guess Broxton should be covered
> as well?

As the issue fixed by the patch is only found on SKL, I agree to
limit it to SKL+. And apply it to other old platforms later if necessary.

BTW: We have tested it on BDW and SKL. It works on both platforms.

Regards,
Libin

> 
> 
> thanks,
> 
> Takashi
> 
> >
> > Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
> > ---
> >  sound/pci/hda/hda_intel.c | 20 ++++++++++++++++++++
> >  1 file changed, 20 insertions(+)
> >
> > diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> > index c38c68f..3ba7cbc 100644
> > --- a/sound/pci/hda/hda_intel.c
> > +++ b/sound/pci/hda/hda_intel.c
> > @@ -890,6 +890,16 @@ static int azx_suspend(struct device *dev)
> >  	return 0;
> >  }
> >
> > +static int azx_freeze_noirq(struct device *dev)
> > +{
> > +	struct pci_dev *pci = to_pci_dev(dev);
> > +
> > +	if (pci->vendor == PCI_VENDOR_ID_INTEL)
> > +		pci_set_power_state(pci, PCI_D3hot);
> > +
> > +	return 0;
> > +}
> > +
> >  static int azx_resume(struct device *dev)
> >  {
> >  	struct pci_dev *pci = to_pci_dev(dev);
> > @@ -924,6 +934,14 @@ static int azx_resume(struct device *dev)
> >  	trace_azx_resume(chip);
> >  	return 0;
> >  }
> > +
> > +static int azx_thaw_noirq(struct device *dev)
> > +{
> > +	struct pci_dev *pci = to_pci_dev(dev);
> > +
> > +	if (pci->vendor == PCI_VENDOR_ID_INTEL)
> > +		pci_set_power_state(pci, PCI_D0);
> > +}
> >  #endif /* CONFIG_PM_SLEEP || SUPPORT_VGA_SWITCHEROO */
> >
> >  #ifdef CONFIG_PM
> > @@ -1035,6 +1053,8 @@ static int azx_runtime_idle(struct device
> *dev)
> >
> >  static const struct dev_pm_ops azx_pm = {
> >  	SET_SYSTEM_SLEEP_PM_OPS(azx_suspend, azx_resume)
> > +	.freeze_noirq = azx_freeze_noirq,
> > +	.thaw_noirq = azx_thaw_noirq,
> >  	SET_RUNTIME_PM_OPS(azx_runtime_suspend,
> azx_runtime_resume, azx_runtime_idle)
> >  };
> >
> > --
> > 1.8.2.1
> >
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >

Re: [PATCH] ALSA: hda - Set intel hda controller power at freeze() and thaw()

[Zhang, Xiong Y]

> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai@suse.de]
> > Sent: Thursday, December 17, 2015 3:44 PM
> > To: Zhang, Xiong Y
> > Cc: alsa-devel@alsa-project.org; Yang, Libin; Lu, Han
> > Subject: Re: [alsa-devel] [PATCH] ALSA: hda - Set intel hda controller
> > power at freeze() and thaw()
> >
> > On Thu, 17 Dec 2015 07:58:44 +0100,
> > Xiong Zhang wrote:
> > >
> > > It takes three minutes to enter into hibernation on some OEM SKL
> > > machines and we see many codec spurious response after thaw()
> > opertion.
> > > This is because HDA is still in D0 state after freeze() call and
> > > pci_pm_freeze/pci_pm_freeze_noirq() don't set D3 hot in pci_bus
> > driver.
> > > It seems bios still access HDA when system enter into freeze state,
> > > HDA will receive codec response interrupt immediately after thaw() call.
> > > Because of this unexpected interrupt, HDA enter into a abnormal
> > > state and slow down the system enter into hibernation.
> > >
> > > In this patch, we put HDA into D3 hot state in azx_freeze_noirq() and
> > > put HDA into D0 state in azx_thaw_noirq().
> >
> > A slight concern is whether this would cause any impact on older
> > chipsets.  I don't believe it would, but BIOSen are often crazy
> > sensitive about such a detail.
> >
> > Maybe safer to limit this to SKL+?  I guess Broxton should be covered
> > as well?
> 
> As the issue fixed by the patch is only found on SKL, I agree to
> limit it to SKL+. And apply it to other old platforms later if necessary.
> 
> BTW: We have tested it on BDW and SKL. It works on both platforms.
> 
[Zhang, Xiong Y] Ok, I will apply the fix to SKL+. But how could I identify the HDA is SKL+
1) HDA device ID or define macro IS_SKL_PLUS with DID,  this means hard code
2) use AZX_DCAPS_I915_POWERWELL, this means applying it to HSW+
3) add a new AZX_DCAPS_xxxx bit, but the bit for pci->driver_date is valuable and hda_intel driver has used most of the bit. Only bit 11, 22 and 31 are left. 

thanks

Re: [PATCH] ALSA: hda - Set intel hda controller power at freeze() and thaw()

[Takashi Iwai]

On Thu, 17 Dec 2015 10:05:08 +0100,
Zhang, Xiong Y wrote:
> 
> > > -----Original Message-----
> > > From: Takashi Iwai [mailto:tiwai@suse.de]
> > > Sent: Thursday, December 17, 2015 3:44 PM
> > > To: Zhang, Xiong Y
> > > Cc: alsa-devel@alsa-project.org; Yang, Libin; Lu, Han
> > > Subject: Re: [alsa-devel] [PATCH] ALSA: hda - Set intel hda controller
> > > power at freeze() and thaw()
> > >
> > > On Thu, 17 Dec 2015 07:58:44 +0100,
> > > Xiong Zhang wrote:
> > > >
> > > > It takes three minutes to enter into hibernation on some OEM SKL
> > > > machines and we see many codec spurious response after thaw()
> > > opertion.
> > > > This is because HDA is still in D0 state after freeze() call and
> > > > pci_pm_freeze/pci_pm_freeze_noirq() don't set D3 hot in pci_bus
> > > driver.
> > > > It seems bios still access HDA when system enter into freeze state,
> > > > HDA will receive codec response interrupt immediately after thaw() call.
> > > > Because of this unexpected interrupt, HDA enter into a abnormal
> > > > state and slow down the system enter into hibernation.
> > > >
> > > > In this patch, we put HDA into D3 hot state in azx_freeze_noirq() and
> > > > put HDA into D0 state in azx_thaw_noirq().
> > >
> > > A slight concern is whether this would cause any impact on older
> > > chipsets.  I don't believe it would, but BIOSen are often crazy
> > > sensitive about such a detail.
> > >
> > > Maybe safer to limit this to SKL+?  I guess Broxton should be covered
> > > as well?
> > 
> > As the issue fixed by the patch is only found on SKL, I agree to
> > limit it to SKL+. And apply it to other old platforms later if necessary.
> > 
> > BTW: We have tested it on BDW and SKL. It works on both platforms.
> > 
> [Zhang, Xiong Y] Ok, I will apply the fix to SKL+. But how could I identify the HDA is SKL+
> 1) HDA device ID or define macro IS_SKL_PLUS with DID,  this means hard code
> 2) use AZX_DCAPS_I915_POWERWELL, this means applying it to HSW+
> 3) add a new AZX_DCAPS_xxxx bit, but the bit for pci->driver_date is valuable and hda_intel driver has used most of the bit. Only bit 11, 22 and 31 are left. 

I suppose 1.  You already hardcoded for PCI ID check to be Intel
only.


Takashi

[PATCH] ALSA: hda - Set SKL+ hda controller power at freeze() and thaw()

[Xiong Zhang]

It takes three minutes to enter into hibernation on some OEM SKL
machines and we see many codec spurious response after thaw() opertion.
This is because HDA is still in D0 state after freeze() call and
pci_pm_freeze/pci_pm_freeze_noirq() don't set D3 hot in pci_bus driver.
It seems bios still access HDA when system enter into freeze state,
HDA will receive codec response interrupt immediately after thaw() call.
Because of this unexpected interrupt, HDA enter into a abnormal
state and slow down the system enter into hibernation.

In this patch, we put HDA into D3 hot state in azx_freeze_noirq() and
put HDA into D0 state in azx_thaw_noirq().

V2: Only apply this fix to SKL+
    Fix compile error when CONFIG_PM_SLEEP isn't defined

Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
---
 sound/pci/hda/hda_intel.c | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index c38c68f..03d3cef 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -890,6 +890,21 @@ static int azx_suspend(struct device *dev)
 	return 0;
 }
 
+#define IS_SKL(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0xa170)
+#define IS_SKL_LP(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x9d70)
+#define IS_BXT(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x5a98)
+#define IS_SKL_PLUS(pci) (IS_SKL(pci) || IS_SKL_LP(pci) || IS_BXT(pci))
+
+static int azx_freeze_noirq(struct device *dev)
+{
+	struct pci_dev *pci = to_pci_dev(dev);
+
+	if (IS_SKL_PLUS(pci))
+		pci_set_power_state(pci, PCI_D3hot);
+
+	return 0;
+}
+
 static int azx_resume(struct device *dev)
 {
 	struct pci_dev *pci = to_pci_dev(dev);
@@ -924,6 +939,16 @@ static int azx_resume(struct device *dev)
 	trace_azx_resume(chip);
 	return 0;
 }
+
+static int azx_thaw_noirq(struct device *dev)
+{
+	struct pci_dev *pci = to_pci_dev(dev);
+
+	if (IS_SKL_PLUS(pci))
+		pci_set_power_state(pci, PCI_D0);
+
+	return 0;
+}
 #endif /* CONFIG_PM_SLEEP || SUPPORT_VGA_SWITCHEROO */
 
 #ifdef CONFIG_PM
@@ -1035,6 +1060,10 @@ static int azx_runtime_idle(struct device *dev)
 
 static const struct dev_pm_ops azx_pm = {
 	SET_SYSTEM_SLEEP_PM_OPS(azx_suspend, azx_resume)
+#if defined(CONFIG_PM_SLEEP)
+	.freeze_noirq = azx_freeze_noirq,
+	.thaw_noirq = azx_thaw_noirq,
+#endif
 	SET_RUNTIME_PM_OPS(azx_runtime_suspend, azx_runtime_resume, azx_runtime_idle)
 };
 
-- 
1.8.2.1

Re: [PATCH] ALSA: hda - Set SKL+ hda controller power at freeze() and thaw()

[Takashi Iwai]

On Fri, 18 Dec 2015 06:29:18 +0100,
Xiong Zhang wrote:
> 
> It takes three minutes to enter into hibernation on some OEM SKL
> machines and we see many codec spurious response after thaw() opertion.
> This is because HDA is still in D0 state after freeze() call and
> pci_pm_freeze/pci_pm_freeze_noirq() don't set D3 hot in pci_bus driver.
> It seems bios still access HDA when system enter into freeze state,
> HDA will receive codec response interrupt immediately after thaw() call.
> Because of this unexpected interrupt, HDA enter into a abnormal
> state and slow down the system enter into hibernation.
> 
> In this patch, we put HDA into D3 hot state in azx_freeze_noirq() and
> put HDA into D0 state in azx_thaw_noirq().
> 
> V2: Only apply this fix to SKL+
>     Fix compile error when CONFIG_PM_SLEEP isn't defined
> 
> Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>

Thanks, applied now with a few more fixes.  I moved azx_freeze_noirq()
and azx_thaw_noirq() in another ifdef CONFIG_PM_SLEEP, as the place
you added isn't only for CONFIG_PM_SLEEP and it may lead to compile
warnings via randconfig.  Also, I added a comment as a brief
explanation in the code.


Takashi

> ---
>  sound/pci/hda/hda_intel.c | 29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
> 
> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> index c38c68f..03d3cef 100644
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -890,6 +890,21 @@ static int azx_suspend(struct device *dev)
>  	return 0;
>  }
>  
> +#define IS_SKL(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0xa170)
> +#define IS_SKL_LP(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x9d70)
> +#define IS_BXT(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x5a98)
> +#define IS_SKL_PLUS(pci) (IS_SKL(pci) || IS_SKL_LP(pci) || IS_BXT(pci))
> +
> +static int azx_freeze_noirq(struct device *dev)
> +{
> +	struct pci_dev *pci = to_pci_dev(dev);
> +
> +	if (IS_SKL_PLUS(pci))
> +		pci_set_power_state(pci, PCI_D3hot);
> +
> +	return 0;
> +}
> +
>  static int azx_resume(struct device *dev)
>  {
>  	struct pci_dev *pci = to_pci_dev(dev);
> @@ -924,6 +939,16 @@ static int azx_resume(struct device *dev)
>  	trace_azx_resume(chip);
>  	return 0;
>  }
> +
> +static int azx_thaw_noirq(struct device *dev)
> +{
> +	struct pci_dev *pci = to_pci_dev(dev);
> +
> +	if (IS_SKL_PLUS(pci))
> +		pci_set_power_state(pci, PCI_D0);
> +
> +	return 0;
> +}
>  #endif /* CONFIG_PM_SLEEP || SUPPORT_VGA_SWITCHEROO */
>  
>  #ifdef CONFIG_PM
> @@ -1035,6 +1060,10 @@ static int azx_runtime_idle(struct device *dev)
>  
>  static const struct dev_pm_ops azx_pm = {
>  	SET_SYSTEM_SLEEP_PM_OPS(azx_suspend, azx_resume)
> +#if defined(CONFIG_PM_SLEEP)
> +	.freeze_noirq = azx_freeze_noirq,
> +	.thaw_noirq = azx_thaw_noirq,
> +#endif
>  	SET_RUNTIME_PM_OPS(azx_runtime_suspend, azx_runtime_resume, azx_runtime_idle)
>  };
>  
> -- 
> 1.8.2.1
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 

Re: [PATCH] ALSA: hda - Set SKL+ hda controller power at freeze() and thaw()

[Takashi Iwai]

On Fri, 18 Dec 2015 09:39:45 +0100,
Takashi Iwai wrote:
> 
> On Fri, 18 Dec 2015 06:29:18 +0100,
> Xiong Zhang wrote:
> > 
> > It takes three minutes to enter into hibernation on some OEM SKL
> > machines and we see many codec spurious response after thaw() opertion.
> > This is because HDA is still in D0 state after freeze() call and
> > pci_pm_freeze/pci_pm_freeze_noirq() don't set D3 hot in pci_bus driver.
> > It seems bios still access HDA when system enter into freeze state,
> > HDA will receive codec response interrupt immediately after thaw() call.
> > Because of this unexpected interrupt, HDA enter into a abnormal
> > state and slow down the system enter into hibernation.
> > 
> > In this patch, we put HDA into D3 hot state in azx_freeze_noirq() and
> > put HDA into D0 state in azx_thaw_noirq().
> > 
> > V2: Only apply this fix to SKL+
> >     Fix compile error when CONFIG_PM_SLEEP isn't defined
> > 
> > Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
> 
> Thanks, applied now with a few more fixes.  I moved azx_freeze_noirq()
> and azx_thaw_noirq() in another ifdef CONFIG_PM_SLEEP, as the place
> you added isn't only for CONFIG_PM_SLEEP and it may lead to compile
> warnings via randconfig.  Also, I added a comment as a brief
> explanation in the code.

Oh, also I added stable to Cc.


Takashi