35a17eb6a8
This is kind of hokey, we could use the hardware provided facilities
much better.
MSIs are assosciated with MSI Queues. MSI Queues generate interrupts
when any MSI assosciated with it is signalled. This suggests a
two-tiered IRQ dispatch scheme:
MSI Queue interrupt --> queue interrupt handler
MSI dispatch --> driver interrupt handler
But we just get one-level under Linux currently. What I'd like to do
is possibly stick the IRQ actions into a per-MSI-Queue data structure,
and dispatch them form there, but the generic IRQ layer doesn't
provide a way to do that right now.
So, the current kludge is to "ACK" the interrupt by processing the
MSI Queue data structures and ACK'ing them, then we run the actual
handler like normal.
We are wasting a lot of useful information, for example the MSI data
and address are provided with ever MSI, as well as a system tick if
available. If we could pass this into the IRQ handler it could help
with certain things, in particular for PCI-Express error messages.
The MSI entries on sparc64 also tell you exactly which bus/device/fn
sent the MSI, which would be great for error handling when no
registered IRQ handler can service the interrupt.
We override the disable/enable IRQ chip methods in sun4v_msi, so we
have to call {mask,unmask}_msi_irq() directly from there. This is
another ugly wart.
Signed-off-by: David S. Miller <davem@davemloft.net>
62 lines
2.1 KiB
Text
62 lines
2.1 KiB
Text
#
|
|
# PCI configuration
|
|
#
|
|
config PCI_MSI
|
|
bool "Message Signaled Interrupts (MSI and MSI-X)"
|
|
depends on PCI
|
|
depends on (X86_LOCAL_APIC && X86_IO_APIC) || IA64 || SPARC64
|
|
help
|
|
This allows device drivers to enable MSI (Message Signaled
|
|
Interrupts). Message Signaled Interrupts enable a device to
|
|
generate an interrupt using an inbound Memory Write on its
|
|
PCI bus instead of asserting a device IRQ pin.
|
|
|
|
Use of PCI MSI interrupts can be disabled at kernel boot time
|
|
by using the 'pci=nomsi' option. This disables MSI for the
|
|
entire system.
|
|
|
|
If you don't know what to do here, say N.
|
|
|
|
config PCI_MULTITHREAD_PROBE
|
|
bool "PCI Multi-threaded probe (EXPERIMENTAL)"
|
|
depends on PCI && EXPERIMENTAL && BROKEN
|
|
help
|
|
Say Y here if you want the PCI core to spawn a new thread for
|
|
every PCI device that is probed. This can cause a huge
|
|
speedup in boot times on multiprocessor machines, and even a
|
|
smaller speedup on single processor machines.
|
|
|
|
But it can also cause lots of bad things to happen. A number
|
|
of PCI drivers cannot properly handle running in this way,
|
|
some will just not work properly at all, while others might
|
|
decide to blow up power supplies with a huge load all at once,
|
|
so use this option at your own risk.
|
|
|
|
It is very unwise to use this option if you are not using a
|
|
boot process that can handle devices being created in any
|
|
order. A program that can create persistent block and network
|
|
device names (like udev) is a good idea if you wish to use
|
|
this option.
|
|
|
|
Again, use this option at your own risk, you have been warned!
|
|
|
|
When in doubt, say N.
|
|
|
|
config PCI_DEBUG
|
|
bool "PCI Debugging"
|
|
depends on PCI && DEBUG_KERNEL
|
|
help
|
|
Say Y here if you want the PCI core to produce a bunch of debug
|
|
messages to the system log. Select this if you are having a
|
|
problem with PCI support and want to see more of what is going on.
|
|
|
|
When in doubt, say N.
|
|
|
|
config HT_IRQ
|
|
bool "Interrupts on hypertransport devices"
|
|
default y
|
|
depends on PCI && X86_LOCAL_APIC && X86_IO_APIC
|
|
help
|
|
This allows native hypertransport devices to use interrupts.
|
|
|
|
If unsure say Y.
|