Re: [PATCH v2 0/2] pinctrl: Intel Cherryview/Braswell support

[Mika Westerberg <mika.westerberg@linux.intel.com>]

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.