The Windows ACPI driver, Acpi.sys, is an inbox component of the Windows operating system. The responsibilities of Acpi.sys include support for power management and Plug and Play (PnP) device enumeration. On hardware platforms that have an ACPI BIOS, the HAL causes Acpi.sys to be loaded during system startup at the base of the device tree. Windows 10 drivers for ASUS desktops, laptops, and motherboards can be downloaded via ASUS Support. Click Download, enter your motherboard model number, and then filter by your operating system - Windows 10 in this case.
The Windows ACPI driver, Acpi.sys, is an inbox component of the Windows operating system. The responsibilities of Acpi.sys include support for power management and Plug and Play (PnP) device enumeration. On hardware platforms that have an ACPI BIOS, the HAL causes Acpi.sys to be loaded during system startup at the base of the device tree. Acpi.sys acts as the interface between the operating system and the ACPI BIOS. Acpi.sys is transparent to the other drivers in the device tree.
Other tasks performed by Acpi.sys on a particular hardware platform might include reprogramming the resources for a COM port or enabling the USB controller for system wake-up.
In this topic
ACPI devices
The hardware platform vendor specifies a hierarchy of ACPI namespaces in the ACPI BIOS to describe the hardware topology of the platform. For more information, see ACPI Namespace Hierarchy.
For each device described in the ACPI namespace hierarchy, the Windows ACPI driver, Acpi.sys, creates either a filter device object (filter DO) or a physical device object (PDO). If the device is integrated into the system board, Acpi.sys creates a filter device object, representing an ACPI bus filter, and attaches it to the device stack immediately above the bus driver (PDO). For other devices described in the ACPI namespace but not on the system board, Acpi.sys creates the PDO. Acpi.sys provides power management and PnP features to the device stack by means of these device objects. For more information, see Device Stacks for an ACPI Device.
Drivers Microsoft Motherboards Drivers
A device for which Acpi.sys creates a device object is called an ACPI device. The set of ACPI devices varies from one hardware platform to the next, and depends on the ACPI BIOS and the configuration of the motherboard. Note that Acpi.sys loads an ACPI bus filter only for a device that is described in the ACPI namespace and is permanently connected to the hardware platform (typically, this device is integrated into the core silicon or soldered to the system board). Not all motherboard devices have an ACPI bus filter.
All ACPI functionality is transparent to higher-level drivers. These drivers must make no assumptions about the presence or absence of an ACPI filter in any given device stack.
Acpi.sys and the ACPI BIOS support the basic functions of an ACPI device. To enhance the functionality of an ACPI device, the device vendor can supply a WDM function driver. For more information, see Operation of an ACPI Device Function Driver.
An ACPI device is specified by a definition block in the system description tables in the ACPI BIOS. A device's definition block specifies, among other things, an operation region, which is a contiguous block of device memory that is used to access device data. Only Acpi.sys modifies the data in an operation region. The device's function driver can read the data in an operation region but must not modify the data. When called, an operation region handler transfers bytes in the operation region to and from the data buffer in Acpi.sys. The combined operation of the function driver and Acpi.sys is device-specific and is defined in the ACPI BIOS by the hardware vendor. In general, the function driver and Acpi.sys access particular areas in an operation region to perform device-specific operations and retrieve information. For more information, see Supporting an Operation Region.
ACPI control methods
ACPI control methods are software objects that declare and define simple operations to query and configure ACPI devices. Control methods are stored in the ACPI BIOS and are encoded in a byte-code format called ACPI Machine Language (AML). The control methods for a device are loaded from the system firmware into the device's ACPI namespace in memory, and interpreted by the Windows ACPI driver, Acpi.sys.
To invoke a control method, the kernel-mode driver for an ACPI device initiates an IRP_MJ_DEVICE_CONTROL request, which is handled by Acpi.sys. For drivers loaded on ACPI-enumerated devices, Acpi.sys always implements the physical device object (PDO) in the driver stack. For more information, see Evaluating ACPI Control Methods.
ACPI specification
The Advanced Configuration and Power Interface Specification (ACPI 5.0 specification) is available from the Unified Extensible Firmware Interface Forum website.
Revision 5.0 of the ACPI specification introduces a set of features to support low-power, mobile PCs that are based on System on a Chip (SoC) integrated circuits and that implement the connected standby power model. Starting with Windows 8 and later versions, the Windows ACPI driver, Acpi.sys, supports the new features in the ACPI 5.0 specification. For more information, see Windows ACPI design guide for SoC platforms.
ACPI debugging
System integrators and ACPI device driver developers can use the Microsoft AMLI debugger to debug AML code. Because AML is an interpreted language, AML debugging requires special software tools.
For more information about the AMLI debugger, see ACPI Debugging.
Microsoft ACPI source language (ASL) compiler
For information about compiling ACPI Source Language (ASL) into AML, see Microsoft ASL Compiler.
Version 5.0 of the Microsoft ASL compiler supports features in the ACPI 5.0 specification.
The ASL compiler is distributed with the Windows Driver Kit (WDK).
The ASL compiler (asl.exe) is located in the ToolsarmACPIVerify, Toolsarm64ACPIVerify, Toolsx86ACPIVerify, and Toolsx64ACPIVerify directories of the installed WDK, for example, C:Program Files (x86)Windows Kits10Toolsx86ACPIVerify.
-->This article clarifies some confusion that vendors have experienced about how hardware that complies with PCI Power Management (PCI-PM) interacts with device drivers in the operating system and about how PCI-PM integrates with ACPI. For more information, see https://www.uefi.org/specifications
Device drivers and PCI power management
This discussion assumes that you are familiar with how Windows Driver Model (WDM) drivers handle power management events, as described in the current Windows DDK. In general, the responsibilities for device drivers are as follows:
Bus drivers: Bus drivers are responsible for enumerating, configuring, and controlling devices. For PCI-PM, the PCI driver is responsible for reading the PCI-PM registers to determine the capabilities of the hardware. When POWER IRPs request power state changes, the PCI driver writes to the PCI power management registers to set the hardware to different Dx states.
When a device is enabled for wake-up, the PCI driver writes to PCI-PM registers to enable the device to fire PME (ACPI will also take an action, see the next section). Finally, when ACPI determines that the PCI bus is waking the system, the PCI driver scans PCI configuration space looking for which device is asserting PME, disables PME in that device, and notifies the driver for that device.
Device driver: The specific driver for the device is responsible for saving and restoring device context, and requesting power state changes as the policy owner for the device. When the device driver receives a POWER IRP requesting a lower device power state change, the device driver is responsible for saving any proprietary device context needed to later turn on the device. In some cases, there may be nothing to save.
PCI-PM registers are strictly the domain of the PCI driver--the IHV's device driver does not need to access any of these registers. Doing so would cause the system to not work reliably. The device driver's responsibility is to perform only proprietary actions.
Integrating ACPI and PCI PM
Some devices, particularly motherboard video devices in portables, may require both PCI Power Management as well as ACPI Source Language Assembler (ASL) to completely power manage the device. The PCI Power Management registers would control the internal state of a device, such as internal clocks and power planes. ASL would control the external state, such as external clocks and power planes, or in the case of video controllers, ASL would control the video backlights. Note that ASL and PCI-PM can only be combined on motherboard devices.
The OnNow architecture is a layered architecture, handling the integration of the device driver, PCI driver, and ACPI driver (and ASL) naturally. The following scenarios show the order in which drivers are called to handle these devices.
Note
For the above scenarios to work as described, a WDM driver must forward POWER IRPs correctly as described in the current version of the Microsoft Windows DDK.
Drivers Microsoft Motherboards For Hp Pavilion
Scenario 1: Turning off a device
- Device driver: Saves proprietary device state.
- PCI driver: Saves Plug and Play configuration, disables the device (interrupts and BARs), and puts the device in D3 using PCI-PM registers.
- ACPI driver: Runs ASL code (_PS3 and _OFF for power resources no longer in use) to control the state external to the chip.
Scenario 2: PCI power management and device drivers
- ACPI driver: Runs ASL code (_PS0 and _ON for any OnNow required power resources) to control the state external to the chip.
- PCI driver: Puts the device in D0 using PCI-PM registers and restores Plug and Play configuration (interrupts and BARs--these might be different from what the device was previously on).
- Device driver: Restores proprietary context in the device.
Scenario 3: Enabling wake-up
- Device driver: Sets proprietary registers in the chip to enable wake-up. For example, in pattern matching network wake-up, this is when the patterns would be programmed into the adapter.
- PCI driver: Sets the wake-up enable bits in the PCI PM registers to allow the device to assert PME.
- ACPI driver: Enables the GPE in the chip set associated with PME (as described by the _PRW object listed under the root PCI bus).
Scenario 4: Wake-up
- ACPI driver: Wakes and scans the GPE status bits for wake-up events, disabling GPEs for set GPE status bits, and running any _Lxx or _Exx methods associated with set GPE bits. In response to a wake-up notification on the PCI bus, the ACPI driver will complete the PCI driver's WAIT_WAKE IRP to notify the PCI driver that it is waking the system.
- PCI driver: Scans configuration space looking for any devices with a set PME status bit. For each device, it disables PME and completes the WAIT_WAKE IRP for that device to inform the driver that it is asserting wake-up. The PCI driver stops scanning for wake devices when it has made a complete pass through all PCI devices having not found any asserting PME and when PME stops being asserted.
- Device driver: Requests the device be put in D0 (see scenario 2) and sets any proprietary registers in the chip required to handle the wake-up event.
Call to action on PCI power management and device drivers
- Integrate ACPI and PCI-PM capabilities into your devices as described in this article.
- The PCI Power Management specification is available at https://www.pcisig.com. This link leaves the Microsoft.com site.
- ACPI Specification available at https://www.uefi.org/specifications. This link leaves the Microsoft.com site.
- The ACPI Component Architecture (ACPICA) compiler can be found at https://acpica.org/downloads/binary-tools.