Hi

Looks we are pretty much agreed on the number now.
In my e-mail though I was questioning what should be optional and what
shouldn't. The current proposal is that wakeup-latency-us is the optional
one, I was thinking that it's make more sense making entry/exit (given the
use is much more specific and yet to be proven) but frankly it is not great
shakes either way, so for me it's fine as it is. The only thing that I think
would be worth clarifying is that the text around wakeup-latency-us, to make
it clear when it makes sense to provide it. So I was thinking something
like:

        - wakeup-latency-us:
                Usage: Optional
                Value type: <prop-encoded-array>
                Definition: u32 value representing maximum delay between the
                            signalling of a wake-up event and the CPU being
                            able to execute normal code again. If omitted,
                            this is assumed to be equal to:
                                entry-latency-us + exit-latency-us
                            It is important to supply this value on systems 
                            where the duration of PREP phase is 
                            non-neglibigle. In such systems 
                            entry-latency-us + exit-latency-us 
                            will exceed wakeup-latency-us by this duration.

The other thing that may be worth adding is some graphs to help explain what
is meant by min-residency. Lorenzo feel free to take this or leave this. But
something like:

The energy consumption of a cpu when it enters a power state can be roughly
characterised by the following graph:

               |
               |
               |
           e   |
           n   |                                      /---
           e   |                               /------
           r   |                        /------
           g   |                  /-----
           y   |           /------
               |       ----
               |      /|
               |     / |
               |    /  |
               |   /   |
               |  /    |
               | /     |                          
               |/      |                          
          -----|-------+----------------------------------
              0|       1                      time


The graph starts with a steep slope and then a shallower one. The first part
denotes the energy costs incurred whilst entering and leaving the power
state. The shallower slope is essentially representing the power consumption
of the state. 
We are defining min-residency for a given state as the period of time after
which choosing that state become the most energy efficient option. A good
way to visualise this, is if we take the same graph above and compare some
states. Due to the limitations of ascii art we are only showing two made up
states C1, and C2:


          |
          |
          |
          |                                                  /-- C1
       e  |                                              /---      
       n  |                                         /----          
       e  |                                     /---               
       r  |                                /----     /----------- C2
       g  |                    /-------/-------------               
       y  |        ------------    /---|
          |       /           /----    |
          |      /        /---         |
          |     /    /----             |
          |    / /---                  |
          |   ---                      |
          |  /                         |
          | /                          |
          |/                           |                  time
       ---/----------------------------+------------------------
          |  better off with C1        | better off with C2
                                       |
                                   min-residency    
                                   for C2               



As you can see, having taken into account entry/exit costs there is period
were C1 is the better choice of state. This is mainly down to the fact that
entry/exit costs are low. However the lower power consumption of C2 means
that after a suitable time, C2 is the better choice. This interval of time
is what we want to call min-residency
                     
Cheers

Charles

-----Original Message-----
From: Santosh Shilimkar [mailto:santosh.shilimkar@ti.com]
Sent: 19 June 2014 15:09
To: Charles Garcia-Tobin; Lorenzo Pieralisi; Nicolas Pitre
Cc: linux-arm-kernel@lists.infradead.org; linux-pm@vger.kernel.org;
devicetree@vger.kernel.org; Mark Rutland; Sudeep Holla; Catalin
Marinas; 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;
Paul Walmsley; Chander Kashyap
Subject: Re: [PATCH v4 1/6] Documentation: arm: define DT idle states
bindings

Charles,

On Thursday 19 June 2014 03:33 AM, Charles Garcia-Tobin wrote:

quoted

quoted

-----Original Message-----
From: Santosh Shilimkar [mailto:santosh.shilimkar@ti.com]
Sent: 18 June 2014 20:27
To: Lorenzo Pieralisi; Nicolas Pitre

[..]

quoted

quoted

quoted

+===========================================
+3 - state node
+===========================================
+
+A state node represents an idle state description and must be

defined as

quoted

+follows:
+
+- state node
+
+	Description: must be child of the idle-states node
+
+	The state node name shall follow standard device tree naming
+	rules ([5], 2.2.1 "Node names"), in particular state nodes which
+	are siblings within a single common parent must be given a unique

name.

quoted

+
+	The idle state entered by executing the wfi instruction

(idle_standby

quoted

+	SBSA,[3][4]) is considered standard on all ARM platforms and

therefore

quoted

+	must not be listed.
+
+	To correctly specify idle states timing and energy related

properties,

quoted

+	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]
__..

quoted

+		    |          |           |          |          |
+
+		    |<------ 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.

Hi Santosh,

To me wake up latency makes up a lot of sense. It is not always the

same as

quoted

exit latency, it will depend on your system, and just how smart it

is. In

quoted

some cases the [ENTRY] period may not be negligible in which case

exit

quoted

latency will be less than the wake up latency.
In addition, it will generally always be shorter than entry+exit

which is

quoted

the default value if omitted, this assumes the PREP time is not

abortable,

quoted

but this is the safer assumption to make.
Wake up latency is really the number that folk have in their head for

what

quoted

you'd stick into the pm_qos to veto entry into states when you are

latency

quoted

constrained.
The one thing that really is an optimisation here is having a

separate exit

quoted

latency, which is being proposed for use in core selection for the
scheduler.
So if anything was going to be made optional pending new scheduler

patches

quoted

should that not be entry/exit latency?

PM QOS angle Nico pointed out and its clear. The wakeup latency as such
is a
worst case wakeup latency from QOS perspective so considering the
aborted idle
case it makes sense to have conservative number which includes entry +
exit.

If you look at current idle governors, only exit latency and target
residency
is being used. No matter how we represent it, as long idle governor or
idle
C-state selection logic gets that information, things should be fine.
So
from that view your point of entry/exit optional makes sense
considering
wakeup latency can convey that information indirectly.

Regards,
Santosh