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 06:27:12 +04:00
|
|
|
/*
|
|
|
|
* This file is provided under a dual BSD/GPLv2 license. When using or
|
|
|
|
* redistributing this file, you may do so under either license.
|
|
|
|
*
|
|
|
|
* GPL LICENSE SUMMARY
|
|
|
|
*
|
|
|
|
* Copyright(c) 2012 Intel Corporation. All rights reserved.
|
2015-04-09 17:33:20 +03:00
|
|
|
* Copyright (C) 2015 EMC Corporation. All Rights Reserved.
|
2017-01-11 03:11:33 +03:00
|
|
|
* Copyright (C) 2016 T-Platforms. All Rights Reserved.
|
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 06:27:12 +04:00
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of version 2 of the GNU General Public License as
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*
|
|
|
|
* BSD LICENSE
|
|
|
|
*
|
|
|
|
* Copyright(c) 2012 Intel Corporation. All rights reserved.
|
2015-04-09 17:33:20 +03:00
|
|
|
* Copyright (C) 2015 EMC Corporation. All Rights Reserved.
|
2017-01-11 03:11:33 +03:00
|
|
|
* Copyright (C) 2016 T-Platforms. All Rights Reserved.
|
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 06:27:12 +04:00
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
*
|
|
|
|
* * Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* * Redistributions in binary form must reproduce the above copy
|
|
|
|
* notice, this list of conditions and the following disclaimer in
|
|
|
|
* the documentation and/or other materials provided with the
|
|
|
|
* distribution.
|
|
|
|
* * Neither the name of Intel Corporation nor the names of its
|
|
|
|
* contributors may be used to endorse or promote products derived
|
|
|
|
* from this software without specific prior written permission.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
|
|
|
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
|
|
|
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
|
|
|
|
* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
|
|
|
|
* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
|
|
|
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
|
|
|
|
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
|
|
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
|
|
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
|
|
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
|
|
|
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
*
|
|
|
|
* Intel PCIe NTB Linux driver
|
|
|
|
*
|
|
|
|
* Contact Information:
|
|
|
|
* Jon Mason <jon.mason@intel.com>
|
|
|
|
*/
|
2015-04-09 17:33:20 +03:00
|
|
|
|
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 06:27:12 +04:00
|
|
|
#include <linux/debugfs.h>
|
2012-11-17 05:52:57 +04:00
|
|
|
#include <linux/delay.h>
|
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 06:27:12 +04:00
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/interrupt.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/pci.h>
|
2012-11-17 05:52:57 +04:00
|
|
|
#include <linux/random.h>
|
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 06:27:12 +04:00
|
|
|
#include <linux/slab.h>
|
2015-04-09 17:33:20 +03:00
|
|
|
#include <linux/ntb.h>
|
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
#include "ntb_hw_intel.h"
|
2018-01-29 23:22:18 +03:00
|
|
|
#include "ntb_hw_gen1.h"
|
|
|
|
#include "ntb_hw_gen3.h"
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
#define NTB_NAME "ntb_hw_intel"
|
|
|
|
#define NTB_DESC "Intel(R) PCI-E Non-Transparent Bridge Driver"
|
|
|
|
#define NTB_VER "2.0"
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
MODULE_DESCRIPTION(NTB_DESC);
|
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 06:27:12 +04:00
|
|
|
MODULE_VERSION(NTB_VER);
|
|
|
|
MODULE_LICENSE("Dual BSD/GPL");
|
|
|
|
MODULE_AUTHOR("Intel Corporation");
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
#define bar0_off(base, bar) ((base) + ((bar) << 2))
|
|
|
|
#define bar2_off(base, bar) bar0_off(base, (bar) - 2)
|
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
static const struct intel_ntb_reg xeon_reg;
|
|
|
|
static const struct intel_ntb_alt_reg xeon_pri_reg;
|
|
|
|
static const struct intel_ntb_alt_reg xeon_sec_reg;
|
|
|
|
static const struct intel_ntb_alt_reg xeon_b2b_reg;
|
|
|
|
static const struct intel_ntb_xlat_reg xeon_pri_xlat;
|
|
|
|
static const struct intel_ntb_xlat_reg xeon_sec_xlat;
|
2015-04-09 17:33:20 +03:00
|
|
|
static const struct ntb_dev_ops intel_ntb_ops;
|
|
|
|
|
|
|
|
static const struct file_operations intel_ntb_debugfs_info;
|
2013-07-31 02:58:49 +04:00
|
|
|
static struct dentry *debugfs_dir;
|
|
|
|
|
2015-05-11 12:45:30 +03:00
|
|
|
static int b2b_mw_idx = -1;
|
|
|
|
module_param(b2b_mw_idx, int, 0644);
|
|
|
|
MODULE_PARM_DESC(b2b_mw_idx, "Use this mw idx to access the peer ntb. A "
|
|
|
|
"value of zero or positive starts from first mw idx, and a "
|
|
|
|
"negative value starts from last mw idx. Both sides MUST "
|
|
|
|
"set the same value here!");
|
|
|
|
|
|
|
|
static unsigned int b2b_mw_share;
|
|
|
|
module_param(b2b_mw_share, uint, 0644);
|
|
|
|
MODULE_PARM_DESC(b2b_mw_share, "If the b2b mw is large enough, configure the "
|
|
|
|
"ntb so that the peer ntb only occupies the first half of "
|
|
|
|
"the mw, so the second half can still be used as a mw. Both "
|
|
|
|
"sides MUST set the same value here!");
|
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
module_param_named(xeon_b2b_usd_bar2_addr64,
|
|
|
|
xeon_b2b_usd_addr.bar2_addr64, ullong, 0644);
|
|
|
|
MODULE_PARM_DESC(xeon_b2b_usd_bar2_addr64,
|
|
|
|
"XEON B2B USD BAR 2 64-bit address");
|
|
|
|
|
|
|
|
module_param_named(xeon_b2b_usd_bar4_addr64,
|
|
|
|
xeon_b2b_usd_addr.bar4_addr64, ullong, 0644);
|
2016-08-08 12:48:42 +03:00
|
|
|
MODULE_PARM_DESC(xeon_b2b_usd_bar4_addr64,
|
2015-05-20 19:55:47 +03:00
|
|
|
"XEON B2B USD BAR 4 64-bit address");
|
|
|
|
|
|
|
|
module_param_named(xeon_b2b_usd_bar4_addr32,
|
|
|
|
xeon_b2b_usd_addr.bar4_addr32, ullong, 0644);
|
2016-08-08 12:48:42 +03:00
|
|
|
MODULE_PARM_DESC(xeon_b2b_usd_bar4_addr32,
|
2015-05-20 19:55:47 +03:00
|
|
|
"XEON B2B USD split-BAR 4 32-bit address");
|
|
|
|
|
|
|
|
module_param_named(xeon_b2b_usd_bar5_addr32,
|
|
|
|
xeon_b2b_usd_addr.bar5_addr32, ullong, 0644);
|
2016-08-08 12:48:42 +03:00
|
|
|
MODULE_PARM_DESC(xeon_b2b_usd_bar5_addr32,
|
2015-05-20 19:55:47 +03:00
|
|
|
"XEON B2B USD split-BAR 5 32-bit address");
|
|
|
|
|
|
|
|
module_param_named(xeon_b2b_dsd_bar2_addr64,
|
|
|
|
xeon_b2b_dsd_addr.bar2_addr64, ullong, 0644);
|
|
|
|
MODULE_PARM_DESC(xeon_b2b_dsd_bar2_addr64,
|
|
|
|
"XEON B2B DSD BAR 2 64-bit address");
|
|
|
|
|
|
|
|
module_param_named(xeon_b2b_dsd_bar4_addr64,
|
|
|
|
xeon_b2b_dsd_addr.bar4_addr64, ullong, 0644);
|
2016-08-08 12:48:42 +03:00
|
|
|
MODULE_PARM_DESC(xeon_b2b_dsd_bar4_addr64,
|
2015-05-20 19:55:47 +03:00
|
|
|
"XEON B2B DSD BAR 4 64-bit address");
|
|
|
|
|
|
|
|
module_param_named(xeon_b2b_dsd_bar4_addr32,
|
|
|
|
xeon_b2b_dsd_addr.bar4_addr32, ullong, 0644);
|
2016-08-08 12:48:42 +03:00
|
|
|
MODULE_PARM_DESC(xeon_b2b_dsd_bar4_addr32,
|
2015-05-20 19:55:47 +03:00
|
|
|
"XEON B2B DSD split-BAR 4 32-bit address");
|
|
|
|
|
|
|
|
module_param_named(xeon_b2b_dsd_bar5_addr32,
|
|
|
|
xeon_b2b_dsd_addr.bar5_addr32, ullong, 0644);
|
2016-08-08 12:48:42 +03:00
|
|
|
MODULE_PARM_DESC(xeon_b2b_dsd_bar5_addr32,
|
2015-05-20 19:55:47 +03:00
|
|
|
"XEON B2B DSD split-BAR 5 32-bit address");
|
2015-05-11 12:45:30 +03:00
|
|
|
|
2016-11-17 00:03:38 +03:00
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
static int xeon_init_isr(struct intel_ntb_dev *ndev);
|
2016-11-17 00:03:38 +03:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static inline void ndev_reset_unsafe_flags(struct intel_ntb_dev *ndev)
|
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 06:27:12 +04:00
|
|
|
{
|
2015-04-09 17:33:20 +03:00
|
|
|
ndev->unsafe_flags = 0;
|
|
|
|
ndev->unsafe_flags_ignore = 0;
|
|
|
|
|
|
|
|
/* Only B2B has a workaround to avoid SDOORBELL */
|
|
|
|
if (ndev->hwerr_flags & NTB_HWERR_SDOORBELL_LOCKUP)
|
|
|
|
if (!ntb_topo_is_b2b(ndev->ntb.topo))
|
|
|
|
ndev->unsafe_flags |= NTB_UNSAFE_DB;
|
|
|
|
|
|
|
|
/* No low level workaround to avoid SB01BASE */
|
|
|
|
if (ndev->hwerr_flags & NTB_HWERR_SB01BASE_LOCKUP) {
|
|
|
|
ndev->unsafe_flags |= NTB_UNSAFE_DB;
|
|
|
|
ndev->unsafe_flags |= NTB_UNSAFE_SPAD;
|
|
|
|
}
|
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 06:27:12 +04:00
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static inline int ndev_is_unsafe(struct intel_ntb_dev *ndev,
|
|
|
|
unsigned long flag)
|
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 06:27:12 +04:00
|
|
|
{
|
2015-04-09 17:33:20 +03:00
|
|
|
return !!(flag & ndev->unsafe_flags & ~ndev->unsafe_flags_ignore);
|
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 06:27:12 +04:00
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static inline int ndev_ignore_unsafe(struct intel_ntb_dev *ndev,
|
|
|
|
unsigned long flag)
|
2013-04-19 04:59:44 +04:00
|
|
|
{
|
2015-04-09 17:33:20 +03:00
|
|
|
flag &= ndev->unsafe_flags;
|
|
|
|
ndev->unsafe_flags_ignore |= flag;
|
2013-04-19 04:59:44 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
return !!flag;
|
2013-04-19 04:59:44 +04:00
|
|
|
}
|
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
int ndev_mw_to_bar(struct intel_ntb_dev *ndev, int idx)
|
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 06:27:12 +04:00
|
|
|
{
|
2015-08-31 16:31:00 +03:00
|
|
|
if (idx < 0 || idx >= ndev->mw_count)
|
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 06:27:12 +04:00
|
|
|
return -EINVAL;
|
2015-04-09 17:33:20 +03:00
|
|
|
return ndev->reg->mw_bar[idx];
|
|
|
|
}
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static inline int ndev_db_addr(struct intel_ntb_dev *ndev,
|
|
|
|
phys_addr_t *db_addr, resource_size_t *db_size,
|
|
|
|
phys_addr_t reg_addr, unsigned long reg)
|
|
|
|
{
|
2015-06-15 15:22:30 +03:00
|
|
|
if (ndev_is_unsafe(ndev, NTB_UNSAFE_DB))
|
|
|
|
pr_warn_once("%s: NTB unsafe doorbell access", __func__);
|
2013-04-19 04:59:44 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
if (db_addr) {
|
|
|
|
*db_addr = reg_addr + reg;
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&ndev->ntb.pdev->dev, "Peer db addr %llx\n", *db_addr);
|
2015-04-09 17:33:20 +03:00
|
|
|
}
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
if (db_size) {
|
|
|
|
*db_size = ndev->reg->db_size;
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&ndev->ntb.pdev->dev, "Peer db size %llx\n", *db_size);
|
2015-04-09 17:33:20 +03:00
|
|
|
}
|
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 06:27:12 +04:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
u64 ndev_db_read(struct intel_ntb_dev *ndev,
|
2015-04-09 17:33:20 +03:00
|
|
|
void __iomem *mmio)
|
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 06:27:12 +04:00
|
|
|
{
|
2015-06-15 15:22:30 +03:00
|
|
|
if (ndev_is_unsafe(ndev, NTB_UNSAFE_DB))
|
|
|
|
pr_warn_once("%s: NTB unsafe doorbell access", __func__);
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
return ndev->reg->db_ioread(mmio);
|
|
|
|
}
|
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
int ndev_db_write(struct intel_ntb_dev *ndev, u64 db_bits,
|
2015-04-09 17:33:20 +03:00
|
|
|
void __iomem *mmio)
|
|
|
|
{
|
2015-06-15 15:22:30 +03:00
|
|
|
if (ndev_is_unsafe(ndev, NTB_UNSAFE_DB))
|
|
|
|
pr_warn_once("%s: NTB unsafe doorbell access", __func__);
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
if (db_bits & ~ndev->db_valid_mask)
|
|
|
|
return -EINVAL;
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
ndev->reg->db_iowrite(db_bits, mmio);
|
2013-04-19 04:59:44 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
return 0;
|
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 06:27:12 +04:00
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static inline int ndev_db_set_mask(struct intel_ntb_dev *ndev, u64 db_bits,
|
|
|
|
void __iomem *mmio)
|
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 06:27:12 +04:00
|
|
|
{
|
2015-04-09 17:33:20 +03:00
|
|
|
unsigned long irqflags;
|
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 06:27:12 +04:00
|
|
|
|
2015-06-15 15:22:30 +03:00
|
|
|
if (ndev_is_unsafe(ndev, NTB_UNSAFE_DB))
|
|
|
|
pr_warn_once("%s: NTB unsafe doorbell access", __func__);
|
2015-04-09 17:33:20 +03:00
|
|
|
|
|
|
|
if (db_bits & ~ndev->db_valid_mask)
|
|
|
|
return -EINVAL;
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
spin_lock_irqsave(&ndev->db_mask_lock, irqflags);
|
|
|
|
{
|
|
|
|
ndev->db_mask |= db_bits;
|
|
|
|
ndev->reg->db_iowrite(ndev->db_mask, mmio);
|
|
|
|
}
|
|
|
|
spin_unlock_irqrestore(&ndev->db_mask_lock, irqflags);
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
return 0;
|
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 06:27:12 +04:00
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static inline int ndev_db_clear_mask(struct intel_ntb_dev *ndev, u64 db_bits,
|
|
|
|
void __iomem *mmio)
|
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 06:27:12 +04:00
|
|
|
{
|
2015-04-09 17:33:20 +03:00
|
|
|
unsigned long irqflags;
|
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 06:27:12 +04:00
|
|
|
|
2015-06-15 15:22:30 +03:00
|
|
|
if (ndev_is_unsafe(ndev, NTB_UNSAFE_DB))
|
|
|
|
pr_warn_once("%s: NTB unsafe doorbell access", __func__);
|
2015-04-09 17:33:20 +03:00
|
|
|
|
|
|
|
if (db_bits & ~ndev->db_valid_mask)
|
|
|
|
return -EINVAL;
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
spin_lock_irqsave(&ndev->db_mask_lock, irqflags);
|
|
|
|
{
|
|
|
|
ndev->db_mask &= ~db_bits;
|
|
|
|
ndev->reg->db_iowrite(ndev->db_mask, mmio);
|
|
|
|
}
|
|
|
|
spin_unlock_irqrestore(&ndev->db_mask_lock, irqflags);
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
return 0;
|
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 06:27:12 +04:00
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static inline int ndev_vec_mask(struct intel_ntb_dev *ndev, int db_vector)
|
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 06:27:12 +04:00
|
|
|
{
|
2015-04-09 17:33:20 +03:00
|
|
|
u64 shift, mask;
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
shift = ndev->db_vec_shift;
|
|
|
|
mask = BIT_ULL(shift) - 1;
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
return mask << (shift * db_vector);
|
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 06:27:12 +04:00
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static inline int ndev_spad_addr(struct intel_ntb_dev *ndev, int idx,
|
|
|
|
phys_addr_t *spad_addr, phys_addr_t reg_addr,
|
|
|
|
unsigned long reg)
|
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 06:27:12 +04:00
|
|
|
{
|
2015-06-15 15:22:30 +03:00
|
|
|
if (ndev_is_unsafe(ndev, NTB_UNSAFE_SPAD))
|
|
|
|
pr_warn_once("%s: NTB unsafe scratchpad access", __func__);
|
2015-04-09 17:33:20 +03:00
|
|
|
|
|
|
|
if (idx < 0 || idx >= ndev->spad_count)
|
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 06:27:12 +04:00
|
|
|
return -EINVAL;
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
if (spad_addr) {
|
|
|
|
*spad_addr = reg_addr + reg + (idx << 2);
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&ndev->ntb.pdev->dev, "Peer spad addr %llx\n",
|
|
|
|
*spad_addr);
|
2015-04-09 17:33:20 +03:00
|
|
|
}
|
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 06:27:12 +04:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static inline u32 ndev_spad_read(struct intel_ntb_dev *ndev, int idx,
|
|
|
|
void __iomem *mmio)
|
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 06:27:12 +04:00
|
|
|
{
|
2015-06-15 15:22:30 +03:00
|
|
|
if (ndev_is_unsafe(ndev, NTB_UNSAFE_SPAD))
|
|
|
|
pr_warn_once("%s: NTB unsafe scratchpad access", __func__);
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
if (idx < 0 || idx >= ndev->spad_count)
|
|
|
|
return 0;
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
return ioread32(mmio + (idx << 2));
|
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 06:27:12 +04:00
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static inline int ndev_spad_write(struct intel_ntb_dev *ndev, int idx, u32 val,
|
|
|
|
void __iomem *mmio)
|
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 06:27:12 +04:00
|
|
|
{
|
2015-06-15 15:22:30 +03:00
|
|
|
if (ndev_is_unsafe(ndev, NTB_UNSAFE_SPAD))
|
|
|
|
pr_warn_once("%s: NTB unsafe scratchpad access", __func__);
|
2015-04-09 17:33:20 +03:00
|
|
|
|
|
|
|
if (idx < 0 || idx >= ndev->spad_count)
|
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 06:27:12 +04:00
|
|
|
return -EINVAL;
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
iowrite32(val, mmio + (idx << 2));
|
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 06:27:12 +04:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static irqreturn_t ndev_interrupt(struct intel_ntb_dev *ndev, int vec)
|
2013-02-12 20:52:50 +04:00
|
|
|
{
|
2015-04-09 17:33:20 +03:00
|
|
|
u64 vec_mask;
|
|
|
|
|
|
|
|
vec_mask = ndev_vec_mask(ndev, vec);
|
|
|
|
|
2016-11-17 00:03:38 +03:00
|
|
|
if ((ndev->hwerr_flags & NTB_HWERR_MSIX_VECTOR32_BAD) && (vec == 31))
|
|
|
|
vec_mask |= ndev->db_link_mask;
|
|
|
|
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&ndev->ntb.pdev->dev, "vec %d vec_mask %llx\n", vec, vec_mask);
|
2013-02-12 20:52:50 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
ndev->last_ts = jiffies;
|
|
|
|
|
|
|
|
if (vec_mask & ndev->db_link_mask) {
|
|
|
|
if (ndev->reg->poll_link(ndev))
|
|
|
|
ntb_link_event(&ndev->ntb);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (vec_mask & ndev->db_valid_mask)
|
|
|
|
ntb_db_event(&ndev->ntb, vec);
|
|
|
|
|
|
|
|
return IRQ_HANDLED;
|
2013-02-12 20:52:50 +04:00
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static irqreturn_t ndev_vec_isr(int irq, void *dev)
|
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 06:27:12 +04:00
|
|
|
{
|
2015-04-09 17:33:20 +03:00
|
|
|
struct intel_ntb_vec *nvec = dev;
|
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 06:27:12 +04:00
|
|
|
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&nvec->ndev->ntb.pdev->dev, "irq: %d nvec->num: %d\n",
|
2016-11-17 00:03:38 +03:00
|
|
|
irq, nvec->num);
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
return ndev_interrupt(nvec->ndev, nvec->num);
|
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 06:27:12 +04:00
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static irqreturn_t ndev_irq_isr(int irq, void *dev)
|
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 06:27:12 +04:00
|
|
|
{
|
2015-04-09 17:33:20 +03:00
|
|
|
struct intel_ntb_dev *ndev = dev;
|
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 06:27:12 +04:00
|
|
|
|
2017-01-11 03:33:37 +03:00
|
|
|
return ndev_interrupt(ndev, irq - ndev->ntb.pdev->irq);
|
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 06:27:12 +04:00
|
|
|
}
|
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
int ndev_init_isr(struct intel_ntb_dev *ndev,
|
2015-04-09 17:33:20 +03:00
|
|
|
int msix_min, int msix_max,
|
|
|
|
int msix_shift, int total_shift)
|
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 06:27:12 +04:00
|
|
|
{
|
2015-04-09 17:33:20 +03:00
|
|
|
struct pci_dev *pdev;
|
2015-05-19 19:04:52 +03:00
|
|
|
int rc, i, msix_count, node;
|
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 06:27:12 +04:00
|
|
|
|
2017-01-11 03:33:37 +03:00
|
|
|
pdev = ndev->ntb.pdev;
|
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 06:27:12 +04:00
|
|
|
|
2015-05-19 19:04:52 +03:00
|
|
|
node = dev_to_node(&pdev->dev);
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
/* Mask all doorbell interrupts */
|
|
|
|
ndev->db_mask = ndev->db_valid_mask;
|
|
|
|
ndev->reg->db_iowrite(ndev->db_mask,
|
|
|
|
ndev->self_mmio +
|
|
|
|
ndev->self_reg->db_mask);
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
/* Try to set up msix irq */
|
|
|
|
|
2015-05-19 19:04:52 +03:00
|
|
|
ndev->vec = kzalloc_node(msix_max * sizeof(*ndev->vec),
|
|
|
|
GFP_KERNEL, node);
|
2015-04-09 17:33:20 +03:00
|
|
|
if (!ndev->vec)
|
|
|
|
goto err_msix_vec_alloc;
|
|
|
|
|
2015-05-19 19:04:52 +03:00
|
|
|
ndev->msix = kzalloc_node(msix_max * sizeof(*ndev->msix),
|
|
|
|
GFP_KERNEL, node);
|
2015-04-09 17:33:20 +03:00
|
|
|
if (!ndev->msix)
|
|
|
|
goto err_msix_alloc;
|
|
|
|
|
|
|
|
for (i = 0; i < msix_max; ++i)
|
|
|
|
ndev->msix[i].entry = i;
|
|
|
|
|
|
|
|
msix_count = pci_enable_msix_range(pdev, ndev->msix,
|
|
|
|
msix_min, msix_max);
|
|
|
|
if (msix_count < 0)
|
|
|
|
goto err_msix_enable;
|
|
|
|
|
|
|
|
for (i = 0; i < msix_count; ++i) {
|
|
|
|
ndev->vec[i].ndev = ndev;
|
|
|
|
ndev->vec[i].num = i;
|
|
|
|
rc = request_irq(ndev->msix[i].vector, ndev_vec_isr, 0,
|
|
|
|
"ndev_vec_isr", &ndev->vec[i]);
|
|
|
|
if (rc)
|
|
|
|
goto err_msix_request;
|
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 06:27:12 +04:00
|
|
|
}
|
|
|
|
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "Using %d msix interrupts\n", msix_count);
|
2015-04-09 17:33:20 +03:00
|
|
|
ndev->db_vec_count = msix_count;
|
|
|
|
ndev->db_vec_shift = msix_shift;
|
|
|
|
return 0;
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
err_msix_request:
|
|
|
|
while (i-- > 0)
|
2016-12-19 08:52:55 +03:00
|
|
|
free_irq(ndev->msix[i].vector, &ndev->vec[i]);
|
2015-04-09 17:33:20 +03:00
|
|
|
pci_disable_msix(pdev);
|
|
|
|
err_msix_enable:
|
|
|
|
kfree(ndev->msix);
|
|
|
|
err_msix_alloc:
|
|
|
|
kfree(ndev->vec);
|
|
|
|
err_msix_vec_alloc:
|
|
|
|
ndev->msix = NULL;
|
|
|
|
ndev->vec = NULL;
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
/* Try to set up msi irq */
|
2012-11-17 05:52:57 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
rc = pci_enable_msi(pdev);
|
|
|
|
if (rc)
|
|
|
|
goto err_msi_enable;
|
2012-11-17 05:52:57 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
rc = request_irq(pdev->irq, ndev_irq_isr, 0,
|
|
|
|
"ndev_irq_isr", ndev);
|
|
|
|
if (rc)
|
|
|
|
goto err_msi_request;
|
2012-11-17 05:52:57 +04:00
|
|
|
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "Using msi interrupts\n");
|
2015-04-09 17:33:20 +03:00
|
|
|
ndev->db_vec_count = 1;
|
|
|
|
ndev->db_vec_shift = total_shift;
|
|
|
|
return 0;
|
2012-11-17 05:52:57 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
err_msi_request:
|
|
|
|
pci_disable_msi(pdev);
|
|
|
|
err_msi_enable:
|
2012-11-17 05:52:57 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
/* Try to set up intx irq */
|
2012-11-17 05:52:57 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
pci_intx(pdev, 1);
|
2012-11-17 05:52:57 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
rc = request_irq(pdev->irq, ndev_irq_isr, IRQF_SHARED,
|
|
|
|
"ndev_irq_isr", ndev);
|
|
|
|
if (rc)
|
|
|
|
goto err_intx_request;
|
|
|
|
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "Using intx interrupts\n");
|
2015-04-09 17:33:20 +03:00
|
|
|
ndev->db_vec_count = 1;
|
|
|
|
ndev->db_vec_shift = total_shift;
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err_intx_request:
|
|
|
|
return rc;
|
2012-11-17 05:52:57 +04:00
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static void ndev_deinit_isr(struct intel_ntb_dev *ndev)
|
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 06:27:12 +04:00
|
|
|
{
|
2015-04-09 17:33:20 +03:00
|
|
|
struct pci_dev *pdev;
|
|
|
|
int i;
|
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 06:27:12 +04:00
|
|
|
|
2017-01-11 03:33:37 +03:00
|
|
|
pdev = ndev->ntb.pdev;
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
/* Mask all doorbell interrupts */
|
|
|
|
ndev->db_mask = ndev->db_valid_mask;
|
|
|
|
ndev->reg->db_iowrite(ndev->db_mask,
|
|
|
|
ndev->self_mmio +
|
|
|
|
ndev->self_reg->db_mask);
|
2012-11-17 05:52:57 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
if (ndev->msix) {
|
|
|
|
i = ndev->db_vec_count;
|
|
|
|
while (i--)
|
|
|
|
free_irq(ndev->msix[i].vector, &ndev->vec[i]);
|
|
|
|
pci_disable_msix(pdev);
|
|
|
|
kfree(ndev->msix);
|
|
|
|
kfree(ndev->vec);
|
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 06:27:12 +04:00
|
|
|
} else {
|
2015-04-09 17:33:20 +03:00
|
|
|
free_irq(pdev->irq, ndev);
|
|
|
|
if (pci_dev_msi_enabled(pdev))
|
|
|
|
pci_disable_msi(pdev);
|
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 06:27:12 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-11-17 00:03:38 +03:00
|
|
|
static ssize_t ndev_ntb_debugfs_read(struct file *filp, char __user *ubuf,
|
|
|
|
size_t count, loff_t *offp)
|
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 06:27:12 +04:00
|
|
|
{
|
2015-04-09 17:33:20 +03:00
|
|
|
struct intel_ntb_dev *ndev;
|
2016-07-22 16:38:22 +03:00
|
|
|
struct pci_dev *pdev;
|
2015-04-09 17:33:20 +03:00
|
|
|
void __iomem *mmio;
|
|
|
|
char *buf;
|
|
|
|
size_t buf_size;
|
|
|
|
ssize_t ret, off;
|
2016-07-22 16:38:22 +03:00
|
|
|
union { u64 v64; u32 v32; u16 v16; u8 v8; } u;
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
ndev = filp->private_data;
|
2017-01-11 03:33:37 +03:00
|
|
|
pdev = ndev->ntb.pdev;
|
2015-04-09 17:33:20 +03:00
|
|
|
mmio = ndev->self_mmio;
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
buf_size = min(count, 0x800ul);
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
buf = kmalloc(buf_size, GFP_KERNEL);
|
|
|
|
if (!buf)
|
|
|
|
return -ENOMEM;
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
off = 0;
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"NTB Device Information:\n");
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"Connection Topology -\t%s\n",
|
|
|
|
ntb_topo_string(ndev->ntb.topo));
|
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 06:27:12 +04:00
|
|
|
|
2015-08-31 16:30:59 +03:00
|
|
|
if (ndev->b2b_idx != UINT_MAX) {
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"B2B MW Idx -\t\t%u\n", ndev->b2b_idx);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"B2B Offset -\t\t%#lx\n", ndev->b2b_off);
|
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"BAR4 Split -\t\t%s\n",
|
|
|
|
ndev->bar4_split ? "yes" : "no");
|
2012-11-17 05:52:57 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"NTB CTL -\t\t%#06x\n", ndev->ntb_ctl);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"LNK STA -\t\t%#06x\n", ndev->lnk_sta);
|
|
|
|
|
|
|
|
if (!ndev->reg->link_is_up(ndev)) {
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"Link Status -\t\tDown\n");
|
|
|
|
} else {
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"Link Status -\t\tUp\n");
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"Link Speed -\t\tPCI-E Gen %u\n",
|
|
|
|
NTB_LNK_STA_SPEED(ndev->lnk_sta));
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"Link Width -\t\tx%u\n",
|
|
|
|
NTB_LNK_STA_WIDTH(ndev->lnk_sta));
|
2012-11-17 05:52:57 +04:00
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"Memory Window Count -\t%u\n", ndev->mw_count);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"Scratchpad Count -\t%u\n", ndev->spad_count);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"Doorbell Count -\t%u\n", ndev->db_count);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"Doorbell Vector Count -\t%u\n", ndev->db_vec_count);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"Doorbell Vector Shift -\t%u\n", ndev->db_vec_shift);
|
|
|
|
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"Doorbell Valid Mask -\t%#llx\n", ndev->db_valid_mask);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"Doorbell Link Mask -\t%#llx\n", ndev->db_link_mask);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"Doorbell Mask Cached -\t%#llx\n", ndev->db_mask);
|
|
|
|
|
|
|
|
u.v64 = ndev_db_read(ndev, mmio + ndev->self_reg->db_mask);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"Doorbell Mask -\t\t%#llx\n", u.v64);
|
|
|
|
|
|
|
|
u.v64 = ndev_db_read(ndev, mmio + ndev->self_reg->db_bell);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"Doorbell Bell -\t\t%#llx\n", u.v64);
|
|
|
|
|
2016-07-22 16:38:22 +03:00
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"\nNTB Window Size:\n");
|
|
|
|
|
|
|
|
pci_read_config_byte(pdev, XEON_PBAR23SZ_OFFSET, &u.v8);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"PBAR23SZ %hhu\n", u.v8);
|
|
|
|
if (!ndev->bar4_split) {
|
|
|
|
pci_read_config_byte(pdev, XEON_PBAR45SZ_OFFSET, &u.v8);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"PBAR45SZ %hhu\n", u.v8);
|
|
|
|
} else {
|
|
|
|
pci_read_config_byte(pdev, XEON_PBAR4SZ_OFFSET, &u.v8);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"PBAR4SZ %hhu\n", u.v8);
|
|
|
|
pci_read_config_byte(pdev, XEON_PBAR5SZ_OFFSET, &u.v8);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"PBAR5SZ %hhu\n", u.v8);
|
|
|
|
}
|
|
|
|
|
|
|
|
pci_read_config_byte(pdev, XEON_SBAR23SZ_OFFSET, &u.v8);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"SBAR23SZ %hhu\n", u.v8);
|
|
|
|
if (!ndev->bar4_split) {
|
|
|
|
pci_read_config_byte(pdev, XEON_SBAR45SZ_OFFSET, &u.v8);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"SBAR45SZ %hhu\n", u.v8);
|
|
|
|
} else {
|
|
|
|
pci_read_config_byte(pdev, XEON_SBAR4SZ_OFFSET, &u.v8);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"SBAR4SZ %hhu\n", u.v8);
|
|
|
|
pci_read_config_byte(pdev, XEON_SBAR5SZ_OFFSET, &u.v8);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"SBAR5SZ %hhu\n", u.v8);
|
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"\nNTB Incoming XLAT:\n");
|
|
|
|
|
|
|
|
u.v64 = ioread64(mmio + bar2_off(ndev->xlat_reg->bar2_xlat, 2));
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"XLAT23 -\t\t%#018llx\n", u.v64);
|
|
|
|
|
2015-06-18 12:17:30 +03:00
|
|
|
if (ndev->bar4_split) {
|
|
|
|
u.v32 = ioread32(mmio + bar2_off(ndev->xlat_reg->bar2_xlat, 4));
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"XLAT4 -\t\t\t%#06x\n", u.v32);
|
|
|
|
|
|
|
|
u.v32 = ioread32(mmio + bar2_off(ndev->xlat_reg->bar2_xlat, 5));
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"XLAT5 -\t\t\t%#06x\n", u.v32);
|
|
|
|
} else {
|
|
|
|
u.v64 = ioread64(mmio + bar2_off(ndev->xlat_reg->bar2_xlat, 4));
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"XLAT45 -\t\t%#018llx\n", u.v64);
|
|
|
|
}
|
2015-04-09 17:33:20 +03:00
|
|
|
|
|
|
|
u.v64 = ioread64(mmio + bar2_off(ndev->xlat_reg->bar2_limit, 2));
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"LMT23 -\t\t\t%#018llx\n", u.v64);
|
|
|
|
|
2015-06-18 12:17:30 +03:00
|
|
|
if (ndev->bar4_split) {
|
|
|
|
u.v32 = ioread32(mmio + bar2_off(ndev->xlat_reg->bar2_limit, 4));
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"LMT4 -\t\t\t%#06x\n", u.v32);
|
|
|
|
u.v32 = ioread32(mmio + bar2_off(ndev->xlat_reg->bar2_limit, 5));
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"LMT5 -\t\t\t%#06x\n", u.v32);
|
|
|
|
} else {
|
|
|
|
u.v64 = ioread64(mmio + bar2_off(ndev->xlat_reg->bar2_limit, 4));
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"LMT45 -\t\t\t%#018llx\n", u.v64);
|
|
|
|
}
|
2015-04-09 17:33:20 +03:00
|
|
|
|
2016-07-22 16:38:23 +03:00
|
|
|
if (pdev_is_xeon(pdev)) {
|
2015-04-09 17:33:20 +03:00
|
|
|
if (ntb_topo_is_b2b(ndev->ntb.topo)) {
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"\nNTB Outgoing B2B XLAT:\n");
|
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
u.v64 = ioread64(mmio + XEON_PBAR23XLAT_OFFSET);
|
2015-04-09 17:33:20 +03:00
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"B2B XLAT23 -\t\t%#018llx\n", u.v64);
|
|
|
|
|
2015-06-18 12:17:30 +03:00
|
|
|
if (ndev->bar4_split) {
|
|
|
|
u.v32 = ioread32(mmio + XEON_PBAR4XLAT_OFFSET);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"B2B XLAT4 -\t\t%#06x\n",
|
|
|
|
u.v32);
|
|
|
|
u.v32 = ioread32(mmio + XEON_PBAR5XLAT_OFFSET);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"B2B XLAT5 -\t\t%#06x\n",
|
|
|
|
u.v32);
|
|
|
|
} else {
|
|
|
|
u.v64 = ioread64(mmio + XEON_PBAR45XLAT_OFFSET);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"B2B XLAT45 -\t\t%#018llx\n",
|
|
|
|
u.v64);
|
|
|
|
}
|
2015-04-09 17:33:20 +03:00
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
u.v64 = ioread64(mmio + XEON_PBAR23LMT_OFFSET);
|
2015-04-09 17:33:20 +03:00
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"B2B LMT23 -\t\t%#018llx\n", u.v64);
|
|
|
|
|
2015-06-18 12:17:30 +03:00
|
|
|
if (ndev->bar4_split) {
|
|
|
|
u.v32 = ioread32(mmio + XEON_PBAR4LMT_OFFSET);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"B2B LMT4 -\t\t%#06x\n",
|
|
|
|
u.v32);
|
|
|
|
u.v32 = ioread32(mmio + XEON_PBAR5LMT_OFFSET);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"B2B LMT5 -\t\t%#06x\n",
|
|
|
|
u.v32);
|
|
|
|
} else {
|
|
|
|
u.v64 = ioread64(mmio + XEON_PBAR45LMT_OFFSET);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"B2B LMT45 -\t\t%#018llx\n",
|
|
|
|
u.v64);
|
|
|
|
}
|
2015-04-09 17:33:20 +03:00
|
|
|
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"\nNTB Secondary BAR:\n");
|
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
u.v64 = ioread64(mmio + XEON_SBAR0BASE_OFFSET);
|
2015-04-09 17:33:20 +03:00
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"SBAR01 -\t\t%#018llx\n", u.v64);
|
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
u.v64 = ioread64(mmio + XEON_SBAR23BASE_OFFSET);
|
2015-04-09 17:33:20 +03:00
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"SBAR23 -\t\t%#018llx\n", u.v64);
|
|
|
|
|
2015-06-18 12:17:30 +03:00
|
|
|
if (ndev->bar4_split) {
|
|
|
|
u.v32 = ioread32(mmio + XEON_SBAR4BASE_OFFSET);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"SBAR4 -\t\t\t%#06x\n", u.v32);
|
|
|
|
u.v32 = ioread32(mmio + XEON_SBAR5BASE_OFFSET);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"SBAR5 -\t\t\t%#06x\n", u.v32);
|
|
|
|
} else {
|
|
|
|
u.v64 = ioread64(mmio + XEON_SBAR45BASE_OFFSET);
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"SBAR45 -\t\t%#018llx\n",
|
|
|
|
u.v64);
|
|
|
|
}
|
2015-04-09 17:33:20 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
2015-05-20 19:55:47 +03:00
|
|
|
"\nXEON NTB Statistics:\n");
|
2015-04-09 17:33:20 +03:00
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
u.v16 = ioread16(mmio + XEON_USMEMMISS_OFFSET);
|
2015-04-09 17:33:20 +03:00
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"Upstream Memory Miss -\t%u\n", u.v16);
|
|
|
|
|
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
2015-05-20 19:55:47 +03:00
|
|
|
"\nXEON NTB Hardware Errors:\n");
|
2015-04-09 17:33:20 +03:00
|
|
|
|
2016-07-22 16:38:23 +03:00
|
|
|
if (!pci_read_config_word(pdev,
|
2015-05-20 19:55:47 +03:00
|
|
|
XEON_DEVSTS_OFFSET, &u.v16))
|
2015-04-09 17:33:20 +03:00
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"DEVSTS -\t\t%#06x\n", u.v16);
|
|
|
|
|
2016-07-22 16:38:23 +03:00
|
|
|
if (!pci_read_config_word(pdev,
|
2015-05-20 19:55:47 +03:00
|
|
|
XEON_LINK_STATUS_OFFSET, &u.v16))
|
2015-04-09 17:33:20 +03:00
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"LNKSTS -\t\t%#06x\n", u.v16);
|
2012-11-17 05:52:57 +04:00
|
|
|
|
2016-07-22 16:38:23 +03:00
|
|
|
if (!pci_read_config_dword(pdev,
|
2015-05-20 19:55:47 +03:00
|
|
|
XEON_UNCERRSTS_OFFSET, &u.v32))
|
2015-04-09 17:33:20 +03:00
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"UNCERRSTS -\t\t%#06x\n", u.v32);
|
|
|
|
|
2016-07-22 16:38:23 +03:00
|
|
|
if (!pci_read_config_dword(pdev,
|
2015-05-20 19:55:47 +03:00
|
|
|
XEON_CORERRSTS_OFFSET, &u.v32))
|
2015-04-09 17:33:20 +03:00
|
|
|
off += scnprintf(buf + off, buf_size - off,
|
|
|
|
"CORERRSTS -\t\t%#06x\n", u.v32);
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = simple_read_from_buffer(ubuf, count, offp, buf, off);
|
|
|
|
kfree(buf);
|
|
|
|
return ret;
|
2012-11-17 05:52:57 +04:00
|
|
|
}
|
|
|
|
|
2016-11-17 00:03:38 +03:00
|
|
|
static ssize_t ndev_debugfs_read(struct file *filp, char __user *ubuf,
|
|
|
|
size_t count, loff_t *offp)
|
|
|
|
{
|
|
|
|
struct intel_ntb_dev *ndev = filp->private_data;
|
|
|
|
|
2017-11-20 20:24:08 +03:00
|
|
|
if (pdev_is_xeon(ndev->ntb.pdev))
|
2016-11-17 00:03:38 +03:00
|
|
|
return ndev_ntb_debugfs_read(filp, ubuf, count, offp);
|
|
|
|
else if (pdev_is_skx_xeon(ndev->ntb.pdev))
|
|
|
|
return ndev_ntb3_debugfs_read(filp, ubuf, count, offp);
|
|
|
|
|
|
|
|
return -ENXIO;
|
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static void ndev_init_debugfs(struct intel_ntb_dev *ndev)
|
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 06:27:12 +04:00
|
|
|
{
|
2015-04-09 17:33:20 +03:00
|
|
|
if (!debugfs_dir) {
|
|
|
|
ndev->debugfs_dir = NULL;
|
|
|
|
ndev->debugfs_info = NULL;
|
|
|
|
} else {
|
|
|
|
ndev->debugfs_dir =
|
2017-01-11 03:33:37 +03:00
|
|
|
debugfs_create_dir(pci_name(ndev->ntb.pdev),
|
|
|
|
debugfs_dir);
|
2015-04-09 17:33:20 +03:00
|
|
|
if (!ndev->debugfs_dir)
|
|
|
|
ndev->debugfs_info = NULL;
|
|
|
|
else
|
|
|
|
ndev->debugfs_info =
|
|
|
|
debugfs_create_file("info", S_IRUSR,
|
|
|
|
ndev->debugfs_dir, ndev,
|
|
|
|
&intel_ntb_debugfs_info);
|
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 06:27:12 +04:00
|
|
|
}
|
2015-04-09 17:33:20 +03:00
|
|
|
}
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static void ndev_deinit_debugfs(struct intel_ntb_dev *ndev)
|
|
|
|
{
|
|
|
|
debugfs_remove_recursive(ndev->debugfs_dir);
|
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 06:27:12 +04:00
|
|
|
}
|
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
int intel_ntb_mw_count(struct ntb_dev *ntb, int pidx)
|
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 06:27:12 +04:00
|
|
|
{
|
2017-01-11 03:11:33 +03:00
|
|
|
if (pidx != NTB_DEF_PEER_IDX)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
return ntb_ndev(ntb)->mw_count;
|
|
|
|
}
|
2013-07-16 03:43:54 +04:00
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
int intel_ntb_mw_get_align(struct ntb_dev *ntb, int pidx, int idx,
|
|
|
|
resource_size_t *addr_align,
|
|
|
|
resource_size_t *size_align,
|
|
|
|
resource_size_t *size_max)
|
2015-04-09 17:33:20 +03:00
|
|
|
{
|
|
|
|
struct intel_ntb_dev *ndev = ntb_ndev(ntb);
|
2017-01-11 03:11:33 +03:00
|
|
|
resource_size_t bar_size, mw_size;
|
2015-04-09 17:33:20 +03:00
|
|
|
int bar;
|
2013-04-19 04:07:36 +04:00
|
|
|
|
2017-01-11 03:11:33 +03:00
|
|
|
if (pidx != NTB_DEF_PEER_IDX)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
if (idx >= ndev->b2b_idx && !ndev->b2b_off)
|
|
|
|
idx += 1;
|
2014-08-29 00:53:23 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
bar = ndev_mw_to_bar(ndev, idx);
|
|
|
|
if (bar < 0)
|
|
|
|
return bar;
|
2013-07-16 03:43:54 +04:00
|
|
|
|
2017-01-11 03:11:33 +03:00
|
|
|
bar_size = pci_resource_len(ndev->ntb.pdev, bar);
|
2014-08-29 00:53:18 +04:00
|
|
|
|
2017-01-11 03:11:33 +03:00
|
|
|
if (idx == ndev->b2b_idx)
|
|
|
|
mw_size = bar_size - ndev->b2b_off;
|
|
|
|
else
|
|
|
|
mw_size = bar_size;
|
|
|
|
|
|
|
|
if (addr_align)
|
|
|
|
*addr_align = pci_resource_len(ndev->ntb.pdev, bar);
|
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 06:27:12 +04:00
|
|
|
|
2017-01-11 03:11:33 +03:00
|
|
|
if (size_align)
|
|
|
|
*size_align = 1;
|
2013-07-16 03:43:54 +04:00
|
|
|
|
2017-01-11 03:11:33 +03:00
|
|
|
if (size_max)
|
|
|
|
*size_max = mw_size;
|
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 06:27:12 +04:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-01-11 03:11:33 +03:00
|
|
|
static int intel_ntb_mw_set_trans(struct ntb_dev *ntb, int pidx, int idx,
|
2015-04-09 17:33:20 +03:00
|
|
|
dma_addr_t addr, resource_size_t size)
|
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 06:27:12 +04:00
|
|
|
{
|
2015-04-09 17:33:20 +03:00
|
|
|
struct intel_ntb_dev *ndev = ntb_ndev(ntb);
|
|
|
|
unsigned long base_reg, xlat_reg, limit_reg;
|
|
|
|
resource_size_t bar_size, mw_size;
|
|
|
|
void __iomem *mmio;
|
|
|
|
u64 base, limit, reg_val;
|
|
|
|
int bar;
|
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 06:27:12 +04:00
|
|
|
|
2017-01-11 03:11:33 +03:00
|
|
|
if (pidx != NTB_DEF_PEER_IDX)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
if (idx >= ndev->b2b_idx && !ndev->b2b_off)
|
|
|
|
idx += 1;
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
bar = ndev_mw_to_bar(ndev, idx);
|
|
|
|
if (bar < 0)
|
|
|
|
return bar;
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
bar_size = pci_resource_len(ndev->ntb.pdev, bar);
|
|
|
|
|
|
|
|
if (idx == ndev->b2b_idx)
|
|
|
|
mw_size = bar_size - ndev->b2b_off;
|
|
|
|
else
|
|
|
|
mw_size = bar_size;
|
|
|
|
|
|
|
|
/* hardware requires that addr is aligned to bar size */
|
|
|
|
if (addr & (bar_size - 1))
|
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 06:27:12 +04:00
|
|
|
return -EINVAL;
|
2015-04-09 17:33:20 +03:00
|
|
|
|
|
|
|
/* make sure the range fits in the usable mw size */
|
|
|
|
if (size > mw_size)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
mmio = ndev->self_mmio;
|
|
|
|
base_reg = bar0_off(ndev->xlat_reg->bar0_base, bar);
|
|
|
|
xlat_reg = bar2_off(ndev->xlat_reg->bar2_xlat, bar);
|
|
|
|
limit_reg = bar2_off(ndev->xlat_reg->bar2_limit, bar);
|
|
|
|
|
|
|
|
if (bar < 4 || !ndev->bar4_split) {
|
2015-11-20 00:00:54 +03:00
|
|
|
base = ioread64(mmio + base_reg) & NTB_BAR_MASK_64;
|
2015-04-09 17:33:20 +03:00
|
|
|
|
|
|
|
/* Set the limit if supported, if size is not mw_size */
|
|
|
|
if (limit_reg && size != mw_size)
|
|
|
|
limit = base + size;
|
|
|
|
else
|
|
|
|
limit = 0;
|
|
|
|
|
|
|
|
/* set and verify setting the translation address */
|
|
|
|
iowrite64(addr, mmio + xlat_reg);
|
|
|
|
reg_val = ioread64(mmio + xlat_reg);
|
|
|
|
if (reg_val != addr) {
|
|
|
|
iowrite64(0, mmio + xlat_reg);
|
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* set and verify setting the limit */
|
|
|
|
iowrite64(limit, mmio + limit_reg);
|
|
|
|
reg_val = ioread64(mmio + limit_reg);
|
|
|
|
if (reg_val != limit) {
|
|
|
|
iowrite64(base, mmio + limit_reg);
|
|
|
|
iowrite64(0, mmio + xlat_reg);
|
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/* split bar addr range must all be 32 bit */
|
|
|
|
if (addr & (~0ull << 32))
|
|
|
|
return -EINVAL;
|
|
|
|
if ((addr + size) & (~0ull << 32))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2015-11-20 00:00:54 +03:00
|
|
|
base = ioread32(mmio + base_reg) & NTB_BAR_MASK_32;
|
2015-04-09 17:33:20 +03:00
|
|
|
|
|
|
|
/* Set the limit if supported, if size is not mw_size */
|
|
|
|
if (limit_reg && size != mw_size)
|
|
|
|
limit = base + size;
|
|
|
|
else
|
|
|
|
limit = 0;
|
|
|
|
|
|
|
|
/* set and verify setting the translation address */
|
|
|
|
iowrite32(addr, mmio + xlat_reg);
|
|
|
|
reg_val = ioread32(mmio + xlat_reg);
|
|
|
|
if (reg_val != addr) {
|
|
|
|
iowrite32(0, mmio + xlat_reg);
|
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* set and verify setting the limit */
|
|
|
|
iowrite32(limit, mmio + limit_reg);
|
|
|
|
reg_val = ioread32(mmio + limit_reg);
|
|
|
|
if (reg_val != limit) {
|
|
|
|
iowrite32(base, mmio + limit_reg);
|
|
|
|
iowrite32(0, mmio + xlat_reg);
|
|
|
|
return -EIO;
|
|
|
|
}
|
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 06:27:12 +04:00
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
return 0;
|
|
|
|
}
|
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 06:27:12 +04:00
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
u64 intel_ntb_link_is_up(struct ntb_dev *ntb, enum ntb_speed *speed,
|
|
|
|
enum ntb_width *width)
|
2015-04-09 17:33:20 +03:00
|
|
|
{
|
|
|
|
struct intel_ntb_dev *ndev = ntb_ndev(ntb);
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
if (ndev->reg->link_is_up(ndev)) {
|
|
|
|
if (speed)
|
|
|
|
*speed = NTB_LNK_STA_SPEED(ndev->lnk_sta);
|
|
|
|
if (width)
|
|
|
|
*width = NTB_LNK_STA_WIDTH(ndev->lnk_sta);
|
|
|
|
return 1;
|
|
|
|
} else {
|
|
|
|
/* TODO MAYBE: is it possible to observe the link speed and
|
|
|
|
* width while link is training? */
|
|
|
|
if (speed)
|
|
|
|
*speed = NTB_SPEED_NONE;
|
|
|
|
if (width)
|
|
|
|
*width = NTB_WIDTH_NONE;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int intel_ntb_link_enable(struct ntb_dev *ntb,
|
|
|
|
enum ntb_speed max_speed,
|
|
|
|
enum ntb_width max_width)
|
|
|
|
{
|
|
|
|
struct intel_ntb_dev *ndev;
|
|
|
|
u32 ntb_ctl;
|
|
|
|
|
|
|
|
ndev = container_of(ntb, struct intel_ntb_dev, ntb);
|
|
|
|
|
|
|
|
if (ndev->ntb.topo == NTB_TOPO_SEC)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&ntb->pdev->dev,
|
2015-04-09 17:33:20 +03:00
|
|
|
"Enabling link with max_speed %d max_width %d\n",
|
|
|
|
max_speed, max_width);
|
|
|
|
if (max_speed != NTB_SPEED_AUTO)
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&ntb->pdev->dev, "ignoring max_speed %d\n", max_speed);
|
2015-04-09 17:33:20 +03:00
|
|
|
if (max_width != NTB_WIDTH_AUTO)
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&ntb->pdev->dev, "ignoring max_width %d\n", max_width);
|
2015-04-09 17:33:20 +03:00
|
|
|
|
|
|
|
ntb_ctl = ioread32(ndev->self_mmio + ndev->reg->ntb_ctl);
|
|
|
|
ntb_ctl &= ~(NTB_CTL_DISABLE | NTB_CTL_CFG_LOCK);
|
|
|
|
ntb_ctl |= NTB_CTL_P2S_BAR2_SNOOP | NTB_CTL_S2P_BAR2_SNOOP;
|
|
|
|
ntb_ctl |= NTB_CTL_P2S_BAR4_SNOOP | NTB_CTL_S2P_BAR4_SNOOP;
|
|
|
|
if (ndev->bar4_split)
|
|
|
|
ntb_ctl |= NTB_CTL_P2S_BAR5_SNOOP | NTB_CTL_S2P_BAR5_SNOOP;
|
|
|
|
iowrite32(ntb_ctl, ndev->self_mmio + ndev->reg->ntb_ctl);
|
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 06:27:12 +04:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
int intel_ntb_link_disable(struct ntb_dev *ntb)
|
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 06:27:12 +04:00
|
|
|
{
|
2015-04-09 17:33:20 +03:00
|
|
|
struct intel_ntb_dev *ndev;
|
|
|
|
u32 ntb_cntl;
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
ndev = container_of(ntb, struct intel_ntb_dev, ntb);
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
if (ndev->ntb.topo == NTB_TOPO_SEC)
|
|
|
|
return -EINVAL;
|
2013-07-16 00:23:47 +04:00
|
|
|
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&ntb->pdev->dev, "Disabling link\n");
|
2015-04-09 17:33:20 +03:00
|
|
|
|
|
|
|
/* Bring NTB link down */
|
|
|
|
ntb_cntl = ioread32(ndev->self_mmio + ndev->reg->ntb_ctl);
|
|
|
|
ntb_cntl &= ~(NTB_CTL_P2S_BAR2_SNOOP | NTB_CTL_S2P_BAR2_SNOOP);
|
|
|
|
ntb_cntl &= ~(NTB_CTL_P2S_BAR4_SNOOP | NTB_CTL_S2P_BAR4_SNOOP);
|
|
|
|
if (ndev->bar4_split)
|
|
|
|
ntb_cntl &= ~(NTB_CTL_P2S_BAR5_SNOOP | NTB_CTL_S2P_BAR5_SNOOP);
|
|
|
|
ntb_cntl |= NTB_CTL_DISABLE | NTB_CTL_CFG_LOCK;
|
|
|
|
iowrite32(ntb_cntl, ndev->self_mmio + ndev->reg->ntb_ctl);
|
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 06:27:12 +04:00
|
|
|
|
2013-07-16 00:23:47 +04:00
|
|
|
return 0;
|
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 06:27:12 +04:00
|
|
|
}
|
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
int intel_ntb_peer_mw_count(struct ntb_dev *ntb)
|
2017-01-11 03:11:33 +03:00
|
|
|
{
|
|
|
|
/* Numbers of inbound and outbound memory windows match */
|
|
|
|
return ntb_ndev(ntb)->mw_count;
|
|
|
|
}
|
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
int intel_ntb_peer_mw_get_addr(struct ntb_dev *ntb, int idx,
|
|
|
|
phys_addr_t *base, resource_size_t *size)
|
2017-01-11 03:11:33 +03:00
|
|
|
{
|
|
|
|
struct intel_ntb_dev *ndev = ntb_ndev(ntb);
|
|
|
|
int bar;
|
|
|
|
|
|
|
|
if (idx >= ndev->b2b_idx && !ndev->b2b_off)
|
|
|
|
idx += 1;
|
|
|
|
|
|
|
|
bar = ndev_mw_to_bar(ndev, idx);
|
|
|
|
if (bar < 0)
|
|
|
|
return bar;
|
|
|
|
|
|
|
|
if (base)
|
|
|
|
*base = pci_resource_start(ndev->ntb.pdev, bar) +
|
|
|
|
(idx == ndev->b2b_idx ? ndev->b2b_off : 0);
|
|
|
|
|
|
|
|
if (size)
|
|
|
|
*size = pci_resource_len(ndev->ntb.pdev, bar) -
|
|
|
|
(idx == ndev->b2b_idx ? ndev->b2b_off : 0);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static int intel_ntb_db_is_unsafe(struct ntb_dev *ntb)
|
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 06:27:12 +04:00
|
|
|
{
|
2015-04-09 17:33:20 +03:00
|
|
|
return ndev_ignore_unsafe(ntb_ndev(ntb), NTB_UNSAFE_DB);
|
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 06:27:12 +04:00
|
|
|
}
|
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
u64 intel_ntb_db_valid_mask(struct ntb_dev *ntb)
|
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 06:27:12 +04:00
|
|
|
{
|
2015-04-09 17:33:20 +03:00
|
|
|
return ntb_ndev(ntb)->db_valid_mask;
|
|
|
|
}
|
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 06:27:12 +04:00
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
int intel_ntb_db_vector_count(struct ntb_dev *ntb)
|
2015-04-09 17:33:20 +03:00
|
|
|
{
|
|
|
|
struct intel_ntb_dev *ndev;
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
ndev = container_of(ntb, struct intel_ntb_dev, ntb);
|
2013-04-19 04:59:44 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
return ndev->db_vec_count;
|
|
|
|
}
|
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 06:27:12 +04:00
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
u64 intel_ntb_db_vector_mask(struct ntb_dev *ntb, int db_vector)
|
2015-04-09 17:33:20 +03:00
|
|
|
{
|
|
|
|
struct intel_ntb_dev *ndev = ntb_ndev(ntb);
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
if (db_vector < 0 || db_vector > ndev->db_vec_count)
|
|
|
|
return 0;
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
return ndev->db_valid_mask & ndev_vec_mask(ndev, db_vector);
|
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 06:27:12 +04:00
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static u64 intel_ntb_db_read(struct ntb_dev *ntb)
|
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 06:27:12 +04:00
|
|
|
{
|
2015-04-09 17:33:20 +03:00
|
|
|
struct intel_ntb_dev *ndev = ntb_ndev(ntb);
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
return ndev_db_read(ndev,
|
|
|
|
ndev->self_mmio +
|
|
|
|
ndev->self_reg->db_bell);
|
|
|
|
}
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static int intel_ntb_db_clear(struct ntb_dev *ntb, u64 db_bits)
|
|
|
|
{
|
|
|
|
struct intel_ntb_dev *ndev = ntb_ndev(ntb);
|
2013-04-19 04:59:44 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
return ndev_db_write(ndev, db_bits,
|
|
|
|
ndev->self_mmio +
|
|
|
|
ndev->self_reg->db_bell);
|
|
|
|
}
|
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 06:27:12 +04:00
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
int intel_ntb_db_set_mask(struct ntb_dev *ntb, u64 db_bits)
|
2015-04-09 17:33:20 +03:00
|
|
|
{
|
|
|
|
struct intel_ntb_dev *ndev = ntb_ndev(ntb);
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
return ndev_db_set_mask(ndev, db_bits,
|
|
|
|
ndev->self_mmio +
|
|
|
|
ndev->self_reg->db_mask);
|
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 06:27:12 +04:00
|
|
|
}
|
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
int intel_ntb_db_clear_mask(struct ntb_dev *ntb, u64 db_bits)
|
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 06:27:12 +04:00
|
|
|
{
|
2015-04-09 17:33:20 +03:00
|
|
|
struct intel_ntb_dev *ndev = ntb_ndev(ntb);
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
return ndev_db_clear_mask(ndev, db_bits,
|
|
|
|
ndev->self_mmio +
|
|
|
|
ndev->self_reg->db_mask);
|
|
|
|
}
|
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 06:27:12 +04:00
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
int intel_ntb_peer_db_addr(struct ntb_dev *ntb, phys_addr_t *db_addr,
|
|
|
|
resource_size_t *db_size)
|
2015-04-09 17:33:20 +03:00
|
|
|
{
|
|
|
|
struct intel_ntb_dev *ndev = ntb_ndev(ntb);
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
return ndev_db_addr(ndev, db_addr, db_size, ndev->peer_addr,
|
|
|
|
ndev->peer_reg->db_bell);
|
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 06:27:12 +04:00
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static int intel_ntb_peer_db_set(struct ntb_dev *ntb, u64 db_bits)
|
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 06:27:12 +04:00
|
|
|
{
|
2015-04-09 17:33:20 +03:00
|
|
|
struct intel_ntb_dev *ndev = ntb_ndev(ntb);
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
return ndev_db_write(ndev, db_bits,
|
|
|
|
ndev->peer_mmio +
|
|
|
|
ndev->peer_reg->db_bell);
|
|
|
|
}
|
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 06:27:12 +04:00
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
int intel_ntb_spad_is_unsafe(struct ntb_dev *ntb)
|
2015-04-09 17:33:20 +03:00
|
|
|
{
|
|
|
|
return ndev_ignore_unsafe(ntb_ndev(ntb), NTB_UNSAFE_SPAD);
|
|
|
|
}
|
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 06:27:12 +04:00
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
int intel_ntb_spad_count(struct ntb_dev *ntb)
|
2015-04-09 17:33:20 +03:00
|
|
|
{
|
|
|
|
struct intel_ntb_dev *ndev;
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
ndev = container_of(ntb, struct intel_ntb_dev, ntb);
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
return ndev->spad_count;
|
|
|
|
}
|
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 06:27:12 +04:00
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
u32 intel_ntb_spad_read(struct ntb_dev *ntb, int idx)
|
2015-04-09 17:33:20 +03:00
|
|
|
{
|
|
|
|
struct intel_ntb_dev *ndev = ntb_ndev(ntb);
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
return ndev_spad_read(ndev, idx,
|
|
|
|
ndev->self_mmio +
|
|
|
|
ndev->self_reg->spad);
|
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 06:27:12 +04:00
|
|
|
}
|
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
int intel_ntb_spad_write(struct ntb_dev *ntb, int idx, u32 val)
|
2014-03-11 20:00:22 +04:00
|
|
|
{
|
2015-04-09 17:33:20 +03:00
|
|
|
struct intel_ntb_dev *ndev = ntb_ndev(ntb);
|
2014-03-11 20:00:22 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
return ndev_spad_write(ndev, idx, val,
|
|
|
|
ndev->self_mmio +
|
|
|
|
ndev->self_reg->spad);
|
|
|
|
}
|
2014-03-11 20:00:22 +04:00
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
int intel_ntb_peer_spad_addr(struct ntb_dev *ntb, int pidx, int sidx,
|
|
|
|
phys_addr_t *spad_addr)
|
2015-04-09 17:33:20 +03:00
|
|
|
{
|
|
|
|
struct intel_ntb_dev *ndev = ntb_ndev(ntb);
|
2014-03-11 20:00:22 +04:00
|
|
|
|
2017-01-11 03:13:20 +03:00
|
|
|
return ndev_spad_addr(ndev, sidx, spad_addr, ndev->peer_addr,
|
2015-04-09 17:33:20 +03:00
|
|
|
ndev->peer_reg->spad);
|
|
|
|
}
|
2014-03-11 20:00:22 +04:00
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
u32 intel_ntb_peer_spad_read(struct ntb_dev *ntb, int pidx, int sidx)
|
2015-04-09 17:33:20 +03:00
|
|
|
{
|
|
|
|
struct intel_ntb_dev *ndev = ntb_ndev(ntb);
|
2014-03-11 20:00:22 +04:00
|
|
|
|
2017-01-11 03:13:20 +03:00
|
|
|
return ndev_spad_read(ndev, sidx,
|
2015-04-09 17:33:20 +03:00
|
|
|
ndev->peer_mmio +
|
|
|
|
ndev->peer_reg->spad);
|
|
|
|
}
|
2014-03-11 20:00:22 +04:00
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
int intel_ntb_peer_spad_write(struct ntb_dev *ntb, int pidx, int sidx,
|
|
|
|
u32 val)
|
2015-04-09 17:33:20 +03:00
|
|
|
{
|
|
|
|
struct intel_ntb_dev *ndev = ntb_ndev(ntb);
|
2014-03-11 20:00:22 +04:00
|
|
|
|
2017-01-11 03:13:20 +03:00
|
|
|
return ndev_spad_write(ndev, sidx, val,
|
2015-04-09 17:33:20 +03:00
|
|
|
ndev->peer_mmio +
|
|
|
|
ndev->peer_reg->spad);
|
|
|
|
}
|
2014-03-11 20:00:22 +04:00
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
static u64 xeon_db_ioread(void __iomem *mmio)
|
2015-04-09 17:33:20 +03:00
|
|
|
{
|
|
|
|
return (u64)ioread16(mmio);
|
|
|
|
}
|
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 06:27:12 +04:00
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
static void xeon_db_iowrite(u64 bits, void __iomem *mmio)
|
2015-04-09 17:33:20 +03:00
|
|
|
{
|
|
|
|
iowrite16((u16)bits, mmio);
|
|
|
|
}
|
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 06:27:12 +04:00
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
static int xeon_poll_link(struct intel_ntb_dev *ndev)
|
2015-04-09 17:33:20 +03:00
|
|
|
{
|
|
|
|
u16 reg_val;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
ndev->reg->db_iowrite(ndev->db_link_mask,
|
|
|
|
ndev->self_mmio +
|
|
|
|
ndev->self_reg->db_bell);
|
|
|
|
|
|
|
|
rc = pci_read_config_word(ndev->ntb.pdev,
|
2015-05-20 19:55:47 +03:00
|
|
|
XEON_LINK_STATUS_OFFSET, ®_val);
|
2015-04-09 17:33:20 +03:00
|
|
|
if (rc)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (reg_val == ndev->lnk_sta)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
ndev->lnk_sta = reg_val;
|
|
|
|
|
|
|
|
return 1;
|
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 06:27:12 +04:00
|
|
|
}
|
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
int xeon_link_is_up(struct intel_ntb_dev *ndev)
|
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 06:27:12 +04:00
|
|
|
{
|
2015-05-19 23:59:34 +03:00
|
|
|
if (ndev->ntb.topo == NTB_TOPO_SEC)
|
|
|
|
return 1;
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
return NTB_LNK_STA_ACTIVE(ndev->lnk_sta);
|
|
|
|
}
|
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 06:27:12 +04:00
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
enum ntb_topo xeon_ppd_topo(struct intel_ntb_dev *ndev, u8 ppd)
|
2015-04-09 17:33:20 +03:00
|
|
|
{
|
2015-05-20 19:55:47 +03:00
|
|
|
switch (ppd & XEON_PPD_TOPO_MASK) {
|
|
|
|
case XEON_PPD_TOPO_B2B_USD:
|
2015-04-09 17:33:20 +03:00
|
|
|
return NTB_TOPO_B2B_USD;
|
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
case XEON_PPD_TOPO_B2B_DSD:
|
2015-04-09 17:33:20 +03:00
|
|
|
return NTB_TOPO_B2B_DSD;
|
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
case XEON_PPD_TOPO_PRI_USD:
|
|
|
|
case XEON_PPD_TOPO_PRI_DSD: /* accept bogus PRI_DSD */
|
2015-04-09 17:33:20 +03:00
|
|
|
return NTB_TOPO_PRI;
|
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 06:27:12 +04:00
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
case XEON_PPD_TOPO_SEC_USD:
|
|
|
|
case XEON_PPD_TOPO_SEC_DSD: /* accept bogus SEC_DSD */
|
2015-04-09 17:33:20 +03:00
|
|
|
return NTB_TOPO_SEC;
|
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 06:27:12 +04:00
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
return NTB_TOPO_NONE;
|
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 06:27:12 +04:00
|
|
|
}
|
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
static inline int xeon_ppd_bar4_split(struct intel_ntb_dev *ndev, u8 ppd)
|
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 06:27:12 +04:00
|
|
|
{
|
2015-05-20 19:55:47 +03:00
|
|
|
if (ppd & XEON_PPD_SPLIT_BAR_MASK) {
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&ndev->ntb.pdev->dev, "PPD %d split bar\n", ppd);
|
2015-04-09 17:33:20 +03:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
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 06:27:12 +04:00
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
static int xeon_init_isr(struct intel_ntb_dev *ndev)
|
2015-04-09 17:33:20 +03:00
|
|
|
{
|
2015-05-20 19:55:47 +03:00
|
|
|
return ndev_init_isr(ndev, XEON_DB_MSIX_VECTOR_COUNT,
|
|
|
|
XEON_DB_MSIX_VECTOR_COUNT,
|
|
|
|
XEON_DB_MSIX_VECTOR_SHIFT,
|
|
|
|
XEON_DB_TOTAL_SHIFT);
|
2015-04-09 17:33:20 +03:00
|
|
|
}
|
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 06:27:12 +04:00
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
static void xeon_deinit_isr(struct intel_ntb_dev *ndev)
|
2015-04-09 17:33:20 +03:00
|
|
|
{
|
|
|
|
ndev_deinit_isr(ndev);
|
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 06:27:12 +04:00
|
|
|
}
|
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
static int xeon_setup_b2b_mw(struct intel_ntb_dev *ndev,
|
|
|
|
const struct intel_b2b_addr *addr,
|
|
|
|
const struct intel_b2b_addr *peer_addr)
|
2014-04-07 21:55:47 +04:00
|
|
|
{
|
2015-04-09 17:33:20 +03:00
|
|
|
struct pci_dev *pdev;
|
|
|
|
void __iomem *mmio;
|
|
|
|
resource_size_t bar_size;
|
|
|
|
phys_addr_t bar_addr;
|
|
|
|
int b2b_bar;
|
|
|
|
u8 bar_sz;
|
|
|
|
|
2017-01-11 03:33:37 +03:00
|
|
|
pdev = ndev->ntb.pdev;
|
2015-04-09 17:33:20 +03:00
|
|
|
mmio = ndev->self_mmio;
|
|
|
|
|
2015-08-31 16:30:59 +03:00
|
|
|
if (ndev->b2b_idx == UINT_MAX) {
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "not using b2b mw\n");
|
2015-04-09 17:33:20 +03:00
|
|
|
b2b_bar = 0;
|
|
|
|
ndev->b2b_off = 0;
|
|
|
|
} else {
|
|
|
|
b2b_bar = ndev_mw_to_bar(ndev, ndev->b2b_idx);
|
|
|
|
if (b2b_bar < 0)
|
|
|
|
return -EIO;
|
2014-04-07 21:55:47 +04:00
|
|
|
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "using b2b mw bar %d\n", b2b_bar);
|
2014-04-07 21:55:47 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
bar_size = pci_resource_len(ndev->ntb.pdev, b2b_bar);
|
2014-04-07 21:55:47 +04:00
|
|
|
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "b2b bar size %#llx\n", bar_size);
|
2014-04-07 21:55:47 +04:00
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
if (b2b_mw_share && XEON_B2B_MIN_SIZE <= bar_size >> 1) {
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "b2b using first half of bar\n");
|
2015-04-09 17:33:20 +03:00
|
|
|
ndev->b2b_off = bar_size >> 1;
|
2015-05-20 19:55:47 +03:00
|
|
|
} else if (XEON_B2B_MIN_SIZE <= bar_size) {
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "b2b using whole bar\n");
|
2015-04-09 17:33:20 +03:00
|
|
|
ndev->b2b_off = 0;
|
|
|
|
--ndev->mw_count;
|
|
|
|
} else {
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "b2b bar size is too small\n");
|
2015-04-09 17:33:20 +03:00
|
|
|
return -EIO;
|
|
|
|
}
|
2014-04-07 21:55:47 +04:00
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
/* Reset the secondary bar sizes to match the primary bar sizes,
|
|
|
|
* except disable or halve the size of the b2b secondary bar.
|
|
|
|
*
|
|
|
|
* Note: code for each specific bar size register, because the register
|
|
|
|
* offsets are not in a consistent order (bar5sz comes after ppd, odd).
|
|
|
|
*/
|
2015-05-20 19:55:47 +03:00
|
|
|
pci_read_config_byte(pdev, XEON_PBAR23SZ_OFFSET, &bar_sz);
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "PBAR23SZ %#x\n", bar_sz);
|
2015-04-09 17:33:20 +03:00
|
|
|
if (b2b_bar == 2) {
|
|
|
|
if (ndev->b2b_off)
|
|
|
|
bar_sz -= 1;
|
|
|
|
else
|
|
|
|
bar_sz = 0;
|
|
|
|
}
|
2015-05-20 19:55:47 +03:00
|
|
|
pci_write_config_byte(pdev, XEON_SBAR23SZ_OFFSET, bar_sz);
|
|
|
|
pci_read_config_byte(pdev, XEON_SBAR23SZ_OFFSET, &bar_sz);
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "SBAR23SZ %#x\n", bar_sz);
|
2015-04-09 17:33:20 +03:00
|
|
|
|
|
|
|
if (!ndev->bar4_split) {
|
2015-05-20 19:55:47 +03:00
|
|
|
pci_read_config_byte(pdev, XEON_PBAR45SZ_OFFSET, &bar_sz);
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "PBAR45SZ %#x\n", bar_sz);
|
2015-04-09 17:33:20 +03:00
|
|
|
if (b2b_bar == 4) {
|
|
|
|
if (ndev->b2b_off)
|
|
|
|
bar_sz -= 1;
|
|
|
|
else
|
|
|
|
bar_sz = 0;
|
|
|
|
}
|
2015-05-20 19:55:47 +03:00
|
|
|
pci_write_config_byte(pdev, XEON_SBAR45SZ_OFFSET, bar_sz);
|
|
|
|
pci_read_config_byte(pdev, XEON_SBAR45SZ_OFFSET, &bar_sz);
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "SBAR45SZ %#x\n", bar_sz);
|
2015-04-09 17:33:20 +03:00
|
|
|
} else {
|
2015-05-20 19:55:47 +03:00
|
|
|
pci_read_config_byte(pdev, XEON_PBAR4SZ_OFFSET, &bar_sz);
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "PBAR4SZ %#x\n", bar_sz);
|
2015-04-09 17:33:20 +03:00
|
|
|
if (b2b_bar == 4) {
|
|
|
|
if (ndev->b2b_off)
|
|
|
|
bar_sz -= 1;
|
|
|
|
else
|
|
|
|
bar_sz = 0;
|
|
|
|
}
|
2015-05-20 19:55:47 +03:00
|
|
|
pci_write_config_byte(pdev, XEON_SBAR4SZ_OFFSET, bar_sz);
|
|
|
|
pci_read_config_byte(pdev, XEON_SBAR4SZ_OFFSET, &bar_sz);
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "SBAR4SZ %#x\n", bar_sz);
|
2015-04-09 17:33:20 +03:00
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
pci_read_config_byte(pdev, XEON_PBAR5SZ_OFFSET, &bar_sz);
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "PBAR5SZ %#x\n", bar_sz);
|
2015-04-09 17:33:20 +03:00
|
|
|
if (b2b_bar == 5) {
|
|
|
|
if (ndev->b2b_off)
|
|
|
|
bar_sz -= 1;
|
|
|
|
else
|
|
|
|
bar_sz = 0;
|
|
|
|
}
|
2015-05-20 19:55:47 +03:00
|
|
|
pci_write_config_byte(pdev, XEON_SBAR5SZ_OFFSET, bar_sz);
|
|
|
|
pci_read_config_byte(pdev, XEON_SBAR5SZ_OFFSET, &bar_sz);
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "SBAR5SZ %#x\n", bar_sz);
|
2015-04-09 17:33:20 +03:00
|
|
|
}
|
2014-04-07 21:55:47 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
/* SBAR01 hit by first part of the b2b bar */
|
|
|
|
if (b2b_bar == 0)
|
|
|
|
bar_addr = addr->bar0_addr;
|
|
|
|
else if (b2b_bar == 2)
|
|
|
|
bar_addr = addr->bar2_addr64;
|
|
|
|
else if (b2b_bar == 4 && !ndev->bar4_split)
|
|
|
|
bar_addr = addr->bar4_addr64;
|
|
|
|
else if (b2b_bar == 4)
|
|
|
|
bar_addr = addr->bar4_addr32;
|
|
|
|
else if (b2b_bar == 5)
|
|
|
|
bar_addr = addr->bar5_addr32;
|
|
|
|
else
|
|
|
|
return -EIO;
|
2014-04-07 21:55:47 +04:00
|
|
|
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "SBAR01 %#018llx\n", bar_addr);
|
2015-05-20 19:55:47 +03:00
|
|
|
iowrite64(bar_addr, mmio + XEON_SBAR0BASE_OFFSET);
|
2014-04-07 21:55:47 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
/* Other SBAR are normally hit by the PBAR xlat, except for b2b bar.
|
|
|
|
* The b2b bar is either disabled above, or configured half-size, and
|
|
|
|
* it starts at the PBAR xlat + offset.
|
|
|
|
*/
|
2013-07-31 02:58:49 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
bar_addr = addr->bar2_addr64 + (b2b_bar == 2 ? ndev->b2b_off : 0);
|
2015-05-20 19:55:47 +03:00
|
|
|
iowrite64(bar_addr, mmio + XEON_SBAR23BASE_OFFSET);
|
|
|
|
bar_addr = ioread64(mmio + XEON_SBAR23BASE_OFFSET);
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "SBAR23 %#018llx\n", bar_addr);
|
2015-04-09 17:33:20 +03:00
|
|
|
|
|
|
|
if (!ndev->bar4_split) {
|
|
|
|
bar_addr = addr->bar4_addr64 +
|
|
|
|
(b2b_bar == 4 ? ndev->b2b_off : 0);
|
2015-05-20 19:55:47 +03:00
|
|
|
iowrite64(bar_addr, mmio + XEON_SBAR45BASE_OFFSET);
|
|
|
|
bar_addr = ioread64(mmio + XEON_SBAR45BASE_OFFSET);
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "SBAR45 %#018llx\n", bar_addr);
|
2015-04-09 17:33:20 +03:00
|
|
|
} else {
|
|
|
|
bar_addr = addr->bar4_addr32 +
|
|
|
|
(b2b_bar == 4 ? ndev->b2b_off : 0);
|
2015-05-20 19:55:47 +03:00
|
|
|
iowrite32(bar_addr, mmio + XEON_SBAR4BASE_OFFSET);
|
|
|
|
bar_addr = ioread32(mmio + XEON_SBAR4BASE_OFFSET);
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "SBAR4 %#010llx\n", bar_addr);
|
2015-04-09 17:33:20 +03:00
|
|
|
|
|
|
|
bar_addr = addr->bar5_addr32 +
|
|
|
|
(b2b_bar == 5 ? ndev->b2b_off : 0);
|
2015-05-20 19:55:47 +03:00
|
|
|
iowrite32(bar_addr, mmio + XEON_SBAR5BASE_OFFSET);
|
|
|
|
bar_addr = ioread32(mmio + XEON_SBAR5BASE_OFFSET);
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "SBAR5 %#010llx\n", bar_addr);
|
2015-04-09 17:33:20 +03:00
|
|
|
}
|
2013-07-31 02:58:49 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
/* setup incoming bar limits == base addrs (zero length windows) */
|
2013-07-31 02:58:49 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
bar_addr = addr->bar2_addr64 + (b2b_bar == 2 ? ndev->b2b_off : 0);
|
2015-05-20 19:55:47 +03:00
|
|
|
iowrite64(bar_addr, mmio + XEON_SBAR23LMT_OFFSET);
|
|
|
|
bar_addr = ioread64(mmio + XEON_SBAR23LMT_OFFSET);
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "SBAR23LMT %#018llx\n", bar_addr);
|
2013-07-31 02:58:49 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
if (!ndev->bar4_split) {
|
|
|
|
bar_addr = addr->bar4_addr64 +
|
|
|
|
(b2b_bar == 4 ? ndev->b2b_off : 0);
|
2015-05-20 19:55:47 +03:00
|
|
|
iowrite64(bar_addr, mmio + XEON_SBAR45LMT_OFFSET);
|
|
|
|
bar_addr = ioread64(mmio + XEON_SBAR45LMT_OFFSET);
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "SBAR45LMT %#018llx\n", bar_addr);
|
2015-04-09 17:33:20 +03:00
|
|
|
} else {
|
|
|
|
bar_addr = addr->bar4_addr32 +
|
|
|
|
(b2b_bar == 4 ? ndev->b2b_off : 0);
|
2015-05-20 19:55:47 +03:00
|
|
|
iowrite32(bar_addr, mmio + XEON_SBAR4LMT_OFFSET);
|
|
|
|
bar_addr = ioread32(mmio + XEON_SBAR4LMT_OFFSET);
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "SBAR4LMT %#010llx\n", bar_addr);
|
2015-04-09 17:33:20 +03:00
|
|
|
|
|
|
|
bar_addr = addr->bar5_addr32 +
|
|
|
|
(b2b_bar == 5 ? ndev->b2b_off : 0);
|
2015-05-20 19:55:47 +03:00
|
|
|
iowrite32(bar_addr, mmio + XEON_SBAR5LMT_OFFSET);
|
|
|
|
bar_addr = ioread32(mmio + XEON_SBAR5LMT_OFFSET);
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "SBAR5LMT %#05llx\n", bar_addr);
|
2013-07-31 02:58:49 +04:00
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
/* zero incoming translation addrs */
|
2015-05-20 19:55:47 +03:00
|
|
|
iowrite64(0, mmio + XEON_SBAR23XLAT_OFFSET);
|
2013-10-04 04:24:03 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
if (!ndev->bar4_split) {
|
2015-05-20 19:55:47 +03:00
|
|
|
iowrite64(0, mmio + XEON_SBAR45XLAT_OFFSET);
|
2015-04-09 17:33:20 +03:00
|
|
|
} else {
|
2015-05-20 19:55:47 +03:00
|
|
|
iowrite32(0, mmio + XEON_SBAR4XLAT_OFFSET);
|
|
|
|
iowrite32(0, mmio + XEON_SBAR5XLAT_OFFSET);
|
2015-04-09 17:33:20 +03:00
|
|
|
}
|
2014-08-29 00:53:23 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
/* zero outgoing translation limits (whole bar size windows) */
|
2015-05-20 19:55:47 +03:00
|
|
|
iowrite64(0, mmio + XEON_PBAR23LMT_OFFSET);
|
2015-04-09 17:33:20 +03:00
|
|
|
if (!ndev->bar4_split) {
|
2015-05-20 19:55:47 +03:00
|
|
|
iowrite64(0, mmio + XEON_PBAR45LMT_OFFSET);
|
2015-04-09 17:33:20 +03:00
|
|
|
} else {
|
2015-05-20 19:55:47 +03:00
|
|
|
iowrite32(0, mmio + XEON_PBAR4LMT_OFFSET);
|
|
|
|
iowrite32(0, mmio + XEON_PBAR5LMT_OFFSET);
|
2013-10-04 04:24:03 +04:00
|
|
|
}
|
2013-09-14 04:05:23 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
/* set outgoing translation offsets */
|
|
|
|
bar_addr = peer_addr->bar2_addr64;
|
2015-05-20 19:55:47 +03:00
|
|
|
iowrite64(bar_addr, mmio + XEON_PBAR23XLAT_OFFSET);
|
|
|
|
bar_addr = ioread64(mmio + XEON_PBAR23XLAT_OFFSET);
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "PBAR23XLAT %#018llx\n", bar_addr);
|
2015-04-09 17:33:20 +03:00
|
|
|
|
|
|
|
if (!ndev->bar4_split) {
|
|
|
|
bar_addr = peer_addr->bar4_addr64;
|
2015-05-20 19:55:47 +03:00
|
|
|
iowrite64(bar_addr, mmio + XEON_PBAR45XLAT_OFFSET);
|
|
|
|
bar_addr = ioread64(mmio + XEON_PBAR45XLAT_OFFSET);
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "PBAR45XLAT %#018llx\n", bar_addr);
|
2015-04-09 17:33:20 +03:00
|
|
|
} else {
|
|
|
|
bar_addr = peer_addr->bar4_addr32;
|
2015-05-20 19:55:47 +03:00
|
|
|
iowrite32(bar_addr, mmio + XEON_PBAR4XLAT_OFFSET);
|
|
|
|
bar_addr = ioread32(mmio + XEON_PBAR4XLAT_OFFSET);
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "PBAR4XLAT %#010llx\n", bar_addr);
|
2015-04-09 17:33:20 +03:00
|
|
|
|
|
|
|
bar_addr = peer_addr->bar5_addr32;
|
2015-05-20 19:55:47 +03:00
|
|
|
iowrite32(bar_addr, mmio + XEON_PBAR5XLAT_OFFSET);
|
|
|
|
bar_addr = ioread32(mmio + XEON_PBAR5XLAT_OFFSET);
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "PBAR5XLAT %#010llx\n", bar_addr);
|
2015-04-09 17:33:20 +03:00
|
|
|
}
|
2013-09-14 04:05:23 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
/* set the translation offset for b2b registers */
|
|
|
|
if (b2b_bar == 0)
|
|
|
|
bar_addr = peer_addr->bar0_addr;
|
|
|
|
else if (b2b_bar == 2)
|
|
|
|
bar_addr = peer_addr->bar2_addr64;
|
|
|
|
else if (b2b_bar == 4 && !ndev->bar4_split)
|
|
|
|
bar_addr = peer_addr->bar4_addr64;
|
|
|
|
else if (b2b_bar == 4)
|
|
|
|
bar_addr = peer_addr->bar4_addr32;
|
|
|
|
else if (b2b_bar == 5)
|
|
|
|
bar_addr = peer_addr->bar5_addr32;
|
|
|
|
else
|
|
|
|
return -EIO;
|
|
|
|
|
|
|
|
/* B2B_XLAT_OFFSET is 64bit, but can only take 32bit writes */
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "B2BXLAT %#018llx\n", bar_addr);
|
2015-05-20 19:55:47 +03:00
|
|
|
iowrite32(bar_addr, mmio + XEON_B2B_XLAT_OFFSETL);
|
|
|
|
iowrite32(bar_addr >> 32, mmio + XEON_B2B_XLAT_OFFSETU);
|
2015-04-09 17:33:20 +03:00
|
|
|
|
|
|
|
if (b2b_bar) {
|
|
|
|
/* map peer ntb mmio config space registers */
|
|
|
|
ndev->peer_mmio = pci_iomap(pdev, b2b_bar,
|
2015-05-20 19:55:47 +03:00
|
|
|
XEON_B2B_MIN_SIZE);
|
2015-04-09 17:33:20 +03:00
|
|
|
if (!ndev->peer_mmio)
|
|
|
|
return -EIO;
|
2016-10-27 21:06:44 +03:00
|
|
|
|
|
|
|
ndev->peer_addr = pci_resource_start(pdev, b2b_bar);
|
2013-09-14 04:05:23 +04:00
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
return 0;
|
2013-09-14 04:05:23 +04:00
|
|
|
}
|
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
static int xeon_init_ntb(struct intel_ntb_dev *ndev)
|
2014-08-29 00:53:23 +04:00
|
|
|
{
|
2017-01-11 03:33:37 +03:00
|
|
|
struct device *dev = &ndev->ntb.pdev->dev;
|
2015-04-09 17:33:20 +03:00
|
|
|
int rc;
|
2015-05-19 23:59:34 +03:00
|
|
|
u32 ntb_ctl;
|
2015-04-09 17:33:20 +03:00
|
|
|
|
|
|
|
if (ndev->bar4_split)
|
|
|
|
ndev->mw_count = HSX_SPLIT_BAR_MW_COUNT;
|
2014-08-29 00:53:23 +04:00
|
|
|
else
|
2015-05-20 19:55:47 +03:00
|
|
|
ndev->mw_count = XEON_MW_COUNT;
|
2014-08-29 00:53:23 +04:00
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
ndev->spad_count = XEON_SPAD_COUNT;
|
|
|
|
ndev->db_count = XEON_DB_COUNT;
|
|
|
|
ndev->db_link_mask = XEON_DB_LINK_BIT;
|
2014-08-29 00:53:13 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
switch (ndev->ntb.topo) {
|
|
|
|
case NTB_TOPO_PRI:
|
|
|
|
if (ndev->hwerr_flags & NTB_HWERR_SDOORBELL_LOCKUP) {
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_err(dev, "NTB Primary config disabled\n");
|
2015-04-09 17:33:20 +03:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
2015-05-19 23:59:34 +03:00
|
|
|
|
|
|
|
/* enable link to allow secondary side device to appear */
|
|
|
|
ntb_ctl = ioread32(ndev->self_mmio + ndev->reg->ntb_ctl);
|
|
|
|
ntb_ctl &= ~NTB_CTL_DISABLE;
|
|
|
|
iowrite32(ntb_ctl, ndev->self_mmio + ndev->reg->ntb_ctl);
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
/* use half the spads for the peer */
|
|
|
|
ndev->spad_count >>= 1;
|
2015-05-20 19:55:47 +03:00
|
|
|
ndev->self_reg = &xeon_pri_reg;
|
|
|
|
ndev->peer_reg = &xeon_sec_reg;
|
|
|
|
ndev->xlat_reg = &xeon_sec_xlat;
|
2015-04-09 17:33:20 +03:00
|
|
|
break;
|
2014-08-29 00:53:13 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
case NTB_TOPO_SEC:
|
|
|
|
if (ndev->hwerr_flags & NTB_HWERR_SDOORBELL_LOCKUP) {
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_err(dev, "NTB Secondary config disabled\n");
|
2015-04-09 17:33:20 +03:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
/* use half the spads for the peer */
|
|
|
|
ndev->spad_count >>= 1;
|
2015-05-20 19:55:47 +03:00
|
|
|
ndev->self_reg = &xeon_sec_reg;
|
|
|
|
ndev->peer_reg = &xeon_pri_reg;
|
|
|
|
ndev->xlat_reg = &xeon_pri_xlat;
|
2015-04-09 17:33:20 +03:00
|
|
|
break;
|
2014-08-29 00:53:13 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
case NTB_TOPO_B2B_USD:
|
|
|
|
case NTB_TOPO_B2B_DSD:
|
2015-05-20 19:55:47 +03:00
|
|
|
ndev->self_reg = &xeon_pri_reg;
|
|
|
|
ndev->peer_reg = &xeon_b2b_reg;
|
|
|
|
ndev->xlat_reg = &xeon_sec_xlat;
|
2014-08-29 00:53:13 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
if (ndev->hwerr_flags & NTB_HWERR_SDOORBELL_LOCKUP) {
|
2015-05-20 19:55:47 +03:00
|
|
|
ndev->peer_reg = &xeon_pri_reg;
|
2014-08-29 00:53:23 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
if (b2b_mw_idx < 0)
|
|
|
|
ndev->b2b_idx = b2b_mw_idx + ndev->mw_count;
|
|
|
|
else
|
|
|
|
ndev->b2b_idx = b2b_mw_idx;
|
2014-08-29 00:53:23 +04:00
|
|
|
|
2015-08-31 16:30:59 +03:00
|
|
|
if (ndev->b2b_idx >= ndev->mw_count) {
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(dev,
|
2015-08-31 16:30:59 +03:00
|
|
|
"b2b_mw_idx %d invalid for mw_count %u\n",
|
|
|
|
b2b_mw_idx, ndev->mw_count);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(dev, "setting up b2b mw idx %d means %d\n",
|
2015-04-09 17:33:20 +03:00
|
|
|
b2b_mw_idx, ndev->b2b_idx);
|
|
|
|
|
|
|
|
} else if (ndev->hwerr_flags & NTB_HWERR_B2BDOORBELL_BIT14) {
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_warn(dev, "Reduce doorbell count by 1\n");
|
2015-04-09 17:33:20 +03:00
|
|
|
ndev->db_count -= 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ndev->ntb.topo == NTB_TOPO_B2B_USD) {
|
2015-05-20 19:55:47 +03:00
|
|
|
rc = xeon_setup_b2b_mw(ndev,
|
|
|
|
&xeon_b2b_dsd_addr,
|
|
|
|
&xeon_b2b_usd_addr);
|
2015-04-09 17:33:20 +03:00
|
|
|
} else {
|
2015-05-20 19:55:47 +03:00
|
|
|
rc = xeon_setup_b2b_mw(ndev,
|
|
|
|
&xeon_b2b_usd_addr,
|
|
|
|
&xeon_b2b_dsd_addr);
|
2015-04-09 17:33:20 +03:00
|
|
|
}
|
|
|
|
if (rc)
|
|
|
|
return rc;
|
|
|
|
|
|
|
|
/* Enable Bus Master and Memory Space on the secondary side */
|
|
|
|
iowrite16(PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER,
|
2015-05-20 19:55:47 +03:00
|
|
|
ndev->self_mmio + XEON_SPCICMD_OFFSET);
|
2014-08-29 00:53:23 +04:00
|
|
|
|
2014-08-29 00:53:13 +04:00
|
|
|
break;
|
2015-04-09 17:33:20 +03:00
|
|
|
|
2014-08-29 00:53:13 +04:00
|
|
|
default:
|
2015-04-09 17:33:20 +03:00
|
|
|
return -EINVAL;
|
2014-08-29 00:53:13 +04:00
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
ndev->db_valid_mask = BIT_ULL(ndev->db_count) - 1;
|
|
|
|
|
|
|
|
ndev->reg->db_iowrite(ndev->db_valid_mask,
|
|
|
|
ndev->self_mmio +
|
|
|
|
ndev->self_reg->db_mask);
|
2014-08-29 00:53:23 +04:00
|
|
|
|
2014-08-29 00:53:13 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
static int xeon_init_dev(struct intel_ntb_dev *ndev)
|
2014-08-29 00:53:13 +04:00
|
|
|
{
|
2015-04-09 17:33:20 +03:00
|
|
|
struct pci_dev *pdev;
|
|
|
|
u8 ppd;
|
|
|
|
int rc, mem;
|
|
|
|
|
2017-01-11 03:33:37 +03:00
|
|
|
pdev = ndev->ntb.pdev;
|
2015-05-08 19:24:40 +03:00
|
|
|
|
|
|
|
switch (pdev->device) {
|
2015-04-09 17:33:20 +03:00
|
|
|
/* 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 use the second memory
|
|
|
|
* window to access the interrupt and scratch pad registers on the
|
|
|
|
* remote system.
|
|
|
|
*/
|
2015-05-08 19:24:40 +03:00
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_SS_JSF:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_PS_JSF:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_B2B_JSF:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_SS_SNB:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_PS_SNB:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_B2B_SNB:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_SS_IVT:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_PS_IVT:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_B2B_IVT:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_SS_HSX:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_PS_HSX:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_B2B_HSX:
|
2015-07-13 15:07:18 +03:00
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_SS_BDX:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_PS_BDX:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_B2B_BDX:
|
2015-05-08 19:24:40 +03:00
|
|
|
ndev->hwerr_flags |= NTB_HWERR_SDOORBELL_LOCKUP;
|
|
|
|
break;
|
|
|
|
}
|
2014-08-29 00:53:13 +04:00
|
|
|
|
2015-05-08 19:24:40 +03:00
|
|
|
switch (pdev->device) {
|
2015-04-09 17:33:20 +03:00
|
|
|
/* There is a hardware errata related to accessing any register in
|
|
|
|
* SB01BASE in the presence of bidirectional traffic crossing the NTB.
|
|
|
|
*/
|
2015-05-08 19:24:40 +03:00
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_SS_IVT:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_PS_IVT:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_B2B_IVT:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_SS_HSX:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_PS_HSX:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_B2B_HSX:
|
2015-07-13 15:07:18 +03:00
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_SS_BDX:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_PS_BDX:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_B2B_BDX:
|
2015-05-08 19:24:40 +03:00
|
|
|
ndev->hwerr_flags |= NTB_HWERR_SB01BASE_LOCKUP;
|
|
|
|
break;
|
|
|
|
}
|
2015-04-09 17:33:20 +03:00
|
|
|
|
2015-05-08 19:24:40 +03:00
|
|
|
switch (pdev->device) {
|
2015-04-09 17:33:20 +03:00
|
|
|
/* HW Errata on bit 14 of b2bdoorbell register. Writes will not be
|
|
|
|
* mirrored to the remote system. Shrink the number of bits by one,
|
|
|
|
* since bit 14 is the last bit.
|
|
|
|
*/
|
2015-05-08 19:24:40 +03:00
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_SS_JSF:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_PS_JSF:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_B2B_JSF:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_SS_SNB:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_PS_SNB:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_B2B_SNB:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_SS_IVT:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_PS_IVT:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_B2B_IVT:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_SS_HSX:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_PS_HSX:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_B2B_HSX:
|
2015-07-13 15:07:18 +03:00
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_SS_BDX:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_PS_BDX:
|
|
|
|
case PCI_DEVICE_ID_INTEL_NTB_B2B_BDX:
|
2015-05-08 19:24:40 +03:00
|
|
|
ndev->hwerr_flags |= NTB_HWERR_B2BDOORBELL_BIT14;
|
|
|
|
break;
|
|
|
|
}
|
2014-08-29 00:53:13 +04:00
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
ndev->reg = &xeon_reg;
|
2015-04-09 17:33:20 +03:00
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
rc = pci_read_config_byte(pdev, XEON_PPD_OFFSET, &ppd);
|
2014-08-29 00:53:13 +04:00
|
|
|
if (rc)
|
2015-04-09 17:33:20 +03:00
|
|
|
return -EIO;
|
2014-08-29 00:53:13 +04:00
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
ndev->ntb.topo = xeon_ppd_topo(ndev, ppd);
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "ppd %#x topo %s\n", ppd,
|
2015-04-09 17:33:20 +03:00
|
|
|
ntb_topo_string(ndev->ntb.topo));
|
|
|
|
if (ndev->ntb.topo == NTB_TOPO_NONE)
|
2014-08-29 00:53:13 +04:00
|
|
|
return -EINVAL;
|
2015-04-09 17:33:20 +03:00
|
|
|
|
|
|
|
if (ndev->ntb.topo != NTB_TOPO_SEC) {
|
2015-05-20 19:55:47 +03:00
|
|
|
ndev->bar4_split = xeon_ppd_bar4_split(ndev, ppd);
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "ppd %#x bar4_split %d\n",
|
2015-04-09 17:33:20 +03:00
|
|
|
ppd, ndev->bar4_split);
|
|
|
|
} else {
|
|
|
|
/* This is a way for transparent BAR to figure out if we are
|
|
|
|
* doing split BAR or not. There is no way for the hw on the
|
|
|
|
* transparent side to know and set the PPD.
|
|
|
|
*/
|
|
|
|
mem = pci_select_bars(pdev, IORESOURCE_MEM);
|
|
|
|
ndev->bar4_split = hweight32(mem) ==
|
|
|
|
HSX_SPLIT_BAR_MW_COUNT + 1;
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_dbg(&pdev->dev, "mem %#x bar4_split %d\n",
|
2015-04-09 17:33:20 +03:00
|
|
|
mem, ndev->bar4_split);
|
2014-08-29 00:53:13 +04:00
|
|
|
}
|
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
rc = xeon_init_ntb(ndev);
|
2015-04-09 17:33:20 +03:00
|
|
|
if (rc)
|
|
|
|
return rc;
|
2014-08-29 00:53:13 +04:00
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
return xeon_init_isr(ndev);
|
2015-04-09 17:33:20 +03:00
|
|
|
}
|
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
static void xeon_deinit_dev(struct intel_ntb_dev *ndev)
|
2015-04-09 17:33:20 +03:00
|
|
|
{
|
2015-05-20 19:55:47 +03:00
|
|
|
xeon_deinit_isr(ndev);
|
2014-08-29 00:53:13 +04:00
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static int intel_ntb_init_pci(struct intel_ntb_dev *ndev, struct pci_dev *pdev)
|
2014-08-29 00:53:13 +04:00
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
pci_set_drvdata(pdev, ndev);
|
|
|
|
|
|
|
|
rc = pci_enable_device(pdev);
|
|
|
|
if (rc)
|
|
|
|
goto err_pci_enable;
|
|
|
|
|
|
|
|
rc = pci_request_regions(pdev, NTB_NAME);
|
|
|
|
if (rc)
|
|
|
|
goto err_pci_regions;
|
|
|
|
|
|
|
|
pci_set_master(pdev);
|
|
|
|
|
|
|
|
rc = pci_set_dma_mask(pdev, DMA_BIT_MASK(64));
|
|
|
|
if (rc) {
|
|
|
|
rc = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
|
|
|
|
if (rc)
|
|
|
|
goto err_dma_mask;
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_warn(&pdev->dev, "Cannot DMA highmem\n");
|
2015-04-09 17:33:20 +03:00
|
|
|
}
|
2014-08-29 00:53:13 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
rc = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64));
|
|
|
|
if (rc) {
|
|
|
|
rc = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(32));
|
|
|
|
if (rc)
|
|
|
|
goto err_dma_mask;
|
2017-01-11 03:33:37 +03:00
|
|
|
dev_warn(&pdev->dev, "Cannot DMA consistent highmem\n");
|
2015-04-09 17:33:20 +03:00
|
|
|
}
|
2017-12-06 17:31:53 +03:00
|
|
|
rc = dma_coerce_mask_and_coherent(&ndev->ntb.dev,
|
|
|
|
dma_get_mask(&pdev->dev));
|
|
|
|
if (rc)
|
|
|
|
goto err_dma_mask;
|
2015-04-09 17:33:20 +03:00
|
|
|
|
|
|
|
ndev->self_mmio = pci_iomap(pdev, 0, 0);
|
|
|
|
if (!ndev->self_mmio) {
|
|
|
|
rc = -EIO;
|
|
|
|
goto err_mmio;
|
|
|
|
}
|
|
|
|
ndev->peer_mmio = ndev->self_mmio;
|
2016-10-27 21:06:44 +03:00
|
|
|
ndev->peer_addr = pci_resource_start(pdev, 0);
|
2014-08-29 00:53:13 +04:00
|
|
|
|
|
|
|
return 0;
|
2015-04-09 17:33:20 +03:00
|
|
|
|
|
|
|
err_mmio:
|
|
|
|
err_dma_mask:
|
|
|
|
pci_clear_master(pdev);
|
|
|
|
pci_release_regions(pdev);
|
|
|
|
err_pci_regions:
|
|
|
|
pci_disable_device(pdev);
|
|
|
|
err_pci_enable:
|
|
|
|
pci_set_drvdata(pdev, NULL);
|
|
|
|
return rc;
|
2014-08-29 00:53:13 +04:00
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static void intel_ntb_deinit_pci(struct intel_ntb_dev *ndev)
|
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 06:27:12 +04:00
|
|
|
{
|
2017-01-11 03:33:37 +03:00
|
|
|
struct pci_dev *pdev = ndev->ntb.pdev;
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
if (ndev->peer_mmio && ndev->peer_mmio != ndev->self_mmio)
|
|
|
|
pci_iounmap(pdev, ndev->peer_mmio);
|
|
|
|
pci_iounmap(pdev, ndev->self_mmio);
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
pci_clear_master(pdev);
|
|
|
|
pci_release_regions(pdev);
|
|
|
|
pci_disable_device(pdev);
|
|
|
|
pci_set_drvdata(pdev, NULL);
|
|
|
|
}
|
2014-08-29 00:53:18 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static inline void ndev_init_struct(struct intel_ntb_dev *ndev,
|
|
|
|
struct pci_dev *pdev)
|
|
|
|
{
|
|
|
|
ndev->ntb.pdev = pdev;
|
|
|
|
ndev->ntb.topo = NTB_TOPO_NONE;
|
|
|
|
ndev->ntb.ops = &intel_ntb_ops;
|
2014-08-29 00:53:18 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
ndev->b2b_off = 0;
|
2015-08-31 16:30:59 +03:00
|
|
|
ndev->b2b_idx = UINT_MAX;
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
ndev->bar4_split = 0;
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
ndev->mw_count = 0;
|
|
|
|
ndev->spad_count = 0;
|
|
|
|
ndev->db_count = 0;
|
|
|
|
ndev->db_vec_count = 0;
|
|
|
|
ndev->db_vec_shift = 0;
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
ndev->ntb_ctl = 0;
|
|
|
|
ndev->lnk_sta = 0;
|
2014-08-29 00:53:13 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
ndev->db_valid_mask = 0;
|
|
|
|
ndev->db_link_mask = 0;
|
|
|
|
ndev->db_mask = 0;
|
2014-08-29 00:53:23 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
spin_lock_init(&ndev->db_mask_lock);
|
|
|
|
}
|
2014-08-29 00:53:23 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static int intel_ntb_pci_probe(struct pci_dev *pdev,
|
|
|
|
const struct pci_device_id *id)
|
|
|
|
{
|
|
|
|
struct intel_ntb_dev *ndev;
|
2015-05-19 19:04:52 +03:00
|
|
|
int rc, node;
|
|
|
|
|
|
|
|
node = dev_to_node(&pdev->dev);
|
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 06:27:12 +04:00
|
|
|
|
2017-11-20 20:24:08 +03:00
|
|
|
if (pdev_is_xeon(pdev)) {
|
2015-05-19 19:04:52 +03:00
|
|
|
ndev = kzalloc_node(sizeof(*ndev), GFP_KERNEL, node);
|
2015-04-09 17:33:20 +03:00
|
|
|
if (!ndev) {
|
|
|
|
rc = -ENOMEM;
|
|
|
|
goto err_ndev;
|
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 06:27:12 +04:00
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
ndev_init_struct(ndev, pdev);
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
rc = intel_ntb_init_pci(ndev, pdev);
|
|
|
|
if (rc)
|
|
|
|
goto err_init_pci;
|
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 06:27:12 +04:00
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
rc = xeon_init_dev(ndev);
|
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 06:27:12 +04:00
|
|
|
if (rc)
|
2015-04-09 17:33:20 +03:00
|
|
|
goto err_init_dev;
|
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 06:27:12 +04:00
|
|
|
|
2016-11-17 00:03:38 +03:00
|
|
|
} else if (pdev_is_skx_xeon(pdev)) {
|
|
|
|
ndev = kzalloc_node(sizeof(*ndev), GFP_KERNEL, node);
|
|
|
|
if (!ndev) {
|
|
|
|
rc = -ENOMEM;
|
|
|
|
goto err_ndev;
|
|
|
|
}
|
|
|
|
|
|
|
|
ndev_init_struct(ndev, pdev);
|
|
|
|
ndev->ntb.ops = &intel_ntb3_ops;
|
|
|
|
|
|
|
|
rc = intel_ntb_init_pci(ndev, pdev);
|
|
|
|
if (rc)
|
|
|
|
goto err_init_pci;
|
|
|
|
|
|
|
|
rc = skx_init_dev(ndev);
|
|
|
|
if (rc)
|
|
|
|
goto err_init_dev;
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
} else {
|
|
|
|
rc = -EINVAL;
|
|
|
|
goto err_ndev;
|
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 06:27:12 +04:00
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
ndev_reset_unsafe_flags(ndev);
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
ndev->reg->poll_link(ndev);
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
ndev_init_debugfs(ndev);
|
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 06:27:12 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
rc = ntb_register_device(&ndev->ntb);
|
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 06:27:12 +04:00
|
|
|
if (rc)
|
2015-04-09 17:33:20 +03:00
|
|
|
goto err_register;
|
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 06:27:12 +04:00
|
|
|
|
2015-06-15 15:21:33 +03:00
|
|
|
dev_info(&pdev->dev, "NTB device registered.\n");
|
|
|
|
|
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 06:27:12 +04:00
|
|
|
return 0;
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
err_register:
|
|
|
|
ndev_deinit_debugfs(ndev);
|
2017-11-20 20:24:08 +03:00
|
|
|
if (pdev_is_xeon(pdev) || pdev_is_skx_xeon(pdev))
|
2015-05-20 19:55:47 +03:00
|
|
|
xeon_deinit_dev(ndev);
|
2015-04-09 17:33:20 +03:00
|
|
|
err_init_dev:
|
|
|
|
intel_ntb_deinit_pci(ndev);
|
|
|
|
err_init_pci:
|
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 06:27:12 +04:00
|
|
|
kfree(ndev);
|
2015-04-09 17:33:20 +03:00
|
|
|
err_ndev:
|
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 06:27:12 +04:00
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static void intel_ntb_pci_remove(struct pci_dev *pdev)
|
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 06:27:12 +04:00
|
|
|
{
|
2015-04-09 17:33:20 +03:00
|
|
|
struct intel_ntb_dev *ndev = pci_get_drvdata(pdev);
|
|
|
|
|
|
|
|
ntb_unregister_device(&ndev->ntb);
|
|
|
|
ndev_deinit_debugfs(ndev);
|
2017-11-20 20:24:08 +03:00
|
|
|
if (pdev_is_xeon(pdev) || pdev_is_skx_xeon(pdev))
|
2015-05-20 19:55:47 +03:00
|
|
|
xeon_deinit_dev(ndev);
|
2015-04-09 17:33:20 +03:00
|
|
|
intel_ntb_deinit_pci(ndev);
|
|
|
|
kfree(ndev);
|
|
|
|
}
|
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 06:27:12 +04:00
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
static const struct intel_ntb_reg xeon_reg = {
|
|
|
|
.poll_link = xeon_poll_link,
|
|
|
|
.link_is_up = xeon_link_is_up,
|
|
|
|
.db_ioread = xeon_db_ioread,
|
|
|
|
.db_iowrite = xeon_db_iowrite,
|
2015-04-09 17:33:20 +03:00
|
|
|
.db_size = sizeof(u32),
|
2015-05-20 19:55:47 +03:00
|
|
|
.ntb_ctl = XEON_NTBCNTL_OFFSET,
|
2015-04-09 17:33:20 +03:00
|
|
|
.mw_bar = {2, 4, 5},
|
|
|
|
};
|
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 06:27:12 +04:00
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
static const struct intel_ntb_alt_reg xeon_pri_reg = {
|
|
|
|
.db_bell = XEON_PDOORBELL_OFFSET,
|
|
|
|
.db_mask = XEON_PDBMSK_OFFSET,
|
|
|
|
.spad = XEON_SPAD_OFFSET,
|
2015-04-09 17:33:20 +03:00
|
|
|
};
|
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
static const struct intel_ntb_alt_reg xeon_sec_reg = {
|
|
|
|
.db_bell = XEON_SDOORBELL_OFFSET,
|
|
|
|
.db_mask = XEON_SDBMSK_OFFSET,
|
2015-04-09 17:33:20 +03:00
|
|
|
/* second half of the scratchpads */
|
2015-05-20 19:55:47 +03:00
|
|
|
.spad = XEON_SPAD_OFFSET + (XEON_SPAD_COUNT << 1),
|
2015-04-09 17:33:20 +03:00
|
|
|
};
|
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 06:27:12 +04:00
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
static const struct intel_ntb_alt_reg xeon_b2b_reg = {
|
|
|
|
.db_bell = XEON_B2B_DOORBELL_OFFSET,
|
|
|
|
.spad = XEON_B2B_SPAD_OFFSET,
|
2015-04-09 17:33:20 +03:00
|
|
|
};
|
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
static const struct intel_ntb_xlat_reg xeon_pri_xlat = {
|
2015-04-09 17:33:20 +03:00
|
|
|
/* Note: no primary .bar0_base visible to the secondary side.
|
|
|
|
*
|
|
|
|
* The secondary side cannot get the base address stored in primary
|
|
|
|
* bars. The base address is necessary to set the limit register to
|
|
|
|
* any value other than zero, or unlimited.
|
|
|
|
*
|
|
|
|
* WITHOUT THE BASE ADDRESS, THE SECONDARY SIDE CANNOT DISABLE the
|
|
|
|
* window by setting the limit equal to base, nor can it limit the size
|
|
|
|
* of the memory window by setting the limit to base + size.
|
|
|
|
*/
|
2015-05-20 19:55:47 +03:00
|
|
|
.bar2_limit = XEON_PBAR23LMT_OFFSET,
|
|
|
|
.bar2_xlat = XEON_PBAR23XLAT_OFFSET,
|
2015-04-09 17:33:20 +03:00
|
|
|
};
|
|
|
|
|
2015-05-20 19:55:47 +03:00
|
|
|
static const struct intel_ntb_xlat_reg xeon_sec_xlat = {
|
|
|
|
.bar0_base = XEON_SBAR0BASE_OFFSET,
|
|
|
|
.bar2_limit = XEON_SBAR23LMT_OFFSET,
|
|
|
|
.bar2_xlat = XEON_SBAR23XLAT_OFFSET,
|
2015-04-09 17:33:20 +03:00
|
|
|
};
|
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
struct intel_b2b_addr xeon_b2b_usd_addr = {
|
2015-09-24 23:03:05 +03:00
|
|
|
.bar2_addr64 = XEON_B2B_BAR2_ADDR64,
|
|
|
|
.bar4_addr64 = XEON_B2B_BAR4_ADDR64,
|
|
|
|
.bar4_addr32 = XEON_B2B_BAR4_ADDR32,
|
|
|
|
.bar5_addr32 = XEON_B2B_BAR5_ADDR32,
|
2015-04-09 17:33:20 +03:00
|
|
|
};
|
|
|
|
|
2018-01-29 23:22:24 +03:00
|
|
|
struct intel_b2b_addr xeon_b2b_dsd_addr = {
|
2015-09-24 23:03:05 +03:00
|
|
|
.bar2_addr64 = XEON_B2B_BAR2_ADDR64,
|
|
|
|
.bar4_addr64 = XEON_B2B_BAR4_ADDR64,
|
|
|
|
.bar4_addr32 = XEON_B2B_BAR4_ADDR32,
|
|
|
|
.bar5_addr32 = XEON_B2B_BAR5_ADDR32,
|
2015-04-09 17:33:20 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
/* operations for primary side of local ntb */
|
|
|
|
static const struct ntb_dev_ops intel_ntb_ops = {
|
|
|
|
.mw_count = intel_ntb_mw_count,
|
2017-01-11 03:11:33 +03:00
|
|
|
.mw_get_align = intel_ntb_mw_get_align,
|
2015-04-09 17:33:20 +03:00
|
|
|
.mw_set_trans = intel_ntb_mw_set_trans,
|
2017-01-11 03:11:33 +03:00
|
|
|
.peer_mw_count = intel_ntb_peer_mw_count,
|
|
|
|
.peer_mw_get_addr = intel_ntb_peer_mw_get_addr,
|
2015-04-09 17:33:20 +03:00
|
|
|
.link_is_up = intel_ntb_link_is_up,
|
|
|
|
.link_enable = intel_ntb_link_enable,
|
|
|
|
.link_disable = intel_ntb_link_disable,
|
|
|
|
.db_is_unsafe = intel_ntb_db_is_unsafe,
|
|
|
|
.db_valid_mask = intel_ntb_db_valid_mask,
|
|
|
|
.db_vector_count = intel_ntb_db_vector_count,
|
|
|
|
.db_vector_mask = intel_ntb_db_vector_mask,
|
|
|
|
.db_read = intel_ntb_db_read,
|
|
|
|
.db_clear = intel_ntb_db_clear,
|
|
|
|
.db_set_mask = intel_ntb_db_set_mask,
|
|
|
|
.db_clear_mask = intel_ntb_db_clear_mask,
|
|
|
|
.peer_db_addr = intel_ntb_peer_db_addr,
|
|
|
|
.peer_db_set = intel_ntb_peer_db_set,
|
|
|
|
.spad_is_unsafe = intel_ntb_spad_is_unsafe,
|
2016-11-17 00:03:38 +03:00
|
|
|
.spad_count = intel_ntb_spad_count,
|
|
|
|
.spad_read = intel_ntb_spad_read,
|
|
|
|
.spad_write = intel_ntb_spad_write,
|
|
|
|
.peer_spad_addr = intel_ntb_peer_spad_addr,
|
|
|
|
.peer_spad_read = intel_ntb_peer_spad_read,
|
|
|
|
.peer_spad_write = intel_ntb_peer_spad_write,
|
|
|
|
};
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static const struct file_operations intel_ntb_debugfs_info = {
|
|
|
|
.owner = THIS_MODULE,
|
|
|
|
.open = simple_open,
|
|
|
|
.read = ndev_debugfs_read,
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct pci_device_id intel_ntb_pci_tbl[] = {
|
|
|
|
{PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_NTB_B2B_JSF)},
|
|
|
|
{PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_NTB_B2B_SNB)},
|
|
|
|
{PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_NTB_B2B_IVT)},
|
|
|
|
{PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_NTB_B2B_HSX)},
|
2015-07-13 15:07:18 +03:00
|
|
|
{PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_NTB_B2B_BDX)},
|
2015-04-09 17:33:20 +03:00
|
|
|
{PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_NTB_PS_JSF)},
|
|
|
|
{PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_NTB_PS_SNB)},
|
|
|
|
{PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_NTB_PS_IVT)},
|
|
|
|
{PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_NTB_PS_HSX)},
|
2015-07-13 15:07:18 +03:00
|
|
|
{PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_NTB_PS_BDX)},
|
2015-04-09 17:33:20 +03:00
|
|
|
{PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_NTB_SS_JSF)},
|
|
|
|
{PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_NTB_SS_SNB)},
|
|
|
|
{PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_NTB_SS_IVT)},
|
|
|
|
{PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_NTB_SS_HSX)},
|
2015-07-13 15:07:18 +03:00
|
|
|
{PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_NTB_SS_BDX)},
|
2016-11-17 00:03:38 +03:00
|
|
|
{PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_NTB_B2B_SKX)},
|
2015-04-09 17:33:20 +03:00
|
|
|
{0}
|
|
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(pci, intel_ntb_pci_tbl);
|
|
|
|
|
|
|
|
static struct pci_driver intel_ntb_pci_driver = {
|
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 06:27:12 +04:00
|
|
|
.name = KBUILD_MODNAME,
|
2015-04-09 17:33:20 +03:00
|
|
|
.id_table = intel_ntb_pci_tbl,
|
|
|
|
.probe = intel_ntb_pci_probe,
|
|
|
|
.remove = intel_ntb_pci_remove,
|
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 06:27:12 +04:00
|
|
|
};
|
2014-04-07 21:55:47 +04:00
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
static int __init intel_ntb_pci_driver_init(void)
|
|
|
|
{
|
2015-06-15 15:21:33 +03:00
|
|
|
pr_info("%s %s\n", NTB_DESC, NTB_VER);
|
|
|
|
|
2015-04-09 17:33:20 +03:00
|
|
|
if (debugfs_initialized())
|
|
|
|
debugfs_dir = debugfs_create_dir(KBUILD_MODNAME, NULL);
|
|
|
|
|
|
|
|
return pci_register_driver(&intel_ntb_pci_driver);
|
|
|
|
}
|
|
|
|
module_init(intel_ntb_pci_driver_init);
|
|
|
|
|
|
|
|
static void __exit intel_ntb_pci_driver_exit(void)
|
|
|
|
{
|
|
|
|
pci_unregister_driver(&intel_ntb_pci_driver);
|
|
|
|
|
|
|
|
debugfs_remove_recursive(debugfs_dir);
|
|
|
|
}
|
|
|
|
module_exit(intel_ntb_pci_driver_exit);
|