linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hauke Mehrtens <hauke@hauke-m.de>
To: Arnd Bergmann <arnd@arndb.de>, linux-arm-kernel@lists.infradead.org
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
	devicetree@vger.kernel.org, zajec5@gmail.com,
	varkabhadram@gmail.com, arend@broadcom.com
Subject: Re: [PATCH v4 1/2] bcma: register bcma as device tree driver
Date: Wed, 24 Sep 2014 00:04:18 +0200	[thread overview]
Message-ID: <5421EE62.2080701@hauke-m.de> (raw)
In-Reply-To: <4345256.UGZH9SeRYG@wuerfel>

On 09/22/2014 09:26 AM, Arnd Bergmann wrote:
> On Monday 22 September 2014 00:38:27 Hauke Mehrtens wrote:
>> +
>> +- reg : iomem address range of chipcommon core
>> +
>> +The cores on the AXI bus are automatically detected by bcma with the
>> +memory ranges they are using and they get registered afterwards.
>> +Automatic detection of the IRQ number is not reliable on
>> +BCM47xx/BCM53xx ARM SoCs. To assign IRQ numbers to the cores, provide
>> +them manually through device tree. The IRQ number and the device tree
>> +child entry will get assigned to the core with the matching reg address.
>> +
>> +Example:
>> +
>> +       axi@18000000 {
>> +               compatible = "brcm,bus-axi";
>> +               reg = <0x18000000 0x1000>;
>> +               ranges = <0x00000000 0x18000000 0x00100000>;
>> +               #address-cells = <1>;
>> +               #size-cells = <1>;
>> +
>> +               pcie@12000 {
>> +                       reg = <0x00012000 0x1000>;
>> +                       interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
>> +               };
>> +
>> +               ethernet@24000 {
>> +                       reg = <0x00024000 0x1000>;
>> +                       interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>;
>> +               };
>> +
>> +               ethernet@25000 {
>> +                       reg = <0x00025000 0x1000>;
>> +                       interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
>> +               };
>> +       };
>>
> 
> While reading through this new version, I had a new idea about how
> this could be handled better for any machines that have a unique
> number in the interrupt field: If you do the same thing as PCI
> and add an interrupt-map property [1], you can translate that
> number into a real interrupt specifier for the child nodes.
> 
> This can work even if every device lists the local interrupt
> as '0', since you can have device-specific lookup entries if you
> use the correct interrupt-map-mask property.
> 
> 	Arnd
> 
> [1] http://www.openfirmware.org/1275/practice/imap/imap0_9d.pdf
> 

I assume this should then look somehow like this:

axi@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
		>;
	};

How does the mapping of these interrupts to the devices work?

Do I have to add a device tree entry for every device after all?

Do you have some example code where this is handled in code, I could not
find the code doing this for PCI.

Hauke

  reply	other threads:[~2014-09-23 22:04 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 [this message]
2014-09-24  9:48     ` Arnd Bergmann
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=5421EE62.2080701@hauke-m.de \
    --to=hauke@hauke-m.de \
    --cc=arend@broadcom.com \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=varkabhadram@gmail.com \
    --cc=zajec5@gmail.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).