ACPI Explained: Architecture, AML, Tables, and Power States

ACPI Explained: Architecture, AML, Tables, and Power States

The Advanced Configuration and Power Interface (ACPI) is the industry-standard framework that allows operating systems to discover platform hardware, configure devices, manage power states, and respond to system events. It is a fundamental component of modern firmware architecture, connecting BIOS or UEFI firmware with the operating system’s hardware-management subsystem.

ACPI introduced a shift toward Operating System-directed configuration and Power Management (OSPM). Instead of requiring firmware to make every power-management decision independently, the operating system uses ACPI descriptions, control methods, hardware interfaces, and event mechanisms to manage the platform according to its overall workload and power requirements.

For firmware engineers, ACPI involves considerably more than a collection of binary tables. It encompasses the ACPI namespace, ACPI Machine Language (AML), standardized power-state models, hardware register interfaces, interrupt-driven events, and firmware-defined control methods.

This guide explains the ACPI architecture, its principal functions, system and device power states, OSPM responsibilities, runtime components, and the relationships among RSDP, RSDT, XSDT, FADT, FACS, DSDT, and SSDT.

The technical discussion follows the general architecture defined by the ACPI Specification. Individual capabilities and hardware interfaces depend on the specification revision, processor architecture, operating system, and platform implementation.

🔍 1. Introduction to ACPI

#

ACPI defines how firmware describes hardware resources and exposes configuration and power-management capabilities to the operating system.

It provides standardized representations of devices, power resources, processor capabilities, system events, and platform control operations. The operating system interprets these descriptions and applies its own policies to manage the hardware.

What is OSPM?

#

Operating System-directed configuration and Power Management, or OSPM, is the operating-system policy and control model enabled by ACPI.

The OS maintains a global view of system activity, including processor load, application requirements, battery status, device utilization, and thermal constraints. It uses that information to decide when to change power states, adjust processor performance, suspend devices, or transition the entire system into a sleep state.

Firmware supplies the platform description and the interfaces needed to execute those decisions. The operating system remains responsible for coordinating system-wide policy.

For example, when a laptop becomes idle, OSPM can place the processor into an appropriate idle state, reduce the power consumption of inactive devices, and adjust performance according to the current workload. If the system becomes too hot, it can coordinate cooling mechanisms, device restrictions, and processor throttling.

These operations depend on the capabilities reported by the platform. ACPI describes available mechanisms; it does not guarantee that every system implements every feature.

ACPI versus traditional BIOS-managed power management

#

Traditional Advanced Power Management (APM) relied more heavily on firmware-managed power policies and BIOS interfaces.

ACPI shifted much of this responsibility toward the operating system by providing a standardized description of hardware and interfaces through which the OS can control supported platform functions.

The distinction is not that firmware becomes unnecessary. Platform firmware still initializes hardware, publishes ACPI tables, implements platform-specific control methods, and supplies the underlying hardware mechanisms.

Instead, ACPI establishes a division of responsibilities: firmware describes and enables platform capabilities, while the OS coordinates their use according to system-wide policy.

Main goals of ACPI

#

ACPI supports several important objectives:

• Operating-system control: Allows OSPM to coordinate system configuration and power management.
• Hardware abstraction: Describes devices and platform resources through standardized structures and interfaces.
• Power efficiency: Supports transitions among processor, device, and system power states.
• Plug and Play configuration: Allows the OS to discover devices and evaluate resource requirements.
• Platform interoperability: Reduces dependence on proprietary interfaces by providing common mechanisms for device description and control.
• Event-driven management: Supports notification and handling of power, thermal, and hardware events.

The result is a firmware-to-OS contract that enables operating systems to manage diverse hardware platforms through common interfaces.

🏗️ 2. The ACPI and OSPM System Architecture

#

ACPI connects applications and operating-system subsystems to platform hardware through several interacting components.

A simplified architecture is:

Applications and System Services
              |
              v
Operating-System Kernel and OSPM
              |
      +-------+--------+
      |                |
      v                v
ACPI Device Drivers   AML Interpreter
      |                |
      +-------+--------+
              |
              v
   ACPI Tables and Namespace
              |
      +-------+--------+
      |                |
      v                v
ACPI Registers     Platform Control Methods
      |                |
      +-------+--------+
              |
              v
       Platform Hardware

This diagram is conceptual rather than a strict execution sequence. The OS may access fixed hardware interfaces directly, use device drivers, execute AML control methods, or combine these mechanisms according to the platform description.

