aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/ntb/ntb_hw.h (follow)
AgeCommit message (Collapse)AuthorFilesLines
2014-10-17ntb: Adding split BAR support for Haswell platformsDave Jiang1-5/+9
On the Haswell platform, a split BAR option to allow creation of 2 32bit BARs (4 and 5) from the 64bit BAR 4. Adding support for this new option. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Jon Mason <jdmason@kudzu.us>
2014-10-17ntb: use errata flag set via DID to implement workaroundDave Jiang1-0/+4
Instead of using a module parameter, we should detect the errata via PCI DID and then set an appropriate flag. This will be used for additional errata later on. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Jon Mason <jdmason@kudzu.us>
2014-10-17NTB: debugfs device entryJon Mason1-0/+1
Create a debugfs entry for the NTB device to log the basic device info, as well as display the error count on a number of registers. Signed-off-by: Jon Mason <jon.mason@intel.com>
2014-04-07ntb: Use pci_msix_vec_count() to obtain number of MSI-XsAlexander Gordeev1-2/+0
Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Signed-off-by: Jon Mason <jon.mason@intel.com>
2014-04-07NTB: Code Style Clean-upJon Mason1-1/+1
Some white space and 80 char overruns corrected. Signed-off-by: Jon Mason <jon.mason@intel.com>
2014-04-07NTB: client event cleanupJon Mason1-3/+1
Provide a better event interface between the client and transport Signed-off-by: Jon Mason <jon.mason@intel.com>
2013-11-20NTB: Disable interrupts and poll under high loadJon Mason1-3/+4
Disable interrupts and poll under high load Signed-off-by: Jon Mason <jon.mason@intel.com>
2013-09-05NTB: Rename Variables for NTB-RPJon Mason1-6/+6
Many variable names in the NTB driver refer to the primary or secondary side. However, these variables will be used to access the reverse case when in NTB-RP mode. Make these names more generic in anticipation of NTB-RP support. Signed-off-by: Jon Mason <jon.mason@intel.com>
2013-09-05NTB: Use DMA Engine to Transmit and ReceiveJon Mason1-0/+1
Allocate and use a DMA engine channel to transmit and receive data over NTB. If none is allocated, fall back to using the CPU to transfer data. Signed-off-by: Jon Mason <jon.mason@intel.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com>
2013-09-03NTB: Enable 32bit SupportJon Mason1-1/+16
Correct the issues on NTB that prevented it from working on x86_32 and modify the Kconfig to allow it to be permitted to be used in that environment as well. Signed-off-by: Jon Mason <jon.mason@intel.com>
2013-09-03NTB: Update Device IDsJon Mason1-5/+10
Add support for new Intel NTB devices on upcoming Xeon hardware. Since the Xeon hardware design is already in place in the driver, all that is needed are the new device ids. Remove the device IDs for NTB devs running in Transparent Bridge mode, as this driver is not being used for those devices. Rename the device IDs for NTB devs running in NTB-RP mode to better identify their usage model. "PS" to denote the Primary Side of NTB, and "SS" to denote the secondary side. The primary side is the interface exposed to the local system, and the secondary side is the interface exposed to the remote system. Signed-off-by: Jon Mason <jon.mason@intel.com>
2013-09-03NTB: BWD Link RecoveryJon Mason1-0/+5
The BWD NTB device will drop the link if an error is encountered on the point-to-point PCI bridge. The link will stay down until all errors are cleared and the link is re-established. On link down, check to see if the error is detected, if so do the necessary housekeeping to try and recover from the error and reestablish the link. There is a potential race between the 2 NTB devices recovering at the same time. If the times are synchronized, the link will not recover and the driver will be stuck in this loop forever. Add a random interval to the recovery time to prevent this race. Signed-off-by: Jon Mason <jon.mason@intel.com>
2013-09-03NTB: Xeon Errata WorkaroundJon Mason1-6/+33
There is a Xeon hardware errata related to writes to SDOORBELL or B2BDOORBELL in conjunction with inbound access to NTB MMIO Space, which may hang the system. To workaround this issue, use one of the memory windows to access the interrupt and scratch pad registers on the remote system. This bypasses the issue, but removes one of the memory windows from use by the transport. This reduction of MWs necessitates adding some logic to determine the number of available MWs. Since some NTB usage methodologies may have unidirectional traffic, the ability to disable the workaround via modparm has been added. See BF113 in http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-c5500-c3500-spec-update.pdf See BT119 in http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-e5-family-spec-update.pdf Signed-off-by: Jon Mason <jon.mason@intel.com>
2013-09-03NTB: Correct debugfs to work with more than 1 NTB DeviceJon Mason1-0/+16
Debugfs was setup in NTB to only have a single debugfs directory. This resulted in the leaking of debugfs directories and files when multiple NTB devices were present, due to each device stomping on the variables containing the previous device's values (thus preventing them from being freed on cleanup). Correct this by creating a secondary directory of the PCI BDF for each device present, and nesting the previously existing information in those directories. Signed-off-by: Jon Mason <jon.mason@intel.com>
2013-01-21NTB: Fix Sparse WarningsJon Mason1-2/+2
Address the sparse warnings and resulting fallout Signed-off-by: Jon Mason <jon.mason@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-17PCI-Express Non-Transparent Bridge SupportJon Mason1-0/+181
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>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.