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

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

 




On 09/13/2014 06:40 PM, Arend van Spriel wrote:
> On 09/13/14 18:02, Hauke Mehrtens wrote:
>> On 09/13/2014 05:13 PM, Arend van Spriel wrote:
>>> On 09/13/14 15:37, Hauke Mehrtens wrote:
>>>> This driver is used by the bcm53xx ARM SoC code. Now it is possible to
>>>> give the address of the chipcommon core in device tree and bcma will
>>>> search for all the other cores.
>>>>
>>>> Signed-off-by: Hauke Mehrtens<hauke@xxxxxxxxxx>
>>>> ---
>>>>    Documentation/devicetree/bindings/bus/bcma.txt | 41 +++++++++++++
>>>>    drivers/bcma/bcma_private.h                    | 16 +++++
>>>>    drivers/bcma/host_soc.c                        | 82
>>>> ++++++++++++++++++++++++++
>>>>    drivers/bcma/main.c                            | 10 ++++
>>>>    include/linux/bcma/bcma.h                      |  2 +
>>>>    5 files changed, 151 insertions(+)
>>>>    create mode 100644 Documentation/devicetree/bindings/bus/bcma.txt
>>>>
>>>> This is based on wireless-testing and should go into that tree.
>>>>
>>>> changes since:
>>>> RFC:
>>>>    - reworded the irq description
>>>>    - improved the example
>>>>    - hocked into bcma_modeinit() and bcma_modexit()
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/bus/bcma.txt
>>>> b/Documentation/devicetree/bindings/bus/bcma.txt
>>>> new file mode 100644
>>>> index 0000000..17e095f
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/bus/bcma.txt
>>>> @@ -0,0 +1,41 @@
>>>> +Broadcom AIX SoC bcma bus driver
>>>
>>> Hi Hauke,
>>>
>>> First of all a typo used all over the place: AIX should be AXI.
>>
>> I will fix that.
>>
>>> The backplane in Broadcom SoC is ARM AXI with additional plugin option
>>> to make it discoverable. Indeed the IRQ info is not included, but I see
>>> no reason for specifying the register space for the cores in device-tree
>>> as that is discoverable by bcma.
>>
>> I specified the register space to make it possible to connect the device
>> tree entry with the core. After the cores are automatically discovered,
>> bcma searches for entry core found, for an device tree entry with the
>> same address space and uses the irq number from that entry. If there is
>> a core defined in device tree which is not found by bcma it will just be
>> ignored. If a core is not specified in device tree it will get
>> registered, but it will not get an IRQ.
>> This was the most stable way I came up with, I also thought about using
>> the core number, like assign the this IRQ to core number 5, but the core
>> numbers could change when we do changes to bcma.
> 
> I understand. In the example I noticed the core base address was also
> used in the entry label, ie. pcie@18002000. However, I am not sure
> whether that can be obtained by the driver. If it is possible it could
> be used to match the dt entry to a core and the register info would be
> redundant.

I could parse that out of the full name. The full name looks like this:
"/axi@18000000/ethernet@18024000", but I do not think that would be nice.

@Arnd Bergmann: is there some better way to connect an automatically
detected device with an device tree entry?

>> In the Broadcom vendor code there is a list with the IRQ numbers which
>> get assigned to a specific core type. For example there is a list with 4
>> IRQ numbers which get assigned to the first 4 Ethernet cores. This would
>> also work, but I do not know how to do this in device tree.
> 
> I am wondering about the IRQ numbers. The SoC would also have a OOB
> routing core, which controls non-axi signals between the cores. I will
> ask internally whether the irq signals are controlled by it and can be
> retrieved from it.

Thanks, It would be nice if that is possible.

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