Re: [PATCH v4 1/2] bcma: register bcma as device tree driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 09/24/2014 11:48 AM, Arnd Bergmann wrote:
> On Wednesday 24 September 2014 00:04:18 Hauke Mehrtens wrote:
>> 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
>>                 >;
>>         };
> 
> 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?

Some cores do have more than one IRQ. The NAND core uses 8 IRQs and the
PCIe controller uses 5 (the vendor code just uses the last one which
gets triggered always). How can I handle this cases where one device has
more than one IRQ? There is no hardware register these IRQ get mapped
to. As far as I know the driver just knows that this device needs more
IRQs. Should I just add a special device node entry for such devices?

>> 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.

Thanks for the description, that worked for me.

>> 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.


I will split this patch into two patches, one just adding the bcma
registration and an additional RFC patch adding the IRQ stuff.

Hauke
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux