From: David Gibson <david@gibson.dropbear.id.au>
To: Mitch Bradley <wmb@firmworks.com>
Cc: devicetree-discuss list <devicetree-discuss@ozlabs.org>,
linuxppc-dev list <linuxppc-dev@ozlabs.org>
Subject: Re: GPIO - marking individual pins (not) available in device tree
Date: Fri, 24 Oct 2008 14:29:44 +1100 [thread overview]
Message-ID: <20081024032944.GE4267@yookeroo.seuss> (raw)
In-Reply-To: <49011C42.2020101@firmworks.com>
On Thu, Oct 23, 2008 at 02:52:18PM -1000, Mitch Bradley wrote:
>>
>>
>> Mitch Bradley wrote:
>> [snip]
>>
>>> You could adopt the convention that preassigned GPIOs must be
>>> represented by subordinate nodes, and any GPIO that is not covered by
>>> a subordinate node's "reg" property is implicitly available. That's
>>> the way it works for other address spaces.
>>
>> I like that idea except for the implicitly available bit.
>>
>> Just summarizing this in my head (also on the list), if we had an
>> "available" property in the node marked as a gpio-controller, that
>> would easily give gpiolib something to parse so that it only gives out
>> allocations for pins that are really, really not being multiplexed for
>> something else or just not being connected.
>>
>> There's a GPIO spec in booting-without-of.txt which basically defines
>> a controller and a bank, and you can assign a bank of GPIO to some
>> other device. Assigning specific GPIO pins should be possible.. umm..
>>
>> http://patchwork.ozlabs.org/patch/5478/
>>
>> With regards to this patch, how about device usage of pins being
>> defined as a range of pins (reusing the standard-ish "ranges" property
>> from PCI binding)?
>
>
> Okay, so it looks to me like your "bank" concept is sort of akin to a
> "gpio-to-gpio bridge", with analogy to a pci-to-pci bridge. Following
> that model, the "name" of your "gpio-bank" would instead be
> "gpio-controller", because its children are GPIO pin nodes that could
> just as well be attached directly to the top-level gpio-controller node.
> The "compatible" property would be different, reflecting the fact that it
> is a "gpio-to-gpio bridge" instead of an "io-to-gpio bridge" (for
> example).
No, no, no, no, no. Making complex multi-level representations of
nested things for gpios is just insanity. Just use the same encoded
format as we already use for gpio descriptors in 'gpios' properties
(which is gpio controller specific, with length defined by
#gpio-cells).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
WARNING: multiple messages have this Message-ID (diff)
From: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
To: Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
Cc: devicetree-discuss list
<devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>,
linuxppc-dev list
<linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>
Subject: Re: GPIO - marking individual pins (not) available in device tree
Date: Fri, 24 Oct 2008 14:29:44 +1100 [thread overview]
Message-ID: <20081024032944.GE4267@yookeroo.seuss> (raw)
In-Reply-To: <49011C42.2020101-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
On Thu, Oct 23, 2008 at 02:52:18PM -1000, Mitch Bradley wrote:
>>
>>
>> Mitch Bradley wrote:
>> [snip]
>>
>>> You could adopt the convention that preassigned GPIOs must be
>>> represented by subordinate nodes, and any GPIO that is not covered by
>>> a subordinate node's "reg" property is implicitly available. That's
>>> the way it works for other address spaces.
>>
>> I like that idea except for the implicitly available bit.
>>
>> Just summarizing this in my head (also on the list), if we had an
>> "available" property in the node marked as a gpio-controller, that
>> would easily give gpiolib something to parse so that it only gives out
>> allocations for pins that are really, really not being multiplexed for
>> something else or just not being connected.
>>
>> There's a GPIO spec in booting-without-of.txt which basically defines
>> a controller and a bank, and you can assign a bank of GPIO to some
>> other device. Assigning specific GPIO pins should be possible.. umm..
>>
>> http://patchwork.ozlabs.org/patch/5478/
>>
>> With regards to this patch, how about device usage of pins being
>> defined as a range of pins (reusing the standard-ish "ranges" property
>> from PCI binding)?
>
>
> Okay, so it looks to me like your "bank" concept is sort of akin to a
> "gpio-to-gpio bridge", with analogy to a pci-to-pci bridge. Following
> that model, the "name" of your "gpio-bank" would instead be
> "gpio-controller", because its children are GPIO pin nodes that could
> just as well be attached directly to the top-level gpio-controller node.
> The "compatible" property would be different, reflecting the fact that it
> is a "gpio-to-gpio bridge" instead of an "io-to-gpio bridge" (for
> example).
No, no, no, no, no. Making complex multi-level representations of
nested things for gpios is just insanity. Just use the same encoded
format as we already use for gpio descriptors in 'gpios' properties
(which is gpio controller specific, with length defined by
#gpio-cells).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
next prev parent reply other threads:[~2008-10-24 3:29 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-23 21:32 GPIO - marking individual pins (not) available in device tree Matt Sealey
2008-10-23 21:32 ` Matt Sealey
2008-10-23 22:22 ` Mitch Bradley
2008-10-23 23:05 ` Matt Sealey
2008-10-24 0:52 ` Mitch Bradley
2008-10-24 3:29 ` David Gibson [this message]
2008-10-24 3:29 ` David Gibson
2008-10-24 4:17 ` Mitch Bradley
2008-10-24 4:17 ` Mitch Bradley
2008-10-24 4:45 ` David Gibson
2008-10-24 4:45 ` David Gibson
2008-10-24 22:14 ` Matt Sealey
2008-10-26 23:47 ` David Gibson
2008-10-27 15:40 ` Matt Sealey
2008-10-27 18:34 ` Anton Vorontsov
2008-10-27 18:56 ` Matt Sealey
2008-10-27 20:10 ` Anton Vorontsov
2008-10-27 20:10 ` Anton Vorontsov
2008-10-27 21:56 ` Matt Sealey
2008-10-27 21:56 ` Matt Sealey
2008-10-27 23:12 ` Anton Vorontsov
2008-10-27 23:12 ` Anton Vorontsov
2008-10-27 23:40 ` Anton Vorontsov
2008-10-28 0:47 ` Matt Sealey
2008-10-28 1:11 ` Matt Sealey
2008-10-28 1:11 ` Matt Sealey
2008-10-28 2:37 ` Anton Vorontsov
2008-10-28 16:53 ` Matt Sealey
2008-10-28 16:53 ` Matt Sealey
2008-10-28 17:39 ` Grant Likely
2008-10-28 19:46 ` Matt Sealey
2008-10-28 19:46 ` Matt Sealey
2008-10-28 0:15 ` David Gibson
2008-10-28 0:15 ` David Gibson
2008-10-28 0:51 ` Matt Sealey
2008-10-28 1:50 ` David Gibson
2008-10-28 5:20 ` Grant Likely
2008-10-28 5:20 ` Grant Likely
2008-10-24 22:03 ` Matt Sealey
2008-10-24 22:20 ` Stephen Neuendorffer
2008-10-24 22:20 ` Stephen Neuendorffer
2008-10-26 21:39 ` Matt Sealey
2008-10-24 23:44 ` Mitch Bradley
2008-10-26 21:13 ` Matt Sealey
2008-10-26 21:13 ` Matt Sealey
2008-10-26 23:53 ` David Gibson
2008-10-27 16:12 ` Matt Sealey
2008-10-27 16:12 ` Matt Sealey
2008-10-27 16:35 ` Scott Wood
2008-10-27 16:35 ` Scott Wood
2008-10-27 17:05 ` Matt Sealey
2008-10-27 17:25 ` Scott Wood
2008-10-27 17:49 ` Matt Sealey
2008-10-27 17:54 ` Scott Wood
2008-10-28 0:38 ` David Gibson
2008-10-28 0:38 ` David Gibson
2008-10-28 0:34 ` David Gibson
2008-10-28 0:34 ` David Gibson
2008-10-24 4:58 ` David Gibson
2008-10-24 3:27 ` David Gibson
2008-10-24 3:27 ` David Gibson
2008-10-24 16:41 ` Anton Vorontsov
2008-10-24 17:01 ` Anton Vorontsov
2008-10-24 22:17 ` Matt Sealey
2008-10-24 22:17 ` Matt Sealey
2008-10-24 22:37 ` Anton Vorontsov
-- strict thread matches above, loose matches on Subject: below --
2008-10-28 13:31 Konstantinos Margaritis
2008-10-28 14:11 ` Anton Vorontsov
2008-10-28 14:11 ` Anton Vorontsov
2008-10-28 14:15 ` Grant Likely
2008-10-28 14:15 ` Grant Likely
2008-10-28 17:06 ` Matt Sealey
2008-10-28 17:06 ` Matt Sealey
2008-10-28 17:32 ` Grant Likely
2008-10-28 23:37 ` David Gibson
2008-10-28 23:37 ` David Gibson
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=20081024032944.GE4267@yookeroo.seuss \
--to=david@gibson.dropbear.id.au \
--cc=devicetree-discuss@ozlabs.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=wmb@firmworks.com \
/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.