Dear Members,

I'm writing a linux device driver (RHEL 5.8) for a DIO card. It has 16 channels. On each channel when the input goas from '1' to '0' (TTL) an interrupt is created.

Accoding to /proc/interrutps, the IRQ is shared with other USB devices.

Is it possible to avoid it ?

My ISR handler is:

/**********************************************************************/
static irqreturn_t irq_handler (int irq, void *data)
{
short status;

status = ioread16 ((void*)(virtual_bar0_base_s+0x1A));
if (status !=0)
iowrite16 (status,(void*)(virtual_bar0_base_s+0x1A));

return IRQ_HANDLED;
}

/**********************************************************************/
0x1A is the interrupt status register. If an interrupt from the DIO is pending, the relevant bit (according to channel) is '1'.

0x1A is also the clear register.

In case of an interrupt I must write the status to the clear register.

Is it possible that this ISR is called also upon an interrupt caused by USB device ?

I noticed that when interrupts are enabled in the DIO, USB devices works very slow.

Thanks,
Zvika

On the x86 architecture, at least, there are "not nearly enough" IRQs out there, so all of them are quite-heavily shared.

Thank you for your reply.

In case of a shared interrupt (e.g USB device and my device) is it possible that a USB event will cause O.S to call my handler ?

Is it possible that an event in my card will cause O.S to call the USB ISR handlers ?

Should I check it in my handler and return IRQ_NONE ?

Thanks,
Zvika

"The cardinal rule of interrupt handlers," in any operating system, is that an interrupt serves only to notify (the "first-level handler" layer of your code ...) that something has just happened that might, or might not, be of interest to you.

You have to examine the status-flags presented by your device to see if it's the one that's ringing. If it is your device, then you squash the interrupt ("whack the alarm clock so that it stops ringing ...") and schedule what is supposed to happen next. Then, get out of there, letting the operating system know that the interrupt was "handled" by you.

But if it is not your device, you simply exit and let the operating-system call the next first-level handler that it may have in its list for that IRQ.

The majority of the actual work of your driver happens at the "second-level handler," which is what you scheduled. It is executed "promptly," but not immediately, by the dispatcher ... and at that point, interrupts are enabled again.

"Use the Source, Luke!" There are literally hundreds of device drivers out there, and one of them has got to be "sufficiently close to whatever-it-is that you are trying to do here" that you can basically steal from it. (Just be sure that the example that you're looking at is recent, and that it corresponds to your particular kernel-version/distro, since the low-level "plumbing" at this level of Linux has evolved over these many years.)

2 members found this post helpful.