From mboxrd@z Thu Jan 1 00:00:00 1970 From: Santosh Shilimkar Subject: Re: [PATCH v4 1/6] Documentation: arm: define DT idle states bindings Date: Wed, 18 Jun 2014 16:55:45 -0400 Message-ID: <53A1FCD1.8070703@ti.com> References: <1402503520-8611-1-git-send-email-lorenzo.pieralisi@arm.com> <1402503520-8611-2-git-send-email-lorenzo.pieralisi@arm.com> <20140613164954.GA16745@e102568-lin.cambridge.arm.com> <20140618173648.GB31573@e102568-lin.cambridge.arm.com> <53A1E818.6030400@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-pm-owner@vger.kernel.org To: Nicolas Pitre Cc: Lorenzo Pieralisi , "linux-arm-kernel@lists.infradead.org" , "linux-pm@vger.kernel.org" , "devicetree@vger.kernel.org" , Mark Rutland , Sudeep Holla , Catalin Marinas , Charles Garcia-Tobin , Rob Herring , "grant.likely@linaro.org" , Peter De Schrijver , Daniel Lezcano , Amit Kucheria , Vincent Guittot , Antti Miettinen , Stephen Boyd , Kevin Hilman , Sebastian Capella , Tomasz Figa , Mark Brown List-Id: devicetree@vger.kernel.org On Wednesday 18 June 2014 04:51 PM, Nicolas Pitre wrote: > On Wed, 18 Jun 2014, Santosh Shilimkar wrote: > >> On Wednesday 18 June 2014 01:36 PM, Lorenzo Pieralisi wrote: >> [..] >>> + To correctly specify idle states timing and energy related properties, >>> + the following definitions identify the different execution phases >>> + a CPU goes through to enter and exit idle states and the implied >>> + energy metrics: >>> + >>> + ..__[EXEC]__|__[PREP]__|__[ENTRY]__|__[IDLE]__|__[EXIT]__|__[EXEC]__.. >>> + | | | | | >>> + >>> + |<------ entry ------->| >>> + | latency | >>> + |<- exit ->| >>> + | latency | >>> + |<-------- min-residency -------->| >>> + |<------- wakeup-latency ------->| >>> + >> I don't know the wakeup latency makes much sense and also correct. >> Hardware wakeup latency is actually exit latency. Is it for failed >> or abort-able ilde case ? We are adding this as a new parameter >> at least from idle states perspective. I think we should just >> avoid it. > > I explained the rationale for this parameter in a previous email but > Lorenzo didn't carry it over. To be clearer, this should be "worst case > wake-up latency". It is of interest for PMQOS. This is the maximum > delay that can be expected from the moment a wake-up event is signaled > and the moment the CPU is back operational. This is more than just exit > latency. By default this is entry_latency + exit_latency but when there > is an abortable PREP phase then it may be shorter than that. > PMQOS angle is right. It is just that the idle code is not going to do anything with this value. But I see a value adding it instead of some one doing calculation. Thanks for clarity Nico !! regards, Santosh From mboxrd@z Thu Jan 1 00:00:00 1970 From: santosh.shilimkar@ti.com (Santosh Shilimkar) Date: Wed, 18 Jun 2014 16:55:45 -0400 Subject: [PATCH v4 1/6] Documentation: arm: define DT idle states bindings In-Reply-To: References: <1402503520-8611-1-git-send-email-lorenzo.pieralisi@arm.com> <1402503520-8611-2-git-send-email-lorenzo.pieralisi@arm.com> <20140613164954.GA16745@e102568-lin.cambridge.arm.com> <20140618173648.GB31573@e102568-lin.cambridge.arm.com> <53A1E818.6030400@ti.com> Message-ID: <53A1FCD1.8070703@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wednesday 18 June 2014 04:51 PM, Nicolas Pitre wrote: > On Wed, 18 Jun 2014, Santosh Shilimkar wrote: > >> On Wednesday 18 June 2014 01:36 PM, Lorenzo Pieralisi wrote: >> [..] >>> + To correctly specify idle states timing and energy related properties, >>> + the following definitions identify the different execution phases >>> + a CPU goes through to enter and exit idle states and the implied >>> + energy metrics: >>> + >>> + ..__[EXEC]__|__[PREP]__|__[ENTRY]__|__[IDLE]__|__[EXIT]__|__[EXEC]__.. >>> + | | | | | >>> + >>> + |<------ entry ------->| >>> + | latency | >>> + |<- exit ->| >>> + | latency | >>> + |<-------- min-residency -------->| >>> + |<------- wakeup-latency ------->| >>> + >> I don't know the wakeup latency makes much sense and also correct. >> Hardware wakeup latency is actually exit latency. Is it for failed >> or abort-able ilde case ? We are adding this as a new parameter >> at least from idle states perspective. I think we should just >> avoid it. > > I explained the rationale for this parameter in a previous email but > Lorenzo didn't carry it over. To be clearer, this should be "worst case > wake-up latency". It is of interest for PMQOS. This is the maximum > delay that can be expected from the moment a wake-up event is signaled > and the moment the CPU is back operational. This is more than just exit > latency. By default this is entry_latency + exit_latency but when there > is an abortable PREP phase then it may be shorter than that. > PMQOS angle is right. It is just that the idle code is not going to do anything with this value. But I see a value adding it instead of some one doing calculation. Thanks for clarity Nico !! regards, Santosh