lkml.org 
[lkml]   [2010]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [tip:x86/apic] x86: Fix out of order gsi -- add remap_ioapic_gsi_to_irq()
    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


    \
     
     \ /
      Last update: 2010-02-27 20:45    [W:0.028 / U:60.724 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site