工程师 - ACPI介绍_2

Advanced Configuration and Power Interface (ACPI) Introduction and Overview

Version 1.4 : 26 April 2016

Copyright © 2016 Intel Corporation. All rights reserved.

*Other names and brands may be claimed as the property of others.

本章提供了高级配置和电源接口 (ACPI) 的高级概述。为便于理解 ACPI，本节将重点放在有关 ACPI 的概括性陈述上，而不会讨论有关 ACPI 的每一个可能的例外情况或细节。ACPI 规范的其余部分对 ACPI 内部工作原理的详细介绍远多于此处讨论的内容，建议使用 ACPI 的开发人员阅读。

This chapter provides a high­level overview of the Advanced Configuration and Power Interface (ACPI). To make it easier to understand ACPI, this section focuses on broad and general statements about ACPI and does not discuss every possible exception or detail about ACPI. The rest of the the ACPI specification provides much greater detail about the inner workings of ACPI than is discussed here, and is recommended reading for developers using ACPI.

History of ACPI

ACPI 是英特尔、微软*、东芝*、惠普*和 Phoenix* 在 1990 年代中期合作开发的。在 ACPI 开发之前，操作系统（OS）主要使用 BIOS（基本输入/输出系统）接口进行电源管理以及设备发现和配置。这种电源管理方法利用操作系统调用系统 BIOS 本机进行电源管理的能力。BIOS 还用于发现系统设备，并在探测输入/输出（I/O）的基础上加载驱动程序，并尝试将正确的驱动程序与正确的设备相匹配（即插即用）。设备的位置也可以硬编码在 BIOS 中，因为平台本身是不可数的。

这些解决方案在三个关键方面存在问题。首先，操作系统应用程序的行为可能会受到 BIOS 配置的电源管理设置的负面影响，导致系统在演示或其他不方便的时候进入睡眠状态。其次，每个系统的电源管理界面都是专有的。这就要求开发人员学习如何为每个系统配置电源管理。最后，各种设备的默认设置也可能相互冲突，导致设备崩溃、行为异常或无法识别。

ACPI 的开发就是为了解决这些问题和其他问题。

ACPI was developed through collaboration between Intel, Microsoft*, Toshiba*, HP*, and Phoenix* in the mid­1990s. Before the development of ACPI, operating systems (OS) primarily used BIOS (Basic Input/Output System) interfaces for power management and device discovery and configuration. This power management approach used the OS’s ability to call the system BIOS natively for power management. The BIOS was also used to discover system devices and load drivers based on probing input/output (I/O) and attempting to match the correct driver to the correct device (plug and play). The location of devices could also be hard coded within the BIOS because the platform itself was non­enumerable.

These solutions were problematic in three key ways. First, the behavior of OS applications could be negatively affected by the BIOS­configured power management settings, causing systems to go to sleep during presentations or other inconvenient times. Second, the power management interface was proprietary on each system. This required developers to learn how to configure power management for each individual system. Finally, the default settings for various devices could also conflict with each other, causing devices to crash, behave erratically, or become undiscoverable.

ACPI was developed to solve these problems and others.

What is ACPI?

ACPI 首先可以理解为一个独立于架构的电源管理和配置框架，它在主机操作系统中形成了一个子系统。该框架建立了一个硬件寄存器集，用于定义电源状态（睡眠、休眠、唤醒等）。硬件寄存器集可对专用硬件和通用硬件进行操作。

标准 ACPI 框架和硬件寄存器集的主要目的是实现电源管理和系统配置，而无需直接从操作系统本地调用固件。ACPI 作为系统固件（BIOS）和操作系统之间的接口层，有一定的限制和规则。箭头表示数据流。

ACPI can first be understood as an architecture ­independent power management and configuration framework that forms a subsystem within the host OS. This framework establishes a hardware register set to define power states (sleep, hibernate, wake, etc). The hardware register set can accommodate operations on dedicated hardware and general purpose hardware.

The primary intention of the standard ACPI framework and the hardware register set is to enable power management and system configuration without directly calling firmware natively from the OS. ACPI serves as an interface layer between the system firmware (BIOS) and the OS, with certain restrictions and rules. The arrows indicate data flows.

[ ACPI overview ] 

