irqchip: kill the GIC routable domain
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 5 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 5 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/5] 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 tps65218OMAP5: (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/swpu249yeah, 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/s222JndDdharch/arm/boot/dts/omap4-panda-common.dtsi +0
-0
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.
Thanks,
M.
Signature · 1 line
Jazz is not dead. It just smells funny...