On Sat, 22 Jan 2011, Ohad Ben-Cohen wrote: > On Thu, Jan 20, 2011 at 7:08 AM, Chris Ball <cjb@xxxxxxxxxx> wrote: > > On Wed, Jan 19, 2011 at 09:45:57AM +0000, Tardy, Pierre wrote: > >> Chris, > >> (Sorry for top posting) > >> Seems we have a intel intern disagreement. > >> > >> Could we have maintainer opinion on this ? > > > > Linus W and Ohad, any input here? Thanks, > > Personally I prefer the runtime PM approach. > > The MMC aggressive clock gating framework is great, but it ended up > duplicating plumbing that already existed in the runtime PM framework > (workqueue, locking, usage refcount, "get/put" API). > > Moving to runtime PM should reduce a fair amount of code from the MMC > core, make the code more readable and easier to maintain, and let us > take advantage of standard tools and knobs that are based on runtime > PM's sysfs entries. No! Please don't conflate those two cases together again. First case: you want to stop the clock _to_ the _card_ when not talking to it. That has nothing to do with power saving performed within the host controller. This is for reducing power consumption by the _card_ (and possibly by the clock generator). The runtime PM stuff has no business here as the decision to gate the clock on the card require MMC/SD protocol knowledge. Second case: you want the _host_CONTROLLER_ to be shut down so it doesn't consume power by itself when idle. This would be performed when case 1 has gated the clock, but not necessarily always. Here the runtime PM infrastructure could make some sense. All host controllers can gate the card's clock, but not all of them can power themselves down. And maybe there would be a case for keeping the clock to a SDIO card active while the host controller is powered down. Knowledge for gating the card's clock is in the core code and independent from the host controller. Knowledge for powering down the host controller is in the host controller driver. So those two cases really need to remain separate. Nicolas
