power management for the nokia internet tablets

1 Copyright © 2007 Nokia. All rights reserved.

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

Nokia Internet Tablet

Power Management

Klaus K Pedersen

Igor Stoppa


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:

P=⋅Ceff⋅V2⋅f

:switching factor

Ceff :effectivecapacitance

f :operatingfrequency

V :operatingvoltage

∀Vn∃f MAXn∣f MAXn=MAX [f V n]

E=P⋅TE∝n⋅V 2

P :DynamicPower

E :Dynamic Energy

T :Period of time

n:cyclesdoneduringT



•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)

T

V Deadline

T2

V2

f 2=MAX [f V 2] E2∝V 22

T

V Deadline

DT1

V1

f 1=MAX [f V 1] E1∝V 12

V 2=V1

2

f 2f 1

WW

E2∝E1

4

Same workload W

Deadline is still met

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.

Example:

SDRAM (Mobile DDR) current:

•active current ≈ 10 - 30 mA

•self-refresh current < 1mA

OMAP2 current:

•active current > 100 mA

•idle < 2mA

P=PstaticPdynamic



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 SchemeCurrent Implementation

Cpufreq

OMAP2 DVFS driverboard cfg

OPSettings

Selection List of Frequencies

Voltage Scaling

Set Vtg

Drv 1 Drv 2 Drv n...

Clk FW

Update



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):

● Constraints should be described by referring to the frequency that they are addressing

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

OP ARM [MHz] DSP [MHz]0 400 1331 330 2202 266 1773 165 85


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.

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

OP0OP1OP2OP3OP4OPn ...


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.

f

idlet

Given Tidle* Compute new

(lower freq)* Start timer for

going up

timertimer


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

Technology

frequency f

operating voltage

driverschange voltage

voltage regulators

given voltage

random frequency

maximum frequency

frequency pol