Lines Matching refs:be
3 ACPI can be used for ARMv8 general purpose servers designed to follow
6 can be retrieved simply by visiting [1], but the SBSA is currently only
13 by the specification can be found via http://www.uefi.org/acpi.
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.
33 of the summary text almost directly, to be honest.
48 Such bindings could be defined in DT at some point, but doing so means ARM
53 and an OS is important. Hardware vendors would not be required to implement
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
71 need to be ported to each and every device individually. It allows the
92 kernel and firmware to agree on a consistent abstraction that can be
94 abstraction is supported, systems can be updated without necessarily having
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,
109 ACPI support in drivers and subsystems for ARMv8 should never be mutually
115 Regardless of whether DT or ACPI is used, the kernel must always be capable
135 Processing of ACPI tables may be disabled by passing acpi=off on the kernel
145 If the pointer to the RSDP table is correct, the table will be mapped into
160 be ignored on arm64.
163 be enforced by the ACPI core on arm64. Doing so allows the ACPI core to
165 hardware from other architectures. Any fields that are not to be used for
166 hardware reduced mode must be set to zero.
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
200 In non-driver code, if the presence of ACPI needs to be detected at
202 set, acpi_disabled will always be 1.
210 ACPI can be useful -- the driver takes into account that it may have less
215 Clocks provide an excellent example. In DT, clocks need to be specified
219 value, this can be done in an ACPI method; all the driver needs to do is
243 The _DSM object (ACPI Section 9.14.1) could also be used for conveying
245 be used if _DSD cannot represent the data required, and there is no way
248 on the contents of _DSM objects will be more difficult to maintain over
263 so that they may be used across all operating systems supporting ACPI.
265 not be used.
267 Before creating new device properties, check to be sure that they have not
274 synthesize the definition of a binding so it can be used in any firmware,
277 to the Linux mailing lists, the device property definitions needed must be
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
283 will always be the canonical site for device property definitions.
288 also be submitting registration requests and this may help smooth the
293 whether DT or ACPI is being used. This API should be used [6]; it can
303 With ACPI, the kernel clock and regulator framework is not expected to be used
310 can be controlled through the optional ACPI methods _PS0, _PS1, _PS2, and _PS3;
316 -- be managed in a _PSx method which gets called on entry to power
319 -- be declared separately as power resources with their own _ON and _OFF
321 via _PRx which specifies which power resources a device needs to be on
329 be implemented.
334 -- Resources allocated or enabled in the _PS0 method should be disabled
340 Such code in _PSx methods will of course be very platform specific. But,
354 When the kernel boots, the clocks are assumed to be set to reasonable
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
364 they could do so by providing ACPI methods that could be invoked by Linux
375 same device may be used on many different systems.
379 else must be discovered by the driver probe function. Then, have the rest
381 allow most divergence between ACPI and DT functionality to be kept local to
444 the released standards from UEFI ASWG. As a practical matter, there will be
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
451 likely be willing to assist in submitting ECRs.
459 ACPI_OS_NAME This macro defines the string to be returned when
461 systems, this macro will be "Linux" by default.
463 can be used to set it to some other value. The
495 [6] Kernel code for the unified device property interface can be found in