Message-ID: <CAE1zotLcLFACKFaPgp2QUK=6qhWvUGu7hmbK+-XuL7+5arBXVg@mail.gmail.com>
Date:	Tue, 5 Apr 2016 15:51:18 +0300
From:	Octavian Purdila <octavian.purdila@...el.com>
To:	Mark Brown <broonie@...nel.org>
Cc:	Irina Tirdea <irina.tirdea@...el.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Len Brown <lenb@...nel.org>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	Rob Herring <robh+dt@...nel.org>,
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Cristina Ciocan <cristina.ciocan@...el.com>,
	devicetree@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 0/4] Add ACPI support for pinctrl configuration

On Tue, Apr 5, 2016 at 12:40 AM, Mark Brown <broonie@...nel.org> wrote:
> On Thu, Mar 31, 2016 at 02:44:41PM +0300, Irina Tirdea wrote:
>
>> This is a proposal for adding ACPI support for pin controller
>> configuration.
>
>> It has been developed to enable the MinnowBoard and IoT community
>> by providing an easy way to specify pin multiplexing and
>> pin configuration.
>
> So this is mainly targeted at modules being added to base boards?

That is the main use case, yes. Velocity of platform
debugging/enabling is another one.

> Without getting into the binding at all here it seems like this is not
> solving the problem at the right abstraction level.  It's exposing the
> pins on the SoC directly without any tie in with the functionality that
> goes over those pins.

This is not completely true. The pinctrl drivers are exposing
functionality in terms of function groups (e.g., i2c1_grp, spi1_grp,
pwm1_grp, etc.) It is not enough, but it is a step in the right
direction for standard bindings and for tools that can build on top of
this.

>  This means that any binding of a board to an ACPI
> using system that just uses this is going to be entirely specific to the
> particular combination of base and expansion board even if the
> electrical connections are standard.
>

This can be solved by tools that work with high level abstractions and
generate this specific information.

> This is something that people are currently looking at for DT, there the
> discussion has been about defining the connectors as entities and hiding
> the details of the muxing on the SoC behind that along with higher level
> concepts like instantiation of buses like I2C and SPI.  It seems like if
> we do want to try to share between DT and ACPI we should be doing it at
> that level rather than dealing with pinmuxing at the extremely low level
> that pinctrl does.
>

At some point we still need to poke registers. We already have a
drivers that do this (pinctrl) and a standard configuration interface
(the pinctrl device tree bindings). It seems natural to build on top
of this for those higher level concepts / tools.

> Obviously for the more general ACPI use case the idiomatic way of
> handling this is that the OS should never see anything about the
> pin muxing. With DT we need to really know what's going on with the
> pinbox because the model is that even for things built into a single
> board the OS is responsible for managing the pins but that's really not
> how ACPI is expected to work.

Maybe. But we already expose pin control / muxing in
drivers/pinctrl/intel, yes, read-only at this point. Very useful for
debugging. Having write access would make debugging even more useful,
not to mention fast prototyping.

Powered by blists - more mailing lists