DPM-mobilinux

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 2 3 7 E A S T A RQU E S A V E NU E , S U NN Y V A L E , CA 94 0 8 5
Mobilinux™ 4.0
Dynamic Power
Management
Programmer’s Guide
1237 East Arques Avenue, Sunnyvale, CA 94085

C O P Y R I G HT
Copyright ©
2005 MontaVista Software, Inc. All Rights Reserved. This product and related
documentation are protected by copyright and distributed under licenses controlling its use,
copying, and distribution. No part of this product or its related documentation may be
reproduced in any form or by any means except under such licenses and this copyright
notice.
MontaVista Software, Inc. makes no representations or warranties with respect to the
contents or use of this manual, and specifically disclaims any express or implied warranties
of merchantability or fitness for any particular purpose.
MontaVista Software, Inc. makes no representations or warranties with respect to
MontaVista®
Linux®
, and specifically disclaims any express or implied warranties of
merchantability or fitness for any particular purpose. MontaVista is a registered trademark of
MontaVista Software, Inc. The registered trademark Linux is used pursuant to a sublicense
from the Linux Mark Institute, the exclusive licensee of Linus Torvalds, owner of the mark
on a world-wide basis. All other names mentioned herein — trademarks, registered
trademarks, and service marks — are the property of their respective owners.
R E V I S I O N H I S T O R Y
This document was prepared by MontaVista Software, Inc.
C O NT AC T
You are welcome to contact us: sales@mvista.com
Edition Version Revision
Documentation
Release Date Notes
.............................................................
Mobilinux 4.0.2 A September 13, 2005 First Release

.....
iii
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.....
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CONTENTS
PREFACE ...............................................................................15
Who Should Read this Manual?................................................................................16
Conventions.................................................................................................................16
Mobilinux 4.0 Documentation Set...........................................................................17
Mobilinux 4.0 Documentation Set Locations ..........................................................17
Other Related MontaVista Documentation .............................................................17
Accessing Online Documentation ...........................................................................18
Accessing man Pages....................................................................................................18
Accessing HTML Man Pages .....................................................................................19
Accessing info Pages....................................................................................................19
Shell Prompts...............................................................................................................20
Using a Bash Shell ........................................................................................................20
Support .........................................................................................................................20
MontaVista Zone..........................................................................................................21
Contact..........................................................................................................................21
Third-Party Documentation......................................................................................21
1 Power Management Background Technology ................1
Background....................................................................................................................2
Power Management Background................................................................................. 2
Why Dynamic Power Management is Needed .......................................................... 2
What is Dynamic Power Management?.....................................................................3
What is an Embedded System?...................................................................................3
What is Embedded Linux?............................................................................................ 4
Dynamic Power Management for Embedded Systems ........................................... 4

iv
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Architectural Summary.................................................................................................4
What is a DPM Policy?.................................................................................................. 5
What is a DPM Power Policy Manager?..................................................................... 5
Dynamic Power Management and Mobile Devices ................................................5
Mobile Devices Conserving Energy ............................................................................ 6
Plugable Power Management Policies......................................................................... 6
2 What is Mobilinux Dynamic Power Management?.........9
What is Mobilinux?.....................................................................................................10
What is Mobilinux Dynamic Power Management? ...............................................10
Mobilinux Dynamic Power Management Benefits................................................10
Mobilinux Dynamic Power Management Features ...............................................11
MontaVista Power Manager .......................................................................................11
DPM Library .................................................................................................................12
Hotplug Agents.............................................................................................................12
Clock Events Tracking ................................................................................................12
Power Profiler Plugin...................................................................................................12
Tick Elimination...........................................................................................................12
High-level Power Manager Interface.........................................................................13
Event Handling.............................................................................................................13
Suspend and Resume Handling..................................................................................13
3 What is MontaVista Power Manager? ...........................15
What is MontaVista Power Manager?......................................................................16
MontaVista Power Manager Features......................................................................16
DPM Interface ..............................................................................................................16
Integrated Components...............................................................................................17
Default Operating Points ............................................................................................17
User-Defined Power Parameters................................................................................17
Default Power Policies.................................................................................................17
Overview of MontaVista Power Manager Tools ...................................................18
Command-Line.............................................................................................................18
Plugin APIs....................................................................................................................18

.....
v
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 MontaVista Power Manager Building Blocks ................19
Operating Points ........................................................................................................20
Operating Points Parameters......................................................................................20
Operating Points Examples ........................................................................................21
Operating Classes........................................................................................................21
Operating States..........................................................................................................22
What is an Operating State?........................................................................................22
Operating States Architecture.....................................................................................22
Operating States Types................................................................................................23
DPM Power Policy.....................................................................................................25
What is a DPM Power Policy?....................................................................................25
Power Policy Architecture...........................................................................................25
5 DPM Device Driver Interfaces .........................................27
DPM Device Driver Background.............................................................................28
DPM Device Constraints Background....................................................................28
How Device Constraints Work..................................................................................28
Device Constraints Features.......................................................................................29
Forced Operating Points............................................................................................29
DPM Classes................................................................................................................30
DPM Driver Scale Callbacks.....................................................................................30
Driver Model and Device Suspend/Resume..........................................................31
6 MontaVista Power Manager Out-of-the-Box ................33
Using Power Manager Out-of-the-Box...................................................................34
Installing Configuration File......................................................................................35
Exiting your Power Manager.....................................................................................35
Power Manager Default Configuration Files..........................................................36
TI-OMAP1710 Board Configuration........................................................................36
Intel PXA27x Mainstone Board Configuration.......................................................37

vi
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 Designing Your Power Manager Building Blocks..........41
Studying Your Hardware’s Power Management Characteristics .........................42
Configuring Your Board..............................................................................................42
Device Power Constraints...........................................................................................42
Guidelines for Setting up DPM Operating Points.................................................42
Designing High-Level Power Management Software Architecture....................43
Designing Power Policy with MontaVista Power Manager...................................44
Designing DPM Suspend/Resume Devices...........................................................44
Specifying Power State Values....................................................................................45
Designing DPM Driver Scale Callbacks..................................................................45
Designing Power-Related Events.............................................................................45
Designing Power Policies ..........................................................................................46
Designing Programmable Sleep/Wakeup Sources ................................................46
Designing DPM Task States......................................................................................47
Designing Sleep/Standby Behavior .........................................................................47
8 Designing Device Interactions with DPM ......................49
Design Considerations ...............................................................................................50
Hardware Restrictions..................................................................................................50
Constraints v.s. Event Messages ................................................................................50
Handeling Conflicting Devices...................................................................................50
Scale Callback................................................................................................................51
Specifying Device Constraints ..................................................................................51
Constraints for an Operating Point ...........................................................................51
Constraints for an Operating Class............................................................................52
Specifying Power Event Userspace Notification...................................................52
Power Hotplug Agents ................................................................................................52
Specifying Device Constraints Interfaces................................................................52
Specifying Constraints through SYSFS.....................................................................53
Asserting Constraints...................................................................................................53
Creating Driver Interface to DPM...........................................................................54
Exporting Driver DPM to Userspace......................................................................55

.....
vii
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9 Implementing Your Power Manager Building Blocks...57
Implementing Power Management for Custom Drivers......................................58
Implementing Precompiled Device Constraints....................................................59
Implementing Driver Scale Callbacks......................................................................59
Implementing Notification of Kernel Power Events............................................60
Developing Your Power Manager............................................................................60
Implementing Notification of Application Power Events...................................61
Implementing DPM Operating Points....................................................................61
Examples........................................................................................................................61
Implementing DPM Operating Classes...................................................................62
Examples........................................................................................................................63
Implementing DPM Operating Policies..................................................................63
Examples........................................................................................................................64
Implementing Policy Manager Handling of Events ..............................................65
Implementing Other Logic for Determining Power Policy.................................66
Implementing Runtime Device Constraints ...........................................................66
Implementing System Suspend/Resume ................................................................67
Event Handling.............................................................................................................67
Suspend and Resume Handling..................................................................................68
Implementing Device Power State Modifications .................................................68
10 Starting Your Power Manager ......................................69
Running Your Power Manager.................................................................................70
Starting Power Manager Manually .............................................................................70
Starting Power Manager Automatically.....................................................................70
Starting Applications with DPM interactions.........................................................70
dpmlib.............................................................................................................................70
/proc...............................................................................................................................71
Testing Your Power Management System..............................................................71
Activating a Policy ......................................................................................................72
Using dpmmgr ..............................................................................................................72
Using sysfs .....................................................................................................................72

