irqchip: kill the GIC routable domain

Quoted 29 lines · Nishanth Menon

Quoted 7 lines · Marc Zyngier

Quoted 3 lines · Nishanth Menon

Anyways.. The following diff[1] on top of your branch makes DRA7 work - I assume you will squash as needed and repost with linux-omap mailing list in CC.

Brilliant. I'll squash that into my tree and repost at some point.

K, it will be nice to have a reflow of the series based on v3.19-rc1 since there are dts dependencies and we dont want folks to have regressions on their platforms of choice..

Obviously, my tests are basic boot tests and should get a few weeks(as you already mentioned) on linux-next to get properly soaked

Quoted 13 lines

Quoted 12 lines

I increased the scope of testing knowing that WUGEN is present in many A9 based TI platforms as well.. and at least OMAP4 showed flakiness in my testing.. Also a few notes:

Stuff like: am437x is a bit questionable (interrupt-parent probably should be wugen?)
175: 0 GIC 39 tps65218

OMAP5: (should be wugen?)

308:       4323          0       GIC 106  OMAP UART2
411:          0          0       GIC 151  twl6040
405:          1          0       GIC  39  palmas

Quoted 8 lines

Quoted 2 lines

Well, I can't really tell. Someone with access to the documentation should be able to find out.

AM437x: http://www.ti.com/lit/pdf/spruhl7
OMAP5: http://www.ti.com/lit/pdf/swpu249

yeah, we should be able to do them as well - trivially since they follow the same structure as other SoCs without crossbar.

Done some stuff in that department.

Quoted 10 lines

Quoted 10 lines

Quoted 4 lines

OMAP4 serial port is flaky -> not sure if it is due to routing of GIC to UART2 and not via WUGEN IRQ branch: with my fix applied:
---------------------------------

[...]

Quoted 2 lines

18: pandaboard-es: Boot FAIL: http://slexy.org/raw/s20ty0Z6i5 (not expected) 19: pandaboard-vanilla: Boot FAIL: http://slexy.org/raw/s20BYfaMd2 (not expected)

Quoted 6 lines

Quoted 1 line

If I read the log correctly, the serial port stops responding after a while?

yeah - dug at the omap4 ones a bit, obviously once the deeper c states are hit, we'd like wakeupgen to wakeup CPU else we will be "sluggish" in the sense that the event is detected when some other wakeupgen enabled interrupt takes place.

I realised that as well once I got a panda up and running.

Quoted 10 lines

Adding the following makes my panda work fine.
1: pandaboard-es: Boot PASS: http://slexy.org/raw/s20o8DaBvh
2: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s222JndDdh

arch/arm/boot/dts/omap4-panda-common.dtsi +0 -0

index 1505135..8b6d50e 100644

arch/arm/boot/dts/omap4-panda-common.dtsi line 376

Quoted 8 lines

arch/arm/boot/dts/omap4-panda-common.dtsi +2 -2

@@ -371,8 +371,8 @@
 	twl: twl at 48 {
 		reg = <0x48>;
 		/* IRQ# = 7 */
-		interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; /* IRQ_SYS_1N cascaded to gic */
-		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; /* IRQ_SYS_1N cascaded to wakeupgen to gic */
+		interrupt-parent = <&wakeupgen>;
 	};

[...]

I already fixed those in my tree, in a slightly different way: no need to have an interrupt parent at all, as we're going to inherit the default anyway.

I've pushed another version of the branch, with the crossbar rework sitting *before* the WUGEN hacks. That should hopefully make bisection work.

If you can give it a shake, that'd be most appreciated. I'll repost the branch in a couple of days.