From owner-freebsd-arm@FreeBSD.ORG Mon Aug 20 02:07:36 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 BCFD51065672 for ; Mon, 20 Aug 2012 02:07:36 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 69B8D8FC15 for ; Mon, 20 Aug 2012 02:07:36 +0000 (UTC) Received: by yenl7 with SMTP id l7so5866857yen.13 for ; Sun, 19 Aug 2012 19:07:30 -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=4zX/Eor9R4TxZzysoGYI0jawIe9/Q3VnIef8DsUaVuo=; b=TE9uFnH7dxh+ckySjRE5nxzpXwDyq6WPvtkGETIALjk8w+GoqkS0HtTCTSNsAA8qfo Km6bdWOi+toZyZ/KIVYJ8ACHDXTvP06xWiAugaNTNLt+BWgZ8uIPQWfjD+g1xBKHiPoe VMEIRoJ6KCsagPShbhdIdOVm31gl+SeYiboxFkH4MTwa1eHwzysvAxQHTMkzY2V7peGX xuzPf6YxjdrLcYstXHIjJg0KV2T7QD2TU3+Qv6EWB4Big6C5/OLMsl6hknLhTf+HU9Ua ZIDJbAdl9fkAg7SNxye8u7AXPv/ZbDEZ8Ewlh0zkK2NNFCiqK/BAFVYQnkmturlX5C7K at3Q== Received: by 10.50.182.162 with SMTP id ef2mr8300699igc.43.1345428449591; Sun, 19 Aug 2012 19:07:29 -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 ud8sm23075730igb.4.2012.08.19.19.07.28 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 19 Aug 2012 19:07:28 -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: <1345420932.27688.298.camel@revolution.hippie.lan> Date: Sun, 19 Aug 2012 20:07:27 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <1345420932.27688.298.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkTLbV7W3lm9C7lzL6MRw4aq1Q5G9SyaGkEafUd1F1SARLkmtwM+pNb2O9D9DWu2CtttoRK 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 02:07:36 -0000 On Aug 19, 2012, at 6:02 PM, Ian Lepore wrote: > On Sun, 2012-08-19 at 17:42 -0600, Warner Losh wrote: >> 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 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. Not really. Like interrupts, they can come from many different sources. = Yet, IRQs are well ordered. Each platform defines how they are = numbered differently, and I wasn't suggesting that the Atmel mapping = would be universal. The mapping is just a by the way this is one way it = is done, not this is the only, or best, way to do it everywhere. > 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. It is no trickier than sharing it back in the at-pic days. > I have no solutions to offer here, just throwing out a couple things > I've run into in the past couple years. Understood.=