Thread (6 messages) 6 messages, 5 authors, 2000-12-05

arguing IRQ (was Re: dual IRQ 23)

From: Stefan Jeglinski <hidden>
Date: 2000-12-04 06:09:49

[I apologize in advance to Geert, Michel, and Ben if I have
misrepresented their previous statements below - I'm trying to figure
this out still]


Geert said:
Shared interrupts are allowed by PCI. If it doesn't work, it means one of the
drivers (or both) can't cope with shared interrupts. The solution is
to fix the driver(s).
However, another consensus seems to be available, as per Michel Lanners:
01:0c.0 FireWire (IEEE 1394): NEC Corporation: Unknown device 00cd
(rev 01) (prog-if 10 [OHCI])
[snip]
 Interrupt: pin A routed to IRQ 1
This is most certainly wrong -> ^

01:0d.0 USB Controller: OPTi Inc. 82C861 (rev 10) (prog-if 10 [OHCI])
[snip]
 Interrupt: pin A routed to IRQ 23
                 and this too ->^^

Bot of these devices should get IRQ25. Why? Because on Macs, all four
IRQ lines of a PCI slot are OR'ed together on the bridge chip.
Therefore, there is one single fixed IRQ per PCI slot. So, the devices
behind the PCI-to-PCI bridge in slot 00:0f should all have the same IRQ,
which should be, following the obvious logic, IRQ 25.

Either a problem with the P2P bridge code in Linux, or with detecting
the IRQ's out of OF, as Ben suggested.
It seems to me that both should have the same interrupt, as Michel
states - after all, they are on the same PCI card; however, the
larger issue is whether neither should be 23, because 23 is already
assigned:
00:0d.0 SCSI storage controller: Adaptec AIC-7881U
[snip]
 Interrupt: pin A routed to IRQ 23

Indeed, Ben has said along these lines:
Ok, I found the problem, I think, with the interrupt. I'm still
investigating, but what it looks like is that the OF tree puts the
AAPL,interrupt property in the pci-bridge node, not in the sub-nodes.
So we must make sure the routine that gets interrupts from the tree
on oldworld iterates to parent devices when it can't find the
AAPL,interrupt property.

Which again indicates that the problem is in the PCI (?) code.

So, is Geert right (PCI ok at least in this aspect, drivers are
buggy)? Or are Ben/Michel right (drivers OK, PCI/IRQ buggy)?



Stefan Jeglinski

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help