从根本上说，ACPI 定义了系统固件和操作系统共享的两类数据结构：数据表和定义块。这些数据结构是固件和操作系统之间的主要通信机制。数据表存储原始数据，由设备驱动程序使用。定义块由字节代码组成，可由解释器执行。

Fundamentally, ACPI defines two types of data structures which are shared between the system firmware and the OS: data tables and definition blocks. These data structures are the primary communication mechanism between the firmware and the OS. Data tables store raw data and are consumed by device drivers. Definition blocks consist of byte code that is executable by an interpreter.

[ACPI structure]

ACPI 子系统由两类数据结构组成：数据表和定义块。

The ACPI subsystem consists of  two types of data structures:  data tables and definition blocks.

初始化时，AML 解释器将定义块中的字节码提取为可枚举对象。

Upon initialization, the AML  interpreter extracts the byte  code in the definition blocks as  enumerable objects.

这些可枚举对象的集合构成了名为 ACPI 命名空间的操作系统结构。

This collection of enumerable  objects forms the OS construct  called the ACPI namespace. 

对象既可以有直接定义的值，或者也可以有必须由 AML 解释器进行评估和解释的值。

Objects can either have a  directly defined value or must be  evaluated and interpreted by  the AML interpreter.

AML 解释器在操作系统的指导下，评估对象并与系统硬件连接，以执行必要的操作。

The AML interpreter, directed by  the OS, evaluates objects and  interfaces with system hardware  to perform necessary  operations.

该定义块字节代码由 ACPI 源语言（ASL）代码编译而成。ASL 是用于定义 ACPI 对象和编写控制方法的语言。ASL 编译器将 ASL 翻译成 ACPI 机器语言（AML）字节码。AML 是 ACPI AML 解释器处理的语言，如下图所示。

This definition block byte code is compiled from the  ACPI Source Language (ASL) code. ASL is the language used to define ACPI objects and to write control methods. An ASL compiler translates ASL into  ACPI Machine Language(AML) byte code. AML is the language processed by the ACPI AML interpreter, as shown in the following Figure.

[ ASL and AML ]

ACPI 源代码 (ASL) 用于定义对象和控制方法。

ACPI Source Langauge (ASL) code is  used to define objects and control  methods.

ASL 编译器将 ASL 翻译成 ACPI 机器语言 (AML) 字节代码，包含在 ACPI 定义块中。

The ASL compiler translates ASL into  ACPI Machine Language (AML) byte  code contained within the ACPI  definition blocks.

定义块由识别表头和可由 AML 解释器执行的字节码组成。

Definition blocks consist of an  identifying table header and byte  code that is executable by an AML  interpreter.

AML 解释器执行字节代码并评估定义块中的对象，使字节代码能够执行循环结构、条件评估、访问定义的地址空间以及执行应用程序所需的其他操作。AML 解释器可以读/写访问定义的地址空间，包括系统内存、I/O、PCI 配置等。它通过定义称为对象的入口点来访问这些地址空间。对象可以是直接定义的值，也可以是必须由 AML 解释器评估和解释的值。

The AML interpreter executes byte code and evaluates objects in the definition blocks to allow the byte code to perform loop constructs, conditional evaluations, access defined address spaces, and perform other operations that applications require. The AML interpreter has read/write access to defined address spaces, including system memory, I/O, PCI configuration, and more. It accesses these address spaces by defining entry points called objects. Objects can either have a directly defined value or else must be evaluated and interpreted by the AML interpreter.

这种可枚举对象的集合是一种操作系统结构，称为 ACPI 命名空间。命名空间是系统中 ACPI 设备的分层表示。系统总线是这些 ACPI 设备的枚举根。在其他总线上可枚举的设备，如 PCI 或 USB 设备，通常不会在命名空间中枚举。相反，它们自己的总线会枚举设备并加载驱动程序。不过，所有可枚举总线都有一种编码技术，允许 ACPI 对设备的特定总线地址进行编码，以便在 ACPI 中找到它们，尽管 ACPI 通常不会加载这些设备的驱动程序。

This collection of enumerable objects is an OS construct called the ACPI namespace. The namespace is a hierarchical representation of the ACPI devices on a system. The system bus is the root of enumeration for these ACPI devices. Devices that are enumerable on other buses, like PCI or USB devices, are usually not enumerated in the namespace. Instead, their own buses enumerate the devices and load their drivers. However, all enumerable buses have an encoding technique that allows ACPI to encode the bus-­specific addresses of the devices so they can be found in ACPI, even though ACPI usually does not load drivers for these devices.

