On Wed, 2009-06-17 at 15:38 +0300, Nayak, Rajendra wrote: > > >-----Original Message----- > >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@xxxxxxxxx] > >Sent: Wednesday, June 17, 2009 3:56 PM > >To: Nayak, Rajendra > >Cc: linux-omap@xxxxxxxxxxxxxxx; 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@xxxxxxxxx] > >> >Sent: Wednesday, June 17, 2009 1:17 PM > >> >To: Nayak, Rajendra > >> >Cc: linux-omap@xxxxxxxxxxxxxxx; 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@xxxxxx> > >> >> --- > >> >> 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 = > >> > > > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