ACPI tables

#

ACPI tables provide the operating system with information about the hardware platform.

They can describe processor topology, interrupt controllers, fixed hardware register blocks, device resources, power-management capabilities, and platform-specific control methods.

Firmware constructs or installs the relevant tables and makes them discoverable before the operating system takes control. The OS locates the tables, validates them, and builds the corresponding internal representations.

AML interpreter

#

ACPI Machine Language (AML) is a compact bytecode used to represent ACPI namespace objects and executable control methods.

AML is generally generated by compiling ACPI Source Language (ASL), a human-readable language used to describe platform devices, resources, and control behavior.

The OS implements an AML execution environment that evaluates these objects when required. Some AML objects return configuration information, while others perform operations involving hardware registers, embedded controllers, or other platform interfaces.

The AML interpreter is therefore an important part of OSPM, but it is not the entire power-management system. The operating system also needs scheduling policies, device drivers, interrupt handling, resource management, and hardware-specific support.

ACPI registers

#

Some ACPI platforms expose fixed hardware register blocks for power-management control and event handling.

On traditional PC implementations, relevant register locations and capabilities are described through the Fixed ACPI Description Table (FADT).

Examples may include:

• PM1a_EVT_BLK: Primary fixed-event status and enable registers.
• PM1a_CNT_BLK: Primary fixed-feature control registers.
• PM1b_EVT_BLK: Optional secondary fixed-event register block.
• PM1b_CNT_BLK: Optional secondary fixed-feature control register block.

Modern ACPI implementations can use Generic Address Structures to describe register locations, and hardware-reduced ACPI platforms may omit the traditional fixed hardware programming model.

Consequently, developers must inspect the actual FADT and platform flags instead of assuming that every ACPI system has the same register blocks.

Events and interrupts

#

ACPI provides mechanisms for notifying OSPM when platform events occur.

Depending on the hardware model, these can include fixed-feature events, General-Purpose Events (GPEs), Embedded Controller events, and System Control Interrupts (SCIs).

The firmware and operating system cooperate to configure these mechanisms so that relevant hardware conditions can be reported and handled without requiring continuous polling of every device.

⚡ 3. The Ten Major Functions of ACPI

#

ACPI combines hardware description, power-state management, configuration interfaces, and event handling into a common framework.

3.1 System power management

#

ACPI defines system-wide states for working, sleeping, soft-off, and mechanical-off conditions.

OSPM can transition the platform into a supported sleep state, configure permitted wake events, and restore normal operation when an enabled event occurs.

The available states and wake capabilities depend on the platform and firmware implementation.

3.2 Device power management

#

ACPI provides a model for device power states and their transitions.

Devices may operate in D0 when fully active or enter lower-power states such as D1, D2, or D3 when appropriate. The OS selects states according to device requirements, system activity, and supported wake behavior.

Control methods such as _PS0 through _PS3 may participate in device power transitions, while power-resource objects can describe shared resources needed by devices.

These methods are optional and platform-dependent; they are not required for every device.

3.3 Processor idle-state management

#

Processor C-states describe processor idle conditions.

When a logical processor has no work to execute, OSPM can place it into a supported idle state. Deeper states generally reduce power consumption but may introduce greater entry and exit latency.

The operating system selects the appropriate state using the available processor capabilities, latency information, and current workload requirements.

3.4 Processor and device performance management

#

ACPI also supports performance management while the system remains in its working state.

Processor P-states historically describe performance operating points, often involving frequency and voltage changes. T-states describe performance throttling mechanisms on platforms that support them.

Modern processors may use additional hardware-managed performance interfaces, such as Collaborative Processor Performance Control (CPPC), where supported.

Device performance management similarly allows supported hardware to operate at different performance levels according to system policy.

3.5 Plug and Play configuration

#

ACPI describes platform devices and their resource requirements through the ACPI namespace.

Objects can identify devices, report whether they are present or enabled, and describe resources such as memory ranges, I/O ports, interrupt assignments, and DMA requirements.

The OS evaluates these descriptions alongside other system information to enumerate devices and manage resource allocation.

ACPI therefore supports Plug and Play configuration without requiring every platform device to be managed through proprietary firmware calls.

3.6 System event handling

#

ACPI defines mechanisms for reporting and handling events that require operating-system attention.

Examples include:

• Power-button activity.
• Thermal threshold events.
• Lid-state changes.
• Embedded Controller notifications.
• Device hot-plug conditions.
• Other platform-specific events exposed through the ACPI namespace.

