Thread (1 message) 1 message, 1 author, 2014-09-14

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

From: hauke@hauke-m.de (Hauke Mehrtens)
Date: 2014-09-14 17:16:51
Also in: linux-devicetree, linux-wireless

On 09/13/2014 06:40 PM, Arend van Spriel wrote:
On 09/13/14 18:02, Hauke Mehrtens wrote:
quoted
On 09/13/2014 05:13 PM, Arend van Spriel wrote:
quoted
On 09/13/14 15:37, Hauke Mehrtens wrote:
quoted
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@hauke-m.de>
---
   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.
quoted
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 at 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 at 18000000/ethernet at 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?
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help