Implementing a power controller, Name – Comtrol eCos User Manual

Page 673

Advertising
background image

Implementing a Power Controller

Name

Implementing a Power Controller

— adding power management support to device drivers and other

packages

Implementing a Power Controller

A system will have some number of power controllers. Usually there will be one power controller for the cpu,

power_controller_cpu

, typically provided by one of the HAL packages and responsible for managing the pro-

cessor itself and associated critical components such as memory. Some or all of the device drivers will provide
power controllers, allowing the power consumption of the associated devices to be controlled. There may be some
arbitrary number of other controllers present in the system. The power management package does not impose any
restrictions on the number or nature of the power controllers in the system, other than insisting that at most one

power_controller_cpu

be provided.

Each power controller involves a single data structure of type PowerController, defined in the header file

cyg/power/power.h

. These data structures should all be placed in the table

__POWER__

, so that the power

management package and other code can easily locate all the controllers in the system. This table is constructed at
link-time, avoiding code-size or run-time overheads. To facilitate this the package provides two macros which
should be used to define a power controller,

POWER_CONTROLLER()

and

POWER_CONTROLLER_CPU()

.

The macro

POWER_CONTROLLER

takes four arguments:

1. A variable name. This can be used to access the power controller directly, as well as via the table.

2. A priority. The table of power controllers is sorted, such that power controllers with a numerically lower

priority come earlier in the table. The special controller

power_controller_cpu

always comes at the end of

the table. When moving from a high-power mode to a lower-powered mode, the power management package
iterates through the table from front to back. When moving to a higher-powered mode the reverse direction
is used. The intention is that the power controller for a software-only package such as a TCP/IP stack should
appear near the start of the table, whereas the controllers for the ethernet and similar devices would be near the
end of the table. Hence when the policy module initiates a mode change to a lower-powered mode the TCP/IP
stack gets a chance to cancel this mode change, before the devices it depends on are powered down. Similarly
when moving to a higher-powered mode the devices will be re-activated before any software that depends on
those devices.

The header file

cyg/power/power.h

defines three priorities

PowerPri_Early

,

PowerPri_Typical

and

PowerPri_Late

. For most controllers one of these priorities, possibly with a small number added or sub-

tracted, will give sufficient control. If an application developer is uncertain about the relative priorities of the
various controllers, a simple

test program

that iterates over the table will quickly eliminate any confusion.

3. A constant string identifier. If the system has been configured without support for such identifiers

(

CYGIMP_POWER_PROVIDE_STRINGS

) then this identifer will be discarded at compile-time. Otherwise it will

be made available to higher-level code using the function

power_get_controller_id

.

4. A function pointer. This will be invoked to perform actual mode changes, as described below.

A typical example of the use of the

POWER_CONTROLLER

macro would be as follows:

569

Advertising