Re: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11

2012-12-12 Thread Borislav Petkov 
On Wed, Dec 12, 2012 at 03:20:25PM +, Lin, Mengdong wrote:
> I remember I didn't observed repetitive attempts to suspend if the
> azx_runtime_suspend() returns -EAGAIN.
>
> Because the HD-A driver does not implement the runtime idle
> callback...

It does now :-)

https://lkml.org/lkml/2012/12/12/128

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11

2012-12-12 Thread Lin, Mengdong 
> -Original Message-
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Wednesday, December 12, 2012 6:52 PM


> > It looks like azx_runtime_suspend() is new in 3.7 and it returns
> > -EAGAIN to indicate that it actually can't be suspended (if my
> > understanding the code is correct).  However, it shouldn't do that,
> > because that causes the runtime PM core to repeat the attempts.  It
> > rather should implement a .runtime_idle() callback returning an error code
> instead.


Hi Boris and Rafael,

I remember I didn't observed repetitive attempts to suspend if the 
azx_runtime_suspend() returns -EAGAIN.

Because the HD-A driver does not implement the runtime idle callback, 
pci_pm_runtime_idle() will call pm_runtime_suspend(dev),
and then __pm_runtime_suspend(dev, 0) will be called. 
Finally the code will go to 'fail' of rpm_suspend: 
...
fail:
__update_runtime_status(dev, RPM_ACTIVE);
dev->power.deferred_resume = false;
wake_up_all(>power.wait_queue);

if (retval == -EAGAIN || retval == -EBUSY) {
dev->power.runtime_error = 0;
...
if ((rpmflags & RPM_AUTO) &&
pm_runtime_autosuspend_expiration(dev) != 0)  ... but 
since the rpmflags is 0, the code will not go to 'repeat' but to 'out'.
goto repeat;
} else {
pm_runtime_cancel_pending(dev);
}
goto out;

Please correct me if I misunderstand something.

Thanks
Mengdong

Re: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11

2012-12-12 Thread Takashi Iwai 
At Wed, 12 Dec 2012 13:13:45 +0100,
Borislav Petkov wrote:
> 
> On Wed, Dec 12, 2012 at 11:58:41AM +0100, Takashi Iwai wrote:
> > Borislav, could you test the patch below?
> 
> [ … ]
> 
> > From: Takashi Iwai 
> > Subject: [PATCH] ALSA: hda - Move runtime PM check to runtime_idle callback
> > 
> > The runtime_idle callback is the right place to check the suspend
> > capability, but currently we do it wrongly in the runtime_suspend
> > callback.  This leads to a kernel error message like:
> >pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] 
> > returns -11
> > and the runtime PM core would even repeat the attempts.
> > 
> > Reported-by: Borislav Petkov 
> 
> -and-tested-by: ...
> 
> Thanks Takashi.

Thanks for quick testing!
I queued the patch for 3.8 kernel now.


Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11

2012-12-12 Thread Borislav Petkov 
On Wed, Dec 12, 2012 at 11:58:41AM +0100, Takashi Iwai wrote:
> Borislav, could you test the patch below?

[ … ]

> From: Takashi Iwai 
> Subject: [PATCH] ALSA: hda - Move runtime PM check to runtime_idle callback
> 
> The runtime_idle callback is the right place to check the suspend
> capability, but currently we do it wrongly in the runtime_suspend
> callback.  This leads to a kernel error message like:
>    pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] 
> returns -11
> and the runtime PM core would even repeat the attempts.
> 
> Reported-by: Borislav Petkov 

  -and-tested-by: ...

Thanks Takashi.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11

2012-12-12 Thread Takashi Iwai 
At Wed, 12 Dec 2012 00:44:33 +0100,
Rafael J. Wysocki wrote:
> 
> On Tuesday, December 11, 2012 06:55:08 PM Borislav Petkov wrote:
> > On Tue, Dec 11, 2012 at 06:48:23PM +0100, Rafael J. Wysocki wrote:
> > > Boris, please send the output of "lspci -vvv' from that box.
> > 
> > Attached.
> 
> So the audio is a Root Complex Integrated Endpoind and there shouldn't be
> any problems with it related to PCIe ports power management.
> 
> It looks like azx_runtime_suspend() is new in 3.7 and it returns -EAGAIN
> to indicate that it actually can't be suspended (if my understanding the
> code is correct).  However, it shouldn't do that, because that causes
> the runtime PM core to repeat the attempts.  It rather should implement
> a .runtime_idle() callback returning an error code instead.

