389 lines
17 KiB
Plaintext
Executable file
389 lines
17 KiB
Plaintext
Executable file
ACPI Device Tree - Representation of ACPI Namespace
|
|
|
|
Copyright (C) 2013, Intel Corporation
|
|
Author: Lv Zheng <lv.zheng@intel.com>
|
|
|
|
|
|
Abstract:
|
|
|
|
The Linux ACPI subsystem converts ACPI namespace objects into a Linux
|
|
device tree under the /sys/devices/LNXSYSTEM:00 and updates it upon
|
|
receiving ACPI hotplug notification events. For each device object in this
|
|
hierarchy there is a corresponding symbolic link in the
|
|
/sys/bus/acpi/devices.
|
|
This document illustrates the structure of the ACPI device tree.
|
|
|
|
|
|
Credit:
|
|
|
|
Thanks for the help from Zhang Rui <rui.zhang@intel.com> and Rafael J.
|
|
Wysocki <rafael.j.wysocki@intel.com>.
|
|
|
|
|
|
1. ACPI Definition Blocks
|
|
|
|
The ACPI firmware sets up RSDP (Root System Description Pointer) in the
|
|
system memory address space pointing to the XSDT (Extended System
|
|
Description Table). The XSDT always points to the FADT (Fixed ACPI
|
|
Description Table) using its first entry, the data within the FADT
|
|
includes various fixed-length entries that describe fixed ACPI features
|
|
of the hardware. The FADT contains a pointer to the DSDT
|
|
(Differentiated System Descripition Table). The XSDT also contains
|
|
entries pointing to possibly multiple SSDTs (Secondary System
|
|
Description Table).
|
|
|
|
The DSDT and SSDT data is organized in data structures called definition
|
|
blocks that contain definitions of various objects, including ACPI
|
|
control methods, encoded in AML (ACPI Machine Language). The data block
|
|
of the DSDT along with the contents of SSDTs represents a hierarchical
|
|
data structure called the ACPI namespace whose topology reflects the
|
|
structure of the underlying hardware platform.
|
|
|
|
The relationships between ACPI System Definition Tables described above
|
|
are illustrated in the following diagram.
|
|
|
|
+---------+ +-------+ +--------+ +------------------------+
|
|
| RSDP | +->| XSDT | +->| FADT | | +-------------------+ |
|
|
+---------+ | +-------+ | +--------+ +-|->| DSDT | |
|
|
| Pointer | | | Entry |-+ | ...... | | | +-------------------+ |
|
|
+---------+ | +-------+ | X_DSDT |--+ | | Definition Blocks | |
|
|
| Pointer |-+ | ..... | | ...... | | +-------------------+ |
|
|
+---------+ +-------+ +--------+ | +-------------------+ |
|
|
| Entry |------------------|->| SSDT | |
|
|
+- - - -+ | +-------------------| |
|
|
| Entry | - - - - - - - -+ | | Definition Blocks | |
|
|
+- - - -+ | | +-------------------+ |
|
|
| | +- - - - - - - - - -+ |
|
|
+-|->| SSDT | |
|
|
| +-------------------+ |
|
|
| | Definition Blocks | |
|
|
| +- - - - - - - - - -+ |
|
|
+------------------------+
|
|
|
|
|
OSPM Loading |
|
|
\|/
|
|
+----------------+
|
|
| ACPI Namespace |
|
|
+----------------+
|
|
|
|
Figure 1. ACPI Definition Blocks
|
|
|
|
NOTE: RSDP can also contain a pointer to the RSDT (Root System
|
|
Description Table). Platforms provide RSDT to enable
|
|
compatibility with ACPI 1.0 operating systems. The OS is expected
|
|
to use XSDT, if present.
|
|
|
|
|
|
2. Example ACPI Namespace
|
|
|
|
All definition blocks are loaded into a single namespace. The namespace
|
|
is a hierarchy of objects identified by names and paths.
|
|
The following naming conventions apply to object names in the ACPI
|
|
namespace:
|
|
1. All names are 32 bits long.
|
|
2. The first byte of a name must be one of 'A' - 'Z', '_'.
|
|
3. Each of the remaining bytes of a name must be one of 'A' - 'Z', '0'
|
|
- '9', '_'.
|
|
4. Names starting with '_' are reserved by the ACPI specification.
|
|
5. The '\' symbol represents the root of the namespace (i.e. names
|
|
prepended with '\' are relative to the namespace root).
|
|
6. The '^' symbol represents the parent of the current namespace node
|
|
(i.e. names prepended with '^' are relative to the parent of the
|
|
current namespace node).
|
|
|
|
The figure below shows an example ACPI namespace.
|
|
|
|
+------+
|
|
| \ | Root
|
|
+------+
|
|
|
|
|
| +------+
|
|
+-| _PR | Scope(_PR): the processor namespace
|
|
| +------+
|
|
| |
|
|
| | +------+
|
|
| +-| CPU0 | Processor(CPU0): the first processor
|
|
| +------+
|
|
|
|
|
| +------+
|
|
+-| _SB | Scope(_SB): the system bus namespace
|
|
| +------+
|
|
| |
|
|
| | +------+
|
|
| +-| LID0 | Device(LID0); the lid device
|
|
| | +------+
|
|
| | |
|
|
| | | +------+
|
|
| | +-| _HID | Name(_HID, "PNP0C0D"): the hardware ID
|
|
| | | +------+
|
|
| | |
|
|
| | | +------+
|
|
| | +-| _STA | Method(_STA): the status control method
|
|
| | +------+
|
|
| |
|
|
| | +------+
|
|
| +-| PCI0 | Device(PCI0); the PCI root bridge
|
|
| +------+
|
|
| |
|
|
| | +------+
|
|
| +-| _HID | Name(_HID, "PNP0A08"): the hardware ID
|
|
| | +------+
|
|
| |
|
|
| | +------+
|
|
| +-| _CID | Name(_CID, "PNP0A03"): the compatible ID
|
|
| | +------+
|
|
| |
|
|
| | +------+
|
|
| +-| RP03 | Scope(RP03): the PCI0 power scope
|
|
| | +------+
|
|
| | |
|
|
| | | +------+
|
|
| | +-| PXP3 | PowerResource(PXP3): the PCI0 power resource
|
|
| | +------+
|
|
| |
|
|
| | +------+
|
|
| +-| GFX0 | Device(GFX0): the graphics adapter
|
|
| +------+
|
|
| |
|
|
| | +------+
|
|
| +-| _ADR | Name(_ADR, 0x00020000): the PCI bus address
|
|
| | +------+
|
|
| |
|
|
| | +------+
|
|
| +-| DD01 | Device(DD01): the LCD output device
|
|
| +------+
|
|
| |
|
|
| | +------+
|
|
| +-| _BCL | Method(_BCL): the backlight control method
|
|
| +------+
|
|
|
|
|
| +------+
|
|
+-| _TZ | Scope(_TZ): the thermal zone namespace
|
|
| +------+
|
|
| |
|
|
| | +------+
|
|
| +-| FN00 | PowerResource(FN00): the FAN0 power resource
|
|
| | +------+
|
|
| |
|
|
| | +------+
|
|
| +-| FAN0 | Device(FAN0): the FAN0 cooling device
|
|
| | +------+
|
|
| | |
|
|
| | | +------+
|
|
| | +-| _HID | Name(_HID, "PNP0A0B"): the hardware ID
|
|
| | +------+
|
|
| |
|
|
| | +------+
|
|
| +-| TZ00 | ThermalZone(TZ00); the FAN thermal zone
|
|
| +------+
|
|
|
|
|
| +------+
|
|
+-| _GPE | Scope(_GPE): the GPE namespace
|
|
+------+
|
|
|
|
Figure 2. Example ACPI Namespace
|
|
|
|
|
|
3. Linux ACPI Device Objects
|
|
|
|
The Linux kernel's core ACPI subsystem creates struct acpi_device
|
|
objects for ACPI namespace objects representing devices, power resources
|
|
processors, thermal zones. Those objects are exported to user space via
|
|
sysfs as directories in the subtree under /sys/devices/LNXSYSTM:00. The
|
|
format of their names is <bus_id:instance>, where 'bus_id' refers to the
|
|
ACPI namespace representation of the given object and 'instance' is used
|
|
for distinguishing different object of the same 'bus_id' (it is
|
|
two-digit decimal representation of an unsigned integer).
|
|
|
|
The value of 'bus_id' depends on the type of the object whose name it is
|
|
part of as listed in the table below.
|
|
|
|
+---+-----------------+-------+----------+
|
|
| | Object/Feature | Table | bus_id |
|
|
+---+-----------------+-------+----------+
|
|
| N | Root | xSDT | LNXSYSTM |
|
|
+---+-----------------+-------+----------+
|
|
| N | Device | xSDT | _HID |
|
|
+---+-----------------+-------+----------+
|
|
| N | Processor | xSDT | LNXCPU |
|
|
+---+-----------------+-------+----------+
|
|
| N | ThermalZone | xSDT | LNXTHERM |
|
|
+---+-----------------+-------+----------+
|
|
| N | PowerResource | xSDT | LNXPOWER |
|
|
+---+-----------------+-------+----------+
|
|
| N | Other Devices | xSDT | device |
|
|
+---+-----------------+-------+----------+
|
|
| F | PWR_BUTTON | FADT | LNXPWRBN |
|
|
+---+-----------------+-------+----------+
|
|
| F | SLP_BUTTON | FADT | LNXSLPBN |
|
|
+---+-----------------+-------+----------+
|
|
| M | Video Extension | xSDT | LNXVIDEO |
|
|
+---+-----------------+-------+----------+
|
|
| M | ATA Controller | xSDT | LNXIOBAY |
|
|
+---+-----------------+-------+----------+
|
|
| M | Docking Station | xSDT | LNXDOCK |
|
|
+---+-----------------+-------+----------+
|
|
|
|
Table 1. ACPI Namespace Objects Mapping
|
|
|
|
The following rules apply when creating struct acpi_device objects on
|
|
the basis of the contents of ACPI System Description Tables (as
|
|
indicated by the letter in the first column and the notation in the
|
|
second column of the table above):
|
|
N:
|
|
The object's source is an ACPI namespace node (as indicated by the
|
|
named object's type in the second column). In that case the object's
|
|
directory in sysfs will contain the 'path' attribute whose value is
|
|
the full path to the node from the namespace root.
|
|
F:
|
|
The struct acpi_device object is created for a fixed hardware
|
|
feature (as indicated by the fixed feature flag's name in the second
|
|
column), so its sysfs directory will not contain the 'path'
|
|
attribute.
|
|
M:
|
|
The struct acpi_device object is created for an ACPI namespace node
|
|
with specific control methods (as indicated by the ACPI defined
|
|
device's type in the second column). The 'path' attribute containing
|
|
its namespace path will be present in its sysfs directory. For
|
|
example, if the _BCL method is present for an ACPI namespace node, a
|
|
struct acpi_device object with LNXVIDEO 'bus_id' will be created for
|
|
it.
|
|
|
|
The third column of the above table indicates which ACPI System
|
|
Description Tables contain information used for the creation of the
|
|
struct acpi_device objects represented by the given row (xSDT means DSDT
|
|
or SSDT).
|
|
|
|
The forth column of the above table indicates the 'bus_id' generation
|
|
rule of the struct acpi_device object:
|
|
_HID:
|
|
_HID in the last column of the table means that the object's bus_id
|
|
is derived from the _HID/_CID identification objects present under
|
|
the corresponding ACPI namespace node. The object's sysfs directory
|
|
will then contain the 'hid' and 'modalias' attributes that can be
|
|
used to retrieve the _HID and _CIDs of that object.
|
|
LNXxxxxx:
|
|
The 'modalias' attribute is also present for struct acpi_device
|
|
objects having bus_id of the "LNXxxxxx" form (pseudo devices), in
|
|
which cases it contains the bus_id string itself.
|
|
device:
|
|
'device' in the last column of the table indicates that the object's
|
|
bus_id cannot be determined from _HID/_CID of the corresponding
|
|
ACPI namespace node, although that object represents a device (for
|
|
example, it may be a PCI device with _ADR defined and without _HID
|
|
or _CID). In that case the string 'device' will be used as the
|
|
object's bus_id.
|
|
|
|
|
|
4. Linux ACPI Physical Device Glue
|
|
|
|
ACPI device (i.e. struct acpi_device) objects may be linked to other
|
|
objects in the Linux' device hierarchy that represent "physical" devices
|
|
(for example, devices on the PCI bus). If that happens, it means that
|
|
the ACPI device object is a "companion" of a device otherwise
|
|
represented in a different way and is used (1) to provide configuration
|
|
information on that device which cannot be obtained by other means and
|
|
(2) to do specific things to the device with the help of its ACPI
|
|
control methods. One ACPI device object may be linked this way to
|
|
multiple "physical" devices.
|
|
|
|
If an ACPI device object is linked to a "physical" device, its sysfs
|
|
directory contains the "physical_node" symbolic link to the sysfs
|
|
directory of the target device object. In turn, the target device's
|
|
sysfs directory will then contain the "firmware_node" symbolic link to
|
|
the sysfs directory of the companion ACPI device object.
|
|
The linking mechanism relies on device identification provided by the
|
|
ACPI namespace. For example, if there's an ACPI namespace object
|
|
representing a PCI device (i.e. a device object under an ACPI namespace
|
|
object representing a PCI bridge) whose _ADR returns 0x00020000 and the
|
|
bus number of the parent PCI bridge is 0, the sysfs directory
|
|
representing the struct acpi_device object created for that ACPI
|
|
namespace object will contain the 'physical_node' symbolic link to the
|
|
/sys/devices/pci0000:00/0000:00:02:0/ sysfs directory of the
|
|
corresponding PCI device.
|
|
|
|
The linking mechanism is generally bus-specific. The core of its
|
|
implementation is located in the drivers/acpi/glue.c file, but there are
|
|
complementary parts depending on the bus types in question located
|
|
elsewhere. For example, the PCI-specific part of it is located in
|
|
drivers/pci/pci-acpi.c.
|
|
|
|
|
|
5. Example Linux ACPI Device Tree
|
|
|
|
The sysfs hierarchy of struct acpi_device objects corresponding to the
|
|
example ACPI namespace illustrated in Figure 2 with the addition of
|
|
fixed PWR_BUTTON/SLP_BUTTON devices is shown below.
|
|
|
|
+--------------+---+-----------------+
|
|
| LNXSYSTEM:00 | \ | acpi:LNXSYSTEM: |
|
|
+--------------+---+-----------------+
|
|
|
|
|
| +-------------+-----+----------------+
|
|
+-| LNXPWRBN:00 | N/A | acpi:LNXPWRBN: |
|
|
| +-------------+-----+----------------+
|
|
|
|
|
| +-------------+-----+----------------+
|
|
+-| LNXSLPBN:00 | N/A | acpi:LNXSLPBN: |
|
|
| +-------------+-----+----------------+
|
|
|
|
|
| +-----------+------------+--------------+
|
|
+-| LNXCPU:00 | \_PR_.CPU0 | acpi:LNXCPU: |
|
|
| +-----------+------------+--------------+
|
|
|
|
|
| +-------------+-------+----------------+
|
|
+-| LNXSYBUS:00 | \_SB_ | acpi:LNXSYBUS: |
|
|
| +-------------+-------+----------------+
|
|
| |
|
|
| | +- - - - - - - +- - - - - - +- - - - - - - -+
|
|
| +-| PNP0C0D:00 | \_SB_.LID0 | acpi:PNP0C0D: |
|
|
| | +- - - - - - - +- - - - - - +- - - - - - - -+
|
|
| |
|
|
| | +------------+------------+-----------------------+
|
|
| +-| PNP0A08:00 | \_SB_.PCI0 | acpi:PNP0A08:PNP0A03: |
|
|
| +------------+------------+-----------------------+
|
|
| |
|
|
| | +-----------+-----------------+-----+
|
|
| +-| device:00 | \_SB_.PCI0.RP03 | N/A |
|
|
| | +-----------+-----------------+-----+
|
|
| | |
|
|
| | | +-------------+----------------------+----------------+
|
|
| | +-| LNXPOWER:00 | \_SB_.PCI0.RP03.PXP3 | acpi:LNXPOWER: |
|
|
| | +-------------+----------------------+----------------+
|
|
| |
|
|
| | +-------------+-----------------+----------------+
|
|
| +-| LNXVIDEO:00 | \_SB_.PCI0.GFX0 | acpi:LNXVIDEO: |
|
|
| +-------------+-----------------+----------------+
|
|
| |
|
|
| | +-----------+-----------------+-----+
|
|
| +-| device:01 | \_SB_.PCI0.DD01 | N/A |
|
|
| +-----------+-----------------+-----+
|
|
|
|
|
| +-------------+-------+----------------+
|
|
+-| LNXSYBUS:01 | \_TZ_ | acpi:LNXSYBUS: |
|
|
+-------------+-------+----------------+
|
|
|
|
|
| +-------------+------------+----------------+
|
|
+-| LNXPOWER:0a | \_TZ_.FN00 | acpi:LNXPOWER: |
|
|
| +-------------+------------+----------------+
|
|
|
|
|
| +------------+------------+---------------+
|
|
+-| PNP0C0B:00 | \_TZ_.FAN0 | acpi:PNP0C0B: |
|
|
| +------------+------------+---------------+
|
|
|
|
|
| +-------------+------------+----------------+
|
|
+-| LNXTHERM:00 | \_TZ_.TZ00 | acpi:LNXTHERM: |
|
|
+-------------+------------+----------------+
|
|
|
|
Figure 3. Example Linux ACPI Device Tree
|
|
|
|
NOTE: Each node is represented as "object/path/modalias", where:
|
|
1. 'object' is the name of the object's directory in sysfs.
|
|
2. 'path' is the ACPI namespace path of the corresponding
|
|
ACPI namespace object, as returned by the object's 'path'
|
|
sysfs attribute.
|
|
3. 'modalias' is the value of the object's 'modalias' sysfs
|
|
attribute (as described earlier in this document).
|
|
NOTE: N/A indicates the device object does not have the 'path' or the
|
|
'modalias' attribute.
|