Armada 375/38x perf support, and a bonus irqchip driver simplification

The map, mask and unmask is unnecessarily complicated, with a different implementation for shared and per CPU interrupts. The current code does the following:

At probe time, all interrupts are disabled and masked on all CPUs.

Shared interrupts:

* When the interrupt is mapped(), it gets disabled and unmasked on the calling CPU.

* When the interrupt is unmasked(), masked(), it gets enabled and disabled.

Per CPU interrupts:

* When the interrupt is mapped, it gets masked on the calling CPU and enabled.

* When the interrupt is unmasked(), masked(), it gets unmasked and masked, on the calling CPU.

This commit simplifies this code, with a much simpler implementation, common to shared and per CPU interrupts.

* When the interrupt is mapped, it's enabled.

* When the interrupt is unmasked(), masked(), it gets unmasked and masked, on the calling CPU.

From the point of the view of the armada_370_xp_irq driver there are potential bug, but

Tested on a Armada XP SoC with SMP and UP configurations, with chained and regular interrupts.

Signed-off-by Ezequiel Garcia <[email protected]>

---
 drivers/irqchip/irq-armada-370-xp.c | 27 ++++-----------------------
 1 file changed, 4 insertions(+), 23 deletions(-)

drivers/irqchip/irq-armada-370-xp.c +4 -23

index 3e238cd..af4e307 100644
@@ -73,33 +73,18 @@ static DEFINE_MUTEX(msi_used_lock);
 static phys_addr_t msi_doorbell_addr;
 #endif
 
