From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 1/2] bcma: register bcma as device tree driver
Date: Wed, 24 Sep 2014 11:48:18 +0200 [thread overview]
Message-ID: <3856565.LYF1mvpGOq@wuerfel> (raw)
In-Reply-To: <5421EE62.2080701@hauke-m.de>
On Wednesday 24 September 2014 00:04:18 Hauke Mehrtens wrote:
> I assume this should then look somehow like this:
>
> axi at 18000000 {
> compatible = "brcm,bus-axi";
> reg = <0x18000000 0x1000>;
> ranges = <0x00000000 0x18000000 0x00100000>;
> #address-cells = <1>;
> #size-cells = <1>;
>
> #interrupt-cells = <1>;
> interrupt-map = <
> /* ChipCommon */
> 0x00000000 0 &gic GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH
>
> /* PCIe Controller 0 */
> 0x00012000 0 &gic GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH
> 0x00012000 1 &gic GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH
> 0x00012000 2 &gic GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH
> 0x00012000 3 &gic GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH
> 0x00012000 4 &gic GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH
> 0x00012000 5 &gic GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH
>
> /* USB 2.0 Controller */
> 0x00021000 0 &gic GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH
> >;
> };
Right, although I would add a few more '<', '>' and ',' for readability,
separating each line with a comma.
You are also missing an 'interrupt-map-mask' property that lists which
bits of the address are significant.
Are the interrupt numbers you have in the example (0, 0, 1, 2, ... 5, 0)
the actual numbers that are present in the hw registers?
> How does the mapping of these interrupts to the devices work?
The same way that of_irq_parse_and_map_pci() works (the second half of it).
It's a very similar situation: you have a discoverable bus on which the
interrupts are listed in a different domain from which they are supposed to
be on the parent. The trick is to make up your own address property
and of_phandle_args on the stack and fill that with the data from
the hw bus scan, so you can get into the middle of the normal DT
irq code that gets them from device nodes.
> Do I have to add a device tree entry for every device after all?
No, unless you want to add other properties in the node, such as
a MAC address, but then you still only need some of the devices.
> Do you have some example code where this is handled in code, I could not
> find the code doing this for PCI.
drivers/of/of_pci_irq.c, though the hard part is done in drivers/of/irq.c,
which parses the interrupt-map and interrupt-map-mask properties.
Arnd
next prev parent reply other threads:[~2014-09-24 9:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-21 22:38 [PATCH v4 1/2] bcma: register bcma as device tree driver Hauke Mehrtens
2014-09-21 22:38 ` [PATCH v4 2/2] bcma: get IRQ numbers from dt Hauke Mehrtens
2014-09-22 7:26 ` [PATCH v4 1/2] bcma: register bcma as device tree driver Arnd Bergmann
2014-09-23 22:04 ` Hauke Mehrtens
2014-09-24 9:48 ` Arnd Bergmann [this message]
2014-09-24 21:19 ` Hauke Mehrtens
2014-09-25 5:55 ` Arnd Bergmann
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=3856565.LYF1mvpGOq@wuerfel \
--to=arnd@arndb.de \
--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