From owner-freebsd-embedded@FreeBSD.ORG Mon Nov 23 11:06:51 2009 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D1541065695 for ; Mon, 23 Nov 2009 11:06:51 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 39CA58FC23 for ; Mon, 23 Nov 2009 11:06:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nANB6pwc070084 for ; Mon, 23 Nov 2009 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nANB6oB2070082 for freebsd-embedded@FreeBSD.org; Mon, 23 Nov 2009 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 Nov 2009 11:06:50 GMT Message-Id: <200911231106.nANB6oB2070082@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-embedded@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org 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: Mon, 23 Nov 2009 11:06:51 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o misc/136889 embedded [nanobsd] [path] nanobsd error reporting and other ref o misc/135588 embedded [nanobsd] simple patch for adding amd64 support o misc/52256 embedded [picobsd] picobsd build script does not read in user/s o kern/42728 embedded [picobsd] many problems in src/usr.sbin/ppp/* after c 4 problems total. From owner-freebsd-embedded@FreeBSD.ORG Fri Nov 27 21:21:37 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 16396106566B for ; Fri, 27 Nov 2009 21:21:37 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from expo.ukrweb.net (mail.univua.net [91.202.128.78]) by mx1.freebsd.org (Postfix) with ESMTP id C9E398FC16 for ; Fri, 27 Nov 2009 21:21:36 +0000 (UTC) Received: from gonzo by expo.ukrweb.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NE7hc-000LAZ-10 for embedded@freebsd.org; Fri, 27 Nov 2009 22:46:04 +0200 Date: Fri, 27 Nov 2009 22:46:03 +0200 From: Oleksandr Tymoshenko To: embedded@freebsd.org Message-ID: <20091127204603.GA81260@bluezbox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD/7.0-STABLE (i386) User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: [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:21:37 -0000 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. 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 -- gonzo _______________________________________________ freebsd-arch@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" ----- End forwarded message ----- -- gonzo 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 From owner-freebsd-embedded@FreeBSD.ORG Sat Nov 28 00:03:42 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 E1EDB106566B for ; Sat, 28 Nov 2009 00:03:41 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from expo.ukrweb.net (mail.univua.net [91.202.128.78]) by mx1.freebsd.org (Postfix) with ESMTP id 97D4E8FC15 for ; Sat, 28 Nov 2009 00:03:41 +0000 (UTC) Received: from [76.77.86.2] (helo=[10.80.5.136]) by expo.ukrweb.net with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NEAmp-000O3y-S4; Sat, 28 Nov 2009 02:03:42 +0200 Message-ID: <4B1068AE.9020806@bluezbox.com> Date: Fri, 27 Nov 2009 16:02:54 -0800 From: Oleksandr Tymoshenko User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Marc Balmer References: <20091127204603.GA81260@bluezbox.com> <4B10450F.4020004@msys.ch> In-Reply-To: <4B10450F.4020004@msys.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Level: ---- X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list Cc: arch@freebsd.org, 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: Sat, 28 Nov 2009 00:03:42 -0000 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 >> ----- >> >> 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? 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.