viii
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11Power Manager Commands ...........................................73
Power Manager commands Accessibility................................................................74
Commands Syntax........................................................................................................74
Operating Points and Classes Commands..............................................................74
Power Policy Commands...........................................................................................74
Power State Commands.............................................................................................75
Device Power State Commands ...............................................................................75
Device Constraint Commands..................................................................................75
System Status Commands..........................................................................................75
Power Events Commands.........................................................................................76
12Plugin Commands and APIs............................................77
Power Manager Commands Accessibility...............................................................78
Commands Syntax........................................................................................................78
Plugin Commands.......................................................................................................78
Plugin APIs..................................................................................................................79
13Power Manager Profiler Plugin ......................................81
DPM-Profiler Plugin Commands.............................................................................82
Terms Definitions.......................................................................................................83
Power Profile.................................................................................................................83
Power Metric.................................................................................................................83
14 DPM APIs .........................................................................85
libdpm DPM APIs Interface.....................................................................................86
int dpm_init() ................................................................................................................86
int dpm_set_state (char *statename) .........................................................................86
int dpm_create_op (char *opname, char *params).................................................86
int dpm_set_op_param (char *opname, char *paramname, int paramvalue).....87
int dpm_get_op_param (char *opname, char *paramname,
char *buf, size_t bufsiz)...................................................87
int dpm_create_class (char *classname, char *opnames).......................................87

.....
ix
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
int dpm_create_policy (char *policyname, char *opsclasses)................................88
int dpm_set_policy_state_map (char *policyname, char *statename,
char *opclass) .........................................................88
int dpm_get_policy_state_map(char *policyname, char *statename,
char *buf, size_t bufsiz).........................................88
int dpm_set_active_policy (char *policyname)........................................................89
int dpm_get_active_policy (char *buf, size_t bufsiz)..............................................89
sys-dpm APIs Interface..............................................................................................90
sys_dpm .........................................................................................................................90
DPM_INIT ...................................................................................................................92
DPM_TERMINATE ..................................................................................................93
DPM_DISABLE..........................................................................................................95
DPM_ENABLE...........................................................................................................97
DPM_CREATE_OPT................................................................................................98
DPM_CREATE_CLASS..........................................................................................100
DPM_CREATE_POLICY.......................................................................................101
DPM_DESTROY_POLICY ...................................................................................103
DPM_SET_POLICY ................................................................................................106
DPM_GET_POLICY...............................................................................................108
DPM_GET_ALL_POLICIES.................................................................................110
DPM_GET_CLASSES.............................................................................................112
DPM_SET_TASK_STATE.....................................................................................113
DPM_GET_TASK_STATE....................................................................................116
DPM_GET_POLICY_STATS................................................................................118
DPM_GET_CLASS_STATS...................................................................................120
DPM_GET_OPT_ STATS......................................................................................122
DPM_GET_OS_STATS ..........................................................................................124
INDEX..................................................................................133

x
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.....
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PREFACE
Welcome to the Mobilinux 4.0 Dynamic Power Management Programmer’s Guide!
The MontaVista Dynamic Power Management (DPM) feature provides applications and
tools to control power policy for power-conscious Linux-based mobile devices. Additionally,
it enables rapid modifications to power parameters of these systems, such as their CPU, bus
frequency, and core voltage scaling.
The Mobilinux 4.0 Dynamic Power Management Programmer’s Guide provides clear and concise
information about the DPM background technology, MontaVista DPM features, concepts,
out-of-the-box Power Manager, and tasks needed to design and to implement user-defined
power management for two supported software development platforms: TI-OMAP 1710
and Intel PXA27x.
The following topics are covered in Preface:
• “Who Should Read this Manual?”
• “Conventions”
• “Mobilinux 4.0 Documentation Set”
• “Accessing Online Documentation”
• “Shell Prompts”
• “Support”
• “Contact”
• “Third-Party Documentation”

Who Should Read this Manual?
16 Who Should Read this Manual?
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
W H O S H O U LD R E A D T HI S M A N U A L ?
The intended audience for this guide are systems developers able to build embedded
systems using one of the following operating systems:
• Linux
• Microsoft® Windows
C O N V E N T I O N S
The following list contains typographical conventions used throughout this manual:
Convention Meaning Example
..............................................................
Courier Programming code, commands
on-screen output,
tools, applications
Edit your .login file.
Type ls -l to list all files.
machine_name% test.doc.
Bold
Courier
What you type,
File names
machine_name% su
dpmmgr.log
Courier
Italics
Variables to be replace with
actual values
set policy <name>
italics new terms, word to be
emphasized
A forced operating point
..............................................................

.....
Mobilinux 4.0 Documentation Set
Mobilinux 4.0 Documentation Set 17
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
M O BI L I N UX 4 . 0 D O C UM E N T A T I O N S E T
The Mobilinux 4.0 Dynamic Power Management Programmer’s Guide is a companion document to
the following manuals in the Mobilinux documentation set:
• Mobilinux 4.0 Release Notes—Contains open issues and late-breaking product-related
information that are not published in the product manuals.
• Mobilinux 4.0 Installation Guide—Provides step-by-step installation instructions.
• Mobilinux 4.0 Kernel Developer's Guide—Provides information on kernel development and
debugging features and instructions on how to use them.
• Mobilinux 4.0 Development Environment Guide—Defines the MontaVista Software
development environment and provides an overview of the development life cycle.
• Mobilinux 4.0 Kernel Migration Guide—Provides the instructions needed to migrate from
the Linux 2.4 kernel to the 2.6 kernel. It a list of obsolete and upgraded features.
• Mobilinux 4.0 Platform Developer’s Guide—Provides information on how to integrate
system components (file system, kernel, applications) and deploy them to a target
system.
• Mobilinux 4.0 Security Reference Guide—Provides information on locating MontaVista
Security Alerts and provides methods for developing a secure system.
• Mobilinux 4.0 Event Broker Programmer’s Guide—Provides instructions and common error
codes for the MontaVista Linux Event Broker.
MOBILINUX 4.0 DOCUMENTATION SET LOCATIONS
Mobilinux 4.0 online documentation are provided on the product CD in the following
directories:
• /opt/montavista/mobilinux/devkit/<architecture>/<processor>/doc
• /opt/montavista/common/doc
OTHER RELATED MONTAVISTA DOCUMENTATION
MontaVista Web site at http://www.mvista.com as well as “MontaVista Zone” at
http://w.ww.support.mvista.com offer up-to-date information on a variety of topics,
including online product documentation, late-breaking updates, product information,
technical whitepapers, and press coverage.

Accessing Online Documentation
18 Accessing Online Documentation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A C C E S S I N G O N L I N E D O CU M E N T A T I O N
In addition to mobilinux documentation set and other related information available on the
company’s Web site, the following documentation is also available online:
• Manual (man) pages—Help pages that provide a description of the application, its
options and usage, links to related documentation, and a list of known problems.
• Information (info) pages—Online manuals.
Note: If you install mobilinux in a different directory, replace the /opt directory with the
location you choose.
ACCESSING MAN PAGES
Mobilinux 4.0 provides man pages in HTML and in standard ASCII formats, located in the
following directories:
SE TTI NG U P Y OUR M AN P AT H
Before accessing standard man pages, first you must include their location (MANPATH) in
your executable search path. To avoid a conflict with the host man pages, creating an alias
for the mobilinux man pages is recommended.
To create an alias for the mobilinux MANPATH, first open a Bash shell and then enter:
alias mvman=”MANPATH=/opt/montavista/mobilinux/man man”
VIE W ING A SC II MA N PA GE S
To display the ASCII version of the man pages, first open a Bash shell and then enter
mvman <application> to display the first page or enter mvman -a <application> to
display all application man pages.
Application Directory
.............................................................
Target /opt/montavista/mobilinux/devkit/<architecture>/
<processor>/target/usr/share/man
Common /opt/montavista/common/man
Cross-Development /opt/montavista/mobilinux/devkit/<architecture>/
<processor>/man
.............................................................

.....
Accessing Online Documentation
Accessing Online Documentation 19
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ACCESSING HTML MAN PAGES
To access the HTML man pages, enter /opt/montavista/mobilinux/devkit/html/
in a Web browser.
ACCESSING INFO PAGES
The mobilinux application info pages are located in the following directories:
SE TTI NG U P Y OUR I NF OP AT H
Before you can access info pages, you must include their location at INFOPATH into your
executable search path. To avoid a conflict with the host info pages, creating an alias for the
mobilinux info pages is recommended.
To create an alias for the mobilinux INFOPATH, first open a Bash shell and then enter:
alias mvinfo=”INFOPATH=/opt/montavista/mobilinux/info info”
VIE W ING A SC II IN FO PA G ES
To display the ASCII version of the info pages, first open a Bash shell and then enter:
mvinfo <application>
Application Directory
.............................................................
Target /opt/montavista/mobilinux/devkit/<architecture>/
<processor>/target/usr/share/info
Common /opt/montavista/common/info
Cross-Development /opt/montavista/mobilinux/devkit/<architecture>/
<processor>/info
.............................................................

