Re: [PATCH v3 04/15] ACPI: Document ACPI device specific properties
From: Mark Rutland <mark.rutland@arm.com>
Date: 2014-10-03 13:48:56
Also in:
linux-acpi, lkml
On Thu, Oct 02, 2014 at 01:15:08PM +0100, Mika Westerberg wrote:
On Thu, Oct 02, 2014 at 01:51:24PM +0200, Arnd Bergmann wrote:quoted
On Thursday 02 October 2014 13:41:23 Mika Westerberg wrote:quoted
On Wed, Oct 01, 2014 at 09:59:14AM +0200, Arnd Bergmann wrote:quoted
On Wednesday 01 October 2014 04:11:20 Rafael J. Wysocki wrote:quoted
From: Mika Westerberg <mika.westerberg@linux.intel.com>quoted
quoted
+The referenced ACPI device is returned in args->adev if found. + +In addition to simple object references it is also possible to have object +references with arguments. These are represented in ASL as follows: + + Device (\_SB.PCI0.PWM) + { + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () {"#pwm-cells", 2} + } + }) + } +Similarly, the "#foo-cells" syntax is an artifact of the limitations of the DT syntax, and I'd assume there would be a better way to encode this in ACPI. Also, a "cell" in Open Firmware is defined as a big-endian 32-bit value, which doesn't directly correspond to something in ACPI, and the '#' character is an artifact of the use of the Forth language in Open Firmware, which you also don't have here.Same here, we tried to make it follow closely the DT description. It is probably not the best/optimal encoding for ACPI but it is documented well in Documentation/devicetree/bindings so why not use it. The summary email from Darren at KS also mentions that for the existing drivers, the existing schemas should be common for both implementations [1]. For new bindings we probably should look out if they can be better represented using ACPI types. [1] http://lwn.net/Articles/609373/I thought when we had discussed the subsystem specific bindings, the consensus there was to have subsystem specific accessors and properties/tables. I would argue that for everything that ACPI already has (interrupts, registers, gpio, dmaengine, ...) the native method should be used, possibly using _DSD to provide naming for otherwise anonymous references.Absolutely. That's precisely what we do in the GPIO patch of this series. E.g we use ACPI GpioIo/GpioInt _CRS resources but give name to the GPIOs with the help of _DSD. For things that don't have correspondence in ACPI but have well defined existing DT schema, like PWMs, we should follow that.
I'm rather concerned that while that's expedient for us, that's going to end up in the creation of Linux-only ACPI tables. If any other OS vendor decides they need to model this information and doesn't wnat to pick up Linux _DSD bindings, what happens if they try to get an explicit object model defined in ACPI for those objects? Mark.