Nishanth Menon had written, on 12/15/2010 06:05 PM, the following:
> Kevin Hilman had written, on 12/15/2010 05:47 PM, the following:
> 
>>> I agree that this additional check in sram_idle should be removed, but
>>> as long as I handle it in omap3_pm_off_mode_enable where the next
>>> states are configured, is'nt that enough or am I missing something?
>>
>> Setting the next states only sets the default states, but CPUidle
>> changes them.
>>
>> Looking closer at omap3_pm_off_mode_enable() though, it already calls
>> into CPUidle and disables the valid bit for any states that have
>> *either* MPU or core off.    You'll probably just need to extend this
>> approach to disable only CORE off state(s).
> Thx. it is clear now. let me see how to clean this up.
k. Does the attached look any better now :)? I have removed the check 
logic from sram_idle path instead made omap3_cpuidle_update_states 
little more generic, updated validity of C state based on errata. This 
now disables just those C states with core OFF on 3630 <ES1.2

in a map, this will now look as follows:
--------+-------+-------+-------+-------+--------+
         | MPU   | Core  | OFF   | OFF Enable-36xx|
         | Dom   | Dom   |       +-------+--------+
C state | State | State | Dis   | ES1.1 | ES 1.2 |
--------+-------+-------+-------+-------+--------+
1       | ON    | ON    | YES   | YES   | YES    |
2       | ON    | ON    | YES   | YES   | YES    |
3       | RET   | ON    | YES   | YES   | YES    |
4       | OFF   | ON    | NO    | YES   | YES    |
5       | RET   | RET   | YES   | YES   | YES    |
6       | OFF   | RET   | NO    | YES   | YES    |
7       | OFF   | OFF   | NO    | NO    | YES    |
--------+-------+-------+-------+-------+--------+

-- 
Regards,
Nishanth Menon