Re: [PATCH v4 1/6] Documentation: arm: define DT idle states bindings
From: Santosh Shilimkar <hidden>
Date: 2014-06-18 20:55:45
Also in:
linux-arm-kernel, linux-pm
On Wednesday 18 June 2014 04:51 PM, Nicolas Pitre wrote:
On Wed, 18 Jun 2014, Santosh Shilimkar wrote:quoted
On Wednesday 18 June 2014 01:36 PM, Lorenzo Pieralisi wrote: [..]quoted
+ 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