ACPI vs. ISA IRQs

Assumption: sharing interrupts is bad.

Plan:
ACPI should attempt to distribute interrupts across the available IRQs.

This mostly applies to PIC mode, where PCI
IRQ Link Devices are available to route PCI
interrupts to open IRQs on the PIC.
(In IO-APIC mode, we generally get no choice
which IO-APIC pins devices are attached to)

We have acpi_irq_penalty[] (disabled at the moment) in pci_link.c hard-coded to tell ACPI to avoid some IRQs that are commonly used by ISA devices.

But if,say, a sound-blaster card requests exclusive access to an IRQ that we didn't happen to reserve, and we happened to set a PCI link device to that IRQ, then sound doesn't work.

How to fix?

We can manually reserve IRQs to over-ride acpi_irq_penalty[], say "acpi_irq_used=5,10" to tell ACPI not to use IRQs that it thought by default were available.

Conversely, we could us, say, "acpi_irq_free=3,15" to tell ACPI that some IRQs it assumed were reserved for ISA are actually available for PCI.

I don't know of an automatic way to handle this. Seems that the ISA devices use Plug-and-Play methods to request IRQs, but there is no mechanism for such an event to boot a PIRQ off an IRQ if ACPI has put it there. Also, if such a mechanism existed, it wouldn't work if PNP were not available to ask for an IRQ.

thoughts?

thanks,
-Len

ref:
http://bugzilla.kernel.org/show_bug.cgi?id=430
http://bugzilla.kernel.org/show_bug.cgi?id=1139
http://bugzilla.kernel.org/show_bug.cgi?id=1391

Assumption: sharing interrupts is bad.

Plan:
ACPI should attempt to distribute interrupts across the available IRQs.

This mostly applies to PIC mode, where PCI
IRQ Link Devices are available to route PCI
interrupts to open IRQs on the PIC.
(In IO-APIC mode, we generally get no choice
which IO-APIC pins devices are attached to)

We have acpi_irq_penalty[] (disabled at the moment) in pci_link.c hard-coded to tell ACPI to avoid some IRQs that are commonly used by ISA devices.

But if,say, a sound-blaster card requests exclusive access to an IRQ that we didn't happen to reserve, and we happened to set a PCI link device to that IRQ, then sound doesn't work.

How to fix?

We can manually reserve IRQs to over-ride acpi_irq_penalty[], say "acpi_irq_used=5,10" to tell ACPI not to use IRQs that it thought by default were available.

Conversely, we could us, say, "acpi_irq_free=3,15" to tell ACPI that some IRQs it assumed were reserved for ISA are actually available for PCI.

I don't know of an automatic way to handle this. Seems that the ISA devices use Plug-and-Play methods to request IRQs, but there is no mechanism for such an event to boot a PIRQ off an IRQ if ACPI has put it there. Also, if such a mechanism existed, it wouldn't work if PNP were not available to ask for an IRQ.

thoughts?

thanks,
-Len

ref:
http://bugzilla.kernel.org/show_bug.cgi?id=430
http://bugzilla.kernel.org/show_bug.cgi?id=1139
http://bugzilla.kernel.org/show_bug.cgi?id=1391

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Acpi-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/acpi-devel