
Other Power Management Options


So far, a lot of talk has been dedicated to describing the internals
of the new power management subsystem, but little has been given to
describe how the new infrastructure interacts with current power
management options. This section describes those relationships, and
although it focuses on options specific to ia32 platforms, the
relationships should be extendable to other platforms. 


ACPI

In terms of system power management, fits nicely into the new PM
infrastructure. It behaves as a PM driver, and provides
platform-specific hooks to transition the system into a low-power
state. At the basic SPM level, this is all that is required, though
ACPI offers a potentially much more powerful solution, since it it
exposes intimate knowledge of the platform power requirements than has
ever been available on ia32 platforms (e.g. response latencies, power
consumption etc.). Exploiting this knowledge is up to the ACPI
platform driver to expose these attributes via sysfs. 

ACPI offers similar potential for device power management. Devices
that appear in the firmware's DSDT (Differentiated System Description
Table) may expose a very fine-grained level of detail about the
devices' power requirements and capabilities. 

ACPI also stress the capabilities of device Performance States. 
A performance state is a power state that describes a trade-off
between the capabilities of a device against the power consumption of
the device. In each performance state that a device supports, the
device is fully running, but different functional hardware units may
be powered off to conserve power. The driver model does not explicitly
recognize performance states, though the new PM extensions to the driver
model provide a framework that could easily be extended to recognize
performance states. 


APM

APM power management does not appear on very many new systems, but the
current Linux install base includes a large number of APM-capable
computers. The new PM model was not developed with APM, or any
firmware-driven PM model, in mind. However, care was taken to ensure
that it conceptually made sense to use such mechanisms as low-level
platform drivers for the PM model. No work has been done, however, to
convert APM to act as a PM driver for the new model.


pm_* infratructure

The original PM infrastucture was developed by Andrew Henroid and was
very ground-breaking, since nothing like it had been done for the
Linux kernel before. It exists in its entirety in:

      kernel/pm.c
      include/linux/pm.h

The general idea is that drivers can declare and register an object
with the pm infrastructure that is accessed during a power state
transition. The idea is very similar to what we have now, though the
registration now is implicit when a device is registered with the
system. And, based on the implementation, we can guarantee that each
device is notified in proper ancestral order, which the old model
cannot do. 

Because the new model is far superior the old-style pm infrastructure,
it is declared deprecated. All drivers that implement pm callbacks
should be converted to use the hooks provided by the new driver model.


swsusp

swsusp is a mechanism for doing suspend-to-disk by saving kernel state
to unused swap space. It was also a ground-breaking feature, as it was
the first true suspend-to-disk implementation for Linux. There are
some questionable characteristics of swsusp that many people have that
the maintainers of swsusp counter are frivilous concerns, and it
currently exists as an alternative to the new PM model. However, the
author has revoked any philosophical issues with swsusp. It can be,
and should be ported to be, used as a backend driver for the generic
Hibernate mechanism. The current code base could be reduced to a
fraction of its current complexity. 
 