Hi,
I do: echo "mem" > /sys/power/state and it trys to go to sleep until it hits the hcd driver which prevents it, so it backs out of the sleep process.
Prevents it how ... if you enable debugging, it must say something.
I get a -EIO returned when trying to suspend one of the ohci pci devices. I'll work on tracking it down some more.
Looks like ehci-hcd doesn't have this issue, sorry for blameing it too.
Hmm, a quick "grep" didn't show EIO coming from either OHCI or usbcore, except to fail hub probes ... or urb->status in the never-seen case that a completed TD is in a "reserved for hardware" state.
When I tried that with "standby" on a few systems, it broke horribly (system lockup, no resume) even without an HCD loaded. That, plus the fact that until recently "apm -s" generally oopsed on resume, has made me rather distrustful of the PM code in 2.6 kernels. Though it works for some folk, I'm told.
I'm working on getting suspend to ram working as we really need this.
I'd agree the PM needs to work better ... that's why I sent you those PCI level PM patches! They at least fixed the problems observable in my configurations. Including one that's been rather pathological! :)
What's the status on the rest of your CONFIG_USB_SUSPEND changes?
I reposted them this morning, they just appeared on the list.
You could merge them if you like, but they'll be frustrating until the HID driver (at least!) gets suspend/resume callbacks. I'm not suggesting they be merged till 2.6.7 is out. (Mostly because it's a new feature that not many folk need, and we've been changing a lot of USB infrastructure already.)
Also, UHCI won't behave yet with remote wakeup, even just of the root hub (vs whole-system wakeup using PME#). Alan knows roughly what to do; the root hub code needs to have a reset/resume timer. I suggest dummy_hcd as the model since it doesn't need per-port timers like EHCI. (There's a "how many ports" limit that many of the latest southbridges are about to break.) And it'd be good to add the new root-hub-only suspend/resume HCD calls too.
How did you do this?
Suspend to D3 by:
echo -n 3 > /sys/class/usb_host/$BUSNAME/device/power/state
Resume to D0 by:
echo -n 0 > /sys/class/usb_host/$BUSNAME/device/power/state
Last I tested, all three HCDs would behave with such cycles.
Hm, suspend to D2 doesn't seem to do anything :(
That is, the power/state file didn't even change to "2"?
That'd be correct in some cases, like controllers that only support D0 and D3. Controllers with PCI PM support should work pretty much "by the book" (PCI PM spec, now generally accessible).
The two problem spots I noticed:
- Controllers that don't support PCI PM. Which is rather a
lot, maybe the majority, of deployed hardware. These should
be able to at least suspend their root hubs, though without
using the PCI PME# signal. It worked for me, even with "apm -s".
The hcd-pci suspends those, but bypasses the "PCI PM needed"
calls like actually saying "go into D2 state". - Linux didn't seem to respond to PME# at all when the system
was running ... maybe it only expects those to be used to
wake up the whole system, not individual components. In any
case, remote wakeup of EHCI or OHCI would make "lspci" report
PME# status for devices in D1/D2/D3, so those drivers were
doing as much as they could.It'd actually be rather Green to have all USB controllers stay suspended until someone connects a device to them, and have Linux activate that controller automatically. These new systems with five (or more!) USB host controllers are keeping most of them idle most of the time, and they shouldn't need to waste any electicity in that mode when PME# is usable.
- Dave
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
