On Friday, October 03, 2014 02:48:49 PM Mark Rutland wrote:

On Thu, Oct 02, 2014 at 01:15:08PM +0100, Mika Westerberg wrote:

quoted

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?

That depends on whether or not systems with that model show up in the market.
If they do, we will do our best to support them.

We do that for Apple already as much as we practically can.

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.