On Fri, Oct 17, 2014 at 8:37 AM, Hanjun Guo hanjun.guo@linaro.org wrote:
If acpi=force is used, the kernel +will ONLY use device configuration information contained in the ACPI tables.
Based on this statement, ...
+In order for the kernel to load and use ACPI tables, the UEFI implementation +MUST set the ACPI_20_TABLE_GUID to point to the RSDP table (the table with +the ACPI signature "RSD PTR "). If this pointer is incorrect and acpi=force +is used, the kernel will disable ACPI and try to use DT to boot.
wouldn't it be more correct to say "If this pointer is incorrect OR acpi=force is used"?
+Forum provides a mechanism for registering such bindings [URL TBD by ASWG]
Did you intend to replace the text in []?
+so that they may be used on any operating system supporting ACPI. Device +properties that have not been registered with the UEFI Forum should not be +used.
Blech. I guess it's necessary, but the information needs to be documented here.
+Drivers should look for device properties in the _DSD object ONLY; the _DSD +object is described in the ACPI specification section 6.2.5, but more +specifically, use the _DSD Device Properties UUID:
- -- UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
- -- http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUI...)
Extra ) here.
+The kernel has an interface for looking up device properties in a manner +independent of whether DT or ACPI is being used and that interface should +be used; it can eliminate some duplication of code paths in driver probing +functions and discourage divergence between DT bindings and ACPI device +properties.
How about a pointer to the documentation for this method?
+Such code in _PS? methods will of course be very platform specific. But,
I would use _PSx instead of _PS? here.
+this allows the driver to abstract out the interface for operating the device +and avoid having to read special non-standard values from ACPI tables. Further, +abstracting the use of these resources allows the hardware to change over time +without requiring updates to the driver.
+Clocks +------ +ACPI makes the assumption that clocks are initialized by the firmware -- +UEFI, in this case -- to some working value before control is handed over +to the kernel. This has implications for devices such as UARTs, or SoC +driven LCD displays, for example.
SOC-driven should be hyphenated.
+When the kernel boots, the clock is assumed to be set to reasonable
to A reasonable
+working value. If for some reason the frequency needs to change -- e.g., +throttling for power management -- the device driver should expect that +process to be abstracted out into some ACPI method that can be invoked +(please see the ACPI specification for further recommendations on standard +methods to be expected). If is not, there is no direct way for ACPI to
If IT is not
+control the clocks.
+Driver Recommendations +---------------------- +DO NOT remove any DT handling when adding ACPI support for a driver. The +same device may be used on many different systems.
+DO try to structure the driver so that it is data driven. That is, set up
data-driven