Hello Sanjeev, On Thu, Apr 14, 2011 at 12:36:17PM -0500, Premi, Sanjeev wrote: > > -----Original Message----- > > From: Valentin, Eduardo > > Sent: Thursday, April 14, 2011 11:04 PM > > To: Premi, Sanjeev > > Cc: Valentin, Eduardo; Paul Walmsley; Kevin Hilman; > > Linux-OMAP; Linux-ARM > > Subject: Re: [PATCH 2/2] OMAP3: PM: Do not rely on ROM code > > to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL > > > > Hello Sanjeev, > > > > > > On Thu, Apr 14, 2011 at 09:13:14AM -0500, Premi, Sanjeev wrote: > > > > -----Original Message----- > > > > From: linux-omap-owner@xxxxxxxxxxxxxxx > > > > [mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of > > > > Valentin, Eduardo > > > > Sent: Wednesday, April 13, 2011 8:51 PM > > > > To: Paul Walmsley; Kevin Hilman > > > > Cc: Linux-OMAP; Linux-ARM; Valentin, Eduardo > > > > Subject: [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to > > > > restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL > > > > > > > > As per OMAP3 erratum (i671), ROM code adds extra latencies while > > > > restoring CM_AUTOIDLE_PLL register, if AUTO_PERIPH_DPLL > > is equal to 1. > > > > > > > > This patch stores 0's in scratchpad content area corresponding to > > > > AUTO_PERIPH_DPLL, to prevent ROM code to try to lock per > > DPLL, since > > > > it won't respect proper programing scheme. > > > > > > > > This register is then stored in prcm context. The saving > > and restore > > > > is now done by kernel side. > > > > > > > > Here follow the erratum description > > > > > > > > DESCRIPTION > > > > > > > > After OFF mode transition, among many restorations, the ROM > > > > Code restores the > > > > CM_AUTOIDLE_PLL register, and after that, it tries to relock > > > > the PER DPLL. > > > > > > > > In case the restoration data stored in scratchpad memory > > > > contains a field > > > > CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL = 1, then the way the ROM > > > > Code restores and > > > > locks the PER DPLL does not respect the PER DPLL > > programming scheme. > > > > > > > > In that case, the DPLL might not lock. Meanwhile, when trying > > > > to lock the PER > > > > DPLL, the ROM Code does not hang. Only extra latencies are > > > > introduced at > > > > wake-up. > > > > > > > > > > [sp] You seem to have missed this patch: > > > http://marc.info/?l=linux-arm-kernel&m=129735383925285&w=2 > > > > Right, > > > > But that one doesn't clear the AUTO_PERIPH_DPLL bits in the > > scratchpad area > > to avoid rom code extra overhead (check my patch description). > > > > Besides, why do we want to add more code inside omap_sram_idle, > > if we have better places to this S&R? > > Didn't see that as a comment earlier? Better later than never :-) ? > > ~sanjeev > > > > > > > > > > > ~sanjeev > > > > > > > > > > All best, > > > > -- > > Eduardo Valentin > > Cheers, -- Eduardo Valentin -- 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
