There is some NTB hardware, which can combine more than just two domains
over NTB. For instance, some IDT PCIe-switches can have NTB-functions
activated on more than two-ports. The different domains are distinguished
by ports they are connected to. So the new port-related methods are added to
the NTB API:
ntb_port_number() - return local port
ntb_peer_port_count() - return number of peers local port can connect to
ntb_peer_port_number(pdix) - return port number by it index
ntb_peer_port_idx(port) - return port index by it number
Current test-drivers aren't changed much. They still support two-ports devices
for the time being while multi-ports hardware drivers aren't added.
By default port-related API is declared for two-ports hardware.
So corresponding hardware drivers won't need to implement it.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Since link operations are usually performed before memory window access
operations, it's logically better to declare link-related API before any
of MW/Doorbell/Scratchpad methods.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
Signed-off-by: Jon Mason <jdmason@kudzu.us>
and correcting a free_irq inconsistency. It adds Intel SKX support.
Finally, it changes the AMD NTB maintainer, and fixes some bugs present
there.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJYXpoNAAoJEG5mS6x6i9IjKZkP/irnIN87sQQcNKoIJJGco4Xc
0S4PwU+E4/dP58f1Pi+9EdxhItXnksIBuGFFdvNYkbBH/pC7e6y8TD3oCmMvXBEG
Qbl9RNB8boI6TZuM2FLtjAUTD6QKqBpubEq9xzRV4/tM/94//JvK8wVvBGAl0z8s
85kUVrNVY2ahntEgldCXPbX8ONNpYeUdm+YEv0whclAvN1nYxZAfSWA/G21I7VbI
TH2PjkYy9R+pJglO9Xl0nBj/YG6/LZZnS37sQLAhgIvMb7NIBhpsXCb63lwKo75e
Sp0p+T+AF9Ax7//g34mljLjtXSEgyOiIfSJrmUa+f/WS1LU8CUI6Z5memo7vEWPW
FRd9t1NLEd4fZJThQKsFgZpAcKpFQPRT4hf9eGlK5N5e2/jFjJQx1KGEtU3RCHA6
UrI+ddU57qwwuD4Rbw8PW1fulsEh7lBmyoIFnTiYnkHffzmqL5e5XX9ODSr9Fctj
c/loucgTMz7T0cgyz3ws8we+HF3o8hzK1gyK3DzRQ46s+PQr46LycLSEFzmqhkHh
9KqvcJMIJNxxy3nn46Ag1W8yO60Ik6Kz0ujPcaDhpaxpLybVJqHSR5X0n98cf8NZ
vPktqMN0b4HGVjIracacvfsT/UhLZpooZTrl+jwrd/iGM0Xqu/VpMVkiRNrcNjSN
Pz6Oxtho25CZVcU1Nxi3
=F0Rd
-----END PGP SIGNATURE-----
Merge tag 'ntb-4.10' of git://github.com/jonmason/ntb
Pull NTB update from Jon Mason:
- NTB bug fixes for removing an unnecessary call to ntb_peer_spad_read,
and correcting a free_irq inconsistency
- add Intel SKX support
- change the AMD NTB maintainer, and fix some bugs present there
* tag 'ntb-4.10' of git://github.com/jonmason/ntb:
ntb_transport: Remove unnecessary call to ntb_peer_spad_read
NTB: Fix 'request_irq()' and 'free_irq()' inconsistancy
ntb: fix SKX NTB config space size register offsets
NTB: correct ntb_peer_spad_read for case when callback is not supplied.
MAINTAINERS: Change in maintainer for AMD NTB
ntb_transport: Limit memory windows based on available, scratchpads
NTB: Register and offset values fix for memory window
NTB: add support for hotplug feature
ntb: Adding Skylake Xeon NTB support
Correct ntb_peer_spad_read for case when callback is not supplied
Signed-off-by: Steve Wahl <Steve.Wahl@dell.com>
Acked-by: Allen Hubbe <Allen.Hubbe@dell.com>
Signed-off-by: Jon Mason <jdmason@kudzu.us>
The comment for ntb_spad_count incorrectly referred to ntb_mw_count.
Signed-off-by: Aaron Sierra <asierra@xes-inc.com>
Acked-by: Allen Hubbe <Allen.Hubbe@dell.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The functions ntb_peer_db_addr and ntb_peer_spad_addr were required by
the api. The functions already support returning an error, so any
existing calling code should already check for it. Any existing code
using drivers that implement the functions will not be affected.
Signed-off-by: Allen Hubbe <Allen.Hubbe@emc.com>
Signed-off-by: Jon Mason <jdmason@kudzu.us>
The documentation should say "peer" not "local" when referring to the
peer doorbell register.
Reported-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Allen Hubbe <Allen.Hubbe@emc.com>
Signed-off-by: Jon Mason <jdmason@kudzu.us>
There was a copy and paste error in the documentation for
ntb_link_is_up. The long description was mistakenly copied from
ntb_link_set_trans.
This adds the appropriate long description for ntb_link_is_up.
Reported-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Allen Hubbe <Allen.Hubbe@emc.com>
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Abstract the NTB device behind a programming interface, so that it can
support different hardware and client drivers.
Signed-off-by: Allen Hubbe <Allen.Hubbe@emc.com>
Signed-off-by: Jon Mason <jdmason@kudzu.us>
This patch only moves files to their new locations, before applying the
next two patches adding the NTB Abstraction layer. Splitting this patch
from the next is intended make distinct which code is changed only due
to moving the files, versus which are substantial code changes in adding
the NTB Abstraction layer.
Signed-off-by: Allen Hubbe <Allen.Hubbe@emc.com>
Signed-off-by: Jon Mason <jdmason@kudzu.us>
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>
Serge Semin