linux-kernel - Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 29 Nov 2008 14:48:51 -0800
From:	David Brownell <david-b@...bell.net>
To:	Sam Ravnborg <sam@...nborg.org>,
	Jaya Kumar <jayakumar.lkml@...il.com>
Cc:	Eric Miao <eric.y.miao@...il.com>,
	Jean Delvare <khali@...ux-fr.org>,
	Eric Miao <eric.miao@...vell.com>,
	Haavard Skinnemoen <hskinnemoen@...el.com>,
	Philipp Zabel <philipp.zabel@...il.com>,
	Russell King <rmk@....linux.org.uk>,
	Ben Gardner <bgardner@...tec.com>, Greg KH <greg@...ah.com>,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	linux-fbdev-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org, linux-embedded@...r.kernel.org
Subject: Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins

On Thursday 27 November 2008, Sam Ravnborg wrote:
> > > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/