Borislav, could you test the patch below?


thanks,

Takashi

---
From: Takashi Iwai 
Subject: [PATCH] ALSA: hda - Move runtime PM check to runtime_idle callback

The runtime_idle callback is the right place to check the suspend
capability, but currently we do it wrongly in the runtime_suspend
callback.  This leads to a kernel error message like:
   pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] 
returns -11
and the runtime PM core would even repeat the attempts.

Reported-by: Borislav Petkov 
Cc:  [v3.7]
Signed-off-by: Takashi Iwai 
---
 sound/pci/hda/hda_intel.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 1da8a5c..0f3d3db 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2691,10 +2691,6 @@ static int azx_runtime_suspend(struct device *dev)
struct snd_card *card = dev_get_drvdata(dev);
struct azx *chip = card->private_data;
 
-   if (!power_save_controller ||
-   !(chip->driver_caps & AZX_DCAPS_PM_RUNTIME))
-   return -EAGAIN;
-
azx_stop_chip(chip);
azx_clear_irq_pending(chip);
return 0;
@@ -2709,12 +2705,25 @@ static int azx_runtime_resume(struct device *dev)
azx_init_chip(chip, 1);
return 0;
 }
+
+static int azx_runtime_idle(struct device *dev)
+{
+   struct snd_card *card = dev_get_drvdata(dev);
+   struct azx *chip = card->private_data;
+
+   if (!power_save_controller ||
+   !(chip->driver_caps & AZX_DCAPS_PM_RUNTIME))
+   return -EBUSY;
+
+   return 0;
+}
+
 #endif /* CONFIG_PM_RUNTIME */
 
 #ifdef CONFIG_PM
 static const struct dev_pm_ops azx_pm = {
SET_SYSTEM_SLEEP_PM_OPS(azx_suspend, azx_resume)
-   SET_RUNTIME_PM_OPS(azx_runtime_suspend, azx_runtime_resume, NULL)
+   SET_RUNTIME_PM_OPS(azx_runtime_suspend, azx_runtime_resume, 
azx_runtime_idle)
 };
 
 #define AZX_PM_OPS _pm
-- 
1.8.0.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11

2012-12-12 Thread Borislav Petkov 
On Wed, Dec 12, 2012 at 12:44:33AM +0100, Rafael J. Wysocki wrote:
> On Tuesday, December 11, 2012 06:55:08 PM Borislav Petkov wrote:
> > On Tue, Dec 11, 2012 at 06:48:23PM +0100, Rafael J. Wysocki wrote:
> > > Boris, please send the output of "lspci -vvv' from that box.
> > 
> > Attached.
> 
> So the audio is a Root Complex Integrated Endpoind and there shouldn't be
> any problems with it related to PCIe ports power management.
> 
> It looks like azx_runtime_suspend() is new in 3.7 and it returns -EAGAIN
> to indicate that it actually can't be suspended (if my understanding the
> code is correct).  However, it shouldn't do that, because that causes
> the runtime PM core to repeat the attempts.  It rather should implement
> a .runtime_idle() callback returning an error code instead.
> 
> Those messages are just noise, though.

Adding author of this (b8dfc4624162c0547d7f36a9df48da2d9b4bd58a).

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11

2012-12-12 Thread Borislav Petkov 
On Wed, Dec 12, 2012 at 12:44:33AM +0100, Rafael J. Wysocki wrote:
 On Tuesday, December 11, 2012 06:55:08 PM Borislav Petkov wrote:
  On Tue, Dec 11, 2012 at 06:48:23PM +0100, Rafael J. Wysocki wrote:
   Boris, please send the output of lspci -vvv' from that box.
  
  Attached.
 
 So the audio is a Root Complex Integrated Endpoind and there shouldn't be
 any problems with it related to PCIe ports power management.
 
 It looks like azx_runtime_suspend() is new in 3.7 and it returns -EAGAIN
 to indicate that it actually can't be suspended (if my understanding the
 code is correct).  However, it shouldn't do that, because that causes
 the runtime PM core to repeat the attempts.  It rather should implement
 a .runtime_idle() callback returning an error code instead.
 
 Those messages are just noise, though.

