RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

[Nayak, Rajendra]

>-----Original Message-----
>From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>Sent: Wednesday, June 17, 2009 1:17 PM
>To: Nayak, Rajendra
>Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard
>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:
>> 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
>
>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.

>
>- Kalle
>
>
>> This patch however does not optimize the C state threshold for
>> CORE OFF states based on the new latency.
>> 
>> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
>> ---
>>  arch/arm/mach-omap2/control.c |    7 +++++++
>>  1 files changed, 7 insertions(+), 0 deletions(-)
>> 
>> diff --git a/arch/arm/mach-omap2/control.c 
>b/arch/arm/mach-omap2/control.c
>> index c9407c0..a7159a9 100644
>> --- a/arch/arm/mach-omap2/control.c
>> +++ b/arch/arm/mach-omap2/control.c
>> @@ -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);
>> +	/*
>> +	 * ROM restore takes 20mS longer if PER idle is enabled 
>before OFF.
>> +	 * 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;
>> +
>>  	prcm_block_contents.cm_clksel1_pll =
>>  			cm_read_mod_reg(PLL_MOD, 
>OMAP3430_CM_CLKSEL1_PLL);
>>  	prcm_block_contents.cm_clksel2_pll =
>

RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

[Kalle Jokiniemi]

On Wed, 2009-06-17 at 12:50 +0300, Nayak, Rajendra wrote:
> >-----Original Message-----
> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
> >Sent: Wednesday, June 17, 2009 1:17 PM
> >To: Nayak, Rajendra
> >Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard
> >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:
> >> 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
> >
> >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.

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

> 
> >
> >- Kalle
> >
> >
> >> This patch however does not optimize the C state threshold for
> >> CORE OFF states based on the new latency.
> >> 
> >> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> >> ---
> >>  arch/arm/mach-omap2/control.c |    7 +++++++
> >>  1 files changed, 7 insertions(+), 0 deletions(-)
> >> 
> >> diff --git a/arch/arm/mach-omap2/control.c 
> >b/arch/arm/mach-omap2/control.c
> >> index c9407c0..a7159a9 100644
> >> --- a/arch/arm/mach-omap2/control.c
> >> +++ b/arch/arm/mach-omap2/control.c
> >> @@ -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);
> >> +	/*
> >> +	 * ROM restore takes 20mS longer if PER idle is enabled 
> >before OFF.
> >> +	 * 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;
> >> +
> >>  	prcm_block_contents.cm_clksel1_pll =
> >>  			cm_read_mod_reg(PLL_MOD, 
> >OMAP3430_CM_CLKSEL1_PLL);
> >>  	prcm_block_contents.cm_clksel2_pll =
> >

RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

[Nayak, Rajendra]

 

>-----Original Message-----
>From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>Sent: Wednesday, June 17, 2009 3:56 PM
>To: Nayak, Rajendra
>Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard
>Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle 
>before OFF, reduces OFF latency by 20ms
>
>On Wed, 2009-06-17 at 12:50 +0300, Nayak, Rajendra wrote:
>> >-----Original Message-----
>> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>> >Sent: Wednesday, June 17, 2009 1:17 PM
>> >To: Nayak, Rajendra
>> >Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard
>> >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:
>> >> 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
>> >
>> >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.
>
>> 
>> 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.

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

>
>- Kalle
>
>> 
>> >
>> >- Kalle
>> >
>> >
>> >> This patch however does not optimize the C state threshold for
>> >> CORE OFF states based on the new latency.
>> >> 
>> >> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
>> >> ---
>> >>  arch/arm/mach-omap2/control.c |    7 +++++++
>> >>  1 files changed, 7 insertions(+), 0 deletions(-)
>> >> 
>> >> diff --git a/arch/arm/mach-omap2/control.c 
>> >b/arch/arm/mach-omap2/control.c
>> >> index c9407c0..a7159a9 100644
>> >> --- a/arch/arm/mach-omap2/control.c
>> >> +++ b/arch/arm/mach-omap2/control.c
>> >> @@ -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);
>> >> +	/*
>> >> +	 * ROM restore takes 20mS longer if PER idle is enabled 
>> >before OFF.
>> >> +	 * 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;
>> >> +
>> >>  	prcm_block_contents.cm_clksel1_pll =
>> >>  			cm_read_mod_reg(PLL_MOD, 
>> >OMAP3430_CM_CLKSEL1_PLL);
>> >>  	prcm_block_contents.cm_clksel2_pll =
>> >
>
>
>

RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

[Kalle Jokiniemi]

On Wed, 2009-06-17 at 15:38 +0300, Nayak, Rajendra wrote:
> 
> >-----Original Message-----
> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
> >Sent: Wednesday, June 17, 2009 3:56 PM
> >To: Nayak, Rajendra
> >Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard
> >Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle 
> >before OFF, reduces OFF latency by 20ms
> >
> >On Wed, 2009-06-17 at 12:50 +0300, Nayak, Rajendra wrote:
> >> >-----Original Message-----
> >> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
> >> >Sent: Wednesday, June 17, 2009 1:17 PM
> >> >To: Nayak, Rajendra
> >> >Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard
> >> >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:
> >> >> 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
> >> >
> >> >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.
> >
> >> 
> >> 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.
> 
> 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

> 
> >
> >- Kalle
> >
> >> 
> >> >
> >> >- Kalle
> >> >
> >> >
> >> >> This patch however does not optimize the C state threshold for
> >> >> CORE OFF states based on the new latency.
> >> >> 
> >> >> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> >> >> ---
> >> >>  arch/arm/mach-omap2/control.c |    7 +++++++
> >> >>  1 files changed, 7 insertions(+), 0 deletions(-)
> >> >> 
> >> >> diff --git a/arch/arm/mach-omap2/control.c 
> >> >b/arch/arm/mach-omap2/control.c
> >> >> index c9407c0..a7159a9 100644
> >> >> --- a/arch/arm/mach-omap2/control.c
> >> >> +++ b/arch/arm/mach-omap2/control.c
> >> >> @@ -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);
> >> >> +	/*
> >> >> +	 * ROM restore takes 20mS longer if PER idle is enabled 
> >> >before OFF.
> >> >> +	 * 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;
> >> >> +
> >> >>  	prcm_block_contents.cm_clksel1_pll =
> >> >>  			cm_read_mod_reg(PLL_MOD, 
> >> >OMAP3430_CM_CLKSEL1_PLL);
> >> >>  	prcm_block_contents.cm_clksel2_pll =
> >> >
> >
> >
> >

RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

[Nayak, Rajendra]

 

>-----Original Message-----
>From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>Sent: Wednesday, June 17, 2009 6:18 PM
>To: Nayak, Rajendra
>Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard
>Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle 
>before OFF, reduces OFF latency by 20ms
>
>On Wed, 2009-06-17 at 15:38 +0300, Nayak, Rajendra wrote:
>> 
>> >-----Original Message-----
>> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>> >Sent: Wednesday, June 17, 2009 3:56 PM
>> >To: Nayak, Rajendra
>> >Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard
>> >Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle 
>> >before OFF, reduces OFF latency by 20ms
>> >
>> >On Wed, 2009-06-17 at 12:50 +0300, Nayak, Rajendra wrote:
>> >> >-----Original Message-----
>> >> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>> >> >Sent: Wednesday, June 17, 2009 1:17 PM
>> >> >To: Nayak, Rajendra
>> >> >Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard
>> >> >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:
>> >> >> 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
>> >> >
>> >> >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.
>> >
>> >> 
>> >> 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.
>> 
>> 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 :)

>
>- Kalle
>
>> 
>> >
>> >- Kalle
>> >
>> >> 
>> >> >
>> >> >- Kalle
>> >> >
>> >> >
>> >> >> This patch however does not optimize the C state threshold for
>> >> >> CORE OFF states based on the new latency.
>> >> >> 
>> >> >> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
>> >> >> ---
>> >> >>  arch/arm/mach-omap2/control.c |    7 +++++++
>> >> >>  1 files changed, 7 insertions(+), 0 deletions(-)
>> >> >> 
>> >> >> diff --git a/arch/arm/mach-omap2/control.c 
>> >> >b/arch/arm/mach-omap2/control.c
>> >> >> index c9407c0..a7159a9 100644
>> >> >> --- a/arch/arm/mach-omap2/control.c
>> >> >> +++ b/arch/arm/mach-omap2/control.c
>> >> >> @@ -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);
>> >> >> +	/*
>> >> >> +	 * ROM restore takes 20mS longer if PER idle is enabled 
>> >> >before OFF.
>> >> >> +	 * 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;
>> >> >> +
>> >> >>  	prcm_block_contents.cm_clksel1_pll =
>> >> >>  			cm_read_mod_reg(PLL_MOD, 
>> >> >OMAP3430_CM_CLKSEL1_PLL);
>> >> >>  	prcm_block_contents.cm_clksel2_pll =
>> >> >
>> >
>> >
>> >
>
>
>

Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

[Kevin Hilman]

"Nayak, Rajendra" <rnayak@ti.com> writes:

>  
>
>>-----Original Message-----
>>From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>>Sent: Wednesday, June 17, 2009 6:18 PM
>>To: Nayak, Rajendra
>>Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard
>>Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle 
>>before OFF, reduces OFF latency by 20ms
>>
>>On Wed, 2009-06-17 at 15:38 +0300, Nayak, Rajendra wrote:
>>> 
>>> >-----Original Message-----
>>> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>>> >Sent: Wednesday, June 17, 2009 3:56 PM
>>> >To: Nayak, Rajendra
>>> >Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard
>>> >Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle 
>>> >before OFF, reduces OFF latency by 20ms
>>> >
>>> >On Wed, 2009-06-17 at 12:50 +0300, Nayak, Rajendra wrote:
>>> >> >-----Original Message-----
>>> >> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>>> >> >Sent: Wednesday, June 17, 2009 1:17 PM
>>> >> >To: Nayak, Rajendra
>>> >> >Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard
>>> >> >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:
>>> >> >> 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
>>> >> >
>>> >> >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.
>>> >
>>> >> 
>>> >> 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.
>>> 
>>> 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 :)
>

So for the benefit of the archives... 

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

Kevin

RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

[Nayak, Rajendra]

>-----Original Message-----
>From: Kevin Hilman [mailto:khilman@deeprootsystems.com] 
>Sent: Tuesday, June 30, 2009 12:28 AM
>To: Nayak, Rajendra
>Cc: Kalle Jokiniemi; linux-omap@vger.kernel.org; Derrick, 
>David; Woodruff, Richard
>Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle 
>before OFF, reduces OFF latency by 20ms
>
>"Nayak, Rajendra" <rnayak@ti.com> writes:
>
>>  
>>
>>>-----Original Message-----
>>>From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>>>Sent: Wednesday, June 17, 2009 6:18 PM
>>>To: Nayak, Rajendra
>>>Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard
>>>Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle 
>>>before OFF, reduces OFF latency by 20ms
>>>
>>>On Wed, 2009-06-17 at 15:38 +0300, Nayak, Rajendra wrote:
>>>> 
>>>> >-----Original Message-----
>>>> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>>>> >Sent: Wednesday, June 17, 2009 3:56 PM
>>>> >To: Nayak, Rajendra
>>>> >Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard
>>>> >Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle 
>>>> >before OFF, reduces OFF latency by 20ms
>>>> >
>>>> >On Wed, 2009-06-17 at 12:50 +0300, Nayak, Rajendra wrote:
>>>> >> >-----Original Message-----
>>>> >> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>>>> >> >Sent: Wednesday, June 17, 2009 1:17 PM
>>>> >> >To: Nayak, Rajendra
>>>> >> >Cc: linux-omap@vger.kernel.org; Derrick, David; 
>Woodruff, Richard
>>>> >> >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:
>>>> >> >> 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
>>>> >> >
>>>> >> >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.
>>>> >
>>>> >> 
>>>> >> 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.
>>>> 
>>>> 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 :)
>>
>
>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

>
>Kevin
>
>

Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

[Kevin Hilman]

"Nayak, Rajendra" <rnayak@ti.com> writes:

[...]

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

RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

[Paul Walmsley]

On Tue, 30 Jun 2009, Nayak, Rajendra wrote:

> >-----Original Message-----
> >From: Kevin Hilman [mailto:khilman@deeprootsystems.com] 
> >Sent: Tuesday, June 30, 2009 12:28 AM
> >To: Nayak, Rajendra
> >Cc: Kalle Jokiniemi; linux-omap@vger.kernel.org; Derrick, 
> >David; Woodruff, Richard
> >Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle 
> >before OFF, reduces OFF latency by 20ms
> >
> >"Nayak, Rajendra" <rnayak@ti.com> writes:
> >
> >>  
> >>
> >>>-----Original Message-----
> >>>From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
> >>>Sent: Wednesday, June 17, 2009 6:18 PM
> >>>To: Nayak, Rajendra
> >>>Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard
> >>>Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle 
> >>>before OFF, reduces OFF latency by 20ms
> >>>
> >>>On Wed, 2009-06-17 at 15:38 +0300, Nayak, Rajendra wrote:
> >>>> 
> >>>> >-----Original Message-----
> >>>> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
> >>>> >Sent: Wednesday, June 17, 2009 3:56 PM
> >>>> >To: Nayak, Rajendra
> >>>> >Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard
> >>>> >Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle 
> >>>> >before OFF, reduces OFF latency by 20ms
> >>>> >
> >>>> >On Wed, 2009-06-17 at 12:50 +0300, Nayak, Rajendra wrote:
> >>>> >> >-----Original Message-----
> >>>> >> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
> >>>> >> >Sent: Wednesday, June 17, 2009 1:17 PM
> >>>> >> >To: Nayak, Rajendra
> >>>> >> >Cc: linux-omap@vger.kernel.org; Derrick, David; 
> >Woodruff, Richard
> >>>> >> >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:
> >>>> >> >> 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
> >>>> >> >
> >>>> >> >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.
> >>>> >
> >>>> >> 
> >>>> >> 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.
> >>>> 
> >>>> 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 :)
> >>
> >
> >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?

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



- Paul

RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

[Nayak, Rajendra]

>-----Original Message-----
>From: Paul Walmsley [mailto:paul@pwsan.com] 
>Sent: Wednesday, July 01, 2009 4:02 AM
>To: Nayak, Rajendra
>Cc: Kevin Hilman; Kalle Jokiniemi; linux-omap@vger.kernel.org; 
>Derrick, David; Woodruff, Richard
>Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle 
>before OFF, reduces OFF latency by 20ms
>
>On Tue, 30 Jun 2009, Nayak, Rajendra wrote:
>
>> >-----Original Message-----
>> >From: Kevin Hilman [mailto:khilman@deeprootsystems.com] 
>> >Sent: Tuesday, June 30, 2009 12:28 AM
>> >To: Nayak, Rajendra
>> >Cc: Kalle Jokiniemi; linux-omap@vger.kernel.org; Derrick, 
>> >David; Woodruff, Richard
>> >Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle 
>> >before OFF, reduces OFF latency by 20ms
>> >
>> >"Nayak, Rajendra" <rnayak@ti.com> writes:
>> >
>> >>  
>> >>
>> >>>-----Original Message-----
>> >>>From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>> >>>Sent: Wednesday, June 17, 2009 6:18 PM
>> >>>To: Nayak, Rajendra
>> >>>Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard
>> >>>Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle 
>> >>>before OFF, reduces OFF latency by 20ms
>> >>>
>> >>>On Wed, 2009-06-17 at 15:38 +0300, Nayak, Rajendra wrote:
>> >>>> 
>> >>>> >-----Original Message-----
>> >>>> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>> >>>> >Sent: Wednesday, June 17, 2009 3:56 PM
>> >>>> >To: Nayak, Rajendra
>> >>>> >Cc: linux-omap@vger.kernel.org; Derrick, David; 
>Woodruff, Richard
>> >>>> >Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle 
>> >>>> >before OFF, reduces OFF latency by 20ms
>> >>>> >
>> >>>> >On Wed, 2009-06-17 at 12:50 +0300, Nayak, Rajendra wrote:
>> >>>> >> >-----Original Message-----
>> >>>> >> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>> >>>> >> >Sent: Wednesday, June 17, 2009 1:17 PM
>> >>>> >> >To: Nayak, Rajendra
>> >>>> >> >Cc: linux-omap@vger.kernel.org; Derrick, David; 
>> >Woodruff, Richard
>> >>>> >> >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:
>> >>>> >> >> 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
>> >>>> >> >
>> >>>> >> >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.
>> >>>> >
>> >>>> >> 
>> >>>> >> 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.
>> >>>> 
>> >>>> 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 :)
>> >>
>> >
>> >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?
>
>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

>
>
>
>- Paul
>
>

RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

[Woodruff, Richard]

> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> 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.

Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

[Kevin Hilman]

"Woodruff, Richard" <r-woodruff2@ti.com> writes:

>> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>> 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

[PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

[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.
This patch however does not optimize the C state threshold for
CORE OFF states based on the new latency.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
 arch/arm/mach-omap2/control.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index c9407c0..a7159a9 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -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);
+	/*
+	 * ROM restore takes 20mS longer if PER idle is enabled before OFF.
+	 * 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;
+
 	prcm_block_contents.cm_clksel1_pll =
 			cm_read_mod_reg(PLL_MOD, OMAP3430_CM_CLKSEL1_PLL);
 	prcm_block_contents.cm_clksel2_pll =
-- 
1.5.4.7

Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

[Högander Jouni]

ext Rajendra Nayak <rnayak@ti.com> writes:

> 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.
> This patch however does not optimize the C state threshold for
> CORE OFF states based on the new latency.

Do you have any numbers to give on what is the impact to consumption?

>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> ---
>  arch/arm/mach-omap2/control.c |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
> index c9407c0..a7159a9 100644
> --- a/arch/arm/mach-omap2/control.c
> +++ b/arch/arm/mach-omap2/control.c
> @@ -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);
> +	/*
> +	 * ROM restore takes 20mS longer if PER idle is enabled before OFF.
> +	 * 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;
> +
>  	prcm_block_contents.cm_clksel1_pll =
>  			cm_read_mod_reg(PLL_MOD, OMAP3430_CM_CLKSEL1_PLL);
>  	prcm_block_contents.cm_clksel2_pll =
> -- 
> 1.5.4.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Jouni Högander
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

[Nayak, Rajendra]

>-----Original Message-----
>From: Högander Jouni [mailto:jouni.hogander@nokia.com] 
>Sent: Tuesday, June 16, 2009 6:23 PM
>To: Nayak, Rajendra
>Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard
>Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle 
>before OFF, reduces OFF latency by 20ms
>
>ext Rajendra Nayak <rnayak@ti.com> writes:
>
>> 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.
>> This patch however does not optimize the C state threshold for
>> CORE OFF states based on the new latency.
>
>Do you have any numbers to give on what is the impact to consumption?

Not yet, I will post some after some profiling.

>
>>
>> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
>> ---
>>  arch/arm/mach-omap2/control.c |    7 +++++++
>>  1 files changed, 7 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/control.c 
>b/arch/arm/mach-omap2/control.c
>> index c9407c0..a7159a9 100644
>> --- a/arch/arm/mach-omap2/control.c
>> +++ b/arch/arm/mach-omap2/control.c
>> @@ -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);
>> +	/*
>> +	 * ROM restore takes 20mS longer if PER idle is enabled 
>before OFF.
>> +	 * 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;
>> +
>>  	prcm_block_contents.cm_clksel1_pll =
>>  			cm_read_mod_reg(PLL_MOD, 
>OMAP3430_CM_CLKSEL1_PLL);
>>  	prcm_block_contents.cm_clksel2_pll =
>> -- 
>> 1.5.4.7
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe 
>linux-omap" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>-- 
>Jouni Högander
>
>

Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

[Kevin Hilman]

Rajendra Nayak <rnayak@ti.com> writes:

> 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.
> This patch however does not optimize the C state threshold for
> CORE OFF states based on the new latency.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>

Please forgive the DPLL ignorance here, but I think a little more
verbose description is needed here, especially for those of use who
don't understand all the voodoo involved with DPLLs and ROM code
interaction.

>From this description, it's not clear what the resulting state of
DPLL4 will be and thus what the impact might be on power consumption.

IOW, Does this leave the DPLL in a locked, or is ROM code is doing a
software-programmed transition to low-power stop?  or is there some
other automatic disable when PER goes to OFF?

Can you clarify and update the description.  Thanks.

Kevin

> ---
>  arch/arm/mach-omap2/control.c |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
> index c9407c0..a7159a9 100644
> --- a/arch/arm/mach-omap2/control.c
> +++ b/arch/arm/mach-omap2/control.c
> @@ -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);
> +	/*
> +	 * ROM restore takes 20mS longer if PER idle is enabled before OFF.
> +	 * 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;
> +
>  	prcm_block_contents.cm_clksel1_pll =
>  			cm_read_mod_reg(PLL_MOD, OMAP3430_CM_CLKSEL1_PLL);
>  	prcm_block_contents.cm_clksel2_pll =
> -- 
> 1.5.4.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

[Derrick, David]

Kevin,

There is a feature to auto idle DPLLs.
The DPLLs will go into a bypass mode when not needed.

The boot ROM restores some PRCM registers from scratchpad memory when waking up from the OFF power mode.
The procedure in the boot ROM is to restore the DPLL4 settings and then poll until the DPLL4 has locked. There is a timeout on the poll of 20ms.

If you store into scratchpad the register such that the autoidle is enabled, then as soon as the boot ROM locks DPLL4 it will immediately go into bypass. Therefore the poll on the DPLL4 locking will time out (20ms).

If you store into scratchpad the register such that the autoidle is not enabled, then the boot ROM will lock DPLL4 and poll until the DPLL4 is locked - which happens in the usec range.

You need to ensure that you re-enable the autoidle of DPLL4 after you get back to user code - which is already done in our base port so you shouldn't have to worry with it unless you have removed this code.

This change allows the wake up latency from OFF mode to be reduced by 20msec.

Note that we have seen some instability with this change so use with caution.

Regards,
David

-----Original Message-----
From: Kevin Hilman [mailto:khilman@deeprootsystems.com] 
Sent: Tuesday, June 16, 2009 9:21 AM
To: Nayak, Rajendra
Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard
Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

Rajendra Nayak <rnayak@ti.com> writes:

> 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.
> This patch however does not optimize the C state threshold for
> CORE OFF states based on the new latency.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>

Please forgive the DPLL ignorance here, but I think a little more
verbose description is needed here, especially for those of use who
don't understand all the voodoo involved with DPLLs and ROM code
interaction.

>From this description, it's not clear what the resulting state of
DPLL4 will be and thus what the impact might be on power consumption.

IOW, Does this leave the DPLL in a locked, or is ROM code is doing a
software-programmed transition to low-power stop?  or is there some
other automatic disable when PER goes to OFF?

Can you clarify and update the description.  Thanks.

Kevin

> ---
>  arch/arm/mach-omap2/control.c |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
> index c9407c0..a7159a9 100644
> --- a/arch/arm/mach-omap2/control.c
> +++ b/arch/arm/mach-omap2/control.c
> @@ -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);
> +	/*
> +	 * ROM restore takes 20mS longer if PER idle is enabled before OFF.
> +	 * 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;
> +
>  	prcm_block_contents.cm_clksel1_pll =
>  			cm_read_mod_reg(PLL_MOD, OMAP3430_CM_CLKSEL1_PLL);
>  	prcm_block_contents.cm_clksel2_pll =
> -- 
> 1.5.4.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

[Paul Walmsley]

Hello David,

On Tue, 16 Jun 2009, Derrick, David wrote:

> Note that we have seen some instability with this change so use with caution.

Could you please expand on this?  Presumably we should not merge this if 
it will cause instability, no?


- Paul