On Thu, 14 Oct 2010, Dmitry Shmidt wrote: > 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. It is already skipped. See mmc_sdio_init_card() and notice the powered_resume argument which avoids all the costly initializations. > > But disabling suspend methods like your patch does is fundamentally > > the wrong approach. > > Again, I am open for reasonable suggestions. It is unreasonable to suspend and resume the system so frequently that the cost of the SDIO powered suspend/resume code becomes measurable. So if you are seeing significant costs associated to suspend/resume, then this is a sign that you probably are misusing it and should not have invoked a suspend at all in the first place. Maybe you should investigate the CPU idle infrastructure instead. But inhibiting the suspend method like this with a flag looks much more like a dirty hack. Nicolas
