Home | History | Annotate | Download | only in porting
      1 page.title=Power Management
      2 pdk.version=1.0
      3 doc.type=porting
      4 @jd:body
      5 
      6 <a name="toc"/>
      7 <div style="padding:10px">
      8 <a href="#androidPowerIntro">Introduction</a><br/>
      9 <a href="#androidPowerWakeLocks">Wake Locks</a><br/><div style="padding-left:40px">
     10 
     11 <a href="#androidPowerWakeLocksDefinitions">Types of Wake Locks</a><br/>
     12 <a href="#androidPowerWakeLockExample">Exploring a Wake Lock Example</a><br/></div>
     13 <a href="#androidPowerPowerManagerClass">PowerManager class</a><br/>
     14 <a href="#androidPowerKernelRegistration">Registering Drivers with the PM Driver</a><br/>
     15 <a href="#androidPowerEarlySuspend">Early Suspend</a><br/>
     16 </div>
     17 
     18 <a name="androidPowerIntro"></a><h2>Introduction</h2>
     19 
     20 <p>Android supports its own Power Management (on top of the standard Linux Power Management) designed with the premise that the CPU shouldn't consume power if no applications or services require power. For more information regarding standard Linux power management, please see <a href="http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.24.y.git;a=blob;f=Documentation/pm.txt">Linux Power Management Support</a> at <a href="http://kernel.org">http://kernel.org</a>.</p>
     21 <p>Android requires that applications and services request CPU resources with &quot;wake locks&quot; through the Android application framework and native Linux libraries. If there are no active wake locks, Android will shut down the CPU. </p>
     22 <p>The image below illustrates the Android power management architecture. </p>
     23 <p><img src='images/androidPMArchitecture.gif'></p>
     24 
     25 Solid elements represent Android blocks and dashed elements represent partner-specific blocks.
     26 
     27 
     28 
     29 <a name="androidPowerWakeLocks"></a><h2>Wake Locks</h2>
     30 
     31 <p>Wake locks are used by applications and services to request CPU resources.</p>
     32 
     33 <p>A locked wakelock, depending on its type, prevents the system from entering suspend or other low-power states. This document describes how to employ wakelocks. </p>
     34 <p>There are two settings for a wakelock:</p>
     35 <ul>
     36   <li><code>WAKE_LOCK_SUSPEND</code>: prevents a full system suspend. </li>
     37   <li><code></code><code>WAKE_LOCK_IDLE</code>: low-power states, which often cause large interrupt latencies or that disable a set of interrupts, will not be entered from idle until the wakelocks are released. </li>
     38 </ul>
     39 <p>Unless the type is specified, this document refers to wakelocks of type <code>WAKE_LOCK_SUSPEND</code>. </p>
     40 <p>If the suspend operation has already started when locking a wakelock, the system will abort the suspend operation as long it has not already reached the <code>suspend_late</code> stage. This means that locking a wakelock from an interrupt handler or a freezeable thread always works, but if you lock a wakelock from a <code>suspend_late</code> handler, you must also return an error from that handler to abort suspend. You can use wakelocks to allow the user-space to decide which keys should wake the full system and turn on the screen. Use <code>set_irq_wake</code> or a platform-specific API to ensure that the keypad interrupt wakes up the CPU. Once the keypad driver has resumed, the sequence of events can look like this:</p>
     41 <ol>
     42   <li> The Keypad driver receives an interrupt, locks the keypad-scan wakelock,
     43     and starts scanning the keypad matrix. </li>
     44   <li>The keypad-scan code detects a key change and reports it to the input-event
     45     driver. </li>
     46   <li>The input-event driver sees the key change, enqueues an event, and locks
     47     the input-event-queue wakelock. </li>
     48   <li>The keypad-scan code detects that no keys are held and unlocks the
     49     keypad-scan wakelock. </li>
     50   <li>The user-space input-event thread returns from select/poll, locks the
     51     process-input-events wakelock, and calls read in the input-event device. </li>
     52   <li>The input-event driver dequeues the key-event and, since the queue is now
     53     empty, unlocks the input-event-queue wakelock. </li>
     54   <li>The user-space input-event thread returns from read. It determines that the
     55     key should not wake up the full system, releases the process-input-events
     56     wakelock, and calls select or poll. </li>
     57 </ol>
     58 <p>The simple sequence diagram below illustrates these steps:</p>
     59     <pre>
     60      					Key pressed      Key released
     61       					     |		      |
     62       keypad-scan       		     ++++++++++++++++++++++
     63       input-event-queue 			  +++ 		  +++
     64       process-input-events 		            +++ 	    +++
     65       </pre>
     66 
     67 <a name="driverAPI"></a><h3>Driver API</h3>
     68 <p>A driver can use the wakelock API by adding a wakelock variable to its state and calling <code>wake_lock_init</code>, as illustrated in the snippet below:</p>
     69 <pre>
     70   struct state {
     71   struct wakelock wakelock;
     72   }
     73   init() {
     74   wake_lock_init(&amp;state-&gt;wakelock, WAKE_LOCK_SUSPEND, &quot;wakelockname&quot;);
     75   }
     76   Before freeing the memory, wake_lock_destroy must be called:
     77   uninit() {
     78   wake_lock_destroy(&amp;state-&gt;wakelock);
     79   }
     80   </pre>
     81 <p> When the driver determines that it needs to run (usually in an interrupt handler), it calls <code>wake_lock</code>:</p>
     82 <pre>
     83   wake_lock(&amp;state-&gt;wakelock);
     84   </pre>
     85 <p>When it no longer needs to run, it calls <code>wake_unlock</code>:</p>
     86 <pre>
     87   wake_unlock(&amp;state-&gt;wakelock);
     88   </pre>
     89 <p> It can also call <code>wake_lock_timeout</code> to release the wakelock after a delay:</p>
     90 <pre>
     91   wake_lock_timeout(&amp;state-&gt;wakelock, HZ);
     92 </pre>
     93 <p> This works whether or not the wakelock is already held. It is useful if the driver woke up other parts of the system that do not use wakelocks but still need to run. Avoid this when possible, since it will waste power if the timeout is long or may fail to finish needed work if the timeout is short.</p>
     94 <a name="userspaceAPI"></a><h3>User-space API</h3>
     95 <p>Write <code>lockname</code> or <code>lockname timeout</code> to <code>/sys/power/wake_lock</code> lock and, if needed, create a wakelock. The timeout here is specified in nanoseconds. Write <code>lockname</code> to <code>/sys/power/wake_unlock</code> to unlock a user wakelock.</p>
     96 <p> Do not use randomly generated wakelock names as there is no API to free a user-space wakelock.</p>
     97 
     98 <a name="androidPowerWakeLocksDefinitions"></a><h3>Types of Wake Locks</h3>
     99 
    100 <table border=1 cellpadding=2 cellspacing=0>
    101     <tbody><tr>
    102         <th scope="col">Wake Lock </th>
    103         <th scope="col">Description</th>
    104     </tr>
    105     <tr>
    106       <td>ACQUIRE_CAUSES_WAKEUP <br/></td>
    107         <td>Normally wake locks don't actually wake the device, they just cause it to remain on once it's already on. Think of the video player app as the normal behavior. Notifications that pop up and want the device to be on are the exception; use this flag to be like them.</td>
    108     </tr>
    109     <tr>
    110       <td>FULL_WAKE_LOCK</td>
    111       <td>Wake lock that ensures that the screen and keyboard are on at full brightness. </td>
    112     </tr>
    113     <tr>
    114       <td>ON_AFTER_RELEASE</td>
    115       <td>When this wake lock is released, poke the user activity timer so the screen stays on for a little longer.</td>
    116     </tr>
    117     <tr>
    118       <td>PARTIAL_WAKE_LOCK</td>
    119       <td>Wake lock that ensures that the CPU is running. The screen might not be on.</td>
    120     </tr>
    121     <tr>
    122       <td>SCREEN_BRIGHT_WAKE_LOCK</td>
    123       <td>Wake lock that ensures that the screen is on at full brightness; the keyboard backlight will be allowed to go off.</td>
    124     </tr>
    125     <tr>
    126       <td>SCREEN_DIM_WAKE_LOCK</td>
    127       <td>Wake lock that ensures that the screen is on, but the keyboard backlight will be allowed to go off, and the screen backlight will be allowed to go dim.</td>
    128     </tr>
    129 </table>
    130 
    131 
    132 <a name="androidPowerWakeLockExample"></a><h3>Exploring a Wake Lock Example</h3>
    133 
    134 <p>All power management calls follow the same basic format:</p>
    135 <p><ol><li>Acquire handle to the <code>PowerManager</code> service.</li>
    136 <li>Create a wake lock and specify the power management flags for screen, timeout, etc.</li>
    137 <li>Acquire wake lock.</li>
    138 <li>Perform operation (play MP3, open HTML page, etc.).</li>
    139 <li>Release wake lock.</li>
    140 </ol>
    141 </p>
    142 <p>The snippet below illustrates this process.</p>
    143 <pre class="prettify">
    144 PowerManager pm = (PowerManager)mContext.getSystemService(
    145                                           Context.POWER_SERVICE);
    146 PowerManager.WakeLock wl = pm.newWakeLock(
    147                                       PowerManager.SCREEN_DIM_WAKE_LOCK
    148                                       | PowerManager.ON_AFTER_RELEASE,
    149                                       TAG);
    150 wl.acquire();
    151  // ...
    152 wl.release();
    153 </pre>
    154 
    155 
    156 <a name="androidPowerPowerManagerClass"></a><h2>PowerManager class</h2>
    157 
    158 <p>The Android Framework exposes power management to services and applications through the <code>PowerManager</code> class.</p>
    159 <p>User space native libraries (any hardware function in <code>//device/lib/hardware/</code> meant to serve as supporting libraries for Android runtime) should never call into Android Power Management directly (see the image above). Bypassing the power management policy in the Android runtime will destabilize the system.</p>
    160 <p>All calls into Power Management should go through the Android runtime PowerManager APIs.</p>
    161 <p> Please visit 
    162 <a href="http://code.google.com/android/reference/android/os/PowerManager.html">http://code.google.com/android/reference/android/os/PowerManager.html</a> for a description of the API and examples.</p>
    163 
    164 
    165 <a name="androidPowerKernelRegistration"></a><h2>Registering Drivers with the PM Driver</h2>
    166 
    167 <p>You can register Kernel-level drivers with the Android Power Manager driver so that they're notified immediately before power down or after power up. For example, you might set a display driver to completely power down when a request comes in to power down from the user space (see the Android MSM MDDI display driver for a sample implementation).</p>
    168 <p>To register drivers with the Android PM driver, implement call-back handlers and register them with the Android PM, as illustrated in the snippet below:</p>
    169 <pre class="prettify">
    170 android_register_early_suspend(android_early_suspend_t *handler)
    171 android_register_early_resume(android_early_resume_t *handler)
    172 </pre>
    173 <p>It is critical in a drive to return immediately and not wait for anything to happen in the call back.</p>
    174 
    175 
    176 <a name="androidPowerEarlySuspend"></a><h2>Early Suspend</h2>
    177 
    178 <p>The early-suspend API allows drivers to get notified when user-space writes to <code>/sys/power/request_state</code> to indicate that the user visible sleep state should change. Suspend handlers are called in order of low to high (4 - 1 below) and resume handlers are called in order of high to low (1 - 4 below).</p>
    179 <ol>
    180   <li><code>EARLY_SUSPEND_LEVEL_BLANK_SCREEN</code>: </li>
    181   <ul>
    182     <li>on suspend: the screen should be turned off but the framebuffer must still be accessible. </li>
    183     <li>on resume: the screen can be turned back on.</li>
    184   </ul>
    185   <li><code>EARLY_SUSPEND_LEVEL_STOP_DRAWING</code>:
    186     <ul>
    187       <li>on suspend: this level notifies user-space that it should stop accessing the framebuffer and it waits for it to complete.</li>
    188       <li>on resume: it notifies user-space that it should resume screen access. Two methods are provided, console switch or a sysfs interface.</li>
    189     </ul>
    190   </li>
    191   <li><code>EARLY_SUSPEND_LEVEL_DISABLE_FB</code>: Turn off the framebuffer
    192     <ul>
    193       <li>on suspend: turn off the framebuffer</li>
    194       <li>on resume: turn the framebuffer back on. </li>
    195     </ul>
    196   </li>
    197   <li><code>EARLY_SUSPEND_LEVEL_STOP_INPUT</code>:
    198     <ul>
    199       <li>on suspend: turn off input devices that are not capable of wakeup or where wakeup is disabled. </li>
    200       <li>on resume: turn the same devices back on.</li>
    201     </ul>
    202   </li>
    203 </ol>
    204