From patchwork Mon May 30 19:20:39 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Grant Likely X-Patchwork-Id: 830822 Received: from bombadil.infradead.org (173-166-109-252-newengland.hfc.comcastbusiness.net [173.166.109.252]) by demeter2.kernel.org (8.14.4/8.14.3) with ESMTP id p4UJUsID006911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 May 2011 19:31:24 GMT Received: from canuck.infradead.org ([2001:4978:20e::1]) by bombadil.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1QR81X-0000zZ-Gl; Mon, 30 May 2011 19:21:11 +0000 Received: from localhost ([127.0.0.1] helo=canuck.infradead.org) by canuck.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1QR81V-000374-36; Mon, 30 May 2011 19:21:09 +0000 Received: from mail-pw0-f49.google.com ([209.85.160.49]) by canuck.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1QR81N-00036l-V5 for linux-arm-kernel@lists.infradead.org; Mon, 30 May 2011 19:21:03 +0000 Received: by pwi8 with SMTP id 8so2103086pwi.36 for ; Mon, 30 May 2011 12:20:59 -0700 (PDT) Received: by 10.68.7.198 with SMTP id l6mr2139896pba.162.1306783259051; Mon, 30 May 2011 12:20:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.40.231 with HTTP; Mon, 30 May 2011 12:20:39 -0700 (PDT) In-Reply-To: <8d2515b13c817cc956b185d043bcef00@kernel.crashing.org> References: <20110527205444.21000.90209.stgit@riker> <20110527205721.21000.78599.stgit@riker> <20110528012427.GB5971@opensource.wolfsonmicro.com> <20110530033826.GE4130@opensource.wolfsonmicro.com> <20110530061155.GC23517@ponder.secretlab.ca> <4DE336A1.5040509@firmworks.com> <20110530070138.GA5036@opensource.wolfsonmicro.com> <8d2515b13c817cc956b185d043bcef00@kernel.crashing.org> From: Grant Likely Date: Mon, 30 May 2011 13:20:39 -0600 X-Google-Sender-Auth: XVgbT9cRODsoy5hcESZyyrAU0mY Message-ID: Subject: Re: [RFC 2/2] ARM:Tegra: Device Tree Support: Initialize audio card gpio's from the device tree. To: Segher Boessenkool X-CRM114-Version: 20090807-BlameThorstenAndJenny ( TRE 0.7.6 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20110530_152102_414414_E4516B3A X-CRM114-Status: GOOD ( 21.76 ) X-Spam-Score: -0.7 (/) X-Spam-Report: SpamAssassin version 3.3.1 on canuck.infradead.org summary: Content analysis details: (-0.7 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.160.49 listed in list.dnswl.org] Cc: "devicetree-discuss@lists.ozlabs.org" , Mark Brown , Mitch Bradley , "linux-tegra@vger.kernel.org" , Olof Johansson , linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter2.kernel.org [140.211.167.43]); Mon, 30 May 2011 19:31:24 +0000 (UTC) X-MIME-Autoconverted: from quoted-printable to 8bit by demeter2.kernel.org id p4UJUsID006911 On Mon, May 30, 2011 at 12:54 PM, Segher Boessenkool wrote: >>> I'm currently dealing with an SoC that has over a hundred GPIOs. >>> Whatever we choose, I think it should be able to handle an insane >>> number of GPIOs without getting any more cumbersome that is >>> necessary. >> >> This is *consumer* side GPIOs, not bindings for the device providing the >> GPIOs.  If a single device needs to use hundreds of GPIOs I'd expect >> many of them will be block functions so you'd have a binding with an >> array for things like "databus" and "addrbus". > > But please name them like "databus-gpio", so that it is obvious what it > is.  Also have to think about how this will work with multiple GPIO > controllers: do you require the GPIO controller node to be part of every > GPIO description, or do you do some "gpio-parent" scheme as well, how > does that interact with not having a single array of GPIOs? > > Better write this down as a binding, before committing to it :-) Here's my thinking: Exactly the same binding for "gpios" as is now, except can use different property names, like "chipsel-gpios" or "wp-gpio". Here is a draft patch to the binding: diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt index edaa84d..21dd4f9 100644 --- a/Documentation/devicetree/bindings/gpio/gpio.txt +++ b/Documentation/devicetree/bindings/gpio/gpio.txt @@ -4,17 +4,45 @@ Specifying GPIO information for devices 1) gpios property ----------------- -Nodes that makes use of GPIOs should define them using `gpios' property, -format of which is: <&gpio-controller1-phandle gpio1-specifier - &gpio-controller2-phandle gpio2-specifier - 0 /* holes are permitted, means no GPIO 3 */ - &gpio-controller4-phandle gpio4-specifier - ...>; +Nodes that makes use of GPIOs should specify them using one or more +properties, each containing a 'gpio-list': -Note that gpio-specifier length is controller dependent. + gpio-list ::= [gpio-list] + single-gpio ::= + gpio-phandle : phandle to gpio controller node + gpio-specifier : Array of #gpio-cells specifying specific gpio + (controller specific) + +GPIO properties should be named either "gpios" or "*-gpio". Exact +meaning of each gpio property must be documented in the device tree +binding for each device. + +For example, the following could be used to describe gpios pins to use +as chip select lines; with chip selects 0, 1 and 3 populated, and chip +select 2 left empty: + + gpio1: gpio1 { + gpio-controller + #gpio-cells = <2>; + }; + gpio2: gpio2 { + gpio-controller + #gpio-cells = <1>; + }; + [...] + chipsel-gpio = <&gpio1 12 0>, + <&gpio1 13 0>, + <0>, /* holes are permitted, means no GPIO 2 */ + <&gpio2 2>; + +Note that gpio-specifier length is controller dependent. In the +above example, &gpio1 uses 2 cells to specify a gpio, while &gpio2 +only uses one. gpio-specifier may encode: bank, pin position inside the bank, whether pin is open-drain and whether pin is logically inverted. +Exact meaning of each specifier cell is controller specific, and must +be documented in the device tree binding for the device. Example of the node using GPIOs: @@ -28,8 +56,8 @@ and empty GPIO flags as accepted by the "qe_pio_e" gpio-controller. 2) gpio-controller nodes ------------------------ -Every GPIO controller node must have #gpio-cells property defined, -this information will be used to translate gpio-specifiers. +Every GPIO controller node must both an empty "gpio-controller" +property, and have #gpio-cells contain the size of the gpio-specifier. Example of two SOC GPIO banks defined as gpio-controller nodes: