OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

PATCH Nayak, Rajendra 5 participants 12 messages Jun 17, 2009 – Jul 1, 2009 2 messages not in the archive

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): 1245224794.6847.141.camel@ubuntu

Nayak, Rajendra

author

2009-06-17 09:51 UTC #1 lore raw

Quoted 27 lines

-----Original Message-----
From: Kalle Jokiniemi [mailto:[email protected]]
Sent: Wednesday, June 17, 2009 1:17 PM
To: Nayak, Rajendra
Cc: [email protected]; Derrick, David; Woodruff, Richard
Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Hi Rajendra,
Quoted 8 lines · Rajendra Nayak
If autoidle for DPLL4 is enabled in the stored scratchpad value of CM_AUTOIDLE_PLL then there is an added delay by the boot ROM when coming out of OFF mode.
The patch disables this bitfield in the stored scratchpad value.
This should significantly reduce CORE OFF latency and also bring down the threshold for CORE OFF, making OFF affordable even with smaller sleep times.
I did some measurements on RX-51 with this patch, and it seems it does not reduce latency, it increases it by few hundred us.
Servicing an empty timer interrupt from off mode (measured from VDD1 ramp up to start of VDD1 ramp down):

Quoted 8 lines

with dpll4 patch : ~14100us
without patch : ~13600us
I attached pictures of both situations.
My kernel had only C7 state enabled.
Have you measured the latency effects on SDP or some other board?

I haven't done the latency measurements on SDP yet, but David had done it sometime back, using a different codebase though.

Can you explain more on how you are measuring the latency here, I am a bit confused. This is supposed to bring down the OFF wakeup latency, the sleep latency remains the same.

Quoted 36 lines

- Kalle
Review
Quoted 9 lines
This patch however does not optimize the C state threshold for CORE OFF states based on the new latency.
Signed-off-by Rajendra Nayak <[email protected]>
---
 arch/arm/mach-omap2/control.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)
(quoted diff) +0 -0
b/arch/arm/mach-omap2/control.c
arch/arm/mach-omap2/control.c void omap3_save_scratchpad_contents(void) · line 240
Quoted 7 lines
index c9407c0..a7159a9 100644
arch/arm/mach-omap2/control.c +0 -0
@@ -238,6 +238,13 @@ void omap3_save_scratchpad_contents(void)
 			cm_read_mod_reg(PLL_MOD, CM_CLKEN);
 	prcm_block_contents.cm_autoidle_pll =
 			cm_read_mod_reg(PLL_MOD, 
OMAP3430_CM_AUTOIDLE_PLL);
arch/arm/mach-omap2/control.c void omap3_save_scratchpad_contents(void) · line 242
Quoted 2 lines
arch/arm/mach-omap2/control.c +2 -0
+	/*
+	 * ROM restore takes 20mS longer if PER idle is enabled 
before OFF.
arch/arm/mach-omap2/control.c void omap3_save_scratchpad_contents(void) · line 246
Quoted 4 lines
arch/arm/mach-omap2/control.c +4 -0
+	 * Clear feature before sleep. The origional idle state is
+	 * restored by software as part of wake procedure.
+	 */
+	prcm_block_contents.cm_autoidle_pll &= 
~OMAP3430_AUTO_PERIPH_DPLL_MASK;
arch/arm/mach-omap2/control.c void omap3_save_scratchpad_contents(void) · line 249
Quoted 3 lines
arch/arm/mach-omap2/control.c +1 -0
+
 	prcm_block_contents.cm_clksel1_pll =
 			cm_read_mod_reg(PLL_MOD, 
OMAP3430_CM_CLKSEL1_PLL);
Quoted 1 line
arch/arm/mach-omap2/control.c +0 -0
 	prcm_block_contents.cm_clksel2_pll =

Kalle Jokiniemi

2009-06-17 10:26 UTC #2 lore raw

Quoted 29 lines · Rajendra

Quoted 29 lines
-----Original Message-----
From: Kalle Jokiniemi [mailto:[email protected]]
Sent: Wednesday, June 17, 2009 1:17 PM
To: Nayak, Rajendra
Cc: [email protected]; Derrick, David; Woodruff, Richard
Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Hi Rajendra,
Quoted 8 lines · Rajendra Nayak
If autoidle for DPLL4 is enabled in the stored scratchpad value of CM_AUTOIDLE_PLL then there is an added delay by the boot ROM when coming out of OFF mode.
The patch disables this bitfield in the stored scratchpad value.
This should significantly reduce CORE OFF latency and also bring down the threshold for CORE OFF, making OFF affordable even with smaller sleep times.
I did some measurements on RX-51 with this patch, and it seems it does not reduce latency, it increases it by few hundred us.
Servicing an empty timer interrupt from off mode (measured from VDD1 ramp up to start of VDD1 ramp down):
with dpll4 patch : ~14100us
without patch : ~13600us

Quoted 8 lines

Quoted 5 lines
I attached pictures of both situations.
My kernel had only C7 state enabled.
Have you measured the latency effects on SDP or some other board?
I haven't done the latency measurements on SDP yet, but David had done it sometime back, using a different codebase though.

OK, I also used our internal code base. Though the PM functionality is pretty much the same as in l-o:pm branch.

Quoted 4 lines

Can you explain more on how you are measuring the latency here, I am a bit confused. This is supposed to bring down the OFF wakeup latency, the sleep latency remains the same.

I'm doing a timer interrupt periodically. Servicing that timer interrupt takes the same amount of time every time. What varies (with the patch) is the transition times from off to active and back to off.

In the pictures the top graph shows current and bottom graph shows the VDD1 and VDD2 voltages. I zoomed from the pictures the interval from when VDD1 goes up, to the point when it starts to go down again.

So I measured: wakeup latency + interrupt service + sleep latency.

- Kalle

Quoted 37 lines

Quoted 37 lines
- Kalle
Review
Quoted 9 lines
This patch however does not optimize the C state threshold for CORE OFF states based on the new latency.
Signed-off-by Rajendra Nayak <[email protected]>
---
 arch/arm/mach-omap2/control.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)
(quoted diff) +0 -0
b/arch/arm/mach-omap2/control.c
arch/arm/mach-omap2/control.c void omap3_save_scratchpad_contents(void) · line 240
Quoted 7 lines
index c9407c0..a7159a9 100644
arch/arm/mach-omap2/control.c +0 -0
@@ -238,6 +238,13 @@ void omap3_save_scratchpad_contents(void)
 			cm_read_mod_reg(PLL_MOD, CM_CLKEN);
 	prcm_block_contents.cm_autoidle_pll =
 			cm_read_mod_reg(PLL_MOD, 
OMAP3430_CM_AUTOIDLE_PLL);
arch/arm/mach-omap2/control.c void omap3_save_scratchpad_contents(void) · line 242
Quoted 2 lines
arch/arm/mach-omap2/control.c +2 -0
+	/*
+	 * ROM restore takes 20mS longer if PER idle is enabled 
before OFF.
arch/arm/mach-omap2/control.c void omap3_save_scratchpad_contents(void) · line 246
Quoted 4 lines
arch/arm/mach-omap2/control.c +4 -0
+	 * Clear feature before sleep. The origional idle state is
+	 * restored by software as part of wake procedure.
+	 */
+	prcm_block_contents.cm_autoidle_pll &= 
~OMAP3430_AUTO_PERIPH_DPLL_MASK;
arch/arm/mach-omap2/control.c void omap3_save_scratchpad_contents(void) · line 249
Quoted 3 lines
arch/arm/mach-omap2/control.c +1 -0
+
 	prcm_block_contents.cm_clksel1_pll =
 			cm_read_mod_reg(PLL_MOD, 
OMAP3430_CM_CLKSEL1_PLL);
Quoted 1 line
arch/arm/mach-omap2/control.c +0 -0
 	prcm_block_contents.cm_clksel2_pll =

Nayak, Rajendra

author

2009-06-17 12:38 UTC #3 lore raw

Quoted 66 lines

-----Original Message-----
From: Kalle Jokiniemi [mailto:[email protected]]
Sent: Wednesday, June 17, 2009 3:56 PM
To: Nayak, Rajendra
Cc: [email protected]; Derrick, David; Woodruff, Richard
Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Quoted 16 lines · Rajendra
Quoted 16 lines
-----Original Message-----
From: Kalle Jokiniemi [mailto:[email protected]]
Sent: Wednesday, June 17, 2009 1:17 PM
To: Nayak, Rajendra
Cc: [email protected]; Derrick, David; Woodruff, Richard
Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Hi Rajendra,
Quoted 5 lines · Rajendra Nayak
If autoidle for DPLL4 is enabled in the stored scratchpad value of CM_AUTOIDLE_PLL then there is an added delay by the boot ROM when coming out of OFF mode.
The patch disables this bitfield in the stored scratchpad value.
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
This should significantly reduce CORE OFF latency and also bring down the threshold for CORE OFF, making OFF affordable even with smaller sleep times.
I did some measurements on RX-51 with this patch, and it
seems it does
Quoted 8 lines
Quoted 8 lines
not reduce latency, it increases it by few hundred us.
Servicing an empty timer interrupt from off mode (measured from VDD1 ramp up to start of VDD1 ramp down):
with dpll4 patch : ~14100us
without patch : ~13600us
Quoted 7 lines
Quoted 5 lines
I attached pictures of both situations.
My kernel had only C7 state enabled.
Have you measured the latency effects on SDP or some other board?
I haven't done the latency measurements on SDP yet, but
David had done it
Quoted 1 line
sometime back, using a different codebase though.
OK, I also used our internal code base. Though the PM functionality is pretty much the same as in l-o:pm branch.
Quoted 2 lines
Can you explain more on how you are measuring the latency
here, I am a bit
Quoted 1 line
confused. This is supposed to bring down the OFF wakeup
latency, the sleep latency
Quoted 1 line
remains the same.
I'm doing a timer interrupt periodically. Servicing that timer interrupt
takes the same amount of time every time. What varies (with the patch) is the transition times from off to active and back to off.

Quoted 5 lines

In the pictures the top graph shows current and bottom graph shows the VDD1 and VDD2 voltages. I zoomed from the pictures the interval from when VDD1 goes up, to the point when it starts to go down again.
So I measured: wakeup latency + interrupt service + sleep latency.

Is the boot ROM different on the OMAP devices on nokia h/w or is it the same as that on the SDP?

Quoted 43 lines

- Kalle
Quoted 37 lines
Quoted 37 lines
- Kalle
Review
Quoted 9 lines
This patch however does not optimize the C state threshold for CORE OFF states based on the new latency.
Signed-off-by Rajendra Nayak <[email protected]>
---
 arch/arm/mach-omap2/control.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)
(quoted diff) +0 -0
b/arch/arm/mach-omap2/control.c
arch/arm/mach-omap2/control.c void omap3_save_scratchpad_contents(void) · line 240
Quoted 7 lines
index c9407c0..a7159a9 100644
arch/arm/mach-omap2/control.c +0 -0
@@ -238,6 +238,13 @@ void omap3_save_scratchpad_contents(void)
 			cm_read_mod_reg(PLL_MOD, CM_CLKEN);
 	prcm_block_contents.cm_autoidle_pll =
 			cm_read_mod_reg(PLL_MOD, 
OMAP3430_CM_AUTOIDLE_PLL);
arch/arm/mach-omap2/control.c void omap3_save_scratchpad_contents(void) · line 242
Quoted 2 lines
arch/arm/mach-omap2/control.c +2 -0
+	/*
+	 * ROM restore takes 20mS longer if PER idle is enabled 
before OFF.
arch/arm/mach-omap2/control.c void omap3_save_scratchpad_contents(void) · line 246
Quoted 4 lines
arch/arm/mach-omap2/control.c +4 -0
+	 * Clear feature before sleep. The origional idle state is
+	 * restored by software as part of wake procedure.
+	 */
+	prcm_block_contents.cm_autoidle_pll &= 
~OMAP3430_AUTO_PERIPH_DPLL_MASK;
arch/arm/mach-omap2/control.c void omap3_save_scratchpad_contents(void) · line 249
Quoted 3 lines
arch/arm/mach-omap2/control.c +1 -0
+
 	prcm_block_contents.cm_clksel1_pll =
 			cm_read_mod_reg(PLL_MOD, 
OMAP3430_CM_CLKSEL1_PLL);
Quoted 1 line
arch/arm/mach-omap2/control.c +0 -0
 	prcm_block_contents.cm_clksel2_pll =

Kalle Jokiniemi

2009-06-17 12:47 UTC #4 lore raw

Quoted 65 lines · Rajendra

Quoted 65 lines
-----Original Message-----
From: Kalle Jokiniemi [mailto:[email protected]]
Sent: Wednesday, June 17, 2009 3:56 PM
To: Nayak, Rajendra
Cc: [email protected]; Derrick, David; Woodruff, Richard
Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Quoted 16 lines · Rajendra
Quoted 16 lines
-----Original Message-----
From: Kalle Jokiniemi [mailto:[email protected]]
Sent: Wednesday, June 17, 2009 1:17 PM
To: Nayak, Rajendra
Cc: [email protected]; Derrick, David; Woodruff, Richard
Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Hi Rajendra,
Quoted 5 lines · Rajendra Nayak
If autoidle for DPLL4 is enabled in the stored scratchpad value of CM_AUTOIDLE_PLL then there is an added delay by the boot ROM when coming out of OFF mode.
The patch disables this bitfield in the stored scratchpad value.
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
This should significantly reduce CORE OFF latency and also bring down the threshold for CORE OFF, making OFF affordable even with smaller sleep times.
I did some measurements on RX-51 with this patch, and it
seems it does
Quoted 8 lines
Quoted 8 lines
not reduce latency, it increases it by few hundred us.
Servicing an empty timer interrupt from off mode (measured from VDD1 ramp up to start of VDD1 ramp down):
with dpll4 patch : ~14100us
without patch : ~13600us
Quoted 7 lines
Quoted 5 lines
I attached pictures of both situations.
My kernel had only C7 state enabled.
Have you measured the latency effects on SDP or some other board?
I haven't done the latency measurements on SDP yet, but
David had done it
Quoted 1 line
sometime back, using a different codebase though.
OK, I also used our internal code base. Though the PM functionality is pretty much the same as in l-o:pm branch.
Quoted 2 lines
Can you explain more on how you are measuring the latency
here, I am a bit
Quoted 1 line
confused. This is supposed to bring down the OFF wakeup
latency, the sleep latency
Quoted 1 line
remains the same.
I'm doing a timer interrupt periodically. Servicing that timer interrupt
takes the same amount of time every time. What varies (with the patch) is the transition times from off to active and back to off.

Quoted 8 lines

Quoted 5 lines
In the pictures the top graph shows current and bottom graph shows the VDD1 and VDD2 voltages. I zoomed from the pictures the interval from when VDD1 goes up, to the point when it starts to go down again.
So I measured: wakeup latency + interrupt service + sleep latency.
Is the boot ROM different on the OMAP devices on nokia h/w or is it the same as that on the SDP?

I have heard that our ROM version would be somehow older version, but I really don't have any facts on that matter.

- Kalle

Quoted 44 lines

Quoted 44 lines
- Kalle
Quoted 37 lines
Quoted 37 lines
- Kalle
Review
Quoted 9 lines
This patch however does not optimize the C state threshold for CORE OFF states based on the new latency.
Signed-off-by Rajendra Nayak <[email protected]>
---
 arch/arm/mach-omap2/control.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)
