> > 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? > 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. Pierre --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
