Power Management for the Nokia Internet Tablets

Nokia Internet Tablet
Power Management

Klaus K Pedersen

Igor Stoppa

This material, including documentation and any related computer programs, is protected by copyright controlled by Nokia. All rights are reserved.

1 Copyright © 2007 Nokia. All rights reserved.

Overview

•Current Solutions:
•Sleep while Idle
•Dynamic Tick

•Future:
•Dynamic Voltage and Frequency Scaling
•CPUFreq
•Dynamic Power Switching


Sleep While Idle

• In the idle loop, always try to go to the target
sleep state
• the target sleep state is set based on latency
• OMAP1 : ARM idle / Big Sleep / Deep Sleep
• OMAP2 : ARM idle / MPU retention / SoC retention
the lowest sleep state is characterized by clock stop
●

(including system osc) and lowered VCORE
(retention voltage)

The major causes of latency are:
● restarting the system oscillator

● restoring VCORE to the active value


Dynamic Tick

• Skips system ticks that are not associated with
any scheduled activity
• Uses the low freq (32khz) clock from the system
XTL to keep track of the time passing
• “Sleep While Idle” can keep the system stopped
for longer time
• Now that the 2.6.21 kernel supports tick-less
activity, we should switch to the standard
implementation
• The current OMAP-specific implementation has
drawbacks as it introduces delays when
calculating the time for the next wakeup


Dynamic Voltage & Frequency Scaling

Premise:

 :switching factor
2
P=⋅C eff⋅V ⋅f C eff :effectivecapacitance
V : operating voltage
2
f :operating frequency
E =P⋅T  E ∝n⋅V
P : Dynamic Power
E : Dynamic Energy
∀ V n ∃f MAXn∣f MAXn=MAX [f V n ] T : Period of time
n : cyclesdone during T



• The power used by a system depends:
 quadratically on the voltage applied,

 linearly on the “work” (freq).

For any given voltage, there is a maximum
●

frequency at which the system is still stable.

The highest stable frequency available
for the currently set voltage yields the
maximum efficiency.



Considerations: Voltage Scaling (CPU only)

Deadline Deadline
V V
V1
V 2=
V1 V2
2
W
W
f 2 f 1
T1 T2
T T
D
2
f 2 =MAX [f V 2 ] E 2 ∝V 2
2
f 1 =MAX [f V 1 ] E 1 ∝V 1

Same workload W
E1
E2∝ Deadline is still met
4
75% Energy saved



Apparently the best choice is the minimum
voltage V suitable for a frequency f that
can meet the deadline.

But ...


Considerations: System-wise performance

Also other leakages than the processor must be considered.

P=P static P dynamic
Example:
SDRAM (Mobile DDR) current:
•active current ≈ 10 - 30 mA
•self-refresh current < 1mA
OMAP2 current:
•active current > 100 mA
•idle < 2mA


Considerations: Causes of Latency

There are several causes that can make a transition slow:

•re-lock DPLLs and DLLs ≈ 0.1 ms
•re-adjust voltage regulators ≈ 5 ms (present)
target value should be ≈ 0.1 ms
•pause / resume device drivers ≈ 20 - 50 ms

Improving drivers is the way to reduce latency



OMAP2 DVFS Scheme
Current Implementation

Cpufreq
Selection List of Frequencies

OP
Set Vtg
OMAP2 DVFS Voltage
Settings
board cfg driver Scaling

Update
Clk
FW
Drv 1 Drv 2 Drv n
...



OMAP2 DVFS Interfaces

Toward OP selector (Cpufreq):
•Get frequencies & OP list
•Set target OP
•Get latency

Toward drivers:
•Register / unregister
•Send sync / async pre and post notification



OMAP2 DVFS

Sequence:
Request of new OP
●

Pre-notification to drivers
●

Wait for ACK from all drivers
●

Change Voltage (if needed)
●

Adjust clocks
●

Tell Clk FW to sync up with
●

Post-notification to drivers
●


CPUFREQ: Lessons learned

•Expressing Constraints
•Determinism
•non-polling governor
•ondemand transition_latency misuse


Expressing Constraints
A real life case: OMAP2 speed sorted (N800):
OP ARM [MHz] DSP [MHz]
0 400 133
1 330 220
2 266 177
3 165 85
Constraints should be described by referring to the
●

frequency that they are addressing

Ex: DSP requires dsp_fclk >= 220MHz rather than
DSP requires OP1


Expressing Constraints: Ranges

Functional constraints are mapped into sets of valid
●

states to enable much richer operations.

Example:
● For embedded targets there would be a one-to-one

mapping between operating-point and bits in the
vector.
...
OPn OP4 OP3 OP2 OP1 OP0

For PC's ACPI: P states are really OPs
●


Towards deterministic behaviour
•cpufreq_set_policy(): still broken
• If there are non overlapping policies, a random
frequency will be selected
• No way to validate a policy is respected.
•RFC: the callback could be replaced with a registered /
unregister (frequency) policy interface.

static struct cpufreq_constraint mypol = {
   .prio = OR_DIE;
   .low = FREQ(OP1);
   ...
err = cpufreq_register_constraint(&mypol);
...
cpufreq_unregister_constraint(&mypol);


CPUFREQ non-polling governors
• The ondemand sawtooth frequency switching algorithm has many
good properties.
• It should be possible to create a non-polling governor with the
properties of ondemand. All what is required is call-backs/notifications
from idle.
Given Tidle
* Compute new
(lower freq)
* Start timer for
going up
f
timer
timer

t
idle


CPUFREQ: transition_latency misuse

•ondemand uses transition_latency to calculate
the polling interval (1000x).

•this weird relation is artificial.

•Introduce:

•polling_interval

•relax_interval i.e. the minimum time to
stay on a newly selected frequency.


Introduce concept of Target Idle state

•For the coming System on Chip in finer geometries we
will have to utilize even lower Idle-states like – off(!)
Problem: off state introduces longer latencies

•We need a mechanism to select the target idle-state.

•CPUFREQ could adjust the idle-state that matches the
state of the system (mostly idle vs mostly active).

•Potential better performance and bigger power-
savings.


Conclusion: Simple rules

•Run as fast as you can for the given the voltage.
•Goto to idle with clock-stop when nothing to do.
•You can't predict the future – so forget about fine-
grained frequency control.
•The time spent in idle vs active (a'la OnDemand) is
a good key for selecting system performance
settings.
•Don't change frequency too often or you waste cpu-
time waiting for drivers to pause and restart
peripherals.


Conclusion: Improvements

OMAP2 DVFS Interfaces

•Use smp-like approach for ARM-DSP
•Get frequencies & OP list for each core
•Get latency for each OP transition
•Add transaction support to clk FW
•Cpufreq to use threaded notifications


Conclusion: Challenges

•Non-SMP systems, with independent OS but
intermingled clock and voltage control

•Relative high current usage by support
components -> nullifies benefit of low
frequency and voltage operation point in a
dynamic idle system.


Power Management for the Nokia Internet Tablets

Recommended

Recommended

More Related Content

What's hot

What's hot (12)

Similar to Power Management for the Nokia Internet Tablets

Similar to Power Management for the Nokia Internet Tablets (20)

Recently uploaded

Recently uploaded (20)

Power Management for the Nokia Internet Tablets