--- a/Symbian3/PDK/Source/GUID-29B84A67-9DB7-5F4C-A4D1-A3BDC69015A8.dita Fri Jun 11 12:39:03 2010 +0100
+++ b/Symbian3/PDK/Source/GUID-29B84A67-9DB7-5F4C-A4D1-A3BDC69015A8.dita Fri Jun 11 15:24:34 2010 +0100
@@ -1,113 +1,113 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
-<!-- This component and the accompanying materials are made available under the terms of the License
-"Eclipse Public License v1.0" which accompanies this distribution,
-and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
-<!-- Initial Contributors:
- Nokia Corporation - initial contribution.
-Contributors:
--->
-<!DOCTYPE concept
- PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
-<concept id="GUID-29B84A67-9DB7-5F4C-A4D1-A3BDC69015A8" xml:lang="en"><title>Additional
-System Wide Power States</title><shortdesc>A base port can add new power states to improve power management
-for phone hardware. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
-<p>The Kernel defines three system wide power states. A base port can add
-new power states to improve power management for phone hardware. </p>
-<p>The generic system wide power states that are defined are <i>Active</i>, <i>Standby</i> and <i>Off</i>.
-Any additional sub-states of the <i>Active</i> power state must be wholly
-managed by the base port. These states may not need to be declared explicitly
-and may result from peripherals, or groups of peripherals, having moved to
-their low power state (see also <xref href="GUID-1D3E61BD-C09D-51FD-A10B-22392FDAEFEC.dita#GUID-1D3E61BD-C09D-51FD-A10B-22392FDAEFEC/GUID-DCB8EA90-9B5F-5BA1-8D22-124980AC6B34">moving
-to their low power state</xref>). The device will then “trickle“ into one
-of these sub-states instead of transitioning into them as a result of a user
-action or system policy decision. </p>
-<p>Usually, the transition of the system into one of the additional low power
-states happens when the CPU enters the idle mode. The transition may be automatic
-and wholly managed by the ASSP hardware or may result from an action taken
-by the software routine that prepares the CPU to go to idle mode. </p>
-<section id="GUID-22A20CBB-6BF2-495F-B32C-63834DD4624C"><title>Sleeping in idle mode</title> <p>An example of this is when
-the base port uses the idle mode to put the CPU and the device into hardware
-“Sleep” mode similar to that which can be achieved with a transition to <i>Standby</i> mode
-as described in the implementation issues for <xref href="GUID-34D1D0BF-20DE-5677-A067-8FF9DD72E703.dita#GUID-34D1D0BF-20DE-5677-A067-8FF9DD72E703/GUID-1F77C71C-D226-58BB-ABAE-43F958CC0C61">implementing
-DPowerController::PowerDown()</xref> </p> <p>When called, the power controller’s <xref href="GUID-34D1D0BF-20DE-5677-A067-8FF9DD72E703.dita#GUID-34D1D0BF-20DE-5677-A067-8FF9DD72E703/GUID-E2A072D0-A67F-5E6D-81ED-CFD77B6ED4F1">DPowerController::CpuIdle() </xref> implementation
-could take the necessary steps to prepare the CPU and the platform to go to
-“Sleep”. </p> <p>There is a balance between the power savings obtained from
-moving the CPU and platform into “Sleep” mode in Idle and the performance
-hit resulting from spending time restoring the status after coming out of
-“Sleep” mode. Usually the <codeph>CpuIdle()</codeph> routine investigates
-the timer queue (using <xref href="GUID-C54D99AA-FF6E-3023-8260-8F5A88FBFBE0.dita#GUID-C54D99AA-FF6E-3023-8260-8F5A88FBFBE0/GUID-69103F26-2C21-3ECA-9DB5-C31A41F6C238"><apiname>NTimerQ::IdleTime()</apiname></xref>) for the next
-timer expiration and decides to move or not to move the CPU and platform into
-“Sleep” mode based on how much time there is before the next timer expiration.
-The threshold above which it is considered productive to move into “Sleep”
-is dependent on the base port. </p> <p>The decision to move into “Sleep” mode
-may also be based on the current level of activity, or collected metrics on
-the length of time spent in Idle, or other historical information. This can
-be implemented entirely by the base port, or it may require the services of
-an external component (such as, for example, Speed Management). </p> <p>The
-transition to a hardware “Sleep” mode may also depend on shared peripherals
-being in a particular state, for example, no pending requests from other peripherals.
-This means that the power controller may need to check with the peripheral
-driver before initiating the change. The power controller could use the ASSP/Variant
-method to access the resource manager and check the usage of a shared peripheral
-using its <codeph>GetCount()</codeph> API. </p> <p>The decision to move into
-“Sleep” mode could be dependent on a number of peripherals (shared and not
-shared) being in Standby and a number of controllable power resources being
-turned off. Therefore the power controller may also need to check with the
-resource manager (through the Variant or ASSP) for the state of a specific
-set of controllable power resources (using the <codeph>ResourceManager::GetResourceState()</codeph> API). </p> <p>On
-going to “Sleep”, an action or set of actions might need to be taken that
-would affect the whole platform. An example of this is when DRAM is put into
-self-refresh mode on entering the CPU Idle mode after all peripherals that
-might access it (including the LCD controller and DSP) are in low power state.
-Unused DRAM banks may also be powered down. </p> <p>The following diagram
-exemplifies how the evolution of system power would look like on a system
-when the most power saving “Sleep” mode can only be reached – from Idle -
-when Peripherals A, B and C are already in their low power mode. On going
-to the most power saving “Sleep” mode, additional actions can be taken to
-lower the system power level: </p> <fig id="GUID-05ED7A51-E1A1-5D2E-AF81-A11A9EC80D7F">
-<title>System power use over time</title>
-<image href="GUID-BF157EE2-B680-554A-AE32-69C652B61FA6_d0e401620_href.png" placement="inline"/>
-</fig> <ul>
-<li id="GUID-FD4E14B6-9471-5A91-B215-E42595645A94"><p>The system is active
-when a request for service is made on peripheral A; the peripheral driver
-for peripheral A requests its transition to operational state increasing the
-system power requirement (a). </p> </li>
-<li id="GUID-FB7914E6-13BC-57C7-BA02-A7DAA3A4F968"><p>After a period of activity
-related to servicing the request, the system enters the idle thread; in <codeph>CpuIdle()</codeph> the
-time for the next timer expiration is investigated and is found to be long
-enough to send the system to sleep, powering down peripherals A, B and C to
-their low power state and other system resources (b). </p> </li>
-<li id="GUID-44F96E35-4DA5-5A34-8D12-6E99D4B96856"><p>The timer expires and
-the system wakes up to the same power level as before (c). </p> </li>
-<li id="GUID-61124A91-05C6-589D-884B-F4CE5FF9A970"><p>The inactivity timer
-implemented in the peripheral driver for peripheral A expires: the peripheral
-is transitioned to the low power state (d). </p> </li>
-<li id="GUID-1A1BF422-6C3A-5F90-BB8E-E84A31478723"><p>At (e) the system enters
-the idle thread again: the timer queue is investigated and then enters sleep
-mode, waking up again when an interrupt occurs (f). </p> </li>
-<li id="GUID-14C0126F-4333-5A96-93CE-7BBA17A422EF"><p>The inactivity timer
-associated with the peripheral drive for peripheral B expires and the peripheral
-is transitioned to its low power state (g). </p> </li>
-<li id="GUID-3CC1A70B-832A-53EC-BD04-9FA58F58F97D"><p>On the next call to <codeph>CpuIdle()</codeph> the
-time for the next timer expiration is not long enough to power off peripherals
-and other system resources: only limited power savings can be made (h) until
-the system wakes up again (i). </p> </li>
-<li id="GUID-FC9FE747-CF6D-501A-B36F-4776F53E5317"><p>Finally, the inactivity
-timer for peripheral C expires and the peripheral is transitioned to low power
-state (j). On reaching another period of system idle all conditions are met
-to send the system to the deepest sleep mode available accompanied by the
-switching off other power resources (k). </p> </li>
-<li id="GUID-6E283027-9516-50AA-94A7-BEA5C1A1E115"><p>On waking up (l) the
-system resources are restored to the same power level as before. </p> </li>
-</ul> <p>Any transition to and from these low power states must be transparent
-to the rest of the system. A transparent transition is one that can be instantly
-reversed, perhaps automatically in hardware, and has no noticeable impact
-on system performance. In other words, it should be possible to wake the processor
-up and move the entire device to Active Mode as if coming from a “normal”
-Idle Mode. </p> <p>To perform a system wide power change which is not transparent,
-peripherals that may be affected by the transition would need to be examined,
-and interfaces would have to be provided so that the users of these peripherals
-could query the peripheral and allow or disallow the system transition into
-that state. </p> </section>
+<?xml version="1.0" encoding="utf-8"?>
+<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
+<!-- This component and the accompanying materials are made available under the terms of the License
+"Eclipse Public License v1.0" which accompanies this distribution,
+and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
+<!-- Initial Contributors:
+ Nokia Corporation - initial contribution.
+Contributors:
+-->
+<!DOCTYPE concept
+ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
+<concept id="GUID-29B84A67-9DB7-5F4C-A4D1-A3BDC69015A8" xml:lang="en"><title>Additional
+System Wide Power States</title><shortdesc>A base port can add new power states to improve power management
+for phone hardware. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
+<p>The Kernel defines three system wide power states. A base port can add
+new power states to improve power management for phone hardware. </p>
+<p>The generic system wide power states that are defined are <i>Active</i>, <i>Standby</i> and <i>Off</i>.
+Any additional sub-states of the <i>Active</i> power state must be wholly
+managed by the base port. These states may not need to be declared explicitly
+and may result from peripherals, or groups of peripherals, having moved to
+their low power state (see also <xref href="GUID-1D3E61BD-C09D-51FD-A10B-22392FDAEFEC.dita#GUID-1D3E61BD-C09D-51FD-A10B-22392FDAEFEC/GUID-DCB8EA90-9B5F-5BA1-8D22-124980AC6B34">moving
+to their low power state</xref>). The device will then “trickle“ into one
+of these sub-states instead of transitioning into them as a result of a user
+action or system policy decision. </p>
+<p>Usually, the transition of the system into one of the additional low power
+states happens when the CPU enters the idle mode. The transition may be automatic
+and wholly managed by the ASSP hardware or may result from an action taken
+by the software routine that prepares the CPU to go to idle mode. </p>
+<section id="GUID-22A20CBB-6BF2-495F-B32C-63834DD4624C"><title>Sleeping in idle mode</title> <p>An example of this is when
+the base port uses the idle mode to put the CPU and the device into hardware
+“Sleep” mode similar to that which can be achieved with a transition to <i>Standby</i> mode
+as described in the implementation issues for <xref href="GUID-34D1D0BF-20DE-5677-A067-8FF9DD72E703.dita#GUID-34D1D0BF-20DE-5677-A067-8FF9DD72E703/GUID-1F77C71C-D226-58BB-ABAE-43F958CC0C61">implementing
+DPowerController::PowerDown()</xref> </p> <p>When called, the power controller’s <xref href="GUID-34D1D0BF-20DE-5677-A067-8FF9DD72E703.dita#GUID-34D1D0BF-20DE-5677-A067-8FF9DD72E703/GUID-E2A072D0-A67F-5E6D-81ED-CFD77B6ED4F1">DPowerController::CpuIdle() </xref> implementation
+could take the necessary steps to prepare the CPU and the platform to go to
+“Sleep”. </p> <p>There is a balance between the power savings obtained from
+moving the CPU and platform into “Sleep” mode in Idle and the performance
+hit resulting from spending time restoring the status after coming out of
+“Sleep” mode. Usually the <codeph>CpuIdle()</codeph> routine investigates
+the timer queue (using <xref href="GUID-C54D99AA-FF6E-3023-8260-8F5A88FBFBE0.dita#GUID-C54D99AA-FF6E-3023-8260-8F5A88FBFBE0/GUID-69103F26-2C21-3ECA-9DB5-C31A41F6C238"><apiname>NTimerQ::IdleTime()</apiname></xref>) for the next
+timer expiration and decides to move or not to move the CPU and platform into
+“Sleep” mode based on how much time there is before the next timer expiration.
+The threshold above which it is considered productive to move into “Sleep”
+is dependent on the base port. </p> <p>The decision to move into “Sleep” mode
+may also be based on the current level of activity, or collected metrics on
+the length of time spent in Idle, or other historical information. This can
+be implemented entirely by the base port, or it may require the services of
+an external component (such as, for example, Speed Management). </p> <p>The
+transition to a hardware “Sleep” mode may also depend on shared peripherals
+being in a particular state, for example, no pending requests from other peripherals.
+This means that the power controller may need to check with the peripheral
+driver before initiating the change. The power controller could use the ASSP/Variant
+method to access the resource manager and check the usage of a shared peripheral
+using its <codeph>GetCount()</codeph> API. </p> <p>The decision to move into
+“Sleep” mode could be dependent on a number of peripherals (shared and not
+shared) being in Standby and a number of controllable power resources being
+turned off. Therefore the power controller may also need to check with the
+resource manager (through the Variant or ASSP) for the state of a specific
+set of controllable power resources (using the <codeph>ResourceManager::GetResourceState()</codeph> API). </p> <p>On
+going to “Sleep”, an action or set of actions might need to be taken that
+would affect the whole platform. An example of this is when DRAM is put into
+self-refresh mode on entering the CPU Idle mode after all peripherals that
+might access it (including the LCD controller and DSP) are in low power state.
+Unused DRAM banks may also be powered down. </p> <p>The following diagram
+exemplifies how the evolution of system power would look like on a system
+when the most power saving “Sleep” mode can only be reached – from Idle -
+when Peripherals A, B and C are already in their low power mode. On going
+to the most power saving “Sleep” mode, additional actions can be taken to
+lower the system power level: </p> <fig id="GUID-05ED7A51-E1A1-5D2E-AF81-A11A9EC80D7F">
+<title>System power use over time</title>
+<image href="GUID-BF157EE2-B680-554A-AE32-69C652B61FA6_d0e390195_href.png" placement="inline"/>
+</fig> <ul>
+<li id="GUID-FD4E14B6-9471-5A91-B215-E42595645A94"><p>The system is active
+when a request for service is made on peripheral A; the peripheral driver
+for peripheral A requests its transition to operational state increasing the
+system power requirement (a). </p> </li>
+<li id="GUID-FB7914E6-13BC-57C7-BA02-A7DAA3A4F968"><p>After a period of activity
+related to servicing the request, the system enters the idle thread; in <codeph>CpuIdle()</codeph> the
+time for the next timer expiration is investigated and is found to be long
+enough to send the system to sleep, powering down peripherals A, B and C to
+their low power state and other system resources (b). </p> </li>
+<li id="GUID-44F96E35-4DA5-5A34-8D12-6E99D4B96856"><p>The timer expires and
+the system wakes up to the same power level as before (c). </p> </li>
+<li id="GUID-61124A91-05C6-589D-884B-F4CE5FF9A970"><p>The inactivity timer
+implemented in the peripheral driver for peripheral A expires: the peripheral
+is transitioned to the low power state (d). </p> </li>
+<li id="GUID-1A1BF422-6C3A-5F90-BB8E-E84A31478723"><p>At (e) the system enters
+the idle thread again: the timer queue is investigated and then enters sleep
+mode, waking up again when an interrupt occurs (f). </p> </li>
+<li id="GUID-14C0126F-4333-5A96-93CE-7BBA17A422EF"><p>The inactivity timer
+associated with the peripheral drive for peripheral B expires and the peripheral
+is transitioned to its low power state (g). </p> </li>
+<li id="GUID-3CC1A70B-832A-53EC-BD04-9FA58F58F97D"><p>On the next call to <codeph>CpuIdle()</codeph> the
+time for the next timer expiration is not long enough to power off peripherals
+and other system resources: only limited power savings can be made (h) until
+the system wakes up again (i). </p> </li>
+<li id="GUID-FC9FE747-CF6D-501A-B36F-4776F53E5317"><p>Finally, the inactivity
+timer for peripheral C expires and the peripheral is transitioned to low power
+state (j). On reaching another period of system idle all conditions are met
+to send the system to the deepest sleep mode available accompanied by the
+switching off other power resources (k). </p> </li>
+<li id="GUID-6E283027-9516-50AA-94A7-BEA5C1A1E115"><p>On waking up (l) the
+system resources are restored to the same power level as before. </p> </li>
+</ul> <p>Any transition to and from these low power states must be transparent
+to the rest of the system. A transparent transition is one that can be instantly
+reversed, perhaps automatically in hardware, and has no noticeable impact
+on system performance. In other words, it should be possible to wake the processor
+up and move the entire device to Active Mode as if coming from a “normal”
+Idle Mode. </p> <p>To perform a system wide power change which is not transparent,
+peripherals that may be affected by the transition would need to be examined,
+and interfaces would have to be provided so that the users of these peripherals
+could query the peripheral and allow or disallow the system transition into
+that state. </p> </section>
</conbody></concept>
\ No newline at end of file