cvs commit: src/sys/i386/acpica madt.c
Nate Lawson
nate at root.org
Tue Nov 11 10:59:21 PST 2003
On Tue, 11 Nov 2003, John Baldwin wrote:
> Modified files:
> sys/i386/acpica madt.c
> Log:
> Some motherboards like to remap the SCI (normally IRQ 9) up to a PCI
> interrupt such as IRQ 22 or 19. However, the ACPI BIOS still routes
> interrupts from some PCI devices to the same intpin calling the pin
> IRQ 22. Thus, ACPI expects to address a single interrupt source via two
> different names. To work around this, if the SCI is remapped to a non-ISA
> interrupt (i.e., greater than 15), then we use
> acpi_OverrideInterruptLevel() function to tell ACPI to use IRQ 22 or 19
> rather than IRQ 9 for the SCI.
>
> Previously we would change IRQ 22 or 19's name to IRQ 9 when we encountered
> such an Interrupt Source Override entry in the MADT which routed the SCI
> properly but left PCI devices mapped to IRQ 22 or 19 w/o a routable
> interrupt.
>
> Tested by: sos
>
> Revision Changes Path
> 1.6 +6 -1 src/sys/i386/acpica/madt.c
>
> --- src/sys/i386/acpica/madt.c:1.5 Mon Nov 10 11:52:57 2003
> +++ src/sys/i386/acpica/madt.c Tue Nov 11 10:20:10 2003
> @@ -536,7 +536,12 @@
> }
>
> if (intr->Source != intr->GlobalSystemInterrupt) {
> - ioapic_remap_vector(new_ioapic, new_pin, intr->Source);
> + /* XXX: This assumes that the SCI uses IRQ 9. */
> + if (intr->GlobalSystemInterrupt > 15 && intr->Source == 9)
> + acpi_OverrideInterruptLevel(
> + intr->GlobalSystemInterrupt);
> + else
> + ioapic_remap_vector(new_ioapic, new_pin, intr->Source);
> if (madt_find_interrupt(intr->Source, &old_ioapic,
> &old_pin) != 0)
> printf("MADT: Could not find APIC for source IRQ %d\n",
Yikes, couldn't that be done by using devclass to get the acpi driver and
find which interrupt it is using? Or maybe better, move this into acpi
itself which can call the override if it finds itself on a different pin?
I'm certain there are non-9 acpi sci implementations although not common.
-Nate
More information about the cvs-src
mailing list