On Tue, 20 Sep 2016, Oliver Neukum wrote:
> On Mon, 2016-09-19 at 14:02 -0400, Alan Stern wrote:
> > > We can for sure enable autosuspend for the sdmmc device, although as
> > > soon as an SD card will be detected the rtsx driver will increase
> > the
> > > runtime PM usage count. The count is decreased when the card is
> > > removed (or failed to be initialized), thus runtime suspend is
> > > prevented as long as there is a functional card inserted.
> Testing autosuspend with card readers on usb_storage I saw a uniform
> response of reporting a medium change event upon resume.
> I am afraid other kinds of readers are not better in that regard.
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
> > 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?
> 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.
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