Basic operation – Comtrol eCos User Manual

Page 659

Advertising
background image

Introduction

are integrated with the processor,

power_controller_cpu

will take care of the integrated devices as a side

effect. In other cases the hardware may not provide any functionality that allows power consumption to be
controlled. For any given device driver it is also possible that no power controller exists either because it was
not required when the driver was written, or because the driver predates the availability of power management.
Again the relevant documentation and sources should be consulted for further information.

3. There may be power controllers which are not associated directly with any specific hardware. For example a

TCP/IP stack could provide a power controller so that it gets informed when the system has been reactivated:
by looking at the system clock it can determine for how long the system has been switched off; using this
information it can then recover from expired dhcp leases, or even to shut down any stream connections that
may have become invalid (although arguably the stack should have refused to go to off mode while there were
open connections).

Basic Operation

By default the Power Management package creates a thread during initialization. It is also possible for the pack-
age to be used without such a thread, for example in configurations which do not include a full kernel, and this
alternative is described below. When a separate thread is used the stacksize and priority for this thread can be con-
trolled by configuration options

CYGNUM_POWER_THREAD_STACKSIZE

and

CYGNUM_POWER_THREAD_PRIORITY

.

Typically the thread will just wait on a semaphore internal to the package, and will do nothing until some other
part of the system requests a change to the power mode.

At some point the policy module will decide that the system should move into a lower-power mode, for example
from active to idle. This is achieved by calling the function

power_set_mode

, provided by the power management

package and declared in

cyg/power/power.h

, with a single argument,

PowerMode_Idle

. This function manip-

ulates some internal state and posts the semaphore, thus waking up the power management thread. Note that the
function returns before the mode change has completed, and in fact depending on thread priorities this return may
happen before any power controller has been invoked.

When the power management thread wakes up it examines the internal state to figure out what it should be doing. In
this case it is supposed to change the global power mode, so it will iterate over all the power controllers requesting
each one to switch to the idle mode. It is up to each power controller to handle this request appropriately. Optionally
the thread will invoke a callback function after processing each power controller, so that higher-level code such as
the policy module can more easily keep track of the actual state of each controller. Once the thread has iterated
through all the power controllers it will again wait on the internal semaphore for the next request to arrive.

Note: At present the power management thread always runs at a single priority, which defaults to a low priority.
A possible future enhancement would be to support two separate priorities. When switching to a lower-powered
mode the thread would run at a low priority as before, thus allowing other threads to run and get a chance to
cancel this mode change. When switching to a higher-powered mode the thread would run at a high priority.
This could be especially important when moving out of the off state: for example it would ensure that all device
drivers get a chance to wake up before ordinary application threads get to run again and possibly attempt I/O
operations.

Although usually calls to

power_set_mode

will come from just one place in the policy module, this is not a hard

requirement. It is possible for multiple threads to call this function, with no need for any synchronization. If the
power management thread is in the middle of performing a mode change and a new request comes in, the thread
will detect this, abort the current operation, and start iterating through the power controllers again with the new

555

Advertising