一般来说，具有 _HID 对象（硬件标识对象）的设备会被 ACPI 枚举并加载驱动程序。具有_ADR对象（物理地址对象）的设备通常不会被ACPI枚举，通常也不会被ACPI加载驱动程序。_ADR 设备通常可以执行所有必要的功能，而无需 ACPI 参与，但如果设备驱动程序无法执行某项功能，或者驱动程序需要与系统固件通信，则 ACPI 可以评估对象以执行所需的功能。

Generally, devices that have a _HID object ( hardware identificationobject) are enumerated and have their drivers loaded by ACPI. Devices that have an _ADR object ( physical address object) are usually not enumerated by ACPI and generally do not have their drivers loaded by ACPI. _ADR devices usually can perform all necessary functions without involving ACPI, but in cases where the device driver cannot perform a function, or if the driver needs to communicate to system firmware, ACPI can evaluate objects to perform the needed function.

例如，PCI 不支持本地热插拔。不过，PCI 可以使用 ACPI 评估对象并定义方法，让 ACPI 填入在 PCI 上执行热插拔所需的功能。

As an example of this, PCI does not support native hotplug. However, PCI can use ACPI to evaluate objects and define methods that allow ACPI to fill in the functions necessary to perform hotplug on PCI.

ACPI 的另一个方面是运行时模型，用于处理系统运行期间发生的任何 ACPI 中断事件。ACPI 会根据需要继续评估对象，以处理这些事件。这种基于中断的运行时模型将在下文的运行时模型部分详细讨论。

An additional aspect of ACPI is a runtime model that handles any ACPI interrupt events that occur during system operation. ACPI continues to evaluate objects as necessary to handle these events. This interrupt­-based runtime model is discussed in greater detail in the Runtime model section below.

ACPI initialization

了解 ACPI 工作原理的最佳方法是按时间顺序排列。当用户启动系统时，系统固件会完成设置、初始化和自检。

The best way to understand how ACPI works is chronologically. The moment the user powers up the system, the system firmware completes its setup, initialization, and self tests.

[ ACPI initialization ]

在将控制权移交给 boostrap 载入器之前，系统固件会根据需要利用运行时可用的信息更新 ACPI 表。

System firmware updates the  ACPI tables as necessary with  information only available at  runtime before handing off  control to the boostrap loader.

XSDT 是操作系统 ACPI 子系统使用的第一个表，包含系统中大多数其他 ACPI 表的地址。

The XSDT is the first table used  by the OS's ACPI subsystem and  contains the addresses of most  of the other ACPI tables on the  system.

XSDT 指向 FADT、SSDT 和其他主要 ACPI 表。

The XSDT points to the FADT,  the SSDTs, and other major ACPI  tables.

FADT 将 ACPI 子系统导向 DSDT，由于 DSDT 是包含定义块的第一个表，因此它是命名空间的起点。

The FADT directs the ACPI  subsystem to the DSDT, which is the  beginning of the namespace by  virtue of being the first table that  contains a definition block.

然后，ACPI 子系统使用 DSDT，并开始根据定义块构建 ACPI 命名空间。XSDT 也会指向 SSDT，并将它们添加到名称空间中。

The ACPI subsystem then  consumes the DSDT and begins  building the ACPI namespace  from the definition blocks. The  XSDT also points to the SSDTs  and adds them to the  namespace.

然后，系统固件会使用固件初始化过程中获得的信息，根据需要更新 ACPI 表，使其包含各种平台配置和电源接口数据，然后再将控制权传递给引导加载程序。扩展根系统描述表（XSDT）是 ACPI 子系统使用的第一个表，包含系统中大多数其他 ACPI 表的地址。XSDT 指向固定 ACPI 描述表（FADT）以及操作系统在初始化过程中处理的其他主要表。操作系统初始化后，FADT 会将 ACPI 子系统导向差异化系统描述表（DSDT），它是命名空间的开端，因为它是包含定义块的第一个表。

