Hello to all
A QNX 4 question about interrupts handling:
I want to ‘qnx_hint_attach()’ the same far routine to handle interrupts
from two or more devices on PCI bus, maybe assigned to different IRQs.
When my Handler gets called (by the kernel), I don’t know which IRQ has
generated the interrupt itself, because the Handler has no parameters.
I can easily clear the interrupt source on my device with a simple write
through PCI, but I need to know the IRQ# to find out WHICH device to
clear: reading ALL the Interrupt Status Registers of ALL my devices
would be too time-consuming…
Is there a qnx call to get this info or should I read some PIC register?
thanks, Davide
I think the simplest and cleanest way to get this info is to attach a
separate interrupt handler for each interrupt. This may seem cumbersome,
but in reality you’re not likely to have more than a few different
interrupts to handle. You can still have each handler call a common
function to perform whatever common code you need to handle each interrupt.
Regards,
Bert Menkveld
Engineer
Corman Technologies Inc.
“Davide Ancri” <davidea@prisma-eng.it> wrote in message
news:3C0B8C41.2040702@prisma-eng.it…
Hello to all
A QNX 4 question about interrupts handling:
I want to ‘qnx_hint_attach()’ the same far routine to handle interrupts
from two or more devices on PCI bus, maybe assigned to different IRQs.
When my Handler gets called (by the kernel), I don’t know which IRQ has
generated the interrupt itself, because the Handler has no parameters.
I can easily clear the interrupt source on my device with a simple write
through PCI, but I need to know the IRQ# to find out WHICH device to
clear: reading ALL the Interrupt Status Registers of ALL my devices
would be too time-consuming…
Is there a qnx call to get this info or should I read some PIC register?
thanks, Davide
Thanks Bert, the approach you describe it’s the one I’ve started working on.
Davide
Bert Menkveld wrote:
I think the simplest and cleanest way to get this info is to attach a
separate interrupt handler for each interrupt. This may seem cumbersome,
but in reality you’re not likely to have more than a few different
interrupts to handle. You can still have each handler call a common
function to perform whatever common code you need to handle each interrupt.
Regards,
Bert Menkveld
Engineer
Corman Technologies Inc.
You could also attach two (or more proxies) and have your single
interrupt handler (attached to all the h/w interrupts you will service)
return with the proxy that represents the IRQ that was triggered. Of
course, Bert’s suggestion is fundamentally the same (six of one - half
dozen of the other) - take your choice.
Davide Ancri wrote:
Thanks Bert, the approach you describe it’s the one I’ve started working
on.
Davide
Bert Menkveld wrote:
I think the simplest and cleanest way to get this info is to attach a
separate interrupt handler for each interrupt. This may seem cumbersome,
but in reality you’re not likely to have more than a few different
interrupts to handle. You can still have each handler call a common
function to perform whatever common code you need to handle each
interrupt.
Regards,
Bert Menkveld
Engineer
Corman Technologies Inc.
“Rennie Allen” <rallen@csical.com> wrote in message
news:3C0D211B.50800@csical.com…
You could also attach two (or more proxies) and have your single
interrupt handler (attached to all the h/w interrupts you will service)
return with the proxy that represents the IRQ that was triggered. Of
course, Bert’s suggestion is fundamentally the same (six of one - half
dozen of the other) - take your choice.
…so. if i understand it correct the question was: how to determine inside
interrupt handling function which IRQ was triggered in order to return
according proxy (previously attached of course and so on) ? i see at least
three sollutions:
first is you can determine which IRQ was triggered by asking it from your
reall hardware. for example, UARTs 8250 and upper have a state register
which bits define the reason of triggered IRQ i.e. it was generated course
of RX buffer is full or TX buffer is empty or line error detected or any
combination of them. if you need to support several alike devices
(COM1/COM2) with the same interrupt handler, you can read this register for
all UARTs and trigger appropriate proxy.
second is that you can ask according Programmable Interrupt Controller (PIC,
first or second for AT) about its IRQ requests currently been in service.
note that if nested interrupts are enabled then there can be more then one
interrupt in service at this moment (nested interrupts).
third is that you can determine which IRQ was fired from appropriate first
level Interrupt Service Routine (ISR) is called then just map software
interrupt number into IRQ number and pass this value into upper level
interrupt handling routine. or at least pass there number of software
interrupt so routine could map it by itself.
which way to choose… under dos i used second or third methods due to if
carefully coded it’s a way more universal. under qnx4 i usually prefer to
stay away from manual PICs programming and qnx4 kernel’s first level ISRs
don’t pass nor interrupt nor mapped IRQ numbers into attached user interrupt
handlers so i use first method or if just attach one interrupt handler per
one interrupt.
Davide Ancri wrote:
Thanks Bert, the approach you describe it’s the one I’ve started working
on.
Davide
Bert Menkveld wrote:
I think the simplest and cleanest way to get this info is to attach a
separate interrupt handler for each interrupt. This may seem
cumbersome,
but in reality you’re not likely to have more than a few different
interrupts to handle. You can still have each handler call a common
function to perform whatever common code you need to handle each
interrupt.
Regards,
Bert Menkveld
Engineer
Corman Technologies Inc.
// wbr