Yong,

Idea of defining various C states is to get maximum power savings both active and inactive usecases. C states you defined below are definitely good as a starting point. May be you can define more C states by adding more granularity depending on what are controlled as part of CPUIdle. Eg: In OMAP, we have defined C states primarily based on MPU and Core States as they are controlled in CPUIdle. MPU supports ON, INACTIVE, RETENTION and OF state and similarly the Core. So C states are defined based on various MPU and Core state combinations (MPU INACTIVE - CORE ACTIVE, MPU RET - CORE RET etc).

Vishwa

On Mon, Jan 31, 2011 at 3:17 PM, Yong Shen yong.shen@linaro.org wrote:

Hi there, I am trying to implement cpuidle driver for imx51, and for better understanding how various c-state map to ARM soc, I would like to get some comments. First of all, we basically have 3 major state for imx51, which are defined in specification of the soc. Like: RUN - Core is active, clocks are on, the peripheral modules required are active. SW can close clocks of modules that are not in use. In addition CCM can enable power gating for the modules described above. WAIT - Core is disabled and clock gated, bus clocks to peripherals can be on as required. PG [power gating] and SRPG[state retention PG] can be applied to Cortex_A8 and the different blocks as described on the section above. STOP - Core is disabled, peripherals are disabled, bus clocks are off, PLLs off. PG and SRPG can be applied to Cortex_A8 and the different blocks as described on the section above. Naturely, I think the maping can be: RUN - c0 WAIT - c1 STOP - c2 Or, if possible, some extra states can be assert into each c-state to get c3, c4.... Since other SOCs, like omap or samsung's chip, already have cpuidle driver, I would like to especially compare imx51 with those. thanks Yong