All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
To: Segher Boessenkool
	<segher-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Cc: Mark Brown
	<broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>,
	"devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org"
	<devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
	"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>,
	Olof Johansson <olofj-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [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-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>

On Mon, May 30, 2011 at 12:54 PM, Segher Boessenkool
<segher-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.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:

WARNING: multiple messages have this Message-ID (diff)
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:

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

Thread overview: 92+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-27 20:56 [RFC 0/2] ARM: Tegra: Device Tree: Audio John Bonesio
2011-05-27 20:56 ` John Bonesio
2011-05-27 20:57 ` [RFC 1/2] ARM:Tegra: Device Tree Support: Initialize the audio card from the device tree John Bonesio
2011-05-27 21:05   ` Grant Likely
2011-05-27 21:05     ` Grant Likely
2011-05-28  1:28   ` Mark Brown
2011-05-28  1:28     ` Mark Brown
2011-06-01  7:07   ` Barry Song
2011-06-01  7:07     ` Barry Song
     [not found]     ` <BANLkTi=NMjBjWVv_o3PocejhgGr8TdG+1Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-06-01 16:47       ` Grant Likely
2011-06-01 16:47         ` Grant Likely
     [not found]         ` <BANLkTi=PtEhxxmZo2DqvmySCmnEd3LbezQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-06-02  9:07           ` Barry Song
2011-06-02  9:07             ` Barry Song
     [not found]             ` <BANLkTikWpiY_o27OF-Jxvq7iPeWzrAYOsQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-06-02 16:04               ` Grant Likely
2011-06-02 16:04                 ` Grant Likely
     [not found]                 ` <20110602160445.GA8373-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2011-06-02 16:21                   ` Barry Song
2011-06-02 16:21                     ` Barry Song
     [not found]                     ` <BANLkTikGp_O-Wd3nMhbV+-RLeXZoWeB6eQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-06-02 21:43                       ` Russell King - ARM Linux
2011-06-02 21:43                         ` Russell King - ARM Linux
     [not found]                         ` <20110602214322.GC10532-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2011-06-03  2:32                           ` Barry Song
2011-06-03  2:32                             ` Barry Song
     [not found]                             ` <BANLkTikiaA3CCRAXkB=x56wtt8nNF9dqxA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-06-03  6:20                               ` Russell King - ARM Linux
2011-06-03  6:20                                 ` Russell King - ARM Linux
2011-06-02 21:36                   ` Russell King - ARM Linux
2011-06-02 21:36                     ` Russell King - ARM Linux
     [not found]                     ` <20110602213656.GB10532-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2011-06-03  1:19                       ` Barry Song
2011-06-03  1:19                         ` Barry Song
     [not found]                         ` <BANLkTimavC-6oMhAHHsBJ2_Em7aXi7eyNQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-06-07  3:44                           ` Barry Song
2011-06-07  3:44                             ` Barry Song
2011-06-14 15:42                       ` Grant Likely
2011-06-14 15:42                         ` Grant Likely
2011-05-27 20:57 ` [RFC 2/2] ARM:Tegra: Device Tree Support: Initialize audio card gpio's " John Bonesio
2011-05-27 21:06   ` Grant Likely
2011-05-27 21:06     ` Grant Likely
2011-05-28  1:24   ` Mark Brown
2011-05-28  1:24     ` Mark Brown
     [not found]     ` <20110528012427.GB5971-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2011-05-30  3:11       ` Olof Johansson
2011-05-30  3:11         ` Olof Johansson
     [not found]         ` <BANLkTinKLcYmStvBEGDcN84BapJXe5Y5bg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-05-30  3:38           ` Mark Brown
2011-05-30  3:38             ` Mark Brown
     [not found]             ` <20110530033826.GE4130-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2011-05-30  6:11               ` Grant Likely
2011-05-30  6:11                 ` Grant Likely
     [not found]                 ` <20110530061155.GC23517-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2011-05-30  6:18                   ` Mitch Bradley
2011-05-30  6:18                     ` Mitch Bradley
     [not found]                     ` <4DE336A1.5040509-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2011-05-30  6:22                       ` Grant Likely
2011-05-30  6:22                         ` Grant Likely
2011-05-30  7:01                       ` Mark Brown
2011-05-30  7:01                         ` Mark Brown
     [not found]                         ` <20110530070138.GA5036-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2011-05-30 16:22                           ` Grant Likely
2011-05-30 16:22                             ` Grant Likely
2011-05-30 18:54                           ` Segher Boessenkool
2011-05-30 18:54                             ` Segher Boessenkool
     [not found]                             ` <8d2515b13c817cc956b185d043bcef00-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2011-05-30 19:20                               ` Grant Likely [this message]
2011-05-30 19:20                                 ` Grant Likely
     [not found]                                 ` <BANLkTi=hkScxYpt449CQCky+bLU3UvkC_A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-05-30 20:53                                   ` Mitch Bradley
2011-05-30 20:53                                     ` Mitch Bradley
     [not found]                                     ` <4DE403C5.7060003-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2011-05-31 17:55                                       ` Stephen Warren
2011-05-31 17:55                                         ` Stephen Warren
     [not found]                                         ` <74CDBE0F657A3D45AFBB94109FB122FF0498E1C22D-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2011-05-31 18:42                                           ` Mitch Bradley
2011-05-31 18:42                                             ` Mitch Bradley
     [not found]                                             ` <4DE536AD.5080200-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2011-06-01 15:59                                               ` Stephen Warren
2011-06-01 15:59                                                 ` Stephen Warren
     [not found]                                                 ` <74CDBE0F657A3D45AFBB94109FB122FF0498E1C3F5-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2011-06-01 16:18                                                   ` Mark Brown
2011-06-01 16:18                                                     ` Mark Brown
     [not found]                                                     ` <20110601161856.GB15583-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2011-06-02 15:40                                                       ` Grant Likely
2011-06-02 15:40                                                         ` Grant Likely
2011-06-01 21:32                                                   ` Mitch Bradley
2011-06-01 21:32                                                     ` Mitch Bradley
     [not found]                                                     ` <4DE6AFF7.3040905-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2011-06-03 21:24                                                       ` Stephen Warren
2011-06-03 21:24                                                         ` Stephen Warren
     [not found]                                                         ` <74CDBE0F657A3D45AFBB94109FB122FF0498E1C870-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2011-06-04  0:25                                                           ` Mitch Bradley
2011-06-04  0:25                                                             ` Mitch Bradley
2011-06-02 14:59                                           ` Grant Likely
2011-06-02 14:59                                             ` Grant Likely
2011-06-02 15:40                                       ` Grant Likely
2011-06-02 15:40                                         ` Grant Likely
2011-06-28 21:39                                   ` Grant Likely
2011-06-28 21:39                                     ` Grant Likely
2011-05-30 23:27                           ` Benjamin Herrenschmidt
2011-05-30 23:27                             ` Benjamin Herrenschmidt
2011-05-30 23:49                             ` Olof Johansson
2011-05-30 23:49                               ` Olof Johansson
     [not found]                               ` <20110530234909.GA3411-O5ziIzlqnXUVNXGz7ipsyg@public.gmane.org>
2011-05-31  0:58                                 ` Segher Boessenkool
2011-05-31  0:58                                   ` Segher Boessenkool
2011-05-31 10:24                                 ` Mark Brown
2011-05-31 10:24                                   ` Mark Brown
2011-05-30  7:10                   ` Mark Brown
2011-05-30  7:10                     ` Mark Brown
2011-05-30 23:26                   ` Benjamin Herrenschmidt
2011-05-30 23:26                     ` Benjamin Herrenschmidt
2011-05-31 10:03                     ` Mark Brown
2011-05-31 10:03                       ` Mark Brown

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-s3s/wqlpoipyb63q8fvjnq@public.gmane.org \
    --cc=broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=olofj-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
    --cc=segher-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org \
    --cc=wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.