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?