On Wed, Oct 13, 2010 at 4:10 PM, Nicolas Pitre <nico@xxxxxxxxxxx> wrote: > On Wed, 13 Oct 2010, Dmitry Shmidt wrote: > >> On Tue, Oct 12, 2010 at 5:53 PM, Nicolas Pitre <nico@xxxxxxxxxxx> wrote: >> >> > 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? >> It just allows to keep power for SDC controller. It doesn't change >> suspend/resume behavior from SDIO device >> perspective. > > I think you misunderstood the purpose of MMC_PM_KEEP_POWER. > > Let's assume the context of a WIFI card. There are cases when you want > the WIFI card to be suspended, and some other cases you want it to > remain alive when the host CPU does suspend itself. So the decision has > to come from the WIFI driver not from the host controller as this is > where the information about the device usage is. And that's exactly > what MMC_PM_KEEP_POWER is about. When the WIFI driver receives a > suspend request, it can set that flag to tell the rest of the stack that > it wants to remain alive regardless of what the rest of the system does > to go to sleep. Then the firmware on the WIFI card can be notified of > that state and go on with its business until it decides it has data for > which the host CPU should pay attention. Then the host resumes itself > as usual, except for the WIFI driver which simply has to continue > operating the card without having to go through reconfiguration, > firmware loading, and so on. Everything is correct but I also want to skip sdio device reinitialization from SDIO stack perspective. > >> >> 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? >> You see, we are not talking about wlan chip power. CPU is consuming in >> average more energy, so >> we are talking about overall savings or consumption and not >> specifically wlan. I mean, definitely >> turn off SDC controller and remove device will save power, BUT we will >> spend much more time on resume >> meaning - more power for CPU... > > I still disagree with your patch. If you want to turn the CPU off and > not the peripherals then this is more about some idle state than suspend > state. Or at least that's how you should conceptualize it. > > If some peripherals are not in use, they should always be powered off > anyway, whether or not the CPU is suspended. Agree 100% but this is not the case. > But disabling suspend methods like your patch does is fundamentally > the wrong approach. Again, I am open for reasonable suggestions. > Nicolas > 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
