On Sun, 23 Jan 2011, Tardy, Pierre wrote: > > > > 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. > > Could not the mmcclock be a device on this own, and use rpm to manage its state? Isn't that rather overkill? The core stack may decide to tell the host controller to set the mmcclock to 400 kHz, 25 MHz, or even 0 Hz depending on various states that are deeply tied to the protocol used with the card and not necessarily for PM purposes. So why would you make the 0 Hz a special case here and handle it in a different framework from the other cases? The fact that we do try to set the clock to 0 Hz as often as possible for PM purposes is only consequential and I don't see the need for a side structure just to handle that case. > > 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. > Agree with this, this is the idea of the my implementation. > > > 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. > But knowledge on *how* to gate the clock is in the host controller driver, and/or platform code. So what? The clock is already handled today for reasons other than PM. And the aggressive clock gating had to modify only the core stack code and zero driver/platform code. Hence I don't see the advantage to move away from what we have now. Could you please elaborate more on the advantages you see there? Nicolas -- 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
