Re: [RFC PATCH 0/9] Add ACPI _DSD and unified device properties support

[Darren Hart <dvhart@linux.intel.com>]

On 8/17/14, 7:11, "Dmitry Torokhov" <dmitry.torokhov@gmail.com> wrote:

>On Sat, Aug 16, 2014 at 09:06:05AM -0700, Darren Hart wrote:
>> On 8/15/14, 23:53, "Mika Westerberg" <mika.westerberg@linux.intel.com>
>> wrote:
>> 
>> >The recent publication of the ACPI 5.1 specification [1] adds a
>>reserved
>> >name
>> >for Device Specific Data (_DSD, Section 6.2.5). This mechanism allows
>>for
>> >passing arbitrary hardware description data to the OS. The exact format
>> >of the
>> >_DSD data is specific to the UUID paired with it [2].
>> >
>> >An ACPI Device Properties UUID has been defined [3] to provide a format
>> >compatible with existing device tree schemas. The purpose for this was
>>to
>> >allow
>> >for the reuse of the existing schemas and encourage the development of
>> >firmware
>> >agnostic device drivers.
>> >
>> >This series accomplishes the following (as well as some other
>> >dependencies):
>> >
>> > * Add _DSD support to the ACPI core
>> >   This simply reads the UUID and the accompanying Package
>> >
>> > * Add ACPI Device Properties _DSD format support
>> >   This understands the hierarchical key:value pair structure
>> >   defined by the Device Properties UUID
>> >
>> > * Add a unified device properties API with ACPI and OF backends
>> >   This provides for the firmware agnostic device properties
>> >   Interface to be used by drivers
>> >
>> > * Provides 2 example drivers that were previously Device Tree aware
>>that
>> >   can now be used with either Device Tree or ACPI Device Properties.
>>The
>> >   both drivers use an arbitrary _HID.
>> >
>> >This has been tested on Minnowboard with relevant parts of the modified
>> >DSDT at the end of this email.
>> 
>> 
>> This eliminates the need for the board files that were the subject of my
>> "How not to write x86 platform drivers" talk at ELC-E last year. With
>> These ACPI core changes and the small changes to the two example
>>drivers,
>> the Minnowboard can now use the GPIO buttons and LEDs through these
>> drivers by adding the ASL fragment below to the DSDT.
>
>>From the drivers perspective I am less than impressed with the need to
>reshuffle all the drivers to support ACPI with the new API. I thought the
>plan
>was to try and keep OF API and try to translate as much as possible to it?

Hi Dmitry,

We discussed this point at length. Ultimately we felt that any solution
would require changes to what the drivers use today. The OF interface uses
OF-domain-specific structures that would have to be wrapped and translated
for ACPI. Providing a firmware-agnostic device properties interface allows
for drivers to be unaware of the underlying firmware implementation, and
for each firmware backend to be a clean implementation with structures and
logic that is appropriate for each.

I do acknowledge the challenge associated with updating the 200+ OF-aware
drivers in the kernel today. The conversion itself is fairly straight
forward, but testing each will require a significant coordination effort.

>
>The same goes for bringing arbitrary HIDs into the drivers. Can we have
>HID->OF
>naming hidden in ACPI (define a new property like "dt-name",  "of_compat"
>or
>whatever) and have ACPI core map one to another.

Another topic of some debate. We have discussed the following:
OF-compatible schemas implemented in ACPI should use the Device Properties
HID, PRP0000, and contain a "compatible" property listing the driver. This
removes the need to allocate new HIDs and reduces the changes to the
current OF drivers (although only minimally so). However, this would
require changes to the driver core to match not only on ACPI HID, but also
include the _DSD "compatible" property - something some developers have
objected to.

I believe the PRP0000 method makes a lot of sense for platform devices, as
opposed to "real" hardware, for things like gpio-keys or leds-gpio where
the driver is mostly glue logic as opposed to providing the hardware
communication itself.

Thanks,

-- 
Darren Hart					Open Source Technology Center
darren.hart@intel.com				            Intel Corporation