linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: grant.likely@secretlab.ca (Grant Likely)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 2/2] ARM:Tegra: Device Tree Support: Initialize audio card gpio's from the device tree.
Date: Mon, 30 May 2011 13:20:39 -0600	[thread overview]
Message-ID: <BANLkTi=hkScxYpt449CQCky+bLU3UvkC_A@mail.gmail.com> (raw)
In-Reply-To: <8d2515b13c817cc956b185d043bcef00@kernel.crashing.org>

On Mon, May 30, 2011 at 12:54 PM, Segher Boessenkool
<segher@kernel.crashing.org> 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 ::= <single-gpio> [gpio-list]
+	single-gpio ::= <gpio-phandle> <gpio-specifier>
+	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:

  reply	other threads:[~2011-05-30 19:20 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-27 20:56 [RFC 0/2] ARM: Tegra: Device Tree: Audio John Bonesio
     [not found] ` <20110527205721.21000.78599.stgit@riker>
2011-05-27 21:06   ` [RFC 2/2] ARM:Tegra: Device Tree Support: Initialize audio card gpio's from the device tree Grant Likely
2011-05-28  1:24   ` Mark Brown
2011-05-30  3:11     ` Olof Johansson
2011-05-30  3:38       ` Mark Brown
2011-05-30  6:11         ` Grant Likely
2011-05-30  6:18           ` Mitch Bradley
2011-05-30  6:22             ` Grant Likely
2011-05-30  7:01             ` Mark Brown
2011-05-30 16:22               ` Grant Likely
2011-05-30 18:54               ` Segher Boessenkool
2011-05-30 19:20                 ` Grant Likely [this message]
2011-05-30 20:53                   ` Mitch Bradley
2011-05-31 17:55                     ` Stephen Warren
2011-05-31 18:42                       ` Mitch Bradley
2011-06-01 15:59                         ` Stephen Warren
2011-06-01 16:18                           ` Mark Brown
2011-06-02 15:40                             ` Grant Likely
2011-06-01 21:32                           ` Mitch Bradley
2011-06-03 21:24                             ` Stephen Warren
2011-06-04  0:25                               ` Mitch Bradley
2011-06-02 14:59                       ` Grant Likely
2011-06-02 15:40                     ` Grant Likely
2011-06-28 21:39                   ` Grant Likely
2011-05-30 23:27               ` Benjamin Herrenschmidt
2011-05-30 23:49                 ` Olof Johansson
2011-05-31  0:58                   ` Segher Boessenkool
2011-05-31 10:24                   ` Mark Brown
2011-05-30  7:10           ` Mark Brown
2011-05-30 23:26           ` Benjamin Herrenschmidt
2011-05-31 10:03             ` Mark Brown
     [not found] ` <20110527205706.21000.34832.stgit@riker>
2011-05-27 21:05   ` [RFC 1/2] ARM:Tegra: Device Tree Support: Initialize the audio card " Grant Likely
2011-05-28  1:28   ` Mark Brown
2011-06-01  7:07   ` Barry Song
2011-06-01 16:47     ` Grant Likely
2011-06-02  9:07       ` Barry Song
2011-06-02 16:04         ` Grant Likely
2011-06-02 16:21           ` Barry Song
2011-06-02 21:43             ` Russell King - ARM Linux
2011-06-03  2:32               ` Barry Song
2011-06-03  6:20                 ` Russell King - ARM Linux
2011-06-02 21:36           ` Russell King - ARM Linux
2011-06-03  1:19             ` Barry Song
2011-06-07  3:44               ` Barry Song
2011-06-14 15:42             ` Grant Likely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='BANLkTi=hkScxYpt449CQCky+bLU3UvkC_A@mail.gmail.com' \
    --to=grant.likely@secretlab.ca \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).