Date: Fri, 27 Nov 2009 22:30:55 +0100 From: Marc Balmer <marc@msys.ch> To: Oleksandr Tymoshenko <gonzo@bluezbox.com> Cc: embedded@freebsd.org Subject: Re: [gonzo@freebsd.org: [RFC] GPIO framework] Message-ID: <4B10450F.4020004@msys.ch> In-Reply-To: <20091127204603.GA81260@bluezbox.com> References: <20091127204603.GA81260@bluezbox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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? > > 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. > > Architecture: > > I tried to separate hardware implementation from logic as much as > possible. All the HW-independent stuff resides in sys/dev/gpio > directory. It consists of gpioc (GPIO controller device), > gpiobus (bus that manages devices attached to GPIO controller) > and gpioled (implementation of LED driver that illustrates usage > pattern of gpiobus, utilizes led(4) interface). > > HW-dependent part might be a part of SoC, I2C extender, whatever. > It should implement interface defined in sys/dev/gpio/gpio_if.m: > gpio_pin_max - get maximum pin available > gpio_pin_getcaps - get capabilities for given pin > gpio_pin_getflags - get flags for given pin > gpio_pin_setflags - set flags for given pin > gpio_pin_getname - get pin name (if any) > gpio_pin_set - set pin value > gpio_pin_get - get pin value > gpio_pin_toggle - toggle(invert) pin value > And on attaching HW driver should add gpioc and gpiobus as its > children. > > gpioc creates /dev/gpiocX entry that is used by gpioctl application > for managing GPIO pins using following ioctls: > GPIOMAXPIN - get maximum pin available > GPIOGETCONFIG - get flags/capabilities/name for given pin > GPIOSETCONFIG - set flags for given pin > GPIOGET - get pin value > GPIOSET - set pin value > GPIOTOGGLE - toggle(invert) pin value > gpioctl usage: > gpioctl -f ctldev -l [-v] > gpioctl -f ctldev -t pin > gpioctl -f ctldev -c pin flag ... > gpioctl -f ctldev pin [0|1] > > gpiobus manages devices attached to gpio controller. Its interface > is a subset of of gpio_if.m interface and allows child devices talk > to GPIO controller. At the moment children could be set only by hints > file and pin space is limited to 32. Example: > > # RF led > hint.gpioled.0.at="gpiobus0" > hint.gpioled.0.name="rf" > # pin 2 > hint.gpioled.0.pins=0x0004 > > Interface functions: > gpiobus_pin_getcaps - get capabilities for given pin > gpiobus_pin_getflags - get flags for given pin > gpiobus_pin_setflags - set flags for given pin > gpiobus_pin_set - set pin value > gpiobus_pin_get - get pin value > gpiobus_pin_toggle - toggle(invert) pin value > > 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. your gpioctl command line syntax is not nice. I suggest you take a closer look at gpio in NetBSD and that we work together on this. My offer stands. - Marc
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B10450F.4020004>