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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
