From owner-freebsd-arch@FreeBSD.ORG Thu Nov 26 09:16:42 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 793631065679; Thu, 26 Nov 2009 09:16:42 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.swip.net [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id AD0198FC13; Thu, 26 Nov 2009 09:16:41 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=6I5d2MoRAAAA:8 a=HegQLxz4BK_eN1qGPMUA:9 a=qedAMZySXq26Xl73EcrYT6v6cbcA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe11.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1169560490; Thu, 26 Nov 2009 09:16:37 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Thu, 26 Nov 2009 09:18:14 +0100 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <20091126045736.GA25431@bluezbox.com> In-Reply-To: <20091126045736.GA25431@bluezbox.com> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911260918.15169.hselasky@c2i.net> Cc: Oleksandr Tymoshenko , embedded@frebsd.org Subject: Re: [RFC] GPIO framework X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 09:16:42 -0000 On Thursday 26 November 2009 05:57:36 Oleksandr Tymoshenko wrote: > 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. > > 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. > > 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 Are there any functions to setup interrupts on GPIO pins? --HPS