lkml.org 
[lkml]   [2016]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RFC PATCH 0/4] Add ACPI support for pinctrl configuration
From
On Tue, Apr 5, 2016 at 9:16 PM, Mark Rutland <mark.rutland@arm.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.

\
 
 \ /
  Last update: 2016-04-05 22:21    [W:0.109 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site