From: wmb@firmworks•com (Mitch Bradley)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
Date: Thu, 05 Jul 2012 08:36:53 -1000 [thread overview]
Message-ID: <4FF5DEC5.9030707@firmworks.com> (raw)
In-Reply-To: <201207051454.24475.arnd@arndb.de>
On 7/5/2012 4:54 AM, Arnd Bergmann wrote:
> On Thursday 05 July 2012, Sebastian Hesselbarth wrote:
>> Andrew,
>>
>> is it possible to group all gpio banks into one DT description?
>> For mach-dove it could be something like:
>>
>> gpio: gpio-controller {
>> compatible = "marvell, orion-gpio";
>> ...
>>
>> bank0 at d0400 {
>> reg = <0xd0400 0x40>;
>> ngpio = <8>;
>> mask-offset = <0>;
>> interrupts = <12>;
>> };
>>
>> bank1 at d0400 {
>> reg = <0xd0400 0x40>;
>> ngpio = <8>;
>> mask-offset = <8>;
>> interrupts = <13>;
>> };
>
> This way you have multiple nodes with the same register
> and different names, which is not how it normally works.
The "mask-offset" property is really a "reg" in disguise.
"reg" is considerably more general than just "memory mapped
register address". It really means "any numeric identifier
that makes sense in the context of a parent device".
Therefore, one could say:
gpio: gpio-controller {
compatible = "marvell, orion-gpio";
reg = <0xd0400 0x40>;
#address-cells = <1>;
#size-cells = <0>;
...
bank0 at 0 {
reg = <0x0>;
ngpio = <8>;
mask-offset = <0>;
interrupts = <12>;
};
bank1 at 8 {
reg = <0x8>;
ngpio = <8>;
interrupts = <13>;
};
>
>>
>> This would have the advantage that DT describes gpio-to-irq dependencies.
>> Moreover, nodes that reference gpios can do gpios = <&gpio 71 0>; instead of
>> gpios = <&gpio3 7 0>;
>
> Is that desired?
>
> The device tree representation should match what is in the data sheet
> normally. If they are in a single continuous number range, then we should
> probably have a single device node with multiple register ranges
> rather than one device node for each 32-bit register. Looking at
> arch/arm/plat-orion/gpio.c I think that is not actually the case though
> and having separate banks is more logical.
>
> Something completely different I just noticed in the original patch:
>
>> @@ -90,6 +74,27 @@ static void pmu_irq_handler(unsigned int irq, struct irq_desc *desc)
>> }
>> }
>>
>> +static int __initdata gpio0_irqs[4] = {
>> + IRQ_DOVE_GPIO_0_7,
>> + IRQ_DOVE_GPIO_8_15,
>> + IRQ_DOVE_GPIO_16_23,
>> + IRQ_DOVE_GPIO_24_31,
>> +};
>> +
>> +static int __initdata gpio1_irqs[4] = {
>> + IRQ_DOVE_HIGH_GPIO,
>> + 0,
>> + 0,
>> + 0,
>> +};
>
> I think the latter one needs to be
>
> +static int __initdata gpio1_irqs[4] = {
> + IRQ_DOVE_HIGH_GPIO,
> + IRQ_DOVE_HIGH_GPIO,
> + IRQ_DOVE_HIGH_GPIO,
> + IRQ_DOVE_HIGH_GPIO,
> +};
>
> so we register all four parts to the same primary IRQ. The
> same is true for the devicetree representation.
>
> Arnd
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
next prev parent reply other threads:[~2012-07-05 18:36 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-03 14:22 [PATCH v2 00/12] IRQ, GPIO SPI, I2C, etc DTC support Andrew Lunn
2012-07-03 14:22 ` [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers Andrew Lunn
2012-07-05 8:15 ` Andrew Lunn
2012-07-05 9:02 ` Thomas Petazzoni
2012-07-05 9:48 ` Andrew Lunn
2012-07-05 10:10 ` Thomas Petazzoni
2012-07-05 10:25 ` Andrew Lunn
2012-07-05 10:11 ` Arnaud Patard (Rtp)
2012-07-05 10:20 ` Thomas Petazzoni
2012-07-05 10:38 ` Arnaud Patard (Rtp)
2012-07-05 11:42 ` Thomas Petazzoni
2012-07-05 11:48 ` Andrew Lunn
2012-07-05 12:09 ` Sebastian Hesselbarth
2012-07-05 12:58 ` Thomas Petazzoni
2012-07-05 13:15 ` Andrew Lunn
2012-07-05 13:28 ` Thomas Petazzoni
2012-07-05 13:33 ` Andrew Lunn
2012-07-05 13:36 ` Thomas Petazzoni
2012-07-05 12:25 ` Arnd Bergmann
2012-07-05 13:08 ` Andrew Lunn
2012-07-05 13:47 ` Arnd Bergmann
2012-07-05 13:54 ` Andrew Lunn
2012-07-05 15:47 ` Arnd Bergmann
2012-07-05 14:14 ` Sebastian Hesselbarth
2012-07-05 14:43 ` Andrew Lunn
2012-07-05 14:54 ` Arnd Bergmann
2012-07-05 15:51 ` Sebastian Hesselbarth
2012-07-05 16:30 ` Arnaud Patard (Rtp)
2012-07-05 16:16 ` Andrew Lunn
2012-07-06 20:08 ` Arnd Bergmann
2012-07-06 21:00 ` Andrew Lunn
2012-07-07 0:24 ` Where to put a large bootloader-supplied device tree on ARM ? Mitch Bradley
2012-07-07 1:23 ` David VomLehn (dvomlehn)
2012-07-07 1:59 ` Mitch Bradley
2012-07-09 4:30 ` Nicolas Pitre
2012-07-12 6:52 ` Mitch Bradley
2012-07-12 18:16 ` Nicolas Pitre
2012-07-12 20:34 ` Rob Herring
2012-07-12 21:38 ` [U-Boot] " Albert ARIBAUD
2012-07-12 21:47 ` Wolfgang Denk
2012-07-13 1:28 ` Rob Herring
2012-07-13 6:45 ` Albert ARIBAUD
2012-07-05 18:36 ` Mitch Bradley [this message]
2012-07-03 14:22 ` [PATCH v2 02/12] SPI: Refactor spi-orion to use SPI framework queue Andrew Lunn
2012-07-03 14:22 ` [PATCH v2 03/12] spi-orion: remove uneeded spi_info Andrew Lunn
2012-07-03 14:22 ` [PATCH v2 04/12] spi-orion: add device tree binding Andrew Lunn
2012-07-03 14:22 ` [PATCH v2 05/12] ARM: kirkwood: use devicetree for orion-spi Andrew Lunn
2012-07-03 14:22 ` [PATCH v2 06/12] ARM: kirkwood: use devicetree for SPI on dreamplug Andrew Lunn
2012-07-03 14:22 ` [PATCH v2 07/12] I2C: MV64XXX: Add Device Tree support Andrew Lunn
2012-07-03 15:59 ` Florian Fainelli
2012-07-03 16:58 ` Andrew Lunn
2012-07-04 19:49 ` Florian Fainelli
2012-07-05 6:52 ` Andrew Lunn
2012-07-03 14:22 ` [PATCH v2 08/12] Kirkwood: Add basic device tree support for QNAP TS219 Andrew Lunn
2012-07-03 15:47 ` Florian Fainelli
2012-07-03 17:09 ` Andrew Lunn
2012-07-03 14:22 ` [PATCH v2 09/12] ARM: Kirkwood: DTify the watchdog timer Andrew Lunn
2012-07-03 14:22 ` [PATCH v2 10/12] ATA: sata_mv: Add device tree support Andrew Lunn
2012-07-03 14:22 ` [PATCH v2 11/12] ARM: Kirkwood: Use DT to configure SATA device Andrew Lunn
2012-07-03 14:52 ` Josh Coombs
2012-07-03 15:32 ` Andrew Lunn
2012-07-03 14:22 ` [PATCH v2 12/12] Crypto: CESA: Add support for DT based instantiation Andrew Lunn
2012-07-03 15:50 ` Florian Fainelli
2012-07-03 17:03 ` Andrew Lunn
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=4FF5DEC5.9030707@firmworks.com \
--to=wmb@firmworks$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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