> One thing I will say. Your code would be a hell of a lot saner for
> merging if you mapped the ISA/Legacy IRQ's as 0-15 (to software) and the
> PCI ones to 16+ like everyone else does. That would kill a _lot_ of
> ifdefs and the IRQ0 corner case
If you have a suggestion on how to do that, I am sure we would
all be grateful to hear it.
Note that the reason the code _exists_ is because the interrupt
lines are physically connected to different pins on the APIC
than they are in "normal" systems. The legitimacy of that
decision is not up for debate at this point -- that is the way
the system was built, and Linux needs to deal with it in
order to run on it.
So the PCI interrupts are in the table at IRQs < 16 (because
it tells which pin is being used), which makes it difficult
to tell whether a PCI or an ISA interrupt is being requested
if you tell the code "irq 3": if ISA, you need to use pin f(X),
while if PCI, you use pin X.
ACPI should have the ISA redirection information, but as
Natalie was saying, drivers hard-code the ISA vectors without
checking the ACPI info.
I suppose it would be possible to detect the ES7000 and have
the kernel re-write the PCI vectors (say, add 16 to them all)
and then re-mangle them based on a "< 16" criteria.
But I don't believe that is a "clean" solution either
(and would break when the ACPI isa redirection table is
properly used).
Anyway, this was the reason for the "severe irq override"
comment by Natalie.
Kevin
On Thu, 2002-12-26 at 02:18, Van Maren, Kevin wrote:
> If you have a suggestion on how to do that, I am sure we would
> all be grateful to hear it.
>
> Note that the reason the code _exists_ is because the interrupt
> lines are physically connected to different pins on the APIC
> than they are in "normal" systems. The legitimacy of that
> decision is not up for debate at this point -- that is the way
> the system was built, and Linux needs to deal with it in
> order to run on it.
The IRQ number is a cookie. Linux knows that on x86 ISA IRQ is mapped
0-15 and the ISA drivers sometimes know about this stuff too. What
exception number comes back off the processor and what function you call
is really quite unrelated. So request/free_irq functionality in the i386
layer can happily remap the irqs back and forth so ISA comes 0-15, and
keep the drivers and core oblivious to this.
> So the PCI interrupts are in the table at IRQs < 16 (because
> it tells which pin is being used), which makes it difficult
> to tell whether a PCI or an ISA interrupt is being requested
> if you tell the code "irq 3": if ISA, you need to use pin f(X),
> while if PCI, you use pin X.
Internal detail - doesnt matter for how you number IRQ's outside of your
arch/i386/kernel internal bits
> ACPI should have the ISA redirection information, but as
> Natalie was saying, drivers hard-code the ISA vectors without
> checking the ACPI info.
ACPI is basically PC specific gunge. Drivers don't and should not know
about it.
> I suppose it would be possible to detect the ES7000 and have
> the kernel re-write the PCI vectors (say, add 16 to them all)
Linux doesn't touch the PCI interrupt line values or really care about
them, so thats trivial to do.
> and then re-mangle them based on a "< 16" criteria.
> But I don't believe that is a "clean" solution either
> (and would break when the ACPI isa redirection table is
> properly used).
No because any ACPI ISA redirect must be done portably, so used to keep
the ISA irq's logically 0-15 on x86
>
> Anyway, this was the reason for the "severe irq override"
> comment by Natalie.
I understand why it was done - I think its the wrong abstraction as it
pushes too much board knowledge into drivers and into places that make
assumptions about ISA (a legacy of Linux original design being for ISA
PC)