GPIO and Pinmux device tree support for Exynos.

GPIO and Pinmux device tree support for Exynos.

[Thomas Abraham]

Hi Grant,

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@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@13800000 {
		compatible = "samsung,s5pv310-uart";
		reg = <0x13800000 0x100>;
		interrupts = <116>;
		gpios = <&GPA  0  2  0  2   /* Tx */
				&GPA  1  2  0  2>;  /* Rx */
};


When the gpio_chip is registered, the corresponding node is searched
in the device tree and attached to the gpio_chip. Along with node
pointer, the of_gpio_n_cells is set to 4 and the of_xlate function is
set to point to the function listed below.

int exynos4_gpio_xlate(struct gpio_chip *gc, struct device_node *np,
			 const void *gpio_spec, u32 *flags)
{
	const __be32 *gpio = gpio_spec;
	const u32 n = be32_to_cpup(gpio);
	unsigned int pin = gc->base + be32_to_cpu(gpio[0]);

	if (gc->of_gpio_n_cells < 4) {
		WARN_ON(1);
		return -EINVAL;
	}

	if (n > gc->ngpio)
		return -EINVAL;

	/* Set PinMux */
	s3c_gpio_cfgpin(pin, be32_to_cpu(gpio[1]));
	/* Set pull up/down */
	s3c_gpio_setpull(pin, be32_to_cpu(gpio[2]));
	/* Set driver strength */
	s5p_gpio_set_drvstr(pin, be32_to_cpu(gpio[3]));

	return n;
}


The above function translates the gpio controller pin number to a
linux gpio number and sets the pinmux, pull up/down and driver
strength values. The device driver uses the of_get_gpio() function to
get the gpio pin number and then calls gpio_request on that gpio
number. The call to of_get_gpio() invokes the gpio translate function
which sets the pinmux, pull up/down and driver strength values.

This handles the gpio and pinmux requirements for exynos. Would this
approach be acceptable?

Thanks,
Thomas.

RE: GPIO and Pinmux device tree support for Exynos.

[Stephen Warren]

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@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@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.

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?

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?

Thanks.

-- 
nvpublic

Re: GPIO and Pinmux device tree support for Exynos.

[Mitch Bradley]

On 8/11/2011 10:06 AM, Stephen Warren 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@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@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.
>
> 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?
>
> 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'm in favor of handling pin-muxing separately from the individual 
devices connected through the pinmux.  The same device programming model 
can be used for different platforms or SoCs with widely differing pin 
muxing strategies and pinmux programming models.

Pin-muxing is a platform configuration issue, not an attribute of 
individual drivers.

>
> Thanks.
>

Re: GPIO and Pinmux device tree support for Exynos.

[Thomas Abraham]

On 12 August 2011 01:36, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 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@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@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
>
>

RE: 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-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 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@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@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

Re: GPIO and Pinmux device tree support for Exynos.

[Shawn Guo]

On Thu, Aug 11, 2011 at 01:06:19PM -0700, Stephen Warren 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@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@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.
> 
I think that individual driver still needs to look for gpios property
to actually use gpio with gpiolib api like gpio_request(),
gpio_direction_output() etc. no?

> 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?
> 
> 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?
> 

-- 
Regards,
Shawn

Re: GPIO and Pinmux device tree support for Exynos.

[Shawn Guo]

On Fri, Aug 12, 2011 at 01:07:37PM -0700, Stephen Warren wrote:
> Thomas Abraham wrote at Friday, August 12, 2011 1:06 AM:
> > On 12 August 2011 01:36, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 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@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@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 happens often on boards for evaluation purpose.  But yes, as you
mentioned below, we can leave it to pinctrl API. 

Regards,
Shawn

> 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.
> 

Re: GPIO and Pinmux device tree support for Exynos.

[Shawn Guo]

On Thu, Aug 11, 2011 at 11:38:50PM +0530, Thomas Abraham wrote:
> Hi Grant,
> 
> 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.
> 
Well, Grant, besides i.mx and Tegra, this is the third soc custom
pinmux binding.  Are you in a position to change your mind yet :)

-- 
Regards,
Shawn

RE: GPIO and Pinmux device tree support for Exynos.

[Stephen Warren]

Shawn Guo wrote at Saturday, August 13, 2011 8:01 AM:
> On Thu, Aug 11, 2011 at 01:06:19PM -0700, Stephen Warren 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@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@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.
>
> I think that individual driver still needs to look for gpios property
> to actually use gpio with gpiolib api like gpio_request(),
> gpio_direction_output() etc. no?

If those pins are actually used as GPIOs with gpio_set/get_value, then
yes, certainly.

However, given the comments in your example at least, it sounds like those
pins are the serial RX/TX lines, in which case they aren't being used as
GPIOs, but are driven by hardware. As such, I'd expect gpio_direction_*()
to be irrelevant for them, since I think those function are only intended
for SW-controlled literal GPIOs. If HW-controlled pins need direction
configuration, that's logically pinmux functionality rather than GPIO
functionality, even if on Exynos, both those functionalities are provided
by the same HW.

-- 
nvpublic