[PATCH 0/2] Couple of fixes regarding CM_AUTOIDLE_PLL register

[PATCH 0/2] Couple of fixes regarding CM_AUTOIDLE_PLL register

[Eduardo Valentin]

Hello guys,

This patch set is fixing the saving and restore of CM_AUTOIDLE_PLL register.
It also includes a patch to save and restore it in kernel side, because
ROM code adds extra delay when we use it to restore this register.

Cheers,

Eduardo Valentin (2):
  OMAP2+: PM: Fix the saving of CM_AUTOIDLE_PLL register on scratchpad
    area
  OMAP3: PM: Do not rely on ROM code to restore
    CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL

 arch/arm/mach-omap2/cm2xxx_3xxx.c |   17 +++++++++++++++++
 arch/arm/mach-omap2/control.c     |    8 +++++++-
 2 files changed, 24 insertions(+), 1 deletions(-)

-- 
1.7.5-rc1

[PATCH 1/2] OMAP2+: PM: Fix the saving of CM_AUTOIDLE_PLL register on scratchpad area

[Eduardo Valentin]

The saving of CCR.CM_AUTOIDLE_PLL is done in scratchpad area.

However, in current code, the saving is done for CM_AUTOIDLE2_PLL
(offset 0x34) instead of CM_AUTOIDLE_PLL (offset 0x30).

This patch changes the code to save the correct register.

Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 arch/arm/mach-omap2/control.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 6952794..df0c75c 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -317,7 +317,7 @@ void omap3_save_scratchpad_contents(void)
 	prcm_block_contents.cm_clken_pll =
 			omap2_cm_read_mod_reg(PLL_MOD, CM_CLKEN);
 	prcm_block_contents.cm_autoidle_pll =
-			omap2_cm_read_mod_reg(PLL_MOD, OMAP3430_CM_AUTOIDLE_PLL);
+			omap2_cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE);
 	prcm_block_contents.cm_clksel1_pll =
 			omap2_cm_read_mod_reg(PLL_MOD, OMAP3430_CM_CLKSEL1_PLL);
 	prcm_block_contents.cm_clksel2_pll =
-- 
1.7.5-rc1

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

[Eduardo Valentin]

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.

WORKAROUND

When saving the context-restore structure in scratchpad memory, in order to
respect the PER DPLL programming scheme, it is advised to store 0 in the
CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL field of the saved structure.

After wake-up, the application should store in CM_AUTOIDLE_PLL register the
right desired value.

Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 arch/arm/mach-omap2/cm2xxx_3xxx.c |   17 +++++++++++++++++
 arch/arm/mach-omap2/control.c     |    8 +++++++-
 2 files changed, 24 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/cm2xxx_3xxx.c b/arch/arm/mach-omap2/cm2xxx_3xxx.c
index 9d0dec8..38830d8 100644
--- a/arch/arm/mach-omap2/cm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/cm2xxx_3xxx.c
@@ -247,6 +247,7 @@ struct omap3_cm_regs {
 	u32 per_cm_clksel;
 	u32 emu_cm_clksel;
 	u32 emu_cm_clkstctrl;
+	u32 pll_cm_autoidle;
 	u32 pll_cm_autoidle2;
 	u32 pll_cm_clksel4;
 	u32 pll_cm_clksel5;
@@ -319,6 +320,15 @@ void omap3_cm_save_context(void)
 		omap2_cm_read_mod_reg(OMAP3430_EMU_MOD, CM_CLKSEL1);
 	cm_context.emu_cm_clkstctrl =
 		omap2_cm_read_mod_reg(OMAP3430_EMU_MOD, OMAP2_CM_CLKSTCTRL);
+	/*
+	 * As per erratum i671, ROM code does not respect the PER DPLL
+	 * programming scheme if CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL == 1.
+	 * In this case, even though this register has been saved in
+	 * scratchpad contents, we need to restore AUTO_PERIPH_DPLL
+	 * by ourselves. So, we need to save it anyway.
+	 */
+	cm_context.pll_cm_autoidle =
+		omap2_cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE);
 	cm_context.pll_cm_autoidle2 =
 		omap2_cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE2);
 	cm_context.pll_cm_clksel4 =