The specific event-delivery path depends on the hardware. GPEs and fixed-feature events may generate an SCI, while certain embedded-controller or device events can use other supported interrupt or notification mechanisms.

3.7 Battery and power-source management

#

ACPI defines interfaces through which the OS can obtain battery status and information about power sources.

Common battery-related objects include _BIF and _BST in older interface models, along with newer or alternative mechanisms where supported.

This information allows the OS to display charge state, estimate remaining capacity or time, respond to low-battery conditions, and coordinate power policies.

Charging thresholds and advanced battery-management features may depend on OEM-specific interfaces, embedded-controller capabilities, or vendor software rather than a universal ACPI control method.

3.8 Thermal management

#

ACPI provides a thermal model that allows firmware to describe thermal zones, temperature-related information, and supported cooling or mitigation mechanisms.

OSPM can use this information to coordinate cooling policies, reduce processor performance, or adjust device operation when temperatures approach defined limits.

Thermal behavior depends on the platform’s sensors, cooling hardware, control methods, and the OS thermal-management implementation.

3.9 Embedded Controller integration

#

An Embedded Controller (EC) commonly manages platform-specific functions such as keyboards, fans, batteries, thermal sensors, and power buttons.

ACPI defines mechanisms for describing EC devices and interacting with supported EC interfaces. The OS can communicate through the relevant driver and control-method infrastructure.

The EC implementation remains hardware-specific, even though ACPI supplies a standard framework for its integration with the operating system.

3.10 SMBus and peripheral management

#

System Management Bus (SMBus) interfaces are used by various platform devices, including temperature sensors, EEPROMs, battery components, and other low-bandwidth peripherals.

ACPI can describe SMBus-related devices and controllers in the platform namespace and provide methods or resource information for their use.

However, SMBus electrical behavior and controller transaction protocols are defined by the applicable SMBus specifications, not by ACPI alone.

The combination of ACPI device description, operating-system bus drivers, and platform-specific interfaces allows supported SMBus devices to participate in system configuration and monitoring.

🔋 4. Understanding ACPI Power States

#

ACPI describes power states at several levels. These states are related, but they are not interchangeable.

Global system states describe the overall system condition. S-states describe system sleep or soft-off conditions. D-states describe device power, while C-states describe processor idle conditions within the working system.

Processor performance states such as P-states and throttling states such as T-states describe other aspects of operation and should not be confused with sleep states.

4.1 Global system states: G-states

#

Global system states characterize the system’s overall operating condition.

S5 is the ACPI sleep state corresponding to the G2 soft-off condition in the traditional ACPI model. G2 and S5 are closely related concepts, but they describe different dimensions of the system state model.

G3 is different from a normal OS shutdown: the system must be restarted to return to a working state, and ordinary hardware execution context is not retained.

4.2 Device power states: D-states

#

D-states describe an individual device’s power condition. They do not directly describe the entire system’s state.

Not every device implements every D-state. D1 and D2 are optional, and the details of each state depend on the device and associated specifications.

ACPI control methods can support device state transitions, while power-resource objects describe shared resources that may need to be enabled or disabled.

4.3 Processor idle states: C-states

#

C-states describe processor idle conditions while the system is in the global working state G0.

The familiar C1, C2, and C3 definitions are historical reference points. Modern processors often implement numerous platform-specific and processor-specific idle states, which the OS discovers through supported interfaces such as _CST or hardware-specific mechanisms.

Deeper idle states generally have higher exit latency, so OSPM must balance energy savings against responsiveness.

The exact cache, interconnect, and processor behavior depends on the implementation rather than being identical across every CPU generation.

4.4 System sleep states: S-states

#

S-states describe system sleep and soft-off conditions.

Not every system supports S1, S2, or S3. Many modern platforms emphasize low-power idle within S0, often referred to as Modern Standby in supported Windows implementations, rather than providing traditional S3 suspend-to-RAM behavior.

S4 and S5 are also fundamentally different. S4 supports restoring an operating-system session from a saved image, whereas S5 represents a shutdown that requires a normal OS startup.

The available sleep states and their wake mechanisms depend on firmware, hardware, and operating-system support.

4.5 Processor performance states: P-states and T-states

#

P-states describe processor performance operating points, often associated with changes in frequency and voltage.

When workload demand increases, OSPM may request a higher performance level. When demand decreases, it may reduce performance to improve energy efficiency.

