1 <!-- Copyright (C) 2001 Red Hat, Inc. -->
2 <!-- This material may be distributed only subject to the terms -->
3 <!-- and conditions set forth in the Open Publication License, v1.0 -->
4 <!-- or later (the latest version is presently available at -->
5 <!-- http://www.opencontent.org/openpub/). -->
6 <!-- Distribution of substantively modified versions of this -->
7 <!-- document is prohibited without the explicit permission of the -->
8 <!-- copyright holder. -->
9 <!-- Distribution of the work or derivative of the work in any -->
10 <!-- standard (paper) book form is prohibited unless prior -->
11 <!-- permission is obtained from the copyright holder. -->
15 >Changing Power Modes</TITLE
16 ><meta name="MSSmartTagsPreventParsing" content="TRUE">
19 CONTENT="Modular DocBook HTML Stylesheet Version 1.64
22 TITLE="eCos Power Management Support"
23 HREF="services-power.html"><LINK
25 TITLE="Power Management Information"
26 HREF="power-info.html"><LINK
28 TITLE="Support for Policy Modules"
29 HREF="power-policy.html"></HEAD
48 >eCos Power Management Support</TH
56 HREF="power-info.html"
69 HREF="power-policy.html"
80 >Changing Power Modes</A
89 >Changing Power Modes -- reducing or increasing power consumption as needed</DIV
91 CLASS="REFSYNOPSISDIV"
111 CLASS="FUNCSYNOPSISINFO"
112 >#include <cyg/power/power.h></PRE
120 > void power_set_mode
122 >( PowerMode new_mode
129 > void power_set_controller_mode
131 >( PowerController* controller
139 > void power_set_controller_mode_now
141 >( PowerController* controller
152 NAME="POWER-CHANGE-GLOBAL"
155 >Changing the Global Power Mode</H2
157 >The primary functionality supported by the power management package is
158 to change the system's global power mode. This is achieved by calling
163 argument, which should be one of <TT
165 >PowerMode_Active</TT
177 >. Typically this function will only
178 be invoked in certain scenarios:</P
185 >A typical system will contain a policy module which is primarily
186 responsible for initiating power mode changes, and a thread inside the
187 power management package. The policy module will call
191 >, which has the effect of
192 manipulating some internal state in the power management package and
193 waking up its thread. When this thread gets scheduled to run (its
194 priority is controlled by a configuration option), it will iterate
195 over the power controllers and invoke each controller to change its
196 power mode. There is support for a <A
197 HREF="power-policy.html#POWER-POLICY-CALLBACK"
198 >callback function</A
201 HREF="power-attached.html"
203 > power controllers.</P
211 power management thread has had a chance to iterate over all the
212 controllers, or even before the thread has been rescheduled at all,
213 the policy module may decide that a different power mode would be more
214 appropriate for the current situation and calls
218 > again. This has the effect of
219 aborting the previous mode change, followed by the power management
220 thread iterating over the power controllers again for the new mode.</P
224 >If there is no single policy module responsible for power mode
225 changes, any code can call <TT
229 there are multiple calls in quick succession, earlier calls will
230 be aborted and the system should end up in the power mode
231 corresponding to the last call</P
235 >As a special case, it is possible for a power controller to call
239 > when invoked by the power
240 management thread. For example a power controller could decide that it
241 is inappropriate for the system to go to sleep because the device it
242 is associated with is still busy. The effect is as if the policy
243 module had called <TT
247 the mode change had completed.</P
251 >If the power management package has been configured not to use a
252 separate thread then obviously the behaviour is somewhat different.
256 > will now iterate over
257 the various power controllers immediately, rather than leaving this to
258 a separate thread, and the whole mode change completes before
262 > returns. If some other thread or a
267 behaviour of the system is undefined. However, it is still legal for a
268 power controller to call <TT
272 effectively this is a recursive call; it is detected by the system,
273 and internal state is updated; the recursive
277 > call now returns, and when the
278 power controller returns back to the original
282 > call it detects what has happened,
283 aborts the previous mode change, and starts a new mode change as
284 requested by the controller.</P
289 > is normally invoked from thread
290 context. If a separate power management thread is used it can be
291 invoked safely from DSR context. If the system is configured not to
292 use such a thread, it may or may not be safe to invoke this function
293 from DSR context: essentially the function just iterates through
294 the various power controllers, and the documentation or source code of
295 each controller present in the current system will have to be examined
296 to determine whether or not this can happen safely in DSR context.
300 > should never be invoked from
306 NAME="POWER-CHANGE-CONTROLLER"
309 >Manipulating an Individual Power Controller</H2
311 >In some cases it is desirable to set the power mode of an individual
312 controller separately from the mode for the system as a whole. For
313 example if a device is not currently being used then the associated
314 power controller could be set to <TT
318 even while the system as a whole is still active. This can be achieved
319 by calling the function
322 >power_set_controller_mode</TT
324 arguments: the first identifies a particular controller; the second
325 specifies the desired new power mode for that controller. The function
326 operates in much the same way as <TT
330 for example if a separate power management thread is being used then
333 >power_set_controller_mode</TT
335 manipulating some internal state and waking up that thread. The
336 limitations are also much the same as for
343 >power_set_controller_mode</TT
344 > should not be invoked
347 >Manipulating individual controllers is often used in conjunction with
349 HREF="power-attached.html"
352 >power_set_controller_attached</TT
355 allowing the policy module to specify which controllers are affected
356 by global mode changes.</P
361 NAME="POWER-CHANGE-CONTROLLER-NOW"
364 >Direct Manipulation of a Power Controller</H2
366 >In exceptional circumstances it may be necessary to invoke a power
367 controller directly, bypassing the power management thread and
368 higher-level functionality such as <A
369 HREF="power-policy.html#POWER-POLICY-CALLBACK"
370 >callback functions</A
374 >power_set_controller_mode_now</TT
376 this. It takes two arguments, a controller and a mode, just like
379 >power_set_controller_mode</TT
384 >power_set_controller_mode_now</TT
386 dangerous. For example no attempt is made to synchronise with any
387 other power mode changes that might be happening concurrently. A
388 possible use is when the system gets woken up out of
392 > mode: depending on the hardware, on which power
393 controllers are present, and on the application code it may be
394 necessary to wake up some power controllers immediately before the
395 system as a whole is ready to run again.</P
412 HREF="power-info.html"
420 HREF="services-power.html"
428 HREF="power-policy.html"
437 >Power Management Information</TD
447 >Support for Policy Modules</TD