All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/2] Couple of fixes regarding CM_AUTOIDLE_PLL register
@ 2011-04-13 15:21 ` Eduardo Valentin
  0 siblings, 0 replies; 18+ messages in thread
From: Eduardo Valentin @ 2011-04-13 15:21 UTC (permalink / raw)
  To: Paul Walmsley, Kevin Hilman; +Cc: Linux-OMAP, Linux-ARM, 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


^ permalink raw reply	[flat|nested] 18+ messages in thread
* [PATCH 0/2] Couple of fixes regarding CM_AUTOIDLE_PLL register
@ 2011-04-13 15:21 ` Eduardo Valentin
  0 siblings, 0 replies; 18+ messages in thread
From: Eduardo Valentin @ 2011-04-13 15:21 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 18+ messages in thread
* [PATCH 1/2] OMAP2+: PM: Fix the saving of CM_AUTOIDLE_PLL register on scratchpad area
  2011-04-13 15:21 ` Eduardo Valentin
@ 2011-04-13 15:21   ` Eduardo Valentin
  -1 siblings, 0 replies; 18+ messages in thread
From: Eduardo Valentin @ 2011-04-13 15:21 UTC (permalink / raw)
  To: Paul Walmsley, Kevin Hilman; +Cc: Linux-OMAP, Linux-ARM, 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


^ permalink raw reply related	[flat|nested] 18+ messages in thread
* [PATCH 1/2] OMAP2+: PM: Fix the saving of CM_AUTOIDLE_PLL register on scratchpad area
@ 2011-04-13 15:21   ` Eduardo Valentin
  0 siblings, 0 replies; 18+ messages in thread
From: Eduardo Valentin @ 2011-04-13 15:21 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply related	[flat|nested] 18+ messages in thread
* [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL
  2011-04-13 15:21 ` Eduardo Valentin
@ 2011-04-13 15:21   ` Eduardo Valentin
  -1 siblings, 0 replies; 18+ messages in thread
From: Eduardo Valentin @ 2011-04-13 15:21 UTC (permalink / raw)
  To: Paul Walmsley, Kevin Hilman; +Cc: Linux-OMAP, Linux-ARM, 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


^ permalink raw reply related	[flat|nested] 18+ messages in thread
* [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL
@ 2011-04-13 15:21   ` Eduardo Valentin
  0 siblings, 0 replies; 18+ messages in thread
