From owner-freebsd-arm@FreeBSD.ORG Mon Aug 20 00:02:21 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7D8C1065679 for ; Mon, 20 Aug 2012 00:02:21 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id 90FE88FC0C for ; Mon, 20 Aug 2012 00:02:21 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta03.emeryville.ca.mail.comcast.net with comcast id ojQX1j0020vp7WLA3o2FXu; Mon, 20 Aug 2012 00:02:15 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta05.emeryville.ca.mail.comcast.net with comcast id oo2E1j00S4NgCEG8Ro2FS3; Mon, 20 Aug 2012 00:02:15 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q7K02Ccx020259; Sun, 19 Aug 2012 18:02:12 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Warner Losh In-Reply-To: <974EEF9B-08C2-4876-9223-48DD4ABDFC99@bsdimp.com> References: <20120819.171723.523519054460575158.hrs@allbsd.org> <8CDAB51C-14A0-42F0-8E16-43A3EABA2703@bsdimp.com> <7E6C76BE-1D3F-40E4-BFE3-DC88715C234C@bsdimp.com> <12A967D8-BC49-49AF-BBD9-40E259932617@kientzle.com> <974EEF9B-08C2-4876-9223-48DD4ABDFC99@bsdimp.com> Content-Type: text/plain; charset="us-ascii" Date: Sun, 19 Aug 2012 18:02:12 -0600 Message-ID: <1345420932.27688.298.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , freebsd-arm@freebsd.org, gonzo@freebsd.org Subject: Re: gpiobus_hinted_child >32 pins support, pin_getname method, and gpio-sysctl bridge patch X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 00:02:21 -0000 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