I have a custom kernel module that coordinates SPI communication with an external part via a GPIO pin that is pulled low by the external part when events happen. The module was working fine on my previous Beaglebone White with a 3.2 kernel (also from rcn-ee.net). However, on the BBB with rcn-ee.net’s 3.8.12-bone17 kernel, the latency for the kernel to fire the interrupt handler for the GPIO interrupt is very erratic and generally much much higher than on the previous setup. This seems to be quite akin to the problem described on this list a couple of days ago, here: https://groups.google.com/forum/?fromgroups=#!category-topic/beagleboard/beaglebone-black/mmilk1ms7eA
However, I’m seeing the problem in kernel space too, not in user space, as in the linked post. I’m setting up the IRQ in a straight-forward way, using request_irq() with IRQF_TRIGGER_FALLING and gpio_to_irq() to obtain the IRQ. I’m seeing this on GPIO3_19, but I’ve tried a couple of other pins too, with the same behavior. I’m setting the pinmux to GPIO mode, pullup selected & enabled, input enabled and “fast slewrate” via ioremap() before requesting the IRQ.
I’m not sure where to go from here. Has there been a deliberate change that affects the latency of GPIO interrupts as a side-effect in newer kernel versions, or is this an unintended effect? As far as I know, the CPU on the BBB is just a faster version of the CPU on the BB, so this must be a problem with newer kernel releases, rather than the hardware?
Anyway, I’m putting this out here in the hope that someone more knowledgable about the low-level hardware could maybe chime in and point me towards the right track?
I just wanted to update this with the (trivial) solution I found: Simply switch to the “performance” CPU governor (e.g. cpufreq-set -c 0 -g performance) – With the default governor, the BBB switches to 300MHz if there is no load, but running at 1000MHz cuts the GPIO interrupt response time down significantly (more than twice as fast). This fixes the issue for me.
I wrote a kernel module to verify this (will upload to github soon) by setting one GPIO pin as an interrupt pin and using another one to trigger interrupts: at 300MHz, in-kernel latency (e.g. time between triggering the interrupt and the IRQ handler being called) is about 20-40usec, at 1000GHz it’s in the range of 10usec, most often significantly below that.
Randy, thanks for the tip, but apparently it’s not the case for the cpufreq governor, as interrupt latency doesn’t improve even after thousands of test runs. The only way to reduce it to force the board to run at its max. frequency.
I’ve added some results to the README in the github repo, too: The most important bits to take from it are that the Raspberry Pi at 700MHz has the lowest IRQ latency, followed by the BBB running at 1GHz. This seems to be a kernel issue, mostly, even though the BBB’s latency is good enough for my purposes. Also, latency on the older BB kernels (3.2.x) seems to be quite erratic.