arm64上为什么要使用ACPI

翻译自Documenttation/arm64/arm-acpi.txt

ACPI on ARMv8 Servers  
---------------------
    ACPI可用于ARMV8通用服务器设计，以满足ARM SBSA（基于服务器的系统架构规范）和SBBR（基于服务器的启动要求规范）的设计规范要求。需要注意的是， SBSA可以通过简单的检索访问到，但由于ARM IP licensing原因，SBSA需要ARM 账户登陆才能访问。
    ARMv8架构实现了阉割版的ACPI 5.1或更高版本硬件模型， 其引用的规范和相关说明文档通过UEFI论坛管理的，规范书链接为，相关说明链接为。
    如果某个ARMv8系统的设计既不满足SBSA和SBBR规范，也不满足ACPI规范书，那么可以认为此硬件没有使用ACPI。
    上述相关的规范文档对工业标准的ARM服务器提出了相关的标准说明，其适用于多个操作系统。此篇文档的目的是描述ACPI与Linux操作系统的交互，当然仅限于在ARMv8系统上
-- 即：Linux对ACPI的期望和ACPI对Linux的期望(todo)

Why ACPI on ARM?
为什么要在ARM上使用ACPI
----------------
    在描述ACPI与Linux的交互细节前，有必要了解下ARM上为什么要使用ACPI， 毕竟，Linux上已经有不可枚举设备的描述方法（译者注：1、已有的描述方法例如dtb；2、可枚举的设备例如USB， PCIE不需要事先的硬件描述）。
    此小节概括了Grant Likely的博客[2]中关于为什么要在ARM上使用ACPI的原因说明。事实上，这里直接照搬了博客中的概括说明。

ARM上使用ACPI原因简述：
--     ACPI的字节编码（AML）支持描述硬件行为，而DT不支持。对于硬件厂商来说，硬件行为是个关键特性，以支持硬件发布。
--     ACPI的OSPM定义的电源管理模型，对特定的电源管理硬件实现做了实现规范的同时，也提供了灵活的变通。
--     在企业服务器圈子里， ACPI已经在现有的使用产品中建立了一些绑定特性（例如RAS），而DT没有，当然DT也可以定义这些特性，但如果这样做的话，ARM和X86在固件和kernel程序中都需要使用不同的代码
--     在硬件平台与OS之间只选择唯一的硬件抽象描述是重要的，这样硬件厂商就不用被要求去实现DT和ACPI，以支持多种操作系统。而且，统一唯一的描述相对于每个操作系统定义一种描述 更利于相互操作
--     新的ACPI管理方式工作得很好，现在Linux与其他的硬件厂商和OS厂商在同一桌上了，事实上，也没有理由认为ACPI只属于Windows或者Linux在这方面次于Windows。将ACPI纳入UEFI论坛也推进了ACPI规范的发展，目前相当一部分的规范推进是由Linux推进的。

    使用ACPI的关键是支持模型。对于服务器来说，硬件行为不仅仅要对kernel负责，而且要对硬件平台与kernel之间隔离负责，以允许长时间演进。ACPI让OS不用了解每个硬件的细节，OS不用针对每个设备做移植；ACPI让硬件厂商对电源管理行为负责，而不需要关心OS的发布节奏，且OS发布节奏也不受硬件的控制。

    ACPI重要的另一个原因是现有的硬件和OS厂商已经使用ACPI搭建了通用的计算机系统协作机制，基础架构是现成的，绑定特性是现成的，处理过程也是现成的。DT使Linux对直接集成硬件可用支持，但对服务器厂商需要的处理过程没有好的支持。当然，Linux可用去做这些支持，但这样的话，是对已有机制的重复创造。ACPI已经满足硬件厂商所需，微软不会使用DT，硬件厂商这样最后会提供两种不同的固件接口，一种给Linux，一种给Windows。


Kernel Compatibility
内核兼容性
--------------------
    ACPI的主要工作是标准化，以使Linux内核后向兼容。在服务器领域，软硬件都可能使用相当长的时间，ACPI在kernel和固件之间形成长期维护的一致性的抽象接口，不随软件和硬件变化而变化。由于抽闲层的存在，系统可以在不更换内核的情况下进行更新。

    当Linux驱动或子系统第一次使用ACPI实现时，它需要一个特定版本的ACPI规范，即基线。
虽然最早的内核版本第一次提供的基础版本的ACPI可能不是最优的，ACPI固件必须继续演进。当可能需要添加驱动（例如cpu电源管理）
新加的功能不应该破坏旧的内核版本支持。更进一步的，ACPI固件在最新版本内核应该继续可以工作。

Relationship with Device Tree
-----------------------------
    驱动和子系统中的ACPI支持与DT支持不应该在编译阶段就相互互斥。
在启动阶段，内核根据bootloader的启动参数或者内核参数只会选择一种方式。
不管使用的是DT或ACPI， 内核必须都能启动（在编译阶段两种方式都编译进了内核）。

Booting using ACPI tables
-------------------------
    在ARMv8上传递ACPI table给内核的唯一方法是通过UEFI system configuration table。由此很明确的是，ACPI只在通过UEFI启动的系统上支持。

    在ARMv8系统启动时，可以有DT，ACPI table或其他不同的启动模式。如果没有参数指定，内核默认使用DT枚举设备，如果没有DT，有ACPI，内核会尝试使用ACPI。如果也没有ACPI，内核启动不了。如果启动参数中指定acpi=force，内核会先尝试ACPI启动，如果没有ACPI table，会尝试DT。基本思想就是内核会尝试不同的启动可能。

    可以通过acpi=off参数强制不使用ACPI table，这也是默认的模式。