On Tue, Oct 12, 2010 at 2:37 PM, Nicolas Pitre <nico@xxxxxxxxxxx> wrote: > On Tue, 12 Oct 2010, Dmitry Shmidt wrote: > >> > Please tell us more about the problem you are trying to solve, and in >> > what ways the current infrastructure is not achieving that goal. Then >> > we might be in a better position to propose suggestions. >> > >> > But selectively ignoring upper suspend requests certainly feels wrong to >> > me. If you need this, then the actual problem must be somewhere else. >> > >> > Nicolas >> >> Let's assume we are talking about device that is not a laptop - and it >> is very power-consumption sensitive. Like smartphone... >> 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? > > > Nicolas > "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. Maybe what I am describing seems weird, but phone developers are fighting for every mA. And mmc card resume if usually deferred - to reduce tiem and save power, but this is a different issue. Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
