[PATCH 1/4] drivers: create a pinmux subsystem

On Mon, May 2, 2011 at 1:52 PM, Stephen Warren [off-list ref] wrote:

Linus Walleij wrote at Monday, May 02, 2011 1:16 PM:

quoted

From: Linus Walleij <redacted>

This creates a subsystem for handling of pinmux devices. These are
devices that enable and disable groups of pins on primarily PGA and
BGA type of chip packages and common in embedded systems.

I would avoid any references to particular package types; I've seen
pinmuxing applied to PLCC and DIP/DIL too, and in general, it's possible
irrespective of package type.

quoted

This is being done to depopulate the arch/arm/* directory of such
custom drivers and try to abstract the infrastructure they all
need. See the Documentation/pinmux.txt file that is part of this
patch for more details.

quoted

diff --git a/Documentation/pinmux.txt b/Documentation/pinmux.txt

...
+The mux settings are:
+
+- Oriented around enumerated physical pins or pads denoted by unsigned
+ ?integers in the range 0..MAX_INT. Every pin on your system (or atleast
+ ?every pin that can be muxed) should have a unique number. The numberspace

Does this imply a model where each pin's "special function" can be
controlled independently? I think reading through the document that
isn't the case, but I just wanted to be sure.

In particular, NVIDIA Tegra has a setup where:

* Pinmux configuration for "special functions" is at a "pad-group"
?level, where there may be 1..N pins in a pad-group, and there is a
?single register field that defines the current special function routed
?to/from all pins in that pad-group at once.

* Each pad group can be assigned 1 of N special functions (none might be
?an option in some/all cases too)

* Some special functions may be assignable to multiple pad groups,
?although obviously only 1 pad group per function at a time.

* GPIO selection is at per-pin granularity; individual pins may be used
?as a GPIO irrespective of what SFR is selected for the pad group
?containing the pin.

* There are also other configurations associated with pinmuxing, such
?as drive strength, pull up/down enables, etc.

Also, some of our drivers use "dynamic pinmuxing". For example, our
downstream I2C driver exposes N I2C busses and reprograms the pinmux
at runtime to attach the actual I2C controller to different sets of
pins, essentially multi-plexing the control across N physical busses.

Tegra has more fun pinmux quirks than just those :)

* Drive strength is also controlled through groups of pins, but
different groups than pinmux.  Most of the drive strength groups are
collections of pad mux groups, but there are a few pins that are in
the same pad mux group but a different drive strength group.
* Setting a pin as a GPIO overrides its group's mux setting, except
for the group's tristate.  You must untristate the entire group to use
a single pin as a GPIO.
* Each group has a "safe mode", but which mux id to select to enter
the safe mode is completely random.

In the end, we determined that there was no way to sanely handle
setting up Tegra's pinmux programatically, and instead required each
board to pass in a table of pinmux settings.