We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Showing results for 
Search instead for 
Did you mean: 
Observer bencai
Registered: ‎05-12-2014

UIO Interrupt handling - max unread interrupts?

It appears UIO limits to 2 maximum "unread" interrupts.

The interrupt counter (cat /proc/interrupt) stops counting after the 2nd interrupt fired without being read. My interrupts are configured as edge trigger and there is no need to clear any flags.

This doesn’t seem to add up for me, perhaps someone could advise?



0 Kudos
2 Replies
Xilinx Employee
Xilinx Employee
Registered: ‎09-10-2008

Re: UIO Interrupt handling - max unread interrupts?



Are you using the uio_pdrv_genirq driver (using generic-uio as the compatible property on your device in the device tree)?


The interrupt handling and that counting has not been crystal clear to me in my UIO work and I never went deeper to completely understand it. So this is more of a conversation for both of us to understand it better.


From http://lxr.free-electrons.com/source/drivers/uio/uio_pdrv_genirq.c


63 static irqreturn_t uio_pdrv_genirq_handler(int irq, struct uio_info *dev_info)
64 {
65 struct uio_pdrv_genirq_platdata *priv = dev_info->priv;
67 /* Just disable the interrupt in the interrupt controller, and
68 * remember the state so we can allow user space to enable it later.
69 */
71 spin_lock(&priv->lock);
72 if (!__test_and_set_bit(UIO_IRQ_DISABLED, &priv->flags))
73 disable_irq_nosync(irq);
74 spin_unlock(&priv->lock);
76 return IRQ_HANDLED;
77 }


You can see that it disables the interrupt at the interrupt controller level until user space re-enables it by writing to the file.


186 /* This driver requires no hardware specific kernel code to handle
187 * interrupts. Instead, the interrupt handler simply disables the
188 * interrupt in the interrupt controller. User space is responsible
189 * for performing hardware specific acknowledge and re-enabling of
190 * the interrupt in the interrupt controller.
191 *
192 * Interrupt sharing is not supported.
193 */


I have sort of viewed it as this method with no kernel module is the easy path, but if you want complete control over things then a small kernel driver together with user space (the original UIO design before the variations of it) allows you to have more interrrupt control over the device, but others may have different thoughts.




0 Kudos
Observer bencai
Registered: ‎05-12-2014

Re: UIO Interrupt handling - max unread interrupts?

Thanks John.
Agree, interrupt handling from user space is not as effective as it was done from Kernel space.

I can see one potential issue with the way interrupt is handled by the UIO driver (for me - edge triggered interrupt), is Linux’s context switching may occur right after the interrupt is disabled, this will cause subsequent interrupts to be ignored.

The purpose of the interrupt counter is to provide an indication of missed handled interrupts, so I expect the counter for the interrupt should be incrementing regardless if the interrupt was handled or not (unless it got disabled as result of improper handling.)
0 Kudos