From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sun, 17 Aug 2014 11:52:16 -0500 Subject: Re: [RFC PATCH 0/9] Add ACPI _DSD and unified device properties support From: Darren Hart Message-ID: References: <1408172039-32513-1-git-send-email-mika.westerberg@linux.intel.com> <20140817141106.GA20345@core.coreip.homeip.net> In-Reply-To: <20140817141106.GA20345@core.coreip.homeip.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit To: Dmitry Torokhov Cc: Mika Westerberg , "Rafael J. Wysocki" , Al Stone , Olof Johansson , Matthew Garrett , Matt Fleming , David Woodhouse , "H. Peter Anvin" , Jacob Pan , Josh Triplett , Aaron Lu , Max Eliaser , Robert Moore , Len Brown , Greg Kroah-Hartman , Linus Walleij , Alexandre Courbot , Mark Brown , Bryan Wu , Richard Purdie , Samuel Ortiz , Lee Jones , Grant Likely , Rob Herring , linux-acpi@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org List-ID: On 8/17/14, 7:11, "Dmitry Torokhov" wrote: >On Sat, Aug 16, 2014 at 09:06:05AM -0700, Darren Hart wrote: >> On 8/15/14, 23:53, "Mika Westerberg" >> 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