On Thursday 27 November 2008, Sam Ravnborg wrote:

quoted

quoted

So my "is it generic enough" question is more at the level of "Are
there enough Linux systems that need this sort of thing to justify
generic support?".  I happen not to have come across the need for
such ganged access from Linux (yet).  Whereas I've yet to use non-x86
Linux systems that don't need to manipulate individual GPIO pins...

I have come across the following scenarios where a bus set of gpio is useful:
- Broadsheet E-Ink controller (uses 16-bit data bus over GPIO)
  framebuffer device (this patch is for this)
- Apollo/Hecuba E-Ink controller (uses 8-bit data bus over GPIO)
  framebuffer device
- 8-bit parallel IO matrix LCD controllers, such as the Samsung KS108,
  also Hitachi, etc

All of those can also be handled with traditional parallel data
busses too, of course.  Are you saying you've seen these used
with Linux systems?  Enough to justify generic support?

I've certainly seen how some of those LCD controllers, graphical
or character based, work with microcontrollers.  They're very
widely available too ... so I can imagine various uClinux systems
have one hooked up.  Most of the Linux system hookups I've happened
across use USB or serial links (e.g. the crystalfontz.com stuff)
since modern PCs are severely GPIO-deprived.

Another example where ganged access might help is keypad matrices.

We have such a system at work. And we need fast acces to the gpio pins
when updating the LCD.
I have not written/looked to deep at the code I just recall it was
a bit messy and not something I would be proud of submitting to any ML.

Often times such messiness is more because the code never got
cleaned up, because it's kind of a one-off to support particular
boards.

You could say that the gpiolib implementation framework got its
start, in part, as a way to unclutter some kernel trees that
had way too much one-off stuff like that.  ;)

- Dave