Re: [PATCH v5 18/18] Documentation: ACPI for ARM64

[Timur Tabi <timur@codeaurora.org>]

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-UUID.pdf)

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


-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.