(quoted diff) +0 -0
b/arch/arm/mach-omap2/control.c
arch/arm/mach-omap2/control.c void omap3_save_scratchpad_contents(void) · line 240
Quoted 7 lines
index c9407c0..a7159a9 100644
arch/arm/mach-omap2/control.c +0 -0
@@ -238,6 +238,13 @@ void omap3_save_scratchpad_contents(void)
 			cm_read_mod_reg(PLL_MOD, CM_CLKEN);
 	prcm_block_contents.cm_autoidle_pll =
 			cm_read_mod_reg(PLL_MOD, 
OMAP3430_CM_AUTOIDLE_PLL);
arch/arm/mach-omap2/control.c void omap3_save_scratchpad_contents(void) · line 242
Quoted 2 lines
arch/arm/mach-omap2/control.c +2 -0
+	/*
+	 * ROM restore takes 20mS longer if PER idle is enabled 
before OFF.
arch/arm/mach-omap2/control.c void omap3_save_scratchpad_contents(void) · line 246
Quoted 4 lines
arch/arm/mach-omap2/control.c +4 -0
+	 * Clear feature before sleep. The origional idle state is
+	 * restored by software as part of wake procedure.
+	 */
+	prcm_block_contents.cm_autoidle_pll &= 
~OMAP3430_AUTO_PERIPH_DPLL_MASK;
arch/arm/mach-omap2/control.c void omap3_save_scratchpad_contents(void) · line 249
Quoted 3 lines
arch/arm/mach-omap2/control.c +1 -0
+
 	prcm_block_contents.cm_clksel1_pll =
 			cm_read_mod_reg(PLL_MOD, 
OMAP3430_CM_CLKSEL1_PLL);
Quoted 1 line
arch/arm/mach-omap2/control.c +0 -0
 	prcm_block_contents.cm_clksel2_pll =

Nayak, Rajendra

author

2009-06-17 13:02 UTC #5 lore raw

Quoted 85 lines

-----Original Message-----
From: Kalle Jokiniemi [mailto:[email protected]]
Sent: Wednesday, June 17, 2009 6:18 PM
To: Nayak, Rajendra
Cc: [email protected]; Derrick, David; Woodruff, Richard
Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Quoted 18 lines · Rajendra
Quoted 18 lines
-----Original Message-----
From: Kalle Jokiniemi [mailto:[email protected]]
Sent: Wednesday, June 17, 2009 3:56 PM
To: Nayak, Rajendra
Cc: [email protected]; Derrick, David; Woodruff, Richard
Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Quoted 8 lines · Rajendra
Quoted 8 lines
-----Original Message-----
From: Kalle Jokiniemi [mailto:[email protected]]
Sent: Wednesday, June 17, 2009 1:17 PM
To: Nayak, Rajendra
Cc: [email protected]; Derrick, David; Woodruff, Richard
Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Hi Rajendra,
Quoted 4 lines · Rajendra Nayak
If autoidle for DPLL4 is enabled in the stored scratchpad value of CM_AUTOIDLE_PLL then there is an added delay by the boot ROM when coming out of OFF mode.
The patch disables this bitfield in the stored
scratchpad value.
Quoted 10 lines
Quoted 10 lines
Quoted 6 lines
Quoted 6 lines
Quoted 4 lines
This should significantly reduce CORE OFF latency and also bring down the threshold for CORE OFF, making OFF affordable even with smaller sleep times.
I did some measurements on RX-51 with this patch, and it
seems it does
Quoted 3 lines
Quoted 3 lines
not reduce latency, it increases it by few hundred us.
Servicing an empty timer interrupt from off mode
(measured from VDD1
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
ramp up to start of VDD1 ramp down):
with dpll4 patch : ~14100us
without patch : ~13600us
I attached pictures of both situations.
My kernel had only C7 state enabled.
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
Have you measured the latency effects on SDP or some other board?
I haven't done the latency measurements on SDP yet, but
David had done it
Quoted 1 line
sometime back, using a different codebase though.
OK, I also used our internal code base. Though the PM
functionality is
Quoted 4 lines
Quoted 4 lines
pretty much the same as in l-o:pm branch.
Quoted 2 lines
Can you explain more on how you are measuring the latency
Quoted 8 lines
Quoted 8 lines
here, I am a bit
Quoted 1 line
confused. This is supposed to bring down the OFF wakeup
latency, the sleep latency
Quoted 1 line
remains the same.
I'm doing a timer interrupt periodically. Servicing that timer interrupt
takes the same amount of time every time. What varies (with
the patch)
Quoted 3 lines
Quoted 3 lines
is the transition times from off to active and back to off.
In the pictures the top graph shows current and bottom
graph shows the
Quoted 3 lines
Quoted 3 lines
VDD1 and VDD2 voltages. I zoomed from the pictures the interval from when VDD1 goes up, to the point when it starts to go down again.

Quoted 7 lines

Quoted 4 lines
Quoted 1 line
So I measured: wakeup latency + interrupt service + sleep latency.
Is the boot ROM different on the OMAP devices on nokia h/w or is it the same as that on the SDP?
I have heard that our ROM version would be somehow older version, but I really don't have any facts on that matter.

Oh.. it turns out that when the scratchpad save routine is called, the autoidle for PER is not even set. Its only set some place later.
So the 20ms or so advantage was always there on l-o pm branch even without this patch :)

Quoted 51 lines

- Kalle
Quoted 27 lines
Quoted 27 lines
- Kalle
Quoted 23 lines
Quoted 23 lines
- Kalle
Review
Quoted 9 lines
This patch however does not optimize the C state threshold for CORE OFF states based on the new latency.
Signed-off-by Rajendra Nayak <[email protected]>
---
 arch/arm/mach-omap2/control.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)
