On Thursday 11 November 2004 14:36, Alan Stern wrote: > On Wed, 10 Nov 2004, David Brownell wrote: > > > * After that interface suspends, so must the root hub > > device itself. Though for hubs that autosuspended, > > this might have nothing left to do! This hub can > > probably issue wakeup events by IRQ, even though > > in terms of at least DMA it's also FROZEN. > > (Also HCD_STATE_SUSPENDED.) > > In some cases autosuspend won't kick in until after a time delay, so > you might not want to rely on it here. As I said, it "might" have nothing left to do. > The actual action required for suspending the root hub device itself will > of course vary according to the type of controller. UHCI won't have to do > anything. OHCI drivers might want to turn off some timers and disable SOF > generation... OHCI doesn't have any timers, the only timers are handled by usbcore and would (in that particular execution sequence) have already been shut down. OHCI autosuspend leaves the bus fully suspended, so no SOFs will be generated. I'm not sure I want to do a detailed comparison with UHCI. > > * So when the PCI device suspend gets called, all it > > needs to do is shutdown PCI access ... which, if > > the controller supports PCI PM, includes setting > > it to a low power PCI state like D1 or D3hot, and > > maybe enabling PCI PME# wakeup (For non-PCI devices, > > bus glue duties are much the same.) > > Right. > > > - Otherwise (without USB_SUSPEND or autosuspend), we > > currently only have PCI and root hub suspend logic. > > 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. > Without USB_SUSPEND we don't have any root-hub suspend logic, there's only > the PCI suspend logic. That is, the root-hub suspend routine may still > exist in the HCD, but it won't be called by usb_suspend_device. This will > definitely make things difficult. The HCD will have to call the routine > itself from within its PCI suspend code when USB_SUSPEND isn't set. That > means coping with in-flight URBs, new submissions, unlinks, and so on all > while the controller is suspended. Sure, but that's no different than in 2.6.0 ... > > * 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). > > Are you talking about the root hub status URB timers? I know you just > changed that code -- doesn't the timer routine avoid calling the HCD if > the HCD state isn't RUNNING or QUIESCING? The virtual root hub polling, yes. I changed things rather minimally ... not wanting to risk breaking things too badly! > Other timers are internal to the HCDs. They are examples of the things I > mentioned above that would be handled by calling the root-hub suspend > routine from within the PCI suspend code. > > > * Hmm, both OHCI and EHCI have hcd->hub_suspend() > > calls, but UHCI doesn't -- just the PCI stuff. > > That's not necessarily an issue, since there > > probably aren't many non-PCI versions of UHCI, > > but it's an issue we should remember. > > 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. > > At least for OHCI it's quite clear how to divvy up tasks > > between root->suspend() and controller->suspend() ... > > the root hub gets everything that's portable, the bus glue > > gets the rest. EHCI can work mostly the same. > > > > We'll be much better off when both PM and USB cores work well > > enough that we just equate USB_SUSPEND with normal CONFIG_PM > > logic. Otherwise we have _way_ too many code paths to test! > > Maybe we shouldn't wait. Trying to do PM suspends without USB_SUSPEND > support just complicates things. Linux has never had USB_SUSPEND before ... this stuff has its fingers though enough other stuff that I'd rather keep the "without USB_SUSPEND" configuration working, so there's more of a safe fallback. > We're talking past each other. You seemed to be concerned that sometimes > freezing an interface will cause a device to reduce its power usage. My > reply merely stated that this shouldn't be a problem. No, my concern was that "freeze" was really acting like a particularly lightweight device suspend case, but was for some reason getting treated (sometimes) like something else. - Dave > > > > The last notion that made sense to me was having > > > > "frozen" just be another suspend state ... > > > > And there don't seem to be any generally useful behavioral > > distinctions between those states. That's maybe most visible > > for the devices that don't directly map to hardware ... like > > the interface devices in USB, or network class devices. > > For things that don't directly map to hardware I agree, there's > practically no distinction between FREEZE and SUSPEND. (Maybe no > distinction at all.) For things that do, of course there is a distinction > -- SUSPEND implies reduced power level and FREEZE doesn't. Also it's > expected that in general devices may take longer to resume from SUSPEND > than from FREEZE. > > If you want to say that this makes FREEZE just another, less restricted > form of suspend state... That's probably just a matter of naming, not > anything substantive. I won't argue against it. > > Alan Stern > >
