Re: [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.

[Nishanth Menon <nm@ti.com>]

Felipe Balbi had written, on 09/02/2010 05:00 AM, the following:
> On Thu, 2 Sep 2010 03:17:56 -0500, Nishanth Menon <nm@ti.com> wrote:
>> Just brainstorming -> if we use the regulator framework - there are 
>> potential benefits - agreed. BUT, consider the cpuidle path -> currently
> 
>> we disable SR while hitting off/ret for class3, this is done in irq 
>> locked context while the regulator framework uses locks by itself - we 
> 
> wouldn't it be enough to:
> 
> spin_unlock(&sr_lock);
> call_whatever_regulator_api();
> spin_lock(&sr_lock);
> 
> [...]
> 
> spin_unlock_irqrestore(&sr_lock, flags);
> 
> ??
> 
> otherwise we will have yet another OMAP-only API to maintain.
> 
unfortunately no. look at omap_sram_idle function in 
arch/arm/mach-omap2/pm34xx.c

we do irq_lock_save to prevent interrupts from messing up our decision logic

apply a lot of checks to translate C state to mean which domain is going 
to go to which OMAP domain state mode - ret/off/inactive etc..

add a bunch of erratas on top of it

finally see if the core/mpu domains (in case of omap4 ivahd domain as 
well) is going to ret/off state - if yes, SR is disabled for that domain.

note - if we allow unlock of irqs at this point, we cannot predictably 
progress down the logic.

the option is to move up the sr disable out of omap_sram_idle into yet 
to be determined logic where irqs are enabled, c state is decided and if 
c state is lower than a threshold (meaning if mpu OR core OR ivahd can 
go to lower power states), disable SR.. not efficient and without 
looking deeper at logic and considering multiple omap generations not 
sure if this will scale either..


-- 
Regards,
Nishanth Menon