Shell Prompts
20 Shell Prompts
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S H E L L P R O M P T S
The following table shows the default system prompt and superuser prompt for the C shell,
Bourne shell, and Korn shell interfaces:
USING A BASH SHELL
The instructions throughout this manual use a Bash shell terminal window. To open a Bash
shell on a Windows host, open the Start menu and select Programs > MontaVista > Bash
Shell.
S U P P O RT
In-depth technical assistance is available. Customers can request help with installation,
configuration, usage and other questions concerning Mobilinux 4.0. Generally, this software
is fully supported for application developers doing development of their project.
General technical assistance is only provided for third-party products that MontaVista
Software recommends for use with Mobilinux 4.0. This service may range from answering
questions to providing workarounds. Because MontaVista Software is not responsible for
the development of these third-party products, some issues might require input from the
original application vendor. MontaVista only provides assistance for these products when
they are being used with Mobilinux 4.0.
MontaVista Software, Inc. wants your input regarding how well we are performing, as well
as any suggestions or comments that you have for improvement.
Please e-mail comments to suggestions@mvista.com.
Shell Prompt
.............................................................
C shell prompt machine_name%
C shell superuser prompt machine_name#
Bourne shell and Korn shell prompt $
Bourne shell and Korn shell superuser prompt #
.............................................................

