On Saturday 13 November 2004 08:38, Alan Stern wrote: > > 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. That's the model in both cases though; what are you thinking ought to be different about root hub behavior? > 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. That is, they'll all report errors? If you can make usbcore behave consistently for all HCDs, preserving the ability of the root hubs to deeply autosuspend, then I'm in favor of it. > 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. The root hub timers get in the way here sometimes; I think root hubs need to be more in control there. > Not so clear is what to do about URBs submitted for the root hub. Right > now the code rejects some "Some" sounds like a bug; all or none would be appropriate. What's a better code to report the "I'm suspended and you shouldn't have called me" error? > 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.) I'd rather have these act the same regardless of whether USB_SUSPEND is set. Autoresume sounds good, going along with autosuspend mechanisms. > > > > * 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? It's a larger version of the problem where the DMA polling from a periodic transfer (usb mouse, etc) keeps the Intel CPU from entering C3 state. The timescale is larger, but the result is the same: needless activity keeps the system too busy to enter some states. If the system in question takes, say, 1/2 second to resume from a particular low power mode, a 1/4 second timer will prevent using that low power mode. > 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? These aren't ACPI states, but it might be OK to think of them as S2 or S3 ... where the longer resume time means that yes, it is exactly that bad. > > > 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. Not yet in Linus' tree we don't ... :) > 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. Relying on that less would be good. But that'd mean being able to use udev->state == USB_STATE_SUSPENDED instead, in some cases. - Dave