Adding author of this (b8dfc4624162c0547d7f36a9df48da2d9b4bd58a).

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11

2012-12-12 Thread Takashi Iwai 
At Wed, 12 Dec 2012 00:44:33 +0100,
Rafael J. Wysocki wrote:
 
 On Tuesday, December 11, 2012 06:55:08 PM Borislav Petkov wrote:
  On Tue, Dec 11, 2012 at 06:48:23PM +0100, Rafael J. Wysocki wrote:
   Boris, please send the output of lspci -vvv' from that box.
  
  Attached.
 
 So the audio is a Root Complex Integrated Endpoind and there shouldn't be
 any problems with it related to PCIe ports power management.
 
 It looks like azx_runtime_suspend() is new in 3.7 and it returns -EAGAIN
 to indicate that it actually can't be suspended (if my understanding the
 code is correct).  However, it shouldn't do that, because that causes
 the runtime PM core to repeat the attempts.  It rather should implement
 a .runtime_idle() callback returning an error code instead.

Borislav, could you test the patch below?


thanks,

Takashi

---
From: Takashi Iwai ti...@suse.de
Subject: [PATCH] ALSA: hda - Move runtime PM check to runtime_idle callback

The runtime_idle callback is the right place to check the suspend
capability, but currently we do it wrongly in the runtime_suspend
callback.  This leads to a kernel error message like:
   pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] 
returns -11
and the runtime PM core would even repeat the attempts.

Reported-by: Borislav Petkov b...@alien8.de
Cc: sta...@vger.kernel.org [v3.7]
Signed-off-by: Takashi Iwai ti...@suse.de
---
 sound/pci/hda/hda_intel.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 1da8a5c..0f3d3db 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2691,10 +2691,6 @@ static int azx_runtime_suspend(struct device *dev)
struct snd_card *card = dev_get_drvdata(dev);
struct azx *chip = card-private_data;
 
-   if (!power_save_controller ||
-   !(chip-driver_caps  AZX_DCAPS_PM_RUNTIME))
-   return -EAGAIN;
-
azx_stop_chip(chip);
azx_clear_irq_pending(chip);
return 0;
@@ -2709,12 +2705,25 @@ static int azx_runtime_resume(struct device *dev)
azx_init_chip(chip, 1);
return 0;
 }
+
+static int azx_runtime_idle(struct device *dev)
+{
+   struct snd_card *card = dev_get_drvdata(dev);
+   struct azx *chip = card-private_data;
+
+   if (!power_save_controller ||
+   !(chip-driver_caps  AZX_DCAPS_PM_RUNTIME))
+   return -EBUSY;
+
+   return 0;
+}
+
 #endif /* CONFIG_PM_RUNTIME */
 
 #ifdef CONFIG_PM
 static const struct dev_pm_ops azx_pm = {
SET_SYSTEM_SLEEP_PM_OPS(azx_suspend, azx_resume)
-   SET_RUNTIME_PM_OPS(azx_runtime_suspend, azx_runtime_resume, NULL)
+   SET_RUNTIME_PM_OPS(azx_runtime_suspend, azx_runtime_resume, 
azx_runtime_idle)
 };
 
 #define AZX_PM_OPS azx_pm
-- 
1.8.0.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11

2012-12-12 Thread Borislav Petkov 
On Wed, Dec 12, 2012 at 11:58:41AM +0100, Takashi Iwai wrote:
 Borislav, could you test the patch below?

[ … ]

 From: Takashi Iwai ti...@suse.de
 Subject: [PATCH] ALSA: hda - Move runtime PM check to runtime_idle callback
 
 The runtime_idle callback is the right place to check the suspend
 capability, but currently we do it wrongly in the runtime_suspend
 callback.  This leads to a kernel error message like:
pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] 
 returns -11
 and the runtime PM core would even repeat the attempts.
 
 Reported-by: Borislav Petkov b...@alien8.de

  -and-tested-by: ...

Thanks Takashi.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11

