On Thu, Mar 28, 2013 at 3:07 PM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
> Subject: PCI / ACPI: Always resume devices on ACPI wakeup notifications
>
> It turns out that the _Lxx control methods provided by some BIOSes
> clear the PME Status bit of PCI devices they handle, which means
On Thu, Mar 28, 2013 at 3:07 PM, Rafael J. Wysocki r...@sisk.pl wrote:
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
Subject: PCI / ACPI: Always resume devices on ACPI wakeup notifications
It turns out that the _Lxx control methods provided by some BIOSes
clear the PME Status bit of PCI
On Friday, March 29, 2013 09:05:35 AM Sarah Sharp wrote:
> On Fri, Mar 29, 2013 at 04:05:54PM +0100, Martin Mokrejs wrote:
> > [ 36.594171] xhci_hcd :0b:00.0: xhci_suspend: stopping port polling.
> > [ 36.594202] xhci_hcd :0b:00.0: // Setting command ring address to
> > 0xd6007001
> >
On Friday, March 29, 2013 04:05:54 PM Martin Mokrejs wrote:
> Hi,
> I applied this patches over 3.8.3 hoping it will fix my issue under
> thread: "Re: 3.8.2: xhci port is dead until pcieport PME# goes to disabled"
> but unfortunately, it is even worse! Now, although lsusb -v nor lsusb -vv do
>
So, I re-tested again with the patch and 3.8.3 but without laptop-mode-tools.
The xHCI port works fine provided
/sys/bus/pci/devices/:0b:00.0/power/control
is set to on and /sys/bus/pci/devices/:00:1c.4/power/control also to on.
If I set parent 1c.4 to auto, it gets suspended and the port
Sarah,
please let me know if you feel the test was screwed by laptop-mode-tools
kicking in, although I believed they were not running while I was on AC power.
I was testing under these conditions:
vostro ~ # grep . /sys/bus/pci/devices/*/power/control
On Fri, Mar 29, 2013 at 04:05:54PM +0100, Martin Mokrejs wrote:
> [ 36.594171] xhci_hcd :0b:00.0: xhci_suspend: stopping port polling.
> [ 36.594202] xhci_hcd :0b:00.0: // Setting command ring address to
> 0xd6007001
> [ 36.594247] xhci_hcd :0b:00.0: hcd_pci_runtime_suspend: 0
>
Hi,
I applied this patches over 3.8.3 hoping it will fix my issue under
thread: "Re: 3.8.2: xhci port is dead until pcieport PME# goes to disabled"
but unfortunately, it is even worse! Now, although lsusb -v nor lsusb -vv do
wakeup the XHCI port but it falls asleep immediately, more quickly than
Hi,
I applied this patches over 3.8.3 hoping it will fix my issue under
thread: Re: 3.8.2: xhci port is dead until pcieport PME# goes to disabled
but unfortunately, it is even worse! Now, although lsusb -v nor lsusb -vv do
wakeup the XHCI port but it falls asleep immediately, more quickly than I
On Fri, Mar 29, 2013 at 04:05:54PM +0100, Martin Mokrejs wrote:
[ 36.594171] xhci_hcd :0b:00.0: xhci_suspend: stopping port polling.
[ 36.594202] xhci_hcd :0b:00.0: // Setting command ring address to
0xd6007001
[ 36.594247] xhci_hcd :0b:00.0: hcd_pci_runtime_suspend: 0
[
Sarah,
please let me know if you feel the test was screwed by laptop-mode-tools
kicking in, although I believed they were not running while I was on AC power.
I was testing under these conditions:
vostro ~ # grep . /sys/bus/pci/devices/*/power/control
So, I re-tested again with the patch and 3.8.3 but without laptop-mode-tools.
The xHCI port works fine provided
/sys/bus/pci/devices/:0b:00.0/power/control
is set to on and /sys/bus/pci/devices/:00:1c.4/power/control also to on.
If I set parent 1c.4 to auto, it gets suspended and the port
On Friday, March 29, 2013 04:05:54 PM Martin Mokrejs wrote:
Hi,
I applied this patches over 3.8.3 hoping it will fix my issue under
thread: Re: 3.8.2: xhci port is dead until pcieport PME# goes to disabled
but unfortunately, it is even worse! Now, although lsusb -v nor lsusb -vv do
wakeup
On Friday, March 29, 2013 09:05:35 AM Sarah Sharp wrote:
On Fri, Mar 29, 2013 at 04:05:54PM +0100, Martin Mokrejs wrote:
[ 36.594171] xhci_hcd :0b:00.0: xhci_suspend: stopping port polling.
[ 36.594202] xhci_hcd :0b:00.0: // Setting command ring address to
0xd6007001
[
From: Rafael J. Wysocki
Subject: PCI / ACPI: Always resume devices on ACPI wakeup notifications
It turns out that the _Lxx control methods provided by some BIOSes
clear the PME Status bit of PCI devices they handle, which means that
pci_acpi_wake_dev() cannot really use that bit to check whether
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
Subject: PCI / ACPI: Always resume devices on ACPI wakeup notifications
It turns out that the _Lxx control methods provided by some BIOSes
clear the PME Status bit of PCI devices they handle, which means that
pci_acpi_wake_dev() cannot really use
16 matches
Mail list logo
