The Advanced Configuration and Power Interface (ACPI) specification is an open industry standard first released in December 1996 developed by HP, Intel, Microsoft, Phoenix and Toshiba that defines common interfaces for hardware recognition, motherboard and device configuration and power management. According to its specification[1], "ACPI is the key element in Operating System-directed configuration and Power Management (OSPM)".
The most widely recognized element of the standard is power management, of which there have been two major improvements. First, it puts the operating system (OS) in control of power management. Conversely, the previously existing APM model assigns power management control to the BIOS, with limited intervention from the OS. In ACPI, the BIOS provides the OS with methods for directly controlling the dirty details of the hardware so it has nearly complete control over the power savings.
The other important feature of ACPI is in bringing power management features previously only available in portable computers to desktop computers and servers. Extremely low consumption states, i.e. in which only memory, or not even memory is powered, but from which ordinary interrupts (real time clock, keyboard, modem, etc.) can quickly wake the system. These modes were previously only available in portable computers.
The standard supports keys on a normal keyboard for suspending or powering off the computer. Some vendors (e.g. ASUS and Compaq) have extended this feature and use it for other keys, especially so-called Power management keys.
ACPI cannot be applied to older hardware; for it to work, the operating system, the motherboard chip-set and for some functions even the CPU need to be designed for it.
ACPI uses its own ACPI Machine Language (or AML) for implementing power event handlers, rather than the native assembly language of the host system.
The first version of Microsoft Windows to support ACPI was Windows 98. Linux, FreeBSD, NetBSD and OpenBSD all have at least some support for ACPI, though problems tend to arise from buggy implementations, especially those which Microsoft platforms and the Microsoft compiler support (though the implementation is not standards-compliant). Some people misinterpret this as the Microsoft tools being able to work around the bugs, when in fact the Microsoft tools simply allow the bugs to go unchecked and handle them in a non-standards-conforming way.
ACPI Global States
The ACPI specification defines the following seven states (so-called global states) an ACPI-compliant computer system can be in:
G0 Working is the normal working state of the computer, meaning that the operating system and whatever applications run. The CPU(s) execute instructions. Within this state (i.e., without entering G1 Sleeping), it is possible for CPU(s) and devices like hard drives, DVD drives, etc. to be repeatedly put into and come back from low-energy states, called C0–Cn and D0–D3. (Laptops, for example, routinely power down all currently unused devices when running on battery; some computers do this to reduce noise.)
G1 Sleeping subdivides into the four states S1 through S4. The time needed to bring the system from here back into G0 Working (wake-latency time) is shortest for S1, short for S2 and S3, and not so short for S4.
- S1 is the most power-hungry of sleep modes. All processor caches are flushed, and the CPU(s) stop executing instructions. Power to the CPU(s) and RAM is maintained; devices that do not indicate they must remain on may be powered down. Some newer machines do not support S1; older machines are more likely to support S1 than S3.
- S2 is a deeper sleep state than S1, where the CPU is powered off; however, it is not commonly implemented.
- S3 is called Standby in Windows, Sleep in Mac OS X, and sometimes also Suspend to RAM (STR), although the ACPI specification mentions only the term Sleep. In this state, main memory (RAM) is still powered, although it is almost the only component that is. Since the state of the operating system and all applications, open documents, etc. lies all in main memory, the user can resume work exactly where he/she left off—the main memory content when the computer comes back from S3 is the same as when it was put into S3. (The specification mentions that S3 is rather similar to S2, only that some more components are powered down in S3.)
- (Main article: Hibernate (OS feature)). S4 is called Hibernation in Windows, Safe Sleep in Mac OS X, and sometimes also Suspend to disk, although the ACPI specification mentions none of these terms. In this state, all content of main memory is saved to a hard drive, preserving the state of the operating system, all applications, open documents etc. That means that after coming back from S4, the user can resume work where it was left off in much the same way as with S3. The difference between S4 and S3, apart from the added time of moving the main memory content to disk and back, is that a power loss of a computer in S3 makes it lose all data in main memory, including all unsaved documents, while a computer in S4 is unaffected. (S4 is quite different from the other S states and actually resembles G2 Soft Off and G3 Mechanical Off more than it resembles S1–S3.)
G2 Soft Off (also known as S5) is almost the same as G3 Mechanical Off, which means among other things that the boot procedure must be run to bring the system from G2 to G0 Working. A key difference is that G3 Mechanical Off is entered only when a power loss occurs, whereas G2 is initiated by the operating system (typically because the user issued a shutdown command in some way). Additionally, for functionality like starting the system when the space bar on the keyboard is pressed, some components remain powered in G2, which means the computer is not safe for dis-assembly in this state.
G3 Mechanical Off: The computer's power consumption is very close to zero, to the point that the power cord can be removed and the system is safe for dis-assembly (typically, only the real-time clock is running off its own small battery). The computer falls into this state when a power loss occurs, e.g. in case of a power outage. Once power is restored, a full boot procedure is necessary to bring the system from G3 to G0 Working.
Furthermore, a state Legacy is defined as the state when an operating system runs which does not support ACPI. In this state, the hardware and power is not managed via ACPI, effectively disabling ACPI.
ACPI Device States
The device states D0-D3 are device-dependent:
- D0 Fully-On is the operating state.
- D1 and D2 are intermediate power states whose definition varies by device.
- D3 Off has the device powered off and unresponsive to its bus.
ACPI Processor States
The CPU power states C0-C3 are defined as follows:
- C0 is the operating state.
- C1 (often known as Halt) is a state where the processor is not executing instructions, but can return to an executing state essentially instantaneously.
- C2 (often known as Stop-Clock) is a state where the processor maintains all software-visible state, but may take longer to wake up.
- C3 (often known as Sleep) is a state where the processor does not need to keep its cache coherent, but maintains other state. Some processors have variations on the C3 state (Deep Sleep, Deeper Sleep, etc.) that differ in how long it takes to wake the processor.
ACPI Performance States
While a device or processor is operating (D0 and C0, respectively), it can be in one of several power-performance states. These states are implementation-dependent, but P0 is always the highest-performance state, with P1 to Pn being successively lower-performance states, up to an implementation-specific limit of n no greater than 16.
P-states in Intel processors are called SpeedStep, and in AMD processors, Cool'n'Quiet.
ACPI Critique
ACPI is a complex specification (over 500 pages long) that contains multiple components, including declarative tables, an imperative byte-code, and specific hardware components. Concerns have been repeatedly raised that an implementation of ACPI has to run complex, untrusted and potentially buggy bytecode with full privileges, thus potentially making any system that implements ACPI unstable and/or insecure.
Where hardware is non-conforming to ACPI, but claims to be, the software interoperating with that hardware is faced with a dilemma: Either it can be written to be ACPI-compliant, thus risking problems with the not-entirely-compliant hardware, or it can deviate from the ACPI standard to accommodate the hardware quirks. That, however, is generally seen as undesirable from a software-engineering point of view, since the software would potentially have to be adapted for and tested with arbitrarily large numbers of hardware devices, which is precisely what standards such as ACPI are intended to avoid. This is a constant debate between "standards purists" (mainly in the Linux community) and advocates of software that "simply works" with as much hardware as possible.
No comments:
Post a Comment