2010/12/29 Gao, Yunpeng <yunpeng.gao@xxxxxxxxx>: > So, why we have to move to the 'aggressive clock gating framework'? The aggressive clock gating makes more sense since the different drivers will know better how to handle the gating. ios with f=0 can be interpreted differently. Else every driver has to register runtime PM hooks for this, which is less elegant. A better question is why the clock gating does not use runtime PM abstractions. The hysteresis (timeout after inactivity, in the MMC spec >= 8 MCLK cycles) can possibly be handled by refactoring the runtime PM framework, someone offered to look at this later actually. > Also, I noticed that in the current 'aggressive clock gating > framework' patch, the clock gating of SDIO card has been > disabled (please reference code and comments of function > mmc_host_may_gate_card() in that patch). We discussed different approaches to this, from marking an SDIO slot as suspendable by using platform data, or whitelisting the SDIO cards that can handle clock gating. It was decided to keep SDIO cards out of it until we have this infrastructure in place. So now you will have the opportunity to fix this! Not all SDIO cards will work properly if you try to gate them so we need a mechanism to selectively do this. Any suggestions? Yours, Linus Walleij -- 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
