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