On Sunday 24 October 2004 09:15, Alan Stern wrote: > On Sat, 23 Oct 2004, David Brownell wrote: > > > We should deploy autosuspend in some other drivers first. Storage > > would be a good trial ... all the control goes from CPU to device, there > > are no status or wakeup events going the other direction. I'd be > > pleasantly surprised if autosuspend there turned up no problems... > > Autosuspend for usb-storage is all very well, but when should it > autoresume? The next time a SCSI command is queued? In some respects it > would be _more_ complicated than autosuspend for hubs, because usb-storage > always has an active child (the SCSI host) whereas a hub would autosuspend > only when all its children are already suspended.
Then maybe Pete's "ub" would be a better candidate... I don't mean to suggest solving suspend issues for SCSI, they still seem to be working through hotplug (and unplug) issues! The Maxtor "One Touch" drives seem to need the host to put them into USB suspend state before they'll spin down and enter their deepest power saving mode. I'd rather it weren't only Windows activating that mode ... Linux should get those benefits (including longer drive life) too! > > > Furthermore, we may be talking about two slightly different things. The > > > new autosuspend I'm proposing would work through usb_suspend_device(), > > > which means changing the hub's state to USB_STATE_SUSPENDED > > > plus doing all > > > the stuff that goes with it. You can't do this in interrupt context. > > > > I certainly see the state as SUSPENDED ... also, it's not "interrupt > > context" > > unless by that you include irqs blocked and the HC's spinlock held; > > It takes place during the root hub's timer call, and timer callbacks run > in interrupt context, not process context. Looking at the code, I see > you've duplicated the functionality of usb_suspend_device. That doesn't > strike me as a good way to do things. Actually that code preceded usb_suspend_device() ... Most of the code is what usb_suspend_device(ohci_root) must delegate ... stuff that only OHCI can know. Not much overlap with usb_suspend_device(), though there may still need to be some cleanup there. > UHCI uses delays not in the suspend path but in the resume path. Now that > I look back on it, though, those delays may not be necessary. Some resume() path delays are normally going to be needed, since USB specifies some that apply if there's a suspended device ... and which I think may also end up resetting devices that were just plugged in. OHCI's resume is handled in a different task. It would be nice to have some way to make khubd do that ... I think all HCDs will need to plan on resumes taking ~30+ msec, and it'd be less error prone if khubd would manage all that. > > Another way to say this is that it's possible to look at suspending > > any hub (root or external) in two parts: downstream links, and > > upstream ones. And > > that while most hubs use standard mechanisms, like IN-interrupt transfers > > or IRQs, to pass resume (and wakeup) events upstream, on some boards > > UHCI root hubs need an alternate implementation ... all the USB events > > behave, but the PCI ones are less functional than may be desired. > > That's not really accurate... For the broken UHCI systems I mentioned > before the PCI events behave okay; it's the USB side that causes problems. > The controller thinks that the overcurrent input counts as a port status > change and will generate wakeup requests whenever the OC input is on. I'd have called that a PCI event -- the resume detect IRQ firing when it shouldn't! There _were_ no USB events associated with any user-visible port. But I see what you mean, and still think that's another argument why root hubs need more flexibility about autosuspend than external hubs will. > > I'm thinking that's another argument in favor of usbcore ensuring that > > HCDs can implement root hub suspend directly ... whatever we decide that > > means, and with some way we can (regresssion) test them so we know they > > all act compatibly. > > I see it rather as an argument that the HCDs should implement > "half-suspend" and it should only be used when the regular hub autosuspend > mechanism isn't available. Can you clarify something else about "half suspend"? It seems very similar to the normal state of OHCI or EHCI when there are no requests queued: the async (control + bulk) and periodic schedules shut down, so there's no DMA. > Maybe it should be implemented directly, as > you say, without the involvement of the hub driver -- I haven't made up my > mind. But if all you want to do is automatically suspend the root hub, in > a normal sort of way, why not rely on the hub driver's autosuspend > facility instead of adding a separate version to each HCD? At one level, it's a "bird in the hand" issue. OHCI already autosuspends, and that works well; the hub driver doesn't do any of that yet! At another level, you keep providing examples of root hubs that have quirks that need special handling, and I keep thinking that piling quirk handling in usbcore (hub driver) sounds worse than making sure any root hub driver (hcd) can just do the right thing without needing to change usbcore. The same things come up when using OHCI with some kinds of external transceiver setup. > > > My use of terms isn't the same as yours, although I agree in substance. > > > I say that the root hub isn't suspended because it can receive and reply > > > to URBs and because root_hub->state is USB_STATE_CONFIGURED, not > > > USB_STATE_SUSPENDED. In other words, as far as usbcore is concerned the > > > root hub isn't suspended. (And as far as the hardware is concerned the > > > root hub isn't running.) > > > > That is, you're agreeing with me ... OHCI root hub state *is* SUSPENDED. > > Um, yes -- it really is SUSPENDED. Not "half-suspended". I see that now > from looking at the code. And we can agree on the difference in meaning > between those two terms. Good! :) > > We probably look at the upstream link a bit differently though, since > > you're thinking of UHCI hubs where the root hub timer needs to poll > > the registers, so that port change events get reported ... so it can't > > be SUSPENDED. > > Exactly so. The same _could_ be made to apply to OHCI and EHCI root hubs, > particularly if CONFIG_PM isn't set. Although you might feel that it's > unnecessary... My logic was that if CONFIG_PM isn't set, the person who built that system wanted to avoid power-saving mechanisms and extra code. The root hub suspend/resume code has historically been #ifdef CONFIG_PM as part of PCI glue, so I just applied that more generically (even on non-PCI controllers). > > I'm trying to use "wakeup" mainly to refer to system events, > > and "resume" for the USB events. So "resume" doesn't imply > > "wakeup", and we can say "root hub resumes" without any > > assumptions about the previous system state. > > That puts you in a bind when trying to talk about the "Device Remote > Wakeup" feature selector (Section 9.4, Table 9.6) for an autosuspended or > selectively suspended device. Even though that's the official name, you > would want to say that it ought to be "Device Remote Resume Request"! That's why I said "mainly"! It's hopeless to get all spec-writers (and developers) to use precisely identical terminology. > > For now, it looks like that "half suspended" state will be mostly > > UHCI-specific. Most OHCI boards don't seem to need it, though > > I certainly expect some of the external transceiver arrangements > > (mostly on embedded boards) will add up to the same thing. > > Most UHCI boards don't need it either. It might nevertheless turn out to > be useful, for example if wakeup_enable has been turned off or if > CONFIG_PM is off. Correct me if I'm wrong, but you can test at runtime whether or not a given UHCI board has that one quirk -- right? Do you know other cases that need "half suspended"? - 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