The system firmware then uses information obtained during firmware initialization to update the ACPI tables as necessary with various platform configurations and power interface data, before passing control to the bootstrap loader. The  extended root system description table (XSDT) is the first table used by the ACPI subsystem and contains the addresses of most of the other ACPI tables on the system. The XSDT points to the  fixed ACPI description table (FADT) as well as other major tables that the OS processes during initialization. After the OS initializes, the FADT directs the ACPI subsystem to the differentiated system description table (DSDT), which is the beginning of the namespace because it is the first table that contains a definition block.

然后，ACPI 子系统会处理 DSDT，并开始根据 ACPI 定义块构建命名空间。XSDT 还会指向辅助系统描述表 (SSDT)，并将其添加到命名空间中。ACPI 数据表为操作系统提供有关系统硬件的原始数据。

The ACPI subsystem then processes the DSDT and begins building the namespace from the ACPI definition blocks. The XSDT also points to the  secondary system description tables (SSDTs) and adds them to the namespace. The ACPI data tables give the OS raw data about the system hardware.

操作系统根据 ACPI 表建立命名空间后，就开始遍历命名空间，并为命名空间中遇到的所有 _HIDdevices 加载设备驱动程序。

After the OS has built the namespace from the ACPI tables, it begins traversing the namespace and loading device drivers for all the  _HIDdevices it encounters in the namespace.

Runtime model

系统启动并运行后，ACPI 与操作系统合作，通过 ACPI 系统控制中断（SCI）处理程序处理任何 ACPI 中断事件。SCI 在整个系统中多路复用，以管理 ACPI 中断事件。

After the system is up and running, ACPI works with the OS to handle any ACPI interrupt events that occur via the ACPI  system control interrupt(SCI) handler. This interrupt invokes ACPI events in one of two general ways: fixed events and  general purpose events(GPEs).The SCI is multiplexed throughout the system to manage ACPI interrupt events.

固定事件是在 ACPI 规范中具有预定义含义的 ACPI 事件。这些固定事件包括按下电源按钮或 ACPI 定时器溢出等操作。这些事件由操作系统处理程序直接处理。

Fixed events are ACPI events that have a predefined meaning in the ACPI specification. These fixed events include actions like pressing the power button or ACPI timer overflows. These events are handled directly by the OS handlers.

GPE 是 ACPI 规范未预定义的 ACPI 事件。这些事件通常通过评估控制方法来处理，控制方法是命名空间中的对象，可以访问系统硬件。当 ACPI 子系统使用 AML 解释器评估控制方法时，GPE 对象会根据操作系统的实现来处理事件。通常情况下，这可能涉及向设备发出通知，以调用设备驱动程序执行某项功能。

GPEs are ACPI events that are not predefined by the ACPI specification. These events are usually handled by evaluating control methods, which are objects in the namespace and can access system hardware. When the ACPI subsystem evaluates the control method with the AML interpreter, the GPE object handles the events according to the OS’s implementation. Typically this might involve issuing a notification to a device to invoke the device driver to perform a function.

我们将在下一节讨论这种运行时模型的一个通用示例。

We discuss a generic example of this runtime model in the next section.

Thermal event example

ACPI 包含一个散热模型，允许系统主动（通过执行打开风扇等操作）或被动（通过执行节流处理器等操作）降低系统功耗来控制系统温度。我们可以使用下图所示的一个通用热事件示例来演示 ACPI 运行时模型是如何工作的。

ACPI includes a thermal model to allow systems to control the system temperature either actively (by performing actions like turning a fan on) or passively by reducing the amount of power the system uses (by performing actions like throttling the processor). We can use an example of a generic thermal event shown in the following Figure to demonstrate how the ACPI runtime model works.

[ Runtime thermal event ]

系统最初在命名空间中找到热区时，会加载热区处理程序来评估热区，以确定温度和跳闸点。

When the system initially finds a  thermal zone[1] in the namespace,  it loads the thermal zone handler to  evaluate the thermal zone to  determine the temperature and trip  points.

当温度在运行期间达到跳变点时，就会发生通用事件。

When the temperature reaches a  trip point during runtime, a general  purpose event [2] occurs.

热区事件会通过 ACPI 系统控制中断 (SCI) 导致中断发生。

The thermal zone event causes an  interrupt via the ACPI system  control interrupt (SCI) [3] to occur.

操作系统收到中断后，处理程序会在命名空间中搜索与 GPE 中断相对应的控制方法对象。找到后，处理程序会对该对象进行评估。

When the OS receives the interrupt,  the handler searches the  namespace for the control method  object [4] corresponding to the GPE  interrupt. Upon finding it, the  handler evaluates that object.

