Messages in this thread | | | Date | Tue, 4 Nov 2014 10:20:56 +0200 | From | Mika Westerberg <> | Subject | Re: [PATCH v2 0/2] pinctrl: Intel Cherryview/Braswell support |
| |
On Mon, Nov 03, 2014 at 05:24:55PM -0600, Timur Tabi wrote: > On Mon, Nov 3, 2014 at 5:01 AM, Mika Westerberg > <mika.westerberg@linux.intel.com> wrote: > > Hi, > > > > This is second version of the patch series adding pinctrl/GPIO support > > for Intel Braswell and Cherrryview. The previous version can be found here: > > > > https://lkml.org/lkml/2014/10/27/118 > > > > I've dropped patches [2/4] and [3/4] as they are already applied to the > > pinctrl tree. > > Mika, > > I am also trying to add ACPI enablement to my pinctrl driver (not yet > submitted), but I'm new to ACPI and pin control drivers, so I have a > lot of catching up to do. > > In reviewing this patchset, it appears to me that pinctrl-cherryview.c > is a normal pinctrl driver that has an acpi_match_table entry, and > nothing more.
Indeed, it just a normal platform driver that can be enumerated from ACPI using the .acpi_match_table entry.
> Assuming that this driver is booting on an ACPI system, what is the > mechanism that calls into the driver to configure the pins? Is there > a definition for pin control in ASL that provides similar > functionality as the pinctrl nodes in a device tree?
There is nothing like that yet in ACPI world but with the ACPI _DSD patches we are getting properties similar to DT which means that we can provide pinctrl bindings from ACPI systems as well. Typically it has been the BIOS that configures things but it cannot get everything 100% right.
Currently I've been testing the muxing functionality so that I have a small board file that sets mappings and the driver core handles everything from there. For example I have development board where SPI pins are muxed as GPIOs by the BIOS and with the mappings when the SPI device appears the core will mux SPI out of those pins.
| |