On Wed, 2004-02-18 at 12:43, Maciej W. Rozycki wrote:
> Note that if changing an I/O APIC input was indeed needed, the
> replace_pin_at_irq() function could be used.
Why is it that all IRQs get their name from the
IOAPIC pin number, but the timer connected to
pin 2 is called IRQ0 instead of IRQ2?
Are there other exceptions to this rule,
or is all the code for re-naming IRQs & pins
effectively just for the timer?
I wonder if we should't be moving to at least a build option which
deletes support for multiple pins at an IRQ, and deletes
suport for non-identity pin->IRQ mapping.
> I still wonder why these arrangements are made so late in a boot --
> after
> all, ACPI IRQ configuration is table-driven and does not require any
> specific hardware initialization to work. So it could be done at the
> stage MP-table parsing happens, couldn't it?
While the ACPI table parsing is very early, the _PRT parsing
can happen only after the ACPI interpreter is up, because
the _PRT's are encoded in AML.
thanks,
-Len
On Thu, 31 Mar 2004, Len Brown wrote:
> Why is it that all IRQs get their name from the
> IOAPIC pin number, but the timer connected to
> pin 2 is called IRQ0 instead of IRQ2?
ISA interrupts get their numbers from 8259A IRQ numbers they would be
routed to in the PIC mode. This lets the code operate in the mixed mode
sanely (which happens for certain hardware), although it's not necessarily
the reason for the numbering used. Note that the MP Specification does
not mandate an identity map of ISA interrupts, although it seems to be
what vendors do.
Also note that depending on the configuration, the timer can effectively
be routed to INTIN2 or INTIN0 by Linux -- one of the alternatives being a
direct connection and the other one being done through the 8259A
configured to be transparent for its IRQ 0.
> I wonder if we should't be moving to at least a build option which
> deletes support for multiple pins at an IRQ, and deletes
> suport for non-identity pin->IRQ mapping.
This can't be done for the timer due to configuration variations.
> While the ACPI table parsing is very early, the _PRT parsing
> can happen only after the ACPI interpreter is up, because
> the _PRT's are encoded in AML.
Hmm, that's unfortunate. Couldn't the interpreter be started earlier?
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +