Jean Pihet <jean.pihet@xxxxxxxxxxxxxx> writes: > Hi Rajendra, > > On Wed, Jun 20, 2012 at 10:57 AM, Rajendra Nayak <rnayak@xxxxxx> wrote: >> Jean, >> >> >> On Wednesday 20 June 2012 02:22 PM, Rajendra Nayak wrote: >>> >>> Hi Jean, >>> >>> On Wednesday 20 June 2012 02:16 PM, Rajendra Nayak wrote: >>>> >>>> On Wednesday 20 June 2012 02:01 PM, Jean Pihet wrote: >>>>> >>>>> Hi Rajendra, >>>>> >>>>> On Wed, Jun 20, 2012 at 10:19 AM, Rajendra Nayak<rnayak@xxxxxx> wrote: >>>>>> >>>>>> Hi Jean, >>>>>> >>>>>> >>>>>> On Friday 01 June 2012 08:41 PM, Jean Pihet wrote: >>>>>>> >>>>>>> >>>>>>> For a power domain to idle all the clock domains in it must idle. >>>>>>> This patch implements an optimization of the cpuidle code by >>>>>>> denying and later allowing only the first registered clock domain >>>>>>> of a power domain, and so optimizes the latency of the low power code. >>>>>> >>>>>> >>>>>> >>>>>> How much do we really save doing this? I understand what you are doing >>>>>> by looking at the patch but the changelog seems very confusing. >>>>> >>>>> The gain is on the registers accesses and the internal PRCM state >>>>> machine. >>>>> If needed the changelog can be updated. >>>> >>>> >>>> Can you explain a bit more on which register accesses are you talking >>>> about? and some more on the PRCM state machine. >>> >>> >>> never mind, I looked at the patch again and then the cpuidle code and >>> figured what you are doing. Makes sense to me now :-) > Ok! > >> >> >> How do you like this updated changelog, I just added one more line. >> >> >> " >> For a power domain to idle all the clock domains in it must idle. >> Denying just *one* clkdm in a pwrdm from idling should have the >> same effect as denying *all*. >> >> This patch implements an optimization of the cpuidle code by >> denying and later allowing only the first registered clock domain >> of a power domain, and so optimizes the latency of the low power code. >> " > That looks great! > > Kevin, > Can you take this change still in your for_3.6/pm/performance branch? > Sorry, too late. 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
