401 lines · plain
1.. SPDX-License-Identifier: GPL-2.02.. include:: <isonum.txt>3 4===================================================5ACPI Device Tree - Representation of ACPI Namespace6===================================================7 8:Copyright: |copy| 2013, Intel Corporation9 10:Author: Lv Zheng <lv.zheng@intel.com>11 12:Credit: Thanks for the help from Zhang Rui <rui.zhang@intel.com> and13 Rafael J.Wysocki <rafael.j.wysocki@intel.com>.14 15Abstract16========17The Linux ACPI subsystem converts ACPI namespace objects into a Linux18device tree under the /sys/devices/LNXSYSTM:00 and updates it upon19receiving ACPI hotplug notification events. For each device object20in this hierarchy there is a corresponding symbolic link in the21/sys/bus/acpi/devices.22 23This document illustrates the structure of the ACPI device tree.24 25ACPI Definition Blocks26======================27 28The ACPI firmware sets up RSDP (Root System Description Pointer) in the29system memory address space pointing to the XSDT (Extended System30Description Table). The XSDT always points to the FADT (Fixed ACPI31Description Table) using its first entry, the data within the FADT32includes various fixed-length entries that describe fixed ACPI features33of the hardware. The FADT contains a pointer to the DSDT34(Differentiated System Description Table). The XSDT also contains35entries pointing to possibly multiple SSDTs (Secondary System36Description Table).37 38The DSDT and SSDT data is organized in data structures called definition39blocks that contain definitions of various objects, including ACPI40control methods, encoded in AML (ACPI Machine Language). The data block41of the DSDT along with the contents of SSDTs represents a hierarchical42data structure called the ACPI namespace whose topology reflects the43structure of the underlying hardware platform.44 45The relationships between ACPI System Definition Tables described above46are illustrated in the following diagram::47 48 +---------+ +-------+ +--------+ +------------------------+49 | RSDP | +->| XSDT | +->| FADT | | +-------------------+ |50 +---------+ | +-------+ | +--------+ +-|->| DSDT | |51 | Pointer | | | Entry |-+ | ...... | | | +-------------------+ |52 +---------+ | +-------+ | X_DSDT |--+ | | Definition Blocks | |53 | Pointer |-+ | ..... | | ...... | | +-------------------+ |54 +---------+ +-------+ +--------+ | +-------------------+ |55 | Entry |------------------|->| SSDT | |56 +- - - -+ | +-------------------| |57 | Entry | - - - - - - - -+ | | Definition Blocks | |58 +- - - -+ | | +-------------------+ |59 | | +- - - - - - - - - -+ |60 +-|->| SSDT | |61 | +-------------------+ |62 | | Definition Blocks | |63 | +- - - - - - - - - -+ |64 +------------------------+65 |66 OSPM Loading |67 \|/68 +----------------+69 | ACPI Namespace |70 +----------------+71 72 Figure 1. ACPI Definition Blocks73 74.. note:: RSDP can also contain a pointer to the RSDT (Root System75 Description Table). Platforms provide RSDT to enable76 compatibility with ACPI 1.0 operating systems. The OS is expected77 to use XSDT, if present.78 79 80Example ACPI Namespace81======================82 83All definition blocks are loaded into a single namespace. The namespace84is a hierarchy of objects identified by names and paths.85The following naming conventions apply to object names in the ACPI86namespace:87 88 1. All names are 32 bits long.89 2. The first byte of a name must be one of 'A' - 'Z', '_'.90 3. Each of the remaining bytes of a name must be one of 'A' - 'Z', '0'91 - '9', '_'.92 4. Names starting with '_' are reserved by the ACPI specification.93 5. The '\' symbol represents the root of the namespace (i.e. names94 prepended with '\' are relative to the namespace root).95 6. The '^' symbol represents the parent of the current namespace node96 (i.e. names prepended with '^' are relative to the parent of the97 current namespace node).98 99The figure below shows an example ACPI namespace::100 101 +------+102 | \ | Root103 +------+104 |105 | +------+106 +-| _PR | Scope(_PR): the processor namespace107 | +------+108 | |109 | | +------+110 | +-| CPU0 | Processor(CPU0): the first processor111 | +------+112 |113 | +------+114 +-| _SB | Scope(_SB): the system bus namespace115 | +------+116 | |117 | | +------+118 | +-| LID0 | Device(LID0); the lid device119 | | +------+120 | | |121 | | | +------+122 | | +-| _HID | Name(_HID, "PNP0C0D"): the hardware ID123 | | | +------+124 | | |125 | | | +------+126 | | +-| _STA | Method(_STA): the status control method127 | | +------+128 | |129 | | +------+130 | +-| PCI0 | Device(PCI0); the PCI root bridge131 | +------+132 | |133 | | +------+134 | +-| _HID | Name(_HID, "PNP0A08"): the hardware ID135 | | +------+136 | |137 | | +------+138 | +-| _CID | Name(_CID, "PNP0A03"): the compatible ID139 | | +------+140 | |141 | | +------+142 | +-| RP03 | Scope(RP03): the PCI0 power scope143 | | +------+144 | | |145 | | | +------+146 | | +-| PXP3 | PowerResource(PXP3): the PCI0 power resource147 | | +------+148 | |149 | | +------+150 | +-| GFX0 | Device(GFX0): the graphics adapter151 | +------+152 | |153 | | +------+154 | +-| _ADR | Name(_ADR, 0x00020000): the PCI bus address155 | | +------+156 | |157 | | +------+158 | +-| DD01 | Device(DD01): the LCD output device159 | +------+160 | |161 | | +------+162 | +-| _BCL | Method(_BCL): the backlight control method163 | +------+164 |165 | +------+166 +-| _TZ | Scope(_TZ): the thermal zone namespace167 | +------+168 | |169 | | +------+170 | +-| FN00 | PowerResource(FN00): the FAN0 power resource171 | | +------+172 | |173 | | +------+174 | +-| FAN0 | Device(FAN0): the FAN0 cooling device175 | | +------+176 | | |177 | | | +------+178 | | +-| _HID | Name(_HID, "PNP0A0B"): the hardware ID179 | | +------+180 | |181 | | +------+182 | +-| TZ00 | ThermalZone(TZ00); the FAN thermal zone183 | +------+184 |185 | +------+186 +-| _GPE | Scope(_GPE): the GPE namespace187 +------+188 189 Figure 2. Example ACPI Namespace190 191 192Linux ACPI Device Objects193=========================194 195The Linux kernel's core ACPI subsystem creates struct acpi_device196objects for ACPI namespace objects representing devices, power resources197processors, thermal zones. Those objects are exported to user space via198sysfs as directories in the subtree under /sys/devices/LNXSYSTM:00. The199format of their names is <bus_id:instance>, where 'bus_id' refers to the200ACPI namespace representation of the given object and 'instance' is used201for distinguishing different object of the same 'bus_id' (it is202two-digit decimal representation of an unsigned integer).203 204The value of 'bus_id' depends on the type of the object whose name it is205part of as listed in the table below::206 207 +---+-----------------+-------+----------+208 | | Object/Feature | Table | bus_id |209 +---+-----------------+-------+----------+210 | N | Root | xSDT | LNXSYSTM |211 +---+-----------------+-------+----------+212 | N | Device | xSDT | _HID |213 +---+-----------------+-------+----------+214 | N | Processor | xSDT | LNXCPU |215 +---+-----------------+-------+----------+216 | N | ThermalZone | xSDT | LNXTHERM |217 +---+-----------------+-------+----------+218 | N | PowerResource | xSDT | LNXPOWER |219 +---+-----------------+-------+----------+220 | N | Other Devices | xSDT | device |221 +---+-----------------+-------+----------+222 | F | PWR_BUTTON | FADT | LNXPWRBN |223 +---+-----------------+-------+----------+224 | F | SLP_BUTTON | FADT | LNXSLPBN |225 +---+-----------------+-------+----------+226 | M | Video Extension | xSDT | LNXVIDEO |227 +---+-----------------+-------+----------+228 | M | ATA Controller | xSDT | LNXIOBAY |229 +---+-----------------+-------+----------+230 | M | Docking Station | xSDT | LNXDOCK |231 +---+-----------------+-------+----------+232 233 Table 1. ACPI Namespace Objects Mapping234 235The following rules apply when creating struct acpi_device objects on236the basis of the contents of ACPI System Description Tables (as237indicated by the letter in the first column and the notation in the238second column of the table above):239 240 N:241 The object's source is an ACPI namespace node (as indicated by the242 named object's type in the second column). In that case the object's243 directory in sysfs will contain the 'path' attribute whose value is244 the full path to the node from the namespace root.245 F:246 The struct acpi_device object is created for a fixed hardware247 feature (as indicated by the fixed feature flag's name in the second248 column), so its sysfs directory will not contain the 'path'249 attribute.250 M:251 The struct acpi_device object is created for an ACPI namespace node252 with specific control methods (as indicated by the ACPI defined253 device's type in the second column). The 'path' attribute containing254 its namespace path will be present in its sysfs directory. For255 example, if the _BCL method is present for an ACPI namespace node, a256 struct acpi_device object with LNXVIDEO 'bus_id' will be created for257 it.258 259The third column of the above table indicates which ACPI System260Description Tables contain information used for the creation of the261struct acpi_device objects represented by the given row (xSDT means DSDT262or SSDT).263 264The fourth column of the above table indicates the 'bus_id' generation265rule of the struct acpi_device object:266 267 _HID:268 _HID in the last column of the table means that the object's bus_id269 is derived from the _HID/_CID identification objects present under270 the corresponding ACPI namespace node. The object's sysfs directory271 will then contain the 'hid' and 'modalias' attributes that can be272 used to retrieve the _HID and _CIDs of that object.273 LNXxxxxx:274 The 'modalias' attribute is also present for struct acpi_device275 objects having bus_id of the "LNXxxxxx" form (pseudo devices), in276 which cases it contains the bus_id string itself.277 device:278 'device' in the last column of the table indicates that the object's279 bus_id cannot be determined from _HID/_CID of the corresponding280 ACPI namespace node, although that object represents a device (for281 example, it may be a PCI device with _ADR defined and without _HID282 or _CID). In that case the string 'device' will be used as the283 object's bus_id.284 285 286Linux ACPI Physical Device Glue287===============================288 289ACPI device (i.e. struct acpi_device) objects may be linked to other290objects in the Linux' device hierarchy that represent "physical" devices291(for example, devices on the PCI bus). If that happens, it means that292the ACPI device object is a "companion" of a device otherwise293represented in a different way and is used (1) to provide configuration294information on that device which cannot be obtained by other means and295(2) to do specific things to the device with the help of its ACPI296control methods. One ACPI device object may be linked this way to297multiple "physical" devices.298 299If an ACPI device object is linked to a "physical" device, its sysfs300directory contains the "physical_node" symbolic link to the sysfs301directory of the target device object. In turn, the target device's302sysfs directory will then contain the "firmware_node" symbolic link to303the sysfs directory of the companion ACPI device object.304The linking mechanism relies on device identification provided by the305ACPI namespace. For example, if there's an ACPI namespace object306representing a PCI device (i.e. a device object under an ACPI namespace307object representing a PCI bridge) whose _ADR returns 0x00020000 and the308bus number of the parent PCI bridge is 0, the sysfs directory309representing the struct acpi_device object created for that ACPI310namespace object will contain the 'physical_node' symbolic link to the311/sys/devices/pci0000:00/0000:00:02:0/ sysfs directory of the312corresponding PCI device.313 314The linking mechanism is generally bus-specific. The core of its315implementation is located in the drivers/acpi/glue.c file, but there are316complementary parts depending on the bus types in question located317elsewhere. For example, the PCI-specific part of it is located in318drivers/pci/pci-acpi.c.319 320 321Example Linux ACPI Device Tree322=================================323 324The sysfs hierarchy of struct acpi_device objects corresponding to the325example ACPI namespace illustrated in Figure 2 with the addition of326fixed PWR_BUTTON/SLP_BUTTON devices is shown below::327 328 +--------------+---+-----------------+329 | LNXSYSTM:00 | \ | acpi:LNXSYSTM: |330 +--------------+---+-----------------+331 |332 | +-------------+-----+----------------+333 +-| LNXPWRBN:00 | N/A | acpi:LNXPWRBN: |334 | +-------------+-----+----------------+335 |336 | +-------------+-----+----------------+337 +-| LNXSLPBN:00 | N/A | acpi:LNXSLPBN: |338 | +-------------+-----+----------------+339 |340 | +-----------+------------+--------------+341 +-| LNXCPU:00 | \_PR_.CPU0 | acpi:LNXCPU: |342 | +-----------+------------+--------------+343 |344 | +-------------+-------+----------------+345 +-| LNXSYBUS:00 | \_SB_ | acpi:LNXSYBUS: |346 | +-------------+-------+----------------+347 | |348 | | +- - - - - - - +- - - - - - +- - - - - - - -+349 | +-| PNP0C0D:00 | \_SB_.LID0 | acpi:PNP0C0D: |350 | | +- - - - - - - +- - - - - - +- - - - - - - -+351 | |352 | | +------------+------------+-----------------------+353 | +-| PNP0A08:00 | \_SB_.PCI0 | acpi:PNP0A08:PNP0A03: |354 | +------------+------------+-----------------------+355 | |356 | | +-----------+-----------------+-----+357 | +-| device:00 | \_SB_.PCI0.RP03 | N/A |358 | | +-----------+-----------------+-----+359 | | |360 | | | +-------------+----------------------+----------------+361 | | +-| LNXPOWER:00 | \_SB_.PCI0.RP03.PXP3 | acpi:LNXPOWER: |362 | | +-------------+----------------------+----------------+363 | |364 | | +-------------+-----------------+----------------+365 | +-| LNXVIDEO:00 | \_SB_.PCI0.GFX0 | acpi:LNXVIDEO: |366 | +-------------+-----------------+----------------+367 | |368 | | +-----------+-----------------+-----+369 | +-| device:01 | \_SB_.PCI0.DD01 | N/A |370 | +-----------+-----------------+-----+371 |372 | +-------------+-------+----------------+373 +-| LNXSYBUS:01 | \_TZ_ | acpi:LNXSYBUS: |374 +-------------+-------+----------------+375 |376 | +-------------+------------+----------------+377 +-| LNXPOWER:0a | \_TZ_.FN00 | acpi:LNXPOWER: |378 | +-------------+------------+----------------+379 |380 | +------------+------------+---------------+381 +-| PNP0C0B:00 | \_TZ_.FAN0 | acpi:PNP0C0B: |382 | +------------+------------+---------------+383 |384 | +-------------+------------+----------------+385 +-| LNXTHERM:00 | \_TZ_.TZ00 | acpi:LNXTHERM: |386 +-------------+------------+----------------+387 388 Figure 3. Example Linux ACPI Device Tree389 390.. note:: Each node is represented as "object/path/modalias", where:391 392 1. 'object' is the name of the object's directory in sysfs.393 2. 'path' is the ACPI namespace path of the corresponding394 ACPI namespace object, as returned by the object's 'path'395 sysfs attribute.396 3. 'modalias' is the value of the object's 'modalias' sysfs397 attribute (as described earlier in this document).398 399.. note:: N/A indicates the device object does not have the 'path' or the400 'modalias' attribute.401