|
1 <?xml version="1.0" encoding="utf-8"?> |
|
2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. --> |
|
3 <!-- This component and the accompanying materials are made available under the terms of the License |
|
4 "Eclipse Public License v1.0" which accompanies this distribution, |
|
5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". --> |
|
6 <!-- Initial Contributors: |
|
7 Nokia Corporation - initial contribution. |
|
8 Contributors: |
|
9 --> |
|
10 <!DOCTYPE concept |
|
11 PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> |
|
12 <concept id="GUID-1D3E61BD-C09D-51FD-A10B-22392FDAEFEC" xml:lang="en"><title>Inactivity |
|
13 Monitoring and Peripheral Low Power States</title><shortdesc>Peripheral inactivity can be defined as the state when that peripheral’s |
|
14 driver has no pending request and is not performing background tasks.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody> |
|
15 <p>It is recommended that peripheral drivers monitor peripheral inactivity |
|
16 because they are in the best position to understand the current hardware requirement. </p> |
|
17 <p>The preferred approach is to implement inactivity monitoring in the platform |
|
18 specific portion of peripheral drivers. However it is not always possible |
|
19 to safely do it that way. In this case, an interface between the platform |
|
20 specific and generic portions of the driver might need to be devised leading |
|
21 to, in the future, inactivity monitoring functionality or assistance being |
|
22 included in generic components. </p> |
|
23 <p>In some cases the developer of the driver might decide to implement inactivity |
|
24 monitoring with a grace delay, using timers. For example, consider a peripheral |
|
25 used as a data input device. If the only way that the platform specific layer |
|
26 of the peripheral driver has any knowledge that an input request is pending, |
|
27 and that data is arriving, is when an incoming unit of data causes an interrupt, |
|
28 then the resulting ISR (or deferred DFC) could re-start a timer with a suitable |
|
29 period. Inactivity could be monitored in the timer callback. This guarantees |
|
30 that if another unit of data arrives before the timer expiration, the peripheral |
|
31 is still in its operational power state. </p> |
|
32 <ul> |
|
33 <li id="GUID-D72B1509-0CFD-55D2-B4D3-84A6130AC3C8"><p> <xref href="GUID-1D3E61BD-C09D-51FD-A10B-22392FDAEFEC.dita#GUID-1D3E61BD-C09D-51FD-A10B-22392FDAEFEC/GUID-1817A738-2351-526F-881D-7EB479E93C4C">Peripheral Power States</xref> </p> </li> |
|
34 <li id="GUID-C6CAE535-2406-53FF-85C6-18552831DB94"><p> <xref href="GUID-1D3E61BD-C09D-51FD-A10B-22392FDAEFEC.dita#GUID-1D3E61BD-C09D-51FD-A10B-22392FDAEFEC/GUID-1E31C6B9-6F69-50C5-908A-BCC648D4D8B1">Peripheral standby</xref> </p> </li> |
|
35 <li id="GUID-36E6FC1E-C3E8-5A78-AF77-D54486719BFF"><p> <xref href="GUID-1D3E61BD-C09D-51FD-A10B-22392FDAEFEC.dita#GUID-1D3E61BD-C09D-51FD-A10B-22392FDAEFEC/GUID-DCB8EA90-9B5F-5BA1-8D22-124980AC6B34">Moving peripherals to a low power state</xref> </p> </li> |
|
36 <li id="GUID-927DF4E2-18A3-51B5-9A46-02C63013954C"><p> <xref href="GUID-1D3E61BD-C09D-51FD-A10B-22392FDAEFEC.dita#GUID-1D3E61BD-C09D-51FD-A10B-22392FDAEFEC/GUID-81231D49-0F35-582D-BDB3-DC1A08C2E448">High latency low power states and non-transparent transitions</xref> </p> </li> |
|
37 <li id="GUID-9DC49460-BE85-5979-B52D-DB6AC7E218D5"><p> <xref href="GUID-1D3E61BD-C09D-51FD-A10B-22392FDAEFEC.dita#GUID-1D3E61BD-C09D-51FD-A10B-22392FDAEFEC/GUID-CA1BB80F-5A1C-5B66-8091-84625A0A9CFB">Peripheral power state diagram and transitions</xref> </p> </li> |
|
38 </ul> |
|
39 <section id="GUID-1817A738-2351-526F-881D-7EB479E93C4C"><title>Peripheral |
|
40 Power States</title> <p>It is possible that a particular ASSP allows peripheral |
|
41 hardware blocks to be independently transitioned to a low power state. From |
|
42 the point of view of power consumption, the base port might consider that |
|
43 those peripherals have three logical power states: </p> <ul> |
|
44 <li id="GUID-49BC931A-15BE-5AC3-8F8F-1C3EFBFC0806"><p> <i>Operational Power</i> – |
|
45 the peripheral is either processing some request, or performing a background |
|
46 task with data transactions to or from it, or the peripheral is being kept |
|
47 in this state in anticipation that data will be input to it, and is drawing |
|
48 an amount of power corresponding to one of its possible modes of operation. </p> </li> |
|
49 <li id="GUID-93AA050E-44F7-5B73-A8A2-4F70A2067E42"><p> <i>Low Power</i> – |
|
50 the peripheral is “idling” after a period of inactivity has been detected, |
|
51 drawing a minimal amount of power required to preserve its internal state. |
|
52 The peripheral should be able to keep its internal state and transition from |
|
53 this to the Operational Power state with a negligible delay and with no impact |
|
54 on the performance of either the peripheral driver or the upper layer components |
|
55 that use it. </p> </li> |
|
56 <li id="GUID-8A39F42D-B928-5DE2-B79A-A1EABBF696E4"><p> <i>Off</i> – the peripheral |
|
57 power has been cut off, and only leakage accounts for power consumption. No |
|
58 state is preserved and the delay to a return to full power is not negligible. </p> </li> |
|
59 </ul> <p>Note that peripheral power states are a notion that only applies |
|
60 to the peripheral hardware block, and not to the driver. The peripheral driver |
|
61 is the component that requests the peripheral to transition between these |
|
62 states. </p> <p>Note also that both Operational and Low Power states are subsets |
|
63 of the Peripheral "Active" state. In some cases the differences in power consumption |
|
64 between the Operational and Low Power modes might not be significant as, with |
|
65 some hardware, only part of the peripheral needs to be operational to service |
|
66 a particular type of request. </p> </section> |
|
67 <section id="GUID-1E31C6B9-6F69-50C5-908A-BCC648D4D8B1"><title>Peripheral |
|
68 standby</title> <p>Some ASSPs make provision for a peripheral standby mode, |
|
69 where individual peripherals can be transitioned to a low power consumption |
|
70 mode of operation under software control, usually by writing to an ASIC internal |
|
71 register. </p> <p>If the peripheral is capable of keeping its internal state, |
|
72 and the transition out of this mode is either done automatically on hardware, |
|
73 or controlled by software, but has no impact on the performance of the peripheral |
|
74 driver or on the users of this peripheral, and can be done with negligible |
|
75 delay, then the peripheral standby mode could be considered a low power state |
|
76 as above. </p> </section> |
|
77 <section id="GUID-DCB8EA90-9B5F-5BA1-8D22-124980AC6B34"><title>Moving peripherals |
|
78 to a low power state</title> <p>It is assumed that peripherals can be transitioned |
|
79 between power states under the peripheral driver's software control. However, |
|
80 transitioning peripherals to a low power state should only be performed if |
|
81 it can be done transparently to the users and consumers of the services provided |
|
82 by that peripheral. Negligible interactive delays may be acceptable, data |
|
83 loss is not acceptable. </p> <p>The transition of a peripheral to a low power |
|
84 state can be requested by the platform-dependent layers of that peripheral |
|
85 driver after inactivity, as defined above, has been detected. That request |
|
86 usually assumes the form of a request to turn a controllable power resource |
|
87 off. The request should be handled by the ASSP/Variant component that manages |
|
88 platform power resources (the resource manager). </p> <p>It can also assume |
|
89 the form of an operation required to put the peripheral in standby mode. In |
|
90 this case the peripheral driver is totally responsible for handling the transition |
|
91 to the low power state. </p> </section> |
|
92 <section id="GUID-81231D49-0F35-582D-BDB3-DC1A08C2E448"><title>High latency |
|
93 low power states and non-transparent transitions</title> <p>This guide is |
|
94 only concerned with peripheral low power states that can be reached and left |
|
95 with no impact on system performance. However, it is possible that transitions |
|
96 to and from a peripheral low power state are long enough to have an impact |
|
97 on system performance, or cause loss of data, or the peripheral is not capable |
|
98 of detecting the hardware events required to guarantee correct operation while |
|
99 in a low power state. If this is the case, then the decision to transition |
|
100 to a low power state cannot be taken solely by the peripheral driver, and |
|
101 will have to be taken in agreement with the users and consumers of the services |
|
102 provided by this peripheral. </p> </section> |
|
103 <section id="GUID-CA1BB80F-5A1C-5B66-8091-84625A0A9CFB"><title>Peripheral |
|
104 power state diagram and transitions</title> <fig id="GUID-A1F2E1D2-FA3B-55C3-B7A3-1AECBDC37453"> |
|
105 <title>Peripheral power state diagram</title> |
|
106 <image href="GUID-E55B594F-CC84-5984-9307-9819F6EBEB7F_d0e29647_href.png" placement="inline"/> |
|
107 </fig> <p>It can be assumed that when the peripheral driver is loaded, the |
|
108 peripheral is put into the <i>Low Power</i> state. If a new request is asserted |
|
109 on that peripheral driver from a user of that peripheral (which can include |
|
110 another dependent peripheral driver or user side Engine/server/application), |
|
111 the peripheral should move to its <i>Operational Power</i> state. The driver |
|
112 can then start monitoring for peripheral inactivity, and when that is detected, |
|
113 and no other dependent peripheral is using this peripheral, it can move the |
|
114 peripheral back to the <i>Low Power</i> state. </p> <p>If, however, the power |
|
115 manager requests the driver to power down the peripheral and no other dependent |
|
116 peripheral is using it, it then moves into its <i>Off</i> state from which |
|
117 it can only return to the <i>Operational Power</i> state when the power manager |
|
118 issues a power up request. Moving from the <i>Off</i> state to the <i>Operational |
|
119 Power</i> state is a relatively lengthy operation and requires resetting the |
|
120 internal state of the peripheral. </p> <p>If another dependent peripheral |
|
121 is using this peripheral, and the power manager issues a power down request, |
|
122 then the driver keeps the peripheral in its operational power state until |
|
123 the dependent peripheral relinquishes its request on it. </p> <p>From the <i>Low |
|
124 Power</i> state, a peripheral can also be turned Off (unconditionally) if |
|
125 the power manager so requests. It can be moved back to the <i>Operational |
|
126 Power</i> state on an internal event (Interrupt, Timer). </p> <fig id="GUID-C5AED7DE-18A1-5FBF-B1E4-44067F246CC2"> |
|
127 <title>Peripheral power states</title> |
|
128 <image href="GUID-EFEACBE5-B9E1-5315-88CA-DA3B7C1BFCE0_d0e29694_href.png" placement="inline"/> |
|
129 </fig> </section> |
|
130 </conbody></concept> |