From owner-freebsd-arm@FreeBSD.ORG Mon Aug 20 00:45:31 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 CB91F106564A; Mon, 20 Aug 2012 00:45:31 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 863E38FC14; Mon, 20 Aug 2012 00:45:31 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q7K0jSsH046634; Mon, 20 Aug 2012 00:45:28 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id zemfivjb2zbi45bkh4st5vmrds; Mon, 20 Aug 2012 00:45:28 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <974EEF9B-08C2-4876-9223-48DD4ABDFC99@bsdimp.com> Date: Sun, 19 Aug 2012 17:45:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1501020F-38C8-44E9-82B3-64DF1090A983@kientzle.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> To: Warner Losh X-Mailer: Apple Mail (2.1278) Cc: gonzo@freebsd.org, freebsd-arm@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:45:31 -0000 On Aug 19, 2012, at 4:42 PM, Warner Losh wrote: >=20 > On Aug 19, 2012, at 5:04 PM, Tim Kientzle wrote: >=20 >> On Aug 19, 2012, at 10:02 AM, Warner Losh wrote: >>>=20 >>> On Aug 19, 2012, at 10:03 AM, Tim Kientzle wrote: >>>=20 >>>> On Aug 19, 2012, at 8:38 AM, Warner Losh wrote: >>>>=20 >>>>>=20 >>>>> 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. >>>>=20 >>>> 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. >>>=20 >>> 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). >>=20 >> I'm not exactly sure what you mean. The Linux DTS file: >>=20 >> = http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux.git;a=3Dblob;f=3D= arch/arm/boot/dts/am335x-bone.dts >>=20 >> inherits most of the real functionality from >>=20 >> = http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux.git;a=3Dblob;f=3D= arch/arm/boot/dts/am33xx.dtsi >>=20 >> 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. >=20 > 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 "under the covers" part is exactly what bothers me about this. I've been reading documentation that says things like "LED#0 on the board is connected to GPIO#1 pin 13". I'd like to be able to take that to the command line and type in: $ gpio 1 13 on or $ gpio /dev/gpio1 13 on and see LED#0 turn on. Since GPIO is used by a lot of folks interfacing new hardware, this kind of translation between hardware interface and software API needs to be trivial. How would the linear addressing approach handle, for example, hot-plugging of a device that provided a USB interface to a group of GPIO pins? (That is, it plugs into the USB port on the board and provides a GPIO header on the other end. Not vice versa. ;-) Tim