(quoted diff) +0 -0
b/arch/arm/mach-omap2/control.c
arch/arm/mach-omap2/control.c void omap3_save_scratchpad_contents(void) · line 240
Quoted 7 lines
index c9407c0..a7159a9 100644
arch/arm/mach-omap2/control.c +0 -0
@@ -238,6 +238,13 @@ void omap3_save_scratchpad_contents(void)
 			cm_read_mod_reg(PLL_MOD, CM_CLKEN);
 	prcm_block_contents.cm_autoidle_pll =
 			cm_read_mod_reg(PLL_MOD, 
OMAP3430_CM_AUTOIDLE_PLL);
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
arch/arm/mach-omap2/control.c void omap3_save_scratchpad_contents(void) · line 242
Quoted 2 lines
arch/arm/mach-omap2/control.c +2 -0
+	/*
+	 * ROM restore takes 20mS longer if PER idle is enabled 
before OFF.
arch/arm/mach-omap2/control.c void omap3_save_scratchpad_contents(void) · line 243
Quoted 1 line
arch/arm/mach-omap2/control.c +1 -0
+	 * Clear feature before sleep. The origional 
idle state is
Quoted 13 lines
Quoted 13 lines
Quoted 10 lines
Quoted 10 lines
arch/arm/mach-omap2/control.c void omap3_save_scratchpad_contents(void) · line 246
Quoted 3 lines
arch/arm/mach-omap2/control.c +3 -0
+	 * restored by software as part of wake procedure.
+	 */
+	prcm_block_contents.cm_autoidle_pll &= 
~OMAP3430_AUTO_PERIPH_DPLL_MASK;
arch/arm/mach-omap2/control.c void omap3_save_scratchpad_contents(void) · line 249
Quoted 3 lines
arch/arm/mach-omap2/control.c +1 -0
+
 	prcm_block_contents.cm_clksel1_pll =
 			cm_read_mod_reg(PLL_MOD, 
OMAP3430_CM_CLKSEL1_PLL);
Quoted 1 line
arch/arm/mach-omap2/control.c +0 -0
 	prcm_block_contents.cm_clksel2_pll =

Kevin Hilman

2009-06-29 18:58 UTC #6 lore raw

Quoted 90 lines · Rajendra

Quoted 90 lines
-----Original Message-----
From: Kalle Jokiniemi [mailto:[email protected]]
Sent: Wednesday, June 17, 2009 6:18 PM
To: Nayak, Rajendra
Cc: [email protected]; Derrick, David; Woodruff, Richard
Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Quoted 18 lines · Rajendra
Quoted 18 lines
-----Original Message-----
From: Kalle Jokiniemi [mailto:[email protected]]
Sent: Wednesday, June 17, 2009 3:56 PM
To: Nayak, Rajendra
Cc: [email protected]; Derrick, David; Woodruff, Richard
Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Quoted 8 lines · Rajendra
Quoted 8 lines
-----Original Message-----
From: Kalle Jokiniemi [mailto:[email protected]]
Sent: Wednesday, June 17, 2009 1:17 PM
To: Nayak, Rajendra
Cc: [email protected]; Derrick, David; Woodruff, Richard
Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Hi Rajendra,
Quoted 4 lines · Rajendra Nayak
If autoidle for DPLL4 is enabled in the stored scratchpad value of CM_AUTOIDLE_PLL then there is an added delay by the boot ROM when coming out of OFF mode.
The patch disables this bitfield in the stored
scratchpad value.
Quoted 10 lines
Quoted 10 lines
Quoted 6 lines
Quoted 6 lines
Quoted 4 lines
This should significantly reduce CORE OFF latency and also bring down the threshold for CORE OFF, making OFF affordable even with smaller sleep times.
I did some measurements on RX-51 with this patch, and it
seems it does
Quoted 3 lines
Quoted 3 lines
not reduce latency, it increases it by few hundred us.
Servicing an empty timer interrupt from off mode
(measured from VDD1
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
ramp up to start of VDD1 ramp down):
with dpll4 patch : ~14100us
without patch : ~13600us
I attached pictures of both situations.
My kernel had only C7 state enabled.
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
Have you measured the latency effects on SDP or some other board?
I haven't done the latency measurements on SDP yet, but
David had done it
Quoted 1 line
sometime back, using a different codebase though.
OK, I also used our internal code base. Though the PM
functionality is
Quoted 4 lines
Quoted 4 lines
pretty much the same as in l-o:pm branch.
Quoted 2 lines
Can you explain more on how you are measuring the latency
Quoted 8 lines
Quoted 8 lines
here, I am a bit
Quoted 1 line
confused. This is supposed to bring down the OFF wakeup
latency, the sleep latency
Quoted 1 line
remains the same.
I'm doing a timer interrupt periodically. Servicing that timer interrupt
takes the same amount of time every time. What varies (with
the patch)
Quoted 3 lines
Quoted 3 lines
is the transition times from off to active and back to off.
In the pictures the top graph shows current and bottom
graph shows the
Quoted 7 lines
Quoted 4 lines
VDD1 and VDD2 voltages. I zoomed from the pictures the interval from when VDD1 goes up, to the point when it starts to go down again.
So I measured: wakeup latency + interrupt service + sleep latency.
Is the boot ROM different on the OMAP devices on nokia h/w or is it the same as that on the SDP?

Quoted 8 lines

Quoted 2 lines
I have heard that our ROM version would be somehow older version, but I really don't have any facts on that matter.
Oh.. it turns out that when the scratchpad save routine is called, the autoidle for PER is not even set. Its only set some place later.
So the 20ms or so advantage was always there on l-o pm branch even without this patch :)

So for the benefit of the archives...

I'm dropping this patch since the equivalent is alrady in PM branch.

Kevin

Nayak, Rajendra

author

