On Fri, Oct 17, 2014 at 8:37 AM, Hanjun Guo <hanjun.guo@xxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
