libgpio

[Ian Lepore]

On Fri, 2014-11-07 at 08:33 -0800, Adrian Chadd wrote:
> Hi,
> 
> Yes, it'd be nice to (later) add an API call that takes multiple pin
> updates (and reads multiple pin updates.) That way higher speed, time
> critical stuff can be done for drivers that grow this feature and can
> do batched/timestamped GPIO events.
> 
> 
> 
> -adrian
> 

mixed bottom/top posting.  grrrr.  comments below, where they belong.

> 
> On 7 November 2014 07:44, Warner Losh <imp at bsdimp.com> wrote:
> >
> > On Nov 6, 2014, at 11:41 PM, Rui Paulo <rpaulo at me.com> wrote:
> >
> >> Hi,
> >>
> >> Some time ago, I wrote a gpio library as a way to interact with the kernel gpio driver in a more sensible way (hiding the details of opening a /dev file, handling all the ioctls, etc.).
> >>
> >> Here's the project code:
> >>
> >>       https://bitbucket.org/rpaulo/libgpio/src
> >>
> >> Here's the header file:
> >>
> >>       https://bitbucket.org/rpaulo/libgpio/src/1dfe793d0b0cd6caff2e196cf667a5c06bbade8d/libgpio.h?at=default
> >>
> >> It looks like some people started using the library and I was wondering if it would be a good candidate for the base system.  I would rewrite gpioctl to use it and I'm open to changing the library API.
> >>
> >> Any comments?
> >
> > I generally like it. Here’s some suggestions, though many may be hard given that our gpio interface is a bit weak.
> >
> > First, there’s no way to set multiple pins at the same time. That’s likely a reflection of our GPIO system, I know, but it is a deficiency. Fortunately, most devices can tolerate multiple pins changing at different times before a ‘clock’ or ‘enable’ pin forces them to latch their state.
> >
> > What the heck is g_caps? There’s nothing at all to describe it. Not even an indirection to look at sys/gpio.h
> >
> > For systems that have multiple GPIO devices (some have a few hundred I/O lines that can be addressed), how
> > do you handle that? Do you just kinda have to know these details?
> >
> > There’s no facilities for interrupts (usually you’d like to say “wait for this line to change and let me know”). I know that the Atmel gpio stuff did this, but I don’t think that made it into the generalization that was later done.
> >
> > I’m not sure that I like the gpio_pin_* helper functions causing the thing to change, rather than operating on a gpio_config_t. But since you don’t normally change a bunch at a time, that’s not so bad.
> >
> > Finally a question: What does Linux do here? Is there a standard interface that we could use to leverage off applications written for Linux? Perhaps beyond the scope of what you’re trying to do, but any discussion about pushing things into the base should ask the question “Is this the right, most useful interface?”
> >
> > Warner


Multiple-pin read/write is really required for anything other than
trivial "turn on this led" type stuff.  A restriction that all the pins
have to be on the same /dev/gpiocN device is fine.

Routines to do simple bit-banging (so that multiple bits can be banged
out with a single call) are also good to have.  It's good for a driver
to support an api for that at the lowest level to get reasonable speed
for things like programming an fpga.  (The at91 gpio drivers do this
now.)

-- Ian