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

[randy rodes]

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.


On Thu, Apr 18, 2013 at 8:38 AM, <hken...@gmail.com> wrote:
> Hi,
>
> I'm trying to make linux 3.8 run on a Beaglebone, but I'm facing problems
> with high interrupt latency when using GPIO as interrupt source. I've
> extended the GPIO/UIO drivers (mostly gpiolib.c) with a feature that makes
> it possible to via sysfs configure which GPIO-pin(s) that should generate
> interrupt. This, in turn, could be used to trigger an "interrupt" on a
> /dev/uioX as usuall in the UIO driver.
>
> Attached are patches for the code. I started on plain 3.8.4, added the
> patches found on git://github.com/beagleboard/kernel.git, branch
> remotes/origin/3.8 and then applied the attached patches.
>
> These patches add the feature:
>
> 0001-First-gpio......patch
> 0002--Cleanup......patch
>
> 0001-Testcode.....patch is a patch that toggles another gpio, just to be
> able to measure the interrupt latency on an oscilloscope.
>
> So what I later do is to set a GPIO as irq source (gpio 60 in the example
> below) and trigger an interrupt with another GPIO (48 in the example below)
> and the I can meassure the latency between GPIO60 (or 48) and GPIO 38.
>
> A jumper must be put between P9:12 and P9:15 on the BeagleBone when
> measuirng latency. (GPIO pin to generate a signal, and GPIO pin to generate
> irq)
>
> What I do on command line:
>
> cd /sys/class/gpio_uio_irq/
> echo "60 IRQ_TYPE_EDGE_RISING" > allocate_gpio_uio_irq
> cd ../gpio
> echo 48 > export
> cd gpio48/
> echo out > direction
> echo 1 > value ; echo 0 > value
>
> If I do this on a 3.2 kernel + TexasInstrument's SDK 05.07.00.00, I get app.
> 15-20 us latency, which is pretty much what I expect, according to TI's
> documentation.
>
> But if I do it on the sw level descibed above, 3.8.4 +
> "git://github.com/beagleboard/kernel.git, branch remotes/origin/3.8" I get
> between 400 us and 2 ms, which is way too much. I use the kernel config for
> Beaglebone "as is" in the git://github.com/beagleboard/kernel.git repo.
>
> Does anyone recognize this behaviour, when it comes to large interrupt
> latency ? It would be interesting to measure latency in general, not only
> for GPIO, but on the other hand, using GPIO as irq source in 3.2 + ...
> worked fine, so I don't see any obvoius reason why it should not work on 3.8
> + ...
>
> GPIO 60 is pin 12 on P9
> GPIO 48 is pin 15 on P9
> GPIO 38 is pin 3 on P8 (GPIO 38 is used as "measuring pin" in the testpatch)
>
> br Håkan Engblom
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[hken...@gmail.com]

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.

[randy rodes]

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.


>
> br Håkan E.

[hken...@gmail.com]

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.

[hken...@gmail.com]

Hi,

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

br Håkan E.

[Hiremath, Vaibhav]

Better you take below patch –

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

 

 

Thanks,

Vaibhav

--

[håkan engblom]

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.

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/vvnkMSZEqjQ/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.