xeno-gpio-xilinx causes gpio-xilinx's IRQ callback(xgpio_irqhandler) to trigger rather than gpio-core's "gpio_pin_interrupt"
greg at embeddedgreg.com
Tue Jul 14 00:43:35 CEST 2020
On Mon., Jul. 13, 2020, 6:37 p.m. Josh Karch via Xenomai <
xenomai at xenomai.org> wrote:
> With the CAN bus issues resolved, I now have a situation where the
> xeno-gpio-xilinx driver (gpio-core.c) causes a complete system lockup when
> IRQs are enabled and a GPIO toggle triggers the IRQ event.
> Here's what I know: I instrumented the NRT driver to see how deeply
> entrenched and intertwined the real-time and non real-time drivers are:
> (1) xeno-gpio-xilinx calls gpio-core which piggybacks upon the Xilinx
> "gpio-xilinx" driver.
> (2)It uses the OF scan information to create /dev/rtdm/gpio at address/gpioxxx
> driver pins.
> When enabling interrupts:
> (1)It uses the NRT "Xgpio-request" function to request a gpio pin and set
> the pin to an input, though for some reason it calls the set gpio as input
> function twice
> (2) It then calls xgpio-toirq twice for some reason
> (3) It sets the IRQ type. Only the rising edge IRQ is supported with the
> Xilinx Driver
> (4) It uses the unmask function in the non RT driver to unmask the IRQ
> (5) It then sets the gpio as input again. I think this is a side effect of
> calling the IOCTL to enable IRQ and then to block file descriptors on
> (6) Once the interrupt is triggered, on occasion the Non realtime
> xgpio_irqhandler gets called rather than the gpio_pin_interrupt function.
> This makes me think the NRT driver is not properly setting the interrupt up
> to work with the Xenomai handler. Once the non realtime xgpio_irqhandler
> gets called the code gets stuck in an infinite loop and crashes.
> Sometimes the system freezes before using the handler, other times it runs
> the handler but it's not possible to break.
> The following is a transcript of a time when the nrt handler is not
> called. Otherwise you'd see a message when IRQ is triggered that the
> system continually is in a nrt IRQ handler loop.
> So the question is: why is the non-rt handler being called and not the
> gpio-core rt_gpio "gpio-pin-interrupt"?
> [ 303.900487] requesting GPIO
> [ 303.903419] setting gpio 0 as input
> [ 303.907004] setting gpio 0 as input
> [ 303.910549] called xgpio to irq
> [ 303.913768] called xgpio to irq
> [ 303.916913] setting irq type 1
> [ 303.919990] unmasking IRQ
> [ 303.922600] setting gpio 0 as input
> [ 324.917162] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
> [ 324.923100] rcu: 0-...0: (1 ticks this GP)
> softirq=8388/8389 fqs=2247
> [ 324.932321] rcu: (detected by 3, t=5252 jiffies, g=12713, q=188)
> [ 324.938411] Task dump for CPU 0:
> [ 324.941629] xeno_gpio_teste R running task 0 433 388
> [ 324.948682] Call trace:
> [ 324.951126] __switch_to+0x94/0xf0
> [ 324.954522] 0xffffff8008dea658
> Josh Karch
Do you have have the gic and the IRQ handlers in place for the xilinx-gpio
xenomai driver? The current implementation doesn't support interrupts.
More information about the Xenomai