T-states describe processor throttling mechanisms on implementations that support them.

Modern platforms may use CPPC or other hardware-managed performance interfaces instead of relying exclusively on traditional P-state tables. The OS uses whichever mechanism the platform exposes and supports.

The distinction is important: C-states describe processor idle conditions, while P-states and T-states describe performance or throttling behavior during active operation.

🧰 5. OSPM Implementation Responsibilities

#

Implementing OSPM requires much more than parsing ACPI tables. The operating system must interpret the hardware description, manage device resources, process events, and coordinate transitions among supported power states.

A practical implementation can be divided into several functional areas.

5.1 Table discovery and validation

#

The OS must locate the Root System Description Pointer (RSDP), follow the applicable RSDT or XSDT, and parse the tables referenced by the root table.

It must validate table headers, lengths, checksums, and address ranges before using the information.

On UEFI systems, the OS can locate the RSDP through the EFI System Table. Legacy discovery methods exist for older PC-compatible boot environments.

5.2 AML execution and namespace construction

#

The OS must implement an AML interpreter and build the ACPI namespace from the available DSDT and SSDT definitions.

This includes handling namespace objects, evaluating supported control methods, and interpreting resource descriptions.

The interpreter must enforce the language’s execution semantics while interacting correctly with operating-system services and platform hardware.

5.3 Device enumeration and resource management

#

The OS must enumerate ACPI-described devices and evaluate their status, identifiers, and resource requirements.

It must coordinate resource allocation with other operating-system subsystems, including memory management, interrupt controllers, and device drivers.

Where necessary, it must manage ACPI power resources and establish the relationships between dependent devices.

5.4 Hardware register and timer support

#

Where the platform implements the traditional ACPI hardware model, OSPM must support the fixed hardware registers and timing facilities described by the firmware.

Examples include power-management event and control registers, timers, reset registers, and real-time clock wake facilities where supported.

Hardware-reduced ACPI systems follow a different programming model and do not necessarily expose all traditional fixed hardware features.

5.5 Processor and device power management

#

OSPM coordinates processor idle states, performance states, device power states, and transitions between active and low-power operation.

The OS must account for entry and exit latency, device dependencies, wake requirements, thermal conditions, and the current workload.

A state that reduces power consumption may still be unsuitable if it makes a required device unavailable or introduces excessive latency.

5.6 Event and interrupt handling

#

OSPM must configure and process supported fixed events, GPEs, SCIs, EC-related events, and device-specific notifications.

Correct handling requires coordination with interrupt management, device drivers, and ACPI control methods.

An event may require a direct OS response, evaluation of a control method, or a sequence of device-state changes.

5.7 Thermal, battery, and power-source policies

#

The operating system must integrate ACPI information into its thermal, battery, and general power-management policies.

Depending on the platform, this may include reading battery state, responding to thermal thresholds, managing cooling devices, adjusting processor performance, and configuring wake behavior.

These responsibilities often require coordination among several subsystems rather than a single ACPI component.

5.8 Operating-system integration

#

A functional implementation also requires system interfaces through which drivers and applications can influence supported power-management policies.

The OS must coordinate ACPI behavior with the scheduler, device power framework, storage stack, networking subsystem, and platform security controls.

The exact API surface is operating-system-specific. ACPI standardizes the firmware-facing interfaces, not every application-level power-management API.

🧭 6. ACPI Runtime Components

#

ACPI runtime behavior depends on the cooperation of firmware-published tables, hardware interfaces, the operating system’s ACPI implementation, and platform drivers.

ACPI tables

#

Firmware publishes the tables needed for hardware discovery and platform configuration.

Some table contents are generated or finalized during boot because they depend on the detected hardware or current platform configuration. Other content is compiled into firmware images ahead of time.

DSDT and SSDT AML code is generally produced by compiling ASL source. The resulting tables are made available to the OS, which interprets their AML definitions.

Tables may reside in system memory after installation, but the original AML content is not necessarily copied from a single monolithic BIOS blob as one operation. Table construction and publication depend on the firmware architecture.

ACPI registers

#

Where applicable, fixed hardware register blocks expose standardized power-management operations and status information.

Their addresses and capabilities are described by ACPI system description structures such as the FADT.

Control methods may also access operation regions that represent memory, I/O, embedded-controller, or other supported address spaces.

The implementation must ensure that these accesses respect hardware requirements and operating-system ownership.

ACPI firmware

#

Platform firmware is responsible for publishing an accurate description of the hardware and supplying valid control methods and resource information.

