Date: Fri, 27 Nov 2009 16:02:54 -0800 From: Oleksandr Tymoshenko <gonzo@bluezbox.com> To: Marc Balmer <marc@msys.ch> Cc: arch@freebsd.org, embedded@freebsd.org Subject: Re: [gonzo@freebsd.org: [RFC] GPIO framework] Message-ID: <4B1068AE.9020806@bluezbox.com> In-Reply-To: <4B10450F.4020004@msys.ch> References: <20091127204603.GA81260@bluezbox.com> <4B10450F.4020004@msys.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org> >> ----- >> >> Date: Thu, 26 Nov 2009 06:57:36 +0200 >> From: Oleksandr Tymoshenko <gonzo@freebsd.org> >> To: arch@freebsd.org >> Cc: embedded@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B1068AE.9020806>