Date:	Tue, 5 Apr 2016 23:09:34 +0300
From:	Octavian Purdila <octavian.purdila@...el.com>
To:	Mark Rutland <mark.rutland@....com>
Cc:	"Tirdea, Irina" <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>,
	"Ciocan, Cristina" <cristina.ciocan@...el.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"charles.garcia-tobin@....com" <charles.garcia-tobin@....com>
Subject: Re: [RFC PATCH 0/4] Add ACPI support for pinctrl configuration

On Tue, Apr 5, 2016 at 9:16 PM, Mark Rutland <mark.rutland@....com> wrote:

>>
>> Right, there is an overlap of the pinctrl "sleep" state with the ACPI power
>> management model.
>>
>> However, the main reason for implementing this is setting initial pin multiplexing
>> and configuration. This is normally done by BIOS, but there is currently no way of
>> changing the default configuration (except for a BIOS update). This is a problem
>> when using boards like MinnowBoard, where it is expected to get the board and
>> to be able to add various devices to its exported GPIO pins.
>
> In the absence of a BIOS update, how is it expected that the relevant pinctrl
> settings for a given device will be known? Does the device provide ACPI
> fragments like an SSDT? Does it simply identify itself in some manner, and
> leave the rest to the kernel? Is this entirely user-driven?
>

See this patch set I just proposed: https://lkml.org/lkml/2016/3/31/334

>> We need a way to change default pin multiplexing to enable the functionality
>> required by a specific device. In some cases we also need to set the bias to
>> get things like interrupts working.
>>
>> Another use case for pinctrl states is using custom reset pin configurations that need
>> to be controlled from the driver.
>
> To be clear, I'm not stating that having pinctrl under the OS is necessarily
> wrong, and I can see why the firmware may not have all the relevant knowledge
> in advance. I can certainly see why having the OS in control can be preferable.
>
> My concern is that there is a conflict with the ACPI model, and potential
> fragility, given that:
>
> * The firmware does not have the relevant information in advance for a given
>   device that may be connected (i.e. how devices may change the pinctrl setup
>   is unknown).
>
> * The firmware is to some extent expected to manage pinctrl today (for power
>   management of devices it does know about), and hence a pinctrl device is
>   potentially under shared management of ACPI and the OS.
>
> * The ACPI specification says nothing about this style of pinctrl management,
>   so it is unclear what the expectations are:
>

Does it say anything at all about pinctrl management?

>   - Is a given pinctrl device under shared ownership by the firmware and
>     kernel, or is a given device entirely under the control of just one?
>
>   - How shared access to the pinctrl device is mediated, e.g. is any locking or
>     signalling mechanism required to ensure that firmware and kernel do not
>     access the device simultaneously in a manner that causes problems.
>
>   - Is the firmware permitted to perform power management of devices for which
>     the kernel handles pinctrl? What states can either expect, and when is such
>     management permitted? e.g. must the OS ensure that a device is in its
>     default state? Can it only call power management calls from particular
>     states? What is the restored state?
>
>   - What the expectations are w.r.t. ownership of pins, e.g. must the firmware
>     never change the state of certain pins? Must it save/restore their state in
>     system-wide power-management scenarios like suspend or hibernate?
>
> I think this needs to be raised with the ASWG, and some level of model needs to
> be defined for this, to cater for the issues raised above.
>
> That might be very simple, e.g. pins are never shared, the pinctrl management
> device must permit concurrent accesses by FW and kernel, the kernel is
> responsible for all management of those pins after system reset.
>
> In the absence of that, this is liable to become fragmented and fragile, and is
> practically impossible to rectify post-hoc.
>

All very good points.

Since our focus is for open-ended configurations and for hardware that
it is not know to firmware we only considered the case where the pins
are not touched after the system boots.

Now I wonder what are the cases were the firmware changes the pin
configuration after boot.

Powered by blists - more mailing lists