We're about at the point where it makes sense to have USB hubs autosuspend themselves when all their ports are either disconnected or suspended. The infrastructure is all in place; it would only require a few additions to the hub driver. The real advantages wouldn't be realized until other USB devices (mainly HID devices like keyboards and mice) also do autosuspend, but it won't hurt to get an early start.
The changes required are fairly straightforward. The autosuspend timeout could be specified as a module parameter (and hence changeable through sysfs). Some of the HCDs already have a sort of autosuspend in place. For instance, the UHCI driver will suspend the controller when all the ports have been disconnected for 1 second, with autoresume when a new connection occurs. It would be very nice to integrate this into the new autosuspend picture; as it stands it's rather awkward because it runs in interrupt context -- and each HCD does it differently (or not at all). With the new scheme the hub driver would be in overall charge. There are two things to consider here. First, CONFIG_USB_SUSPEND might not be set. Obviously then we wouldn't autosuspend external hubs -- but we would still want to autosuspend root hubs. Not only will this provide a non-trivial power saving in itself, but also it will prevent DMA bus mastering and hence allow the CPU to go to a lower power state. Second, not all root hubs support remote wakeup. (All external hubs do, if I'm not mistaken.) Again obviously we wouldn't want to autosuspend a root hub if it won't send wakeup requests. But with root hubs there's another alternative, something we might call a "half-suspended" state. The driver can basically stop the controller and turn off most of its high-power components, while leaving the port status registers alive. In effect, the root hub's downstream ports would be suspended while its upstream port would be awake. This would have most of the advantages of suspending the root hub (power savings, no DMA) but without actually going into the suspended state. Wakeup requests wouldn't be needed since the hub driver could still learn about status changes, through the usual status interrupt URB. And this could be used without CONFIG_USB_SUSPEND, since the device wouldn't actually be suspended. (This does, however, raise the question of what the root-hub autosuspend timeout should be if CONFIG_USB_SUSPEND isn't set. Should it be controlled by the module parameter, or should it automatically happen after all ports have been disconnected for 1 second?) The HCDs will have to be changed to add support for "half-suspend". This shouldn't be too hard, and it can be done separately from the major part of the work. Comments? Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