From: Eduardo Valentin @ 2011-04-13 15:21 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply related	[flat|nested] 18+ messages in thread
* RE: [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL
  2011-04-13 15:21   ` Eduardo Valentin
@ 2011-04-14 14:13     ` Premi, Sanjeev
  -1 siblings, 0 replies; 18+ messages in thread
From: Premi, Sanjeev @ 2011-04-14 14:13 UTC (permalink / raw)
  To: Valentin, Eduardo, Paul Walmsley, Kevin Hilman; +Cc: Linux-OMAP, Linux-ARM

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



^ permalink raw reply	[flat|nested] 18+ messages in thread
* [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL
@ 2011-04-14 14:13     ` Premi, Sanjeev
  0 siblings, 0 replies; 18+ messages in thread
From: Premi, Sanjeev @ 2011-04-14 14:13 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL
  2011-04-14 14:13     ` Premi, Sanjeev
@ 2011-04-14 17:33       ` Eduardo Valentin
  -1 siblings, 0 replies; 18+ messages in thread
From: Eduardo Valentin @ 2011-04-14 17:33 UTC (permalink / raw)
  To: Premi, Sanjeev
  Cc: Valentin, Eduardo, Paul Walmsley, Kevin Hilman, Linux-OMAP, Linux-ARM

Hello Sanjeev,


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

^ permalink raw reply	[flat|nested] 18+ messages in thread
* [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL
@ 2011-04-14 17:33       ` Eduardo Valentin
  0 siblings, 0 replies; 18+ messages in thread
From: Eduardo Valentin @ 2011-04-14 17:33 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 18+ messages in thread
* RE: [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL
  2011-04-14 17:33       ` Eduardo Valentin
@ 2011-04-14 17:36         ` Premi, Sanjeev
  -1 siblings, 0 replies; 18+ messages in thread
From: Premi, Sanjeev @ 2011-04-14 17:36 UTC (permalink / raw)
  To: Valentin, Eduardo; +Cc: Paul Walmsley, Kevin Hilman, Linux-OMAP, Linux-ARM

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

^ permalink raw reply	[flat|nested] 18+ messages in thread
* [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL
@ 2011-04-14 17:36         ` Premi, Sanjeev
  0 siblings, 0 replies; 18+ messages in thread
From: Premi, Sanjeev @ 2011-04-14 17:36 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL
  2011-04-14 17:36         ` Premi, Sanjeev
@ 2011-04-14 17:42           ` Eduardo Valentin
  -1 siblings, 0 replies; 18+ messages in thread
From: Eduardo Valentin @ 2011-04-14 17:42 UTC (permalink / raw)
  To: Premi, Sanjeev
  Cc: Valentin, Eduardo, Paul Walmsley, Kevin Hilman, Linux-OMAP, Linux-ARM

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

^ permalink raw reply	[flat|nested] 18+ messages in thread
* [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL
@ 2011-04-14 17:42           ` Eduardo Valentin
  0 siblings, 0 replies; 18+ messages in thread
From: Eduardo Valentin @ 2011-04-14 17:42 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 18+ messages in thread
* Re: [PATCH 0/2] Couple of fixes regarding CM_AUTOIDLE_PLL register
  2011-04-13 15:21 ` Eduardo Valentin
@ 2011-04-20 19:32   ` Paul Walmsley
  -1 siblings, 0 replies; 18+ messages in thread
From: Paul Walmsley @ 2011-04-20 19:32 UTC (permalink / raw)
  To: Eduardo Valentin; +Cc: Kevin Hilman, Linux-OMAP, Linux-ARM


Thanks, queued both of these for 2.6.39-rc.


- Paul

^ permalink raw reply	[flat|nested] 18+ messages in thread
* [PATCH 0/2] Couple of fixes regarding CM_AUTOIDLE_PLL register
@ 2011-04-20 19:32   ` Paul Walmsley
  0 siblings, 0 replies; 18+ messages in thread
From: Paul Walmsley @ 2011-04-20 19:32 UTC (permalink / raw)
  To: linux-arm-kernel


Thanks, queued both of these for 2.6.39-rc.


- Paul

^ permalink raw reply	[flat|nested] 18+ messages in thread
* RE: [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL
  2011-04-14 14:13     ` Premi, Sanjeev
@ 2011-04-20 19:35       ` Paul Walmsley
  -1 siblings, 0 replies; 18+ messages in thread
From: Paul Walmsley @ 2011-04-20 19:35 UTC (permalink / raw)
  To: Premi, Sanjeev; +Cc: Valentin, Eduardo, Kevin Hilman, Linux-OMAP, Linux-ARM

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

^ permalink raw reply	[flat|nested] 18+ messages in thread
* [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL
@ 2011-04-20 19:35       ` Paul Walmsley
  0 siblings, 0 replies; 18+ messages in thread
From: Paul Walmsley @ 2011-04-20 19:35 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 18+ messages in thread
end of thread, other threads:[~2011-04-20 19:35 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-04-13 15:21 [PATCH 0/2] Couple of fixes regarding CM_AUTOIDLE_PLL register Eduardo Valentin
2011-04-13 15:21 ` Eduardo Valentin
2011-04-13 15:21 ` [PATCH 1/2] OMAP2+: PM: Fix the saving of CM_AUTOIDLE_PLL register on scratchpad area Eduardo Valentin
2011-04-13 15:21   ` Eduardo Valentin
2011-04-13 15:21 ` [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL Eduardo Valentin
2011-04-13 15:21   ` Eduardo Valentin
2011-04-14 14:13   ` Premi, Sanjeev
2011-04-14 14:13     ` Premi, Sanjeev
2011-04-14 17:33     ` Eduardo Valentin
2011-04-14 17:33       ` Eduardo Valentin
2011-04-14 17:36       ` Premi, Sanjeev
2011-04-14 17:36         ` Premi, Sanjeev
2011-04-14 17:42         ` Eduardo Valentin
2011-04-14 17:42           ` Eduardo Valentin
2011-04-20 19:35     ` Paul Walmsley
2011-04-20 19:35       ` Paul Walmsley
2011-04-20 19:32 ` [PATCH 0/2] Couple of fixes regarding CM_AUTOIDLE_PLL register Paul Walmsley
2011-04-20 19:32   ` Paul Walmsley

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.