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@xxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
