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 :-)
> -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
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()
nd
> 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.
>
elow?
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 messag
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
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
- 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
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
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
-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).
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 :-)
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
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
tual/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 _P
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] r
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
] 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
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
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
20 matches
Mail list logo
