Messages in this thread | | | Subject | Re: GPIOLIB, GPIO_SYS and port-wide accesses | From | Ben Nizette <> | Date | Fri, 14 Aug 2009 18:11:52 +1000 |
| |
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.
| |