On Monday 25 October 2004 08:18, Alan Stern wrote: > 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?
Sure -- all SCSI commands go through usb-storage, in task context, so it could just usb_resume_device() before submitting any URBs. Though this does raise the issue that it probably makes sense to have the "hardware" layer suspended while the upper layers' "virtual devices" don't know about it. That's not the assumption I think we've been using so far... > > The Maxtor "One Touch" drives seem to need the host t > > 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? Autosuspend can be tested on other drives too ... though they may not have the obvious "LED blinking" display of effectiveness. I can verify, but won't have much time for it until after I get more of the usbcore/hcd/pmcore updates merged. (I suspect the button one touches to issue a "please backup now" request uses the interrupt-IN endpoint; it's otherwise the sort of generic SCSI-ish device that also works with "ub".) > 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. I don't follow this at all. First, why a separate autoresume task? And second, as soon as the devices are marked NOTATTACHED, any resume should fail-fast. (Unless your locking updates changed that behavior...) > 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. Suspending hubs in that state makes no sense to me; but since we don't do any hub suspend yet, we can defer such discussions till later. > > 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. The CMD_ASE bit is for Async Schedule Enable, and the CMD_PSE bit is for Periodic Schedule Enable. > 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. Turning off controller clocks is an additional level of power saving, but that gets into controller-specific behaviors. I think we need to avoid making too many rules in usbcore about how root hubs act; the hardware designers rely on having flexibility there. > 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. That's almost a definitional thing, right -- when the hub driver is ready, we'd know because such a change would be easy? :) Thing is, suspended hubs will also stop blinkenlights. I'd miss them! - 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
