diff options
author | Geert Uytterhoeven <geert+renesas@glider.be> | 2019-08-30 17:02:58 +0200 |
---|---|---|
committer | Rob Herring <robh@kernel.org> | 2019-09-02 15:56:46 +0100 |
commit | fb2d23291bf1dc2351152f218eaf9513b4bad1e1 (patch) | |
tree | 2b7416165e9fb0b33db7e92bc8c0bd39a5a7e47c /Documentation/devicetree/bindings/arm | |
parent | 08dc99e5407d2873801b36cae5d584e372a5f769 (diff) |
dt-bindings: arm: idle-states: Use "e.g." and "i.e." consistently
Replace abbreviations "eg" and "ie" by "e.g." resp. "i.e." for
consistency.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Diffstat (limited to 'Documentation/devicetree/bindings/arm')
-rw-r--r-- | Documentation/devicetree/bindings/arm/idle-states.txt | 16 |
1 files changed, 8 insertions, 8 deletions
diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt b/Documentation/devicetree/bindings/arm/idle-states.txt index 2d325bed37e5..610b16c28d99 100644 --- a/Documentation/devicetree/bindings/arm/idle-states.txt +++ b/Documentation/devicetree/bindings/arm/idle-states.txt @@ -28,7 +28,7 @@ PM implementation to put the processor in different idle states (which include states listed above; "off" state is not an idle state since it does not have wake-up capabilities, hence it is not considered in this document). -Idle state parameters (eg entry latency) are platform specific and need to be +Idle state parameters (e.g. entry latency) are platform specific and need to be characterized with bindings that provide the required information to OS PM code so that it can build the required tables and use them at runtime. @@ -90,20 +90,20 @@ These timing parameters can be used by an OS in different circumstances. An idle CPU requires the expected min-residency time to select the most appropriate idle state based on the expected expiry time of the next IRQ -(ie wake-up) that causes the CPU to return to the EXEC phase. +(i.e. wake-up) that causes the CPU to return to the EXEC phase. An operating system scheduler may need to compute the shortest wake-up delay for CPUs in the system by detecting how long will it take to get a CPU out -of an idle state, eg: +of an idle state, e.g.: wakeup-delay = exit-latency + max(entry-latency - (now - entry-timestamp), 0) In other words, the scheduler can make its scheduling decision by selecting -(eg waking-up) the CPU with the shortest wake-up latency. +(e.g. waking-up) the CPU with the shortest wake-up latency. The wake-up latency must take into account the entry latency if that period has not expired. The abortable nature of the PREP period can be ignored if it cannot be relied upon (e.g. the PREP deadline may occur much sooner than -the worst case since it depends on the CPU operating conditions, ie caches +the worst case since it depends on the CPU operating conditions, i.e. caches state). An OS has to reliably probe the wakeup-latency since some devices can enforce @@ -183,15 +183,15 @@ and IDLE2: Graph 2: idle states min-residency example In graph 2 above, that takes into account idle states entry/exit energy -costs, it is clear that if the idle state residency time (ie time till next +costs, it is clear that if the idle state residency time (i.e. time till next wake-up IRQ) is less than IDLE2-min-residency, IDLE1 is the better idle state choice energywise. This is mainly down to the fact that IDLE1 entry/exit energy costs are lower than IDLE2. -However, the lower power consumption (ie shallower energy curve slope) of idle -state IDLE2 implies that after a suitable time, IDLE2 becomes more energy +However, the lower power consumption (i.e. shallower energy curve slope) of +idle state IDLE2 implies that after a suitable time, IDLE2 becomes more energy efficient. The time at which IDLE2 becomes more energy efficient than IDLE1 (and other |