Commit | Line | Data |
---|---|---|
dc81f2cf GG |
1 | ACPI on ARMv8 Servers |
2 | --------------------- | |
3 | ACPI can be used for ARMv8 general purpose servers designed to follow | |
4 | the ARM SBSA (Server Base System Architecture) [0] and SBBR (Server | |
5 | Base Boot Requirements) [1] specifications. Please note that the SBBR | |
6 | can be retrieved simply by visiting [1], but the SBSA is currently only | |
7 | available to those with an ARM login due to ARM IP licensing concerns. | |
8 | ||
9 | The ARMv8 kernel implements the reduced hardware model of ACPI version | |
10 | 5.1 or later. Links to the specification and all external documents | |
11 | it refers to are managed by the UEFI Forum. The specification is | |
12 | available at http://www.uefi.org/specifications and documents referenced | |
13 | by the specification can be found via http://www.uefi.org/acpi. | |
14 | ||
15 | If an ARMv8 system does not meet the requirements of the SBSA and SBBR, | |
16 | or cannot be described using the mechanisms defined in the required ACPI | |
17 | specifications, then ACPI may not be a good fit for the hardware. | |
18 | ||
19 | While the documents mentioned above set out the requirements for building | |
20 | industry-standard ARMv8 servers, they also apply to more than one operating | |
21 | system. The purpose of this document is to describe the interaction between | |
22 | ACPI and Linux only, on an ARMv8 system -- that is, what Linux expects of | |
23 | ACPI and what ACPI can expect of Linux. | |
24 | ||
25 | ||
26 | Why ACPI on ARM? | |
27 | ---------------- | |
28 | Before examining the details of the interface between ACPI and Linux, it is | |
29 | useful to understand why ACPI is being used. Several technologies already | |
30 | exist in Linux for describing non-enumerable hardware, after all. In this | |
31 | section we summarize a blog post [2] from Grant Likely that outlines the | |
32 | reasoning behind ACPI on ARMv8 servers. Actually, we snitch a good portion | |
33 | of the summary text almost directly, to be honest. | |
34 | ||
35 | The short form of the rationale for ACPI on ARM is: | |
36 | ||
37 | -- ACPI’s bytecode (AML) allows the platform to encode hardware behavior, | |
38 | while DT explicitly does not support this. For hardware vendors, being | |
39 | able to encode behavior is a key tool used in supporting operating | |
40 | system releases on new hardware. | |
41 | ||
42 | -- ACPI’s OSPM defines a power management model that constrains what the | |
43 | platform is allowed to do into a specific model, while still providing | |
44 | flexibility in hardware design. | |
45 | ||
46 | -- In the enterprise server environment, ACPI has established bindings (such | |
47 | as for RAS) which are currently used in production systems. DT does not. | |
48 | Such bindings could be defined in DT at some point, but doing so means ARM | |
49 | and x86 would end up using completely different code paths in both firmware | |
50 | and the kernel. | |
51 | ||
52 | -- Choosing a single interface to describe the abstraction between a platform | |
53 | and an OS is important. Hardware vendors would not be required to implement | |
54 | both DT and ACPI if they want to support multiple operating systems. And, | |
55 | agreeing on a single interface instead of being fragmented into per OS | |
56 | interfaces makes for better interoperability overall. | |
57 | ||
58 | -- The new ACPI governance process works well and Linux is now at the same | |
59 | table as hardware vendors and other OS vendors. In fact, there is no | |
60 | longer any reason to feel that ACPI is only belongs to Windows or that | |
61 | Linux is in any way secondary to Microsoft in this arena. The move of | |
62 | ACPI governance into the UEFI forum has significantly opened up the | |
63 | specification development process, and currently, a large portion of the | |
64 | changes being made to ACPI is being driven by Linux. | |
65 | ||
66 | Key to the use of ACPI is the support model. For servers in general, the | |
67 | responsibility for hardware behaviour cannot solely be the domain of the | |
68 | kernel, but rather must be split between the platform and the kernel, in | |
69 | order to allow for orderly change over time. ACPI frees the OS from needing | |
70 | to understand all the minute details of the hardware so that the OS doesn’t | |
71 | need to be ported to each and every device individually. It allows the | |
72 | hardware vendors to take responsibility for power management behaviour without | |
73 | depending on an OS release cycle which is not under their control. | |
74 | ||
75 | ACPI is also important because hardware and OS vendors have already worked | |
76 | out the mechanisms for supporting a general purpose computing ecosystem. The | |
77 | infrastructure is in place, the bindings are in place, and the processes are | |
78 | in place. DT does exactly what Linux needs it to when working with vertically | |
79 | integrated devices, but there are no good processes for supporting what the | |
80 | server vendors need. Linux could potentially get there with DT, but doing so | |
81 | really just duplicates something that already works. ACPI already does what | |
82 | the hardware vendors need, Microsoft won’t collaborate on DT, and hardware | |
83 | vendors would still end up providing two completely separate firmware | |
84 | interfaces -- one for Linux and one for Windows. | |
85 | ||
86 | ||
87 | Kernel Compatibility | |
88 | -------------------- | |
89 | One of the primary motivations for ACPI is standardization, and using that | |
90 | to provide backward compatibility for Linux kernels. In the server market, | |
91 | software and hardware are often used for long periods. ACPI allows the | |
92 | kernel and firmware to agree on a consistent abstraction that can be | |
93 | maintained over time, even as hardware or software change. As long as the | |
94 | abstraction is supported, systems can be updated without necessarily having | |
95 | to replace the kernel. | |
96 | ||
97 | When a Linux driver or subsystem is first implemented using ACPI, it by | |
98 | definition ends up requiring a specific version of the ACPI specification | |
99 | -- it's baseline. ACPI firmware must continue to work, even though it may | |
100 | not be optimal, with the earliest kernel version that first provides support | |
101 | for that baseline version of ACPI. There may be a need for additional drivers, | |
102 | but adding new functionality (e.g., CPU power management) should not break | |
103 | older kernel versions. Further, ACPI firmware must also work with the most | |
104 | recent version of the kernel. | |
105 | ||
106 | ||
107 | Relationship with Device Tree | |
108 | ----------------------------- | |
109 | ACPI support in drivers and subsystems for ARMv8 should never be mutually | |
110 | exclusive with DT support at compile time. | |
111 | ||
112 | At boot time the kernel will only use one description method depending on | |
113 | parameters passed from the bootloader (including kernel bootargs). | |
114 | ||
115 | Regardless of whether DT or ACPI is used, the kernel must always be capable | |
116 | of booting with either scheme (in kernels with both schemes enabled at compile | |
117 | time). | |
118 | ||
119 | ||
120 | Booting using ACPI tables | |
121 | ------------------------- | |
122 | The only defined method for passing ACPI tables to the kernel on ARMv8 | |
123 | is via the UEFI system configuration table. Just so it is explicit, this | |
124 | means that ACPI is only supported on platforms that boot via UEFI. | |
125 | ||
126 | When an ARMv8 system boots, it can either have DT information, ACPI tables, | |
127 | or in some very unusual cases, both. If no command line parameters are used, | |
128 | the kernel will try to use DT for device enumeration; if there is no DT | |
129 | present, the kernel will try to use ACPI tables, but only if they are present. | |
130 | In neither is available, the kernel will not boot. If acpi=force is used | |
131 | on the command line, the kernel will attempt to use ACPI tables first, but | |
132 | fall back to DT if there are no ACPI tables present. The basic idea is that | |
133 | the kernel will not fail to boot unless it absolutely has no other choice. | |
134 | ||
135 | Processing of ACPI tables may be disabled by passing acpi=off on the kernel | |
136 | command line; this is the default behavior. | |
137 | ||
138 | In order for the kernel to load and use ACPI tables, the UEFI implementation | |
139 | MUST set the ACPI_20_TABLE_GUID to point to the RSDP table (the table with | |
140 | the ACPI signature "RSD PTR "). If this pointer is incorrect and acpi=force | |
141 | is used, the kernel will disable ACPI and try to use DT to boot instead; the | |
142 | kernel has, in effect, determined that ACPI tables are not present at that | |
143 | point. | |
144 | ||
145 | If the pointer to the RSDP table is correct, the table will be mapped into | |
146 | the kernel by the ACPI core, using the address provided by UEFI. | |
147 | ||
148 | The ACPI core will then locate and map in all other ACPI tables provided by | |
149 | using the addresses in the RSDP table to find the XSDT (eXtended System | |
150 | Description Table). The XSDT in turn provides the addresses to all other | |
151 | ACPI tables provided by the system firmware; the ACPI core will then traverse | |
152 | this table and map in the tables listed. | |
153 | ||
154 | The ACPI core will ignore any provided RSDT (Root System Description Table). | |
155 | RSDTs have been deprecated and are ignored on arm64 since they only allow | |
156 | for 32-bit addresses. | |
157 | ||
158 | Further, the ACPI core will only use the 64-bit address fields in the FADT | |
159 | (Fixed ACPI Description Table). Any 32-bit address fields in the FADT will | |
160 | be ignored on arm64. | |
161 | ||
162 | Hardware reduced mode (see Section 4.1 of the ACPI 5.1 specification) will | |
163 | be enforced by the ACPI core on arm64. Doing so allows the ACPI core to | |
164 | run less complex code since it no longer has to provide support for legacy | |
165 | hardware from other architectures. Any fields that are not to be used for | |
166 | hardware reduced mode must be set to zero. | |
167 | ||
168 | For the ACPI core to operate properly, and in turn provide the information | |
169 | the kernel needs to configure devices, it expects to find the following | |
170 | tables (all section numbers refer to the ACPI 5.1 specfication): | |
171 | ||
172 | -- RSDP (Root System Description Pointer), section 5.2.5 | |
173 | ||
174 | -- XSDT (eXtended System Description Table), section 5.2.8 | |
175 | ||
176 | -- FADT (Fixed ACPI Description Table), section 5.2.9 | |
177 | ||
178 | -- DSDT (Differentiated System Description Table), section | |
179 | 5.2.11.1 | |
180 | ||
181 | -- MADT (Multiple APIC Description Table), section 5.2.12 | |
182 | ||
183 | -- GTDT (Generic Timer Description Table), section 5.2.24 | |
184 | ||
185 | -- If PCI is supported, the MCFG (Memory mapped ConFiGuration | |
186 | Table), section 5.2.6, specifically Table 5-31. | |
187 | ||
188 | If the above tables are not all present, the kernel may or may not be | |
189 | able to boot properly since it may not be able to configure all of the | |
190 | devices available. | |
191 | ||
192 | ||
193 | ACPI Detection | |
194 | -------------- | |
195 | Drivers should determine their probe() type by checking for a null | |
196 | value for ACPI_HANDLE, or checking .of_node, or other information in | |
197 | the device structure. This is detailed further in the "Driver | |
198 | Recommendations" section. | |
199 | ||
200 | In non-driver code, if the presence of ACPI needs to be detected at | |
201 | runtime, then check the value of acpi_disabled. If CONFIG_ACPI is not | |
202 | set, acpi_disabled will always be 1. | |
203 | ||
204 | ||
205 | Device Enumeration | |
206 | ------------------ | |
207 | Device descriptions in ACPI should use standard recognized ACPI interfaces. | |
208 | These may contain less information than is typically provided via a Device | |
209 | Tree description for the same device. This is also one of the reasons that | |
210 | ACPI can be useful -- the driver takes into account that it may have less | |
211 | detailed information about the device and uses sensible defaults instead. | |
212 | If done properly in the driver, the hardware can change and improve over | |
213 | time without the driver having to change at all. | |
214 | ||
215 | Clocks provide an excellent example. In DT, clocks need to be specified | |
216 | and the drivers need to take them into account. In ACPI, the assumption | |
217 | is that UEFI will leave the device in a reasonable default state, including | |
218 | any clock settings. If for some reason the driver needs to change a clock | |
219 | value, this can be done in an ACPI method; all the driver needs to do is | |
220 | invoke the method and not concern itself with what the method needs to do | |
221 | to change the clock. Changing the hardware can then take place over time | |
222 | by changing what the ACPI method does, and not the driver. | |
223 | ||
224 | In DT, the parameters needed by the driver to set up clocks as in the example | |
225 | above are known as "bindings"; in ACPI, these are known as "Device Properties" | |
226 | and provided to a driver via the _DSD object. | |
227 | ||
228 | ACPI tables are described with a formal language called ASL, the ACPI | |
229 | Source Language (section 19 of the specification). This means that there | |
230 | are always multiple ways to describe the same thing -- including device | |
231 | properties. For example, device properties could use an ASL construct | |
232 | that looks like this: Name(KEY0, "value0"). An ACPI device driver would | |
233 | then retrieve the value of the property by evaluating the KEY0 object. | |
234 | However, using Name() this way has multiple problems: (1) ACPI limits | |
235 | names ("KEY0") to four characters unlike DT; (2) there is no industry | |
236 | wide registry that maintains a list of names, minimzing re-use; (3) | |
237 | there is also no registry for the definition of property values ("value0"), | |
238 | again making re-use difficult; and (4) how does one maintain backward | |
239 | compatibility as new hardware comes out? The _DSD method was created | |
240 | to solve precisely these sorts of problems; Linux drivers should ALWAYS | |
241 | use the _DSD method for device properties and nothing else. | |
242 | ||
243 | The _DSM object (ACPI Section 9.14.1) could also be used for conveying | |
244 | device properties to a driver. Linux drivers should only expect it to | |
245 | be used if _DSD cannot represent the data required, and there is no way | |
246 | to create a new UUID for the _DSD object. Note that there is even less | |
247 | regulation of the use of _DSM than there is of _DSD. Drivers that depend | |
248 | on the contents of _DSM objects will be more difficult to maintain over | |
249 | time because of this; as of this writing, the use of _DSM is the cause | |
250 | of quite a few firmware problems and is not recommended. | |
251 | ||
252 | Drivers should look for device properties in the _DSD object ONLY; the _DSD | |
253 | object is described in the ACPI specification section 6.2.5, but this only | |
254 | describes how to define the structure of an object returned via _DSD, and | |
255 | how specific data structures are defined by specific UUIDs. Linux should | |
256 | only use the _DSD Device Properties UUID [5]: | |
257 | ||
258 | -- UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301 | |
259 | ||
260 | -- http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf | |
261 | ||
262 | The UEFI Forum provides a mechanism for registering device properties [4] | |
263 | so that they may be used across all operating systems supporting ACPI. | |
264 | Device properties that have not been registered with the UEFI Forum should | |
265 | not be used. | |
266 | ||
267 | Before creating new device properties, check to be sure that they have not | |
268 | been defined before and either registered in the Linux kernel documentation | |
269 | as DT bindings, or the UEFI Forum as device properties. While we do not want | |
270 | to simply move all DT bindings into ACPI device properties, we can learn from | |
271 | what has been previously defined. | |
272 | ||
273 | If it is necessary to define a new device property, or if it makes sense to | |
274 | synthesize the definition of a binding so it can be used in any firmware, | |
275 | both DT bindings and ACPI device properties for device drivers have review | |
276 | processes. Use them both. When the driver itself is submitted for review | |
277 | to the Linux mailing lists, the device property definitions needed must be | |
278 | submitted at the same time. A driver that supports ACPI and uses device | |
279 | properties will not be considered complete without their definitions. Once | |
280 | the device property has been accepted by the Linux community, it must be | |
281 | registered with the UEFI Forum [4], which will review it again for consistency | |
282 | within the registry. This may require iteration. The UEFI Forum, though, | |
283 | will always be the canonical site for device property definitions. | |
284 | ||
285 | It may make sense to provide notice to the UEFI Forum that there is the | |
286 | intent to register a previously unused device property name as a means of | |
287 | reserving the name for later use. Other operating system vendors will | |
288 | also be submitting registration requests and this may help smooth the | |
289 | process. | |
290 | ||
291 | Once registration and review have been completed, the kernel provides an | |
292 | interface for looking up device properties in a manner independent of | |
293 | whether DT or ACPI is being used. This API should be used [6]; it can | |
294 | eliminate some duplication of code paths in driver probing functions and | |
295 | discourage divergence between DT bindings and ACPI device properties. | |
296 | ||
297 | ||
298 | Programmable Power Control Resources | |
299 | ------------------------------------ | |
300 | Programmable power control resources include such resources as voltage/current | |
301 | providers (regulators) and clock sources. | |
302 | ||
303 | With ACPI, the kernel clock and regulator framework is not expected to be used | |
304 | at all. | |
305 | ||
306 | The kernel assumes that power control of these resources is represented with | |
307 | Power Resource Objects (ACPI section 7.1). The ACPI core will then handle | |
308 | correctly enabling and disabling resources as they are needed. In order to | |
309 | get that to work, ACPI assumes each device has defined D-states and that these | |
310 | can be controlled through the optional ACPI methods _PS0, _PS1, _PS2, and _PS3; | |
311 | in ACPI, _PS0 is the method to invoke to turn a device full on, and _PS3 is for | |
312 | turning a device full off. | |
313 | ||
314 | There are two options for using those Power Resources. They can: | |
315 | ||
316 | -- be managed in a _PSx method which gets called on entry to power | |
317 | state Dx. | |
318 | ||
319 | -- be declared separately as power resources with their own _ON and _OFF | |
320 | methods. They are then tied back to D-states for a particular device | |
321 | via _PRx which specifies which power resources a device needs to be on | |
322 | while in Dx. Kernel then tracks number of devices using a power resource | |
323 | and calls _ON/_OFF as needed. | |
324 | ||
325 | The kernel ACPI code will also assume that the _PSx methods follow the normal | |
326 | ACPI rules for such methods: | |
327 | ||
328 | -- If either _PS0 or _PS3 is implemented, then the other method must also | |
329 | be implemented. | |
330 | ||
331 | -- If a device requires usage or setup of a power resource when on, the ASL | |
332 | should organize that it is allocated/enabled using the _PS0 method. | |
333 | ||
334 | -- Resources allocated or enabled in the _PS0 method should be disabled | |
335 | or de-allocated in the _PS3 method. | |
336 | ||
337 | -- Firmware will leave the resources in a reasonable state before handing | |
338 | over control to the kernel. | |
339 | ||
340 | Such code in _PSx methods will of course be very platform specific. But, | |
341 | this allows the driver to abstract out the interface for operating the device | |
342 | and avoid having to read special non-standard values from ACPI tables. Further, | |
343 | abstracting the use of these resources allows the hardware to change over time | |
344 | without requiring updates to the driver. | |
345 | ||
346 | ||
347 | Clocks | |
348 | ------ | |
349 | ACPI makes the assumption that clocks are initialized by the firmware -- | |
350 | UEFI, in this case -- to some working value before control is handed over | |
351 | to the kernel. This has implications for devices such as UARTs, or SoC-driven | |
352 | LCD displays, for example. | |
353 | ||
354 | When the kernel boots, the clocks are assumed to be set to reasonable | |
355 | working values. If for some reason the frequency needs to change -- e.g., | |
356 | throttling for power management -- the device driver should expect that | |
357 | process to be abstracted out into some ACPI method that can be invoked | |
358 | (please see the ACPI specification for further recommendations on standard | |
359 | methods to be expected). The only exceptions to this are CPU clocks where | |
360 | CPPC provides a much richer interface than ACPI methods. If the clocks | |
361 | are not set, there is no direct way for Linux to control them. | |
362 | ||
363 | If an SoC vendor wants to provide fine-grained control of the system clocks, | |
364 | they could do so by providing ACPI methods that could be invoked by Linux | |
365 | drivers. However, this is NOT recommended and Linux drivers should NOT use | |
366 | such methods, even if they are provided. Such methods are not currently | |
367 | standardized in the ACPI specification, and using them could tie a kernel | |
368 | to a very specific SoC, or tie an SoC to a very specific version of the | |
369 | kernel, both of which we are trying to avoid. | |
370 | ||
371 | ||
372 | Driver Recommendations | |
373 | ---------------------- | |
374 | DO NOT remove any DT handling when adding ACPI support for a driver. The | |
375 | same device may be used on many different systems. | |
376 | ||
377 | DO try to structure the driver so that it is data-driven. That is, set up | |
378 | a struct containing internal per-device state based on defaults and whatever | |
379 | else must be discovered by the driver probe function. Then, have the rest | |
380 | of the driver operate off of the contents of that struct. Doing so should | |
381 | allow most divergence between ACPI and DT functionality to be kept local to | |
382 | the probe function instead of being scattered throughout the driver. For | |
383 | example: | |
384 | ||
385 | static int device_probe_dt(struct platform_device *pdev) | |
386 | { | |
387 | /* DT specific functionality */ | |
388 | ... | |
389 | } | |
390 | ||
391 | static int device_probe_acpi(struct platform_device *pdev) | |
392 | { | |
393 | /* ACPI specific functionality */ | |
394 | ... | |
395 | } | |
396 | ||
397 | static int device_probe(struct platform_device *pdev) | |
398 | { | |
399 | ... | |
400 | struct device_node node = pdev->dev.of_node; | |
401 | ... | |
402 | ||
403 | if (node) | |
404 | ret = device_probe_dt(pdev); | |
405 | else if (ACPI_HANDLE(&pdev->dev)) | |
406 | ret = device_probe_acpi(pdev); | |
407 | else | |
408 | /* other initialization */ | |
409 | ... | |
410 | /* Continue with any generic probe operations */ | |
411 | ... | |
412 | } | |
413 | ||
414 | DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it | |
415 | clear the different names the driver is probed for, both from DT and from | |
416 | ACPI: | |
417 | ||
418 | static struct of_device_id virtio_mmio_match[] = { | |
419 | { .compatible = "virtio,mmio", }, | |
420 | { } | |
421 | }; | |
422 | MODULE_DEVICE_TABLE(of, virtio_mmio_match); | |
423 | ||
424 | static const struct acpi_device_id virtio_mmio_acpi_match[] = { | |
425 | { "LNRO0005", }, | |
426 | { } | |
427 | }; | |
428 | MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match); | |
429 | ||
430 | ||
431 | ASWG | |
432 | ---- | |
433 | The ACPI specification changes regularly. During the year 2014, for instance, | |
434 | version 5.1 was released and version 6.0 substantially completed, with most of | |
435 | the changes being driven by ARM-specific requirements. Proposed changes are | |
436 | presented and discussed in the ASWG (ACPI Specification Working Group) which | |
437 | is a part of the UEFI Forum. | |
438 | ||
439 | Participation in this group is open to all UEFI members. Please see | |
440 | http://www.uefi.org/workinggroup for details on group membership. | |
441 | ||
442 | It is the intent of the ARMv8 ACPI kernel code to follow the ACPI specification | |
443 | as closely as possible, and to only implement functionality that complies with | |
444 | the released standards from UEFI ASWG. As a practical matter, there will be | |
445 | vendors that provide bad ACPI tables or violate the standards in some way. | |
446 | If this is because of errors, quirks and fixups may be necessary, but will | |
447 | be avoided if possible. If there are features missing from ACPI that preclude | |
448 | it from being used on a platform, ECRs (Engineering Change Requests) should be | |
449 | submitted to ASWG and go through the normal approval process; for those that | |
450 | are not UEFI members, many other members of the Linux community are and would | |
451 | likely be willing to assist in submitting ECRs. | |
452 | ||
453 | ||
454 | Linux Code | |
455 | ---------- | |
456 | Individual items specific to Linux on ARM, contained in the the Linux | |
457 | source code, are in the list that follows: | |
458 | ||
459 | ACPI_OS_NAME This macro defines the string to be returned when | |
460 | an ACPI method invokes the _OS method. On ARM64 | |
461 | systems, this macro will be "Linux" by default. | |
462 | The command line parameter acpi_os=<string> | |
463 | can be used to set it to some other value. The | |
464 | default value for other architectures is "Microsoft | |
465 | Windows NT", for example. | |
466 | ||
467 | ACPI Objects | |
468 | ------------ | |
469 | Detailed expectations for ACPI tables and object are listed in the file | |
470 | Documentation/arm64/acpi_object_usage.txt. | |
471 | ||
472 | ||
473 | References | |
474 | ---------- | |
475 | [0] http://silver.arm.com -- document ARM-DEN-0029, or newer | |
476 | "Server Base System Architecture", version 2.3, dated 27 Mar 2014 | |
477 | ||
478 | [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0044a/Server_Base_Boot_Requirements.pdf | |
479 | Document ARM-DEN-0044A, or newer: "Server Base Boot Requirements, System | |
480 | Software on ARM Platforms", dated 16 Aug 2014 | |
481 | ||
482 | [2] http://www.secretlab.ca/archives/151, 10 Jan 2015, Copyright (c) 2015, | |
483 | Linaro Ltd., written by Grant Likely. A copy of the verbatim text (apart | |
484 | from formatting) is also in Documentation/arm64/why_use_acpi.txt. | |
485 | ||
486 | [3] AMD ACPI for Seattle platform documentation: | |
487 | http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Seattle_ACPI_Guide.pdf | |
488 | ||
489 | [4] http://www.uefi.org/acpi -- please see the link for the "ACPI _DSD Device | |
490 | Property Registry Instructions" | |
491 | ||
492 | [5] http://www.uefi.org/acpi -- please see the link for the "_DSD (Device | |
493 | Specific Data) Implementation Guide" | |
494 | ||
495 | [6] Kernel code for the unified device property interface can be found in | |
496 | include/linux/property.h and drivers/base/property.c. | |
497 | ||
498 | ||
499 | Authors | |
500 | ------- | |
501 | Al Stone <al.stone@linaro.org> | |
502 | Graeme Gregory <graeme.gregory@linaro.org> | |
503 | Hanjun Guo <hanjun.guo@linaro.org> | |
504 | ||
505 | Grant Likely <grant.likely@linaro.org>, for the "Why ACPI on ARM?" section |