2019-05-19 12:07:45 +00:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
2015-04-09 14:33:20 +00:00
|
|
|
menuconfig NTB
|
|
|
|
|
tristate "Non-Transparent Bridge support"
|
|
|
|
|
depends on PCI
|
|
|
|
|
help
|
|
|
|
|
The PCI-E Non-transparent bridge hardware is a point-to-point PCI-E bus
|
|
|
|
|
connecting 2 systems. When configured, writes to the device's PCI
|
|
|
|
|
mapped memory will be mirrored to a buffer on the remote system. The
|
|
|
|
|
ntb Linux driver uses this point-to-point communication as a method to
|
|
|
|
|
transfer data from one system to the other.
|
PCI-Express Non-Transparent Bridge Support
A PCI-Express non-transparent bridge (NTB) is a point-to-point PCIe bus
connecting 2 systems, providing electrical isolation between the two subsystems.
A non-transparent bridge is functionally similar to a transparent bridge except
that both sides of the bridge have their own independent address domains. The
host on one side of the bridge will not have the visibility of the complete
memory or I/O space on the other side of the bridge. To communicate across the
non-transparent bridge, each NTB endpoint has one (or more) apertures exposed to
the local system. Writes to these apertures are mirrored to memory on the
remote system. Communications can also occur through the use of doorbell
registers that initiate interrupts to the alternate domain, and scratch-pad
registers accessible from both sides.
The NTB device driver is needed to configure these memory windows, doorbell, and
scratch-pad registers as well as use them in such a way as they can be turned
into a viable communication channel to the remote system. ntb_hw.[ch]
determines the usage model (NTB to NTB or NTB to Root Port) and abstracts away
the underlying hardware to provide access and a common interface to the doorbell
registers, scratch pads, and memory windows. These hardware interfaces are
exported so that other, non-mainlined kernel drivers can access these.
ntb_transport.[ch] also uses the exported interfaces in ntb_hw.[ch] to setup a
communication channel(s) and provide a reliable way of transferring data from
one side to the other, which it then exports so that "client" drivers can access
them. These client drivers are used to provide a standard kernel interface
(i.e., Ethernet device) to NTB, such that Linux can transfer data from one
system to the other in a standard way.
Signed-off-by: Jon Mason <jon.mason@intel.com>
Reviewed-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17 02:27:12 +00:00
|
|
|
|
2015-04-09 14:33:20 +00:00
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
if NTB
|
|
|
|
|
|
2019-05-23 22:30:56 +00:00
|
|
|
config NTB_MSI
|
|
|
|
|
bool "MSI Interrupt Support"
|
|
|
|
|
depends on PCI_MSI
|
|
|
|
|
help
|
|
|
|
|
Support using MSI interrupt forwarding instead of (or in addition to)
|
|
|
|
|
hardware doorbells. MSI interrupts typically offer lower latency
|
|
|
|
|
than doorbells and more MSI interrupts can be made available to
|
|
|
|
|
clients. However this requires an extra memory window and support
|
|
|
|
|
in the hardware driver for creating the MSI interrupts.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
2015-04-09 14:33:20 +00:00
|
|
|
source "drivers/ntb/hw/Kconfig"
|
|
|
|
|
|
2015-04-15 15:12:41 +00:00
|
|
|
source "drivers/ntb/test/Kconfig"
|
|
|
|
|
|
2015-04-09 14:33:20 +00:00
|
|
|
config NTB_TRANSPORT
|
|
|
|
|
tristate "NTB Transport Client"
|
|
|
|
|
help
|
|
|
|
|
This is a transport driver that enables connected systems to exchange
|
|
|
|
|
messages over the ntb hardware. The transport exposes a queue pair api
|
|
|
|
|
to client drivers.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
endif # NTB
|
