[beagleboard] Long interrupt latency when using GPIO as irq source

GoogleGroups
1

In the past on another processor, i have seen sometimes disabling
power management has a very good impact on reducing the latency.
What i did was:
a) to disable cpu-idle - not to allow system to go to lower c states
b) operate at highest operating frequency by using ondemand or
performance governor - to eliminate voltage scaling etc.

I have not done it on AM processor, but these are generic enough
concepts to surely have an impact.

2

Hi Randy,

Yes, that could possibly be one explaination. However I’m already running the performance governor. I also tried to take away all possibility to do any frequency scaling from the linux config, still same result…
Thanks anyway.

Has anyone else who has measured interrupt latency on BeagleBone runnign linux 3.8.x ?

br Håkan E.

3

Hi Randy,

Yes, that could possibly be one explaination. However I’m already running the performance governor. I also tried to take away all possibility to do any frequency scaling from the linux config, still same result…
Thanks anyway.

Has anyone else who has measured interrupt latency on BeagleBone runnign linux 3.8.x ?

Curious, any further progress you could make?

I have chosen 3.8 kernel so am concerned if this is some major issue in the kernel.

4

Hi Randy,

Yes I’ve found the root cause of this issue.

The problem is a missmatch in the kernel config, as I see it.

The problem is fixed with this patch:

diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 3926f37…57d1b7d 100644
— a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -233,7 +233,7 @@ static inline void omap_intc_handle_irq(void __iomem *base_addr, struct pt_regs
goto out;

irqnr = readl_relaxed(base_addr + 0xd8);
-#ifdef CONFIG_SOC_TI81XX
+#if defined(CONFIG_SOC_TI81XX) || defined(CONFIG_SOC_AM33XX)
if (irqnr)
goto out;
irqnr = readl_relaxed(base_addr + 0xf8);

The problem is that CONFIG_SOC_TI81XX is not set for beaglebone, and that causes some interrupts, the ones seen in register INTC_PENDING_IRQ3 (0xf8) not to be seen when the linux kernel asks the interrupt controller which interrupt that caused the interrupt.
In my system, that caused the GPIO interrupts not to be seen by the linux kernel other than “some interrupt occured” but it was not possible to determine which. What eventually made the GPIO interrupt “visable” was probably some other interrupt coming in, not sure about that though.

Anyway the above patch solves the problem, or setting CONFIG_SOC_TI81XX in the linux config, but I prefer the patch solution. I think this should be reported back to the maintainer(s), but I’m not sure who to contact. I’ll look into that. If somebody reads this and know who to contact please let me know.

BTW CONFIG_SOC_TI81XX is not set in the beaglebone linux config from git://github.com/beagleboard/kernel.git, so if this config is used “as is” the problem will be present.

br Håkan E.

5

Hi,

The fix for this problem is now in the git://github.com/beagleboard/kernel.git repo.

br Håkan E.

6

Better you take below patch –

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-May/098602.html

Thanks,

Vaibhav

7

Hi Vaibhav,

I checked the patch you suggested, and it seems to do more or less the same thing as my suggestion. Is there something else that makes the patch you suggest better ? I’m just curious to know what makes it better, I’m not questioning it.

/Håkan E.