Arnd Bergmann wrote at Tuesday, August 16, 2011 8:37 AM:

On Tuesday 16 August 2011, Linus Walleij wrote:

quoted

One specific thing worries me: Grant asked me to make sure
to NOT create a global pin number space for the pinmuxes (and thus
pinctrl). This means that in order to proceed, mappings of pinmux
groups or pincontrol (such as bias) groups, each device using such
an entity need to reference the intended pincontroller/mux instance.

Say mmc instance 0 need pingroup foo on pincontroller bar
means that there must be a specific reference from mmc.0:s
struct device * to pinctrl bar:s struct device *. Maybe this is
peanuts in DT, sorry not enough insight.

I think what you are looking for is the equivalent of the
interrupt-parent property for pinmux. The idea is that each
node in the device tree can point to a device managing the
pinmux, so reference would point to a local number in that
space. We have discussed this for the GPIO case already, and
I suspect that the two should be identical (gpio-controller
and pinmux-controller using the same device node and same
property to refer to them). Since the pinmux-parent
(gpio-parent, ...) property gets inherited by all child
devices, you only need to set it once at the root of the
device tree for the simple case where there is only one
controller.

One issue here: There isn't always a single gpio/pinmux parent; as a
concrete example, the ALSA/ASoC driver for Tegra+WM8903 uses GPIOs both
from Tegra itself, and from the WM8903 audio codec.

I could imagine the same being true in basically any case where one
device uses N GPIOs (e.g. SD controller with power, change-detect,
and read-only GPIOs; some could easily come from the SoC and some
from a GPIO expander).

I'm not quite so sure that multiple parents would be useful for pinmux,
but I wouldn't say that it was impossible...

-- 
nvpublic