| Message ID | 877gtb6723.fsf@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Kevin, On Mon, 6 Aug 2012, Kevin Hilman wrote: > Is this only happening on this 37xx platform? Just curious, because > it seems to be a problem on any OMAP3xxx SoC. So far I've only run the baseline tests on 37xx, so wanted to state only what was observed here. > ...it must be the usecounts that are not being updated. This seems to > be a side effect of the pre/post transition optimization I did. A quick > hack seems to indicate that that's indeed the case[1]. By default, > omap_sram_idle() is now only calling the pre/post callbacks for MPU, > NEON, PER, and CORE, and only if those domains are transitioning, so any > other domains not explicitly managed by the idle path have lots their > usecounting. Oops. > > I guess Tero's usecounting series should fix this up. Thanks for the diagnosis. Care to put together a patch to fix this for v3.6-rc? The earliest point that the usecounting improvements could get in would be v3.7. This problem is breaking the PM regression tests here that parse the powerdomain state count fields. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Paul Walmsley <paul@pwsan.com> writes: > Hi Kevin, > > On Mon, 6 Aug 2012, Kevin Hilman wrote: > >> Is this only happening on this 37xx platform? Just curious, because >> it seems to be a problem on any OMAP3xxx SoC. > > So far I've only run the baseline tests on 37xx, so wanted to state only > what was observed here. > >> ...it must be the usecounts that are not being updated. This seems to >> be a side effect of the pre/post transition optimization I did. A quick >> hack seems to indicate that that's indeed the case[1]. By default, >> omap_sram_idle() is now only calling the pre/post callbacks for MPU, >> NEON, PER, and CORE, and only if those domains are transitioning, so any >> other domains not explicitly managed by the idle path have lots their >> usecounting. Oops. >> >> I guess Tero's usecounting series should fix this up. > > Thanks for the diagnosis. Care to put together a patch to fix this for > v3.6-rc? Done. http://marc.info/?l=linux-omap&m=134437239010649&w=2 Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index e4fc88c..d87416f 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -70,6 +70,7 @@ void (*omap3_do_wfi_sram)(void); static struct powerdomain *mpu_pwrdm, *neon_pwrdm; static struct powerdomain *core_pwrdm, *per_pwrdm; +static struct powerdomain *dss_pwrdm, *usbhost_pwrdm; static void omap3_core_save_context(void) { @@ -393,7 +394,11 @@ static int omap3_pm_suspend(void) omap3_intc_suspend(); + pwrdm_pre_transition(dss_pwrdm); + pwrdm_pre_transition(usbhost_pwrdm); omap_sram_idle(); + pwrdm_post_transition(usbhost_pwrdm); + pwrdm_post_transition(dss_pwrdm); restore: /* Restore next_pwrsts */ @@ -718,6 +723,8 @@ int __init omap3_pm_init(void) neon_pwrdm = pwrdm_lookup("neon_pwrdm"); per_pwrdm = pwrdm_lookup("per_pwrdm"); core_pwrdm = pwrdm_lookup("core_pwrdm"); + dss_pwrdm = pwrdm_lookup("dss_pwrdm"); + usbhost_pwrdm = pwrdm_lookup("usbhost_pwrdm"); neon_clkdm = clkdm_lookup("neon_clkdm"); mpu_clkdm = clkdm_lookup("mpu_clkdm");