GPIO and Pinmux device tree support for Exynos.

[Thomas Abraham]

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.
>>
>> In the dts file, the interrupt controller node is listed as
>>
>> GPA: gpio-controller at 11400000 {
>>               compatible = "samsung,exynos4-gpio-gpa0", "samsung,exynos4-gpio";
>>               #gpio-cells = <4>;
>>               gpio-controller;
>> };
>>
>> The meaning of the 4 cells are as below. The values of all the cells
>> are set as per the exynos chip specification.
>>
>> < [GPIO Pin Number]  [Pin-Mux Function Number] [Pull Up/Down Setting]
>> [Driver Strength Setting] >
>>
>>
>> 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. 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 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.

Thanks for your suggestions.

Thanks,
Thomas.

>
> Thanks.
>
> --
> nvpublic
>
>