Re: [PATCH v4 1/6] Documentation: arm: define DT idle states bindings

[Santosh Shilimkar <santosh.shilimkar@ti.com>]

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