Lines Matching refs:to
3 ACPI can be used for ARMv8 general purpose servers designed to follow
7 available to those with an ARM login due to ARM IP licensing concerns.
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
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
29 useful to understand why ACPI is being used. Several technologies already
33 of the summary text almost directly, to be honest.
37 -- ACPI’s bytecode (AML) allows the platform to encode hardware behavior,
39 able to encode behavior is a key tool used in supporting operating
43 platform is allowed to do into a specific model, while still providing
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,
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
64 changes being made to ACPI is being driven by Linux.
66 Key to the use of ACPI is the support model. For servers in general, the
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
78 in place. DT does exactly what Linux needs it to when working with vertically
90 to provide backward compatibility for Linux kernels. In the server market,
92 kernel and firmware to agree on a consistent abstraction that can be
95 to replace the kernel.
99 -- it's baseline. ACPI firmware must continue to work, even though it may
122 The only defined method for passing ACPI tables to the kernel on ARMv8
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.
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.
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
141 is used, the kernel will disable ACPI and try to use DT to boot instead; the
145 If the pointer to the RSDP table is correct, the table will be mapped into
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
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.
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):
189 able to boot properly since it may not be able to configure all of the
200 In non-driver code, if the presence of ACPI needs to be detected at
213 time without the driver having to change at all.
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
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
224 In DT, the parameters needed by the driver to set up clocks as in the example
226 and provided to a driver via the _DSD object.
230 are always multiple ways to describe the same thing -- including device
235 names ("KEY0") to four characters unlike DT; (2) there is no industry
240 to solve precisely these sorts of problems; Linux drivers should ALWAYS
244 device properties to a driver. Linux drivers should only expect it to
246 to create a new UUID for the _DSD object. Note that there is even less
248 on the contents of _DSM objects will be more difficult to maintain over
254 describes how to define the structure of an object returned via _DSD, and
267 Before creating new device properties, check to be sure that they have not
270 to simply move all DT bindings into ACPI device properties, we can learn from
273 If it is necessary to define a new device property, or if it makes sense to
277 to the Linux mailing lists, the device property definitions needed must be
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
303 With ACPI, the kernel clock and regulator framework is not expected to be used
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
311 in ACPI, _PS0 is the method to invoke to turn a device full on, and _PS3 is for
316 -- be managed in a _PSx method which gets called on entry to power
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
338 over control to the kernel.
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.
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
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.,
357 process to be abstracted out into some ACPI method that can be invoked
359 methods to be expected). The only exceptions to this are CPU clocks where
361 are not set, there is no direct way for Linux to control them.
363 If an SoC vendor wants to provide fine-grained control of the system clocks,
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.
377 DO try to structure the driver so that it is data-driven. That is, set up
381 allow most divergence between ACPI and DT functionality to be kept local to
414 DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it
439 Participation in this group is open to all UEFI members. Please see
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
449 submitted to ASWG and go through the normal approval process; for those that
451 likely be willing to assist in submitting ECRs.
456 Individual items specific to Linux on ARM, contained in the the Linux
459 ACPI_OS_NAME This macro defines the string to be returned when
463 can be used to set it to some other value. The