On Sun, 24 Oct 2004, David Brownell wrote: > > 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!
Do you know anyone who has that drive and can test autosuspend? My trial (more accurately, mental!) implementation is running into a problem with autoresume. The race between autoresume and disconnect is very difficult to handle. If the disconnect arrives first, then the autoresume process will block waiting to acquire the device lock. But the disconnect routine can't finish until the autoresume process has exited; otherwise an oops might ensue as the driver module is unloaded. The only solution I can think of is to make the device locking for resume follow the approach of usb_lock_device_for_reset() -- use trylock(), cope with locking failures by delaying and looping, and return an error if the device becomes NOTATTACHED. Probably the same thing should be done for suspend. That means changing locktree. Do you have any better suggestions? > > 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. I'm not so sure about those delays. There isn't time now to go chasing through the USB spec, but I'm quite sure that downstream resume signalling in a resuming hub is different for ports that were suspended before the hub and ports that weren't. In particular, ports that were suspended will remain suspended after the hub resumes. We should give some thought to whether we will ever allow hubs to suspend when they have enabled, non-suspended downstream ports. Assuming we never do (which is the current pattern) then there needn't be any resume delays. > > 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. In this case, it would be best to say that the broken root hubs don't support wakeup. Then it could never be enabled, so the root hubs would never autosuspend. Their only option would be "half-suspend". > 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. I wasn't aware of this. Are you sure that there's no DMA activity? My cursory reading of the EHCI spec didn't show any way to shut down the periodic schedule, but I could easily have missed it. Taking your word for it, then yes -- the normal idle state you describe is very similar to "half suspend". About the only significant difference is that the controller and some of its internal clocks would remain running (generating frames, for instance, even though there are no active enabled ports to send SOF packets out of). So maybe this really is only an issue for UHCI. > 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. I agree about quirks, so it sounds like "half-suspend" should remain internal to the UHCI driver. As for the "bird in the hand" aspect -- taking the autosuspend code out of OHCI when the hub driver is ready won't involve much of a change. > > 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"? Right, and no. Alan Stern ------------------------------------------------------- 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
