I've started cleaning up mpparse.c/ioapic.c for the addition of acpi
support, but I got stuck in the mess of global variables.
What's the purpose of of the irq_2_pin in io_apic.c?
I assume that I overlook something, but afaics the code allows one
physical interrupt source (e.g. INTA from device 9 on pci bus 0) to
arrive at multiple ioapic pins.
Can that happen, is that important?
Silly question: Why can't we ignore all but the first pin? If we don't
enable the additional pins, we don't have to disable them during
disable_irq().
disable_irq() and enable_irq() seem to be the only users of irq_2_pin.
Btw, is is correct that the isa irq's are always connected to the first
io apic? find_isa_irq_pin() doesn't handle that, and the caller just
access io apic 0.
--
Manfred
On Fri, 2 Feb 2001, Manfred wrote:
> What's the purpose of of the irq_2_pin in io_apic.c?
Just for what the comment says: to map our IRQ number to an apic:pin
entity in O(1). It has to be fast! You would have to parse the MP table
otherwise -- see pin_2_irq().
> I assume that I overlook something, but afaics the code allows one
> physical interrupt source (e.g. INTA from device 9 on pci bus 0) to
> arrive at multiple ioapic pins.
That's secondary, AFAIK.
> Can that happen, is that important?
>
> Silly question: Why can't we ignore all but the first pin? If we don't
> enable the additional pins, we don't have to disable them during
> disable_irq().
Possibly yes -- I haven't seen such a system.
> disable_irq() and enable_irq() seem to be the only users of irq_2_pin.
That's why it has to be fast.
> Btw, is is correct that the isa irq's are always connected to the first
> io apic? find_isa_irq_pin() doesn't handle that, and the caller just
> access io apic 0.
It appears it happens so for all systems checked so far. The MPS does
not seem to enforce this configuration, so we might relax this dependency
for flexibility. Note that not only find_isa_irq_pin() hardcodes this
assumption -- setup_ExtINT_IRQ0_pin() does as well, for example.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Fri, 2 Feb 2001, Maciej W. Rozycki wrote:
> > Can that happen, is that important?
> >
> > Silly question: Why can't we ignore all but the first pin? If we don't
> > enable the additional pins, we don't have to disable them during
> > disable_irq().
>
> Possibly yes -- I haven't seen such a system.
it does exist, and the feature fixed a real bug. I dont remember which
system exactly :-|
> > Btw, is is correct that the isa irq's are always connected to the first
> > io apic? find_isa_irq_pin() doesn't handle that, and the caller just
> > access io apic 0.
>
> It appears it happens so for all systems checked so far. The MPS does
> not seem to enforce this configuration, so we might relax this
> dependency for flexibility. Note that not only find_isa_irq_pin()
> hardcodes this assumption -- setup_ExtINT_IRQ0_pin() does as well, for
> example.
(hm, dont we have an assert in there to catch ISA IRQs bound to the second
IO-APIC?) In any case, it would be a very surprising move if anyone added
a second IO-APIC for the sake of *ISA* devices. This would be truly
backwards.
Ingo
On Fri, 2 Feb 2001, Ingo Molnar wrote:
> (hm, dont we have an assert in there to catch ISA IRQs bound to the second
> IO-APIC?) In any case, it would be a very surprising move if anyone added
> a second IO-APIC for the sake of *ISA* devices. This would be truly
> backwards.
It's just the matter of the order I/O APICs are listed in the MP table.
I think it's only the limited number of multiple-I/O APIC systems
available so far that prevented from a reverse listing to happen. Given
recent developments which lead to more such systems (e.g. using the
infamous ServerWorks chipset which embeds two I/O APICs internally), it's
only the matter of time until this happens, I'm afraid.
No need to hurry, though -- we might fix the problem once (if) it
appears.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +