Documentation/arch/arm64/arm-acpi.rst

Source file repositories/reference/linux-study-clean/Documentation/arch/arm64/arm-acpi.rst

File Facts

System
Linux kernel
Corpus path
Documentation/arch/arm64/arm-acpi.rst
Extension
.rst
Size
26965 bytes
Lines
576
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

===================
ACPI on Arm systems
===================

ACPI can be used for Armv8 and Armv9 systems designed to follow
the BSA (Arm Base System Architecture) [0] and BBR (Arm
Base Boot Requirements) [1] specifications.  Both BSA and BBR are publicly
accessible documents.
Arm Servers, in addition to being BSA compliant, comply with a set
of rules defined in SBSA (Server Base System Architecture) [2].

The Arm kernel implements the reduced hardware model of ACPI version
5.1 or later.  Links to the specification and all external documents
it refers to are managed by the UEFI Forum.  The specification is
available at http://www.uefi.org/specifications and documents referenced
by the specification can be found via http://www.uefi.org/acpi.

If an Arm system does not meet the requirements of the BSA and BBR,
or cannot be described using the mechanisms defined in the required ACPI
specifications, then ACPI may not be a good fit for the hardware.

While the documents mentioned above set out the requirements for building
industry-standard Arm systems, they also apply to more than one operating
system.  The purpose of this document is to describe the interaction between
ACPI and Linux only, on an Arm system -- that is, what Linux expects of
ACPI and what ACPI can expect of Linux.


Why ACPI on Arm?
----------------
Before examining the details of the interface between ACPI and Linux, it is
useful to understand why ACPI is being used.  Several technologies already
exist in Linux for describing non-enumerable hardware, after all.  In this
section we summarize a blog post [3] from Grant Likely that outlines the
reasoning behind ACPI on Arm systems.  Actually, we snitch a good portion
of the summary text almost directly, to be honest.

The short form of the rationale for ACPI on Arm is:

-  ACPI’s byte code (AML) allows the platform to encode hardware behavior,
   while DT explicitly does not support this.  For hardware vendors, being
   able to encode behavior is a key tool used in supporting operating
   system releases on new hardware.

-  ACPI’s OSPM defines a power management model that constrains what the
   platform is allowed to do into a specific model, while still providing
   flexibility in hardware design.

-  In the enterprise server environment, ACPI has established bindings (such
   as for RAS) which are currently used in production systems.  DT does not.
   Such bindings could be defined in DT at some point, but doing so means Arm
   and x86 would end up using completely different code paths in both firmware
   and the kernel.

-  Choosing a single interface to describe the abstraction between a platform
   and an OS is important.  Hardware vendors would not be required to implement
   both DT and ACPI if they want to support multiple operating systems.  And,
   agreeing on a single interface instead of being fragmented into per OS
   interfaces makes for better interoperability overall.

-  The new ACPI governance process works well and Linux is now at the same
   table as hardware vendors and other OS vendors.  In fact, there is no
   longer any reason to feel that ACPI only belongs to Windows or that
   Linux is in any way secondary to Microsoft in this arena.  The move of
   ACPI governance into the UEFI forum has significantly opened up the
   specification development process, and currently, a large portion of the
   changes being made to ACPI are being driven by Linux.

Key to the use of ACPI is the support model.  For servers in general, the
responsibility for hardware behaviour cannot solely be the domain of the

Annotation

Implementation Notes