Interrupt Handler

QNX Newsgroups (Archives) qnx.qnx4
1

Given an 2 interrupt handlers connected to the same IRQ.

Upon receiving the IRQ the first handler is called by the kernel and the IRQ
is cleared. Is the second handler guarantied to be called.

  • Mario
2

Mario Charest wrote:

Given an 2 interrupt handlers connected to the same IRQ.

Upon receiving the IRQ the first handler is called by the kernel and the IRQ
is cleared. Is the second handler guarantied to be called.

Essentially the algorithm is such:

On interrupt,
-stash some segments,
-save the irq number on the stack,
-fetch the pointer to the head of the registered
handlers list for that IRQ
-call “run handlers”
for (p=head ; p ; p=p->next) {
if (proxy = p->func()) {
push proxy onto event stack (for applying later)
}
}
…

So (long winded) yes, all the handlers are called for a particular
level, since there is no method for one ISR handler to report to the OS
that it had already handled the source of the IRQ for this particular
run. Not to mention it’s handy/required to be able to tell when an IRQ
fires regardless of if you’re going to handle the cause or not for some
applications.

Hope that helps.

–

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

3

Mario Charest wrote:

So (long winded) yes, all the handlers are called for a particular
level, since there is no method for one ISR handler to report to the OS
that it had already handled the source of the IRQ for this particular
run.


OS could look at IRQ signal on PIC?

Well putting in gear to do that type of checking would slow down a main
line code path which is supposed to be as small/fast as posible. I
would imagine that in a shared IRQ setup, checking to see if an IRQ is
pending still after running a handler which handled the last IRQ,
wouldn’t work well. Also, in a shared case, it seems like a
possible/likely that after executing the ISR for the first IRQ, and new
IRQ from another device could be now pending. Running all the handlers
for that level, would allow the handler for the new incomming IRQ to be
handled without having to take the exception path for a new entry into
the OS (kinda like a pre-emptive strike against pending IRQs :slight_smile: )

\

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

4

“Adam Mallory” <amallory@qnx.com> wrote in message
news:c7r465$cr2$1@inn.qnx.com…

Mario Charest wrote:
Given an 2 interrupt handlers connected to the same IRQ.


So (long winded) yes, all the handlers are called for a particular
level, since there is no method for one ISR handler to report to the OS
that it had already handled the source of the IRQ for this particular
run.

OS could look at IRQ signal on PIC?

Not to mention it’s handy/required to be able to tell when an IRQ
fires regardless of if you’re going to handle the cause or not for some
applications.

Indeed

Hope that helps.

Yes it does! Thanks Adam

–

Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net