2009-06-30 05:58 UTC #7 lore raw

Quoted 112 lines

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Tuesday, June 30, 2009 12:28 AM
To: Nayak, Rajendra
Cc: Kalle Jokiniemi; [email protected]; Derrick, David; Woodruff, Richard
Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Quoted 20 lines · Rajendra
Quoted 20 lines
-----Original Message-----
From: Kalle Jokiniemi [mailto:[email protected]]
Sent: Wednesday, June 17, 2009 6:18 PM
To: Nayak, Rajendra
Cc: [email protected]; Derrick, David; Woodruff, Richard
Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Quoted 9 lines · Rajendra
Quoted 9 lines
-----Original Message-----
From: Kalle Jokiniemi [mailto:[email protected]]
Sent: Wednesday, June 17, 2009 3:56 PM
To: Nayak, Rajendra
Cc: [email protected]; Derrick, David; Woodruff, Richard
Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines · Rajendra
Quoted 5 lines
Quoted 5 lines
-----Original Message-----
From: Kalle Jokiniemi [mailto:[email protected]]
Sent: Wednesday, June 17, 2009 1:17 PM
To: Nayak, Rajendra
Cc: [email protected]; Derrick, David;
Woodruff, Richard
Quoted 24 lines
Quoted 24 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Hi Rajendra,
Quoted 4 lines · Rajendra Nayak
If autoidle for DPLL4 is enabled in the stored scratchpad value of CM_AUTOIDLE_PLL then there is an added delay by the boot ROM when coming out of OFF mode.
The patch disables this bitfield in the stored
scratchpad value.
Quoted 10 lines
Quoted 10 lines
Quoted 6 lines
Quoted 6 lines
Quoted 4 lines
This should significantly reduce CORE OFF latency and also bring down the threshold for CORE OFF, making OFF affordable even with smaller sleep times.
I did some measurements on RX-51 with this patch, and it
seems it does
Quoted 3 lines
Quoted 3 lines
not reduce latency, it increases it by few hundred us.
Servicing an empty timer interrupt from off mode
(measured from VDD1
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
ramp up to start of VDD1 ramp down):
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
with dpll4 patch : ~14100us
without patch : ~13600us
I attached pictures of both situations.
My kernel had only C7 state enabled.
Have you measured the latency effects on SDP or some
other board?
Quoted 19 lines
Quoted 19 lines
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
I haven't done the latency measurements on SDP yet, but
David had done it
Quoted 1 line
sometime back, using a different codebase though.
OK, I also used our internal code base. Though the PM
functionality is
Quoted 12 lines
Quoted 12 lines
pretty much the same as in l-o:pm branch.
Quoted 2 lines
Can you explain more on how you are measuring the latency
here, I am a bit
Quoted 1 line
confused. This is supposed to bring down the OFF wakeup
latency, the sleep latency
Quoted 1 line
remains the same.
I'm doing a timer interrupt periodically. Servicing that timer interrupt
takes the same amount of time every time. What varies (with
Quoted 6 lines
Quoted 6 lines
the patch)
Quoted 3 lines
Quoted 3 lines
is the transition times from off to active and back to off.
In the pictures the top graph shows current and bottom
graph shows the
Quoted 1 line
Quoted 1 line
VDD1 and VDD2 voltages. I zoomed from the pictures the
interval from
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
when VDD1 goes up, to the point when it starts to go down again.
So I measured: wakeup latency + interrupt service + sleep latency.
Is the boot ROM different on the OMAP devices on nokia h/w or is it the same as that on the SDP?
I have heard that our ROM version would be somehow older
version, but I
Quoted 3 lines
Quoted 1 line
really don't have any facts on that matter.
Oh.. it turns out that when the scratchpad save routine is
called, the autoidle
Quoted 2 lines
for PER is not even set. Its only set some place later. So the 20ms or so advantage was always there on l-o pm

Quoted 7 lines

branch even without this
Quoted 2 lines
patch :)
So for the benefit of the archives...
I'm dropping this patch since the equivalent is alrady in PM branch.

Kevin,

Today the sequence is such that the PER dpll autoidle is set only after the first scratchpad save (so this patch has no affect). Sometime in future, if with some change in function sequencing we end up enabling the PER dpll autoidle early on, we might have an additional 20ms or so OFF latency without anyone really noticing. Would'nt it be good to just have this patch to take care of any sequencing changes later?

regards,
Rajendra

Quoted 4 lines

Kevin

Kevin Hilman

2009-06-30 22:24 UTC #8 lore raw

"Nayak, Rajendra" <[email protected]> writes:

[...]

Quoted 11 lines

Quoted 10 lines
Quoted 6 lines
Oh.. it turns out that when the scratchpad save routine is called, the autoidle for PER is not even set. Its only set some place later. So the 20ms or so advantage was always there on l-o pm branch even without this patch :)
So for the benefit of the archives...
I'm dropping this patch since the equivalent is alrady in PM branch.

Quoted 7 lines

Today the sequence is such that the PER dpll autoidle is set only after the first scratchpad save (so this patch has no affect). Sometime in future, if with some change in function sequencing we end up enabling the PER dpll autoidle early on, we might have an additional 20ms or so OFF latency without anyone really noticing. Would'nt it be good to just have this patch to take care of any sequencing changes later?

Yes, I think you're right. This change could indeed prevent some future problmes down the road. I'll merge it.

Thanks,

Kevin

Paul Walmsley

2009-06-30 22:32 UTC #9 lore raw