@@ -441,6 +451,13 @@ void omap3_cm_restore_context(void)
 			       CM_CLKSEL1);
 	omap2_cm_write_mod_reg(cm_context.emu_cm_clkstctrl, OMAP3430_EMU_MOD,
 			       OMAP2_CM_CLKSTCTRL);
+	/*
+	 * As per erratum i671, ROM code does not respect the PER DPLL
+	 * programming scheme if CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL == 1.
+	 * In this case, we need to restore AUTO_PERIPH_DPLL by ourselves.
+	 */
+	omap2_cm_write_mod_reg(cm_context.pll_cm_autoidle, PLL_MOD,
+			       CM_AUTOIDLE);
 	omap2_cm_write_mod_reg(cm_context.pll_cm_autoidle2, PLL_MOD,
 			       CM_AUTOIDLE2);
 	omap2_cm_write_mod_reg(cm_context.pll_cm_clksel4, PLL_MOD,
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index df0c75c..da53ba3 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -316,8 +316,14 @@ void omap3_save_scratchpad_contents(void)
 			omap2_cm_read_mod_reg(WKUP_MOD, CM_CLKSEL);
 	prcm_block_contents.cm_clken_pll =
 			omap2_cm_read_mod_reg(PLL_MOD, CM_CLKEN);
+	/*
+	 * As per erratum i671, ROM code does not respect the PER DPLL
+	 * programming scheme if CM_AUTOIDLE_PLL..AUTO_PERIPH_DPLL == 1.
+	 * Then,  in anycase, clear these bits to avoid extra latencies.
+	 */
 	prcm_block_contents.cm_autoidle_pll =
-			omap2_cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE);
+			omap2_cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE) &
+			~OMAP3430_AUTO_PERIPH_DPLL_MASK;
 	prcm_block_contents.cm_clksel1_pll =
 			omap2_cm_read_mod_reg(PLL_MOD, OMAP3430_CM_CLKSEL1_PLL);
 	prcm_block_contents.cm_clksel2_pll =
-- 
1.7.5-rc1

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

[Premi, Sanjeev]

> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org 
> [mailto:linux-omap-owner at vger.kernel.org] 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

~sanjeev

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

[Eduardo Valentin]

Hello Sanjeev,


On Thu, Apr 14, 2011 at 09:13:14AM -0500, Premi, Sanjeev wrote:
> > -----Original Message-----
> > From: linux-omap-owner at vger.kernel.org 
> > [mailto:linux-omap-owner at vger.kernel.org] 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

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

[Premi, Sanjeev]

> -----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 at vger.kernel.org 
> > > [mailto:linux-omap-owner at vger.kernel.org] 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?

~sanjeev

> 
> 
> > 
> > ~sanjeev
> > 
> > 
> 
> All best,
> 
> --
> Eduardo Valentin
> 

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

[Eduardo Valentin]

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 at vger.kernel.org 
> > > > [mailto:linux-omap-owner at vger.kernel.org] 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

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

[Paul Walmsley]

Hi

On Thu, 14 Apr 2011, Premi, Sanjeev wrote:

> [sp] You seem to have missed this patch:
> http://marc.info/?l=linux-arm-kernel&m=129735383925285&w=2

I asked Eduardo to post his patches because there was no response to

http://marc.info/?l=linux-arm-kernel&m=129961775124912&w=2

and because he tracked down and fully documented the actual problem.


- Paul

[PATCH 0/2] Couple of fixes regarding CM_AUTOIDLE_PLL register

[Paul Walmsley]

Thanks, queued both of these for 2.6.39-rc.


- Paul