This version of this document is no longer maintained. For the latest documentation, see http://www.qnx.com/developers/docs.

Power Management Architecture

This chapter contains the following topics:

• Introduction
• QNX Neutrino power management framework
• Power management architecture
  • Low-level power management architecture
  • Power manager architecture
• Power managed entities
• Power modes (states)
• Power managed objects

Introduction

This chapter describes the power management framework along with two different approaches for power management support. It also provides the major components of the power management architecture. In addition, it includes a discussion on power managed entities, power modes (states), and power managed objects.

QNX Neutrino power management framework

The power management framework is included as part of the QNX Neutrino RTOS. It is based on the principle of providing mechanisms -- not policies -- to control and manage power. You use these mechanisms to implement your own power management policy, i.e. what determines how to save energy or when to go to a low-power state. The framework consists of the following:

• a set of interfaces for low-level control of individual device power modes and the CPU power mode
• a more sophisticated set of services for implementing a system-wide power management policy that can manage applications or other software subsystems as well as hardware devices.

Power management framework as part of QNX Neutrino RTOS.

Power management architecture

In order to accommodate the above framework, the power management architecture can be broken into two parts:

1. A custom power management architecture using the QNX Neutrino resource manager interface. This approach provides a very simple and basic standalone power management solution that doesn't require a system-wide power manager.
2. A sophisticated server-client architecture to build a power manager, which is the server, and implements the system-wide power management policy. The power manager interacts with the clients, such as power managed devices, to determine device power capabilities and to manipulate device power states, based on the status of the power source (e.g. battery).

Components of the power management architecture

The major components of the power management architecture are:

• a central power manager that implements the system power management policy
• device driver(s) that interact with the power manager to adjust power levels according to the system policy
• monitoring applications -- may provide input events or data used by the power management policy
• applications -- may receive notification of power mode changes.

Basic device and CPU power management can be implemented without requiring the power manager.

Components of the power management architecture

Power managed devices or services

These are the device drivers that manage the power consumption of the hardware devices they control. These device drivers have the most intimate knowledge of the device's usage pattern and power consumption characteristics. Therefore, they determine when the devices should change power states or which states are appropriate for current usage.

Power managed services are some arbitrary software components whose behavior can be modeled via power modes.

Power sensitive applications

These are applications whose behavior depends on the power mode of the system specific drivers or software subsystems.

Power monitoring applications

These are applications that monitor specific system parameters that are relevant to the system-wide power management policy. For example, you may consider monitoring battery levels or other data that may require changing the system power mode.

Low-level power management architecture

Low-level power management architecture provides a straight forward way of controlling the power modes of the device drivers and the CPU.

At the most basic level, the framework provides a set of low-level services to:

• set or query the device power modes of individual devices, provided via a file descriptor-based interface implemented by device drivers.
• set the CPU power mode, provided by your custom code, in co-operation with the board-specific startup and IPL software, to manage the different CPU-specific operating modes and board-specific mechanisms for handling standby and wakeup operations.

This low-level architecture can provide a very simple form of power management, subject to the following restrictions:

• It applies only to CPU and hardware devices managed by the device drivers.
• It provides no explicit mechanism for applications to be aware of changes to either the power mode state of the system or of specific devices.
• It provides no explicit mechanism for influencing the policy that controls the system's power mode state.

Although this architecture may be suitable for some extremely simple embedded systems, a more comprehensive, system-wide power management policy would typically require much tighter integration with application-level services provided by the product. This is achieved by a higher level set of services that are based around the use of a centralized power manager, described in the next section.

You can find details about this architecture in the Low-level Power Management chapter.

Power manager architecture

The power manager architecture has two important components: the server and the client. The power manager is referred to as the server, and it implements a centralized power management policy. The power manager interacts with the clients, such as power managed devices or services to determine device power capabilities and to manipulate device power states.

The power management policy is product specific. It takes into consideration various operating modes of the product. Each mode determines the available functions of the product based on power constraints. The policy:

• determines the appropriate power mode state(s) of the product, and also includes responding to external input events, or monitoring and evaluating the system status information.
• manages the transitions between power mode states and co-ordinates changes to the power mode states of all power managed entities.

The power manager is implemented using a library that provides the basic mechanisms for:

• handling power managed entities
• managing the system power mode state machine
• interacting with device drivers and application clients.

You should use the server library to implement your own product-specific power manager. In essence, it is the specific power manager code that uses the server library and is built by linking product-specific initialization and policy code. The services provided by the library interact with the policy code to manage the overall system power mode state. See Implementing System Power Management Policy in this guide for details.

The power manager interacts with the clients to control the use of power for your hardware peripherals. See the Power Manager Clients chapter in this guide for details.

The Power Management Toolkit includes both a server and client library to provide a rich set of APIs and datatypes that enable two-way communication between the server and the clients. See the API Reference chapter in this guide for a list of APIs and datatypes.

Power managed entities

Power managed entities include:

Hardware devices

Power levels are manipulated via software control. The drivers for these devices interact with the power management policy to change the device's power mode according to policy decisions.

Software subsystems

Mode of operation is changed based on the system power mode (state). These subsystems include system services, or more general sets of applications that provide a specific service. As the power management policy changes the system power mode (state), these services are notified and change their behavior to provide only the level of service required for that system state.

In addition, the CPU is also a power managed entity; it provides active, idle and standby operational mode. Many embedded processors allow scaling of power consumption within the CPU's active operating mode using techniques such as voltage or frequency scaling.

Power modes (states)

The power management framework defines four generic power modes that apply to power managed entities:

Active

Indicates that the entity is operational from a user's perspective.

Idle

Indicates that the entity is partially powered; not all functions are operational. The entity is operational from a user's point of view, and transition to the Active mode when it is used.

Standby

Indicates that the entity is partially powered; only limited functions are operational, such as implementing wakeup events. The entity is not operational from a user's perspective.

Off

Indicates that the entity is powered down and is not operational.

Different power managed entities may support further modes -- a number of different states within each of these generic power modes. For example, different Active states represent different operating modes that provide tradeoffs between performance and power consumption.

The framework allows each power managed entity to define these different entity-specific states and how they map to these modes.

Power managed objects

Power managed objects represent the power managed entities in a hierarchical namespace. Each object within this namespace describes:

• information describing the power mode status of the object
• arbitrary properties associated with the object.

The namespace hierarchy provides a rudimentary configuration database that represents:

• physical relationships, such as the hardware topology describing the connection between buses and peripherals
• logical relationships, describing the relationship between system-level services and their constituent power managed entities.

Power managed objects as represented in a hierarchical namespace.