Firmware also initializes the platform so that the operating system can use the described interfaces.

Incorrect ACPI definitions can produce symptoms such as devices failing to enumerate, broken suspend/resume behavior, missing thermal controls, or devices that report incorrect power-state capabilities.

The quality of the firmware description is therefore essential to operating-system compatibility.

The overall control sequence

#

The relationship can be summarized as:

Firmware initializes the platform
             |
             v
Firmware publishes ACPI tables
             |
             v
OS discovers RSDP and table hierarchy
             |
             v
OS builds ACPI namespace and interprets AML
             |
             v
OSPM coordinates drivers, registers, and events
             |
             v
Hardware changes configuration or power state

This is a conceptual flow rather than a strictly linear runtime sequence. After initialization, OSPM continually evaluates events and policies and may invoke ACPI methods as required.

📚 7. ACPI System Description Tables

#

ACPI uses a hierarchy of tables to describe hardware, processor topology, interrupt controllers, fixed hardware interfaces, and platform-specific configuration logic.

7.1 Main ACPI tables

#

The RSDT and XSDT provide the root list of system description tables. The operating system typically prefers the XSDT on capable systems because it supports 64-bit physical addresses.

Not all tables are reached through the root table in the same way. For example, the FADT contains addresses for the DSDT and FACS. The FACS is not an ordinary table entry in the RSDT or XSDT.

7.2 RSDP: Locating the ACPI table hierarchy

#

The RSDP is the starting point for ACPI table discovery.

On UEFI systems, the firmware communicates its location through the EFI System Table. Older BIOS-compatible discovery mechanisms can involve scanning specified legacy memory ranges for the RSD PTR signature.

The RSDP contains the address of the RSDT and, for the appropriate revision, the XSDT.

A parser must verify the RSDP revision and checksum requirements rather than assuming that every platform provides the same table-pointer layout.

7.3 RSDT and XSDT

#

The RSDT contains 32-bit physical pointers to other ACPI tables.

The XSDT provides the corresponding 64-bit pointer structure for systems supporting extended physical addresses.

Both tables include standard ACPI headers that identify their lengths and signatures. The OS uses these structures to locate additional tables exposed by the firmware.

7.4 FADT: Fixed ACPI Description Table

#

The FADT describes key characteristics of the platform’s ACPI hardware model.

Depending on the architecture and implementation, it may provide:

• Addresses and lengths of fixed ACPI register blocks.
• Flags describing platform capabilities.
• The address of the DSDT.
• The address of the FACS.
• Information relevant to power management, reset behavior, and legacy compatibility.

The FADT also indicates whether the traditional ACPI hardware programming model is implemented.

On hardware-reduced platforms, some legacy register blocks are not used, and OSPM must follow the applicable alternative interfaces.

7.5 FACS: Firmware ACPI Control Structure

#

The FACS is a shared data structure used for specific firmware/OS coordination functions.

Depending on the ACPI version and platform model, important fields include:

• Hardware Signature: Used in supported contexts to help determine whether the hardware configuration is compatible with a saved S4 state.
• Firmware Waking Vector: A legacy wake-related entry point used by supported resume mechanisms.
• Global Lock: A synchronization mechanism for certain operations shared between the OS and firmware.

The FACS has its own format and is referenced through the FADT rather than being an ordinary ACPI table with the same standard header and checksum structure as the DSDT or FADT.

Modern platforms may use additional or different mechanisms for resume, but the FACS remains important when analyzing firmware implementations that support the relevant interfaces.

7.6 DSDT and SSDT

#

The DSDT provides the principal AML definition block for the platform. It describes devices and control methods that are part of the system’s ACPI namespace.

Common objects and methods include:

• _HID: Hardware identifier.
• _UID: Unique identifier for a device or object.
• _STA: Device status.
• _INI: Initialization method for applicable namespace objects.
• _CRS: Current resource settings.
• _PRS: Possible resource settings where supported.
• _PS0 through _PS3: Device power-state methods when implemented.
• _PR0 through _PR3: Power-resource references associated with device power states.

These objects are defined by the ACPI specification and related device-specific requirements. Not every device implements every method.

SSDTs provide additional namespace definitions. Firmware may publish multiple SSDTs to modularize the platform description, and additional tables can be loaded through supported runtime mechanisms.

This modularity allows platform-specific functionality to be separated into logical groups instead of placing every device and control method into one large DSDT.

