On Friday 22 October 2004 14:20, Alan Stern wrote: > 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.
So long as it doesn't get in the way of me finishing basic integration of USB_SUSPEND and system suspend, I'm all for it! > 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. OHCI autosuspends too, whenever it can do it for "free" (in the virtual root hub timer call, with IRQs blocked). And if all ports are suspended or disconnected, it's probably free. The resume-detect IRQ handler will undo it automatically. (Usually NOT right after autosuspend; but that spinlock protection does seem useful!) > 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. I've thought that too. So you want to save me the effort of writing autosuspend logic for EHCI? :) > 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. Thing is, I think EHCI will be able to do that as easily as OHCI can. So no _need_ for usbcore to be involved ... except for external hubs. > Second, not all root hubs support remote wakeup. (All external hubs do, > if I'm not mistaken.) I think all hubs have to handle at least the "resume on change in port connect status" style wakeup, including root hubs. Waking the system from a sleep state is a different issue, not all root hubs are wired to do that. That is, if you partition a hub into "downstream" (towards peripherals) and "upstream" (towards CPU, through buses and bridges) links, the downstream can always suspend/wake, but the upstream link may not be able to do that except as part of a system sleep transition. > 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. I describe that differently: the root hub itself is fully suspended. The frame clock might not even be running. Nothing goes on downstream of that hub, nothing. What's _not_ suspended is the interface to its bus ... it still issues IRQs, the host can read registers, and so on. Upstream activity is completely normal, outside of system sleep states. For now, PCI HCDs can't usefully suspend the bus interfaces unless they also enter a system suspend state. Of course there's still work to be done getting ACPI wakeup to trigger using USB keyboards. > 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. Erm, it won't involve _any_ kind of "wakeup" from a system sleep state: the CPU is getting scheduled, so there's no sleep state! That logic in the OHCI code kicks in with CONFIG_PM, though if CONFIG_USB_SUSPEND is also in use, it'll get more action. > (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. Hmm ... other than not working for external hubs, or through a settable timer, how does the current OHCI behavior differ from what you're describing? I have no problem with a module parameter that controls how external hubs autosuspend. Root hubs ... I'm pretty happy with how OHCI is behaving, and think EHCI can be very similar. - Dave ------------------------------------------------------- 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
