Darren Etheridge [off-list ref] wrote on Tue [2014-May-06 14:58:04 -0500]:

Nishanth Menon [off-list ref] wrote on Tue [2014-May-06 14:46:10 -0500]:

quoted

On 05/06/2014 02:40 PM, Felipe Balbi wrote:

quoted

On Tue, May 06, 2014 at 07:26:17PM +0530, Sricharan R wrote:

quoted

This adds the irq crossbar device node.

There is a IRQ crossbar device in the soc, which
maps the irq requests from the peripherals to the
mpu interrupt controller's inputs. The Peripheral irq
requests are connected to only one crossbar
input and the output of the crossbar is connected to only one
controller's input line. The crossbar device is used to map
a peripheral input to a free mpu's interrupt controller line.

Cc: Benoit Cousson <redacted>
Cc: Santosh Shilimkar <redacted>
Cc: Rajendra Nayak <redacted>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sricharan R <redacted>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
[V5] Rebased on top of 3.15-rc4 and corrected the
     irqs-reserved list

 arch/arm/boot/dts/dra7.dtsi |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 149b550..0274a86 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi

@@ -790,6 +790,14 @@
 			status = "disabled";
 		};
 	};
+
+	crossbar_mpu: crossbar at 4a020000 {

shouldn't this be "status = disabled"; so that boards enable this
on-demand ??

It cannot be and does not need to be. crossbar is an SoC feature. by
defining crossbar, the IRQ numbers we provide in DTS now becomes
crossbar numbers which get mapped to GIC interrupt numbers dynamically.

further crossbar is not a board feature. it is as ingrained in DRA7
behavior as GIC is. we are fortunate that we have some default mapping
of crossbar that allows the current peripherals to work, with this
support, we dont have to depend any longer on "we are lucky that is
mapped".

That said, in hindsight, patch #1 and 2 should be squashed IMHO. else
we have a bisectability problem here.

Yes the bisectability problem is completely true - I was just testing
that as your email came in.  In fact I think all three patches need to
be squashed into one, I can't boot the dra7-EVM unless I have all three
patches applied.

Or I just tried reordering, so patch 3/3 becomes patch 1 and then squash
patch 1/3 and patch 2/3 together to form patch 2.  That seems to at
least let the kernel boot to completion.

Darren