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. Nicolas -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
