[gonzo@freebsd.org: [RFC] GPIO framework]

Oleksandr Tymoshenko gonzo at bluezbox.com
Sat Nov 28 00:21:37 UTC 2009


Marc Balmer wrote:
> Oleksandr Tymoshenko schrieb:
>> Forwarding RFC to embedded@ because there was typo in Cc address in 
>> the  original message :(
>>
>> ----- Forwarded message from Oleksandr Tymoshenko <gonzo at freebsd.org> 
>> -----
>>
>> Date: Thu, 26 Nov 2009 06:57:36 +0200
>> From: Oleksandr Tymoshenko <gonzo at freebsd.org>
>> To: arch at freebsd.org
>> Cc: embedded at frebsd.org
>> Subject: [RFC] GPIO framework
>> User-Agent: Mutt/1.5.20 (2009-06-14)
>>
>> Recently I've been working on GPIO framework that, I believe, is much 
>> needed for embedded applications of FreeBSD. Now framework
>> is  mature enough to show it to the world, so this is my request for 
>> review.
>>
>> Patch: http://people.freebsd.org/~gonzo/mips/gpio.diff
>> sys/gpio.h is based on the same file from NetBSD but all the other 
>> files have been written from the scratch.
> 
> why that?
Because the hard stuff is hwpart <-> bus <-> devices hierarchy and
their interoperability. For these I wanted to use kobj/newbus API and
it's not available in NetBSD. The rest of the code is relatively
simple.

>> Description:
>>
>> GPIO stands for General Purpose Input/Output. This interface may be
>> thought of as a set of pins which could serve as input or output 
>> having logical 0 and logical 1 as their values (some other options
>> are applicable, but they're not crucial for this explanation).
>> Most common usage of GPIO interface is LED and button control for
>> various SoCs.
> 
> we do much more, since years:  we attach I2C buses over GPIO, or 1-Wire
> buses.  GPIO is not just for LEDs.
     I know, these two were picked as an example.

>> Reference implementation of child device is sys/dev/gpio/gpioled.c
>> It provides on/off function for led(4) API
>>
>> Any comments/feedback are welcome
>>
> 
> it suffers from the same problems my implementation in other BSD 
> suffers:  No interrupt capabilities, no capability to build buses wider 
> than 1 bit.
     Adding interrupts should not be an issue. Child devices setup 
handlers on gpiobus using bus_setup_intr. HW implementation
catches interrupts and reports pins to gpiobus via GPIOBUS_INTR() 
method and then bus dispatches interrupts to child devices. There
might be some hidden pitfalls but I can't tell them from the top of my
head. Some additional info on interrupts/userland interaction here:
http://lists.freebsd.org/pipermail/freebsd-arch/2009-November/009711.html

Could you elaborate on multi-bit buses? I'm not well acquainted
with this area so any examples would help :)

> your gpioctl command line syntax is not nice.
     Why? Since there is no need for complex rule language as in, for
instance, ipfw I decided to use traditional getopt approach.

> I suggest you take a closer look at gpio in NetBSD and that we work 
> together on this.  My offer stands.
     I appreciate your offer but as it was mentioned above the most
vital part is not OS-independent and it makes adopting NetBSD gpio
framework somewhat complicated.

Having ioctl-wise compatibility may turn out useful though. I'll think 
about it.


More information about the freebsd-arch mailing list