On Tue, Apr 5, 2016 at 9:16 PM, Mark Rutland <mark.rutland@xxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
