Date: Sun, 9 Nov 2014 02:42:16 +0100 From: Bernd Walter <ticso@cicely7.cicely.de> To: Ian Lepore <ian@freebsd.org> Cc: arm@freebsd.org, embedded@freebsd.org, Rui Paulo <rpaulo@me.com> Subject: Re: libgpio Message-ID: <20141109014216.GB27422@cicely7.cicely.de> In-Reply-To: <1415421418.1200.278.camel@revolution.hippie.lan> References: <B3B50210-8AE9-411A-84B1-AE6C10494149@me.com> <58908C87-6046-4873-87B1-74995EFA72D1@bsdimp.com> <7B37033A-A7DC-4328-90E0-F33A2A008D68@me.com> <1415421418.1200.278.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 07, 2014 at 09:36:58PM -0700, Ian Lepore wrote: > On Fri, 2014-11-07 at 20:08 -0800, Rui Paulo wrote: > > On Nov 7, 2014, at 07:44, Warner Losh <imp@bsdimp.com> wrote: > > > I generally like it. Here?s some suggestions, though many may be hard given that our gpio interface is a bit weak. > > > > > > First, there?s no way to set multiple pins at the same time. That?s likely a reflection of our GPIO system, I know, but it is a deficiency. Fortunately, most devices can tolerate multiple pins changing at different times before a ?clock? or ?enable? pin forces them to latch their state. > > > > OK; I'll work on an API that does this even if it's just a for loop setting multiple pins to their state. > > > > 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. Same time may be required, but very often writing one after the other is Ok, but the ioctl delay is the problem. > 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). This is fairly simple, but that mask register needs locking. > > > What the heck is g_caps? There?s nothing at all to describe it. Not even an indirection to look at sys/gpio.h > > > > It's what describes the pin: input/output/pullup/etc. I'll add some documentation. I need to write a man page anyway. > > > > > 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? > > > > 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. > > > > 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". Currently I'm facing a different problem. I would just write a kernel driver, but I only know how to do it with boot time configured device.hints. This won't work dynamically and I'm still lost with FDT stuff. I already did kernel drivers and have problems with this. Thinking of all the Raspi-class devices and addon boards popular with all the hobby people there should be something easy to help them. To test a big APA102C LED arrays (784 LEDs SPI) I did userland GPIO based SPI, but with the large array 784 LEDs) it took too long to update the whole array. I did this because we don't have userland SPI HW support and I wanted a quick test result, so yes in that case the correct answer would be to use the hardware SPI, but there are many other usecases. I'm not saying that userland gpio needs support for every possible use case, but we should have some handbook examples for all the hobby hardware people. I have some LogiPI and LogiBone FPGA addon for BeagleBone and Raspberry. Bought them to support their idea on kickstarter, not because I had a given usecase. On the Beagle and Raspbery you need to bitbang the FPGA data, which could take some time if done from userland. Their examples assume to access FPGA registers by SPI, or in case of the Beagle it's also possible via memory mapping. The SPI case would easily work from userland once we have that support, but the much faster memory mapping on the Beaglebone needs more. Userland support for more efficient GPIO is quite nice, but to support all those people we really should have some hello world kernel samples. Note too myself: I should setup a webpage with the AP102C LED testcode. -- B.Walter <bernd@bwct.de> http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141109014216.GB27422>