From owner-freebsd-embedded@FreeBSD.ORG Fri Nov 27 21:31:39 2009 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EA1B1065679 for ; Fri, 27 Nov 2009 21:31:39 +0000 (UTC) (envelope-from marc@msys.ch) Received: from sleipnir.msys.ch (unknown [IPv6:2001:4060:c0de:f000::3]) by mx1.freebsd.org (Postfix) with ESMTP id 14CEB8FC19 for ; Fri, 27 Nov 2009 21:31:38 +0000 (UTC) Received: from mail.msys.ch (smtp.msys.ch [157.161.101.10]) by sleipnir.msys.ch (8.14.3/8.14.1) with ESMTP id nARLUts4008182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Nov 2009 22:30:56 +0100 (CET) Received: from PowerBook-G4.local (gw.vnode.ch [62.12.170.129]) (authenticated bits=0) by mail.msys.ch (8.14.3/8.14.1) with ESMTP id nARLUthd008149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Nov 2009 22:30:55 +0100 (CET) Message-ID: <4B10450F.4020004@msys.ch> Date: Fri, 27 Nov 2009 22:30:55 +0100 From: Marc Balmer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Oleksandr Tymoshenko References: <20091127204603.GA81260@bluezbox.com> In-Reply-To: <20091127204603.GA81260@bluezbox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL Cc: embedded@freebsd.org Subject: Re: [gonzo@freebsd.org: [RFC] GPIO framework] X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 21:31:39 -0000 Oleksandr Tymoshenko schrieb: > Forwarding RFC to embedded@ because there was typo in Cc address in > the original message :( > > ----- Forwarded message from Oleksandr Tymoshenko ----- > > Date: Thu, 26 Nov 2009 06:57:36 +0200 > From: Oleksandr Tymoshenko > 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