2018-01-26 11:45:16 -06:00
|
|
|
# SPDX-License-Identifier: GPL-2.0
|
2005-04-16 15:20:36 -07:00
|
|
|
#
|
|
|
|
|
# PCI configuration
|
|
|
|
|
#
|
2016-02-03 13:24:22 -08:00
|
|
|
|
2018-11-15 20:05:32 +01:00
|
|
|
# select this to offer the PCI prompt
|
|
|
|
|
config HAVE_PCI
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
# select this to unconditionally force on PCI support
|
|
|
|
|
config FORCE_PCI
|
|
|
|
|
bool
|
|
|
|
|
select HAVE_PCI
|
|
|
|
|
select PCI
|
|
|
|
|
|
2024-01-31 10:00:21 +01:00
|
|
|
# select this to provide a generic PCI iomap,
|
|
|
|
|
# without PCI itself having to be defined
|
|
|
|
|
config GENERIC_PCI_IOMAP
|
|
|
|
|
bool
|
|
|
|
|
|
2018-11-15 20:05:32 +01:00
|
|
|
menuconfig PCI
|
|
|
|
|
bool "PCI support"
|
|
|
|
|
depends on HAVE_PCI
|
|
|
|
|
help
|
|
|
|
|
This option enables support for the PCI local bus, including
|
|
|
|
|
support for PCI-X and the foundations for PCI Express support.
|
|
|
|
|
Say 'Y' here unless you know what you are doing.
|
|
|
|
|
|
2019-01-14 15:35:46 -06:00
|
|
|
if PCI
|
|
|
|
|
|
2018-11-15 20:05:33 +01:00
|
|
|
config PCI_DOMAINS
|
|
|
|
|
bool
|
|
|
|
|
depends on PCI
|
|
|
|
|
|
|
|
|
|
config PCI_DOMAINS_GENERIC
|
|
|
|
|
bool
|
|
|
|
|
select PCI_DOMAINS
|
|
|
|
|
|
2018-11-15 20:05:34 +01:00
|
|
|
config PCI_SYSCALL
|
|
|
|
|
bool
|
|
|
|
|
|
2016-02-03 13:24:22 -08:00
|
|
|
source "drivers/pci/pcie/Kconfig"
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
config PCI_MSI
|
|
|
|
|
bool "Message Signaled Interrupts (MSI and MSI-X)"
|
2014-11-12 12:11:25 +01:00
|
|
|
select GENERIC_MSI_IRQ
|
2005-04-16 15:20:36 -07: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-05 22:33:34 -07: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.
|
|
|
|
|
|
2010-04-08 09:38:47 -07:00
|
|
|
If you don't know what to do here, say Y.
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2020-08-26 13:17:02 +02:00
|
|
|
config PCI_MSI_ARCH_FALLBACKS
|
|
|
|
|
bool
|
|
|
|
|
|
2017-11-02 15:14:02 -07:00
|
|
|
config PCI_QUIRKS
|
|
|
|
|
default y
|
|
|
|
|
bool "Enable PCI quirk workarounds" if EXPERT
|
|
|
|
|
help
|
|
|
|
|
This enables workarounds for various PCI chipset bugs/quirks.
|
|
|
|
|
Disable this only if your target machine is unaffected by PCI
|
|
|
|
|
quirks.
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
config PCI_DEBUG
|
|
|
|
|
bool "PCI Debugging"
|
2019-01-14 15:35:46 -06:00
|
|
|
depends on DEBUG_KERNEL
|
2005-04-16 15:20:36 -07:00
|
|
|
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.
|
|
|
|
|
|
2012-02-23 19:23:32 -08:00
|
|
|
config PCI_REALLOC_ENABLE_AUTO
|
|
|
|
|
bool "Enable PCI resource re-allocation detection"
|
2017-09-20 08:44:20 +02:00
|
|
|
depends on PCI_IOV
|
2012-02-23 19:23:32 -08:00
|
|
|
help
|
|
|
|
|
Say Y here if you want the PCI core to detect if PCI resource
|
|
|
|
|
re-allocation needs to be enabled. You can always use pci=realloc=on
|
2017-09-20 08:44:20 +02:00
|
|
|
or pci=realloc=off to override it. It will automatically
|
|
|
|
|
re-allocate PCI resources if SR-IOV BARs have not been allocated by
|
|
|
|
|
the BIOS.
|
2012-02-23 19:23:32 -08:00
|
|
|
|
|
|
|
|
When in doubt, say N.
|
|
|
|
|
|
2008-11-25 21:17:13 -08:00
|
|
|
config PCI_STUB
|
|
|
|
|
tristate "PCI Stub driver"
|
|
|
|
|
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.
|
|
|
|
|
|
2018-04-24 16:47:16 -05:00
|
|
|
config PCI_PF_STUB
|
|
|
|
|
tristate "PCI PF Stub driver"
|
|
|
|
|
depends on PCI_IOV
|
|
|
|
|
help
|
|
|
|
|
Say Y or M here if you want to enable support for devices that
|
2018-11-05 14:53:21 -06:00
|
|
|
require SR-IOV support, while at the same time the PF (Physical
|
|
|
|
|
Function) itself is not providing any actual services on the
|
|
|
|
|
host itself such as storage or networking.
|
2018-04-24 16:47:16 -05:00
|
|
|
|
|
|
|
|
When in doubt, say N.
|
|
|
|
|
|
2010-08-02 21:31:05 -04:00
|
|
|
config XEN_PCIDEV_FRONTEND
|
2019-11-20 21:40:36 +08:00
|
|
|
tristate "Xen PCI Frontend"
|
2021-09-17 12:48:03 +02:00
|
|
|
depends on XEN_PV
|
2019-11-20 21:40:36 +08:00
|
|
|
select PCI_XEN
|
2010-12-10 22:33:15 -05:00
|
|
|
select XEN_XENBUS_FRONTEND
|
2019-11-20 21:40:36 +08:00
|
|
|
default y
|
|
|
|
|
help
|
|
|
|
|
The PCI device frontend driver allows the kernel to import arbitrary
|
|
|
|
|
PCI devices from a PCI backend to support PCI driver domains.
|
2010-08-02 21:31:05 -04:00
|
|
|
|
2011-09-27 15:57:13 +02:00
|
|
|
config PCI_ATS
|
|
|
|
|
bool
|
|
|
|
|
|
2022-07-19 13:52:46 -07:00
|
|
|
config PCI_DOE
|
|
|
|
|
bool
|
|
|
|
|
|
2016-05-10 17:19:51 +02:00
|
|
|
config PCI_ECAM
|
|
|
|
|
bool
|
|
|
|
|
|
2017-03-16 22:50:06 +01:00
|
|
|
config PCI_LOCKLESS_CONFIG
|
|
|
|
|
bool
|
|
|
|
|
|
2018-10-18 17:37:16 +02:00
|
|
|
config PCI_BRIDGE_EMUL
|
|
|
|
|
bool
|
2017-03-16 22:50:06 +01:00
|
|
|
|
2009-03-20 11:25:11 +08:00
|
|
|
config PCI_IOV
|
|
|
|
|
bool "PCI IOV support"
|
2011-09-27 15:57:13 +02:00
|
|
|
select PCI_ATS
|
2009-03-20 11:25:11 +08:00
|
|
|
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 11:20:47 -06:00
|
|
|
|
PCI/NPEM: Add Native PCIe Enclosure Management support
Native PCIe Enclosure Management (NPEM, PCIe r6.1 sec 6.28) allows managing
LEDs in storage enclosures. NPEM is indication oriented and it does not
give direct access to LEDs. Although each indication *could* represent an
individual LED, multiple indications could also be represented as a single,
multi-color LED or a single LED blinking in a specific interval. The
specification leaves that open.
Each enabled indication (capability register bit on) is represented as a
ledclass_dev which can be controlled through sysfs. For every ledclass
device only 2 brightness states are allowed: LED_ON (1) or LED_OFF (0).
This corresponds to the NPEM control register (Indication bit on/off).
Ledclass devices appear in sysfs as child devices (subdirectory) of PCI
device which has an NPEM Extended Capability and indication is enabled in
NPEM capability register. For example, these are LEDs created for pcieport
"10000:02:05.0" on my setup:
leds/
├── 10000:02:05.0:enclosure:fail
├── 10000:02:05.0:enclosure:locate
├── 10000:02:05.0:enclosure:ok
└── 10000:02:05.0:enclosure:rebuild
They can be also found in "/sys/class/leds" directory. The parent PCIe
device domain/bus/device/function address is used to guarantee uniqueness
across leds subsystem.
To enable/disable a "fail" indication, the "brightness" file can be edited:
echo 1 > ./leds/10000:02:05.0:enclosure:fail/brightness
echo 0 > ./leds/10000:02:05.0:enclosure:fail/brightness
PCIe r6.1, sec 7.9.19.2 defines the possible indications.
Multiple indications for same parent PCIe device can conflict and hardware
may update them when processing new request. To avoid issues, driver
refresh all indications by reading back control register.
This driver expects to be the exclusive NPEM extended capability manager.
It waits up to 1 second after imposing new request, it doesn't verify if
controller is busy before write, and it assumes the mutex lock gives
protection from concurrent updates.
If _DSM LED management is available, we assume the platform may be using
NPEM for its own purposes (see PCI Firmware Spec r3.3 sec 4.7), so the
driver does not use NPEM. A future patch will add _DSM support; an info
message notes whether NPEM or _DSM is being used.
NPEM is a PCIe extended capability so it should be registered in
pcie_init_capabilities() but it is not possible due to LED dependency. The
parent pci_device must be added earlier for led_classdev_register() to be
successful. NPEM does not require configuration on kernel side, so it is
safe to register LED devices later.
Link: https://lore.kernel.org/r/20240904104848.23480-3-mariusz.tkaczyk@linux.intel.com
Suggested-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-09-04 12:48:47 +02:00
|
|
|
config PCI_NPEM
|
|
|
|
|
bool "Native PCIe Enclosure Management"
|
|
|
|
|
depends on LEDS_CLASS=y
|
|
|
|
|
help
|
|
|
|
|
Support for Native PCIe Enclosure Management. It allows managing LED
|
|
|
|
|
indications in storage enclosures. Enclosure must support following
|
|
|
|
|
indications: OK, Locate, Fail, Rebuild, other indications are
|
|
|
|
|
optional.
|
|
|
|
|
|
2011-09-27 15:57:15 +02:00
|
|
|
config PCI_PRI
|
|
|
|
|
bool "PCI PRI support"
|
|
|
|
|
select PCI_ATS
|
|
|
|
|
help
|
|
|
|
|
PRI is the PCI Page Request Interface. It allows PCI devices that are
|
|
|
|
|
behind an IOMMU to recover from page faults.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2011-09-27 15:57:16 +02:00
|
|
|
config PCI_PASID
|
|
|
|
|
bool "PCI PASID support"
|
|
|
|
|
select PCI_ATS
|
|
|
|
|
help
|
|
|
|
|
Process Address Space Identifiers (PASIDs) can be used by PCI devices
|
|
|
|
|
to access more than one IO address space at the same time. To make
|
|
|
|
|
use of this feature an IOMMU is required which also supports PASIDs.
|
|
|
|
|
Select this option if you have such an IOMMU and want to compile the
|
|
|
|
|
driver for it into your kernel.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
PCI/P2PDMA: Support peer-to-peer memory
Some PCI devices may have memory mapped in a BAR space that's intended for
use in peer-to-peer transactions. To enable such transactions the memory
must be registered with ZONE_DEVICE pages so it can be used by DMA
interfaces in existing drivers.
Add an interface for other subsystems to find and allocate chunks of P2P
memory as necessary to facilitate transfers between two PCI peers:
struct pci_dev *pci_p2pmem_find[_many]();
int pci_p2pdma_distance[_many]();
void *pci_alloc_p2pmem();
The new interface requires a driver to collect a list of client devices
involved in the transaction then call pci_p2pmem_find() to obtain any
suitable P2P memory. Alternatively, if the caller knows a device which
provides P2P memory, they can use pci_p2pdma_distance() to determine if it
is usable. With a suitable p2pmem device, memory can then be allocated
with pci_alloc_p2pmem() for use in DMA transactions.
Depending on hardware, using peer-to-peer memory may reduce the bandwidth
of the transfer but can significantly reduce pressure on system memory.
This may be desirable in many cases: for example a system could be designed
with a small CPU connected to a PCIe switch by a small number of lanes
which would maximize the number of lanes available to connect to NVMe
devices.
The code is designed to only utilize the p2pmem device if all the devices
involved in a transfer are behind the same PCI bridge. This is because we
have no way of knowing whether peer-to-peer routing between PCIe Root Ports
is supported (PCIe r4.0, sec 1.3.1). Additionally, the benefits of P2P
transfers that go through the RC is limited to only reducing DRAM usage
and, in some cases, coding convenience. The PCI-SIG may be exploring
adding a new capability bit to advertise whether this is possible for
future hardware.
This commit includes significant rework and feedback from Christoph
Hellwig.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
[bhelgaas: fold in fix from Keith Busch <keith.busch@intel.com>:
https://lore.kernel.org/linux-pci/20181012155920.15418-1-keith.busch@intel.com,
to address comment from Dan Carpenter <dan.carpenter@oracle.com>, fold in
https://lore.kernel.org/linux-pci/20181017160510.17926-1-logang@deltatee.com]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-10-04 15:27:35 -06:00
|
|
|
config PCI_P2PDMA
|
|
|
|
|
bool "PCI peer-to-peer transfer support"
|
2019-01-14 15:35:46 -06:00
|
|
|
depends on ZONE_DEVICE
|
2022-07-08 10:50:52 -06:00
|
|
|
#
|
|
|
|
|
# The need for the scatterlist DMA bus address flag means PCI P2PDMA
|
|
|
|
|
# requires 64bit
|
|
|
|
|
#
|
|
|
|
|
depends on 64BIT
|
PCI/P2PDMA: Support peer-to-peer memory
Some PCI devices may have memory mapped in a BAR space that's intended for
use in peer-to-peer transactions. To enable such transactions the memory
must be registered with ZONE_DEVICE pages so it can be used by DMA
interfaces in existing drivers.
Add an interface for other subsystems to find and allocate chunks of P2P
memory as necessary to facilitate transfers between two PCI peers:
struct pci_dev *pci_p2pmem_find[_many]();
int pci_p2pdma_distance[_many]();
void *pci_alloc_p2pmem();
The new interface requires a driver to collect a list of client devices
involved in the transaction then call pci_p2pmem_find() to obtain any
suitable P2P memory. Alternatively, if the caller knows a device which
provides P2P memory, they can use pci_p2pdma_distance() to determine if it
is usable. With a suitable p2pmem device, memory can then be allocated
with pci_alloc_p2pmem() for use in DMA transactions.
Depending on hardware, using peer-to-peer memory may reduce the bandwidth
of the transfer but can significantly reduce pressure on system memory.
This may be desirable in many cases: for example a system could be designed
with a small CPU connected to a PCIe switch by a small number of lanes
which would maximize the number of lanes available to connect to NVMe
devices.
The code is designed to only utilize the p2pmem device if all the devices
involved in a transfer are behind the same PCI bridge. This is because we
have no way of knowing whether peer-to-peer routing between PCIe Root Ports
is supported (PCIe r4.0, sec 1.3.1). Additionally, the benefits of P2P
transfers that go through the RC is limited to only reducing DRAM usage
and, in some cases, coding convenience. The PCI-SIG may be exploring
adding a new capability bit to advertise whether this is possible for
future hardware.
This commit includes significant rework and feedback from Christoph
Hellwig.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
[bhelgaas: fold in fix from Keith Busch <keith.busch@intel.com>:
https://lore.kernel.org/linux-pci/20181012155920.15418-1-keith.busch@intel.com,
to address comment from Dan Carpenter <dan.carpenter@oracle.com>, fold in
https://lore.kernel.org/linux-pci/20181017160510.17926-1-logang@deltatee.com]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-10-04 15:27:35 -06:00
|
|
|
select GENERIC_ALLOCATOR
|
2023-06-12 16:31:56 +01:00
|
|
|
select NEED_SG_DMA_FLAGS
|
PCI/P2PDMA: Support peer-to-peer memory
Some PCI devices may have memory mapped in a BAR space that's intended for
use in peer-to-peer transactions. To enable such transactions the memory
must be registered with ZONE_DEVICE pages so it can be used by DMA
interfaces in existing drivers.
Add an interface for other subsystems to find and allocate chunks of P2P
memory as necessary to facilitate transfers between two PCI peers:
struct pci_dev *pci_p2pmem_find[_many]();
int pci_p2pdma_distance[_many]();
void *pci_alloc_p2pmem();
The new interface requires a driver to collect a list of client devices
involved in the transaction then call pci_p2pmem_find() to obtain any
suitable P2P memory. Alternatively, if the caller knows a device which
provides P2P memory, they can use pci_p2pdma_distance() to determine if it
is usable. With a suitable p2pmem device, memory can then be allocated
with pci_alloc_p2pmem() for use in DMA transactions.
Depending on hardware, using peer-to-peer memory may reduce the bandwidth
of the transfer but can significantly reduce pressure on system memory.
This may be desirable in many cases: for example a system could be designed
with a small CPU connected to a PCIe switch by a small number of lanes
which would maximize the number of lanes available to connect to NVMe
devices.
The code is designed to only utilize the p2pmem device if all the devices
involved in a transfer are behind the same PCI bridge. This is because we
have no way of knowing whether peer-to-peer routing between PCIe Root Ports
is supported (PCIe r4.0, sec 1.3.1). Additionally, the benefits of P2P
transfers that go through the RC is limited to only reducing DRAM usage
and, in some cases, coding convenience. The PCI-SIG may be exploring
adding a new capability bit to advertise whether this is possible for
future hardware.
This commit includes significant rework and feedback from Christoph
Hellwig.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
[bhelgaas: fold in fix from Keith Busch <keith.busch@intel.com>:
https://lore.kernel.org/linux-pci/20181012155920.15418-1-keith.busch@intel.com,
to address comment from Dan Carpenter <dan.carpenter@oracle.com>, fold in
https://lore.kernel.org/linux-pci/20181017160510.17926-1-logang@deltatee.com]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-10-04 15:27:35 -06:00
|
|
|
help
|
2022-07-20 15:22:03 +08:00
|
|
|
Enables drivers to do PCI peer-to-peer transactions to and from
|
PCI/P2PDMA: Support peer-to-peer memory
Some PCI devices may have memory mapped in a BAR space that's intended for
use in peer-to-peer transactions. To enable such transactions the memory
must be registered with ZONE_DEVICE pages so it can be used by DMA
interfaces in existing drivers.
Add an interface for other subsystems to find and allocate chunks of P2P
memory as necessary to facilitate transfers between two PCI peers:
struct pci_dev *pci_p2pmem_find[_many]();
int pci_p2pdma_distance[_many]();
void *pci_alloc_p2pmem();
The new interface requires a driver to collect a list of client devices
involved in the transaction then call pci_p2pmem_find() to obtain any
suitable P2P memory. Alternatively, if the caller knows a device which
provides P2P memory, they can use pci_p2pdma_distance() to determine if it
is usable. With a suitable p2pmem device, memory can then be allocated
with pci_alloc_p2pmem() for use in DMA transactions.
Depending on hardware, using peer-to-peer memory may reduce the bandwidth
of the transfer but can significantly reduce pressure on system memory.
This may be desirable in many cases: for example a system could be designed
with a small CPU connected to a PCIe switch by a small number of lanes
which would maximize the number of lanes available to connect to NVMe
devices.
The code is designed to only utilize the p2pmem device if all the devices
involved in a transfer are behind the same PCI bridge. This is because we
have no way of knowing whether peer-to-peer routing between PCIe Root Ports
is supported (PCIe r4.0, sec 1.3.1). Additionally, the benefits of P2P
transfers that go through the RC is limited to only reducing DRAM usage
and, in some cases, coding convenience. The PCI-SIG may be exploring
adding a new capability bit to advertise whether this is possible for
future hardware.
This commit includes significant rework and feedback from Christoph
Hellwig.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
[bhelgaas: fold in fix from Keith Busch <keith.busch@intel.com>:
https://lore.kernel.org/linux-pci/20181012155920.15418-1-keith.busch@intel.com,
to address comment from Dan Carpenter <dan.carpenter@oracle.com>, fold in
https://lore.kernel.org/linux-pci/20181017160510.17926-1-logang@deltatee.com]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-10-04 15:27:35 -06:00
|
|
|
BARs that are exposed in other devices that are the part of
|
|
|
|
|
the hierarchy where peer-to-peer DMA is guaranteed by the PCI
|
|
|
|
|
specification to work (ie. anything below a single PCI bridge).
|
|
|
|
|
|
|
|
|
|
Many PCIe root complexes do not support P2P transactions and
|
|
|
|
|
it's hard to tell which support it at all, so at this time,
|
2019-07-30 08:04:00 -05:00
|
|
|
P2P DMA transactions must be between devices behind the same root
|
PCI/P2PDMA: Support peer-to-peer memory
Some PCI devices may have memory mapped in a BAR space that's intended for
use in peer-to-peer transactions. To enable such transactions the memory
must be registered with ZONE_DEVICE pages so it can be used by DMA
interfaces in existing drivers.
Add an interface for other subsystems to find and allocate chunks of P2P
memory as necessary to facilitate transfers between two PCI peers:
struct pci_dev *pci_p2pmem_find[_many]();
int pci_p2pdma_distance[_many]();
void *pci_alloc_p2pmem();
The new interface requires a driver to collect a list of client devices
involved in the transaction then call pci_p2pmem_find() to obtain any
suitable P2P memory. Alternatively, if the caller knows a device which
provides P2P memory, they can use pci_p2pdma_distance() to determine if it
is usable. With a suitable p2pmem device, memory can then be allocated
with pci_alloc_p2pmem() for use in DMA transactions.
Depending on hardware, using peer-to-peer memory may reduce the bandwidth
of the transfer but can significantly reduce pressure on system memory.
This may be desirable in many cases: for example a system could be designed
with a small CPU connected to a PCIe switch by a small number of lanes
which would maximize the number of lanes available to connect to NVMe
devices.
The code is designed to only utilize the p2pmem device if all the devices
involved in a transfer are behind the same PCI bridge. This is because we
have no way of knowing whether peer-to-peer routing between PCIe Root Ports
is supported (PCIe r4.0, sec 1.3.1). Additionally, the benefits of P2P
transfers that go through the RC is limited to only reducing DRAM usage
and, in some cases, coding convenience. The PCI-SIG may be exploring
adding a new capability bit to advertise whether this is possible for
future hardware.
This commit includes significant rework and feedback from Christoph
Hellwig.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
[bhelgaas: fold in fix from Keith Busch <keith.busch@intel.com>:
https://lore.kernel.org/linux-pci/20181012155920.15418-1-keith.busch@intel.com,
to address comment from Dan Carpenter <dan.carpenter@oracle.com>, fold in
https://lore.kernel.org/linux-pci/20181017160510.17926-1-logang@deltatee.com]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-10-04 15:27:35 -06:00
|
|
|
port.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2011-03-29 09:45:57 -07:00
|
|
|
config PCI_LABEL
|
|
|
|
|
def_bool y if (DMI || ACPI)
|
|
|
|
|
select NLS
|
pci: PCIe driver for Marvell Armada 370/XP systems
This driver implements the support for the PCIe interfaces on the
Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to
cover earlier families of Marvell SoCs, such as Dove, Orion and
Kirkwood.
The driver implements the hw_pci operations needed by the core ARM PCI
code to setup PCI devices and get their corresponding IRQs, and the
pci_ops operations that are used by the PCI core to read/write the
configuration space of PCI devices.
Since the PCIe interfaces of Marvell SoCs are completely separate and
not linked together in a bus, this driver sets up an emulated PCI host
bridge, with one PCI-to-PCI bridge as child for each hardware PCIe
interface.
In addition, this driver enumerates the different PCIe slots, and for
those having a device plugged in, it sets up the necessary address
decoding windows, using the mvebu-mbus driver.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-05-16 17:55:22 +02:00
|
|
|
|
2016-02-16 21:56:23 +00:00
|
|
|
config PCI_HYPERV
|
2019-11-20 21:40:36 +08:00
|
|
|
tristate "Hyper-V PCI Frontend"
|
2022-11-11 14:54:38 +01:00
|
|
|
depends on ((X86 && X86_64) || ARM64) && HYPERV && PCI_MSI && SYSFS
|
2019-08-22 05:05:41 +00:00
|
|
|
select PCI_HYPERV_INTERFACE
|
2019-11-20 21:40:36 +08:00
|
|
|
help
|
|
|
|
|
The PCI device frontend driver allows the kernel to import arbitrary
|
|
|
|
|
PCI devices from a PCI backend to support PCI driver domains.
|
2016-02-16 21:56:23 +00:00
|
|
|
|
PCI: Create device tree node for bridge
The PCI endpoint device such as Xilinx Alveo PCI card maps the register
spaces from multiple hardware peripherals to its PCI BAR. Normally,
the PCI core discovers devices and BARs using the PCI enumeration process.
There is no infrastructure to discover the hardware peripherals that are
present in a PCI device, and which can be accessed through the PCI BARs.
Apparently, the device tree framework requires a device tree node for the
PCI device. Thus, it can generate the device tree nodes for hardware
peripherals underneath. Because PCI is self discoverable bus, there might
not be a device tree node created for PCI devices. Furthermore, if the PCI
device is hot pluggable, when it is plugged in, the device tree nodes for
its parent bridges are required. Add support to generate device tree node
for PCI bridges.
Add an of_pci_make_dev_node() interface that can be used to create device
tree node for PCI devices.
Add a PCI_DYNAMIC_OF_NODES config option. When the option is turned on,
the kernel will generate device tree nodes for PCI bridges unconditionally.
Initially, add the basic properties for the dynamically generated device
tree nodes which include #address-cells, #size-cells, device_type,
compatible, ranges, reg.
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://lore.kernel.org/r/1692120000-46900-3-git-send-email-lizhi.hou@amd.com
Signed-off-by: Rob Herring <robh@kernel.org>
2023-08-15 10:19:57 -07:00
|
|
|
config PCI_DYNAMIC_OF_NODES
|
|
|
|
|
bool "Create Device tree nodes for PCI devices"
|
2023-08-31 11:19:07 -07:00
|
|
|
depends on OF_IRQ
|
PCI: Create device tree node for bridge
The PCI endpoint device such as Xilinx Alveo PCI card maps the register
spaces from multiple hardware peripherals to its PCI BAR. Normally,
the PCI core discovers devices and BARs using the PCI enumeration process.
There is no infrastructure to discover the hardware peripherals that are
present in a PCI device, and which can be accessed through the PCI BARs.
Apparently, the device tree framework requires a device tree node for the
PCI device. Thus, it can generate the device tree nodes for hardware
peripherals underneath. Because PCI is self discoverable bus, there might
not be a device tree node created for PCI devices. Furthermore, if the PCI
device is hot pluggable, when it is plugged in, the device tree nodes for
its parent bridges are required. Add support to generate device tree node
for PCI bridges.
Add an of_pci_make_dev_node() interface that can be used to create device
tree node for PCI devices.
Add a PCI_DYNAMIC_OF_NODES config option. When the option is turned on,
the kernel will generate device tree nodes for PCI bridges unconditionally.
Initially, add the basic properties for the dynamically generated device
tree nodes which include #address-cells, #size-cells, device_type,
compatible, ranges, reg.
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://lore.kernel.org/r/1692120000-46900-3-git-send-email-lizhi.hou@amd.com
Signed-off-by: Rob Herring <robh@kernel.org>
2023-08-15 10:19:57 -07:00
|
|
|
select OF_DYNAMIC
|
|
|
|
|
help
|
|
|
|
|
This option enables support for generating device tree nodes for some
|
|
|
|
|
PCI devices. Thus, the driver of this kind can load and overlay
|
|
|
|
|
flattened device tree for its downstream devices.
|
|
|
|
|
|
|
|
|
|
Once this option is selected, the device tree nodes will be generated
|
|
|
|
|
for all PCI bridges.
|
|
|
|
|
|
2020-09-28 15:46:51 -04:00
|
|
|
choice
|
|
|
|
|
prompt "PCI Express hierarchy optimization setting"
|
|
|
|
|
default PCIE_BUS_DEFAULT
|
|
|
|
|
depends on PCI && EXPERT
|
|
|
|
|
help
|
|
|
|
|
MPS (Max Payload Size) and MRRS (Max Read Request Size) are PCIe
|
|
|
|
|
device parameters that affect performance and the ability to
|
|
|
|
|
support hotplug and peer-to-peer DMA.
|
|
|
|
|
|
|
|
|
|
The following choices set the MPS and MRRS optimization strategy
|
|
|
|
|
at compile-time. The choices are the same as those offered for
|
|
|
|
|
the kernel command-line parameter 'pci', i.e.,
|
|
|
|
|
'pci=pcie_bus_tune_off', 'pci=pcie_bus_safe',
|
|
|
|
|
'pci=pcie_bus_perf', and 'pci=pcie_bus_peer2peer'.
|
|
|
|
|
|
|
|
|
|
This is a compile-time setting and can be overridden by the above
|
|
|
|
|
command-line parameters. If unsure, choose PCIE_BUS_DEFAULT.
|
|
|
|
|
|
|
|
|
|
config PCIE_BUS_TUNE_OFF
|
|
|
|
|
bool "Tune Off"
|
|
|
|
|
depends on PCI
|
|
|
|
|
help
|
|
|
|
|
Use the BIOS defaults; don't touch MPS at all. This is the same
|
|
|
|
|
as booting with 'pci=pcie_bus_tune_off'.
|
|
|
|
|
|
|
|
|
|
config PCIE_BUS_DEFAULT
|
|
|
|
|
bool "Default"
|
|
|
|
|
depends on PCI
|
|
|
|
|
help
|
|
|
|
|
Default choice; ensure that the MPS matches upstream bridge.
|
|
|
|
|
|
|
|
|
|
config PCIE_BUS_SAFE
|
|
|
|
|
bool "Safe"
|
|
|
|
|
depends on PCI
|
|
|
|
|
help
|
|
|
|
|
Use largest MPS that boot-time devices support. If you have a
|
|
|
|
|
closed system with no possibility of adding new devices, this
|
|
|
|
|
will use the largest MPS that's supported by all devices. This
|
|
|
|
|
is the same as booting with 'pci=pcie_bus_safe'.
|
|
|
|
|
|
|
|
|
|
config PCIE_BUS_PERFORMANCE
|
|
|
|
|
bool "Performance"
|
|
|
|
|
depends on PCI
|
|
|
|
|
help
|
|
|
|
|
Use MPS and MRRS for best performance. Ensure that a given
|
|
|
|
|
device's MPS is no larger than its parent MPS, which allows us to
|
|
|
|
|
keep all switches/bridges to the max MPS supported by their
|
|
|
|
|
parent. This is the same as booting with 'pci=pcie_bus_perf'.
|
|
|
|
|
|
|
|
|
|
config PCIE_BUS_PEER2PEER
|
|
|
|
|
bool "Peer2peer"
|
|
|
|
|
depends on PCI
|
|
|
|
|
help
|
|
|
|
|
Set MPS = 128 for all devices. MPS configuration effected by the
|
|
|
|
|
other options could cause the MPS on one root port to be
|
|
|
|
|
different than that of the MPS on another, which may cause
|
|
|
|
|
hot-added devices or peer-to-peer DMA to fail. Set MPS to the
|
|
|
|
|
smallest possible value (128B) system-wide to avoid these issues.
|
|
|
|
|
This is the same as booting with 'pci=pcie_bus_peer2peer'.
|
|
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
|
2022-02-24 16:47:43 -06:00
|
|
|
config VGA_ARB
|
|
|
|
|
bool "VGA Arbitration" if EXPERT
|
|
|
|
|
default y
|
|
|
|
|
depends on (PCI && !S390)
|
|
|
|
|
help
|
|
|
|
|
Some "legacy" VGA devices implemented on PCI typically have the same
|
|
|
|
|
hard-decoded addresses as they did on ISA. When multiple PCI devices
|
|
|
|
|
are accessed at same time they need some kind of coordination. Please
|
|
|
|
|
see Documentation/gpu/vgaarbiter.rst for more details. Select this to
|
|
|
|
|
enable VGA arbiter.
|
|
|
|
|
|
|
|
|
|
config VGA_ARB_MAX_GPUS
|
|
|
|
|
int "Maximum number of GPUs"
|
|
|
|
|
default 16
|
|
|
|
|
depends on VGA_ARB
|
|
|
|
|
help
|
|
|
|
|
Reserves space in the kernel to maintain resource locking for
|
|
|
|
|
multiple GPUS. The overhead for each GPU is very small.
|
|
|
|
|
|
2016-03-21 09:26:41 +02:00
|
|
|
source "drivers/pci/hotplug/Kconfig"
|
2018-05-31 09:12:37 +08:00
|
|
|
source "drivers/pci/controller/Kconfig"
|
2017-04-10 19:25:10 +05:30
|
|
|
source "drivers/pci/endpoint/Kconfig"
|
2017-03-06 18:30:54 -06:00
|
|
|
source "drivers/pci/switch/Kconfig"
|
2024-06-12 10:20:17 +02:00
|
|
|
source "drivers/pci/pwrctl/Kconfig"
|
2019-01-14 15:35:46 -06:00
|
|
|
|
|
|
|
|
endif
|