Re: FW: [PATCH] i386: irq: Kill IRQ compression
l> From: Eric W. Biederman [mailto:[EMAIL PROTECTED] Sent: Friday, February 16, 2007 2:22 AM To: Protasevich, Natalie Cc: Len Brown; Andi Kleen; lkml - Kernel Mailing List; linux-acpi@vger.kernel.org Subject: Re: [PATCH] i386: irq: Kill IRQ compression [EMAIL PROTECTED] (Eric W. Biederman) writes: > By itself I don't think we are going to observe any real problems > with this patch. > > However if we are going to be serious about this we need to do a > few more things. > > - kill ioapic_renumber_irq. Looking closer ioapic_renumber_irq does not appear to be an irq compress thing. Rather it appears to be a work around for a weird acpi implementation where gsi 0 - 15 are not the ISA irqs. Natalie is my reading of the code there correct? Yes, indeed. If so keeping ioapic_renumber_irq makes sense. Although giving it a name that suggests it is working around weird implementation details would be good. Sure. I think it was originally renumber_gsi something, but Len had to change it so it sounds more explicit as familiar "IRQ". --Natalie Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FW: [PATCH] i386: irq: Kill IRQ compression
"Natalie Protasevich" <[EMAIL PROTECTED]> writes: > This routine actually renumbers gsi's. I don't think you can kill > ioapic_renumber_irq without bringing down ES7000 that have swapped > legacy/PCI ranges and are still out there. Moreover, mach-es7000 > purpose is to define and use the range swapper on the first ioapic. > Kernel still assumes legacy mapping having no overrides of that > extent. Perhaps the real fix is to have ACPI/MPS parsers to read the > actual pin/gsi information from the tables, which turned out pretty > difficult last time we tried. > --Natalie Yes I noticed, and you replied just before I send off an email explicitly asking you about this :) At first glance I thought it was that other piece of irq compression that showed up in arch/x86_64/io_apic.c but it appears arch/i386/io_apic.c does not have that. Anyway now all we have to do is bump up NR_IRQS and we should be good, patch in a moment. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: irq: Kill IRQ compression
[EMAIL PROTECTED] (Eric W. Biederman) writes: > By itself I don't think we are going to observe any real problems > with this patch. > > However if we are going to be serious about this we need to do a > few more things. > > - kill ioapic_renumber_irq. Looking closer ioapic_renumber_irq does not appear to be an irq compress thing. Rather it appears to be a work around for a weird acpi implementation where gsi 0 - 15 are not the ISA irqs. Natalie is my reading of the code there correct? If so keeping ioapic_renumber_irq makes sense. Although giving it a name that suggests it is working around weird implementation details would be good. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FW: [PATCH] i386: irq: Kill IRQ compression
From: Eric W. Biederman [mailto:[EMAIL PROTECTED] Sent: Friday, February 16, 2007 12:44 AM To: Len Brown Cc: Andi Kleen; Protasevich, Natalie; lkml - Kernel Mailing List; linux-acpi@vger.kernel.org Subject: Re: [PATCH] i386: irq: Kill IRQ compression Len Brown <[EMAIL PROTECTED]> writes: > This code makes simple systems complex: > > ACPI: PCI Interrupt :03:04.0[A] -> GSI 18 (level, low) -> IRQ 16 > ACPI: PCI Interrupt :00:1d.0[A] -> GSI 16 (level, low) -> IRQ 17 > ACPI: PCI Interrupt :00:1d.1[B] -> GSI 19 (level, low) -> IRQ 18 > ACPI: PCI Interrupt :00:1d.7[D] -> GSI 23 (level, low) -> IRQ 19 > > The same code was already removed from x86_64 By itself I don't think we are going to observe any real problems with this patch. However if we are going to be serious about this we need to do a few more things. - kill iopaic_renumber_irq. This routine actually renumbers gsi's. I don't think you can kill ioapic_renumber_irq without bringing down ES7000 that have swapped legacy/PCI ranges and are still out there. Moreover, mach-es7000 purpose is to define and use the range swapper on the first ioapic. Kernel still assumes legacy mapping having no overrides of that extent. Perhaps the real fix is to have ACPI/MPS parsers to read the actual pin/gsi information from the tables, which turned out pretty difficult last time we tried. --Natalie - Increase NR_IRQS. We will still be limited to about 208 interrupts in use at one time, but we can allow more irq sources to be described. This reminds me. I really need to dig up my patch that doesn't allocate a vector for an irq until request irq time. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: irq: Kill IRQ compression
Len Brown <[EMAIL PROTECTED]> writes: > This code makes simple systems complex: > > ACPI: PCI Interrupt :03:04.0[A] -> GSI 18 (level, low) -> IRQ 16 > ACPI: PCI Interrupt :00:1d.0[A] -> GSI 16 (level, low) -> IRQ 17 > ACPI: PCI Interrupt :00:1d.1[B] -> GSI 19 (level, low) -> IRQ 18 > ACPI: PCI Interrupt :00:1d.7[D] -> GSI 23 (level, low) -> IRQ 19 > > The same code was already removed from x86_64 By itself I don't think we are going to observe any real problems with this patch. However if we are going to be serious about this we need to do a few more things. - kill iopaic_renumber_irq. - Increase NR_IRQS. We will still be limited to about 208 interrupts in use at one time, but we can allow more irq sources to be described. This reminds me. I really need to dig up my patch that doesn't allocate a vector for an irq until request irq time. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i386: irq: Kill IRQ compression
This code makes simple systems complex:
ACPI: PCI Interrupt :03:04.0[A] -> GSI 18 (level, low) -> IRQ 16
ACPI: PCI Interrupt :00:1d.0[A] -> GSI 16 (level, low) -> IRQ 17
ACPI: PCI Interrupt :00:1d.1[B] -> GSI 19 (level, low) -> IRQ 18
ACPI: PCI Interrupt :00:1d.7[D] -> GSI 23 (level, low) -> IRQ 19
The same code was already removed from x86_64
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
Cc: Eric W. Biederman <[EMAIL PROTECTED]>
Cc: Natalie Protasevich <[EMAIL PROTECTED]>
---
arch/i386/kernel/io_apic.c |5
arch/i386/kernel/mpparse.c | 41 -
include/asm-i386/io_apic.h |1
3 files changed, 1 insertion(+), 46 deletions(-)
Index: linus/arch/i386/kernel/mpparse.c
===
--- linus.orig/arch/i386/kernel/mpparse.c
+++ linus/arch/i386/kernel/mpparse.c
@@ -1041,20 +1041,12 @@ void __init mp_config_acpi_legacy_irqs (
}
}
-#define MAX_GSI_NUM4096
-
int mp_register_gsi(u32 gsi, int triggering, int polarity)
{
int ioapic = -1;
int ioapic_pin = 0;
int idx, bit = 0;
static int pci_irq = 16;
- /*
-* Mapping between Global System Interrups, which
-* represent all possible interrupts, and IRQs
-* assigned to actual devices.
-*/
- static int gsi_to_irq[MAX_GSI_NUM];
/* Don't set up the ACPI SCI because it's already set up */
if (acpi_gbl_FADT.sci_interrupt == gsi)
@@ -1087,42 +1079,11 @@ int mp_register_gsi(u32 gsi, int trigger
if ((1< 15), but
-* avoid a problem where the 8254 timer (IRQ0) is setup
-* via an override (so it's not on pin 0 of the ioapic),
-* and at the same time, the pin 0 interrupt is a PCI
-* type. The gsi > 15 test could cause these two pins
-* to be shared as IRQ0, and they are not shareable.
-* So test for this condition, and if necessary, avoid
-* the pin collision.
-*/
- if (gsi > 15 || (gsi == 0 && !timer_uses_ioapic_pin_0))
- gsi = pci_irq++;
- /*
-* Don't assign IRQ used by ACPI SCI
-*/
- if (gsi == acpi_gbl_FADT.sci_interrupt)
- gsi = pci_irq++;
- gsi_to_irq[irq] = gsi;
- } else {
- printk(KERN_ERR "GSI %u is too high\n", gsi);
- return gsi;
- }
- }
-
io_apic_set_pci_routing(ioapic, ioapic_pin, gsi,
triggering == ACPI_EDGE_SENSITIVE ? 0 : 1,
polarity == ACPI_ACTIVE_HIGH ? 0 : 1);
Index: linus/arch/i386/kernel/io_apic.c
===
--- linus.orig/arch/i386/kernel/io_apic.c
+++ linus/arch/i386/kernel/io_apic.c
@@ -2212,8 +2212,6 @@ static inline void unlock_ExtINT_logic(v
ioapic_write_entry(apic, pin, entry0);
}
-int timer_uses_ioapic_pin_0;
-
/*
* This code may look a bit paranoid, but it's supposed to cooperate with
* a wide range of boards and BIOS bugs. Fortunately only the timer IRQ
@@ -2250,9 +2248,6 @@ static inline void __init check_timer(vo
pin2 = ioapic_i8259.pin;
apic2 = ioapic_i8259.apic;
- if (pin1 == 0)
- timer_uses_ioapic_pin_0 = 1;
-
printk(KERN_INFO "..TIMER: vector=0x%02X apic1=%d pin1=%d apic2=%d
pin2=%d\n",
vector, apic1, pin1, apic2, pin2);
Index: linus/include/asm-i386/io_apic.h
===
--- linus.orig/include/asm-i386/io_apic.h
+++ linus/include/asm-i386/io_apic.h
@@ -142,7 +142,6 @@ extern int io_apic_get_unique_id (int io
extern int io_apic_get_version (int ioapic);
extern int io_apic_get_redir_entries (int ioapic);
extern int io_apic_set_pci_routing (int ioapic, int pin, int irq, int
edge_level, int active_high_low);
-extern int timer_uses_ioapic_pin_0;
#endif /* CONFIG_ACPI */
extern int (*ioapic_renumber_irq)(int ioapic, int irq);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