.....
Contact
Contact 21
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MONTAVISTA ZONE
MontaVista Zone is the MontaVista Software, Inc. subscriber-only support Web site. It
provides focused information about embedded Linux systems, access to MontaVista
developed software, and provides answers to frequently asked questions (FAQs) about
products and services.
MontaVista Zone is located at http://support.mvista.com.
C O NT AC T
You are welcome to contact MontaVista. For suggestions, please send e-mail to
suggestions@mvista.com. For questions about future availability, what you purchased,
supported targets and so forth, please contact your sales manager or generally you can
e-mail sales@mvista.com. If you purchased a named contact seat, contact information for
MontaVista Technical Support is located under the Contact Support link on MontaVista
Zone. If you cannot see this link, then you purchased a platform developer or application
developer seat and you will need to contact your designated named contact.
T H I RD -P AR T Y DO CU M E N T A T I O N
A variety of Linux, Unix, and Java documentation is currently available. The following list
contains some sources of available third-party documentation:
• O’Reilly Safari—Publishes computer software developer books
(http://safari.oreilly.com/).
• Addison Wesley professional publications—Publishes professional computer books
(http://www.awprofessional.com/).
• Prentice Hall—Publishes academic and reference books
(http://www.awprofessional.com/).
• Wrox—Publishes Programmer-to-programmer books
(http://www.wrox.com/WileyCDA/).
• Online news groups—Provides a forum for computer-focused news groups (for
example, Google, Yahoo, and similar services). For examples of Google news groups,
see http://groups.google.com/.
Note: This list are provided for your convenience only—MontaVista Software does not
specifically endorse them.

Third-Party Documentation
22 Third-Party Documentation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
POWER MANAGEMENT
.....
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BACKGROUND TECHNOLOGY
This chapter provides brief descriptions of the concepts of the Dynamic Power
Management (DPM) background technology in embedded Linux environments that apply
to mobile devices.
Understanding these DPM background technology concepts permits better utilization of
the Mobilinux Dynamic Power Management feature.
The following topics are covered in this chapter:
• “Background”
• “What is Dynamic Power Management?”
• “What is an Embedded System?”
• “Architectural Summary”
• “Dynamic Power Management and Mobile Devices”

POWER M A N A G EM E N T B A C K G R OU N D TE C HN O LOG Y
Background
2 Background
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B AC K G R O U ND
Topics in this section include:
• “Power Management Background”
• “Why Dynamic Power Management is Needed”
POWER MANAGEMENT BACKGROUND
Power management was first introduced in laptop computers to allow longer operating
times while running on battery power; later, it was brought into the desktop PC market.
Many early power management systems had long recovery times, difficult configuration
methods, and low energy savings. Since the early days, however, power management has
improved rapidly, becoming more powerful, reliable, and easier to use. It now delivers
considerably more energy savings.
Power management in personal computers relies on the fact that for most of the time a
typical PC is on, it is not doing anything productive. As long as the computer is idle, energy
use can be reduced without interfering with work. Common methods to reduce energy
usage are slowing down or stopping the processor clock, spinning down the hard disk, and
turning off entire system components such as video, sound cards, or disk controllers.
WHY DYNAMIC POWER MANAGEMENT IS NEEDED
The dynamic power management (DPM) technology provides the ability to reduce energy
consumption by devices when they are not in active use. In addition to the environmental
benefits of reduced energy consumption, power management can improve equipment
reliability by reducing wasted heat.
The DPM technology improves power conservation capabilities based on open source
platforms. It applies to running systems, adjusting power parameters on-the-fly, while
ensuring real-time deadlines of running software are met. These deadlines could be either
hard real-time systems, which guarantees a deterministic response time to an event so that a
late response is considered to be a system failure, or they could be soft real-time systems to
indicate that attempts to minimize event response time and does not consider a late
response as a system failure.

.....
POW ER M A N A G EM E NT BA CK G R O U ND TE C HN OL OG Y
What is Dynamic Power Management?
What is Dynamic Power Management? 3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
W H AT IS DY NA M I C P O W E R M A N AG E M E N T ?
Traditional power management for computer systems focused on regulating the power
consumption in static modes such as sleep and suspend. These are de-activating states, often
requiring a user action to re-activate the system. There are usually significant latencies and
overheads for entering and exiting these states, and in desktop and server systems a
firmware layer typically supports these modes.
Recent advances in processor design techniques have led to the development of systems that
support advances in hardware to scale clocking information such as CPU and core bus
frequencies as well as core voltages with low latency. It enables dynamically adjusting power
management parameters to realize power savings during brief idle periods or execution of
tasks with lower performance and power demands. Since CPU power consumption typically
decreases with the cube of voltage while frequencies scale linearly with voltage, significant
opportunities exist for tuning the power-performance trade-off to the needs of the
application.
Dynamic power management is basically a set of schemes implemented while programs are
running. Many architectures provide the equivalent of a halt instruction that reduces CPU
power during idle periods. The operating system and device drivers can also manage power
of peripheral devices, for example spinning down disks during periods of inactivity. Highly
integrated processors with on-board peripherals often include software-controlled clock
management capabilities to reduce power consumption by inactive peripherals and
peripheral controllers. The memory subsystem also provides a profitable area for dynamic
power management, either through the memory controller implementation or through
software-based schemes.
In support of these dynamic power management strategies, several processors supported by
Mobilinux allow dynamic voltage and frequency scaling of the processor core.
DPM targets the Linux operating system and the characteristics of hardware used for
embedded Linux.

What is an Embedded System?
4 What is an Embedded System?
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
W H A T IS A N E M B E D DE D S Y S T E M ?
Typically, embedded systems perform specific tasks that are stored in the system firmware.
While desktop computers and handheld devices are general-purpose computing devices that
are capable of running software to perform many different tasks, an embedded system is
primarily designed for a specific task, for example a TV controller.
In the past, it was easier to distinguish an embedded system from a general-purpose
computers than it is today. Clearly, the increase in hardware performance and the lower cost
of that hardware has blurred the line between general-purpose computers and embedded
systems.
Embedded systems usually do not have machine abstractions to insulate the operating
system from low-level device and power management activities. In embedded Linux, as in
other operating systems that target battery-powered applications, power management
activities thereby require specific intervention on the part of the operating system kernel and
device drivers. Notice, however, while low-level implementation of dynamic power
management is resident in the operating system kernel, power management strategies and
policies can and do emanate from middleware and user application code.
WHAT IS EMBEDDED LINUX?
Using Linux in embedded system designs enables saving innumerable hours
in creating codes, developing reliable products, and featuring packed,
robust, and quick to market.
DYNAMIC POWER MANAGEMENT FOR EMBEDDED SYSTEMS
The processors mentioned above are highly integrated system-on-a-chip (SOC) processors
designed for embedded applications. The applications of these processors typically do not
include a traditional BIOS, therefore control of the dynamic power state of the system must
be implemented in the operating system.

.....
Architectural Summary
Architectural Summary 5
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A R C H I T E C T U R AL S U M M A R Y
The low-level implementation of the dynamic power management architecture resides in the
kernel of the operating system, whereas the power management strategies come from
outside of the system. Notice that DPM is not a self-contained device driver. The low-level
implementation of DPM requires enhancements at a few key places in the operating system.
A system designer familiar with the characteristics of the embedded system and its special
features and requirements needs to define a complete dynamic power management strategy
for each application in advance. The strategy is communicated to DPM in two ways: as a
predefined set of policies and as an application or policy-set specific policy manager that
manages the policies.
WHAT IS A DPM POLICY?
DPM policies are named data structures. Policies may be defined in such a way that they
exert very fine-grained control over the dynamic state of the system. For this reason, policies
must be installed into the operating system kernel for efficiency. Policies specify the
component and device-state transitions that ensure reliable operations in line with the power
management strategy. The structure of DPM policies and the effects of policies on the
system are covered in Chapter 3, “What is MontaVista Power Manager?” A major
component of the policy mechanism deals with the interaction of device states with policies.
WHAT IS A DPM POWER POLICY MANAGER?
DPM policy managers are executable programs that activate policies by name. Policy
managers implement user-defined and/or application-specific power management
strategies. They can execute either as part of the kernel or in userspace (or both) as required
by the strategy. Policy managers may be very active, responding in real-time to changes in
application power or performance requirements. However, they may be more passive, for
example by changing policies on a longer time scale in response to changes in available
battery power. In fact, DPM supports strategies that do not require any policy manager at
all. Effective strategies for some applications may consist of a single policy installed at
system initialization, perhaps modified by critical applications that interact directly with
DPM.

Dynamic Power Management and Mobile Devices
6 Dynamic Power Management and Mobile Devices
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DYNAMIC POWER MANAGEMENT AND MOBILE DEVICES
Hand-held device makers highlight battery life and power management as key features to
stay competitive in the market. While users perceive results of power management in terms
of battery life, it’s really a combination of CPU capabilities, system software, middleware,
and policy that lets users enjoy their devices for more time between charges or battery
changes.
Any portable device owner notices that the device behaves differently when running on
battery versus on ac power—the screen dims, the processor clock slows, and the system
drifts off to standby or sleep whenever possible after an inactive period.
System behaviors such as standby and sleep leverage native CPU capabilities to reduce
operational voltage and/or clock frequency to save power. What users need to understand is
that in addition to wholesale changes among system-wide states, actual power management
can also be incremental and can occur many hundreds of times each second.
Any DPM strategy begins with scaling the operating voltage and frequency of the one or
more processor cores present in a portable device. Highly integrated processors such as the
Intel PXA27x and the Texas Instrument OMAP family offer dynamic scaling of core
voltage and frequency.
MOBILE DEVICES CONSERVING ENERGY
The overriding power management goal in portable systems is to reduce system-wide energy
consumption. The current generation of embedded processors are so power-efficient that
the processor may no longer be the major energy-consumer in systems that include high-
performance memories and large color displays. Therefore, a dynamic power management
system that is only concerned with voltage and frequency scaling the processor core may be
of limited use. Instead, aggressive power management strategies that encompass the entire
system are needed. For example, scaling bus frequencies can drive significant reductions in
system-wide energy consumption.

.....
Dynamic Power Management and Mobile Devices 7
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PLUGABLE POWER MANAGEMENT POLICIES
The breakdowns of system-wide energy consumption agree that are the most effective way
to manage energy consumption are highly application dependent. Therefore, a dynamic
power management architecture needs to be flexible enough to support multiple platforms
with differing requirements. Part of this flexibility is the requirement to support plug-able
power management policies that allow device manufacturers to specialize policies for their
applications and differentiate their products based on their own unique approaches to power
management. The requirements for simplicity and flexibility are best served by leaving the
workings of the dynamic power management system completely transparent to most tasks.
Where this chapter provided background knowledge on the dynamic power management
technology, the next chapter introduces the MontaVista Dynamic Power Management
feature and provide specifics about it.

8 Dynamic Power Management and Mobile Devices
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
WHAT IS MOBILINUX
.....
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DYNAMIC POWER MANAGEMENT?
The Mobilinux Dynamic Power Management feature provides applications and tools that
enable the users to control power policy for power-conscious Linux-based mobile devices.
Additionally, it allows rapid modifications to power parameters of these systems, such as
their CPU, bus frequencies, and core voltage scaling.
This chapter covers the following topics:
• “What is Mobilinux?”
• “What is Mobilinux Dynamic Power Management?”
• “Mobilinux Dynamic Power Management Benefits”
• “Mobilinux Dynamic Power Management Features”

W H A T I S M OB I LI NUX DY N A M IC POW ER
M A N A G E M EN T ?
10 What is Mobilinux?
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
W H AT IS M O B I L I N UX ?
Mobilinux is an optimized Linux operating system and development environment, ideally
suited for wireless handsets and mobile devices. It is based on a 2.6 kernel and meets the
requirements for power management, hard real-time performance, fast start-up, and small
footprint.
Mobilinux is built to address key areas of development for mobile and wireless devices.
MontaVista Mobilinux along with the Intel PXA27x™ and TI OMAP™ processors
provides wireless devices with flexible and scalable solutions.
Mobilinux enables setting up a power management profile that best meets the requirements
of your device by helping you implement it for maximum performance and lowest cost.
W H AT IS M O B I L I N UX D Y N A M I C P O W E R
M A N AG E M E N T ?
Mobilinux Dynamic Power Management (DPM) provides mechanisms to aggressively
control power policy for Linux-based mobile devices.
Mobilinux DPM feature rapidly scales power parameters such as CPU frequency as the
operating system transitions between idling and running tasks as well as when the system
switches among tasks with different power requirements.
M O BI L I N UX DY N A M I C P O W E R M A N AG E M E N T
B E N E F I T S
Mobilinux DPM feature provides the following benefits:
• Saves on system power by consuming less power during periods of reduced activities.
• Increases system efficiency and frees up system and cooling power capacity by providing
operating system independent power management.
• Provides more power saving options by supporting dynamic power savings modes.
• Protects the environment.
• Conserves energy through increased efficiency in portable devices.

.....
W HA T IS M O B IL INU X DY NA MI C POWE R MA NA G E M EN T ?
Mobilinux Dynamic Power Management Features
Mobilinux Dynamic Power Management Features 11
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
M O BI L I N UX DY N A M I C P O W E R M A N AG E M E N T
F E A T U RE S
The following is a list of features provided by Mobilinux 4.0 Power Management:
• “MontaVista Power Manager”
• “DPM Library”
• “Hotplug Agents”
• “Clock Events Tracking”
• “Power Profiler Plugin”
• “Timer Interrupt Event Reduction”
• “Tick Elimination”
• “Power Manager Interface”
• “High-level Power Manager Interface”
• “Event Handling”
• “Suspend and Resume Handling”
MONTAVISTA POWER MANAGER
The MontaVista Power Manager software provides default operating points and operating
policies for each Mobilinux board, allowing DPM to be used out-of-the-box.
It implements basic DPM policy management and modifies power settings according to
simple heuristics, such as system load. The Power Manager allows for customizing of power
parameters and policy heuristics as well as user-defined suspend and resume scripts for
userspace actions at suspend and resume time.
A plugin is added by creating a shared library that conforms to the Plugin API and by
loading the plugin into the Power Manager through using the load command. This enable
users to add value by adding better power policy management plugins to further extend the
features of the MontaVista Power Manager.
See Chapter 3,“What is MontaVista Power Manager?”

12 Mobilinux Dynamic Power Management Features
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DPM LIBRARY
The DPM library conveniently provides a set of API-based functions that control DPM
through the sysfs interface. Using the sysfs interface, the DPM library provides backward
compatibility for existing sys-dpm-based applications that perform the same functions.
HOTPLUG AGENTS
In a variety of situations it may be useful to communicate information on power
requirements or state changes from the kernel to a userspace Power Manager. For example,
the information may request a system suspend in response to an interrupt received due to a
button press, or the information may communicate device status changes that could lead the
Power Manager to change system power state.
For this reason, DPM provides functions that notify userspace through the Hotplug
mechanism, instead of traditional method of notifying userspace policy handlers of changes
in devices present (along with their associated chores such as downloading firmware for new
devices). Hotplug executes an agent script to perform userspace handling of the power
event.
CLOCK EVENTS TRACKING
The Mobilinux DPM Trace Toolkit Integration feature provides a method that tracks
changes in any clock frequency by DPM. The clock events tracking feature provides a way to
examine the system operating state transitions that DPM invokes.
See Chapter 4, “MontaVista Power Manager Building Blocks.”
POWER PROFILER PLUGIN
The Power Profiler Plugin is provided along with the Power Manager. This plugin is enables
measuring the CPU load and set profiles and DPM policies according to these commands.
See Chapter 4, “MontaVista Power Manager Building Blocks.”
TICK ELIMINATION
The purpose of this feature is to prevent system wake ups for timers that serve no useful
purpose while the system is in sleep or idle mode. This enables longer sleeps and thus more
power savings.

.....
W HA T IS M O B IL INU X DY NA MI C POWE R MA NA G E M EN T ?
Mobilinux Dynamic Power Management Features
Mobilinux Dynamic Power Management Features 13
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The kernel relies on periodic timer interrupts to allow the kernel keep the current time and
date up-to-date, to do accounting, and to see if the software timer service routines should be
called.
Even when the processor is otherwise idle, these interrupts occur and can cause the
processor to be brought out of a power savings mode even though there may not be
anything for it to do other than update the time and go back to sleep.
HIGH-LEVEL POWER MANAGER INTERFACE
Power Manager serves as the preferred DPM interface instead of users directly accessing the
lower-level interfaces. Embedded systems usually do not have BIOS and typically do not
provide machine abstractions to insulate the operating system from low-level device and
power management activities. In operating systems that target battery-powered applications,
power management activities thereby require specific intervention on the part of the
operating system kernel and device drivers. Notice, however, that while low-level
implementation of DPM is resident in the operating system kernel, power management
strategies and policies can and do emanate from middleware and user application code.
EVENT HANDLING
The Power Manager has features that allow power policy to be adjusted in reaction to
various system and device power events.
See Chapter 9, “What is Mobilinux Dynamic Power Management?.”
SUSPEND AND RESUME HANDLING
The Power Manager is able to check the requested (or defaulted) sleep operating state
against device constraints. If not rejected by the previous methods, these user-defined
scripts are executed (if present) before and after the actual system suspend, respectively.
Power managed device drivers continue to receive notifications of system suspend and
resume states.
During an operating system suspend state, the microprocessor will no longer be active. In
theory Power Manager puts all devices into a device power state that is appropriate to an
operating state suspend state. However, it is possible that a suspend system power state
configuration or an application device power requirement not be appropriate for a particular
device.

14 Mobilinux Dynamic Power Management Features
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
WHAT IS
.....
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MONTAVISTA POWER MANAGER?
The MontaVista Power Manager software is the interface to the Mobilinux Dynamic Power
Management (DPM). It provides default operating points and operating policies for each
Mobilinux board, allowing DPM to be used out-of-the-box.
• “What is MontaVista Power Manager?.”
• “MontaVista Power Manager Features.”
• “Overview of MontaVista Power Manager Tools.”

W H A T I S M O N T A VI S T A POWE R MA NA G E R?
What is MontaVista Power Manager?
16 What is MontaVista Power Manager?
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
W H AT IS M O N T A V I S T A P O W E R M A NA G E R ?
The MontaVista Power Manager implements basic DPM policy management and modifies
power settings according to simple heuristics, such as system load.
It allows for customizing of power parameters and policy heuristics as well as user-defined
suspend and resume scripts for userspace actions at suspend and resume time.
MontaVista Power Manager features can be further extended to meet the needs of a
particular system by adding by adding custom power policy management plugins.
When a system sleep or suspend mode is required, the power manager requests the
appropriate mode after executing custom actions necessary to prepare for the suspend,
according to the needs of the particular system.
M O NT AV IS T A P O W E R M A NA G E R F E A T U RE S
The MontaVista Power Manager features the following:
• “DPM Interface”
• “Integrated Components”
• “Default Operating Points”
• “User-Defined Power Parameters”
• “Default Power Policies”
See Chapter 4, “MontaVista Power Manager Building Blocks”
DPM INTERFACE
The new interface for Power Manager is a sysfs interface. It provides an interface that no
longer requires that DPM-aware applications be compiled with board-specific kernel header
files. Knowledge of kernel implementation details are defined in those header files, such as
array indices of power parameters, number of power parameters, operating state numeric
identifiers, and so on.

.....
W HA T I S M O N TA V I S T A POWE R M A N A G ER ?
MontaVista Power Manager Features
MontaVista Power Manager Features 17
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
INTEGRATED COMPONENTS
Power Manager integrates the various components involved in a power management system,
such as kernel drivers and power-aware application, into a framework that users can use for
their products.
DEFAULT OPERATING POINTS
Power Manager provides default operating points and policies for each Mobilinux supported
board, allowing DPM to be used out-of-the-box. DPM runs the system at a certain
operating point at any given time, chosen from a set of possible operating points according
to rules set by the system designer.
USER-DEFINED POWER PARAMETERS
The DPM implementation for a platform is based on information from the silicon or board
vendor describing the available power parameters and operating points that have been
validated to operate successfully on the platform. MontaVista can then support DPM
software modification of these power parameters and can support DPM running at the
validated operating points.
Power Manager allows for customer extensions to power parameters and policy switching
heuristics, as well as customer-written suspend and resume scripts for userspace actions at
suspend and resume time.
DEFAULT POWER POLICIES
Power management policies or schemes are used to make decisions on the state of operation
of electronic systems such as portable devices.
Dynamic power management schemes or policies can be used to control the power
consumption levels of electronic systems, by setting their components in different states,
where each is characterized by a performance level and a power consumption. The power
consumption can be formulated as an optimization problem called policy optimization. It
enables basic DPM policy management, switching power settings according to simple
heuristics, for example, switching to a higher performance level when system load increases.

W H A T I S M O N T A VI S T A POWE R MA NA G E R?
Overview of MontaVista Power Manager Tools
18 Overview of MontaVista Power Manager Tools
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OVERVIEW OF MONTAVISTA POWER MANAGER TOOLS
The following tools allow for modifications to Power Manager.
COMMAND-LINE
Power Manager reads commands from any source, including the following:
• Configuration file selected by the startup script by default.
• Another dpmmgr invoked by the command-line parameters.
• FIFO /tmp/dpmmgr.fifo at runtime to receive commands from applications and
kernel event messages, such as from power hotplug scripts.
• Plugins through plugin API function calls.
The command line may consist of several dpmmgr commands that are separated by
semicolons ";".
A number of commands refer to devices by using the syntax bus/device, where bus is a
string comprised of a sysfs bus name, and devices is a sysfs device name. For example,
platform/omap1710 refers to the device named omap1710 on the platform bus.
See Chapter 11, “Power Manager Commands.”
The Power Manager enables the users to add value by adding plugins that extend the
features of the base policy manager.
The dpm-profiler plugin can measure the CPU load and set the profiles and DPM policies
according to these commands.
See Chapter 13, “Power Manager Profiler Plugin.”
PLUGIN APIS
Plugins can be added by creating a shared library that conforms to the Plugin APIs and by
loading the plugin into the policy manager using the load command.
The Power Manager Plugin API includes callbacks or functions that are called by dpmmgr
into the plugin.
See Chapter 12, “Plugin Commands and APIs.”

19
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
.....
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BUILDING BLOCKS
Mobilinux Dynamic Power Manager (DPM) responds with low latency to the system
workload and environment by dynamically adjusting system operating parameters to balance
system performance and power consumption, without requiring user interactions.
The key to design a power efficient DPM is to implement a power manager policy that
meets the needs of your system. This requires understanding your overall power
management goals, the CPU execution states of your system, and the available power want
DPM to manage.
MontaVista Power Manger allows you to design a power policy that is specific to your
development platform by building the following components:
• “Operating Points”
• “Operating Classes”
• “Operating States”
• “DPM Power Policy”
Note: This chapter explains the concepts of each of these building blocks. See Chapter 8,
“Designing Device Interactions with DPM,” for specific instructions for building these
blocks.

M ON T A VI S TA POWER M A N A G ER B U I LD IN G B L OC K S
Operating Points
20 Operating Points
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
O P E RA T I N G P O I N T S
A system executes at a particular operating point at any given point in time. The operating
point, in turn, can be described by such parameters as the core voltage, CPU and bus
frequencies, and the states of peripheral devices.
A dynamic power management system is defined as a set of rules and procedures that move
the system from one operating point to another as events occur.
Selecting appropriate operating points has a critical impact on system energy consumption.
Additionally, modern voltage and frequency scalable systems support multiple operating
points.
Operating points are the lowest-level objects in the DPM system hierarchy. An operating
point object encapsulates the minimal set of inter-dependent, physical, and discrete
parameters that define a specific system performance level along with its associated energy
cost. A good example of inter-dependency is the relationship between voltage and frequency
of a CPU core. The core voltage limits the maximum operating frequency of a voltage-
scalable CPU, while the frequency of the processor cannot be considered without also
considering the voltage.
Operating points, by nature, are processor- and system-dependent. The system designer is
responsible for defining as many operating points as are necessary to satisfy the power
management need of the application, such as core voltage levels, CPU and bus frequencies,
memory timing parameters, and other clocking related data.
Note: For a complete list of the default operating points provided for your board see the
chapter specific to your supported platform in this manual.
OPERATING POINTS PARAMETERS
For a list of power parameters used by operating points see the DPM header files. Any value
associated with each parameter in these files is an integer. You can modify or adjust each
parameter for your specific platform; however, you must make your modifications according
to the rules specified by the manufacturer of your board.

.....
M ON T A VI S TA POWER M A N A G E R B U I LD IN G B L OC K S
Operating Classes
Operating Classes 21
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OPERATING POINTS EXAMPLES
An operating point is a specific set of values of the hardware operating parameters. Each
operating point is labeled with a name. The following table provides an example of four
operating points for a theoretical system:
O P E RA T I N G CL A S S E S
An operating class is a set of operating points. Operating point classes allow DPM to
automatically choose an appropriate operating point from among a list of available operating
points, according to the constraints set by drivers. Constraints describe the required
relationships between the hardware operating parameters. For example, for a network
adapter to function properly, it may require that the frequency of the IO bus, to which it is
attached, be greater than 10 Mhz. To learn more about device constraints, see Chapter 5,
“DPM Device Driver Interfaces.”
An example of an operating class may be a class that offers a choice of a lower power
operating point or a higher power operating point, allowing the lower power operating point
to be set if no drivers have asserted a constraint disallowing the lower power operating
point.
A power policy can map an operating state to a single operating point, or it can map an
operating state to a class that contain multiple operating points. When switching operating
points to match a change in operating state, DPM will choose the first operating point in the
class that is allowed under the current device constraints.
For example, the following shows how to create an operating class using the sysfs interface:
create class-name op-name op-name... > /sys/dpm/class/control
The variable class-name must be unique among other classes and operating points.
Operating
Point Voltage Processor
Clock
Processor
Clock Bus
I/O Bus
Clock
................................... ......................fast_cpu 5000 mV 400 Mhz 200 Mhz 100 Mhz
slow_cpu 5000 mV 100 Mhz 50 Mhz 100 Mhz
med_cpu 5000 mV 50 Mhz 25 Mhz 100 Mhz
Sleep 0 mV 0 Mhz 0 Mhz 0 Mhz
................................... ......................

Operating States
22 Operating States
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Each op-name is the name of an operating point within the class. The order of names is
significant. When choosing an operating point from the class, DPM will evaluate each
operating point in left-to-right order, choosing the first operating point that meets the
current constraints.
The variable class-name is specified in a policy to map an operating state to the class.
O P E RA T I N G S T A T E S
Operating states are CPU execution states that are triggered by the scheduler when
performing a context switch, other kernel-specific actions (such as entering the idle loop), or
an explicit command using a DPM API.
WHAT IS AN OPERATING STATE?
The concept of the operating state was first introduced by observing that significant system-
wide energy savings can be achieved by reducing CPU and bus frequencies and core voltage
while the system is in idle state. Therefore a mechanism was required to specify a different
operating point during the time that programs are executing, versus the times that the
system is idle. This led to a distinction between an active state and an idle state, each with a
potentially different operating point. The transition from the active state operating point to
an idle state operating point and back is smoothly and efficiently managed by the DPM
implementation in the operating system.
OPERATING STATES ARCHITECTURE
The concept of an operating state applies to task-specific operating points for power-aware
tasks. This requires multiple task-specific active states or task states. The DPM architecture
allows for any number of task states. The default task state is expected to be used by the
large majority of tasks, analogous to the way that most tasks now use the default scheduling
policy of the operating system. Tasks with special requirements may specify how to run in
different task states, each of which may be associated with a different operating point.
Note: Tasks never explicitly specify an operating point. Instead, the operating point is
implied by the task state and the current policy.

.....
Operating States
Operating States 23
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operating states also appear in the DPM policy architecture. Conceptually, a DPM policy
simply associates an operating point with each of the system operating states. Changing to a
new DPM policy simply changes the association.
The operating state is an abstraction that software uses to request a specific level of system
performance. The system’s current operating state is set from each process’ operating state
when the process is active.
The default operating state of each process is inherited from its parent. A process’ operating
state can be changed using a DPM API.
The board-specific implementation portion of DPM can alter the system’s current operating
state while kernel code is executing. For example, the kernel idle loop code might set the
system’s current operating state to idle while there is no task that is ready to be executed.
OPERATING STATES TYPES
In general, DPM defines the following three basic operating states for kernel use:
• DPM_SLEEP_STATE
• DPM_IDLE_STATE
• DPM_DPM_TASK_STATE
SL E EP
The sleep operating state instructs DPM to suspend the system to a low-power sleep or
standby state.
When DPM enters the sleep operating state, the following actions take place:
1 The device suspend() function is invoked for each device, saving device state
for later resume, and placing the device in a low-power state.
2 Other board-specific actions, such as to place SDRAM in auto refresh mode,
may occur.
3 The CPU in placed in a low-power mode selected by the operating point
parameters.
When the system is resumed due to receipt of a wake-up event, the following actions take
place:

Operating States
24 Operating States
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 The CPU comes out of sleep/standby mode and resumes execution.
2 Other board-specific actions may occur, such as to take SDRAM out of auto
refresh mode.
3 The operating state changes to DPM_TASK_STATE.
4 The device resume() function is invoked for each device in order to restore
state and power up the device.
ID LE
The idle operating state is entered whenever the Linux scheduler executes the idle loop. The
idle loop typically executes a wait-for-interrupt instruction that will temporarily halt
processor execution cause kernel execution to resume upon receipt of the next interrupt.
There may also be other actions performed by the idle loop for your board, such as to place
SDRAM into self-refresh state. The DPM operating point selected for the idle operating
state may modify additional power parameters for reduced power consumption during idle
periods, such as to reduce the frequency of clocks.
TA SK
The task state function is the default operating state for all processes. DPM by default
supports nine task states. The following list displays the names of all of the default task
states:
• task-4
• task-3
• task-2
• task-1
• task
• task+1
• task+2
• task+3
• task+4
Applications can either be assigned a task state by the policy manager or can set their own
task state directly. In both cases use the DPM API calls, see Chapter 12, “Plugin Commands
and APIs.”

.....
DPM Power Policy
DPM Power Policy 25
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DP M P O W E R P O L I C Y
The DPM Power Policy is the highest-level abstraction of the DPM architecture. A DPM
Power Policy is a named data structure, which is installed into the DPM implementation in
the operating system and is managed by the Power Manager that resides outside of the
operating system. Once a DPM system is initialized and activated, the system will always be
executing under a particular DPM policy.
WHAT IS A DPM POWER POLICY?
A policy is a mapping of an operating state or class invoked for each operating state. For
example, a low-battery-strength policy might map all operating states to low power
operating points. Or, a high-battery-strength policy might map a task operating state used by
interactive processes to a high power operating point, a task operating state used by
background processes to a medium power operating point, and an operating state used by
the kernel idle loop to a low power and low wake up latency operating point.
POWER POLICY ARCHITECTURE
The highest-level abstraction of the DPM architecture is the Power Policy, which maps each
operating state to an operating point or a harmonized class of operating point. A power
management strategy specifies at least one policy and may specify as many different policies
as are necessary for different scenarios. The policy in effect at any given point in time
controls the operating point of the system in every operating state.
The DPM architecture does not require the presence of any operating states other than a
single task state common to all platforms. The number of task states may vary from
platform to platform, however on all platforms the task states are only given meaning by the
policies and Power Manager.
If multiple policies are needed, then Power Manager needs to coordinate the activation of
different policies at different times. Power Manager may collect information from the
operating system, user preferences, running programs, configuration files and physical
devices to make its policy decisions. The location of the policy manager (kernel space or
userspace), the types of information required, and all of the actions taken in response to that
information are not specified. The intention of this architecture is simply to define a
consistent way for policy developers to express policies that are controlled by the policy
manager and implemented by DPM.

DPM Power Policy
26 DPM Power Policy
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
.....
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DPM DEVICE DRIVER INTERFACES
Ideally, a power management system would be entirely transparent to as many levels of the
software stack as possible. Developers experienced in building handheld devices believe that
some degree of explicit participation is required across the system, including the kernel and
driver interfaces.
In the DPM architecture for Linux, the DPM subsystem within the kernel maintains the
system’s power state and ties together the various power-managed elements of a DPM
system. DPM serves as a service provider to drivers, middleware, and applications.
• “DPM Device Driver Background”
• “DPM Device Constraints Background”
• “Forced Operating Points”
• “DPM Classes”
• “DPM Driver Scale Callbacks”
• “Driver Model and Device Suspend/Resume”

DP M D EV I C E DR IVE R IN T ER F AC ES
DPM Device Driver Background
28 DPM Device Driver Background
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DP M D E V I CE DR IVER B A CK GR OU N D
The automatic selection of operating points as devices change state is a central feature of
DPM. Embedded systems may not have a BIOS or machine abstraction layer to insulate the
operating system from low-level device and power management. Therefore, this task falls to
the operating system and its device drivers. As the complexity of embedded systems increases
and the interrelationships between clock sources and power management modes become
more complex, this becomes an increasingly difficult task.
Under the DPM abstraction, the system designer needs to design the power management
system by pre-selecting sets of meaningful operating points for the application and
organizing these operating points within power management policies that are suitable for
the application.
DP M D E V I CE CO N S T R AI N T S B A C K G RO UN D
Device constraints allow drivers to control entry to DPM operating points. Constraints
restrict entry to operating points that are incompatible with correct operation of devices.
The appropriate device constraints to use, and the consequences of violating these
constraints, is determined by the characteristics of the hardware platform.
Constraints may also restrict DPM operations in ways considered useful by the system
designer, such as allowing DPM to transition to a low-power idle mode only if a set of
devices are not in use, regardless of whether or not the underlying hardware is capable of
operating the devices in that mode.
HOW DEVICE CONSTRAINTS WORK
The manner in which DPM interprets constraints depends on the way the current DPM
policy is defined. DPM policies can map a system operating state to a specific DPM
operating point or to a DPM class of operating points.
Devices specify their requirements as sets of constraints associated with particular device
states. For example, an LCD controller might specify a pixel clock in the range of 16 to 25
MHz while active and no constraint while inactive. When devices change state, and their
requirements for system resources change, these requirements are communicated to DPM.
Simple rules are defined to invalidate inappropriate operating points and to automatically

.....
DP M D EV I C E D R IVE R IN T ER F A CE S
Forced Operating Points
Forced Operating Points 29
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
select one of possibly several valid operating points from the operating classes under the
new constraints.
This mechanism frees the policy manager to focus on high-level management, while
ensuring that the system always operates at the best operating point, as defined by the
system designer, consistent with the current policy and device states.
This mechanism also supports systems that include simple policy managers, or that do not
implement any run-time DPM policy management at all. The system designer may be able
to describe a suitable dynamic power management strategy using only a single DPM policy,
based on operating point operating classes that anticipate the significant states of peripheral
devices with regard to power management.
To design DPM operating classes, see Chapter 8, “Designing Device Interactions with
DPM.”
DEVICE CONSTRAINTS FEATURES
DPM checks device constraints and either chooses an operating point from an operating
class that does not violate the constraints, or it blocks transition to any new operating point
if there is no operating point that does not violates those constraints.
The following are some of the features of the constraints interfaces:
• Writing a constraint with the same power parameter ID as an existing constraint
overwrites the previous constraint with the new settings.
• Power parameter with the minimum or maximum value -1 means no constraint.
• Existing constraints can be removed using this syntax.
• Reading the device sysfs constraints attribute returns more information, including
asserted=yes/no status, as well as the number of times an operating point was rejected
due to this constraint.
F O R CE D O P E R A T I N G P O I N T S
A forced operating point may be set even if device constraints would normally disallow it.
Devices with constraints incompatible with the operating point are first suspended before
the operating point is set.

DPM Classes
30 DPM Classes
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
This feature is implemented as a per-operating point attribute, named force. The force
attribute is only supported for sleep operating points, that is, operating points that place the
system into a low-power sleep, suspend, or standby state. Force flag handling is
implemented by Power Manager.
If you are implementing your own power policy manager and want to have similar
functionality, then you may implement the code to check the force attribute and power
down the affected devices in your power policy manager.
D P M C L A S S E S
DPM classes are fully supported in Mobilinux and may contain more than one operating
point. DPM classes allow DPM to automatically choose an appropriate operating point
from among a choice of several operating points, according to the constraints set by drivers.
For example, a class may offer a choice of a lower power operating point or a higher power
operating point, allowing the lower power operating point to be set if no drivers have
asserted a constraint disallowing the lower power operating point.
In Mobilinux, a DPM policy can map an operating state to a single operating point, or it can
map an operating state to a class containing multiple operating points.
D P M D R I V E R S C A LE C A L L B A C K S
DPM-enabled device drivers are more stateful than default drivers. They are driven through
various states by external events and through callbacks from the kernel DPM subsystem to
reflect operational policies.
Mobilinux DPM has the capability to call drivers when scaling clock frequencies. This
enables drivers to react to any necessary change on all platforms. This is done using the scale
driver callback.

.....
DP M D EV I C E D R IVE R IN T ER F A CE S
Driver Model and Device Suspend/Resume
Driver Model and Device Suspend/Resume 31
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DR I V E R M O D E L A ND D E V I C E S U S P E N D /R E S U M E
The device suspend and resume features associated with DPM are a standard part of the 2.6
kernel on which Mobilinux is based. The 2.6 code typically registers such devices as platform
devices on the built-in platform bus. This avoids the need to issue separate LDM registration
or deregistration calls for each platform that supports a particular driver.
The platform bus uses the following sequence:
suspend: 1. SUSPEND_DISABLE; 2. SUSPEND_SAVE_STATE; 3. SUSPEND_POWER_DOWN
resume: 1. RESUME_POWER_ON; 2. RESUME_RESTORE_STATE; 3. RESUME_ENABLE
Depending on the particulars of the platform, the suspend mode requested, and the device
driver, all 3 levels may or may not be useful, and some may be ignored if not useful.

Driver Model and Device Suspend/Resume
32 Driver Model and Device Suspend/Resume
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
.....
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OUT-OF-THE-BOX
MontaVista Power Manager provides configuration files that are specific to each supported
development platform board.
This chapter provides lists of default operating points and policies as well as configurations
for each supported board, as follows:
• “Using Power Manager Out-of-the-Box”
• “Installing Configuration File”
• “Exiting From your Power Manager”
• “Power Manager Default Configuration Files”

M ON T A VI S TA POWER M A N A G ER O U T -OF -T H E-B OX
Using Power Manager Out-of-the-Box
34 Using Power Manager Out-of-the-Box
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
US I NG P O W E R M A N AG E R O U T - O F -T H E - BO X
MontaVista provides system startup scripts to start and stop the MontaVista Power
Manager, dpmmgr. These scripts pass the board-specific configuration file at
/lib/modules/$(uname -r)/dpmmgr.conf to dpmmgr, where $(uname -r) is the
release number of the Linux kernel and Mobilinux product.
The following shows the syntax to dpmmgr:
dpmmgr [options] [command-line]
where [options] are,
-f <file> set configuration file
-v verbose debugging info
-l enable logging
-d run as a daemon
Note: -l saves information in /var/log/dpmmgr.log file.
[command-line] is a command line to send to the Power Manager, which must have
been previously started. dpmmgr sends the command-line to the Power Manager and exits,
providing a convenient way to execute dpmmgr commands on-the-fly.
You may want to setup both a high-power and low-power policy specific to your board,
assuming reasonable operating points for higher-power and lower-power that are still
running are known for the board. You may also choose an operating point for the idle state
if an appropriate low-power operating point with low latency to enter and exit is known for
the board.
As part of the installation of MontaVista Power Manager, the dpm-profiler will also be
installed by default. See Chapter 13, “Plugin Commands and APIs.”

.....
M ON T A VI S TA POWER M A N A G ER O U T- OF -T HE -B OX
Installing Configuration File
Installing Configuration File 35
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I N S T A L LI N G CO N F I G U R A T I O N F I LE
During the installation of Mobilinux, the dpmmgr.conf file specific to your board will be
installed as well.
1 After installing your LSP, you may you may start MontaVista Power Manager as
shown below:
/var/log/dpmmgr -v “status”
2 Check the output in dpmmgr.log file if logging is enabled to see any messages
logged during Power Manager startup.
/etc/init.d/dpmmgr.log start
Initialized from configuration file:
/lib/modules/2.6.10_mobilinux402-mainstone_pxa27x/dpmmgr.conf
Poll interval: 3 seconds.
Plugins loaded: dpm-profiler
load-scale: active profile is "battery-hi".
load-scale: power metric is 0 => "set policy lo-power".
E X I T I NG F RO M Y O UR P O W E R M A N AG E R
To exist from your MontaVista Power Manager enter the following command:
dpmmgr -v "exit"
dpmmgr shut down 04 Jan 1970 05:34

Power Manager Default Configuration Files
36 Power Manager Default Configuration Files
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
P O W E R M A NA G E R DE F AU L T C O N FI G U R AT IO N F I L E S
This section provides the default configuration files for each one of the supported
development platform provided by MontaVista.
Note: Check the MontaVista Zone for the latest changes to the default configuration files.
TI-OMAP1710 BOARD CONFIGURATION
The following is the MontaVista Power Manager configuration for the TI-OMAP1710 H3
development platform board.
Note: Please refer to the TI-supplied documentation for your board and processor model
to verify the operating points supported on your hardware.
load /usr/lib/dpm-profiler.so
Specifies operating points to run the CPU at 192, 168, 84, and 60 MHz,
respectively.
op 192dpll-mult=16 dpll-div=1 arm-div=1 tc-div=2
Specifies operating points to place the 168 and 60 MHz CPU system into
Sleep mode, respectively.
op sleep-168 dpll-mult=14 dpll-div=1 arm-div=0
op sleep-60 dpll-mult=1 dpll-div=2 arm-div=0 tc-div=2
Defines hi-power policies for the above system.
policy hi-power idle, idle-task,task,task+1,task+2,task+3,task+4=192
policy hi-power task-1,task-2,task-3,task-4=168 sleep=sleep-168
Defines low-power policies for the above system.
policy lo-power idle, idle-task, task, task-1,task-2,task-3,task-4=60
policy lo-power task+1,task+2,task+3,task+4=84 sleep=sleep-60
Configuration plugin to increase the power by 50 when CPU at 50%
utilization.
tell dpm-profiler cpu 50% +50
Configuration plugin to specify battery-hi profile to lo-power or hi-power
policy depending on the given value of 0 or 50, respectively.

.....
Power Manager Default Configuration Files 37
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tell dpm-profiler profile battery-hi at 0 set policy lo-power
tell dpm-profiler profile battery-hi at 50 set policy hi-power
Configuration plugin to specify battery-low profile to lo-power or hi-
power policy depending on the given value of 0 or 90, respectively.
tell dpm-profiler profile battery-lo at 0 set policy lo-power
tell dpm-profiler profile battery-lo at 90 set policy hi-power
Configuration plugin to activate the battery-hi profile which will remain
in effect until it is overridden by another set profile command.
tell dpm-profiler set profile battery-hi
Command to report a status summary to stdout.
status
INTEL PXA27X MAINSTONE BOARD CONFIGURATION
The following is the MontaVista Power Manager configuration for the Intel PXA27x
Mainstone II development platform.
Note: Please refer to the Intel-supplied documentation for your board and processor model
to verify the operating points supported on your hardware.
load /usr/lib/dpm-profiler.so
Specifies operating points to run the CPU at 104, 208, and 312 MHz.
op 104mhz v=900 l=8 n=2 b=1 half_turbo=0 cccra=1 cpll-on=1 ppll-on=1
sleep_mode=0
sleep_mode=0
sleep_mode=0
Specifies operating points to put the system into Sleep, Deep Sleep, and
Standby mode, respectively:
# Sleep Mode
op sleep v=1500 l=0 n=0 b=0 half_turbo=-1 cccra=0 cpll-on=0
ppll-on=0 sleep_mode=3
# Deep Sleep Mode
op dsleep v=1500 l=0 n=0 b=0 half_turbo=-1 cccra=0 cpll-on=0

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
# Standby Mode
op stndby v=1500 l=0 n=0 b=0 half_turbo=-1 cccra=0 cpll-on=0
Specifies operating points to put the system into the Sleep mode, where
the second statement enables the Peripheral PLL.
# 13m
op 13m v=1500 l=1 n=2 b=0 half_turbo=0 cccra=0 cpll-on=0
ppll-on=0 sleep_mode=-1
# 13mext
op 13mext v=1500 l=1 n=2 b=0 half_turbo=0 cccra=0 cpll-on=0
ppll-on=1 sleep_mode=-1
Specifies operating points to run the CPU at 520, 416, 312, and 208 MHz,
respectively. The operating points specified for 520mhz and 416mhz may
fail on some B0 hardware:
op 520mhz v=1450 l=16 n=5 b=1 half_turbo=0 cccra=1 cpll-on=1
op 416mhz v=1350 l=16 n=4 b=1 half_turbo=0 cccra=1 cpll-on=1
op 312mhz_2 v=1250 l=16 n=3 b=1 half_turbo=0 cccra=1 cpll-on=1
op 208mhz_2 v=1150 l=16 n=2 b=1 half_turbo=0 cccra=1 cpll-on=1
Defines hi-power policies for the above system.
policy hi-power idle, idle-task,task,task+1,task+2,task+3,
task+4=312mhz
policy hi-power task-1,task-2,task-3,task-4=208mhz sleep=sleep
Defines lo-power policies for the above system.
policy lo-power idle, idle-task, task, task-1, task-2,task-3,task-
4=104mhz
policy lo-power task+1,task+2,task+3,task+4=208mhz sleep=dsleep
utilization.

.....
Power Manager Default Configuration Files 39
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
utilization.
Configuration plugin to activate the battery-hi profile, which will remain
tell dpm-profiler profile battery-hi at 0 set policy lo-power
tell dpm-profiler profile battery-hi at 50 set policy hi-power
Configuration plugin to activate the battery-lo profile, which will remain
tell dpm-profiler profile battery-lo at 0 set policy lo-power
tell dpm-profiler profile battery-lo at 90 set policy hi-power
Configuration plugin to activate the battery-hi profile which will remain
tell dpm-profiler set profile battery-hi
Command to report a status summary to stdout.
status

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
DESIGNING YOUR
.....
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
POWER MANAGER BUILDING BLOCKS
Chapter 4, “MontaVista Power Manager Building Blocks,” explained that MontaVista Power
Manger allows you design a power policy that is specific to your development platform by
building its components: operating points, classes, policies, and states. This chapter explains
how to build these blocks.
This chapter covers the following chapters:
• “Studying Your Hardware’s Power Management Characteristics”
• “Guidelines for Setting up DPM Operating Points”
• “Designing High-Level Power Management Software Architecture”
• “Designing DPM Suspend/Resume Devices”
• “Designing DPM Driver Scale Callbacks”
• “Designing Power-Related Events”
• “Designing Power Policies”
• “Designing Programmable Sleep/Wakeup Sources”
• “Designing DPM Task States”
• “Designing Sleep/Standby Behavior”

DE SIG NI N G YO UR POWER M A N A GER BUIL DI N G
B LO CK S
42 Studying Your Hardware’s Power Management Characteristics
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S T U D Y I N G Y O U R H A R D W AR E ’ S P O W E R
M A N AG E M E N T C H AR A C T E R I S T I CS
Before designing your MontaVista Power Manager building blocks, first consult your silicon
or board vendor technical reference manuals, errata, application notes on power
management for the following information:
• Validated or supported operating points.
• Power consumption of hardware components running at different operating points.
• Latencies associated with entering different operating points.
• Clocking dependencies and other information on device dependencies on power states.
CONFIGURING YOUR BOARD
By default, dpmmgr will be preconfigured with a selection of operating points expected to
function properly on the evaluation supported board supported by your Mobilinux LSP.
Comments in the dpmmgr configuration file may indicate known issues with certain
operating points on particular hardware revisions.
DEVICE POWER CONSTRAINTS
Mobilinux Dynamic Power Management for your board is typically preconfigured with device
power constraints in the drivers for devices that have dependencies on power states, preventing
DPM from setting runtime operating points incompatible with active devices.
See Chapter 8, “Designing Your Power Manager Building Blocks,” for information about
your board and how to set operating points through DPM software interfaces and other
power management programming information.

DPM-mobilinux

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (19)

Similar to DPM-mobilinux

Similar to DPM-mobilinux (20)

More from Sholeh Gregory

More from Sholeh Gregory (6)

DPM-mobilinux