irqchip: kill the GIC routable domain

This proves to be usefull with stacked domains.

Signed-off-by Marc Zyngier <[email protected]>

---
 include/linux/irq.h |  1 +
 kernel/irq/chip.c   | 16 ++++++++++++++++
 2 files changed, 17 insertions(+)

include/linux/irq.h +1 -0

index 8badf34..7de85b8 100644
@@ -459,6 +459,7 @@ extern void irq_chip_eoi_parent(struct irq_data *data);
 extern int irq_chip_set_affinity_parent(struct irq_data *data,
 					const struct cpumask *dest,
 					bool force);
+extern int irq_chip_set_wake_parent(struct irq_data *data, unsigned int on);
 #endif
 
 static inline void irq_chip_write_msi_msg(struct irq_data *data,

kernel/irq/chip.c +0 -0

index 6f1c7a5..96c190b 100644

kernel/irq/chip.c +13 -0

+ * @data:	Pointer to interrupt specific data
+ * @on:		Whether to set or reset the wake-up capability of this irq
+ *
+ * Conditional, as the underlying parent chip might not implement it.
+ */
+int irq_chip_set_wake_parent(struct irq_data *data, unsigned int on)
+{
+	data = data->parent_data;
+	if (data->chip->irq_set_wake)
+		return data->chip->irq_set_wake(data, on);
+
+	return -ENOSYS;
+}
 #endif
 
 /**

Thanks for the CC, interesting read for me, good preparation for the next revision of my Vybrid patchset. One thing I stumbled upon below:

Quoted 26 lines · Marc Zyngier

This proves to be usefull with stacked domains.

Signed-off-by Marc Zyngier <[email protected]>

---
 include/linux/irq.h |  1 +
 kernel/irq/chip.c   | 16 ++++++++++++++++
 2 files changed, 17 insertions(+)

include/linux/irq.h +1 -0

index 8badf34..7de85b8 100644
@@ -459,6 +459,7 @@ extern void irq_chip_eoi_parent(struct irq_data *data);
 extern int irq_chip_set_affinity_parent(struct irq_data *data,
 					const struct cpumask *dest,
 					bool force);
+extern int irq_chip_set_wake_parent(struct irq_data *data, unsigned int on);
 #endif
 
 static inline void irq_chip_write_msi_msg(struct irq_data *data,

kernel/irq/chip.c +0 -0

index 6f1c7a5..96c190b 100644
@@ -948,6 +948,22 @@ int irq_chip_retrigger_hierarchy(struct irq_data *data)
 

kernel/irq/chip.c int irq_chip_retrigger_hierarchy(struct irq_data *data) · line 953

Quoted 5 lines

kernel/irq/chip.c +3 -0

 	return -ENOSYS;
 }
+
+/**
+ * irq_chip_set_wake - Set/reset wake-up on the parent interrupt

                       ^

This should be irq_chip_set_wake_parent I guess...

After my series removing the gic_arch_extn hack, I figured that the next step was to expunge the GIC driver of the routable domain horror.

There is a few reasons for this:

- The allocation of interrupts in this domain is fairly similar to what we do for MSI (see the GICv2m driver), and stacked domains have proved to be a fitting solution.

- The current description in DT is currently entierely inaccurate, and as we already broke it for the OMAP WUGEN block, we might as well do it again for the TI crossbar.

- The way crossbar, WUGEN and GIC interract is quite complex (this is effectively a stack of three interrupt controllers with interesting exceptions and braindead routing), and stacked domains are the right abstraction for that.

- Other platforms (Freescale Vybrid) are starting to come up with the same type of things, and it'd be good to avoid them following the same broken model.

- It removes a few lines from the code base so it can't completely be a bad idea!

So this patch series does exactly that: make the crossbar a stacked interrupt controller that only takes care of setting up the routing, fix the DTs to represent the actual HW, and remove a bit of the craziness from the GIC code.

As for the previous series:

- I haven't been able to test this at all, I don't have access to the HW. TI people, please test and post fixes, as I expect I introduced a few bugs.

- This actively *breaks* existing setups. If you boot a new kernel with an old DT, interrupt routing *will* be broken. Old kernels on a new DT won't boot either! You've been warned. This really outline the necessity of actually describing the HW in device trees...

As for the patches, they are on top of 3.18-rc7 + tip/irq/irqdomain-arm + the gic_arch_extn removal series.

I've pushed the code to:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/die-gic-arch-extn-die-die-die

Comments welcome,

	 M.

Marc Zyngier (5):
genirq: Add irqchip_set_wake_parent
irqchip: crossbar: convert dra7 crossbar to stacked domains
DT: update ti,irq-crossbar binding
irqchip: GIC: get rid of routable domain
DT: arm,gic: kill arm,routable-irqs

 Documentation/devicetree/bindings/arm/gic.txt      |   6 -
 .../devicetree/bindings/arm/omap/crossbar.txt      |  18 +-
 arch/arm/boot/dts/dra7.dtsi                        |  10 +-
 arch/arm/boot/dts/dra72x.dtsi                      |   3 +-
 arch/arm/boot/dts/dra74x.dtsi                      |   5 +-
 arch/arm/mach-omap2/omap4-common.c                 |   4 -
 drivers/irqchip/irq-crossbar.c                     | 202 ++++++++++++---------
 drivers/irqchip/irq-gic.c                          |  59 +-----
 include/linux/irq.h                                |   1 +
 include/linux/irqchip/arm-gic.h                    |   6 -
 include/linux/irqchip/irq-crossbar.h               |  11 --
 kernel/irq/chip.c                                  |  16 ++
 12 files changed, 153 insertions(+), 188 deletions(-)
 delete mode 100644 include/linux/irqchip/irq-crossbar.h

Signature · 1 line

2.1.3

Quoted 58 lines · Marc Zyngier

After my series removing the gic_arch_extn hack, I figured that the next step was to expunge the GIC driver of the routable domain horror.

There is a few reasons for this:

- The allocation of interrupts in this domain is fairly similar to what we do for MSI (see the GICv2m driver), and stacked domains have proved to be a fitting solution.

- The current description in DT is currently entierely inaccurate, and as we already broke it for the OMAP WUGEN block, we might as well do it again for the TI crossbar.

- The way crossbar, WUGEN and GIC interract is quite complex (this is effectively a stack of three interrupt controllers with interesting exceptions and braindead routing), and stacked domains are the right abstraction for that.

- Other platforms (Freescale Vybrid) are starting to come up with the same type of things, and it'd be good to avoid them following the same broken model.

- It removes a few lines from the code base so it can't completely be a bad idea!

So this patch series does exactly that: make the crossbar a stacked interrupt controller that only takes care of setting up the routing, fix the DTs to represent the actual HW, and remove a bit of the craziness from the GIC code.

As for the previous series:

- I haven't been able to test this at all, I don't have access to the HW. TI people, please test and post fixes, as I expect I introduced a few bugs.

- This actively *breaks* existing setups. If you boot a new kernel with an old DT, interrupt routing *will* be broken. Old kernels on a new DT won't boot either! You've been warned. This really outline the necessity of actually describing the HW in device trees...

As for the patches, they are on top of 3.18-rc7 + tip/irq/irqdomain-arm + the gic_arch_extn removal series.

I've pushed the code to:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/die-gic-arch-extn-die-die-die

Comments welcome,

	 M.

Marc Zyngier (5):
genirq: Add irqchip_set_wake_parent
irqchip: crossbar: convert dra7 crossbar to stacked domains
DT: update ti,irq-crossbar binding
irqchip: GIC: get rid of routable domain
DT: arm,gic: kill arm,routable-irqs

Quoted 18 lines

 Documentation/devicetree/bindings/arm/gic.txt      |   6 -
 .../devicetree/bindings/arm/omap/crossbar.txt      |  18 +-
 arch/arm/boot/dts/dra7.dtsi                        |  10 +-
 arch/arm/boot/dts/dra72x.dtsi                      |   3 +-
 arch/arm/boot/dts/dra74x.dtsi                      |   5 +-
 arch/arm/mach-omap2/omap4-common.c                 |   4 -
 drivers/irqchip/irq-crossbar.c                     | 202 ++++++++++++---------
 drivers/irqchip/irq-gic.c                          |  59 +-----
 include/linux/irq.h                                |   1 +
 include/linux/irqchip/arm-gic.h                    |   6 -
 include/linux/irqchip/irq-crossbar.h               |  11 --
 kernel/irq/chip.c                                  |  16 ++
 12 files changed, 153 insertions(+), 188 deletions(-)
 delete mode 100644 include/linux/irqchip/irq-crossbar.h

Signature · 1 line

2.1.3

	Patches are available here:
	https://patchwork.kernel.org/patch/5449231/
	https://patchwork.kernel.org/patch/5449241/
	https://patchwork.kernel.org/patch/5449271/
	https://patchwork.kernel.org/patch/5449261/
	https://patchwork.kernel.org/patch/5449251/

Marc,

Quoted 78 lines · Nishanth Menon

Quoted 58 lines · Marc Zyngier

After my series removing the gic_arch_extn hack, I figured that the next step was to expunge the GIC driver of the routable domain horror.

There is a few reasons for this:

- The allocation of interrupts in this domain is fairly similar to what we do for MSI (see the GICv2m driver), and stacked domains have proved to be a fitting solution.

- The current description in DT is currently entierely inaccurate, and as we already broke it for the OMAP WUGEN block, we might as well do it again for the TI crossbar.

- The way crossbar, WUGEN and GIC interract is quite complex (this is effectively a stack of three interrupt controllers with interesting exceptions and braindead routing), and stacked domains are the right abstraction for that.

- Other platforms (Freescale Vybrid) are starting to come up with the same type of things, and it'd be good to avoid them following the same broken model.

- It removes a few lines from the code base so it can't completely be a bad idea!

So this patch series does exactly that: make the crossbar a stacked interrupt controller that only takes care of setting up the routing, fix the DTs to represent the actual HW, and remove a bit of the craziness from the GIC code.

As for the previous series:

- I haven't been able to test this at all, I don't have access to the HW. TI people, please test and post fixes, as I expect I introduced a few bugs.

- This actively *breaks* existing setups. If you boot a new kernel with an old DT, interrupt routing *will* be broken. Old kernels on a new DT won't boot either! You've been warned. This really outline the necessity of actually describing the HW in device trees...

As for the patches, they are on top of 3.18-rc7 + tip/irq/irqdomain-arm + the gic_arch_extn removal series.

I've pushed the code to:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/die-gic-arch-extn-die-die-die

Comments welcome,

	 M.

Marc Zyngier (5):
genirq: Add irqchip_set_wake_parent
irqchip: crossbar: convert dra7 crossbar to stacked domains
DT: update ti,irq-crossbar binding
irqchip: GIC: get rid of routable domain
DT: arm,gic: kill arm,routable-irqs

Quoted 18 lines

 Documentation/devicetree/bindings/arm/gic.txt      |   6 -
 .../devicetree/bindings/arm/omap/crossbar.txt      |  18 +-
 arch/arm/boot/dts/dra7.dtsi                        |  10 +-
 arch/arm/boot/dts/dra72x.dtsi                      |   3 +-
 arch/arm/boot/dts/dra74x.dtsi                      |   5 +-
 arch/arm/mach-omap2/omap4-common.c                 |   4 -
 drivers/irqchip/irq-crossbar.c                     | 202 ++++++++++++---------
 drivers/irqchip/irq-gic.c                          |  59 +-----
 include/linux/irq.h                                |   1 +
 include/linux/irqchip/arm-gic.h                    |   6 -
 include/linux/irqchip/irq-crossbar.h               |  11 --
 kernel/irq/chip.c                                  |  16 ++
 12 files changed, 153 insertions(+), 188 deletions(-)
 delete mode 100644 include/linux/irqchip/irq-crossbar.h

Signature · 1 line

2.1.3

Quoted 6 lines

	Patches are available here:
	https://patchwork.kernel.org/patch/5449231/
	https://patchwork.kernel.org/patch/5449241/
	https://patchwork.kernel.org/patch/5449271/
	https://patchwork.kernel.org/patch/5449261/
	https://patchwork.kernel.org/patch/5449251/

dra7xx-evm(3.18-rc7):  Boot PASS: http://slexy.org/raw/s2PXWFB47A
dra7xx-evm(irq branch):  Boot FAIL: http://slexy.org/raw/s2xMgD4zkP

Would you want me to debug more - dts changes perhaps?

On 07/12/14 18:03, Nishanth Menon wrote:

Quoted 4 lines

dra7xx-evm(3.18-rc7):  Boot PASS: http://slexy.org/raw/s2PXWFB47A
dra7xx-evm(irq branch):  Boot FAIL: http://slexy.org/raw/s2xMgD4zkP

Would you want me to debug more - dts changes perhaps?

Yes, it would be useful to find out. One thing that strikes me is that the kernel boots all the way, so I assume IRQs are actually up and running.

One thing though. The "irq" branch shows this:

[   15.359025] pbias_mmc_omap5: disabling

and the MMC subsystem never initializes. I'm pretty sure this is related. Config option?

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.

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

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

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

I suggest skipping 3.19 if possible and giving it a more detailed time in linux-next with omap4 etc being more thoroughly being tested before letting it through, if possible.

[1] ------------- diff ------------

 arch/arm/boot/dts/dra7-evm.dts |    2 +-
 arch/arm/boot/dts/dra7.dtsi    |   23 +++++++++++++----------
 drivers/irqchip/irq-crossbar.c |    4 ++--
 3 files changed, 16 insertions(+), 13 deletions(-)

arch/arm/boot/dts/dra7-evm.dts +0 -0

index c6ce625..d024429 100644

drivers/irqchip/irq-crossbar.c +1 -1

index b44915a..f7daff0 100644
@@ -99,7 +99,7 @@ static int allocate_gic_irq(struct irq_domain *domain, unsigned virq,
 	if (err)
 		cb->irq_map[i] = IRQ_FREE;
 	else
-		cb->write(hwirq, i);
+		cb->write(i, hwirq);
 
 	return err;
 }

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.

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

Quoted 4 lines

OMAP5: (should be wugen?)

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

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

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)

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

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

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

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

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.

Quoted 85 lines · Marc Zyngier

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.

Quoted 6 lines

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.

Did a quick run.. and thought of testing power management and found that CPUFreq for my platforms are broken in v3.18-rc7 and my scripts broke (so much for my cronjob testing daily boot... now I gotta add some PM test as well.. Sigh..) anyways.. just boot log..

based on
irq/die-gic-arch-extn-die-die-die c0024cb irqchip: gic: Drop support for gic_arch_extn

 1: am335x-evm:  Boot PASS: http://slexy.org/raw/s201YeK4dW
 2:  am335x-sk:  Boot PASS: http://slexy.org/raw/s20nydiyVx
 3: am3517-evm:  Boot PASS: http://slexy.org/raw/s2aTrenePo
 4:  am437x-sk:  Boot FAIL: http://slexy.org/raw/s20NNiEa4W
 5: am43xx-epos:  Boot PASS: http://slexy.org/raw/s2gghhhyOy
 6: am43xx-gpevm:  Boot PASS: http://slexy.org/raw/s2LY4Cb75N
 7: BeagleBoard-XM:  Boot PASS: http://slexy.org/raw/s2e8iJMUXu
 8: beagleboard-vanilla:  Boot PASS: http://slexy.org/raw/s20wqxUmvr
 9: beaglebone-black:  Boot PASS: http://slexy.org/raw/s21I0g2Ba3
10: beaglebone:  Boot PASS: http://slexy.org/raw/s2lpED0qW4
11: craneboard:  Boot PASS: http://slexy.org/raw/s230RKflY3
12: dra72x-evm:  Boot FAIL: http://slexy.org/raw/s21fWVnjaB
13: dra7xx-evm:  Boot PASS: http://slexy.org/raw/s20yEhfruO

14: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s20qZaXwz0
15: n900: Boot PASS: http://slexy.org/raw/s21LNTXZP7
16: omap5-evm: Boot PASS: http://slexy.org/raw/s2WF8eAcK2
17: pandaboard-es: Boot PASS: http://slexy.org/raw/s21PVo7ENF
18: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s2BcMbSrVF

19:    sdp2430:  Boot PASS: http://slexy.org/raw/s24LgXbav1
20:    sdp3430:  Boot PASS: http://slexy.org/raw/s21IaKdkUs

TOTAL = 20 boards, Booted Boards = 18, No Boot boards = 2

will try to first try and save a bit of cpufreq and reinstate my scripts and once you post based on 3.19-rc1, will do a retest..

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.