CODEWITHSUNDEEP
linux-kernellinux-device-driverdriversinterrupt-handling
TheLoneJoker
TheLoneJoker

Reputation: 1629

Linux device driver - Threaded IRQ handler

Recently, I ran into a situation where I would like to use threaded IRQ's for a Keypad driver. For some background on threaded IRQ handlers:

http://lwn.net/Articles/302043/

From what I understand, every time an IRQ would occur the IRQ handler thread would be woken up. So, if i press KEY A, it wakes up the thread and it runs through to completion. Now, what would be the behavior should i press KEY B, when the handler thread is still running while servicing the IRQ from KEY A... Would the IRQ from KEY B be ignored ?

What would be the expected behavior ?

Upvotes: 3

Views: 7185

Answers (2)

Martin
Martin

Reputation: 3602

The way it works with interrupts is that processor will call an enabled interrupt over and over again until application clears the corresponding interrupt flag. So what you do is disable that particular interrupt in the hardware handler and wake up your thread. When hardware handler exits, interrupt flags will be set but the interrupt will not be called again. So you then in your thread checkeach flag and clear it as you go. When you detect that a flag for a keypress is set, you read out the key and then clear it. If a new key is pressed after you read data register and there is no fifo in hardware then that key press will be lost. You then clear the interrupt flag and enable the hardware interrupt again. The idea is that this process happens so fast that there is no way to lose a key because your thread will always run sooner than human can press another key.

In the situation such as usb (ie if you write a usb driver that communicates with pc) you have the option to tell usb peripheral when you are done reading data so it can tell the host it can accept more data. In that situation you can never lose data because you will read data out and clear the flag and only then tell the peripheral that you are ready. All the time until then the peripheral will tell the host that it is not ready so no data will be clocked in over the usb bus.

Upvotes: 0

Chamila Chulatunga
Chamila Chulatunga

Reputation: 4914

Ideally the system would always acknowledge the sequence of Key A->Key B.

However to acknowledge that a key was pressed, the system must do something at the point at which each key is pressed, I.e. when the keyboard interrupt occurs - at a minimum it must record the key presses, perhaps in a queue.

And from the perspective of a single processor, it can only do one thing at a time, so if it is in the middle of recording key press A, then it can't at the same time record key press B. It would either have to abandon A and record B instead, or it would have to ignore B.

Thus the goal of interrupt handling is to minimise the amount of time the processor spends doing the minimum it needs to for acknowledging any given interrupt.

The goal of threaded interrupts is to push more of the work to separate threads, so that the minimum needed for acknowledging an interrupt is reduced, and therefore the time spent handling the interrupt (where it can't handle any other interrupts at the same time) is reduced.

Even then there is still no theoretical guarantee that the processor won't have to discard or ignore interrupts, but it does make it a lot less likely in practice.

For your specific example of key presses, if you were somehow able to be quick enough to press B before the processor had completed its minimum handling of A, then since both interrupts are from the same source, and therefore have the same priority, B would be ignored, and it would appear to you as if B was never pressed.

Upvotes: 4

Related Questions