[v5] powerpc: gpio driver for mpc8349/8572/8610 and compatible

[Trent Piepho]

On Thu, 30 Oct 2008, Peter Korsgaard wrote:
>>>>>> "Trent" == Trent Piepho <tpiepho at freescale.com> writes:
> Trent> On Tue, 23 Sep 2008, Peter Korsgaard wrote:
> >> +- compatible : "fsl,<CHIP>-gpio" followed by "fsl,mpc8349-gpio" for
> >> +  83xx, "fsl,mpc8572-gpio" for 85xx and "fsl,mpc8610-gpio" for 86xx.
>
> Trent> Why have the three different compatible settings when the code
> Trent> doesn't do anything different?
>
> Purely for cosmetics / ease of use - As requested by Kumar:
>
> http://ozlabs.org/pipermail/linuxppc-dev/2008-September/062934.html

Though I see Scott didn't agree.

> >> +#define MPC8XXX_GPIO_PINS	32
>
> Trent> 8572 has eight GPIOs.
>
> Doesn't matter - It's register interface is compatible. Most real
> world design with the other SoCs also don't have all 32 gpio pins
> available because of pin multiplexing.

Doesn't it seem flawed that 32 gpios will show up under debugfs and via the
sysfs interface, when it's known that there are only 8?

Since there is an 8572 compat property, it's not like it's not solvable.

> Trent> I wrote an MPC8572 GPIO driver back in March, and posted it
> Trent> internally at Freescale on June 2nd.  But it was just
> Trent> ignored...  I wonder what your secret is to get Kumar to apply
> Trent> your patches?  It's too bad this work keeps getting
> Trent> duplicated.
>
> Did you try bribing? ;) No, seriously, why didn't you post it to
> linuxppc-dev, so the rest of the world would know about it?

Well, I get totally ignored posting to an internal Freescale list, it doesn't
seem like it will be any better posting to an external list.

> Trent> But, I'm using the GPIOs to bit-bang a JTAG bus in the 20-30
> Trent> MHz range.  The obvious GPIO driver is *much* too slow for
> Trent> that.  I got less than 3 MHz, and your driver looks like it
> Trent> might be slightly slower than my initial driver.
>
> I would write a dedicated driver for something like that instead of
> using gpiolib.

But the JTAG bus only uses four GPIOs, the other four get used for other
things with gpiolib, like gpio leds for example.  I also found it very handy
to be able to see and modify all the gpio lines, even the ones the JTAG driver
is using, via a sysfs interface to gpiolib.

> Gpiolib has quite some overhead compared to the actual work for
> changing a SoC gpio pin, but it also has some very nice

Certainly is does, but there are ways to make it faster.

> Trent> So I went to a lot of effort to speed it up and managed to
> Trent> increase GPIO performance by nearly a factor of 10.  Trying to
> Trent> commit my driver at this point is probably hopeless and I
> Trent> doubt anyone else cares about gpio speed.  But at least the
> Trent> number of gpios for 8572 can be fixed.
>
> Sure, going dedicated always can improve performance. I recently did
> some work in u-boot talking directly to the mpc83xx spi controller and
> got ~5x throughput compared to the Linux driver.

It's not dedicated though.  The gpiolib interface is still used.