7.7 Typical ACPI discovery chain

#

The discovery relationships are best represented as:

RSDP
  |
  +--> RSDT / XSDT
  |       |
  |       +--> FADT
  |       |      |
  |       |      +--> DSDT
  |       |      +--> FACS
  |       |
  |       +--> MADT
  |       +--> SSDT
  |       +--> Other tables
  |
  +--> Root-table checksum and revision validation

This structure is central to firmware debugging. A valid RSDP does not guarantee that every referenced table is valid, and a correct FADT does not guarantee that the AML namespace behaves correctly.

Firmware engineers should validate both table integrity and the correctness of the referenced structures.

🛠️ 8. ACPI Firmware Development and Debugging

#

ACPI debugging requires checking both the binary table structure and the behavior of the control methods executed by the operating system.

8.1 Inspecting ACPI tables

#

A common starting point is to dump the platform’s ACPI tables and inspect their headers, signatures, lengths, checksums, and references.

On Linux, tools such as acpidump can retrieve tables from the running system. The resulting data can be examined using AML tools such as iasl, which can disassemble AML to ASL-like source for analysis.

When validating the table hierarchy, check:

• The location and revision of the RSDP.
• The addresses and lengths of the RSDT or XSDT.
• The signatures and checksums of referenced tables.
• The FADT pointers to the DSDT and FACS.
• The consistency of device definitions and resource declarations.

8.2 Disassembling AML

#

AML can be difficult to inspect directly because it is a compact binary representation rather than a human-readable source language.

Disassembling the relevant tables into ASL-like text can make it easier to understand the namespace, device hierarchy, control methods, and resource declarations.

However, disassembly does not automatically recover the original source structure or comments. Macros, build-time definitions, and source-level organization may have been lost during compilation.

When possible, compare disassembled tables with the original firmware source and the definitions generated by the platform build system.

8.3 Common ACPI failure symptoms

#

Troubleshooting should distinguish a malformed table from an incorrect control method and from an OS driver or hardware problem.

A table can pass structural validation while still describing incorrect resources or implementing methods that fail at runtime.

✅ 9. Summary and Frequently Asked Questions

#

What is ACPI?

#

ACPI is a standardized framework for describing hardware and supporting operating-system-directed configuration and power management.

It combines system description tables, the ACPI namespace, AML control methods, register interfaces, and event mechanisms to let the operating system manage supported hardware capabilities.

Are ACPI tables created dynamically during BIOS POST?

#

ACPI tables are published by firmware before the operating system takes control, but not every table is necessarily constructed from scratch during POST.

Some table content is compiled into the firmware image from ASL source, while other fields or tables may be generated or finalized dynamically according to the platform configuration.

The OS locates and parses the tables through the RSDP and the root-table hierarchy. SSDTs may provide modular additions to the ACPI namespace, including through supported dynamic-loading mechanisms.

Is AML responsible for all ACPI hardware control?

#

No. AML is an important part of ACPI, but the operating system also uses device drivers, fixed hardware registers where supported, interrupt mechanisms, and other platform interfaces.

Some operations can be performed through standardized hardware registers without invoking AML control methods. Other platform functions depend on AML-defined methods and device-specific logic.

What is the relationship between G-states, S-states, D-states, and C-states?

#

These state families describe different levels of power management.

• G-states describe the overall system condition.
• S-states describe system sleep and soft-off states.
• D-states describe device power states.
• C-states describe processor idle states while the system is working.

P-states and T-states describe additional performance and throttling behaviors, respectively.

Key takeaways

#

• ACPI and OSPM: Firmware describes platform capabilities, while the OS coordinates system configuration and power policy.
• Tables and AML: System description tables expose hardware information and control methods that the OS interprets.
• Power management: Global, system, device, and processor states describe different aspects of system operation and sleep behavior.
• Event handling: Fixed events, GPEs, SCIs, EC interfaces, and device notifications allow the OS to respond to platform conditions.
• Table discovery: The normal relationship is RSDP → RSDT/XSDT → system description tables, with the FADT providing references to the DSDT and FACS.
• Firmware correctness: Valid table structures, accurate device descriptions, correct resource assignments, and reliable control methods are all necessary for robust ACPI behavior.

Ultimately, ACPI is the contract through which platform firmware describes hardware capabilities and exposes supported control mechanisms to the operating system. For BIOS and UEFI engineers, understanding that contract is essential to developing compatible devices, reliable power transitions, correct thermal behavior, and predictable OS integration.