Benjamin Herrenschmidt wrote, responding to Alan Stern:
>>I think the hub driver's power management code may be at fault. It needs
>>to cancel the status interrupt URB when suspending and resubmit it when
>>waking up; right now it probably does neither one.
>>
>>Or maybe I'm wrong about that. Perhaps it's okay to leave the URB active.
>>If that's the case, then the root hub power management code needs to be
>>changed to restart the status URB timer after a wakeup.
I thought that patch got merged already ...
>>I'm not sure how the design is intended to work, but either way something
>>needs to be fixed.
Yes, it seems like all the HCDs (and the hub driver) need attention.
Plus, the enumeration process should respect hubs' power budgets,
and handle overcurrent better. I had a hub re-enumerate over forty
times not that long ago, just because it enabled too many things at
once and the surge currents made lots of trouble. Plenty of power,
if it got turned on carefully enough... :)
> Could well be. I need to spend some time auditing power management
> in the USB drivers in general. The idea here is that a sub-driver
> (USB device driver) should make sure it has no more pending URBs
> when returning from suspend() and the HCD driver should just cancel
> pending URBs if still any and reject any one that would be submited
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?
Suspend should likely enable remote wakeup (trevor.pering@intel.com
has been asking about that), at least as a config option. That'll
be useful for things like keyboards and mice.
Now's probably a good time to work on this sort of integration issue.
I'll be glad to see contributions in this area.
> before it's woken up. It's especially very important on OHCI to not
> touch chip registers (like enabling bulk queue etc...) after the chip
> have been put to suspend state. On some chips, that can cause random
> bus mastering to main memory during sleep, which can cause all sorts
> of interesting results especially when the north bridge is asleep...
There's already code in the OHCI driver to handle that for some
of the Apple hardware, as you know. And it should kick in on at
least some of the power management paths; although not all, as
Pavel has noted.
- 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:27 EST