summaryrefslogtreecommitdiffstats
path: root/drivers/ntb/ntb_regs.h
Commit message (Collapse)AuthorAgeFilesLines
* ntb: Adding split BAR support for Haswell platformsDave Jiang2014-10-171-8/+23
| | | | | | | | | 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>
* NTB: debugfs device entryJon Mason2014-10-171-2/+5
| | | | | | | 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>
* NTB: Enable Snoop on Primary SideJon Mason2013-11-201-5/+7
| | | | | | | | | | Enable Snoop from Primary to Secondary side on BAR23 and BAR45 on all TLPs. Previously, Snoop was only enabled from Secondary to Primary side. This can have a performance improvement on some workloads. Also, make the code more obvious about how the link is being enabled. Signed-off-by: Jon Mason <jon.mason@intel.com>
* NTB: remove duplicate definesMichael Opdenacker2013-11-201-3/+0
| | | | | | | Remove duplicate defines in drivers/ntb/ntb_regs.h Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com> Signed-off-by: Jon Mason <jon.mason@intel.com>
* NTB: Xeon Doorbell errata workaroundJon Mason2013-11-201-0/+1
| | | | | | | | | | | | | | Modifications to the 14th bit of the B2BDOORBELL register will not be mirrored to the remote system due to a hardware issue. To get around the issue, shrink the number of available doorbell bits by 1. The max number of doorbells was being used as a way to referencing the Link Doorbell bit. Since this would no longer work, the driver must now explicitly reference that bit. This does not affect the xeon_errata_workaround case, as it is not using the b2bdoorbell register. Signed-off-by: Jon Mason <jon.mason@intel.com>
* NTB: Remove References of non-B2B BWD HWJon Mason2013-09-051-1/+0
| | | | | | | NTB-RP is not a supported configuration on BWD hardware. Remove the code attempting to set it up. Signed-off-by: Jon Mason <jon.mason@intel.com>
* NTB: NTB-RP supportJon Mason2013-09-051-2/+3
| | | | | | | | | | | | | | | | | | | | | | Add support for Non-Transparent Bridge connected to a PCI-E Root Port on the remote system (also known as NTB-RP mode). This allows for a NTB enabled system to be connected to a non-NTB enabled system/slot. Modifications to the registers and BARs/MWs on the Secondary side by the remote system are reflected into registers on the Primary side for the local system. Similarly, modifications of registers and BARs/MWs on Primary side by the local system are reflected into registers on the Secondary side for the Remote System. This allows communication between the 2 sides via these registers and BARs/MWs. Note: there is not a fix for the Xeon Errata (that was already worked around in NTB-B2B mode) for NTB-RP mode. Due to this limitation, NTB-RP will not work on the Secondary side with the Xeon Errata workaround enabled. To get around this, disable the workaround via the xeon_errata_workaround=0 modparm. However, this can cause the hang described in the errata. Signed-off-by: Jon Mason <jon.mason@intel.com>
* NTB: BWD Link RecoveryJon Mason2013-09-031-0/+15
| | | | | | | | | | | | | | | 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>
* NTB: Xeon Errata WorkaroundJon Mason2013-09-031-10/+15
| | | | | | | | | | | | | | | | | | | | 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>
* NTB: Correct Number of Scratch Pad RegistersJon Mason2013-09-031-2/+2
| | | | | | | | The NTB Xeon hardware has 16 scratch pad registers and 16 back-to-back scratch pad registers. Correct the #define to represent this and update the variable names to reflect their usage. Signed-off-by: Jon Mason <jon.mason@intel.com>
* PCI-Express Non-Transparent Bridge SupportJon Mason2013-01-171-0/+139
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>
OpenPOWER on IntegriCloud