From owner-freebsd-embedded@FreeBSD.ORG Fri Nov 7 16:57:27 2014 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2799543D; Fri, 7 Nov 2014 16:57:27 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D98DCEEB; Fri, 7 Nov 2014 16:57:26 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Xmmqi-000CSR-Vz; Fri, 07 Nov 2014 16:57:25 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sA7GvNWh001353; Fri, 7 Nov 2014 09:57:23 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+dta4syf2PtEywCHtMdSqy X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: libgpio From: Ian Lepore To: Adrian Chadd In-Reply-To: References: <58908C87-6046-4873-87B1-74995EFA72D1@bsdimp.com> Content-Type: text/plain; charset="windows-1251" Date: Fri, 07 Nov 2014 09:57:23 -0700 Message-ID: <1415379443.1200.215.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id sA7GvNWh001353 Cc: "freebsd-arm@freebsd.org" , "freebsd-embedded@freebsd.org" , Rui Paulo X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 16:57:27 -0000 On Fri, 2014-11-07 at 08:33 -0800, Adrian Chadd wrote: > Hi, >=20 > Yes, it'd be nice to (later) add an API call that takes multiple pin > updates (and reads multiple pin updates.) That way higher speed, time > critical stuff can be done for drivers that grow this feature and can > do batched/timestamped GPIO events. >=20 >=20 >=20 > -adrian >=20 mixed bottom/top posting. grrrr. comments below, where they belong. >=20 > On 7 November 2014 07:44, Warner Losh wrote: > > > > On Nov 6, 2014, at 11:41 PM, Rui Paulo wrote: > > > >> Hi, > >> > >> Some time ago, I wrote a gpio library as a way to interact with the = kernel gpio driver in a more sensible way (hiding the details of opening = a /dev file, handling all the ioctls, etc.). > >> > >> Here's the project code: > >> > >> https://bitbucket.org/rpaulo/libgpio/src > >> > >> Here's the header file: > >> > >> https://bitbucket.org/rpaulo/libgpio/src/1dfe793d0b0cd6caff2e1= 96cf667a5c06bbade8d/libgpio.h?at=3Ddefault > >> > >> It looks like some people started using the library and I was wonder= ing if it would be a good candidate for the base system. I would rewrite= gpioctl to use it and I'm open to changing the library API. > >> > >> Any comments? > > > > I generally like it. Here=92s some suggestions, though many may be ha= rd given that our gpio interface is a bit weak. > > > > First, there=92s no way to set multiple pins at the same time. That=92= s likely a reflection of our GPIO system, I know, but it is a deficiency.= Fortunately, most devices can tolerate multiple pins changing at differe= nt times before a =91clock=92 or =91enable=92 pin forces them to latch th= eir state. > > > > What the heck is g_caps? There=92s nothing at all to describe it. Not= even an indirection to look at sys/gpio.h > > > > For systems that have multiple GPIO devices (some have a few hundred = I/O lines that can be addressed), how > > do you handle that? Do you just kinda have to know these details? > > > > There=92s no facilities for interrupts (usually you=92d like to say =93= wait for this line to change and let me know=94). I know that the Atmel g= pio stuff did this, but I don=92t think that made it into the generalizat= ion that was later done. > > > > I=92m not sure that I like the gpio_pin_* helper functions causing th= e thing to change, rather than operating on a gpio_config_t. But since yo= u don=92t normally change a bunch at a time, that=92s not so bad. > > > > Finally a question: What does Linux do here? Is there a standard inte= rface that we could use to leverage off applications written for Linux? P= erhaps beyond the scope of what you=92re trying to do, but any discussion= about pushing things into the base should ask the question =93Is this th= e right, most useful interface?=94 > > > > Warner Multiple-pin read/write is really required for anything other than trivial "turn on this led" type stuff. A restriction that all the pins have to be on the same /dev/gpiocN device is fine. Routines to do simple bit-banging (so that multiple bits can be banged out with a single call) are also good to have. It's good for a driver to support an api for that at the lowest level to get reasonable speed for things like programming an fpga. (The at91 gpio drivers do this now.) -- Ian