Re: GPIOLIB, GPIO_SYS and port-wide accesses

[Ben Nizette <bn@niasdigital.com>]

On Fri, 2009-08-14 at 10:01 +1000, John Williams wrote:
> Did anything ever come of that?

Nothing ever did, though others keep half-heartedly implementing the
same thing every few months.  They seem to disappear before it's
accepted though.

> 
> Per-bit access is pretty inflexible if you are driving a 7-segment
> display or 8-LED bar display, holding lots of file descriptors open
> etc, and lots of syscall overhead.
> 
> sysfs syntax like
> 
> $ echo "240-247" > export
> $ echo 255 > gpio240-247/direction  (8-bit binary mask - output)
> $ echo 255 > gpio240-247/value (all ones)
> 

The first line, to some eyes, would violate the one-value-per-attribute
thing sysfs insists on, but sure there are ways to do this.

> would be reasonably friendly, obviously the underlying gpiolib would
> have to have some notion of coupled ports.

The main stumbling block is that implementers forget that gpiolib is
just one implementation of the gpio api - any solution should

1) define accessor functions for multiple bits in the gpio api
2) implement these in gpiolib and other gpio api implementations (I
think the other implementations at the moment are all just stubs anyway)
3) Get gpiolib to bunt requests to the gpiochip
4) Write support for each gpiochip which has this functionality

The other stumbling block is that this all depends on bitmasks of some
kind or other but there's no good reason to nail this to any particular
word size.  Sure most are 8- or 32-bit banks but we have to deal with
the weird ones too.  In particular, I've seen FPGA-implemented gpio
controllers with banks of many hundred GPIO.  Accommodating those will
take an amount of bit-fu.

Anyway, if anyone out there has the patience to stick around until a
solution is correct we'll get something useful for all I'm sure.

	--Ben.