[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Sensing Interrupt Pins that is not in your trace?
> From: Lame Brooks-G14738 <email@example.com>
> What about option #3) make your device also connect to INTs B, C, & D in its
> PCI slot? If you only have one input available on your device and you don't
> care about being able to differentiate separate interrupt lines (as implied
> by your wanting a backplane with all INTs wire ORed to only one interrupt
> line), then just logically OR them on your card.
> > From: Addison Chen [mailto:firstname.lastname@example.org]
> > I am currently coding firmware for a PCI device that have the
> > ability to sense interrupts in the PCI backplane. If I do get
> > an interrupt, the interrupt handler gets called.
> > Right now, I want to sense interrupts from other PCI devices
> > on the same backplane. The problem is, some of the PCI devices
> > are MULTI-functional devices that take up 2 or more Interrupt
> > pins (i.e. INTA# and INTB#). Since my device (that I am coding)
> > uses only INTA#, it can't see an interrupt INTB# from a
> > multifunctional device.
> > Is there any way to be able to sense interrupts from ALL PCI
> > devices? Currently, I can think of 2 solutions:
> > 1) Poll the interrupt registers on each device for
> > interrupts. Solution is too slow!
> > 2) Purchase a special PCI backplane that have all INTA#, INTB#,
> > INTC#, and INTD# connected to the same trace. That way, the PCI
> > device that I am coding can detect any interrupts occurring.
> > BUT, does this special PCI backplane exists?
Lame's suggestion is good, but you still need to be careful about
the backplane - the INTs from one slot are not necessarily connected
to any of the INT pins from other slots. In the extreme case, each
INT from each slot could be individually connected solely to an
interrupt controller input.
And then there's always the possibility of functions using Message
Signaled Interrupts, raising interrupts without driving any INT.