power-controller.html

ecos源代码包

></TR
></TABLE
><P
>This defines a power controller structure
<TT
CLASS="VARNAME"
>power_controller_cpu</TT
>. It should not be declared
static since higher-level code may well want to manipulate the cpu's
power mode directly, and the variable is declared by the power
management package's header file.</P
><P
>Some care has to be taken to ensure that the power controllers
actually end up in the final executable. If a power controller
variable ends up in an ordinary library and is never referenced
directly then typically the linker will believe that the variable is
not needed and it will not end up in the executable. For eCos packages
this can be achieved in the CDL, by specifying that the containing
source file should end up in <TT
CLASS="FILENAME"
>libextras.a</TT
> rather
than the default <TT
CLASS="FILENAME"
>libtarget.a</TT
>:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>cdl_package CYGPKG_HAL_WUMPUS_ARCH {
    &#8230;
    compile -library=libextras.a data.c
}</PRE
></TD
></TR
></TABLE
><P
>If the file <TT
CLASS="FILENAME"
>data.c</TT
> instantiates a power
controller this is now guaranteed to end up in the final executable,
as intended. Typically HAL and device driver packages will already
have some data that must not be eliminated by the linker, so they will
already contain a file that gets built into
<TT
CLASS="FILENAME"
>libextras.a</TT
>. For power controllers defined inside
application code it is important that the power controllers end up in
<TT
CLASS="FILENAME"
>.o</TT
> object files rather than in
<TT
CLASS="FILENAME"
>.a</TT
> library archive files.</P
><P
>All the real work of a power controller is done by the mode change
function. If the power management package has been configured to use a
separate thread then this mode change function will be invoked by that
thread (except for the special case of <A
HREF="power-change.html#POWER-CHANGE-CONTROLLER-NOW"
><TT
CLASS="FUNCTION"
>power_set_controller_mode_now</TT
></A
>). 
If no separate thread is used then the mode change function will be
invoked directly by <TT
CLASS="FUNCTION"
>power_set_mode</TT
> or
<TT
CLASS="FUNCTION"
>power_set_controller_mode</TT
>.</P
><P
>The mode change function will be invoked with three arguments. The
first argument identifies the power controller. Usually this argument
is not actually required since a given mode change function will only
ever be invoked for a single power controller. For example,
<TT
CLASS="FUNCTION"
>xyzzy_device_power_mode_change</TT
> will only ever be
used in conjunction with <TT
CLASS="VARNAME"
>xyzzy_power_controller</TT
>.
However there may be some packages which contain multiple controllers,
all of which can share a single mode change function, and in that case
it is essential to identify the specific controller. The second
argument specifies the mode the controller should switch to, if
possible: it will be one of <TT
CLASS="LITERAL"
>PowerMode_Active</TT
>,
<TT
CLASS="LITERAL"
>PowerMode_Idle</TT
>, <TT
CLASS="LITERAL"
>PowerMode_Sleep</TT
>
or <TT
CLASS="LITERAL"
>PowerMode_Off</TT
>. The final argument will be one of
<TT
CLASS="LITERAL"
>PowerModeChange_Controller</TT
>,
PowerModeChange_ControllerNow, or
<TT
CLASS="LITERAL"
>PowerModeChange_Global</TT
>, and identifies the call
that caused this invocation. For example, if the mode change function
was invoked because of a call to <TT
CLASS="FUNCTION"
>power_set_mode</TT
>
then this argument will be <TT
CLASS="LITERAL"
>PowerModeChange_Global</TT
>.
It is up to each controller to decide how to interpret this final
argument. A typical controller might reject a global request to switch
to <SPAN
CLASS="TYPE"
>off</SPAN
> mode if the associated device is still busy, but
if the request was aimed specifically at this controller then it could
instead abort any current I/O operations and switch off the device.</P
><P
>The <SPAN
CLASS="STRUCTNAME"
>PowerController</SPAN
> data structure contains
one field, <TT
CLASS="STRUCTFIELD"
><I
>mode</I
></TT
>, that needs to be updated
by the power mode change function. At all times it should indicate the
current mode for this controller. When a mode change is requested the
desired mode is passed as the second argument. The exact operation of
the power mode change function depends very much on what is being
controlled and the current circumstances, but some guidelines are
possible:</P
><P
></P
><OL
TYPE="1"
><LI
><P
>If the request can be satisfied without obvious detriment, do so and
update the <TT
CLASS="STRUCTFIELD"
><I
>mode</I
></TT
> field. Reducing the power
consumption of a device that is not currently being used is generally
harmless.</P
></LI
><LI
><P
>If a request is a no-op, for example if the system is switching
from <SPAN
CLASS="TYPE"
>idle</SPAN
> to <SPAN
CLASS="TYPE"
>sleep</SPAN
> mode and the controller
does not distinguish between these modes, simply act as if the request
was satisfied.</P
></LI
><LI
><P
>If a request is felt to be unsafe, for example shutting down a
device that is still in use, then the controller may decide
to reject this request. This is especially true if the request was a
global mode change as opposed to one intended specifically for this
controller: in the latter case the policy module should be given due
deference. There are a number of ways in which a request can be
rejected:</P
><P
></P
><OL
TYPE="a"
><LI
><P
>If the request cannot be satisfied immediately but may be feasible in
a short while, leave the <TT
CLASS="STRUCTFIELD"
><I
>mode</I
></TT
> field
unchanged. Higher-level code in the policy module can interpret this
as a hint to retry the operation a little bit later. This approach is
also useful if the mode change can be started but will take some time
to complete, for example shutting down a socket connection, and
additional processing will be needed later on.</P
></LI
><LI
><P
>If the request is felt to be inappropriate, for example switching off
a device that is still in use, the mode change function can
call <TT
CLASS="FUNCTION"
>power_set_controller_mode</TT
> to reset the
desired mode for this controller back to the current mode.
Higher-level code can then interpret this as a hint that there is more
activity in the system than had been apparent.</P
></LI
><LI
><P
>For a global mode change, if the new mode is felt to be inappropriate
then the power controller can call <TT
CLASS="FUNCTION"
>power_set_mode</TT
>
to indicate this. An example of this would be the policy module
deciding to switch off the whole unit while there is still I/O
activity.</P
></LI
></OL
></LI
></OL
><P
>Mode change functions should not directly manipulate any other fields
in the <SPAN
CLASS="STRUCTNAME"
>PowerController</SPAN
> data structure. If it
is necessary to keep track of additional data then static variables
can be used.</P
><P
>It should be noted that the above are only guidelines. Their
application in any given situation may be unclear. In addition the
detailed requirements of specific systems will vary, so even if the
power controller for a given device driver follows the above
guidelines exactly it may turn out that slightly different behaviour
would be more appropriate for the actual system that is being
developed. Fortunately the open source nature of
<SPAN
CLASS="PRODUCTNAME"
>eCos</SPAN
> allows system developers to fine-tune
power controllers to meet their exact requirements.</P
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="power-attached.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="ecos-ref.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="io-usb-slave.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Attached and Detached Controllers</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="services-power.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>eCos USB Slave Support</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>