RE: [(repost) git Patch 1/1] avoid IRQ0 ioapic pin collision

[Brown, Len]

Natalie,
Regarding the "IRQ compression" in mp_register_gsi()....

Some time ago we invented ioapic_renumber_irq() to handle the case
where the ES7000 BIOS is missing the INTERRUPT_OVERRIDES needed
to tell that legacy IRQs used pins > 15, and PCI interrupts used
pins < 16.

In that case, the ES7000 uses es7000_rename_gsi() to simply re-number
the IRQs for the lower pins to some unused numbers above the highest
GSI in the system -- emulating what the BIOS should have done.

Later, GSI compression was also added to mp_register_gsi():

if (triggering == ACPI_LEVEL_SENSITIVE)
{
	gsi = pci_irq++;
	...
}

This GSI "compression" was intended to handle systems which have a large
number of sparsely populated IOAPICs.  On these systems, the maximum
GSI is well above NR_IRQS.  While there can be a large number of devices
on these boxes, the total in use is actually still below NR_IRQs --
so squeezing the GSIs into the IRQ numbers works.

The problem with doing this is that it also compresses the IRQ numbers
for the other 99.99% of the systems on earth, causing complexity
and bugs, such as several mentioned on this thread.

I'm thinking that it would be simpler for the big iron that has
GSI's > NR_IRQs, to simply use the existing ioapci_renumber_irq() hook
to do whatever compression or re-naming they fancy.
This will also allow for simpler systems to remain simple
and use identity irq = gsi numbering.
(don't get me started on CONFIG_PCI_MSI, that is an independent issue)

Also, as we discussed, it would probably be cleaner even on those large
systems if the compression algorithm did not re-name every GSI, but only
did re-names when it really has to (GSI > NR_IRQS).  eg.

< gsi = pci_irq++
---
> if (GSI < NR_IRQS)
>    gsi = irq;
> else
>    BUG_ON(irq_used >= NR_IRQS)
>    gsi = platform specific algorithm to grab the unused IRQs that
>    can never have any real devices attached.
> irqs_used++;

If we had done this, then we wouldn't have needed kimbal's patch.
If we do this, then we can delete that workaround on top of workaround.

thoughts?
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/