On Fri, 13 Aug 2004 20:21:52 +0000
"Charles M. Hannum" <abuse@spamalicious.com> wrote:

> PCI slots have four interrupt lines (INTA-INTD).=20
I know. (Although the PCI host bridge has INTE and INTF as well. Maybe a
64 bit PCI extension?)

> A PCI-PCI bridge maps these=20
> to its subdevices in a prescribed fashion, by "swizzling" them based
> on the device number.  (So, one device might gets A,B,C,D, another
> B,C,D,A, etc.). =20
Aha, that is that "swizzling" thing in pcibus_attach_args and
pci_attach_args.=20

> How the slot interrupts are mapped to system interrupts is
> unspecified.=20
This is not the problem. I know the interrupt routing up to the PCI host
bridge interrupt controller. What I don't know is how it continues on
the PCI side.

> There is no method for determining which=20
> device(s) generated the interrupt; you just poll each one.
My question was unprecise in that: Can this polling be done in a device
independent manner, e.g. by reading the PCI config space / PCI-PCI
bridge registers? Or is this polling done by calling the interrupt
handler of all device drivers that use that interrupt?

> I'd say, if you have the mapping of the 4 interrupts working, don't
> argue with it too much.  :-)
The real problem is: The hp700 interrupt routing code does not spport
shared interrupts at the moment. The hp700 hardware has a hierarchic
"tree" of interrupt registers / conrollers. So once the CPU gets an
interrupt it can walk down the "interrupt path" to the interrupt bit
that caused the interrupt. As every device has its own, individual
interrupt bit you immediatly know what interrupt handler to call and
only this single handler has to be called. But PCI is an alien to the
PA-IO architecture, so things go different behind the PCI host bridge.
My interrupt knowledge ends at the PCI host bridge. ;-)

PCI devices can share a single interrupt. So there are two
possibilities:=20
A) It is possible to determine in a device independent way which PCI
device caused the interrupt. In that case the interrupt routing code
needs to be extended so that it determines the exact device and calls
only the interrupt handler in question.
B) It is _not_ possible to determine which PCI device caused the
interrupt. In that case the interrupt routing code needs to be extended
so that it calls all interrupt handlers related to this interrupt.

From what it looks like and what you told me B) is the case.
--=20


tsch=FC=DF,
       Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/