On Fri, 12 Nov 2004, David Brownell wrote: > > Now you're getting into trouble. Without USB_SUSPEND I wouldn't expect > > the USB subsystem to play very well with the PM subsystem. (Note that > > even without USB_SUSPEND we will still have autosuspend for UHCI root > > hubs, in the form of "half-suspend". Not that it will help much in this > > case.) > > OHCI autosuspend just relies on CONFIG_PM. > > If USB_SUSPEND is off, we should now (assuming Linus already > merged that batch of patches from Greg!) be in somewhat better > shape than in, say, 2.6.8 (and much better than 2.6.0). But > yes, there's all sorts of stuff one might reasonably want, > that's not yet done. Maybe things aren't quite as bad as I thought at first. Our model should be that when CONFIG_PM is set and CONFIG_USB_SUSPEND isn't then suspending the HC does a "bus-wide" suspend. Packets won't be sent, but URBs don't have to be unlinked -- they can just sit in the schedule waiting until things start up again. Each usb_device->state can remain as CONFIGURED (since the core won't support USB_STATE_SUSPENDED), including the root hub device. HCDs should be able to enqueue and dequeue URBs, but none will complete normally. The root hub status timer will continue to fire four times per second but it shouldn't call the HCD's hub_status_data routine. Not so clear is what to do about URBs submitted for the root hub. Right now the code rejects some of them with -EAGAIN, a rather inappropriate response. Perhaps the best course is to accept them, and resume the HC if it's necessary to call the hub_control routine. Under normal circumstances, such as preparing for a system suspend, there shouldn't be any such URBs. (Although there might be a few since the suspend call won't be synchronized with the hub driver.) > > > * Whoops, that means root hub timers never stop > > > without USB_SUSPEND! That prevents some systems > > > from reaching lower power states ... it came up > > > recently with some OMAP timer patches. If timers > > > are constantly firing, automatic entry into deeper > > > sleep states (think S1) can't kick it. Kicking > > > those states in gave about an 8% power saving in > > > one simple test ... a one-day battery life going > > > up by almost another two hours (significant). Worrying about this now is almost certainly a case of premature optimization, but I'll ask anyway out of curiosity. Which aspect of the root hub timer prevents the sleep states? Is it the I/O needed for checking the port statuses? Not calling the hub_status_data routine would prevent that. Or is it that the system timer interrupt can't be turned off so long as there are any active timers? Is it really so bad having to go back to S0 from S1 for a fraction of a millisecond, four times per second? > > UHCI's suspend support has been lagging, partly because I've been working > > on other things instead and partly because I want to wait and see the PM > > interfaces stabilize before making a lot of changes. > > That's the right thing to do. I _think_ that last set of > changes makes a decent milestone, and would be happy if > we can avoid changing usbcore PM support for a while. But we will have to change it to match the FREEZE vs. SUSPEND semantics. I've started thinking about hcd->state and to what extent we really need it. More on this later -- but maybe it could be made mostly private to the HCDs and ignored by the core. Alan Stern
