1 .. SPDX-License-Identifier: GPL-2.0 2 .. include:: <isonum.txt> 3 4 =================================================== 5 ACPI Device Tree - Representation of ACPI Namespace 6 =================================================== 7 8 :Copyright: |copy| 2013, Intel Corporation 9 10 :Author: Lv Zheng <lv.zheng@intel.com> 11 12 :Credit: Thanks for the help from Zhang Rui <rui.zhang@intel.com> and 13 Rafael J.Wysocki <rafael.j.wysocki@intel.com>. 14 15 Abstract 16 ======== 17 The Linux ACPI subsystem converts ACPI namespace objects into a Linux 18 device tree under the /sys/devices/LNXSYSTM:00 and updates it upon 19 receiving ACPI hotplug notification events. For each device object 20 in this hierarchy there is a corresponding symbolic link in the 21 /sys/bus/acpi/devices. 22 23 This document illustrates the structure of the ACPI device tree. 24 25 ACPI Definition Blocks 26 ====================== 27 28 The ACPI firmware sets up RSDP (Root System Description Pointer) in the 29 system memory address space pointing to the XSDT (Extended System 30 Description Table). The XSDT always points to the FADT (Fixed ACPI 31 Description Table) using its first entry, the data within the FADT 32 includes various fixed-length entries that describe fixed ACPI features 33 of the hardware. The FADT contains a pointer to the DSDT 34 (Differentiated System Description Table). The XSDT also contains 35 entries pointing to possibly multiple SSDTs (Secondary System 36 Description Table). 37 38 The DSDT and SSDT data is organized in data structures called definition 39 blocks that contain definitions of various objects, including ACPI 40 control methods, encoded in AML (ACPI Machine Language). The data block 41 of the DSDT along with the contents of SSDTs represents a hierarchical 42 data structure called the ACPI namespace whose topology reflects the 43 structure of the underlying hardware platform. 44 45 The relationships between ACPI System Definition Tables described above 46 are 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 Blocks 73 74 .. note:: RSDP can also contain a pointer to the RSDT (Root System 75 Description Table). Platforms provide RSDT to enable 76 compatibility with ACPI 1.0 operating systems. The OS is expected 77 to use XSDT, if present. 78 79 80 Example ACPI Namespace 81 ====================== 82 83 All definition blocks are loaded into a single namespace. The namespace 84 is a hierarchy of objects identified by names and paths. 85 The following naming conventions apply to object names in the ACPI 86 namespace: 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. names 94 prepended with '\' are relative to the namespace root). 95 6. The '^' symbol represents the parent of the current namespace node 96 (i.e. names prepended with '^' are relative to the parent of the 97 current namespace node). 98 99 The figure below shows an example ACPI namespace:: 100 101 +------+ 102 | \ | Root 103 +------+ 104 | 105 | +------+ 106 +-| _PR | Scope(_PR): the processor namespace 107 | +------+ 108 | | 109 | | +------+ 110 | +-| CPU0 | Processor(CPU0): the first processor 111 | +------+ 112 | 113 | +------+ 114 +-| _SB | Scope(_SB): the system bus namespace 115 | +------+ 116 | | 117 | | +------+ 118 | +-| LID0 | Device(LID0); the lid device 119 | | +------+ 120 | | | 121 | | | +------+ 122 | | +-| _HID | Name(_HID, "PNP0C0D"): the hardware ID 123 | | | +------+ 124 | | | 125 | | | +------+ 126 | | +-| _STA | Method(_STA): the status control method 127 | | +------+ 128 | | 129 | | +------+ 130 | +-| PCI0 | Device(PCI0); the PCI root bridge 131 | +------+ 132 | | 133 | | +------+ 134 | +-| _HID | Name(_HID, "PNP0A08"): the hardware ID 135 | | +------+ 136 | | 137 | | +------+ 138 | +-| _CID | Name(_CID, "PNP0A03"): the compatible ID 139 | | +------+ 140 | | 141 | | +------+ 142 | +-| RP03 | Scope(RP03): the PCI0 power scope 143 | | +------+ 144 | | | 145 | | | +------+ 146 | | +-| PXP3 | PowerResource(PXP3): the PCI0 power resource 147 | | +------+ 148 | | 149 | | +------+ 150 | +-| GFX0 | Device(GFX0): the graphics adapter 151 | +------+ 152 | | 153 | | +------+ 154 | +-| _ADR | Name(_ADR, 0x00020000): the PCI bus address 155 | | +------+ 156 | | 157 | | +------+ 158 | +-| DD01 | Device(DD01): the LCD output device 159 | +------+ 160 | | 161 | | +------+ 162 | +-| _BCL | Method(_BCL): the backlight control method 163 | +------+ 164 | 165 | +------+ 166 +-| _TZ | Scope(_TZ): the thermal zone namespace 167 | +------+ 168 | | 169 | | +------+ 170 | +-| FN00 | PowerResource(FN00): the FAN0 power resource 171 | | +------+ 172 | | 173 | | +------+ 174 | +-| FAN0 | Device(FAN0): the FAN0 cooling device 175 | | +------+ 176 | | | 177 | | | +------+ 178 | | +-| _HID | Name(_HID, "PNP0A0B"): the hardware ID 179 | | +------+ 180 | | 181 | | +------+ 182 | +-| TZ00 | ThermalZone(TZ00); the FAN thermal zone 183 | +------+ 184 | 185 | +------+ 186 +-| _GPE | Scope(_GPE): the GPE namespace 187 +------+ 188 189 Figure 2. Example ACPI Namespace 190 191 192 Linux ACPI Device Objects 193 ========================= 194 195 The Linux kernel's core ACPI subsystem creates struct acpi_device 196 objects for ACPI namespace objects representing devices, power resources 197 processors, thermal zones. Those objects are exported to user space via 198 sysfs as directories in the subtree under /sys/devices/LNXSYSTM:00. The 199 format of their names is <bus_id:instance>, where 'bus_id' refers to the 200 ACPI namespace representation of the given object and 'instance' is used 201 for distinguishing different object of the same 'bus_id' (it is 202 two-digit decimal representation of an unsigned integer). 203 204 The value of 'bus_id' depends on the type of the object whose name it is 205 part 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 Mapping 234 235 The following rules apply when creating struct acpi_device objects on 236 the basis of the contents of ACPI System Description Tables (as 237 indicated by the letter in the first column and the notation in the 238 second column of the table above): 239 240 N: 241 The object's source is an ACPI namespace node (as indicated by the 242 named object's type in the second column). In that case the object's 243 directory in sysfs will contain the 'path' attribute whose value is 244 the full path to the node from the namespace root. 245 F: 246 The struct acpi_device object is created for a fixed hardware 247 feature (as indicated by the fixed feature flag's name in the second 248 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 node 252 with specific control methods (as indicated by the ACPI defined 253 device's type in the second column). The 'path' attribute containing 254 its namespace path will be present in its sysfs directory. For 255 example, if the _BCL method is present for an ACPI namespace node, a 256 struct acpi_device object with LNXVIDEO 'bus_id' will be created for 257 it. 258 259 The third column of the above table indicates which ACPI System 260 Description Tables contain information used for the creation of the 261 struct acpi_device objects represented by the given row (xSDT means DSDT 262 or SSDT). 263 264 The fourth column of the above table indicates the 'bus_id' generation 265 rule of the struct acpi_device object: 266 267 _HID: 268 _HID in the last column of the table means that the object's bus_id 269 is derived from the _HID/_CID identification objects present under 270 the corresponding ACPI namespace node. The object's sysfs directory 271 will then contain the 'hid' and 'modalias' attributes that can be 272 used to retrieve the _HID and _CIDs of that object. 273 LNXxxxxx: 274 The 'modalias' attribute is also present for struct acpi_device 275 objects having bus_id of the "LNXxxxxx" form (pseudo devices), in 276 which cases it contains the bus_id string itself. 277 device: 278 'device' in the last column of the table indicates that the object's 279 bus_id cannot be determined from _HID/_CID of the corresponding 280 ACPI namespace node, although that object represents a device (for 281 example, it may be a PCI device with _ADR defined and without _HID 282 or _CID). In that case the string 'device' will be used as the 283 object's bus_id. 284 285 286 Linux ACPI Physical Device Glue 287 =============================== 288 289 ACPI device (i.e. struct acpi_device) objects may be linked to other 290 objects in the Linux' device hierarchy that represent "physical" devices 291 (for example, devices on the PCI bus). If that happens, it means that 292 the ACPI device object is a "companion" of a device otherwise 293 represented in a different way and is used (1) to provide configuration 294 information on that device which cannot be obtained by other means and 295 (2) to do specific things to the device with the help of its ACPI 296 control methods. One ACPI device object may be linked this way to 297 multiple "physical" devices. 298 299 If an ACPI device object is linked to a "physical" device, its sysfs 300 directory contains the "physical_node" symbolic link to the sysfs 301 directory of the target device object. In turn, the target device's 302 sysfs directory will then contain the "firmware_node" symbolic link to 303 the sysfs directory of the companion ACPI device object. 304 The linking mechanism relies on device identification provided by the 305 ACPI namespace. For example, if there's an ACPI namespace object 306 representing a PCI device (i.e. a device object under an ACPI namespace 307 object representing a PCI bridge) whose _ADR returns 0x00020000 and the 308 bus number of the parent PCI bridge is 0, the sysfs directory 309 representing the struct acpi_device object created for that ACPI 310 namespace object will contain the 'physical_node' symbolic link to the 311 /sys/devices/pci0000:00/0000:00:02:0/ sysfs directory of the 312 corresponding PCI device. 313 314 The linking mechanism is generally bus-specific. The core of its 315 implementation is located in the drivers/acpi/glue.c file, but there are 316 complementary parts depending on the bus types in question located 317 elsewhere. For example, the PCI-specific part of it is located in 318 drivers/pci/pci-acpi.c. 319 320 321 Example Linux ACPI Device Tree 322 ================================= 323 324 The sysfs hierarchy of struct acpi_device objects corresponding to the 325 example ACPI namespace illustrated in Figure 2 with the addition of 326 fixed 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 Tree 389 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 corresponding 394 ACPI namespace object, as returned by the object's 'path' 395 sysfs attribute. 396 3. 'modalias' is the value of the object's 'modalias' sysfs 397 attribute (as described earlier in this document). 398 399 .. note:: N/A indicates the device object does not have the 'path' or the 400 'modalias' attribute.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.