Messages in this thread | | | Subject | Re: ACPI SCI IOAPIC bug (Re: Fixes for nforce2 hard lockup, apic, io-apic, udma133 covered) | From | Len Brown <> | Date | 31 Mar 2004 17:19:40 -0500 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |