GPIO and Pinmux device tree support for Exynos.
Shawn Guo
shawn.guo at freescale.com
Sun Aug 14 00:00:47 EST 2011
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 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.
>
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
More information about the devicetree-discuss
mailing list