cvs commit: src/sys/i386/acpica madt.c

[John Baldwin]

On 11-Nov-2003 Nate Lawson wrote:
> 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.

The acpi driver doesn't exist yet.  MADT is part of acpi, so it's already
in acpi.  What might be nice is if I can somehow ask acpi what it's
SCI is.  This is at SI_SUB_INTR btw, so acpi0 doesn't exist yet, but
the VM system is up and running and we should be able to get to the ACPI
tables ok.  I'm not entirely happy with this hack.  Another way of doing
it might be to create an extra layer in the nexus for translating IRQ
resource allocations to re-route them as per interrupt source override
requests.  Hmm, I thought that that would have dmesg print out irq 9 for
ACPI but have the handler actually live on irq 22.  However, if we do the
remapping at the bus_alloc_resource() stage, then it might still print out
irq 22 for the dmesg in which case that would be ok.  It would also move the
clock interrupt to irq 2.  That has other problems when it comes to mixed
mode.  Grr, maybe what I could do is use ioapic_remap_vector() if the mapping
is from one ISA IRQ to another ISA IRQ and use the remapping table in the
nexus otherwise.  Still, the above will work for now.  Note that systems
that use a level other than 9 for the SCI aren't going to need an MADT
entry for IRQ 9 to remap it up to a high interrupt.

-- 

John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/