[PATCH] pinctrl: spawn U300 pinctrl from the COH901 GPIO

[Stephen Warren]

Linus Walleij wrote at Tuesday, February 21, 2012 6:35 AM:
> From: Linus Walleij <linus.walleij at linaro.org>
> 
> This solves the riddle on how the U300 pin controller shall be
> able to reference the struct gpio_chip even though these are
> two separate drivers: spawn the pinctrl child from the GPIO
> driver and pass in the struct gpio_chip as platform data.
> In the process we rename the U300 "pinmux-u300" to
> "pinctrl-u300" so as not to confuse.
> 
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>

That's quite a neat solution, but it's not going to work very well with
device tree, if U300 is being converted to it. The reason is that the
two (GPIO, pinctrl) platform devices would be instantiated directly from
DT by the core DT code. I guess your DT board file does have the option
to explicitly override the platform data passed to your devices to
achieve the same effect, but perhaps there's a different way of making
this work, that doesn't require platform data...

I'd thought about doing the following for Tegra, where we're cheating a
little with the gpio range base value:

When GPIO driver is probed, call a function in the pinctrl driver to
tell it what the "struct gpio_chip *" value is.

When pinctrl is probed, if that call has happened, go ahead and register
the GPIO range, else don't.

In the call from GPIO to pinctrl, if the pinctrl driver has already
probed, register the GPIO range, else just save the gpio_chip value for
later use in the pinctrl driver's probe.

This way, the communication is explicit in code in the drivers, works
whichever order the drivers probe, etc.

Does that sound like a reasonable solution?

It's plausible that with deferred probe, this could be reworked to use
that, but this way might still be better for this case?

-- 
nvpublic