| Message ID | alpine.DEB.2.00.1207121334150.25585@utopia.booyaka.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
-----Original Message----- From: Paul Walmsley <paul@pwsan.com> To: Joe Woodward <jw@terrafix.co.uk> Cc: Kevin Hilman <khilman@ti.com>, "linux-omap\\\\@vger.kernel.org" <linux-omap@vger.kernel.org> Date: Thu, 12 Jul 2012 13:35:14 -0600 (MDT) Subject: Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC? > Hello Joe, > > On Thu, 12 Jul 2012, Joe Woodward wrote: > > > I think this has fixed the following warning: > > [ 0.000000] clockdomain: mpu_clkdm: powerdomain ¬õ`À8ºsÀ does > not exist > > > > But when I try and suspend I still get the same problems: > > # echo mem > /sys/power/state > > [ 13.283935] PM: Syncing filesystems ... done. > > [ 13.300537] Freezing user space processes ... (elapsed 0.01 > seconds) done. > > [ 13.324859] Freezing remaining freezable tasks ... (elapsed 0.02 > seconds) done. > > [ 13.356140] Suspending console(s) (use no_console_suspend to > debug) > > [ 13.487823] PM: suspend of devices complete after 120.578 msecs > > [ 13.491577] PM: late suspend of devices complete after 3.722 msecs > > [ 13.497375] PM: noirq suspend of devices complete after 5.767 > msecs > > [ 13.497436] Disabling non-boot CPUs ... > > [ 15.806640] Powerdomain (iva2_pwrdm) didn't enter target state 1 > > [ 15.806640] Powerdomain (dss_pwrdm) didn't enter target state 1 > > [ 15.806671] Powerdomain (per_pwrdm) didn't enter target state 1 > > [ 15.806671] Powerdomain (core_pwrdm) didn't enter target state 1 > > [ 15.806671] Powerdomain (usbhost_pwrdm) didn't enter target state > 1 > > [ 15.806671] Could not enter target state in pm_suspend > > [ 15.809722] PM: noirq resume of devices complete after 2.868 msecs > > [ 15.813598] PM: early resume of devices complete after 2.380 msecs > > [ 16.179382] mmc1: error -110 during resume (card was removed?) > > [ 16.189575] PM: resume of devices complete after 375.824 msecs > > [ 16.279602] Restarting tasks ... done. > > sh: write error: Operation not permitted > > Thanks for the test. Perhaps you could try the following untested > patch? > > > - Paul > Thanks Paul, That patch does indeed seem to fix all my problems! With it I can now suspend, and all power domains hit the target states. Kevin - I did reply to your request for logs, but haven't seen the message make it to the mailing list... If you've not got it, let me know and I can try and send it again. Cheers, Joe > --- > arch/arm/mach-omap2/pm34xx.c | 14 +++++--------- > 1 file changed, 5 insertions(+), 9 deletions(-) > > diff --git a/arch/arm/mach-omap2/pm34xx.c > b/arch/arm/mach-omap2/pm34xx.c > index e4fc88c..ced2f76 100644 > --- a/arch/arm/mach-omap2/pm34xx.c > +++ b/arch/arm/mach-omap2/pm34xx.c > @@ -545,13 +545,10 @@ static void __init prcm_setup_regs(void) > OMAP3430_PER_MOD, OMAP3430_PM_MPUGRPSEL); > > /* Don't attach IVA interrupts */ > - if (omap3_has_iva()) { > - omap2_prm_write_mod_reg(0, WKUP_MOD, OMAP3430_PM_IVAGRPSEL); > - omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430_PM_IVAGRPSEL1); > - omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430ES2_PM_IVAGRPSEL3); > - omap2_prm_write_mod_reg(0, OMAP3430_PER_MOD, > - OMAP3430_PM_IVAGRPSEL); > - } > + omap2_prm_write_mod_reg(0, WKUP_MOD, OMAP3430_PM_IVAGRPSEL); > + omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430_PM_IVAGRPSEL1); > + omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430ES2_PM_IVAGRPSEL3); > + omap2_prm_write_mod_reg(0, OMAP3430_PER_MOD, OMAP3430_PM_IVAGRPSEL); > > /* Clear any pending 'reset' flags */ > omap2_prm_write_mod_reg(0xffffffff, MPU_MOD, OMAP2_RM_RSTST); > @@ -565,8 +562,7 @@ static void __init prcm_setup_regs(void) > /* Clear any pending PRCM interrupts */ > omap2_prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET); > > - if (omap3_has_iva()) > - omap3_iva_idle(); > + omap3_iva_idle(); > > omap3_d2d_idle(); > } > -- > 1.7.10 -- 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
+ Mark On Fri, 13 Jul 2012, Joe Woodward wrote: > Thanks Paul, > > That patch does indeed seem to fix all my problems! > > With it I can now suspend, and all power domains hit the target states. OK, great. That patch is basically a revert of a819c4f16d5a2708c11e708fd59a96565c5384a8 ("ARM: OMAP3: PM: Only access IVA if one exists"). Sounds like we need to discriminate between the case where the IVA2 is present but has been efused off in some way (as in the AM3703) vs. the case where the IVA2 is not present at all (as in the AM35xx). Mark, do you have the time to take a look at this? Maybe omap3_has_iva() needs to be split into omap3_has_iva() and omap3_has_usable_iva(). Or maybe you can come up with a better idea... - 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
On Fri, Jul 13, 2012 at 12:26:13PM -0600, Paul Walmsley wrote: > + Mark > > On Fri, 13 Jul 2012, Joe Woodward wrote: > > > Thanks Paul, > > > > That patch does indeed seem to fix all my problems! > > > > With it I can now suspend, and all power domains hit the target states. > > OK, great. That patch is basically a revert of > a819c4f16d5a2708c11e708fd59a96565c5384a8 ("ARM: OMAP3: PM: Only access IVA > if one exists"). Sounds like we need to discriminate between the case > where the IVA2 is present but has been efused off in some way (as in the > AM3703) vs. the case where the IVA2 is not present at all (as in the > AM35xx). > > Mark, do you have the time to take a look at this? Maybe omap3_has_iva() > needs to be split into omap3_has_iva() and omap3_has_usable_iva(). Or > maybe you can come up with a better idea... Sure, I'll see what I can figure out. Mark -- 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
On Fri, Jul 13, 2012 at 12:26:13PM -0600, Paul Walmsley wrote: > + Mark > > On Fri, 13 Jul 2012, Joe Woodward wrote: > > > Thanks Paul, > > > > That patch does indeed seem to fix all my problems! > > > > With it I can now suspend, and all power domains hit the target states. > > OK, great. That patch is basically a revert of > a819c4f16d5a2708c11e708fd59a96565c5384a8 ("ARM: OMAP3: PM: Only access IVA > if one exists"). Sounds like we need to discriminate between the case > where the IVA2 is present but has been efused off in some way (as in the > AM3703) vs. the case where the IVA2 is not present at all (as in the > AM35xx). > > Mark, do you have the time to take a look at this? Maybe omap3_has_iva() > needs to be split into omap3_has_iva() and omap3_has_usable_iva(). Or > maybe you can come up with a better idea... Hi Joe. I'm finally getting around to this... Unfortunately, I don't have the hardware to test it so I can't tell exactly what code needs to run to make it work again. Would you mind identifying the pieces of code need to run for it to work? omap3_has_iva() shows up in just a few places. Thanks, Mark -- 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
On Mon, 16 Jul 2012, Mark A. Greer wrote: > I'm finally getting around to this... Unfortunately, I don't have the > hardware to test it so I can't tell exactly what code needs to run to make > it work again. Would you mind identifying the pieces of code need to run > for it to work? omap3_has_iva() shows up in just a few places. We did a test by removing the two instances in pm34xx.c. I'm pretty sure that the IVAGRPSEL writes are necessary, since the reset values for those bits are 1, and those definitely need to be cleared. Not sure about the omap3_iva_idle() call; Joe, maybe you can try with just the first hunk of the patch that I sent? - 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
-----Original Message----- From: Paul Walmsley <paul@pwsan.com> To: Joe Woodward <jw@terrafix.co.uk>, "Mark A. Greer" <mgreer@animalcreek.com> Cc: Kevin Hilman <khilman@ti.com>, linux-omap@vger.kernel.org Date: Mon, 16 Jul 2012 18:43:15 -0600 (MDT) Subject: Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC? > On Mon, 16 Jul 2012, Mark A. Greer wrote: > > > I'm finally getting around to this... Unfortunately, I don't have > the > > hardware to test it so I can't tell exactly what code needs to run to > make > > it work again. Would you mind identifying the pieces of code need > to run > > for it to work? omap3_has_iva() shows up in just a few places. > > We did a test by removing the two instances in pm34xx.c. I'm pretty > sure > that the IVAGRPSEL writes are necessary, since the reset values for > those > bits are 1, and those definitely need to be cleared. Not sure about > the > omap3_iva_idle() call; Joe, maybe you can try with just the first hunk > of > the patch that I sent? The patch you sent is basically in two halves: - the writes to the registers - the calling of omap3_iva_idle(). If I patch only the writes to the registers then suspend still fails. If I patch only the calling of omap3_iva_idle() then suspend works. If I patch both the writes to the registers and the calling of omap3_iva_idle() then suspend works. Cheers, Joe > > > - 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 -- 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
Hi Joe, Mark, On Tue, 17 Jul 2012, Joe Woodward wrote: > The patch you sent is basically in two halves: > - the writes to the registers > - the calling of omap3_iva_idle(). > > If I patch only the writes to the registers then suspend still fails. > If I patch only the calling of omap3_iva_idle() then suspend works. > If I patch both the writes to the registers and the calling of omap3_iva_idle() then suspend works. Wow, that's unexpected. Thanks very much for trying this. Well Mark, I guess that's your answer. Looks like the IVA is still running on that AM3703 chip. I guess it's probably best to do both halves, anyway. - 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
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index e4fc88c..ced2f76 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -545,13 +545,10 @@ static void __init prcm_setup_regs(void) OMAP3430_PER_MOD, OMAP3430_PM_MPUGRPSEL); /* Don't attach IVA interrupts */ - if (omap3_has_iva()) { - omap2_prm_write_mod_reg(0, WKUP_MOD, OMAP3430_PM_IVAGRPSEL); - omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430_PM_IVAGRPSEL1); - omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430ES2_PM_IVAGRPSEL3); - omap2_prm_write_mod_reg(0, OMAP3430_PER_MOD, - OMAP3430_PM_IVAGRPSEL); - } + omap2_prm_write_mod_reg(0, WKUP_MOD, OMAP3430_PM_IVAGRPSEL); + omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430_PM_IVAGRPSEL1); + omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430ES2_PM_IVAGRPSEL3); + omap2_prm_write_mod_reg(0, OMAP3430_PER_MOD, OMAP3430_PM_IVAGRPSEL); /* Clear any pending 'reset' flags */ omap2_prm_write_mod_reg(0xffffffff, MPU_MOD, OMAP2_RM_RSTST); @@ -565,8 +562,7 @@ static void __init prcm_setup_regs(void) /* Clear any pending PRCM interrupts */ omap2_prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET); - if (omap3_has_iva()) - omap3_iva_idle(); + omap3_iva_idle(); omap3_d2d_idle(); }