Russell King wrote:
>These aren't assumptions. The fact of PCI is that there are at the most 4
>interrupts. On each card, these are labelled INTA, INTB, INTC, and INTD.
This is a slight oversimplification. There are at most 4 interrupt outputs
per PCI device, but in theory at least it would be possible for each one of
these to attach to a separate input on the IO-APIC or whatever.
The "rotating irqs" scheme that you illustrated is a common compromise but
it doesn't have to be done that way. So yes, the kernel *does* contain
assumptions about the wiring of the backplane but you're right that it has no
way to know what the hardware looks like.
A slightly cleaner way to deal with this is the scheme that's used on CATS
boards where the knowledge about the hardware layout is in the firmware rather
than the kernel. Of course this still doesn't allow you to take an EBSA-285,
plug it into any slot in a random backplane with unknown wiring and have it
work. The only way to achieve that would be to autoprobe for IRQs which is
generally considered bad form on PCI systems.
The advantage to putting the knowledge about routing in the kernel on the
other hand is that it allows you to take four EBSA-285s, stick them in a
passive backplane with one as the configuration master and the others as
slaves, and they can all work out the interrupt mapping from one card to
another.
p.
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
