linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: Matt Sealey <matt@genesi-usa.com>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	devicetree-discuss list <devicetree-discuss@ozlabs.org>,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: GPIO - marking individual pins (not) available in device tree
Date: Sat, 25 Oct 2008 02:37:48 +0400	[thread overview]
Message-ID: <20081024223748.GA30499@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <49024986.5030406@genesi-usa.com>

On Fri, Oct 24, 2008 at 05:17:42PM -0500, Matt Sealey wrote:
> Anton Vorontsov wrote:
>> On Fri, Oct 24, 2008 at 08:41:20PM +0400, Anton Vorontsov wrote:
>> [...]
>>>> Would we suggest a node;
>>>>
>>>> gpio-header {
>>>> 	compatible = "bplan,efika-gpio";
>>>> 	gpios = <&gpio-standard 16 0 17 0>;
>>>> };
>>>>
>>>> gpio-header2 {
>>>> 	compatible = "bplan,efika-gpio-wkup";
>>>> 	gpios = <&gpio-wkup 18 0>;
>>>> };
>>> IMO this looks very reasonable. You properly describe the hardware:
>>> physical device (header) and its resources.
>>
>> If there are actually two headers, that is. If you use two nodes
>> just to specify which gpio is wkup, that is's a bit ugly... Why not
>>
>> gpio-header {
>> 	compatible = "bplan,<board>-gpio-header";
>> 	gpios = <&standard 16 0
>> 		 &standard 17 0
>> 		 &wakeup 18 0>;
>> }
>>
>> And the driver whould know that on this particular <board>
>> third gpio is the wakeup one?
>
> Good point, I concede to your much better plan :D

;-)

> Back to the other discussion, where we give individual GPIOs some
> names so they are detectable and not just programmable as a bank,
> do you have any ideas about that? :/

Pure GPIOs don't have names. But when you use bindings they
automatically translate to names. For example FHCI bindings:

                usb@6c0 {
                        compatible = "fsl,mpc8360-qe-usb",
                                     "fsl,mpc8323-qe-usb";
                        reg = <0x6c0 0x40 0x8b00 0x100>;
                        interrupts = <11>;
                        interrupt-parent = <&qeic>;
                        fsl,fullspeed-clock = "clk21";
                        fsl,lowspeed-clock = "brg9";
                        gpios = <&qe_pio_b  2 0   /* USBOE */
                                 &qe_pio_b  3 0   /* USBTP */
                                 &qe_pio_b  8 0   /* USBTN */
                                 &qe_pio_b  9 0   /* USBRP */
                                 &qe_pio_b 11 0   /* USBRN */
                                 &bcsr13    5 0   /* SPEED */
                                 &bcsr13    4 1>; /* POWER */
                };

The bindings specify that gpios[0] (here qe_pio_b 2) is USBOE,
gpios[1] (here qe_pin_b 3) is USBTP, and so on.

There is nothing new in this. You can see the reg = <> property in
these bindings. It specify two regions: 0x6c0 0x40 - USB Regs
and 0x8b00 0x100 - USB parameter ram. Pure addresses don't have
names until bindings applied.

The same is for interrupts. Device may specify several interrupts:

                enet0: ethernet@24000 {
                        cell-index = <0>;
                        device_type = "network";
                        model = "TSEC";
                        compatible = "gianfar";
                        reg = <0x24000 0x1000>;
                        local-mac-address = [ 00 00 00 00 00 00 ];
                        interrupts = <32 0x8 33 0x8 34 0x8>;
                        interrupt-parent = <&ipic>;
                        phy-handle = <&phy1c>;
                        linux,network-index = <0>;
                };

IRQ 32 is tx interrupt, IRQ33 is rx interrupt, and IRQ34 is
error-reporting interrupt.

But w/o any bindings nobody can tell what does IRQ33 mean (well,
actually we can tell it for ipic on this particular processor,
since it has hard-coded "SOC device<->irq" mapping. But it might
be not true for other controllers, or even ipic's external
interrupts).

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

  reply	other threads:[~2008-10-24 22:37 UTC|newest]

Thread overview: 52+ 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 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
2008-10-24  4:17         ` Mitch Bradley
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 21:56                         ` Matt Sealey
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  2:37                               ` Anton Vorontsov
2008-10-28 16:53                                 ` Matt Sealey
2008-10-28 17:39                                   ` Grant Likely
2008-10-28 19:46                                     ` Matt Sealey
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-24 22:03       ` Matt Sealey
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 23:53             ` David Gibson
2008-10-27 16:12               ` Matt Sealey
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:34                 ` David Gibson
2008-10-24  4:58     ` 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:37       ` Anton Vorontsov [this message]
  -- 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:15 ` Grant Likely
2008-10-28 17:06   ` Matt Sealey
2008-10-28 17:32     ` Grant Likely
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=20081024223748.GA30499@oksana.dev.rtsoft.ru \
    --to=avorontsov@ru.mvista.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=devicetree-discuss@ozlabs.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=matt@genesi-usa.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 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).