Re: [tip:x86/apic] x86: Fix out of order gsi -- add remap_ioapic_gsi_to_irq()

[Yinghai Lu <yinghai@kernel.org>]

On 02/27/2010 11:04 AM, Eric W. Biederman wrote:
> Ingo Molnar <mingo@elte.hu> writes:
> 
>> Causes:
>>
>>  arch/x86/kernel/apic/io_apic.c:1042: error: implicit declaration of function ?remap_ioapic_gsi_to_irq?
>>
>> Please send delta fix.
> 
> I am certain I have said this before but the entire concept of 
> irq != gsi is broken.  We used to have code that did this and it was a
> non-ending source of problems that we finally removed after we pushed
> up the limit on the number of irqs.
> 
> We already have the irq_2_pin list which allows for arbitrary mappings
> between irqs and the ioapics and pins.  So there should be no problem
> mapping irq to gsi and assigning irqs to arbitrary ioapic pins.
> 
> I have yet to see something that even purports to be an explanation
> of why our handling of acpi int_src_overrides is broken and why
> it needs the mess that is a remapper.
> 
> I don't doubt YHs changes fix something but this feels like a direction
> that trades off one bug for another instead of actually fixing the code.
> 
> It does look like we have weird old hard codes in some of the
> irq_2_pin and pin_2_irq paths that YH is touching, and it may make sense
> to introduce a concept of ioapic pin index.  
> 
> The touching of drivers/pnp/pnpacpi/rsparser.c feels like just the tip of
> the iceberg in dealing with weird bugs if we continue down this path.
> 

the x3950 has strange gsi base 

ACPI: IOAPIC (id[0x10] address[0xfecff000] gsi_base[0])
IOAPIC[0]: apic_id 16, version 0, address 0xfecff000, GSI 0-2
ACPI: IOAPIC (id[0x0f] address[0xfec00000] gsi_base[3])
IOAPIC[1]: apic_id 15, version 0, address 0xfec00000, GSI 3-38
ACPI: IOAPIC (id[0x0e] address[0xfec01000] gsi_base[39])
IOAPIC[2]: apic_id 14, version 0, address 0xfec01000, GSI 39-74

and BIOS using INT_SRC_OVR to map back gsi  3 - 18 to irq 0 - 15
ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 4 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 5 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 3 global_irq 6 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 4 global_irq 7 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 6 global_irq 9 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 7 global_irq 10 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 8 global_irq 11 low edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 12 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 12 global_irq 15 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 13 global_irq 16 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 17 low edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 18 dfl dfl)
if we dont have this patch to do the remap (swap some mapping between ioapic), and only assume irq = gsi,

the irq from first ioapic controller will be blocked.

so far this patch only affect (fix ) x3950.

all other platform will all have boot_ioapic_idx's gsi_base == 0, 
the function will just still return gsi.

other solution will ask IBM to fix their bios, so we can get

ACPI: IOAPIC (id[0x10] address[0xfecff000] gsi_base[36])
IOAPIC[0]: apic_id 16, version 0, address 0xfecff000, GSI 36-38
ACPI: IOAPIC (id[0x0f] address[0xfec00000] gsi_base[0])
IOAPIC[1]: apic_id 15, version 0, address 0xfec00000, GSI 0-35
ACPI: IOAPIC (id[0x0e] address[0xfec01000] gsi_base[39])
IOAPIC[2]: apic_id 14, version 0, address 0xfec01000, GSI 39-74
then they don't need append that bunch of OVR.

Yinghai