Power Management for the Nokia Internet Tablets

Power Management for the Nokia Internet Tablets - Presentation Transcript

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.

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 3 Copyright © 2007 Nokia. All rights reserved.

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 4 Copyright © 2007 Nokia. All rights reserved.

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 5 Copyright © 2007 Nokia. All rights reserved.

Dynamic Voltage & Frequency Scaling • 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. 6 Copyright © 2007 Nokia. All rights reserved.

Dynamic Voltage & Frequency Scaling 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 7 Copyright © 2007 Nokia. All rights reserved.

Dynamic Voltage & Frequency Scaling 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 9 Copyright © 2007 Nokia. All rights reserved.

Dynamic Voltage & Frequency Scaling 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 10 Copyright © 2007 Nokia. All rights reserved.

Dynamic Voltage & Frequency Scaling 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 ... 11 Copyright © 2007 Nokia. All rights reserved.

Dynamic Voltage & Frequency Scaling 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 12 Copyright © 2007 Nokia. All rights reserved.

Dynamic Voltage & Frequency Scaling 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 ● 13 Copyright © 2007 Nokia. All rights reserved.

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 15 Copyright © 2007 Nokia. All rights reserved.

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 ● 16 Copyright © 2007 Nokia. All rights reserved.

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); 17 Copyright © 2007 Nokia. All rights reserved.

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 18 Copyright © 2007 Nokia. All rights reserved.

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. 19 Copyright © 2007 Nokia. All rights reserved.

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. 20 Copyright © 2007 Nokia. All rights reserved.

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. 21 Copyright © 2007 Nokia. All rights reserved.

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 22 Copyright © 2007 Nokia. All rights reserved.

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. 23 Copyright © 2007 Nokia. All rights reserved.