2012-12-12 Thread Takashi Iwai 
At Wed, 12 Dec 2012 13:13:45 +0100,
Borislav Petkov wrote:
 
 On Wed, Dec 12, 2012 at 11:58:41AM +0100, Takashi Iwai wrote:
  Borislav, could you test the patch below?
 
 [ … ]
 
  From: Takashi Iwai ti...@suse.de
  Subject: [PATCH] ALSA: hda - Move runtime PM check to runtime_idle callback
  
  The runtime_idle callback is the right place to check the suspend
  capability, but currently we do it wrongly in the runtime_suspend
  callback.  This leads to a kernel error message like:
 pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] 
  returns -11
  and the runtime PM core would even repeat the attempts.
  
  Reported-by: Borislav Petkov b...@alien8.de
 
 -and-tested-by: ...
 
 Thanks Takashi.

Thanks for quick testing!
I queued the patch for 3.8 kernel now.


Takashi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11

2012-12-12 Thread Lin, Mengdong 
 -Original Message-
 From: Borislav Petkov [mailto:b...@alien8.de]
 Sent: Wednesday, December 12, 2012 6:52 PM


  It looks like azx_runtime_suspend() is new in 3.7 and it returns
  -EAGAIN to indicate that it actually can't be suspended (if my
  understanding the code is correct).  However, it shouldn't do that,
  because that causes the runtime PM core to repeat the attempts.  It
  rather should implement a .runtime_idle() callback returning an error code
 instead.


Hi Boris and Rafael,

I remember I didn't observed repetitive attempts to suspend if the 
azx_runtime_suspend() returns -EAGAIN.

Because the HD-A driver does not implement the runtime idle callback, 
pci_pm_runtime_idle() will call pm_runtime_suspend(dev),
and then __pm_runtime_suspend(dev, 0) will be called. 
Finally the code will go to 'fail' of rpm_suspend: 
...
fail:
__update_runtime_status(dev, RPM_ACTIVE);
dev-power.deferred_resume = false;
wake_up_all(dev-power.wait_queue);

if (retval == -EAGAIN || retval == -EBUSY) {
dev-power.runtime_error = 0;
...
if ((rpmflags  RPM_AUTO) 
pm_runtime_autosuspend_expiration(dev) != 0)  ... but 
since the rpmflags is 0, the code will not go to 'repeat' but to 'out'.
goto repeat;
} else {
pm_runtime_cancel_pending(dev);
}
goto out;

Please correct me if I misunderstand something.

Thanks
Mengdong

Re: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11

2012-12-12 Thread Borislav Petkov 
On Wed, Dec 12, 2012 at 03:20:25PM +, Lin, Mengdong wrote:
 I remember I didn't observed repetitive attempts to suspend if the
 azx_runtime_suspend() returns -EAGAIN.

 Because the HD-A driver does not implement the runtime idle
 callback...

It does now :-)

https://lkml.org/lkml/2012/12/12/128

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11

2012-12-11 Thread Rafael J. Wysocki 
On Tuesday, December 11, 2012 06:55:08 PM Borislav Petkov wrote:
> On Tue, Dec 11, 2012 at 06:48:23PM +0100, Rafael J. Wysocki wrote:
> > Boris, please send the output of "lspci -vvv' from that box.
> 
> Attached.

So the audio is a Root Complex Integrated Endpoind and there shouldn't be
any problems with it related to PCIe ports power management.

It looks like azx_runtime_suspend() is new in 3.7 and it returns -EAGAIN
to indicate that it actually can't be suspended (if my understanding the
code is correct).  However, it shouldn't do that, because that causes
the runtime PM core to repeat the attempts.  It rather should implement
a .runtime_idle() callback returning an error code instead.

Those messages are just noise, though.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11

2012-12-11 Thread Borislav Petkov 
On Tue, Dec 11, 2012 at 06:48:23PM +0100, Rafael J. Wysocki wrote:
> Boris, please send the output of "lspci -vvv' from that box.

Attached.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
00:00.0 Host bridge: Advanced Micro Devices [AMD] Family 14h Processor Root 
Complex
Subsystem: Advanced Micro Devices [AMD] Family 14h Processor Root 
Complex
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- SERR-  [disabled]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Express (v2) Root Complex Integrated Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 
unlimited
ExtTag+ RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- 
Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- 
TransPend-
LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency 
L0 <64ns, L1 <1us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk- 
DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- 
SpeedDis-, Selectable De-emphasis: -6dB
 Transmit Margin: Normal Operating Range, 
