Forums » Software Development »
High Latency for GPIO Interrupts in 3.2 Kernel
Added by Michael Karasoff over 11 years ago
Just switched over to the 3.2 Kernel from 3.1 to support programming of the 512MB flash, and the latency for a GPIO Interrupt has gone through the roof - from ~20usec on 3.1 to >400usec on 3.2. Kind of odd: 3.2 the interrupt tends to get handled quicker if I start to load the processor. I've run LMBench on both kernels, and that shows the performance between the two to be equivalent - the performance problem seems isolated to GPIO interrupt.
Does anyone know why or have an idea why this is the case and how I may get performance back to 3.1 levels?
In both 3.1 and 3.2 I'm using the same code for this GPIO interrupt handler, as described in the "IRQ handling" section: http://processors.wiki.ti.com/index.php/GPIO_Driver_Guide
Thanks,
Mike
Replies (13)
RE: High Latency for GPIO Interrupts in 3.2 Kernel - Added by Michael Williamson over 11 years ago
Are you handling the interrupts in a kernel module or via the gpio sysfs file hooks?
RE: High Latency for GPIO Interrupts in 3.2 Kernel - Added by Michael Karasoff over 11 years ago
Kernel Module.
RE: High Latency for GPIO Interrupts in 3.2 Kernel - Added by Michael Karasoff over 11 years ago
The GPIO interrupt is on GPIO bank 0. Is there any chance that there is power management being applied to the GPIO or the GPIO 0 bank clock (clk_rc32k_ck) has changed? The fact that the latency goes down when I load the processor is awfully suspicious.
The interrupt period is 2msec.
Thanks.
RE: High Latency for GPIO Interrupts in 3.2 Kernel - Added by Michael Karasoff over 11 years ago
This is a bug in the kernel. Lines 215-219 of the file arch/arm/mach-omap2/irq.c should be modified:
215c215 < #ifdef CONFIG_SOC_OMAPTI816X --- > //#ifdef CONFIG_SOC_OMAPTI816X 219c219 < #endif --- > //#endif
RE: High Latency for GPIO Interrupts in 3.2 Kernel - Added by Michael Williamson over 11 years ago
Thanks Michael,
We'll get it applied in the local tree (which came from TI, really).
Sorry for the inconvenience.
-Mike
RE: High Latency for GPIO Interrupts in 3.2 Kernel - Added by Jonathan Cormier over 10 years ago
Hi Michael,
I'm trying to understand what your patch effects. Do you know what the 0xf8 register refers to? I've searched through the TRM and the datasheet so far but haven't found anything obvious.
#ifdef CONFIG_SOC_OMAPTI816X
if (irqnr)
goto out;
irqnr = readl_relaxed(base_addr + 0xf8);
#endif
RE: High Latency for GPIO Interrupts in 3.2 Kernel - Added by Jonathan Cormier over 10 years ago
Okay found the register in the 335x TRM:
6.5.1.42 INTC_PENDING_IRQ3 Register (offset = F8h)
RE: High Latency for GPIO Interrupts in 3.2 Kernel - Added by Michael Karasoff over 10 years ago
Yes that is it.
I've been running the kernel with this change for quite a while, and haven't seen any issues.
RE: High Latency for GPIO Interrupts in 3.2 Kernel - Added by Jonathan Cormier over 10 years ago
Okay thanks for the feedback. I'm planning on committing the following patch which should have the same effect.
Proposed patch:
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 1fef061..419b1a1 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -212,7 +212,7 @@ static inline void omap_intc_handle_irq(void __iomem *base_a
goto out;
irqnr = readl_relaxed(base_addr + 0xd8);
-#ifdef CONFIG_SOC_OMAPTI816X
+#if defined(CONFIG_SOC_OMAPTI816X) || defined(CONFIG_SOC_OMAPAM33XX)
if (irqnr)
goto out;
irqnr = readl_relaxed(base_addr + 0xf8);
It would be appreciated if you could test this before I push it. With my luck its the small changes that couldn't possibly break that always get me.
RE: High Latency for GPIO Interrupts in 3.2 Kernel - Added by Michael Karasoff over 10 years ago
Thanks. I'll make the change and let you know in a day or two how this works for me.
RE: High Latency for GPIO Interrupts in 3.2 Kernel - Added by Jonathan Cormier over 10 years ago
Hi Michael,
Did you get a chance to check this out?
RE: High Latency for GPIO Interrupts in 3.2 Kernel - Added by Michael Karasoff over 10 years ago
Yes, it is working.
Thanks.
