GPIO and Pinmux device tree support for Exynos.

[Stephen Warren]

Thomas Abraham wrote at Friday, August 12, 2011 1:06 AM:
> On 12 August 2011 01:36, Stephen Warren <swarren at nvidia.com> wrote:
> > Thomas Abraham wrote at Thursday, August 11, 2011 12:09 PM:
> >> I did some work on the gpio and pinmux device tree support for exynos.
> >> I thought to discuss with you about what was done before proceeding
> >> further.
...
> >> GPA: gpio-controller at 11400000 {
> >>               compatible = "samsung,exynos4-gpio-gpa0", "samsung,exynos4-gpio";
> >>               #gpio-cells = <4>;
> >>               gpio-controller;
> >> };
...
> >> Device nodes would include the gpio's that it would use (as in below example)
> >>
> >> serial at 13800000 {
> >>               compatible = "samsung,s5pv310-uart";
> >>               reg = <0x13800000 0x100>;
> >>               interrupts = <116>;
> >>               gpios = <&GPA  0  2  0  2   /* Tx */
> >>                               &GPA  1  2  0  2>;  /* Rx */
> >> };
> >
> > The one problem with this approach is that presumably every single driver
> > (e.g. for the serial port above) must look for and handle the gpios
> > property, whereas presumably a serial port would otherwise have no need
> > to deal with GPIOs.
> 
> The pin-mux setting on exynos4 is done in the device driver's probe
> function. A pointer to a function, which is in the platform code, that
> sets up the pin-mux for the driver/peripheral is passed in the
> platform data of the driver. The driver invokes that function during
> the probe to setup the pinmux. And all drivers adopt this approach.
> 
> The advantage of this approach is that the pin-mux are configured at
> driver probe time and makes it possible to switch the functionality of
> the pin at runtime if a pin is used by two controllers.

Does this happen often in practice? It seems like it wouldn't be that
common due to the HW difficulties of using the same SoC pins for different
purposes on the same board.

Once Linus W's proposed pinctrl API is present, that might address this
situation more directly. I don't recall any detailed discussion about how
that API would integrate with device tree. That's probably a conversation
we need to have.

> I intend to
> retain this feature even when driver uses dt (no more function pointer
> from platform data). So, as you said, every driver will require a
> change to get a list of gpio's it uses and request them.
> 
> > That's probably quite a bit of work. Also, what if some pins need to be
> > configured for which there is no driver to parse that property?
> 
> Is there any particular example for this? Will there not be a node in
> dt node for such a case. If there is a node in dt which includes a
> gpio property, it should be possible to use this approach.

I don't have any examples. It may well be a tenuous benefit. I suppose
that if any such usage did come up, we could always invent an appropriate
driver for the HW module that was being driven out on those pins, and
add the associated DT node to instantiate it.

> > I just recently started working on this for Tegra, and in
> > http://www.spinics.net/lists/arm-kernel/msg136138.html
> > I proposed listing all the GPIO/pinmux settings directly within the GPIO
> > and pinmux nodes, thus making only the GPIO and pinmux drivers responsible
> > for parsing them. What do you think of that idea?
> 
> I read through your email. Your approach effortlessly integrates with
> the existing Tegra gpio and pinmux code but similar approach would be
> difficult for exynos.
> 
> And for exynos, the gpio and pin-mux registers are all part of a
> single register set. For instance, pin-mux function 0 and 1 when
> selected, configures the gpio as a input line and output line
> respectively. Function 2 to 15 select various other pin function
> modes. So it would be difficult to use your approach for exynos.

The idea behind my proposal in that thread was that each GPIO and/or
pinmux controller would define its own custom binding as appropriate
for the hardware.

Tegra has separate GPIO and pinmux controllers, and hence has two device
tree nodes to represent them.

For Exynos, given your description, I assume you'd describe the pin
muxing purely within the pinmux DT node, including "GPIO" as a mux/function
option just like any other, since that's how the HW works.

It might also be possible to create a unified DT binding for pin-muxing
driven by Linus W's pinctrl API. However, that binding would stray towards
being tied to SW (the pinctrl API) rather than pure HW, which a per-SoC
custom binding would represent.

-- 
nvpublic