Re: [PATCH v3 04/15] ACPI: Document ACPI device specific properties

[Rafael J. Wysocki]

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:
> > On Thu, Oct 02, 2014 at 01:51:24PM +0200, Arnd Bergmann wrote:
> > > On Thursday 02 October 2014 13:41:23 Mika Westerberg wrote:
> > > > On Wed, Oct 01, 2014 at 09:59:14AM +0200, Arnd Bergmann wrote:
> > > > > On Wednesday 01 October 2014 04:11:20 Rafael J. Wysocki wrote:
> > > > > > From: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx>
> > > > 
> > > > > > +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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/