Re: [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?


> 
> ~sanjeev
> 
> 

All best,

--
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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux