>>-----Original Message----- >>From: Paul Walmsley [mailto:[email protected]] >>Sent: Wednesday, January 20, 2010 11:05 PM >>To: Gopinath, Thara >>Cc: [email protected] >>Subject: Re: [PATCH 6/8] OMAP3 PM: Enable DPLL4 autoidle after system off. >> >>Hi Thara, >> >>two comments: >> >>On Wed, 20 Jan 2010, Thara Gopinath wrote: >> >>> DPLL4 autoidle is controlled through the register CM_PLL_AUTOIDLE >>> which is to be restored by rom code from the scratchpad in case >>> of a core domain context loss. But enabling this bit in scratchpad >>> causes rom code to take an extra 20 ms delay in the restore path. >>> To avoid this delay this bit is not enabled in the scratchpad today. >>> This means after a core off happens DPLL4 autoidle is never again >>> enabled back. >>> This patch enables DPLL4 autoidle in case of core domain losing >>> context. >> >>Shouldn't this be contingent on whether DPLL4 autoidle was enabled before >>the CORE off transition?
Hi Paul, Hmmm may be yes.. But you see today we enable all autoidle bits in the init. Why I had to make this unconditional is because later before core entering OSWR I explicitly disable this bit in the register. This is so as to match this register content with those of scratchpad during OSWR. Failing to do this rom code while exiting OSWR will take the path it takes while coming out of core off . This causes a crash in the system today. Also another reason is omap3_prcm_save_context needs to be called only during core off today. If I move saving of this bit and restoring it back into omap3_prcm_save_context and omap3_prcm_restore_context I will have to call it during core OSWR also. Wanted to avoid the extra complications. But if this approach is not ok, I can modify the save restore APIs to take power state as a parameter and do only dpll4 autoidle save and restore in case of OSWR. Is this ok? >> >>> Signed-off-by: Thara Gopinath <[email protected]> >>> --- >>> arch/arm/mach-omap2/pm34xx.c | 8 ++++++++ >>> 1 files changed, 8 insertions(+), 0 deletions(-) >>> >>> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c >>> index e4db1ea..6e6d954 100644 >>> --- a/arch/arm/mach-omap2/pm34xx.c >>> +++ b/arch/arm/mach-omap2/pm34xx.c >>> @@ -520,6 +520,14 @@ void omap_sram_idle(void) >>> */ >>> if (cpu_is_omap3430()) >>> usb_musb_disable_autoidle(); >>> + /* We do not program the scratchpad to restore back >>> + * PER DPLL in autoidle due to 20 ms delay in >>> + * rom code restore path. So enable it explicitly >>> + * after core off >>> + */ >> >>This multi-line comment needs to be fixed to conform to >>Documentation/CodingStyle. Oops.. My bad. Will fix and resend the patch. Don't know why checkpatch is not catching this. I will wait a couple of days for comments on other patches also and resend all of them after fixing the relevant comments. >> >>> + cm_rmw_mod_reg_bits( >>> + 0x0, (1 << OMAP3430_AUTO_PERIPH_DPLL_SHIFT), >>> + PLL_MOD, CM_AUTOIDLE); >>> } >>> omap_uart_resume_idle(0); >>> omap_uart_resume_idle(1); >>> -- >>> 1.5.6.3 >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in >>> the body of a message to [email protected] >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> >> >>- Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
