From: Eric W. Biederman [mailto:ebiederm@xxxxxxxxxxxx] Sent: Friday, February 16, 2007 12:44 AM To: Len Brown Cc: Andi Kleen; Protasevich, Natalie; lkml - Kernel Mailing List; linux-acpi@xxxxxxxxxxxxxxx Subject: Re: [PATCH] i386: irq: Kill IRQ compression Len Brown <lenb@xxxxxxxxxx> writes: > This code makes simple systems complex: > > ACPI: PCI Interrupt 0000:03:04.0[A] -> GSI 18 (level, low) -> IRQ 16 > ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 17 > ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 18 > ACPI: PCI Interrupt 0000: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-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
