mbox series

[00/19] Implement NTB Controller using multiple PCI EP

Message ID 20200514145927.17555-1-kishon@ti.com
Headers show
Series Implement NTB Controller using multiple PCI EP | expand

Message

Kishon Vijay Abraham I May 14, 2020, 2:59 p.m. UTC
This series is about implementing SW defined NTB using
multiple endpoint instances. This series has been tested using
2 endpoint instances in J7 connected to two DRA7 boards. However there
is nothing platform specific for the NTB functionality.

This was presented in Linux Plumbers Conference. The presentation
can be found @ [1]

RFC patch series can be found @ [2]

This series has been validated after applying [3] and [4]

Changes from RFC:
1) Converted the DT binding patches to YAML schema and merged the
   DT binding patches together
2) NTB documentation is converted to .rst
3) One HOST can now interrupt the other HOST using MSI-X interrupts
4) Added support for teardown of memory window and doorbell
   configuration
5) Add support to provide support 64-bit memory window size from
   DT

[1] -> https://www.linuxplumbersconf.org/event/4/contributions/395/attachments/284/481/Implementing_NTB_Controller_Using_PCIe_Endpoint_-_final.pdf
[2] -> http://lore.kernel.org/r/20190926112933.8922-1-kishon@ti.com
[3] -> http://lore.kernel.org/r/20200508130646.23939-1-kishon@ti.com
[4] -> http://lore.kernel.org/r/20200506151429.12255-1-kishon@ti.com

Kishon Vijay Abraham I (19):
  dt-bindings: PCI: Endpoint: Add DT bindings for PCI EPF NTB Device
  Documentation: PCI: Add specification for the *PCI NTB* function
    device
  PCI: endpoint: Add API to get reference to EPC from device-tree
  PCI: endpoint: Add API to create EPF device from device tree
  PCI: endpoint: Add "pci-epf-bus" driver
  PCI: endpoint: Make *_get_first_free_bar() take into account 64 bit
    BAR
  PCI: endpoint: Add helper API to get the 'next' unreserved BAR
  PCI: endpoint: Make *_free_bar() to return error codes on failure
  PCI: endpoint: Remove unused pci_epf_match_device()
  PCI: endpoint: Make pci_epf_driver ops optional
  PCI: endpoint: Add helper API to populate header with values from DT
  PCI: endpoint: Add support to associate secondary EPC with EPF
  PCI: endpoint: Add pci_epc_ops to map MSI irq
  PCI: cadence: Implement ->msi_map_irq() ops
  PCI: endpoint: Add EP function driver to provide NTB functionality
  PCI: Add TI J721E device to pci ids
  NTB: Add support for EPF PCI-Express Non-Transparent Bridge
  NTB: tool: Enable the NTB/PCIe link on the local or remote side of
    bridge
  NTB: ntb_perf/ntb_tool: Use PCI device for dma_alloc_coherent()

 Documentation/PCI/endpoint/index.rst          |    1 +
 Documentation/PCI/endpoint/pci-test-ntb.rst   |  344 +++
 .../bindings/pci/endpoint/pci-epf-bus.yaml    |   42 +
 .../bindings/pci/endpoint/pci-epf-device.yaml |   69 +
 .../bindings/pci/endpoint/pci-epf-ntb.yaml    |   68 +
 drivers/misc/pci_endpoint_test.c              |    1 -
 drivers/ntb/hw/Kconfig                        |    1 +
 drivers/ntb/hw/Makefile                       |    1 +
 drivers/ntb/hw/epf/Kconfig                    |    5 +
 drivers/ntb/hw/epf/Makefile                   |    1 +
 drivers/ntb/hw/epf/ntb_hw_epf.c               |  752 ++++++
 drivers/ntb/test/ntb_perf.c                   |    3 +-
 drivers/ntb/test/ntb_tool.c                   |    4 +-
 .../pci/controller/cadence/pcie-cadence-ep.c  |   50 +
 drivers/pci/endpoint/Makefile                 |    3 +-
 drivers/pci/endpoint/functions/Kconfig        |   12 +
 drivers/pci/endpoint/functions/Makefile       |    1 +
 drivers/pci/endpoint/functions/pci-epf-ntb.c  | 2038 +++++++++++++++++
 drivers/pci/endpoint/functions/pci-epf-test.c |   13 +-
 drivers/pci/endpoint/pci-ep-cfs.c             |    6 +-
 drivers/pci/endpoint/pci-epc-core.c           |  216 +-
 drivers/pci/endpoint/pci-epf-bus.c            |   54 +
 drivers/pci/endpoint/pci-epf-core.c           |  137 +-
 include/linux/pci-epc.h                       |   43 +-
 include/linux/pci-epf.h                       |   26 +-
 include/linux/pci_ids.h                       |    1 +
 26 files changed, 3823 insertions(+), 69 deletions(-)
 create mode 100644 Documentation/PCI/endpoint/pci-test-ntb.rst
 create mode 100644 Documentation/devicetree/bindings/pci/endpoint/pci-epf-bus.yaml
 create mode 100644 Documentation/devicetree/bindings/pci/endpoint/pci-epf-device.yaml
 create mode 100644 Documentation/devicetree/bindings/pci/endpoint/pci-epf-ntb.yaml
 create mode 100644 drivers/ntb/hw/epf/Kconfig
 create mode 100644 drivers/ntb/hw/epf/Makefile
 create mode 100644 drivers/ntb/hw/epf/ntb_hw_epf.c
 create mode 100644 drivers/pci/endpoint/functions/pci-epf-ntb.c
 create mode 100644 drivers/pci/endpoint/pci-epf-bus.c

