libgpio

[Ian Lepore]

On Fri, 2014-11-07 at 20:08 -0800, Rui Paulo wrote:
> On Nov 7, 2014, at 07:44, Warner Losh <imp at bsdimp.com> wrote:
> > 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.
> 
> OK;  I'll work on an API that does this even if it's just a for loop setting multiple pins to their state.
> 

A loop would default the purpose of the feature.  Sometimes you need to
create a bus out of a collection of pins, and it only works if you can
manipulate the pin states atomically as a group.  If the underlying
device doesn't support it, then you wouldn't be trying to do it in the
first place.

The current at91 gpio interface supports this in a fairly simple way,
but not a way that would necessarily map to every device (it assumes 32
pins per /dev/gpiocN for example).

> > What the heck is g_caps? There’s nothing at all to describe it. Not even an indirection to look at sys/gpio.h
> 
> It's what describes the pin: input/output/pullup/etc.  I'll add some documentation.  I need to write a man page anyway.
> 
> > 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?
> 
> Right now you have to work with each individually.  We could change it so that it opens all gpio devices and provides a structure that includes all pins.
> 

That's probably not a good idea, because gpio devices can come and go.
For example, at work we have hot-pluggable expansion cards with an i2c
bus that runs to each expansion slot, and there are i2c devices that
provide gpio.  FTDI usb<->serial chips also provide gpio pins and can
come and go.

I think userland software working with gpios is generally purpose-
specific and targeted at a particular piece of hardware, and just knows
what device and pin numbers to work with, as opposed to knowing some
abstraction like "pin 147".

-- Ian

> > 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.
> 
> There's no kernel support for it, but the library could create a thread to poll the pin to see if it has changed.  It's wasteful, but I don't see any better way until we have GPIO interrupts.
> 
> > 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.
> 
> I just added those to make it easy to configure pins in one shot.
> 
> > 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?”
> 
> That was correctly answered by Johny.
> 
> --
> Rui Paulo
> 
> 
> 
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>