On Tue, 2016-09-20 at 10:12 -0400, Alan Stern wrote:
> On Tue, 20 Sep 2016, Oliver Neukum wrote:

> That shouldn't be an issue in this case, at least, not with the current 
> code.  The sdmmc and memstick drivers block autosuspend if media is 
> present.

> > > Which means that autosuspend matters only when a card isn't present, 
> > > and the host is polled every second or so to see whether a card has 
> > > been inserted.
> > > 
> > > Under those circumstances you probably don't want to use
> > > autosuspend.  
> > > That is, resuming before each poll and suspending afterward may use 
> > > less energy than staying at full power all the time.
> > 
> > Is that based on concrete figures about power consumption?
> No.

Well, I have no idea how to improve this much without hideous

> > And it seems to me that we need a way to indicate that the heuristics
> > should not be used, but a device immediately suspended. The timer
> > is sensible only if the next wakeup is unknown.
> The driver can always turn off autosuspend if it wants to.

Yes, but this is not the point. A heuristic with a timeout makes
sense only if the uses are unpredictable. If you know with a high
degree of probability when the next activity comes, you ought to either
suspend now or not all until the next activity.

Likewise the heuristic is appropriate for leaf nodes. You get nothing
from a delay on inner nodes. Any storage (generic sense) device
is an inner node. It should suspend immediately after the block
device which is the leaf node.


To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to