Patrick is currently merging a bunch of important PM updates that should help for non-PPC platforms.
I'm pulling Linus' tree right now; seems to have a bunch of them, but I wouldn't know if it's back to working yet.
I do notice that one part of the patch was to remove per-driver suspend/resume calls in favor of per-bus_type calls. That means we may have to reconsider the (lack of) need for usb-specific suspend/resume calls that drivers would implement (to unlink or otherwise cleanup before suspend, etc).
The root hub timer patch doesn't seem to have gotten in since I saw calls to it (see my detailed comment below in my previous mail)
OK, someone needs to resolve that. I think it was a Paul Mackerras patch, from earlier this month. I just forwarded the last copy of the patch that I had sitting around.
The last time this came up, Alan Stern suggested that USB
drivers should unlink their URBs as part of suspend.
I agree with him. But we can't expect all drivers to be fixed and I prefer not crashing the host if a single driver is not fixed...
I'm not entirely sure I like that solution; we didn't need it in 2.4,
so it "shouldn't" be needed now.
2.4 worked sort of "magically" and wasn't very robust on PM if you had devices plugged in.
That kind of magic I don't like. It might be better to take a "we know it'll work" approach on 2.6 at this point, rather than find out what the exact problems were. ("usb-ohci" would leak TDs on some paths. That problem appears to be fixed now.)
- I haven't yet figured out other code path leading to touching chip registers outside of the above, I'm not too sure about the ED stuffs.
In normal operation, I'd only expect it from: IRQs, the root hub timer, and urb enqueue/dequeue. But things like checking the frame number (does any driver even use that call?) would too.
We can error it (or just return the last frame number) when suspending.
Simpler to just check hcd->state and fail if it's not running.
urb enqueue should fail imho (it could be implemented if we shadow the queue registers but I prefer sending an error to a driver doing the wrong thing), but doesn't it fail currently _after_ dealing with the ED ? urb dequeue could be implemented with shadow registers or be able to fail, but the later seem more complicated, don't you think ?
I don't follow you. If we go the "all urbs must be dequeued before we suspend" route, there's not going to be a problem. Then all the enqueue/dequeue paths will just check hcd->state and fail if it's not running.
Do that seem correct to you ?
It doesn't seem like it uses the driver model suspend/resume logic, which is where a lot of this work should be done. For example, all the children of the OHCI hardware (root hub, and devices connected to it) can do their cleanup in driver model suspend calls before the OHCI PM gets called ... and resumed after it comes back.
Sure, but the OHCI driver itself should be robust enough to deal gracefully with incorrect drivers imho.
Actually one of the goals of the HCD glue layer is to move most of the shared functionality into shared code, so that each HCD doesn't need to re-implement/re-debug such stuff ... and so that we don't have as many differences between HCDs. That's also a goal of the driver model: more similarity between drivers.
In this case, there are certainly OHCI-specific things to do, like ASIC hooks that only make sense on PMAC, but most of the other things you've mentioned are also needed for EHCI and UHCI. So we'll be better off if most of the updates are generic.
- Dave
------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
