"Nayak, Rajendra" <rnayak@xxxxxx> writes: > > >>-----Original Message----- >>From: Kalle Jokiniemi [mailto:kalle.jokiniemi@xxxxxxxxx] >>Sent: Wednesday, June 17, 2009 6:18 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 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. > > 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 -- 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
