From owner-freebsd-arm@FreeBSD.ORG Sat Nov 8 04:37:03 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55F3258B; Sat, 8 Nov 2014 04:37:03 +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 15D9EC7D; Sat, 8 Nov 2014 04:37:02 +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 1Xmxlk-0003fD-QQ; Sat, 08 Nov 2014 04:37:01 +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 sA84axMh002540; Fri, 7 Nov 2014 21:36:59 -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: U2FsdGVkX185YLfL3hOH80v5go8QAP1I 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: Rui Paulo In-Reply-To: <7B37033A-A7DC-4328-90E0-F33A2A008D68@me.com> References: <58908C87-6046-4873-87B1-74995EFA72D1@bsdimp.com> <7B37033A-A7DC-4328-90E0-F33A2A008D68@me.com> Content-Type: text/plain; charset="windows-1251" Date: Fri, 07 Nov 2014 21:36:58 -0700 Message-ID: <1415421418.1200.278.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 sA84axMh002540 Cc: arm@freebsd.org, embedded@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 04:37:03 -0000 On Fri, 2014-11-07 at 20:08 -0800, Rui Paulo wrote: > On Nov 7, 2014, at 07:44, Warner Losh wrote: > > I generally like it. Here=92s some suggestions, though many may be ha= rd given that our gpio interface is a bit weak. > >=20 > > 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. >=20 > OK; I'll work on an API that does this even if it's just a for loop se= tting multiple pins to their state. >=20 A loop would default the purpose of the feature. Sometimes you need to create a bus out of a collection of pins, and it only works if you can manipulate the pin states atomically as a group. If the underlying device doesn't support it, then you wouldn't be trying to do it in the first place. The current at91 gpio interface supports this in a fairly simple way, but not a way that would necessarily map to every device (it assumes 32 pins per /dev/gpiocN for example). > > What the heck is g_caps? There=92s nothing at all to describe it. Not= even an indirection to look at sys/gpio.h >=20 > It's what describes the pin: input/output/pullup/etc. I'll add some do= cumentation. I need to write a man page anyway. >=20 > > 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? >=20 > Right now you have to work with each individually. We could change it = so that it opens all gpio devices and provides a structure that includes = all pins. >=20 That's probably not a good idea, because gpio devices can come and go. For example, at work we have hot-pluggable expansion cards with an i2c bus that runs to each expansion slot, and there are i2c devices that provide gpio. FTDI usb<->serial chips also provide gpio pins and can come and go. I think userland software working with gpios is generally purpose- specific and targeted at a particular piece of hardware, and just knows what device and pin numbers to work with, as opposed to knowing some abstraction like "pin 147". -- Ian > > 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. >=20 > There's no kernel support for it, but the library could create a thread= to poll the pin to see if it has changed. It's wasteful, but I don't se= e any better way until we have GPIO interrupts. >=20 > > 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. >=20 > I just added those to make it easy to configure pins in one shot. >=20 > > 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 >=20 > That was correctly answered by Johny. >=20 > -- > Rui Paulo >=20 >=20 >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20