Re: fixing usb suspend/resuming
From: David Brownell
Date: Sat Jul 17 2004 - 12:37:04 EST
Hi,
Somehow batch of mail to me got delayed, and yours was in it.
So I thought I'd follow up on this, since I've noticed the
same thing in other contexts:
Alexander Gran wrote:
When I want acpi to go to S3 (echo 3 > /proc/acpi/sleep), the driver want's to
enter S2, which the device does not support:
I'm not clear on the intended relationship between PCI device state
numbers and ACPI device states in Linux ... but it's clear from the
specs (ACPI ch2, the mostly-generic bit) that ACPI "3" != PCI "3".
Power Off == ACPI 3
== PCI 4 (D3cold)
Low Power == ACPI 2
== PCI 3 (D3hot; or maybe D1 or D2, depending)
And in much the same way "USB Suspend" is an ACPI low power
state (2) ... not an ACPI power off state (3). And for USB
host controllers, PCI D3hot is expected to support USB suspend.
I'm suspecting that something is mistranslating between ACPI
power state numbering and PCI power state numbering
I'd _certainly_ expect that the numbers passed to PCI suspend
and resume calls would match the PCI state numbers, not the
ACPI numbers! But those numbers aren't documented in the
Linux sources, so probably different people are making rather
different assumptions. After all, "3 == 3" and "2 == 2".
That's all different from the ACPI system power states, too.
(Which is what I'd expect /proc/acpi/sleep to affect.)
- Dave
Stopping tasks:
===================================================================|
radeonfb: suspending to state: 2...
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 0x mode
agpgart: Putting AGP V2 device at 0000:01:00.0 into 0x mode
ehci_hcd 0000:00:1d.7: suspend D0 --> D2
ehci_hcd 0000:00:1d.7: PCI suspend fail, -5
ehci_hcd 0000:00:1d.7: resume from state D0
This seems to be an acpi problem. I'm no acpi god, and no idea how it works. I
found that every call before acpi has state 3, every afterwards has state 2.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/