The Advanced Configuration and Power Interface (ACPI) specification lets Microsoft Windows operating systems power, manage and configure hardware. ACPI is based on the Windows Driver Model (WDM), introduced in Windows 98 and Windows 2000 to provide a unified driver model for these and future Windows operating systems. With WDM came a standardized way of doing plug-and-play and power management.
Before ACPI there was Advanced Power Management (APM), in which a computer's BIOS managed power with or, most often, without the cooperation of the operating system. It generally supported a "suspend-to-RAM" state, in which the operating system and applications stopped working, the computer appeared to be off, but RAM was maintained. Resuming from this state restarted the operating system and applications from the point where they were suspended.
Many APM machines also supported a "suspend-to-disk" state, in which the contents of memory were written to disk at the point that the operating system and applications were suspended. That allowed the entire machine to shut off.
Aside from state transitions that affected the entire computer, APM could move specific devices temporarily out of the working state while the operating system was running. It set timers in hardware that caused a system management interrupt (SMI). When an Intel-compatible processor received an SMI, it jumped immediately to BIOS code.
The BIOS code could move a device such as a disk or a flat-panel display from the working state to the off state. Then the BIOS set a trap on the device's registers, so that when the operating system tried to access the device again, the processor jumped first into the BIOS code, allowing the BIOS to move the device back into the working state before the operating system touched it.
When an APM BIOS did move the entire machine into a suspended state, it would enable interrupts from any device that could wake the machine.
APM created quite a few problems. To move devices or the machine in or out of the working state, the BIOS had to change the device runtime control registers. Because the BIOS couldn't see what the OS did to the devices and the OS couldn't see what the BIOS did, the hardware state would be out of sync with the software (OS) or the firmware (BIOS) state or both.
In addition, if the machine has any slots, the user can plug any arbitrary device into one of those slots. Because that device wasn't present when the machine left the factory, the BIOS cannot know about it and cannot include it in any power management. And, many APM operations involve suspending the operating system-without operating system knowledge-for relatively unbounded amounts of time. This makes media streaming and other real-time-like applications nearly impossible.
The Windows Driver Model offers a unified means of managing a collection of devices that might be designed into a Windows system. WDM is built around the concept of a device node, which is a collection of device objects stacked on top of each other. Each device object is managed by a device driver. In the device node, there will be, at a minimum, a device object called the physical device object (PDO), owned and managed by a bus driver, and a functional device object (FDO), which is owned and managed by a driver that controls the specific device.
Bus drivers control plug-and-play and power management, typically managing this for all devices on the bus. Functional drivers control a specific device's function. There may also be filter device objects within a device node that are owned by an auxiliary driver. The best example of this in Windows 2000 is the ACPI driver, which filters any device node that has power management or plug-and-play properties that fall within the realm of ACPI.
Messages, called I/O request packets (IRPs), are sent to the top device object in the stack. The top device processes the IRP and then sends it down to the device below it. When the device at the bottom (the PDO) is finished with the IRP, it sends it back up the stack.
This system allows various tasks required to move a device from a powered-on to a powered-off state to be shared by several drivers.
By separating the tasks required for plug-and-play and power management into separate drivers, these tasks can be handled across an entire bus, or even the entire system. Plug-and-play, in particular, suffers when there is no central management. By compartmentalizing plug-and-play and power support into drivers that are separate from the functional driver, it becomes easy to thoroughly test these features. Forty years of computer science has shown that modular designs are easier to test, debug and maintain. Although this may seem like a minor point, there are millions of lines of source code in Windows 2000. Modular design is the only way that we could deliver such a large project.
The I/O request packets system allows new devices-and even buses-to be supported in systems that shipped before those devices or buses even existed, with full support for power management.
WDM and ACPI were designed together, and many of the concepts in one can be found in the other. System and device power states are the most notable. The system can be in any of five states, S0 through S5. S0 is the working state. Code-whether operating system or application-executes only in the S0 state. S1 through S3 are sleeping states where the processor is not executing code, RAM is preserved and the machine appears to be off. These states are most analogous to the APM suspend-to-RAM state. The S4 is the hibernation state and is very close to the APM suspend-to-disk state. Finally, S5 is the off state where no context is saved.
WDM is specifically designed to enable a device to be powered off whenever it is not being used. When the device is needed, it can be moved back into the working (D0) state. Sometimes this is done in response to something the user has done, like initiating a phone call via a modem. And sometimes it is done in response to an external event-such as a phone call from an outside caller.
The first is handled by sending an IRP to the device node, telling it that the device is needed, which triggers an internal IRP that moves the device back into the D0 state. The second is handled by arming the device to trigger a wakeup signal. The signal, triggered by the modem getting a call, instructs the operating system that it must send an IRP to the device node telling it to move itself back into the D0 state.
WDM makes no distinction between moving a device into the D0 state when the system is in the S0 state (for example, your machine is running and you have no idea that your modem has been powered off) and moving a device into the D0 state when the system is in an S1 through S4 sleep state (for example, your whole machine was asleep, appearing to be off). If the system happens to be in a sleeping state when the device needs to be powered on, the whole machine is first moved to the S0 state, then the device is moved into the D0 state.
WDM defines four device states, D0 through D3. D0 is the working state in which the device is fully functional, and D3 is the off state. D1 and D2 are similar to D3, although the device consumes more power in them than it would in D3, though the time required to wake the device may be reduced.
Some general guidelines to insure that devices successfully transition to D0 when required that the entire machine transitions to S0 requested are:
1. A device's interrupt circuitry should be separated from its wakeup circuitry.
2. Devices cannot be permitted to generate interrupts while they are in the D3 state.
3. Power management event signals should only be generated in the D3 state.