linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kishon Vijay Abraham I <kishon@ti.com>
To: Bjorn Helgaas <bhelgaas@google.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Rob Herring <robh+dt@kernel.org>, Jon Mason <jdmason@kudzu.us>,
	Dave Jiang <dave.jiang@intel.com>,
	Allen Hubbe <allenbh@gmail.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>, <kishon@ti.com>,
	<linux-pci@vger.kernel.org>, <linux-doc@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>,
	<linux-ntb@googlegroups.com>
Subject: [RFC PATCH 04/21] Documentation: PCI: Add specification for the *PCI NTB* function device
Date: Thu, 26 Sep 2019 16:59:16 +0530	[thread overview]
Message-ID: <20190926112933.8922-5-kishon@ti.com> (raw)
In-Reply-To: <20190926112933.8922-1-kishon@ti.com>

Add specification for the *PCI NTB* function device. The endpoint function
driver and the host PCI driver should be created based on this
specification.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
 Documentation/PCI/endpoint/pci-test-ntb.txt | 315 ++++++++++++++++++++
 1 file changed, 315 insertions(+)
 create mode 100644 Documentation/PCI/endpoint/pci-test-ntb.txt

diff --git a/Documentation/PCI/endpoint/pci-test-ntb.txt b/Documentation/PCI/endpoint/pci-test-ntb.txt
new file mode 100644
index 000000000000..c8bfe9dbfd8b
--- /dev/null
+++ b/Documentation/PCI/endpoint/pci-test-ntb.txt
@@ -0,0 +1,315 @@
+			       PCI NTB FUNCTION
+		    Kishon Vijay Abraham I <kishon@ti.com>
+
+PCI NTB Function allows two different systems (or hosts) to communicate
+with each other by configurig the endpoint instances in such a way that
+transactions from one system is routed to the other system.
+
+In the below diagram, PCI NTB function configures the SoC with multiple
+PCIe Endpoint (EP) instances in such a way that transaction from one EP
+controller is routed to the other EP controller. Once PCI NTB function
+configures the SoC with multiple EP instances, HOST1 and HOST2 can
+communicate with each other using SoC as a bridge.
+
+   +-------------+                                   +-------------+
+   |             |                                   |             |
+   |    HOST1    |                                   |    HOST2    |
+   |             |                                   |             |
+   +------^------+                                   +------^------+
+          |                                                 |
+          |                                                 |
++---------|-------------------------------------------------|---------+
+|  +------v------+                                   +------v------+  |
+|  |             |                                   |             |  |
+|  |     EP      |                                   |     EP      |  |
+|  | CONTROLLER1 |                                   | CONTROLLER2 |  |
+|  |             <----------------------------------->             |  |
+|  |             |                                   |             |  |
+|  |             |                                   |             |  |
+|  |             |  SoC With Multiple EP Instances   |             |  |
+|  |             |  (Configured using NTB Function)  |             |  |
+|  +-------------+                                   +-------------+  |
++---------------------------------------------------------------------+
+
+Constructs used for Implementing NTB:
+
+	*) Config Region
+	*) Self Scratchpad Registers
+	*) Peer Scratchpad Registers
+	*) Doorbell Registers
+	*) Memory Window
+
+Modeling Constructs:
+
+  There are 5 or more distinct regions (config, self scratchpad, peer
+scratchpad, doorbell, one or more memory windows) to be modeled to achieve
+NTB functionality. Atleast one memory window is required while more than
+one is permitted. All these regions should be mapped to BAR for hosts to
+access these regions.
+
+If one 32-bit BAR is allocated for each of these regions, the scheme would
+look like
+	BAR0 -> Config Region
+	BAR1 -> Self Scratchpad
+	BAR2 -> Peer Scratchpad
+	BAR3 -> Doorbell
+	BAR4 -> Memory Window 1
+	BAR5 -> Memory Window 2
+
+However if we allocate a separate BAR for each of the region, there would not
+be enough BARs for all the regions in a platform that supports only 64-bit
+BAR.
+
+In order to be be supported by most of the platforms, the regions should be
+packed and mapped to BARs in a way that provides NTB functionality and
+also making sure the hosts doesn't access any region that it is not supposed
+to.
+
+The following scheme is used in EPF NTB Function
+
+	BAR0 -> Config Region + Self Scratchpad
+	BAR1 -> Peer Scratchpad
+	BAR2 -> Doorbell + Memory Window 1
+	BAR3 -> Memory Window 2
+	BAR4 -> Memory Window 3
+	BAR4 -> Memory Window 4
+
+With this scheme, for the basic NTB functionality 3 BARs should be sufficient.
+
+Modeling Config/Scratchpad Region:
+
++-----------------+------->+------------------+        +-----------------+
+|       BAR0      |        |  CONFIG REGION   |        |       BAR0      |
++-----------------+----+   +------------------+<-------+-----------------+
+|       BAR1      |    |   |SCRATCHPAD REGION |        |       BAR1      |
++-----------------+    +-->+------------------+<-------+-----------------+
+|       BAR2      |            Local Memory            |       BAR2      |
++-----------------+                                    +-----------------+
+|       BAR3      |                                    |       BAR3      |
++-----------------+                                    +-----------------+
+|       BAR4      |                                    |       BAR4      |
++-----------------+                                    +-----------------+
+|       BAR5      |                                    |       BAR5      |
++-----------------+                                    +-----------------+
+  EP CONTROLLER 1                                        EP CONTROLLER 2
+
+Above diagram shows Config region + Scratchpad region for HOST1 (connected to
+EP controller 1) allocated in local memory. The HOST1 can access the config
+region and scratchpad region (self scratchpad) using BAR0 of EP controller 1.
+The peer host (HOST2 connected to EP controller 2) can also access this
+scratchpad region (peer scratchpad) using BAR1 of EP controller 2. This
+diagram shows the case where Config region and Scratchpad region is allocated
+for HOST1, however the same is applicable for HOST2.
+
+Modeling Doorbell/Memory Window 1:
+
++-----------------+    +----->+----------------+-----------+-----------------+
+|       BAR0      |    |      |   Doorbell 1   +-----------> MSI|X ADDRESS 1 |
++-----------------+    |      +----------------+           +-----------------+
+|       BAR1      |    |      |   Doorbell 2   +---------+ |                 |
++-----------------+    |      +----------------+         | |                 |
+|       BAR2      |    |      |   Doorbell 3   +-------+ | +-----------------+
++-----------------+    |      +----------------+       | +-> MSI|X ADDRESS 2 |
+|       BAR3      |    |      |   Doorbell 4   +-----+ |   +-----------------+
++----------------------+      +----------------+     | |   |                 |
+|       BAR4      |           |                |     | |   +-----------------+
++----------------------+      |      MW1       +---+ | +-->+ MSI|X ADDRESS 3||
+|       BAR5      |    |      |                |   | |     +-----------------+
++-----------------+    +----->-----------------+   | |     |                 |
+  EP CONTROLLER 1             |                |   | |     +-----------------+
+                              |                |   | +---->+ MSI|X ADDRESS 4 |
+                              +----------------+   |       +-----------------+
+                               EP CONTROLLER 2     |       |                 |
+                                 (OB SPACE)        |       |                 |
+                                                   +------->      MW1        |
+                                                           |                 |
+                                                           |                 |
+                                                           +-----------------+
+                                                           |                 |
+                                                           |                 |
+                                                           |                 |
+                                                           |                 |
+                                                           |                 |
+                                                           +-----------------+
+							    PCI Address Space
+							    (Managed by HOST2)
+
+Above diagram shows how the doorbell and memory window 1 is mapped so that
+HOST1 can raise doorbell interrupt on HOST2 and also how HOST1 can access
+buffers exposed by HOST2 using memory window1 (MW1). Here doorbell and
+memory window 1 regions are allocated in EP controller 2 outbound (OB) address
+space. Allocating and configuring BARs for doorbell and memory window1
+is done during the initialization phase of NTB endpoint function driver.
+Mapping from EP controller 2 OB space to PCI address space is done when HOST2
+sends CMD_CONFIGURE_MW/CMD_CONFIGURE_DOORBELL. The commands are explained
+below.
+
+Modeling Optional Memory Windows:
+
+This is modeled the same was as MW1 but each of the additional memory windows
+is mapped to separate BARs.
+
+Config Region:
+
+Config Region is a construct that is specific to NTB implemented using NTB
+Endpoint Function Driver. The host and endpoint side NTB function driver will
+exchange informatio with each other using this region. Config Region has
+Control/Status Registers for configuring the Endpoint Controller. Host can
+write into this region for configuring the outbound ATU and to indicate the
+link status. Endpoint can indicate the status of commands issued be host in
+this region. Endpoint can also indicate the scratchpad offset, number of
+memory windows to the host using this region.
+
+The format of Config Region is given below. Each of the fields here are 32
+bits.
+
+	+------------------------+
+	|         COMMAND        |
+	+------------------------+
+	|         ARGUMENT       |
+	+------------------------+
+	|         STATUS         |
+	+------------------------+
+	|         TOPOLOGY       |
+	+------------------------+
+	|    ADDRESS (LOWER 32)  |
+	+------------------------+
+	|    ADDRESS (UPPER 32)  |
+	+------------------------+
+	|           SIZE         |
+	+------------------------+
+	|  MEMORY WINDOW1 OFFSET |
+	+------------------------+
+	|   NO OF MEMORY WINDOW  |
+	+------------------------+
+	|       SPAD OFFSET      |
+	+------------------------+
+	|        SPAD COUNT      |
+	+------------------------+
+	|      DB ENTRY SIZE     |
+	+------------------------+
+	|         DB DATA        |
+	+------------------------+
+	|            :           |
+	+------------------------+
+	|            :           |
+	+------------------------+
+	|         DB DATA        |
+	+------------------------+
+
+
+  COMMAND:
+
+	NTB function supports three commands:
+
+	  CMD_CONFIGURE_DOORBELL (0x1): Command to configure doorbell. Before
+	invoking this command, the host should allocate and initialize
+	MSI/MSI-X vectors (i.e initialize the MSI/MSI-X capability in the
+	Endpoint). The endpoint on receiving this command will configure
+	the outbound ATU such that transaction to DB BAR will be routed
+	to the MSI/MSI-X address programmed by the host. The ARGUMENT
+	register should be populated with number of DBs to configure (in the
+	lower 16 bits) and if MSI or MSI-X should be configured (BIT 16).
+	(TODO: Add support for MSI-X).
+
+	  CMD_CONFIGURE_MW (0x2): Command to configure memory window. The
+	host invokes this command after allocating a buffer that can be
+	accessed by remote host. The allocated address should be programmed
+	in the ADDRESS register (64 bit), the size should be programmed in
+	the SIZE register and the memory window index should be programmed
+	in the ARGUMENT register. The endpoint on receiving this command
+	will configure the outbound ATU such that trasaction to MW BAR
+	will be routed to the address provided by the host.
+
+	  CMD_LINK_UP (0x3): Command to indicate an NTB application is
+	bound to the EP device on the host side. Once the endpoint
+	receives this command from both the hosts, the endpoint will
+	raise an LINK_UP event to both the hosts to indicate the hosts
+	can start communicating with each other.
+
+  ARGUMENT:
+
+	The value of this register is based on the commands issued in
+	command register. See COMMAND section for more information.
+
+  configuring memory window and to indicate the host side NTB application
+  has initialized.
+
+  TOPOLOGY:
+
+	Set to NTB_TOPO_B2B_USD for Primary interface
+	Set to NTB_TOPO_B2B_DSD for Secondary interface
+
+  ADDRESS/SIZE:
+
+	Address and Size to be used while configuring the memory window.
+	See "CMD_CONFIGURE_MW" for more info.
+
+  MEMORY WINDOW1 OFFSET:
+
+	Memory Window 1 and Doorbell registers are packed together in the
+	same BAR. The initial portion of the region will have doorbell
+	registers and the latter portion of the region is for memory window 1.
+	This register will specify the offset of the memory window 1.
+
+  NO OF MEMORY WINDOW:
+
+	Specifies the number of memory windows supported by the NTB device.
+
+  SPAD OFFSET:
+
+	Self scratchpad region and config region are packed together in the
+	same BAR. The initial portion of the will have config region and
+	the latter portion of the region is for self scratchpad. This
+	register will specify the offset of the self scratchpad registers.
+
+  SPAD COUNT:
+
+	Specifies the number of scratchpad registers supported by the NTB
+	device.
+
+  DB ENTRY SIZE:
+
+	Used to determine the offset within the DB BAR that should be written
+	in order to raise doorbell. EPF NTB can use either MSI/MSI-X to
+	ring doorbell (MSI-X support will be added later). MSI uses same
+	address for all the interrupts and MSI-X can provide different
+	addresses for different interrupts. The MSI/MSI-X address is provided
+	by the host and the address it gives is based on the MSI/MSI-X
+	implementation supported by the host. For instance, ARM platform
+	using GIC ITS will have same MSI-X address for all the interrupts.
+	In order to support all the combinations and use the same mechanism
+	for both MSI and MSI-X, EPF NTB allocates separate region in the
+	Outbound Address Space for each of the interrupts. This region will
+	be mapped to the MSI/MSI-X address provided by the host. If a host
+	provides the same address for all the interrupts, all the regions
+	will be translated to the same address. If a host provides different
+	address, the regions will be translated to different address. This
+	will ensure there is no difference while raising the doorbell.
+
+  DB DATA:
+
+	EPF NTB supports 32 interrupts. So there are 32 DB DATA registers.
+	This holds the MSI/MSI-X data that has to be written to MSI address
+	for raising doorbell interrupt. This will be populated by EPF NTB
+	while invoking CMD_CONFIGURE_MW.
+
+Scratchpad Registers:
+
+  Each host has it's own register space allocated in the memory of NTB EPC.
+  They are both readable and writable from both sides of the bridge. They
+  are used by applications built over NTB and can be used to pass control
+  and status information between both sides of a device.
+
+  Scratchpad registers has 2 parts
+	1) Self Scratchpad: Host's own register space
+	2) Peer Scratchpad: Remote host's register space.
+
+Doorbell Registers:
+
+  Registers using which one host can interrupt the other host.
+
+Memory Window:
+
+  Actual transfer of data between the two hosts will happen using the
+  memory window.
-- 
2.17.1


  parent reply	other threads:[~2019-09-26 11:32 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-26 11:29 [RFC PATCH 00/21] Implement NTB Controller using multiple PCI Kishon Vijay Abraham I
2019-09-26 11:29 ` [RFC PATCH 01/21] dt-bindings: PCI: Endpoint: Add DT bindings for PCI EPF Bus Kishon Vijay Abraham I
2019-09-26 11:29 ` [RFC PATCH 02/21] dt-bindings: PCI: Endpoint: Add DT bindings for PCI EPF Device Kishon Vijay Abraham I
2019-10-15 18:42   ` Rob Herring
2019-10-16  4:45     ` Kishon Vijay Abraham I
2019-09-26 11:29 ` [RFC PATCH 03/21] dt-bindings: PCI: Endpoint: Add DT bindings for PCI EPF NTB Device Kishon Vijay Abraham I
2019-09-26 11:29 ` Kishon Vijay Abraham I [this message]
2019-11-17 23:26   ` [RFC PATCH 04/21] Documentation: PCI: Add specification for the *PCI NTB* function device Jon Mason
2019-09-26 11:29 ` [RFC PATCH 05/21] PCI: endpoint: Add API to get reference to EPC from device-tree Kishon Vijay Abraham I
2019-11-17 23:28   ` Jon Mason
2019-09-26 11:29 ` [RFC PATCH 06/21] PCI: endpoint: Add API to create EPF device from device tree Kishon Vijay Abraham I
2019-09-26 11:29 ` [RFC PATCH 07/21] PCI: endpoint: Add "pci-epf-bus" driver Kishon Vijay Abraham I
2019-09-26 11:29 ` [RFC PATCH 08/21] PCI: endpoint: Make *_get_first_free_bar() take into account 64 bit BAR Kishon Vijay Abraham I
2019-09-26 11:29 ` [RFC PATCH 09/21] PCI: endpoint: Add helper API to get the 'next' unreserved BAR Kishon Vijay Abraham I
2019-09-26 11:29 ` [RFC PATCH 10/21] PCI: endpoint: Make pci_epf_driver ops optional Kishon Vijay Abraham I
2019-09-26 11:29 ` [RFC PATCH 11/21] PCI: endpoint: Add helper API to populate header with values from DT Kishon Vijay Abraham I
2019-09-26 11:29 ` [RFC PATCH 12/21] PCI: endpoint: Add support to associate secondary EPC with EPF Kishon Vijay Abraham I
2019-09-26 11:29 ` [RFC PATCH 13/21] PCI: endpoint: Add pci_epc_ops to map MSI irq Kishon Vijay Abraham I
2019-09-26 11:29 ` [RFC PATCH 14/21] PCI: cadence: Implement ->msi_map_irq() ops Kishon Vijay Abraham I
2019-09-26 11:29 ` [RFC PATCH 15/21] PCI: endpoint: Remove unused pci_epf_match_device() Kishon Vijay Abraham I
2019-09-26 11:29 ` [RFC PATCH 16/21] PCI: endpoint: Fix missing mutex_unlock in error case Kishon Vijay Abraham I
2019-09-26 11:29 ` [RFC PATCH 17/21] PCI: endpoint: *_free_bar() to return error codes on failure Kishon Vijay Abraham I
2019-09-26 11:29 ` [RFC PATCH 18/21] PCI: endpoint: Add EP function driver to provide NTB functionality Kishon Vijay Abraham I
2019-09-26 11:29 ` [RFC PATCH 19/21] PCI: Add TI J721E device to pci ids Kishon Vijay Abraham I
2019-09-26 11:29 ` [RFC PATCH 20/21] NTB: Add support for EPF PCI-Express Non-Transparent Bridge Kishon Vijay Abraham I
2019-11-17 23:40   ` Jon Mason
2019-09-26 11:29 ` [RFC PATCH 21/21] NTB: tool: Enable the NTB/PCIe link on the local or remote side of bridge Kishon Vijay Abraham I
2019-11-17 23:43 ` [RFC PATCH 00/21] Implement NTB Controller using multiple PCI Jon Mason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190926112933.8922-5-kishon@ti.com \
    --to=kishon@ti.com \
    --cc=allenbh@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=corbet@lwn.net \
    --cc=dave.jiang@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jdmason@kudzu.us \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-ntb@googlegroups.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).