2005-04-16 18:20:36 -04:00
|
|
|
#
|
|
|
|
# PCI configuration
|
|
|
|
#
|
2007-04-18 04:46:20 -04:00
|
|
|
config ARCH_SUPPORTS_MSI
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2005-04-16 18:20:36 -04:00
|
|
|
config PCI_MSI
|
|
|
|
bool "Message Signaled Interrupts (MSI and MSI-X)"
|
|
|
|
depends on PCI
|
2007-04-18 04:46:20 -04:00
|
|
|
depends on ARCH_SUPPORTS_MSI
|
2005-04-16 18:20:36 -04:00
|
|
|
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.
|
|
|
|
|
2006-03-06 00:33:34 -05:00
|
|
|
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.
|
|
|
|
|
2005-04-16 18:20:36 -04:00
|
|
|
If you don't know what to do here, say N.
|
|
|
|
|
2007-10-29 09:48:09 -04:00
|
|
|
config PCI_LEGACY
|
|
|
|
bool "Enable deprecated pci_find_* API"
|
|
|
|
depends on PCI
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Say Y here if you want to include support for the deprecated
|
2009-10-30 15:46:48 -04:00
|
|
|
pci_find_device() API. Most drivers have been converted over
|
|
|
|
to using the proper hotplug APIs, so this option serves to
|
|
|
|
include/exclude only a few drivers that are still using this
|
|
|
|
API.
|
2007-10-29 09:48:09 -04:00
|
|
|
|
2005-04-16 18:20:36 -04:00
|
|
|
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.
|
|
|
|
|
2008-11-26 00:17:13 -05:00
|
|
|
config PCI_STUB
|
|
|
|
tristate "PCI Stub driver"
|
|
|
|
depends on PCI
|
|
|
|
help
|
|
|
|
Say Y or M here if you want be able to reserve a PCI device
|
|
|
|
when it is going to be assigned to a guest operating system.
|
|
|
|
|
|
|
|
When in doubt, say N.
|
|
|
|
|
2006-10-04 05:16:55 -04:00
|
|
|
config HT_IRQ
|
|
|
|
bool "Interrupts on hypertransport devices"
|
|
|
|
default y
|
2006-10-11 04:22:04 -04:00
|
|
|
depends on PCI && X86_LOCAL_APIC && X86_IO_APIC
|
2006-10-04 05:16:55 -04:00
|
|
|
help
|
|
|
|
This allows native hypertransport devices to use interrupts.
|
|
|
|
|
|
|
|
If unsure say Y.
|
2009-03-19 23:25:11 -04:00
|
|
|
|
|
|
|
config PCI_IOV
|
|
|
|
bool "PCI IOV support"
|
|
|
|
depends on PCI
|
|
|
|
help
|
|
|
|
I/O Virtualization is a PCI feature supported by some devices
|
|
|
|
which allows them to create virtual devices which share their
|
|
|
|
physical resources.
|
|
|
|
|
|
|
|
If unsure, say N.
|
PCI hotplug: move IOAPIC support from acpiphp to ioapic driver
This patch moves PCI I/O APIC support from acpiphp to a separate driver.
Like pciehp and shpchp, acpiphp handles PCI hotplug, i.e., addition and
removal of PCI adapters. But in addition, acpiphp handles some ACPI
hotplug, such as the addition of new host bridges, and the I/O APIC
support was tangled up with that.
I don't think the I/O APIC support needs to be in acpiphp; PCI I/O APICs
usually appear as a function on a PCI host bridge, and we'll enumerate the
APIC before any of the devices behind the bridge that use it.
As far as I know, nobody actually uses I/O APIC hotplug. It depends on
acpi_register_ioapic(), which is only implemented for ia64, and I don't
think any vendors have supported I/O chassis hotplug yet.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
CC: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
CC: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-10-26 13:20:47 -04:00
|
|
|
|
|
|
|
config PCI_IOAPIC
|
|
|
|
bool
|
|
|
|
depends on PCI
|
|
|
|
depends on ACPI
|
|
|
|
depends on HOTPLUG
|
|
|
|
default y
|