Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 19 Aug 2012 18:02:12 -0600
From:      Ian Lepore <freebsd@damnhippie.dyndns.org>
To:        Warner Losh <imp@bsdimp.com>
Cc:        Tim Kientzle <tim@kientzle.com>, freebsd-arm@freebsd.org, gonzo@freebsd.org
Subject:   Re: gpiobus_hinted_child >32 pins support, pin_getname method, and gpio-sysctl bridge patch
Message-ID:  <1345420932.27688.298.camel@revolution.hippie.lan>
In-Reply-To: <974EEF9B-08C2-4876-9223-48DD4ABDFC99@bsdimp.com>
References:  <20120819.171723.523519054460575158.hrs@allbsd.org> <8CDAB51C-14A0-42F0-8E16-43A3EABA2703@bsdimp.com> <E7C5ED5C-7120-4B69-9146-D9CC7A8E14C2@kientzle.com> <7E6C76BE-1D3F-40E4-BFE3-DC88715C234C@bsdimp.com> <12A967D8-BC49-49AF-BBD9-40E259932617@kientzle.com> <974EEF9B-08C2-4876-9223-48DD4ABDFC99@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2012-08-19 at 17:42 -0600, Warner Losh wrote:
> On Aug 19, 2012, at 5:04 PM, Tim Kientzle wrote:
> 
> > On Aug 19, 2012, at 10:02 AM, Warner Losh wrote:
> >> 
> >> On Aug 19, 2012, at 10:03 AM, Tim Kientzle wrote:
> >> 
> >>> On Aug 19, 2012, at 8:38 AM, Warner Losh wrote:
> >>> 
> >>>> 
> >>>> In general, I like this code in the context of the current GPIO framework.  I've been growing dissatisfied with the current GPIO framework, however, and some of my comments reflect that more than any comments about this specific code.
> >>> 
> >>> I noticed that Linux on BeagleBone does not
> >>> simply number all pins as we do.  Pins are identified by
> >>> two numbers:  a unit number and a pin number.
> >> 
> >> Is this in the code, or just in the FTD?  On Atmel, there's a single number from 0 to max-1 with all negative numbers being invalid.  But Atmel doesn't have proper FTD support in Linux just yet (3.5 has a good start, and 3.6 will add the missing pinmux/pinctl stuff).
> > 
> > I'm not exactly sure what you mean.  The Linux DTS file:
> > 
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/arm/boot/dts/am335x-bone.dts
> > 
> > inherits most of the real functionality from
> > 
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/arm/boot/dts/am33xx.dtsi
> > 
> > There are certainly separate entries there for each GPIO module.  I presume (but haven't verified) that the unit number maps directly to a "gpio#" device name.
> 
> There's similar things in the Atmel DTS files, but under the covers the gpio pins map into a uniform space number 0 to 32*N-1, where N is the number of GPIO units.

The possibility exists that there can be sets of gpios managed by
different hardware that's completely unrelated.  For example, you can
have some number of gpio pins on an SoC, then have an iicbus device that
provides a bunch more gpio pins.  I'm not sure whether or not that
confounds the idea of having a big zero-N address space for naming pins.

Another annoying complexity is IRQs associated with pins.  Some pins can
directly generate IRQn on the SoC.  Other pins are grouped together by
device or bank or whatever, such that any change on pins M-N generates
IRQn.  Sharing the IRQ for the latter type between multiple drivers
(each using one or more pins in the shared bank) can be tricky, because
on some hardware, reading the status register that says which pins
changed clears that register.

I have no solutions to offer here, just throwing out a couple things
I've run into in the past couple years.

-- Ian




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1345420932.27688.298.camel>