EnterModifiedCompliance- ComplianceSOS-
 Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, 
EqualizationComplete-, EqualizationPhase1-
 EqualizationPhase2-, EqualizationPhase3-, 
LinkEqualizationRequest-
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: fee0100c  Data: 41c1
Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 
Len=010 
Kernel driver in use: radeon

00:01.1 Audio device: Advanced Micro Devices [AMD] nee ATI Wrestler HDMI Audio 
[Radeon HD 6250/6310]
Subsystem: Advanced Micro Devices [AMD] nee ATI Wrestler HDMI Audio 
[Radeon HD 6250/6310]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel

00:05.0 PCI bridge: Advanced Micro Devices [AMD] Family 14h Processor Root Port 
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, 
L1 <1us
ExtTag+ RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- 
Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- 
TransPend-
LnkCap: Port #2, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 
<64ns, L1 <1us
ClockPM- Surprise- LLActRep+ BwNot+
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- 
CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ 
DLActive+ BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- 
Surprise-
Slot #5, PowerLimit 75.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- 
LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- 
Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ 
Interlock-

Re: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11

2012-12-11 Thread Rafael J. Wysocki 
On Tuesday, December 11, 2012 06:03:15 PM Borislav Petkov wrote:
> Hi guys,
> 
> I've got the message tagged "HERE" in dmesg running 3.7 (of course, this
> is a new message):
> 
> ...
> [   27.41] input: ACPI Virtual Keyboard Device as 
> /devices/virtual/input/input14
> [   29.550494] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 
> [snd_hda_intel] returns -11 <-- HERE
> [   29.610630] powernow-k8: this CPU is not supported anymore, using 
> acpi-cpufreq instead.
> [   29.676307] acpi-cpufreq: overriding BIOS provided _PSD data
> [   32.575161] Program wdm tried to access /dev/mem between 100000->104000.
> [   34.242866] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 
> [snd_hda_intel] returns -11 <-- HERE
> [ 1502.142636] usbcore: registered new interface driver usblp
> [ 1988.970449] Program wdm tried to access /dev/mem between 10->104000.
> [ 1988.994976] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 
> [snd_hda_intel] returns -11 <-- HERE

Well, this looks like the driver is having a problem.

Takashi, have we done any PM changes to that driver recently?

Boris, please send the output of "lspci -vvv' from that box.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11

2012-12-11 Thread Borislav Petkov 
Hi guys,

I've got the message tagged "HERE" in dmesg running 3.7 (of course, this
is a new message):

...
[   27.41] input: ACPI Virtual Keyboard Device as 
/devices/virtual/input/input14
[   29.550494] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 
[snd_hda_intel] returns -11   <-- HERE
[   29.610630] powernow-k8: this CPU is not supported anymore, using 
acpi-cpufreq instead.
[   29.676307] acpi-cpufreq: overriding BIOS provided _PSD data
[   32.575161] Program wdm tried to access /dev/mem between 10->104000.
[   34.242866] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 
[snd_hda_intel] returns -11   <-- HERE
[ 1502.142636] usbcore: registered new interface driver usblp
[ 1988.970449] Program wdm tried to access /dev/mem between 10->104000.
[ 1988.994976] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 
[snd_hda_intel] returns -11   <-- HERE

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11

2012-12-11 Thread Borislav Petkov 
Hi guys,

I've got the message tagged HERE in dmesg running 3.7 (of course, this
is a new message):

...
[   27.41] input: ACPI Virtual Keyboard Device as 
/devices/virtual/input/input14
[   29.550494] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 
[snd_hda_intel] returns -11   -- HERE
[   29.610630] powernow-k8: this CPU is not supported anymore, using 
acpi-cpufreq instead.
[   29.676307] acpi-cpufreq: overriding BIOS provided _PSD data
[   32.575161] Program wdm tried to access /dev/mem between 10-104000.
[   34.242866] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 
[snd_hda_intel] returns -11   -- HERE
[ 1502.142636] usbcore: registered new interface driver usblp
[ 1988.970449] Program wdm tried to access /dev/mem between 10-104000.
[ 1988.994976] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 
[snd_hda_intel] returns -11   -- HERE

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11

