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:
next prev parent 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).