From owner-freebsd-arm@FreeBSD.ORG Mon Aug 20 02:14:59 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7FE9C106564A for ; Mon, 20 Aug 2012 02:14:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 389818FC12 for ; Mon, 20 Aug 2012 02:14:59 +0000 (UTC) Received: by obbun3 with SMTP id un3so11973463obb.13 for ; Sun, 19 Aug 2012 19:14:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=sJOCFsAv9vJrEix6MiVdLMt4mSq2vBfjDXY4qsaEa6A=; b=PeIVuewpr4ObY6w6/7mlbxjX5d45LeqlK2EX4mDoFlYlpip8MMF9zkXp8TSQpb9rL3 LtCqEuVHlHiPhxlhjZvKZyIF3n0eSQNDRAGO41PU8RhBaFGPZCr4fKOXqv4h9KVljOn3 hEtmaaaORnV3g0O3nmM7Cu9BFoxjjATd+ZIX2PMmSmSwY7HkwBYVivr+aLZlR3UxjgS7 3tmVJ76MMpkP0JmJOwdHWgXTL75f8pe8skABxLVdrCvbiazvh5d0zOxRzODGL7L7eq2U UqOZeUUFld7c9uJPD2Gilz4QDFGXrj67gIvKgNQ+lDhYegqRcOXw6H4z9hkH2Zx84Zkl pdNQ== Received: by 10.50.46.170 with SMTP id w10mr8244498igm.44.1345428898109; Sun, 19 Aug 2012 19:14:58 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id wm7sm23098725igb.6.2012.08.19.19.14.56 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 19 Aug 2012 19:14:57 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1501020F-38C8-44E9-82B3-64DF1090A983@kientzle.com> Date: Sun, 19 Aug 2012 20:14:55 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <284D7D21-D87B-4112-BBDB-17CA0F9A6FDD@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> <1501020F-38C8-44E9-82B3-64DF1090A983@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkIxdhkum349ZLKm6cj/F5mu9TM2UzhvldzY5Px0cI1Pn9xqyW/9L7KLfDpuSVUEViAPlEL 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 02:14:59 -0000 On Aug 19, 2012, at 6:45 PM, Tim Kientzle wrote: >=20 > On Aug 19, 2012, at 4:42 PM, Warner Losh wrote: >=20 >>=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. >=20 > The "under the covers" part is exactly what bothers me > about this. This makes a number of interfaces a simple int, rather than having some = kind of struct. > 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. Yet other documentation says "The LED is connected to PC23" which has no = simple mapping to this stuff. Sure that's gpio2, since that's what = would most likely get PIOC from the chip, but it could just as easily be = 3 since C is the 3rd letter of the alphabet. > 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. Correct. The current mapping we have is insane. We have to have a = base-address of the GPIO hardware, coupled with a mask and pass that = complex thing around, when we could more easily pass around a simple = int. Linux did it this way to make their board files easier to cope = with. I'm not sure how it is exposed outside the kernel, honestly. = Given the trend to FDT, tuples aren't too bad to carry around since you = don't have to contrive them to be in free code as much. > 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. ;-) Each platform would have a fixed set of pins, followed by a dynamically = allocated range for the odd-ball situations like this. For most things, gpio does single bit, and for single bit on one of many = GPIOs units, masks are a pain. But until I have gpioNG going, along with the pinctl and pinmux support = with DTS tie ins, I guess I'm just flapping my yapper, eh? Warner