[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