On Tue, 12 Oct 2010, Dmitry Shmidt wrote: > On Tue, Oct 12, 2010 at 2:37 PM, Nicolas Pitre <nico@xxxxxxxxxxx> wrote: > > On Tue, 12 Oct 2010, Dmitry Shmidt wrote: > > > >> So you want to go to suspend very aggressively. > >> And you want to keep connectivity. And you want to resume quickly - > >> else it is very easy to be in the situation where > >> you just suspending and resuming all the time. > >> So it doesn't make sense on every suspend/resume rescan for alive sdio > >> card. Makes sense ? > > > > Yes, but in this case the suspend methods are inappropriate when the > > phone is in live usage. They are meant to be used, say, when the phone > > becomes unused and its flap is folded. Otherwise, what is supposed to > > happen when you actually want the SDIO card to be suspended if the > > suspend method is cut out? > > "Flap is folded"... It is not the case for usual smartphones anymore. :) > Simple scenario - you are siting in chat, wait like 15 sec and your > screen goes Off, after another 5 sec kernel gets suspend command and > tries to suspend. And you are getting new message - you want to resume > quickly and process this packet with no delay. OK... and how do you want to achieve that? Why isn't MMC_PM_KEEP_POWER suitable for this? > Maybe what I am describing seems weird, but phone developers are > fighting for every mA. How can you save power when the WIFI interface is not in use if you disabled the suspend method with your patch? > And mmc card resume if usually deferred - to reduce tiem and save > power, but this is a different issue. How much time are we talking about? Nicolas
