On Mon, 12 Jul 2010, Oliver Neukum wrote: > > I don't see how it affects the topic of this discussion, though. It > > means that suspending whenever you learn there is no media will yield > > essentially the same result as suspending whenever the device file is > > closed. > > If you suspend as soon as you close, yes. If you use the heuristics > of waiting a little time before you suspend, no. My SCSI patches use a 100-ms delay. This was necessary because during initial probing of a new disk, the device file gets opened and closed several times in quick succession. On the other hand, usb-storage's delay could be set to 0 with no ill effects. > > As for the time required... I have thought several times that perhaps > > we should have an "autosuspend_ms" attribute in addition to (if not > > instead of) the "autosuspend" file. While delays much shorter than 50 > > or 100 ms don't make any sense, that still leaves a lot of room between > > 50 and 1000 ms, which is the shortest we can currently accomodate. > > The people at Sony/Ericsson tested that with cdc-acm. No useful > power savings. It might be different with storage. It might be different with storage _and_ probing every few seconds. The real benefit here is not so much the delay for the storage device, but rather the autosuspend delay for the parent hub. > > > Now we could shift this to user space, > > > > Shift what to user space? > > Setting delay to 0 as soon as user space learns that no medium is present. There's no need to worry about the medium. Let userspace set the delay to 0 when the storage device is first registered, and leave it there. > > > but I doubt we'd get it in > > > in a reasonable time frame. And I believe this is a feature we could > > > use in the long run. > > > > Do you mean we could use autosuspend for storage devices in general, or > > that we could use autosuspend whenever no media is present? > > The feature of a driver letting the core know that the device will be idle > from now on for some time. Well, in fact you _don't_ know how long the device will be idle. Perhaps the user is already inserting a new medium. The basic scheme should be very simple. A driver tells the core that its device is currently idle by means of the usual autosuspend function calls. Deciding what to do then is up to the core, as determined by the configurable policy settings set by userspace. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
