Hi Tero, On Fri, 2011-01-21 at 12:37 +0200, Tero Kristo wrote: > On OMAP3 SoCs, if the CORE powerdomain enters off-mode, many other > parts of the chip will be reset. If those parts of the chip are busy, > the reset will disrupt them, causing unpredictable and generally > undesirable results. This reset is caused by the core domain wakeup > (COREDOMAINWKUP_RST), and it can occur for example in a case where > some peripheral domain is in retention or inactive state and core > enters off. This will result in the peripheral domain being reset.
Found a minor bug here... > Signed-off-by: Tero Kristo <tero.kri...@nokia.com> > Cc: Paul Walmsley <p...@pwsan.com> > Cc: Kevin Hilman <khil...@deeprootsystems.com> > Cc: Santosh Shilimkar <santosh.shilim...@ti.com> > Cc: Vishwanath Sripathy <vishwanath...@ti.com> > --- > arch/arm/mach-omap2/cpuidle34xx.c | 40 +++++++++++++++++++++++++++++++++++- > 1 files changed, 38 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-omap2/cpuidle34xx.c > b/arch/arm/mach-omap2/cpuidle34xx.c > index f3e043f..d31b858 100644 > --- a/arch/arm/mach-omap2/cpuidle34xx.c > +++ b/arch/arm/mach-omap2/cpuidle34xx.c > @@ -61,7 +61,7 @@ struct omap3_processor_cx { > struct omap3_processor_cx omap3_power_states[OMAP3_MAX_STATES]; > struct omap3_processor_cx current_cx_state; > struct powerdomain *mpu_pd, *core_pd, *per_pd; > -struct powerdomain *cam_pd; > +struct powerdomain *cam_pd, *dss_pd, *iva2_pd, *sgx_pd, *usb_pd; > > /* > * The latencies/thresholds for various C states have > @@ -235,7 +235,7 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev, > { > struct cpuidle_state *new_state = next_valid_state(dev, state); > u32 core_next_state, per_next_state = 0, per_saved_state = 0; > - u32 cam_state; > + u32 cam_state, dss_state, iva2_state, sgx_state, usb_state; > struct omap3_processor_cx *cx; > int ret; > > @@ -256,6 +256,8 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev, > * its own code. > */ > > + /* XXX Add CORE-active check here */ > + > /* > * Prevent idle completely if CAM is active. > * CAM does not have wakeup capability in OMAP3. > @@ -275,6 +277,36 @@ static int omap3_enter_idle_bm(struct cpuidle_device > *dev, > (core_next_state > PWRDM_POWER_RET)) > per_next_state = PWRDM_POWER_RET; > > + /* XXX Add prevent-PER-off check here */ > + > + /* > + * If we are attempting CORE off, check if any other powerdomains > + * are at retention or higher. CORE off causes chipwide reset which > + * would reset these domains also. > + */ > + if (core_next_state == PWRDM_POWER_OFF) { > + iva2_state = pwrdm_read_pwrst(iva2_pd); > + sgx_state = pwrdm_read_pwrst(sgx_pd); > + usb_state = pwrdm_read_pwrst(usb_pd); > + dss_state = pwrdm_read_pwrst(dss_pd); > + > + if (cam_state > PWRDM_POWER_OFF || > + dss_state > PWRDM_POWER_OFF || > + iva2_state > PWRDM_POWER_OFF || > + per_next_state > PWRDM_POWER_OFF || > + sgx_state > PWRDM_POWER_OFF || > + usb_state > PWRDM_POWER_OFF) > + core_next_state = PWRDM_POWER_RET; > + } > + > + /* Fallback to new target core/mpu state */ > + while (cx->core_state < core_next_state) { > + state--; This can potentially pick a state that has its 'valid' flag set to zero, for example, a state with MPU/CORE set to off-mode, but enable_off_mode=0. The fix is to also add a check for cx->valid in the while test. Will fold that fix into original patch and queue for 2.6.39. Kevin > + cx = cpuidle_get_statedata(state); > + } > + > + new_state = state; > + > /* Are we changing PER target state? */ > if (per_next_state != per_saved_state) > pwrdm_set_next_pwrst(per_pd, per_next_state); > @@ -489,6 +521,10 @@ int __init omap3_idle_init(void) > core_pd = pwrdm_lookup("core_pwrdm"); > per_pd = pwrdm_lookup("per_pwrdm"); > cam_pd = pwrdm_lookup("cam_pwrdm"); > + dss_pd = pwrdm_lookup("dss_pwrdm"); > + iva2_pd = pwrdm_lookup("iva2_pwrdm"); > + sgx_pd = pwrdm_lookup("sgx_pwrdm"); > + usb_pd = pwrdm_lookup("usbhost_pwrdm"); > > omap_init_power_states(); > cpuidle_register_driver(&omap3_idle_driver); -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html