2012-12-11 Thread Rafael J. Wysocki 
On Tuesday, December 11, 2012 06:03:15 PM Borislav Petkov wrote:
 Hi guys,
 
 I've got the message tagged HERE in dmesg running 3.7 (of course, this
 is a new message):
 
 ...
 [   27.41] input: ACPI Virtual Keyboard Device as 
 /devices/virtual/input/input14
 [   29.550494] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 
 [snd_hda_intel] returns -11 -- HERE
 [   29.610630] powernow-k8: this CPU is not supported anymore, using 
 acpi-cpufreq instead.
 [   29.676307] acpi-cpufreq: overriding BIOS provided _PSD data
 [   32.575161] Program wdm tried to access /dev/mem between 10-104000.
 [   34.242866] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 
 [snd_hda_intel] returns -11 -- HERE
 [ 1502.142636] usbcore: registered new interface driver usblp
 [ 1988.970449] Program wdm tried to access /dev/mem between 10-104000.
 [ 1988.994976] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 
 [snd_hda_intel] returns -11 -- HERE

Well, this looks like the driver is having a problem.

Takashi, have we done any PM changes to that driver recently?

Boris, please send the output of lspci -vvv' from that box.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11

2012-12-11 Thread Borislav Petkov 
On Tue, Dec 11, 2012 at 06:48:23PM +0100, Rafael J. Wysocki wrote:
 Boris, please send the output of lspci -vvv' from that box.

Attached.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
00:00.0 Host bridge: Advanced Micro Devices [AMD] Family 14h Processor Root 
Complex
Subsystem: Advanced Micro Devices [AMD] Family 14h Processor Root 
Complex
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort- SERR- PERR- INTx-
Latency: 64

00:01.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI 
Wrestler [Radeon HD 6310] (prog-if 00 [VGA controller])
Subsystem: Lenovo Device 21ec
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 44
Region 0: Memory at e000 (32-bit, prefetchable) [size=256M]
Region 1: I/O ports at 4000 [size=256]
Region 2: Memory at f030 (32-bit, non-prefetchable) [size=256K]
Expansion ROM at unassigned [disabled]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Express (v2) Root Complex Integrated Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 4us, L1 
unlimited
ExtTag+ RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- 
Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- 
TransPend-
LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency 
L0 64ns, L1 1us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk- 
DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- 
SpeedDis-, Selectable De-emphasis: -6dB
 Transmit Margin: Normal Operating Range, 
EnterModifiedCompliance- ComplianceSOS-
 Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, 
EqualizationComplete-, EqualizationPhase1-
 EqualizationPhase2-, EqualizationPhase3-, 
LinkEqualizationRequest-
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: fee0100c  Data: 41c1
Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 
Len=010 ?
Kernel driver in use: radeon

00:01.1 Audio device: Advanced Micro Devices [AMD] nee ATI Wrestler HDMI Audio 
[Radeon HD 6250/6310]
Subsystem: Advanced Micro Devices [AMD] nee ATI Wrestler HDMI Audio 
[Radeon HD 6250/6310]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin B routed to IRQ 43
Region 0: Memory at f0344000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Express (v2) Root Complex Integrated Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 4us, L1 
unlimited
ExtTag+ RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- 
Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- 
TransPend-
LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency 
L0 64ns, L1 1us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed unknown, Width

Re: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11

2012-12-11 Thread Rafael J. Wysocki 
On Tuesday, December 11, 2012 06:55:08 PM Borislav Petkov wrote:
 On Tue, Dec 11, 2012 at 06:48:23PM +0100, Rafael J. Wysocki wrote:
  Boris, please send the output of lspci -vvv' from that box.
 
 Attached.

So the audio is a Root Complex Integrated Endpoind and there shouldn't be
any problems with it related to PCIe ports power management.

It looks like azx_runtime_suspend() is new in 3.7 and it returns -EAGAIN
to indicate that it actually can't be suspended (if my understanding the
code is correct).  However, it shouldn't do that, because that causes
the runtime PM core to repeat the attempts.  It rather should implement
a .runtime_idle() callback returning an error code instead.

Those messages are just noise, though.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/