From owner-freebsd-arch@FreeBSD.ORG Sat Nov 28 00:21:37 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0128310656A4 for ; Sat, 28 Nov 2009 00: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 95CE08FC14 for ; Sat, 28 Nov 2009 00:21:36 +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 Cc: arch@freebsd.org, embedded@freebsd.org Subject: Re: [gonzo@freebsd.org: [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: Sat, 28 Nov 2009 00:21:37 -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.