On Wed, 20 Sep 2006, David Brownell wrote: > On Wednesday 20 September 2006 10:09 am, Alan Stern wrote: > > Dave: > > > > I want to modify the bus_suspend and bus_resume routines in ohci-hub.c. > > The idea is to have versions that can operate entirely in interrupt > > context. > > > > Normally of course this would be impossible. But if you know that no > > ports are enabled (or even connected) and none have been for the last > > second or so, then it should be possible to move directly between the > > OPER and SUSPEND states with no delays. > > If all enabled ports are suspended, it's also OK; and "the last second > or so" is not a necessary constraint.
My point didn't get through -- I want to do this for bus_resume as well as for bus_suspend. Yes, the existing code already does call bus_suspend in interrupt context, but it never calls bus_resume that way. The idea is to provide a rudimentary "turn off the root hub when nothing's using it" capability. When CONFIG_USB_SUSPEND is set then the generic autosuspend code in usbcore will take care of things, so this would kick in only when CONFIG_USB_SUSPEND is off. Under that condition downstream ports are never suspended, so the root hub could be stopped only when no devices are attached (enabled, if you want to be pedantic). Fortunately that also means then RESUME state doesn't need to last for many milliseconds (no devices to resume). So in principle we could make the transition through RESUME to OPER very quickly and do it all inside an interrupt handler. However it's possible that some OHCI controllers _need_ the RESUME state to last a certain minimum time. Do you know of any such requirement in real hardware? This feature would be used whenever CONFIG_USB_SUSPEND isn't set. (Another possibility is that the autosuspend code in usbcore could be moved outside the CONFIG_USB_SUSPEND-protected region. This feels like a strange way to do things, though.) That leaves two possibilities: either CONFIG_PM is set or it isn't. (1) If CONFIG_PM is set, then we certainly do want to do a bus suspend when nothing is connected. In the absence of the autosuspend code, this is the best way to do it. On the other hand, eventually we will do away with CONFIG_USB_SUSPEND (i.e., assume it is set whenever CONFIG_PM is set). Once that happens, this case will never arise. So do we care about this case? (2) If CONFIG_PM isn't set, then you can make a good argument that it doesn't matter whether the bus ever gets suspended. I feel that it still would be good to do so under the minimal assumption that nothing is connected, especially if it can be done in a lightweight fashion with a small amount of code. In the end, if you disagree with (2) and decide that CONFIG_USB_SUSPEND can be eliminated, then this approach wouldn't be needed at all. In the meantime, I think it's a good idea. Alan Stern ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
