libgpio

[Luiz Otavio O Souza]

On 8 November 2014 02:08, Rui Paulo wrote:
> On Nov 7, 2014, at 07:44, Warner Losh 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.

We can support this at kernel.  Most of gpio controllers provides
direct access to the state of a group of pins usually accessed as
'banks' (generally 32 bits/pins wide, but it is not unusual smaller
sizes - 8 bits on i2c expanders).

We should add the support to do the direct read and write to these banks.

This is a task already in the GPIO TODO list (at
https://wiki.freebsd.org/FreeBSD/GPIO).

>
>> 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.
>
>> 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.

The proper implementation for this will only happen when (arm/)intrng
is complete.  But i think i'll commit what i have for now, which can
only work for direct gpio childs (and soon userland), but it is better
than what we have today.

>
>> 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.

Well... For RPi, they teach how to access and program the GPIO
controller via mapped memory
(http://elinux.org/RPi_Low-level_peripherals#C).

There are many libraries implementing GPIO stuff this way (with the
arduino API for example). But then, everything is mostly polled (they
are possibly intended for hobby stuff).

Rui, as for libgpio, please go for it.

Luiz