-/*
- * In SMP mode:
- * For shared global interrupts, mask/unmask global enable bit
- * For CPU interrupts, mask/unmask the calling CPU's bit
- */
 static void armada_370_xp_irq_mask(struct irq_data *d)
 {
 	irq_hw_number_t hwirq = irqd_to_hwirq(d);
 
-	if (hwirq != ARMADA_370_XP_TIMER0_PER_CPU_IRQ)
-		writel(hwirq, main_int_base +
-				ARMADA_370_XP_INT_CLEAR_ENABLE_OFFS);
-	else
-		writel(hwirq, per_cpu_int_base +
-				ARMADA_370_XP_INT_SET_MASK_OFFS);
+	writel(hwirq, per_cpu_int_base + ARMADA_370_XP_INT_SET_MASK_OFFS);
 }
 
 static void armada_370_xp_irq_unmask(struct irq_data *d)
 {
 	irq_hw_number_t hwirq = irqd_to_hwirq(d);
 
-	if (hwirq != ARMADA_370_XP_TIMER0_PER_CPU_IRQ)
-		writel(hwirq, main_int_base +
-				ARMADA_370_XP_INT_SET_ENABLE_OFFS);
-	else
-		writel(hwirq, per_cpu_int_base +
-				ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
+	writel(hwirq, per_cpu_int_base + ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
 }
 
 #ifdef CONFIG_PCI_MSI

@@ -282,12 +267,8 @@ static struct irq_chip armada_370_xp_irq_chip = {
 static int armada_370_xp_mpic_irq_map(struct irq_domain *h,
 				      unsigned int virq, irq_hw_number_t hw)
 {
-	armada_370_xp_irq_mask(irq_get_irq_data(virq));
-	if (hw != ARMADA_370_XP_TIMER0_PER_CPU_IRQ)
-		writel(hw, per_cpu_int_base +
-			ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
-	else
-		writel(hw, main_int_base + ARMADA_370_XP_INT_SET_ENABLE_OFFS);
+	writel(hw, main_int_base + ARMADA_370_XP_INT_SET_ENABLE_OFFS);
+
 	irq_set_status_flags(virq, IRQ_LEVEL);
 
 	if (hw == ARMADA_370_XP_TIMER0_PER_CPU_IRQ) {

Quoted 27 lines · Ezequiel Garcia

The map, mask and unmask is unnecessarily complicated, with a different implementation for shared and per CPU interrupts. The current code does the following:

At probe time, all interrupts are disabled and masked on all CPUs.

Shared interrupts:

* When the interrupt is mapped(), it gets disabled and unmasked on the calling CPU.

* When the interrupt is unmasked(), masked(), it gets enabled and disabled.

Per CPU interrupts:

* When the interrupt is mapped, it gets masked on the calling CPU and enabled.

* When the interrupt is unmasked(), masked(), it gets unmasked and masked, on the calling CPU.

This commit simplifies this code, with a much simpler implementation, common to shared and per CPU interrupts.

* When the interrupt is mapped, it's enabled.

Quoted 2 lines

* When the interrupt is unmasked(), masked(), it gets unmasked and masked, on the calling CPU.

By doing this you change the behavior of the irqchip. Before this patch, masking a shared interrupt was masking it on all the CPUs in the same time whereas with this change it will mask the interrupt only on the calling CPU. It worth checking it is the expected behavior.

Moreover I wonder how it is supposed to work with the irq affinity. Let say that the irq was enabled on the CPU0,

then there is irq_unmask call on CPU1, then the irq would be enabled on both CPUs. It will modify the irq affinity and moreover it will also lead
to an invalidate state with the MPIC because we can't manage an interrupt on more than one CPU.

From the point of the view of the armada_370_xp_irq driver there are potential bug, but maybe the use case I described can't happen. Could you check it?

Hi Gregory,

Quoted 28 lines · Gregory CLEMENT

Quoted 27 lines · Ezequiel Garcia

The map, mask and unmask is unnecessarily complicated, with a different implementation for shared and per CPU interrupts. The current code does the following:

At probe time, all interrupts are disabled and masked on all CPUs.

Shared interrupts:

* When the interrupt is mapped(), it gets disabled and unmasked on the calling CPU.

* When the interrupt is unmasked(), masked(), it gets enabled and disabled.

Per CPU interrupts:

* When the interrupt is mapped, it gets masked on the calling CPU and enabled.

* When the interrupt is unmasked(), masked(), it gets unmasked and masked, on the calling CPU.

This commit simplifies this code, with a much simpler implementation, common to shared and per CPU interrupts.

* When the interrupt is mapped, it's enabled.

Quoted 8 lines

Quoted 2 lines

* When the interrupt is unmasked(), masked(), it gets unmasked and masked, on the calling CPU.

By doing this you change the behavior of the irqchip. Before this patch, masking a shared interrupt was masking it on all the CPUs in the same time whereas with this change it will mask the interrupt only on the calling CPU. It worth checking it is the expected behavior.

The kernel will always mask/unmask on the appropriate CPU, so I don't see any issues with this.

Quoted 2 lines

Moreover I wonder how it is supposed to work with the irq affinity. Let say that the irq was enabled on the CPU0,

If you mean enabled as in irq_enable(irq_desc), then let's keep in mind that currently that calls .irq_unmask.

Quoted 8 lines

then there is irq_unmask call on CPU1, then the irq would be enabled on both CPUs. It will modify the irq affinity and moreover it will also lead
to an invalidate state with the MPIC because we can't manage an interrupt on more than one CPU.

From the point of the view of the armada_370_xp_irq driver there are potential bug, but maybe the use case I described can't happen. Could you check it?

In this irqchip driver, shared interrupts are handled via handle_level_irq(), which masks() and unmasks() the interrupt. In other words, it's always done in the same CPU. I guess this is the most frequent mask/unmask operation.

On the other side, if a driver calls enable_irq() on one CPU and then enable_irq() on the other CPU, that's exactly what will happen. Although the smp_affinity setting will prevent an interrupt from being dispatched to more than one CPU.

I really don't see an issue with this patch, but I think it needs as much discussion and as much testing as possible. This piece of code is rather critical, and is working just fine, so I'd like to have an excellent reason before changing any of it.

The irqchip driver called armada_xp_mpic_smp_cpu_init() when CONFIG_SMP=Y to initialize some per cpu registers. The function is called on each CPU by calling it explicitly on the boot CPU and then using a CPU notifier for the non boot CPUs.

This commit removes the CONFIG_SMP constrain, so the per cpu registers are also initialized when CONFIG_SMP=N, which is the right thing to do.

Signed-off-by Ezequiel Garcia <[email protected]>

---
 drivers/irqchip/irq-armada-370-xp.c | 47 ++++++++++++++++++-------------------
 1 file changed, 23 insertions(+), 24 deletions(-)

drivers/irqchip/irq-armada-370-xp.c +23 -24

index af4e307..de5eb26 100644
@@ -285,28 +285,6 @@ static int armada_370_xp_mpic_irq_map(struct irq_domain *h,
 	return 0;
 }
 
-#ifdef CONFIG_SMP
-static void armada_mpic_send_doorbell(const struct cpumask *mask,
-				      unsigned int irq)
-{
-	int cpu;
-	unsigned long map = 0;
-
-	/* Convert our logical CPU mask into a physical one. */
-	for_each_cpu(cpu, mask)
-		map |= 1 << cpu_logical_map(cpu);
-
-	/*
-	 * Ensure that stores to Normal memory are visible to the
-	 * other CPUs before issuing the IPI.
-	 */
-	dsb();
-
-	/* submit softirq */
-	writel((map << 8) | irq, main_int_base +
-		ARMADA_370_XP_SW_TRIG_INT_OFFS);
-}
-
 static void armada_xp_mpic_smp_cpu_init(void)
 {
 	u32 control;

@@ -329,6 +307,28 @@ static void armada_xp_mpic_smp_cpu_init(void)
 	writel(0, per_cpu_int_base + ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
 }
 
+#ifdef CONFIG_SMP
+static void armada_mpic_send_doorbell(const struct cpumask *mask,
+				      unsigned int irq)
+{
+	int cpu;
+	unsigned long map = 0;
+
+	/* Convert our logical CPU mask into a physical one. */
+	for_each_cpu(cpu, mask)
+		map |= 1 << cpu_logical_map(cpu);
+
+	/*
+	 * Ensure that stores to Normal memory are visible to the
+	 * other CPUs before issuing the IPI.
+	 */
+	dsb();
+
+	/* submit softirq */
+	writel((map << 8) | irq, main_int_base +
+		ARMADA_370_XP_SW_TRIG_INT_OFFS);
+}
+
 static int armada_xp_mpic_secondary_init(struct notifier_block *nfb,
 					 unsigned long action, void *hcpu)
 {

@@ -492,9 +492,8 @@ static int __init armada_370_xp_mpic_of_init(struct device_node *node,
 
 	BUG_ON(!armada_370_xp_mpic_domain);
 
-#ifdef CONFIG_SMP
+	/* Setup for the boot CPU */
 	armada_xp_mpic_smp_cpu_init();
-#endif
 
 	armada_370_xp_msi_init(node, main_int_res.start);
 

This commit introduces a helper function is_percpu_irq(), to be used when interrupts are mapped to decide which ones are set as per CPU.

This change will allow to extend the list of per cpu interrupts in a less intrusive fashion; also, it makes the code slightly more readable by keeping a list of the per CPU interrupts.

Signed-off-by Ezequiel Garcia <[email protected]>

---
 drivers/irqchip/irq-armada-370-xp.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

drivers/irqchip/irq-armada-370-xp.c +11 -1

index de5eb26..3871c688 100644
@@ -73,6 +73,16 @@ static DEFINE_MUTEX(msi_used_lock);
 static phys_addr_t msi_doorbell_addr;
 #endif
 
+static inline bool is_percpu_irq(irq_hw_number_t irq)
+{
+	switch (irq) {
+	case ARMADA_370_XP_TIMER0_PER_CPU_IRQ:
+		return true;
+	default:
+		return false;
+	}
+}
+
 static void armada_370_xp_irq_mask(struct irq_data *d)
 {
 	irq_hw_number_t hwirq = irqd_to_hwirq(d);

@@ -271,7 +281,7 @@ static int armada_370_xp_mpic_irq_map(struct irq_domain *h,
 
 	irq_set_status_flags(virq, IRQ_LEVEL);
 
-	if (hw == ARMADA_370_XP_TIMER0_PER_CPU_IRQ) {
+	if (is_percpu_irq(hw)) {
 		irq_set_percpu_devid(virq);
 		irq_set_chip_and_handler(virq, &armada_370_xp_irq_chip,
 					handle_percpu_devid_irq);

Signature · 7 lines

2.1.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Hi,

Quoted 3 lines · Ezequiel Garcia

This commit introduces a helper function is_percpu_irq(), to be used when interrupts are mapped to decide which ones are set as per CPU.

Quoted 3 lines

This change will allow to extend the list of per cpu interrupts in a less intrusive fashion; also, it makes the code slightly more readable by keeping a list of the per CPU interrupts.

I believe you can use the existing (and similarly named) irq_is_percpu for this.

The Armada 375 SoC has a Cortex-A9 CPU, and so the PMU is available to be used. This commit enables it in the devicetree.

Signed-off-by Ezequiel Garcia <[email protected]>

---
 arch/arm/boot/dts/armada-375.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

arch/arm/boot/dts/armada-375.dtsi +0 -0

index de65714..f131cd2 100644

arch/arm/boot/dts/armada-375.dtsi +1 -0

+
 	soc {
 		compatible = "marvell,armada375-mbus", "marvell,armada370-mbus", "simple-bus";
 		#address-cells = <2>;

Signature · 7 lines

2.1.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 13 lines · Ezequiel Garcia

The Armada 375 SoC has a Cortex-A9 CPU, and so the PMU is available to be used. This commit enables it in the devicetree.

Signed-off-by Ezequiel Garcia <[email protected]>

---
 arch/arm/boot/dts/armada-375.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

arch/arm/boot/dts/armada-375.dtsi +0 -0

index de65714..f131cd2 100644

arch/arm/boot/dts/armada-375.dtsi line 61

Quoted 7 lines

arch/arm/boot/dts/armada-375.dtsi +4 -0

@@ -55,6 +55,11 @@
 		};
 	};
 
+	pmu {
+		compatible = "arm,cortex-a9-pmu";
+		interrupts-extended = <&mpic 3>;
+	};

Just to check - the interrupts from both CPUs are muxed into a single line into the interrupt controller?

This isn't gonig to work at the moment -- the perf code will associate this interrupt with CPU0 and you'll lose events on CPU1.

Hopefully there's a separate interrupt for CPU1?

The <mpic 3> is a per CPU interrupt.

Actually, the interrupt contains more than just PMU events, it contains a summary of several CPU events: Perf counters for each CPU, Power management interrupts for each CPU, L2 cache interrupt, among others.

Dear Ezequiel Garcia,

Quoted 2 lines · Ezequiel Garcia

The <mpic 3> is a per CPU interrupt.

Quoted 3 lines

Actually, the interrupt contains more than just PMU events, it contains a summary of several CPU events: Perf counters for each CPU, Power management interrupts for each CPU, L2 cache interrupt, among others.

This is kind of a side discussion but if this <mpic 3> interrupts does much more than PMU events, then we should implement a separate irqchip driver for this, to "demultiplex" the events notified by this interrupt.

Yes, today we are only using the PMU events from <mpic 3>, but what if tomorrow we need to be notified of other events in other drivers? We would be screwed, because we would have to change the DT
representation: the PMU would no longer take <&mpic 3> as the interrupt, but <&some_other_irq_controller XYZ> as the interrupt.

Quoted 8 lines · Ezequiel Garcia

Quoted 6 lines

The <mpic 3> is a per CPU interrupt.

Actually, the interrupt contains more than just PMU events, it contains a summary of several CPU events: Perf counters for each CPU, Power management interrupts for each CPU, L2 cache interrupt, among others.

Quoted 3 lines

This is kind of a side discussion but if this <mpic 3> interrupts does much more than PMU events, then we should implement a separate irqchip driver for this, to "demultiplex" the events notified by this interrupt.

Oh, I didn't realize this was possible.

Dear Ezequiel Garcia,

Quoted 12 lines · Ezequiel Garcia

Quoted 11 lines · Ezequiel Garcia

Quoted 6 lines

The <mpic 3> is a per CPU interrupt.

Actually, the interrupt contains more than just PMU events, it contains a summary of several CPU events: Perf counters for each CPU, Power management interrupts for each CPU, L2 cache interrupt, among others.

This is kind of a side discussion but if this <mpic 3> interrupts does much more than PMU events, then we should implement a separate irqchip driver for this, to "demultiplex" the events notified by this interrupt.

Quoted 1 line

Oh, I didn't realize this was possible.

The only trick is that it can't be a separate DT node, because the registers that contains the mask/cause informations for the events notified by <mpic 3> belongs to the MPIC registers area.

Dear Ezequiel Garcia,

Quoted 12 lines · Ezequiel Garcia

Quoted 11 lines · Ezequiel Garcia

Quoted 6 lines

The <mpic 3> is a per CPU interrupt.

Actually, the interrupt contains more than just PMU events, it contains a summary of several CPU events: Perf counters for each CPU, Power management interrupts for each CPU, L2 cache interrupt, among others.

This is kind of a side discussion but if this <mpic 3> interrupts does much more than PMU events, then we should implement a separate irqchip driver for this, to "demultiplex" the events notified by this interrupt.

Quoted 1 line

Oh, I didn't realize this was possible.

The only trick is that it can't be a separate DT node, because the registers that contains the mask/cause informations for the events notified by <mpic 3> belongs to the MPIC registers area.

Not sure how to handle that, maybe Mark will have some suggestions.

Quoted 18 lines · Thomas Petazzoni

Dear Ezequiel Garcia,

Quoted 13 lines · Ezequiel Garcia

Quoted 11 lines · Ezequiel Garcia

Quoted 6 lines

The <mpic 3> is a per CPU interrupt.

Actually, the interrupt contains more than just PMU events, it contains a summary of several CPU events: Perf counters for each CPU, Power management interrupts for each CPU, L2 cache interrupt, among others.

This is kind of a side discussion but if this <mpic 3> interrupts does much more than PMU events, then we should implement a separate irqchip driver for this, to "demultiplex" the events notified by this interrupt.

Oh, I didn't realize this was possible.

Quoted 5 lines

The only trick is that it can't be a separate DT node, because the registers that contains the mask/cause informations for the events notified by <mpic 3> belongs to the MPIC registers area.

Not sure how to handle that, maybe Mark will have some suggestions.

I'm not sure I follow why you would need a separate irqchip driver. Why can't this live in the existing mpic driver?

Hi Mark,

Thanks for the reply. You made me research and test this in depth :)

Quoted 25 lines · Mark Rutland

Quoted 13 lines · Ezequiel Garcia

The Armada 375 SoC has a Cortex-A9 CPU, and so the PMU is available to be used. This commit enables it in the devicetree.

Signed-off-by Ezequiel Garcia <[email protected]>

---
 arch/arm/boot/dts/armada-375.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

arch/arm/boot/dts/armada-375.dtsi +0 -0

index de65714..f131cd2 100644

arch/arm/boot/dts/armada-375.dtsi line 61

Quoted 7 lines

arch/arm/boot/dts/armada-375.dtsi +4 -0

@@ -55,6 +55,11 @@
 		};
 	};
 
+	pmu {
+		compatible = "arm,cortex-a9-pmu";
+		interrupts-extended = <&mpic 3>;
+	};

Just to check - the interrupts from both CPUs are muxed into a single line into the interrupt controller?

Quoted 5 lines

This isn't gonig to work at the moment -- the perf code will associate this interrupt with CPU0 and you'll lose events on CPU1.

Hopefully there's a separate interrupt for CPU1?

The <mpic 3> is a per CPU interrupt.

Actually, the interrupt contains more than just PMU events, it contains a summary of several CPU events: Perf counters for each CPU, Power management interrupts for each CPU, L2 cache interrupt, among others.

The interrupt cause can be read from a banked register called "CPU subsystem local cause". Conversely, each of these must be enabled from another (banked) register.

As far as I understand, this works (or should work) because the irqchip driver enables *just* the perf counter interrupt for the running CPU in the armada_xp_mpic_secondary_init(). Then, the ARM perf code requests the interrupt as per cpu and things just work, right?

However:

1) In the Armada 375 SoC case, the MPIC is chained and the code does not register the cpu notifier, so armada_xp_mpic_secondary_init is not called on CPU1.

2) Even when ensuring armada_xp_mpic_secondary_init is called on each CPU, and thus each perf counter interrupt is enabled, I can't see the PMU interrupt for CPU1, but just the one for the boot CPU.

I'll check with the hardware designer about this.

The Armada 380 and 385 SoCs have a Cortex-A9 CPU, so the PMU is available to be used. This commit enables it in the devicetree.

Signed-off-by Ezequiel Garcia <[email protected]>

---
 arch/arm/boot/dts/armada-38x.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

arch/arm/boot/dts/armada-38x.dtsi +0 -0

index 242d0ec..bba3c90 100644

Quoted 16 lines · Ezequiel Garcia

The Armada 380 and 385 SoCs have a Cortex-A9 CPU, so the PMU is available to be used. This commit enables it in the devicetree.

Signed-off-by Ezequiel Garcia <[email protected]>

---
 arch/arm/boot/dts/armada-38x.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

arch/arm/boot/dts/armada-38x.dtsi +0 -0

index 242d0ec..bba3c90 100644
@@ -30,6 +30,11 @@
 		eth2 = &eth2;
 	};
 

arch/arm/boot/dts/armada-38x.dtsi line 36

Quoted 4 lines

arch/arm/boot/dts/armada-38x.dtsi +4 -0

+	pmu {
+		compatible = "arm,cortex-a9-pmu";
+		interrupts-extended = <&mpic 3>;
+	};

Is there not a separate interrupt for CPU1 on Armada 385?

Now that Armada 375/38x have support for the PMU, this commit enables perf events in the defconfig.

Signed-off-by Ezequiel Garcia <[email protected]>

---
 arch/arm/configs/mvebu_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

arch/arm/configs/mvebu_v7_defconfig +0 -0

index ed0a0d1..d1a4669 100644

arch/arm/configs/mvebu_v7_defconfig +0 -0

 CONFIG_SLAB=y
 CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y

Signature · 7 lines

2.1.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 8 lines · Ezequiel Garcia

Now that Armada 375/38x have support for the PMU, this commit enables perf events in the defconfig.

Signed-off-by Ezequiel Garcia <[email protected]>

---
 arch/arm/configs/mvebu_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

arch/arm/configs/mvebu_v7_defconfig CONFIG_HIGH_RES_TIMERS=y · line 8

Quoted 9 lines

arch/arm/configs/mvebu_v7_defconfig +1 -0

index ed0a0d1..d1a4669 100644
@@ -5,6 +5,7 @@ CONFIG_HIGH_RES_TIMERS=y
 CONFIG_LOG_BUF_SHIFT=14
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_EXPERT=y
+CONFIG_PERF_EVENTS=y

Isn't this provided by CONFIG_ARM already?

Surely you want CONFIG_HW_PERF_EVENTS?

Quoted 4 lines

Quoted 1 line

+CONFIG_PERF_EVENTS=y

Isn't this provided by CONFIG_ARM already?

No, you need to select it explicitly, as the other platforms do.

This patchset enables support for perf hardware events, by enabling the PMU interrupts in the irqchip driver.

While doing this, we noticed the driver could use some cleaning to simplify the overly complex implementation of the .map(), .unmask() and .mask() functions.

The first three patches are the result of this cleaning effort, while the rest of the series is the Perf support for Armada 375 and Armada 38x SoCs.

The series is based on v3.18-rc1.

Ezequiel Garcia (7):
irqchip: armada-370-xp: Simplify interrupt map, mask and unmask
irqchip: armada-370-xp: Initialize per cpu registers when CONFIG_SMP=N
irqchip: armada-370-xp: Introduce a is_percpu_irq() helper for
readability
irqchip: armada-370-xp: Enable Performance Counter interrupts

ARM: mvebu: Enable Performance Monitor Unit on Armada 375 SoC
ARM: mvebu: Enable Performance Monitor Unit on Armada 380/385 SoC
ARM: mvebu: Enable perf support in mvebu_v7_defconfig

 arch/arm/boot/dts/armada-375.dtsi   |  5 ++
 arch/arm/boot/dts/armada-38x.dtsi   |  5 ++
 arch/arm/configs/mvebu_v7_defconfig |  1 +
 drivers/irqchip/irq-armada-370-xp.c | 95 ++++++++++++++++++-------------------
 4 files changed, 58 insertions(+), 48 deletions(-)

Signature · 1 line

2.1.0

Quoted 10 lines · Ezequiel Garcia

This patchset enables support for perf hardware events, by enabling the PMU interrupts in the irqchip driver.

While doing this, we noticed the driver could use some cleaning to simplify the overly complex implementation of the .map(), .unmask() and .mask() functions.

The first three patches are the result of this cleaning effort, while the rest of the series is the Perf support for Armada 375 and Armada 38x SoCs.

Quoted 8 lines

The series is based on v3.18-rc1.

Ezequiel Garcia (7):
irqchip: armada-370-xp: Simplify interrupt map, mask and unmask
irqchip: armada-370-xp: Initialize per cpu registers when CONFIG_SMP=N
irqchip: armada-370-xp: Introduce a is_percpu_irq() helper for
readability
irqchip: armada-370-xp: Enable Performance Counter interrupts

Patches 1 to 4 tentatively applied to irqchip/mvebu. Things have been quiet, so let's get it in next for some more test coverage.

Jason, Ezequiel,

Quoted 22 lines · Jason Cooper

Quoted 10 lines · Ezequiel Garcia

This patchset enables support for perf hardware events, by enabling the PMU interrupts in the irqchip driver.

While doing this, we noticed the driver could use some cleaning to simplify the overly complex implementation of the .map(), .unmask() and .mask() functions.

The first three patches are the result of this cleaning effort, while the rest of the series is the Perf support for Armada 375 and Armada 38x SoCs.

Quoted 8 lines

The series is based on v3.18-rc1.

Ezequiel Garcia (7):
irqchip: armada-370-xp: Simplify interrupt map, mask and unmask
irqchip: armada-370-xp: Initialize per cpu registers when CONFIG_SMP=N
irqchip: armada-370-xp: Introduce a is_percpu_irq() helper for
readability
irqchip: armada-370-xp: Enable Performance Counter interrupts

Patches 1 to 4 tentatively applied to irqchip/mvebu. Things have been quiet, so let's get it in next for some more test coverage.

Ezequiel, are these patches really the version we want to see merged? I think you're working on a different implementation that demultiplex the coherency fabric events interrupt.

Quoted 23 lines · Thomas Petazzoni

Jason, Ezequiel,

Quoted 20 lines · Jason Cooper

Quoted 18 lines · Ezequiel Garcia

This patchset enables support for perf hardware events, by enabling the PMU interrupts in the irqchip driver.

While doing this, we noticed the driver could use some cleaning to simplify the overly complex implementation of the .map(), .unmask() and .mask() functions.

The first three patches are the result of this cleaning effort, while the rest of the series is the Perf support for Armada 375 and Armada 38x SoCs.

The series is based on v3.18-rc1.

Ezequiel Garcia (7):
irqchip: armada-370-xp: Simplify interrupt map, mask and unmask
irqchip: armada-370-xp: Initialize per cpu registers when CONFIG_SMP=N
irqchip: armada-370-xp: Introduce a is_percpu_irq() helper for
readability
irqchip: armada-370-xp: Enable Performance Counter interrupts

Quoted 3 lines

Quoted 2 lines

Patches 1 to 4 tentatively applied to irqchip/mvebu. Things have been quiet, so let's get it in next for some more test coverage.

Jason, please consider *only* patch 1 for inclusion, as long as we have Gregory's Ack on it. I don't want to break the irqchip driver because of a clean-up! On the other side, if such weird handling is needed, we need find why and document it.

Quoted 24 lines · Ezequiel Garcia

Quoted 23 lines · Thomas Petazzoni

Jason, Ezequiel,

Quoted 20 lines · Jason Cooper

Quoted 18 lines · Ezequiel Garcia

This patchset enables support for perf hardware events, by enabling the PMU interrupts in the irqchip driver.

While doing this, we noticed the driver could use some cleaning to simplify the overly complex implementation of the .map(), .unmask() and .mask() functions.

The first three patches are the result of this cleaning effort, while the rest of the series is the Perf support for Armada 375 and Armada 38x SoCs.

The series is based on v3.18-rc1.

Ezequiel Garcia (7):
irqchip: armada-370-xp: Simplify interrupt map, mask and unmask
irqchip: armada-370-xp: Initialize per cpu registers when CONFIG_SMP=N
irqchip: armada-370-xp: Introduce a is_percpu_irq() helper for
readability
irqchip: armada-370-xp: Enable Performance Counter interrupts

Quoted 8 lines

Quoted 3 lines

Quoted 2 lines

Patches 1 to 4 tentatively applied to irqchip/mvebu. Things have been quiet, so let's get it in next for some more test coverage.

Jason, please consider *only* patch 1 for inclusion, as long as we have Gregory's Ack on it. I don't want to break the irqchip driver because of a clean-up! On the other side, if such weird handling is needed, we need find why and document it.

No sweat. I've now rolled irqchip/mvebu back to:

aaae00a7fa86 irqchip: armada-370-xp: Simplify interrupt map, mask and unmask

and an updated for-next is being build-tested and pushed hopefully before Stephen gets his cup of coffee. :)