Implementing a power controller, Name – Comtrol eCos User Manual
Page 673
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
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