Comments

Rob Herring May 22, 2020, 4:11 p.m. UTC | #1
On Thu, May 14, 2020 at 8:59 AM Kishon Vijay Abraham I <kishon@ti.com> wrote:
>
> This series is about implementing SW defined NTB using
> multiple endpoint instances. This series has been tested using
> 2 endpoint instances in J7 connected to two DRA7 boards. However there
> is nothing platform specific for the NTB functionality.
>
> This was presented in Linux Plumbers Conference. The presentation
> can be found @ [1]

I'd like to know why putting this into DT is better than configfs.
Does it solve some problem? Doing things in userspace is so much
easier and more flexible than modifying and updating a DT.

I don't really think the PCI endpoint stuff is mature enough to be
putting into DT either.

Rob
Kishon Vijay Abraham I May 23, 2020, 1:47 a.m. UTC | #2
Hi Rob,

On 5/22/2020 9:41 PM, Rob Herring wrote:
> On Thu, May 14, 2020 at 8:59 AM Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>
>> This series is about implementing SW defined NTB using
>> multiple endpoint instances. This series has been tested using
>> 2 endpoint instances in J7 connected to two DRA7 boards. However there
>> is nothing platform specific for the NTB functionality.
>>
>> This was presented in Linux Plumbers Conference. The presentation
>> can be found @ [1]
> 
> I'd like to know why putting this into DT is better than configfs.
> Does it solve some problem? Doing things in userspace is so much
> easier and more flexible than modifying and updating a DT.

It's a lot cleaner to have an endpoint function bound to two different endpoint
controller using device tree than configfs.

+    epf_bus {
+      compatible = "pci-epf-bus";
+
+      func@0 {
+        compatible = "pci-epf-ntb";
+        epcs = <&pcie0_ep>, <&pcie1_ep>;
+        epc-names = "primary", "secondary";
+        reg = <0>;
+        epf,vendor-id = /bits/ 16 <0x104c>;
+        epf,device-id = /bits/ 16 <0xb00d>;
+        num-mws = <4>;
+        mws-size = <0x0 0x100000>, <0x0 0x100000>, <0x0 0x100000>, <0x0 0x100000>;
+      };

For device tree, just using phandles is enough and the driver can easily parse
DT to get EPCs bound to the endpoint function
+        epcs = <&pcie0_ep>, <&pcie1_ep>;
+        epc-names = "primary", "secondary";

This would be
ln -s functions/pci-epf-ntb/func1 controllers/2900000.pcie-ep/
ln -s functions/pci-epf-ntb/func1 controllers/2910000.pcie-ep/

pci_epc_epf_link() should then maintain the order of EPC bound to EPF and
designate one as PRIMARY_INTERFACE and the second as SECONDARY_INTERFACE.
pci_epf_bind() should be made to behave differently for NTB case.

While the standard properties (like vendorid, deviceid) has configfs entries,
additional logic would be required for adding function specific fields like
num-mws and mws-size above.

While all this support could be added in configfs, it looks simpler to
represent then in DT.

> 
> I don't really think the PCI endpoint stuff is mature enough to be
> putting into DT either.

I think this will anyways come when we have to export real HW peripherals to
the remote HOST using EP controller.

Thanks
Kishon