In reply to Nayak, Rajendra

Quoted 120 lines · Rajendra

Quoted 112 lines
-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Tuesday, June 30, 2009 12:28 AM
To: Nayak, Rajendra
Cc: Kalle Jokiniemi; [email protected]; Derrick, David; Woodruff, Richard
Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Quoted 20 lines · Rajendra
Quoted 20 lines
-----Original Message-----
From: Kalle Jokiniemi [mailto:[email protected]]
Sent: Wednesday, June 17, 2009 6:18 PM
To: Nayak, Rajendra
Cc: [email protected]; Derrick, David; Woodruff, Richard
Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Quoted 9 lines · Rajendra
Quoted 9 lines
-----Original Message-----
From: Kalle Jokiniemi [mailto:[email protected]]
Sent: Wednesday, June 17, 2009 3:56 PM
To: Nayak, Rajendra
Cc: [email protected]; Derrick, David; Woodruff, Richard
Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines · Rajendra
Quoted 5 lines
Quoted 5 lines
-----Original Message-----
From: Kalle Jokiniemi [mailto:[email protected]]
Sent: Wednesday, June 17, 2009 1:17 PM
To: Nayak, Rajendra
Cc: [email protected]; Derrick, David;
Woodruff, Richard
Quoted 24 lines
Quoted 24 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Hi Rajendra,
Quoted 4 lines · Rajendra Nayak
If autoidle for DPLL4 is enabled in the stored scratchpad value of CM_AUTOIDLE_PLL then there is an added delay by the boot ROM when coming out of OFF mode.
The patch disables this bitfield in the stored
scratchpad value.
Quoted 10 lines
Quoted 10 lines
Quoted 6 lines
Quoted 6 lines
Quoted 4 lines
This should significantly reduce CORE OFF latency and also bring down the threshold for CORE OFF, making OFF affordable even with smaller sleep times.
I did some measurements on RX-51 with this patch, and it
seems it does
Quoted 3 lines
Quoted 3 lines
not reduce latency, it increases it by few hundred us.
Servicing an empty timer interrupt from off mode
(measured from VDD1
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
ramp up to start of VDD1 ramp down):
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
with dpll4 patch : ~14100us
without patch : ~13600us
I attached pictures of both situations.
My kernel had only C7 state enabled.
Have you measured the latency effects on SDP or some
other board?
Quoted 19 lines
Quoted 19 lines
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
I haven't done the latency measurements on SDP yet, but
David had done it
Quoted 1 line
sometime back, using a different codebase though.
OK, I also used our internal code base. Though the PM
functionality is
Quoted 12 lines
Quoted 12 lines
pretty much the same as in l-o:pm branch.
Quoted 2 lines
Can you explain more on how you are measuring the latency
here, I am a bit
Quoted 1 line
confused. This is supposed to bring down the OFF wakeup
latency, the sleep latency
Quoted 1 line
remains the same.
I'm doing a timer interrupt periodically. Servicing that timer interrupt
takes the same amount of time every time. What varies (with
Quoted 6 lines
Quoted 6 lines
the patch)
Quoted 3 lines
Quoted 3 lines
is the transition times from off to active and back to off.
In the pictures the top graph shows current and bottom
graph shows the
Quoted 1 line
Quoted 1 line
VDD1 and VDD2 voltages. I zoomed from the pictures the
interval from
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
when VDD1 goes up, to the point when it starts to go down again.
So I measured: wakeup latency + interrupt service + sleep latency.
Is the boot ROM different on the OMAP devices on nokia h/w or is it the same as that on the SDP?
I have heard that our ROM version would be somehow older
version, but I
Quoted 3 lines
Quoted 1 line
really don't have any facts on that matter.
Oh.. it turns out that when the scratchpad save routine is
called, the autoidle
Quoted 2 lines
for PER is not even set. Its only set some place later. So the 20ms or so advantage was always there on l-o pm
Quoted 7 lines
branch even without this
Quoted 2 lines
patch :)
So for the benefit of the archives...
I'm dropping this patch since the equivalent is alrady in PM branch.

Quoted 7 lines

Kevin,
Today the sequence is such that the PER dpll autoidle is set only after the first scratchpad save (so this patch has no affect). Sometime in future, if with some change in function sequencing we end up enabling the PER dpll autoidle early on, we might have an additional 20ms or so OFF latency without anyone really noticing. Would'nt it be good to just have this patch to take care of any sequencing changes later?

I don't think we should merge this until David can tell us more about the instability that is caused by this patch.

- Paul

Nayak, Rajendra

author

2009-07-01 05:39 UTC #10 lore raw

Quoted 145 lines

