Pavel Machek wrote:
>>Agreed, this needs work. Some USB device drivers will likely need to
>>implement suspend()/resume() callbacks, which thoughtfully enough the
>>driver model conversion already gave us. At one point it was planned
>>to have it automatically traverse the devices and suspend, leaves up to
>>root; and resume in the reverse order. Is that behaving now?
>
>
> Yes.
Well, partially; but it's not used consistently. Could you
(or someone) explain what the plan is? I see:
- Three separate x86 PM "initiators": APM, ACPI, swsusp.
(Plus ones for ARM and MIPS.)
- Two driver registration infrastructures, the driver model
stuff and the older pm_*() stuff.
The pm_*() is how a handful of sound drivers and other random
stuff register themselves -- and how PCI does it.
I'd sure have expected PCI to only use the driver model stuff,
and I'll hope all those users will all be phased out by the
time that 2.6 gets near the end of its test cycle.
The "initiators" all talk to _both_ infrastructures, but they
don't talk to the driver model stuff in the same way. For
example, on suspend:
- ACPI issues a NOTIFY, which can veto the suspend;
then SAVE_STATE, ditto; finally POWER_DOWN.
- APM uses the pm_*() calls for a vetoable check,
never issues SAVE_STATE, then goes POWER_DOWN.
- While swsusp is more like ACPI except that it doesn't
support vetoing from either NOTIFY or SAVE_STATE.
That all seems more problematic to me. Seems to me that
APM should issue SAVE_STATE (and RESTORE_STATE), and all
three PM "initiators" should agree on vetoing.
For USB, the {SAVE,RESTORE}_STATE calls would be the most
natural place to do the "kill pending urbs" calls that
Alan Stern mentioned -- at least, for D3 or swsusp levels.
Likely for D1 and D2, devices with pending I/O won't really
be keen on from suspending.
Now, for the record I tried to suspend a test1 APM-works
system, with UHCI, and it wouldn't resume -- unclear why,
or if test2 will do the same.
A different APM-works system, with OHCI and test2, did
suspend/resume OK; but something went wrong with OHCI
even before any driver model PM calls happened, if the
OHCI driver was active (doing DMA): the HCD got an
"Unrecoverable Error" IRQ, which generally means that
some kind DMA fault appeared.
All of which is a roundabout way of adding to what I
said: the PM infrastructure USB will need to rely on
seems like it needs polishing yet! :)
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jul 31 2003 - 22:00:48 EST