Power Management Scenarios: Difference between revisions

From OLPC
Jump to navigation Jump to search
m (category)
(Update for a more modern world as implemented in Update.1.)
Line 1: Line 1:
== PMD ==
== Ohm ==


Power management on the XO will be controlled by a special application known as the Power Management Daemon (or PMD for short). This yet to be defined application will be responsible for processing
Power management on the XO will be controlled by a special application, the Power Management Daemon. It is implemented in Ohm, the Open Hardware Manager daemon originally written for the OpenEmbedded project. Ohm is responsible for processing
power events from both Sugar and the kernel and managing the system accordingly. It will use these scenarios as a roadmap for designing the power management policy on the system.
power events from both Sugar and the kernel and managing the system accordingly. Ohm will use these scenarios to resist the useless consumption of power by the system.




Line 11: Line 11:
=== On Demand ===
=== On Demand ===


The XO enters STR on demand from some application or user input. This does not imply that the user will have a shiny button to press to enter the state, only that the state is not entered automatically by some hardware event or timer. Typically, the PMD would be notified through DBUS to enter the sleep state. The appropriate wakeup events for this mode would be the Power button, RTC and EC - possibly configurable by the requesting application. Enabling LID events will be complex, because presumably we don't want to wake up on the LID down event.
The XO enters STR on demand from some application or user input. This does not imply that the user will have a shiny button to press to enter the state, only that the state is not entered automatically by some hardware event or timer. Typically, Ohm would be notified through DBUS to enter the sleep state. The appropriate wakeup events for this mode would be the Power button, RTC and EC - possibly configurable by the requesting application. Enabling LID events will not be complex, because Ohm can wake up on the LID down event,
turn off the video display and do any other further power reduction, and go back into suspend.


=== Lid down/up ===
=== Lid down/up ===


The XO enters STR when the LID is closed, and resumed when the LID is opened. Upon detecting a lid down event, the PMD enables the LID event as a wakeup event and enters the STR state through the /sys/power/state interface. LID up is configured to wake the system when the lid is lifted again. EC wakeups may be enabled to allow the system to process battery and WLAN events, but the PMD will have to be smart enough to realize that the LID is still down, and it should process the event and go back to sleep again. Since this mode has the LID down, it is not necessary to keep the DCON alive or the backlight enabled. The DCON should be put into a sleep mode before suspending.
The XO enters STR when the LID is closed, and resumed when the LID is opened. Upon detecting a lid down event, Ohm enables the LID event as a wakeup event and enters the STR state through the /sys/power/state interface. LID up is configured to wake the system when the lid is lifted again. EC wakeups may be enabled to allow the system to process battery and WLAN events, but Ohm will realize that the LID is still down, and that it should process the event and go back to sleep again. Since this mode has the LID down, it is not necessary to keep the DCON alive or the backlight enabled. The DCON should be put into a sleep mode before suspending.


=== System Idle ===
=== System Idle ===


The XO enters STR when it is believed that the system has nothing to do. The metric used for "nothing to do", as well as the idle time is still largely to be determined. This is the hardest of all modes, and will be done last.
The XO enters STR when it is believed that the system has nothing to do for some period of time, or until an event occurs (such as a keypress, USB insertion, AC on or off, or packet reception). The metric used for "nothing to do", as well as the idle time is determined by Ohm's heuristics.





Revision as of 13:38, 30 January 2008

Ohm

Power management on the XO will be controlled by a special application, the Power Management Daemon. It is implemented in Ohm, the Open Hardware Manager daemon originally written for the OpenEmbedded project. Ohm is responsible for processing power events from both Sugar and the kernel and managing the system accordingly. Ohm will use these scenarios to resist the useless consumption of power by the system.


Suspend to RAM

The following are the scenarios we wish to support for Suspend to RAM (STR):

On Demand

The XO enters STR on demand from some application or user input. This does not imply that the user will have a shiny button to press to enter the state, only that the state is not entered automatically by some hardware event or timer. Typically, Ohm would be notified through DBUS to enter the sleep state. The appropriate wakeup events for this mode would be the Power button, RTC and EC - possibly configurable by the requesting application. Enabling LID events will not be complex, because Ohm can wake up on the LID down event, turn off the video display and do any other further power reduction, and go back into suspend.

Lid down/up

The XO enters STR when the LID is closed, and resumed when the LID is opened. Upon detecting a lid down event, Ohm enables the LID event as a wakeup event and enters the STR state through the /sys/power/state interface. LID up is configured to wake the system when the lid is lifted again. EC wakeups may be enabled to allow the system to process battery and WLAN events, but Ohm will realize that the LID is still down, and that it should process the event and go back to sleep again. Since this mode has the LID down, it is not necessary to keep the DCON alive or the backlight enabled. The DCON should be put into a sleep mode before suspending.

System Idle

The XO enters STR when it is believed that the system has nothing to do for some period of time, or until an event occurs (such as a keypress, USB insertion, AC on or off, or packet reception). The metric used for "nothing to do", as well as the idle time is determined by Ohm's heuristics.