On Wed, 21 Sep 2016, Oliver Neukum wrote:
> 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.
Almost true, but not quite. When an inner node has more than one leaf
beneath it, enabling an autosuspend delay for the inner node can make
sense -- particularly if the leaf activities are uncorrelated.
> Any storage (generic sense) device
> is an inner node. It should suspend immediately after the block
> device which is the leaf node.
Yes. In this case, however, the USB device has two platform devices
beneath it: one for SDMMC and one for MemoryStick cards.
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