-----Original Message-----
From: Paul Walmsley [mailto:[email protected]]
Sent: Wednesday, July 01, 2009 4:02 AM
To: Nayak, Rajendra
Cc: Kevin Hilman; Kalle Jokiniemi; [email protected]; Derrick, David; Woodruff, Richard
Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Quoted 21 lines · Rajendra
Quoted 21 lines
-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Tuesday, June 30, 2009 12:28 AM
To: Nayak, Rajendra
Cc: Kalle Jokiniemi; [email protected]; Derrick, David; Woodruff, Richard
Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Quoted 10 lines · Rajendra
Quoted 10 lines
-----Original Message-----
From: Kalle Jokiniemi [mailto:[email protected]]
Sent: Wednesday, June 17, 2009 6:18 PM
To: Nayak, Rajendra
Cc: [email protected]; Derrick, David; Woodruff, Richard
Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines · Rajendra
Quoted 6 lines
Quoted 6 lines
-----Original Message-----
From: Kalle Jokiniemi [mailto:[email protected]]
Sent: Wednesday, June 17, 2009 3:56 PM
To: Nayak, Rajendra
Cc: [email protected]; Derrick, David;
Woodruff, Richard
Quoted 16 lines
Quoted 16 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Quoted 5 lines · Rajendra
Quoted 5 lines
-----Original Message-----
From: Kalle Jokiniemi [mailto:[email protected]]
Sent: Wednesday, June 17, 2009 1:17 PM
To: Nayak, Rajendra
Cc: [email protected]; Derrick, David;
Woodruff, Richard
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Hi Rajendra,
On Tue, 2009-06-16 at 14:52 +0300, Rajendra Nayak wrote:
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
If autoidle for DPLL4 is enabled in the stored scratchpad value of CM_AUTOIDLE_PLL then there is an added delay by the boot ROM when coming out of OFF mode.
The patch disables this bitfield in the stored
scratchpad value.
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
This should significantly reduce CORE OFF latency and also bring down the threshold for CORE OFF, making OFF
affordable
Quoted 38 lines
Quoted 38 lines
Quoted 10 lines
Quoted 10 lines
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
even with smaller sleep times.
I did some measurements on RX-51 with this patch, and it
seems it does
Quoted 3 lines
Quoted 3 lines
not reduce latency, it increases it by few hundred us.
Servicing an empty timer interrupt from off mode
(measured from VDD1
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
ramp up to start of VDD1 ramp down):
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
with dpll4 patch : ~14100us
without patch : ~13600us
I attached pictures of both situations.
My kernel had only C7 state enabled.
Have you measured the latency effects on SDP or some
other board?
Quoted 19 lines
Quoted 19 lines
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
I haven't done the latency measurements on SDP yet, but
David had done it
Quoted 1 line
sometime back, using a different codebase though.
OK, I also used our internal code base. Though the PM
functionality is
Quoted 12 lines
Quoted 12 lines
pretty much the same as in l-o:pm branch.
Quoted 2 lines
Can you explain more on how you are measuring the latency
here, I am a bit
Quoted 1 line
confused. This is supposed to bring down the OFF wakeup
latency, the sleep latency
Quoted 1 line
remains the same.
I'm doing a timer interrupt periodically. Servicing that timer interrupt
takes the same amount of time every time. What varies (with
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Quoted 6 lines
the patch)
Quoted 3 lines
Quoted 3 lines
is the transition times from off to active and back to off.
In the pictures the top graph shows current and bottom
graph shows the
Quoted 1 line
Quoted 1 line
VDD1 and VDD2 voltages. I zoomed from the pictures the
interval from
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
when VDD1 goes up, to the point when it starts to go
down again.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
So I measured: wakeup latency + interrupt service +
sleep latency.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Is the boot ROM different on the OMAP devices on nokia
h/w or is it
Quoted 14 lines
Quoted 14 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
the same as that on the SDP?
I have heard that our ROM version would be somehow older
version, but I
Quoted 3 lines
Quoted 1 line
really don't have any facts on that matter.
Oh.. it turns out that when the scratchpad save routine is
called, the autoidle
Quoted 2 lines
for PER is not even set. Its only set some place later. So the 20ms or so advantage was always there on l-o pm
branch even without this
Quoted 2 lines
patch :)
Quoted 7 lines
Quoted 3 lines
So for the benefit of the archives...
I'm dropping this patch since the equivalent is alrady in PM branch.
Kevin,
Today the sequence is such that the PER dpll autoidle is set
only after the first
Quoted 1 line
scratchpad save (so this patch has no affect). Sometime in
future, if with some change
Quoted 1 line
in function sequencing we end up enabling the PER dpll

Quoted 8 lines

autoidle early on, we might have
Quoted 2 lines
an additional 20ms or so OFF latency without anyone really noticing. Would'nt it be good to just have this patch to take care of
any sequencing changes later?
I don't think we should merge this until David can tell us more about the
instability that is caused by this patch.

Paul,

Even without this patch we have always had PER DPLL autoidle disabled in scratchpad in l-o base.
This patch does not have any affect today as I said and if there were instabilities to be seen we should have already seen them.

regards,
Rajendra

Quoted 6 lines

- Paul

A message that is not in the archive (sent off-list or not yet received): [email protected]

Woodruff, Richard

2009-07-01 14:28 UTC #12 lore raw

Quoted 5 lines

From: Kevin Hilman [mailto:[email protected]]
Sent: Wednesday, July 01, 2009 9:19 AM
David, did you see stability problems when using this patch on top of linux-omap PM branch? Or did you see problems on some internal tree?

Issue was on one internal tree. Tests need to be re-applied to current trees.

Regards,
Richard W.

Kevin Hilman

2009-07-01 14:36 UTC #13 lore raw

Quoted 8 lines · Richard

Quoted 5 lines
From: Kevin Hilman [mailto:[email protected]]
Sent: Wednesday, July 01, 2009 9:19 AM
David, did you see stability problems when using this patch on top of linux-omap PM branch? Or did you see problems on some internal tree?
Issue was on one internal tree. Tests need to be re-applied to current trees.

OK, then presumably the same problems already exist in linux-omap since we've had this feature for awhile.

I'm going to apply this patch to the PM branch.

A more detailed report of the test and the instability against the current tree would be very helpful.

Kevin