然后，热区处理程序会采取任何必要的措施来处理该事件。

The thermal zone handler then  takes whatever actions are  necessary to handle the event [5].

ACPI 热敏区包括读取当前系统温度和跳闸点的控制方法。

1. 操作系统最初在命名空间中找到热敏区时，会加载热敏区驱动程序，该驱动程序会评估热敏区，以获取当前温度和跳闸点。

2. 当系统组件升温到足以触发跳闸点时，就会发生热区 GPE。

3. GPE 会通过 SCI 发出中断。ACPI 子系统收到中断后，首先会检查是否发生了任何固定事件。在本例中，热区事件是 GPE，因此没有固定事件发生。

4. ACPI 子系统然后在命名空间中搜索与中断 GPE 编号匹配的控制方法。找到后，ACPI 子系统会评估控制方法，然后访问硬件和/或通知热区处理程序。

5. 然后，操作系统的热区处理程序会采取任何必要的措施来处理该事件，包括可能访问硬件。

ACPI 是一个非常强大的接口实现。热区跳闸点可以通知系统打开风扇、降低设备性能、读取温度、关闭系统，或根据需要采取这些行动和其他行动的任意组合。

该运行时模型用于整个系统，以管理在系统运行期间发生的所有 ACPI 事件。

The ACPI thermal zone includes control methods to read the current system temperature and trip points.

1. When the OS initially finds a thermal zone in the namespace, it loads the thermal zone driver, which evaluates the thermal zone to obtain the current temperature and  trip points.

2. When a system component heats up enough to trigger a trip point, a thermal zone GPE occurs.

3. The GPE causes an interrupt via the SCI to occur. When the ACPI subsystem receives the interrupt, it first checks whether any fixed events have occurred. In this example, the thermal zone event is a GPE, so no fixed event has occurred.

4. The ACPI subsystem then searches the namespace for the control method that matches the GPE number of the interrupt. Upon finding it, the ACPI subsystem evaluates the control method, which might then access hardware and/or notify the thermal zone handler.

5. The operating system’s thermal zone handler then takes whatever actions are necessary to handle the event, including possibly accessing hardware.

ACPI is a very robust interface implementation. The thermal zone trip point could notify the system to turn on a fan, reduce a device’s performance, read the temperature, shut down the system, or any combination of these and other actions depending on the need.

This runtime model is used throughout the system to manage all of the ACPI events that occur during system operation.

Summary

ACPI 可以说是一个由概念和接口组成的框架，这些概念和接口的实现在主机操作系统中形成了一个子系统。ACPI 表、处理程序、解释器、命名空间、事件和中断模型共同构成了 ACPI 的实现，在主机操作系统中创建了 ACPI 子系统。从这个意义上说，ACPI 是系统硬件/固件与操作系统和操作系统应用程序之间的接口，用于配置和电源管理。这就为各种操作系统提供了一种标准化的方式，通过 ACPI 命名空间来支持电源管理和配置。

ACPI 命名空间是系统中所有 ACPI 设备的可枚举分层表示，用于查找和加载系统中 ACPI 设备的驱动程序。命名空间可以通过实时评估对象和发送中断来实现动态功能，同时限制操作系统调用本地系统固件代码。这样，设备制造商就能在设备中编码自己的指令和事件。它还通过实施标准化的电源管理接口，减少了不兼容性和不稳定性。

ACPI can best be described as a framework of concepts and interfaces that are implemented to form a subsystem within the host OS. The ACPI tables, handlers, interpreter, namespace, events, and interrupt model together form this implementation of ACPI, creating the ACPI subsystem within the host OS. In this sense, ACPI is the interface between the system hardware/firmware and the OS and OS applications for configuration and power management. This gives various OS a standardized way to support power management and configuration via the ACPI namespace.

The ACPI namespace is the enumerable, hierarchical representation of all ACPI devices on the system and is used to both find and load drivers for ACPI devices on the system. The namespace can be dynamic by evaluating objects and sending interrupts in real time, all while restricting the OS from calling native system firmware code. This enables device manufacturers to code their own instructions and events into devices. It also reduces incompatibility and instability by implementing a standardized power management interface.

参考：

https://www.intel.com/content/www/us/en/developer/topic-technology/open/acpica/overview.html