"S, Venkatraman" <[email protected]> writes: > On Wed, Jul 13, 2011 at 8:29 PM, Kevin Hilman <[email protected]> wrote:
[...] >> >> My basic question is this: why does this device need to be runtime >> resumed during system suspend? Why can't it just stay runtime >> suspended? >> > > From my understanding, the runtime suspend is usually implemented to not > lose the card 'context', i.e. transactions can continue after a > runtime suspend / > resume cycle. > > For system suspend, the MMC core sends a sleep command (which, in > itself, is a transaction) to the card to go to sleep state, and for > all practical purposes, the card is treated as 'removed'. When the > system resumes, the card is rescanned and re-initialized. > > Hence, for system suspend, the MMC controller needs to be enabled to > actually send the command which puts the card to sleep (and hence the > resume). Great, this is the detail I was looking for since my MMC knowledge is quite limited. So, in theory, this same sleep command could be sent during runtime suspend as well, so that a system suspend would not have to runtime resume, correct? But I suppose it would result in a much higher latency runtime resumes. It might be worth experimenting with doing this, possibly in combination with longer auto-suspend delay times. Thanks for the explanation, Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
