Support for configurable PCIe endpoint

From the high level this should look _similar_ to the gadget framework of USB.

Hi,

The PCIe controller present in TI's DRA7 SoC is capable of operating either in Root Complex mode or Endpoint mode. (It uses Synopsys Designware Core).I'd assume most of the PCIe controllers on other platforms that use Designware core should also be capable to operate in endpoint mode. But linux kernel right now supports only RC mode.

PCIe endpoint support discussion came up briefly before [1] but it was felt the practical use case will find firmware more suitable and endpoint support in kernel can be used only for validation or demo.

Validation or demo is itself a valid use case in my opinion (consider something similar to gadget zero for USB). There can be other use cases as well. The RC can use the SoC with EP mode support as an accelerator to accomplish specific task. Here RC gives data to the EP. The EP processes the data. The processing can be done either in ARM itself or it can use other hardware accelerators (like DSP, IVA-HD etc..) present in the EP system. If HW accelerator is used, the linux kernel running in ARM can be used to accomplish other tasks. Once EP mode support is added, I think more use cases will be added.

From the high level this should look _similar_ to the gadget framework of USB. One difference from USB would be this should allow HW components (like DSP, PRU etc.. and maybe even some peripheral) in the EP system to be used by RC system.

So these are the high-level steps that I thought would be needed to add EP support in linux.
*) move pcie-designware.c out of drivers/pci/host (maybe create a drivers/pci/designware/ folder?). All users of pcie-designware.c should be moved here.
This is in preparation for adding EP mode support to designware.

*) Add library functions in pcie-designware.c specific to EP mode like initializing general ecam registers, BAR registers etc.. These functions should be invoked from a *function* driver (function driver should determine the use of a particular EP).

*) Add a sample *function* driver that can be used just for validation. This function driver will invoke the previously added functions in PCIe controller to initialize ecam, BAR etc.. This will invoke the PCIe controller functions through *ep-core* layer. That way the same function driver can be made to work with different PCIe controllers. (A PCIe driver corresponding to this function driver should also be implemented in RC side)

*) Add *ep-core* layer to bind the function driver to the controller driver and using which the function driver will invoke controller driver callbacks (to initialize ecam, BAR registers etc..)

*) Modify platform driver to support EP mode (in my case pci-dra7xx.c).

*) dt binding specific to EP mode should be created.

Quoted 21 lines · CEST Kishon Vijay Abraham I

Hi,

The PCIe controller present in TI's DRA7 SoC is capable of operating either in Root Complex mode or Endpoint mode. (It uses Synopsys Designware Core).I'd assume most of the PCIe controllers on other platforms that use Designware core should also be capable to operate in endpoint mode. But linux kernel right now supports only RC mode.

PCIe endpoint support discussion came up briefly before [1] but it was felt the practical use case will find firmware more suitable and endpoint support in kernel can be used only for validation or demo.

Validation or demo is itself a valid use case in my opinion (consider something similar to gadget zero for USB). There can be other use cases as well. The RC can use the SoC with EP mode support as an accelerator to accomplish specific task. Here RC gives data to the EP. The EP processes the data. The processing can be done either in ARM itself or it can use other hardware accelerators (like DSP, IVA-HD etc..) present in the EP system. If HW accelerator is used, the linux kernel running in ARM can be used to accomplish other tasks. Once EP mode support is added, I think more use cases will be added.

Quoted 3 lines

From the high level this should look _similar_ to the gadget framework of USB. One difference from USB would be this should allow HW components (like DSP, PRU etc.. and maybe even some peripheral) in the EP system to be used by RC system.

(Adding Jon Mason)

We have the drivers/ntb framework, which in theory should be able to handle this, but in practice is only used for a very small number of bridge implementations, and is also limited in the way it can be configured (compared to USB gadget)

Quoted 6 lines

So these are the high-level steps that I thought would be needed to add EP support in linux.
*) move pcie-designware.c out of drivers/pci/host (maybe create a drivers/pci/designware/ folder?). All users of pcie-designware.c should be moved here.
This is in preparation for adding EP mode support to designware.

A lot of the other drivers in drivers/pci/host support endpoint mode too, I don't think moving them all elsewhere is helpful or necessary here.

Quoted 13 lines

*) Add library functions in pcie-designware.c specific to EP mode like initializing general ecam registers, BAR registers etc.. These functions should be invoked from a *function* driver (function driver should determine the use of a particular EP).

*) Add a sample *function* driver that can be used just for validation. This function driver will invoke the previously added functions in PCIe controller to initialize ecam, BAR etc.. This will invoke the PCIe controller functions through *ep-core* layer. That way the same function driver can be made to work with different PCIe controllers. (A PCIe driver corresponding to this function driver should also be implemented in RC side)

Quoted 3 lines

*) Add *ep-core* layer to bind the function driver to the controller driver and using which the function driver will invoke controller driver callbacks (to initialize ecam, BAR registers etc..)

I think we should first have a rough idea what the framework should look like, and how it handles having multiple hardware implementation and multiple protocol implementations, before we modify a particular driver.

So this step here should come a bit earlier than the others.

Quoted 4 lines

*) Modify platform driver to support EP mode (in my case pci-dra7xx.c).

*) dt binding specific to EP mode should be created.

Right.

Hi,

The PCIe controller present in TI's DRA7 SoC is capable of operating either in Root Complex mode or Endpoint mode. (It uses Synopsys Designware Core).I'd assume most of the PCIe controllers on other platforms that use Designware core should also be capable to operate in endpoint mode. But linux kernel right now supports only RC mode.

PCIe endpoint support discussion came up briefly before [1] but it was felt the practical use case will find firmware more suitable and endpoint support in kernel can be used only for validation or demo.

Validation or demo is itself a valid use case in my opinion (consider something similar to gadget zero for USB). There can be other use cases as well. The RC can use the SoC with EP mode support as an accelerator to accomplish specific task. Here RC gives data to the EP. The EP processes the data. The processing can be done either in ARM itself or it can use other hardware accelerators (like DSP, IVA-HD etc..) present in the EP system. If HW accelerator is used, the linux kernel running in ARM can be used to accomplish other tasks. Once EP mode support is added, I think more use cases will be added.

Quoted 1 line

From the high level this should look _similar_ to the gadget framework of USB.

One difference from USB would be this should allow HW components (like DSP, PRU etc.. and maybe even some peripheral) in the EP system to be used by RC system.

So these are the high-level steps that I thought would be needed to add EP support in linux.
*) move pcie-designware.c out of drivers/pci/host (maybe create a drivers/pci/designware/ folder?). All users of pcie-designware.c should be moved here.
This is in preparation for adding EP mode support to designware.

Quoted 11 lines · Kishon Vijay Abraham I

Hi,

The PCIe controller present in TI's DRA7 SoC is capable of operating either in Root Complex mode or Endpoint mode. (It uses Synopsys Designware Core).I'd assume most of the PCIe controllers on other platforms that use Designware core should also be capable to operate in endpoint mode. But linux kernel right now supports only RC mode.

PCIe endpoint support discussion came up briefly before [1] but it was felt the practical use case will find firmware more suitable and endpoint support in kernel can be used only for validation or demo.

I disagree. It's highly useful for rapid prototyping of hardware interfaces, and I've been looking into PCIe EP drivers for exactly that reason recently. Going a little offtopic: any good DRA7 eval boards you'd recommend to try for this purpose?

We already have a EP driver in the tree:

drivers/misc/spear13xx_pcie_gadget.c

but as far as I can tell it doesn't really work at the moment.

drivers/ntb seems like a reasonable start, while an alternative approach that we have discussed in the past would be based on top of virtio, so we could use the existing front-end drivers (net, block, v9fs, console, ...).

Quoted 4 lines · Arnd Bergmann

drivers/ntb seems like a reasonable start, while an alternative approach that we have discussed in the past would be based on top of virtio, so we could use the existing front-end drivers (net, block, v9fs, console, ...).

I don't really think either is a good aproach for the lowest level interface. To be useful the EP driver needs to be able to implement any (reasonable) thing a PCIe device could do. Both NTB and virtio can sit on top of that, though.

Quoted 8 lines · Kishon Vijay Abraham I

Hi,

The PCIe controller present in TI's DRA7 SoC is capable of operating either in Root Complex mode or Endpoint mode. (It uses Synopsys Designware Core).I'd assume most of the PCIe controllers on other platforms that use Designware core should also be capable to operate in endpoint mode. But linux kernel right now supports only RC mode.

Quoted 3 lines

PCIe endpoint support discussion came up briefly before [1] but it was felt the practical use case will find firmware more suitable and endpoint support in kernel can be used only for validation or demo.

I disagree. It's highly useful for rapid prototyping of hardware interfaces, and I've been looking into PCIe EP drivers for exactly that reason recently. Going a little offtopic: any good DRA7 eval boards you'd recommend to try for this purpose?

We already have a EP driver in the tree:

drivers/misc/spear13xx_pcie_gadget.c

but as far as I can tell it doesn't really work at the moment.

Quoted 9 lines

Validation or demo is itself a valid use case in my opinion (consider something similar to gadget zero for USB). There can be other use cases as well. The RC can use the SoC with EP mode support as an accelerator to accomplish specific task. Here RC gives data to the EP. The EP processes the data. The processing can be done either in ARM itself or it can use other hardware accelerators (like DSP, IVA-HD etc..) present in the EP system. If HW accelerator is used, the linux kernel running in ARM can be used to accomplish other tasks. Once EP mode support is added, I think more use cases will be added.

That sounds useful as well.

Quoted 3 lines

Quoted 1 line

From the high level this should look _similar_ to the gadget framework of USB.

One difference from USB would be this should allow HW components (like DSP, PRU etc.. and maybe even some peripheral) in the EP system to be used by RC system.

Indeed.

Quoted 6 lines

So these are the high-level steps that I thought would be needed to add EP support in linux.
*) move pcie-designware.c out of drivers/pci/host (maybe create a drivers/pci/designware/ folder?). All users of pcie-designware.c should be moved here.
This is in preparation for adding EP mode support to designware.

I'd use a new drivers/pci/controller. Or maybe just skip the rename for now and see how this evolves.

The rest of the plan sounds fine to me.

Hi,

The PCIe controller present in TI's DRA7 SoC is capable of operating either in Root Complex mode or Endpoint mode. (It uses Synopsys Designware Core). I'd assume most of the PCIe controllers on other platforms that use Designware core should also be capable to operate in endpoint mode. But linux kernel right now supports only RC mode.

PCIe endpoint support discussion came up briefly before [1] but it was felt the practical use case will find firmware more suitable and endpoint support in kernel can be used only for validation or demo.

*) Modify platform driver to support EP mode (in my case pci-dra7xx.c).

*) dt binding specific to EP mode should be created.

Once I complete the implementation and start posting RFC patches, a lot of these will become clear. But I want to check if this sounds okay to you guys before starting the implementation.

Let me know if you have some other ideas too.

Cheers
Kishon

[1] -> http://www.spinics.net/lists/linux-pci/msg26026.html

Hi Kishon,

Quoted 20 lines · Kishon Vijay Abraham I

Hi,

The PCIe controller present in TI's DRA7 SoC is capable of operating either in Root Complex mode or Endpoint mode. (It uses Synopsys Designware Core). I'd assume most of the PCIe controllers on other platforms that use Designware core should also be capable to operate in endpoint mode. But linux kernel right now supports only RC mode.

PCIe endpoint support discussion came up briefly before [1] but it was felt the practical use case will find firmware more suitable and endpoint support in kernel can be used only for validation or demo.

*) Modify platform driver to support EP mode (in my case pci-dra7xx.c).

*) dt binding specific to EP mode should be created.

Once I complete the implementation and start posting RFC patches, a lot of these will become clear. But I want to check if this sounds okay to you guys before starting the implementation.

Quoted 7 lines

Let me know if you have some other ideas too.

Cheers
Kishon

[1] -> http://www.spinics.net/lists/linux-pci/msg26026.html

You are rising a topic that we are also addressing in Synopsys.

For the PCIe RC hardware validation we are currently using the standard pcie-designware and pcie-designware-plat drivers.

For the Endpoint we have to use an internal software package. Its main purpose is to initialize the IP registers, eDMA channels and make data transfer to prove that the everything is working properly. This is done in 2 levels, a custom driver built and loaded and an application that makes some ioctl to the driver executing some interesting functions to check the Endpoint status and make some data exchange.

Quoted 6 lines · Joao Pinto

You are rising a topic that we are also addressing in Synopsys.

For the PCIe RC hardware validation we are currently using the standard pcie-designware and pcie-designware-plat drivers.

Quoted 6 lines

For the Endpoint we have to use an internal software package. Its main purpose is to initialize the IP registers, eDMA channels and make data transfer to prove that the everything is working properly. This is done in 2 levels, a custom driver built and loaded and an application that makes some ioctl to the driver executing some interesting functions to check the Endpoint status and make some data exchange.

hmm.. the platform I have doesn't have a DMA in PCIe IP
(http://www.ti.com/lit/ug/spruhz6g/spruhz6g.pdf). So in your testing does the EP access RC memory? i.e the driver in the RC allocates memory from it's DDR and gives it's DDR address to the EP. The EP then transfers data to this address. (This is a typical use case with ethernet PCIe cards). IIUC that's not simple with configurable EPs. I'd like to know more about your testing though.

Quoted 14 lines · CEST Kishon Vijay Abraham I

Quoted 6 lines · Joao Pinto

You are rising a topic that we are also addressing in Synopsys.

For the PCIe RC hardware validation we are currently using the standard pcie-designware and pcie-designware-plat drivers.

Quoted 6 lines

For the Endpoint we have to use an internal software package. Its main purpose is to initialize the IP registers, eDMA channels and make data transfer to prove that the everything is working properly. This is done in 2 levels, a custom driver built and loaded and an application that makes some ioctl to the driver executing some interesting functions to check the Endpoint status and make some data exchange.

Quoted 6 lines

hmm.. the platform I have doesn't have a DMA in PCIe IP
(http://www.ti.com/lit/ug/spruhz6g/spruhz6g.pdf). So in your testing does the EP access RC memory? i.e the driver in the RC allocates memory from it's DDR and gives it's DDR address to the EP. The EP then transfers data to this address. (This is a typical use case with ethernet PCIe cards). IIUC that's not simple with configurable EPs. I'd like to know more about your testing though.

What's the difference between using the EDMA on that chip or a DMA engine that is part of the PCIe bridge?

Hi Arnd,

Quoted 23 lines · Arnd Bergmann

Quoted 20 lines · CEST Kishon Vijay Abraham I

Quoted 6 lines · Joao Pinto

You are rising a topic that we are also addressing in Synopsys.

For the PCIe RC hardware validation we are currently using the standard pcie-designware and pcie-designware-plat drivers.

Quoted 6 lines

For the Endpoint we have to use an internal software package. Its main purpose is to initialize the IP registers, eDMA channels and make data transfer to prove that the everything is working properly. This is done in 2 levels, a custom driver built and loaded and an application that makes some ioctl to the driver executing some interesting functions to check the Endpoint status and make some data exchange.

hmm.. the platform I have doesn't have a DMA in PCIe IP
(http://www.ti.com/lit/ug/spruhz6g/spruhz6g.pdf). So in your testing does the EP access RC memory? i.e the driver in the RC allocates memory from it's DDR and gives it's DDR address to the EP. The EP then transfers data to this address. (This is a typical use case with ethernet PCIe cards). IIUC that's not simple with configurable EPs. I'd like to know more about your testing though.

Quoted 2 lines

What's the difference between using the EDMA on that chip or a DMA engine that is part of the PCIe bridge?

Do you mean the difference between using DMA on an EP (like ethernet card or sata card) and DMA on PCI RC system? or is it the difference between eDMA within the PCIe IP and system DMA?

Quoted 29 lines · CEST Kishon Vijay Abraham I

Hi Arnd,

Quoted 25 lines · Arnd Bergmann

Quoted 14 lines · CEST Kishon Vijay Abraham I

Quoted 6 lines · Joao Pinto

You are rising a topic that we are also addressing in Synopsys.

For the PCIe RC hardware validation we are currently using the standard pcie-designware and pcie-designware-plat drivers.

Quoted 6 lines

For the Endpoint we have to use an internal software package. Its main purpose is to initialize the IP registers, eDMA channels and make data transfer to prove that the everything is working properly. This is done in 2 levels, a custom driver built and loaded and an application that makes some ioctl to the driver executing some interesting functions to check the Endpoint status and make some data exchange.

Quoted 6 lines

hmm.. the platform I have doesn't have a DMA in PCIe IP
(http://www.ti.com/lit/ug/spruhz6g/spruhz6g.pdf). So in your testing does the EP access RC memory? i.e the driver in the RC allocates memory from it's DDR and gives it's DDR address to the EP. The EP then transfers data to this address. (This is a typical use case with ethernet PCIe cards). IIUC that's not simple with configurable EPs. I'd like to know more about your testing though.

What's the difference between using the EDMA on that chip or a DMA engine that is part of the PCIe bridge?

Quoted 3 lines

Do you mean the difference between using DMA on an EP (like ethernet card or sata card) and DMA on PCI RC system? or is it the difference between eDMA within the PCIe IP and system DMA?

The latter. You write that there is no DMA in the PCIe IP, but from the perspective of the RC, it should not matter whether the DMA engine is part of the EP logic or behind it.

-----Original Message-----
From: Kishon Vijay Abraham I [mailto:kishon at ti.com]
Sent: Thursday, August 04, 2016 6:02 PM
To: Joao Pinto <[email protected]>; bhelgaas at google.com; linux- pci at vger.kernel.org; arnd at arndb.de; Jingoo Han <[email protected]>; Pratyush Anand <[email protected]>
Cc: Ley Foon Tan <[email protected]>; Rob Herring <[email protected]>; Tanmay Inamdar <[email protected]>; Roy Zang <tie-
fei.zang at freescale.com>; Mingkai Hu <[email protected]>; Minghuan Lian <[email protected]>; Richard Zhu <[email protected]>; Lucas Stach <[email protected]>; Murali Karicheri <[email protected]>; Thomas Petazzoni <[email protected]>; Jason Cooper <[email protected]>; Thierry Reding <[email protected]>; Simon Horman <[email protected]>; Zhou Wang <[email protected]>; Gabriele Paoloni <[email protected]>; Stanimir Varbanov <svarbanov@mm- sol.com>; David Daney <[email protected]>; linux-
kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux- omap at vger.kernel.org; Carlos Palminha <[email protected]>
Subject: Re: Support for configurable PCIe endpoint

Hi,

Quoted 36 lines · Joao Pinto

Hi Kishon,

Quoted 20 lines · Kishon Vijay Abraham I

Hi,

The PCIe controller present in TI's DRA7 SoC is capable of operating either in Root Complex mode or Endpoint mode. (It uses Synopsys Designware Core). I'd assume most of the PCIe controllers on other platforms that use Designware core should also be capable to operate in endpoint mode. But linux kernel right now supports only RC mode.

PCIe endpoint support discussion came up briefly before [1] but it was felt the practical use case will find firmware more suitable and endpoint support in kernel can be used only for validation or demo.

*) Modify platform driver to support EP mode (in my case pci-dra7xx.c).

*) dt binding specific to EP mode should be created.

Once I complete the implementation and start posting RFC patches, a lot of these will become clear. But I want to check if this sounds okay to you guys before starting the implementation.

Quoted 7 lines

Let me know if you have some other ideas too.

Cheers
Kishon

[1] -> http://www.spinics.net/lists/linux-pci/msg26026.html

You are rising a topic that we are also addressing in Synopsys.

For the PCIe RC hardware validation we are currently using the standard pcie-designware and pcie-designware-plat drivers.

Quoted 6 lines

For the Endpoint we have to use an internal software package. Its main purpose is to initialize the IP registers, eDMA channels and make data transfer to prove that the everything is working properly. This is done in 2 levels, a custom driver built and loaded and an application that makes some ioctl to the driver executing some interesting functions to check the Endpoint status and make some data exchange.

hmm.. the platform I have doesn't have a DMA in PCIe IP
(http://www.ti.com/lit/ug/spruhz6g/spruhz6g.pdf). So in your testing does the EP access RC memory? i.e the driver in the RC allocates memory from it's DDR and gives it's DDR address to the EP. The EP then transfers data to this address. (This is a typical use case with ethernet PCIe cards). IIUC that's not simple with configurable EPs. I'd like to know more about your testing though.

Quoted 71 lines

-----Original Message-----
From: Kishon Vijay Abraham I [mailto:kishon at ti.com]
Sent: Thursday, August 04, 2016 6:02 PM
To: Joao Pinto <[email protected]>; bhelgaas at google.com; linux- pci at vger.kernel.org; arnd at arndb.de; Jingoo Han <[email protected]>; Pratyush Anand <[email protected]>
Cc: Ley Foon Tan <[email protected]>; Rob Herring <[email protected]>; Tanmay Inamdar <[email protected]>; Roy Zang <tie-
fei.zang at freescale.com>; Mingkai Hu <[email protected]>; Minghuan Lian <[email protected]>; Richard Zhu <[email protected]>; Lucas Stach <[email protected]>; Murali Karicheri <[email protected]>; Thomas Petazzoni <[email protected]>; Jason Cooper <[email protected]>; Thierry Reding <[email protected]>; Simon Horman <[email protected]>; Zhou Wang <[email protected]>; Gabriele Paoloni <[email protected]>; Stanimir Varbanov <svarbanov@mm- sol.com>; David Daney <[email protected]>; linux-
kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux- omap at vger.kernel.org; Carlos Palminha <[email protected]>
Subject: Re: Support for configurable PCIe endpoint

Hi,

Quoted 36 lines · Joao Pinto

Hi Kishon,

Quoted 20 lines · Kishon Vijay Abraham I

Hi,

The PCIe controller present in TI's DRA7 SoC is capable of operating either in Root Complex mode or Endpoint mode. (It uses Synopsys Designware Core). I'd assume most of the PCIe controllers on other platforms that use Designware core should also be capable to operate in endpoint mode. But linux kernel right now supports only RC mode.

PCIe endpoint support discussion came up briefly before [1] but it was felt the practical use case will find firmware more suitable and endpoint support in kernel can be used only for validation or demo.

*) Modify platform driver to support EP mode (in my case pci-dra7xx.c).

*) dt binding specific to EP mode should be created.

Once I complete the implementation and start posting RFC patches, a lot of these will become clear. But I want to check if this sounds okay to you guys before starting the implementation.

Quoted 7 lines

Let me know if you have some other ideas too.

Cheers
Kishon

[1] -> http://www.spinics.net/lists/linux-pci/msg26026.html

You are rising a topic that we are also addressing in Synopsys.

For the PCIe RC hardware validation we are currently using the standard pcie-designware and pcie-designware-plat drivers.

Quoted 6 lines

For the Endpoint we have to use an internal software package. Its main purpose is to initialize the IP registers, eDMA channels and make data transfer to prove that the everything is working properly. This is done in 2 levels, a custom driver built and loaded and an application that makes some ioctl to the driver executing some interesting functions to check the Endpoint status and make some data exchange.

Quoted 7 lines

hmm.. the platform I have doesn't have a DMA in PCIe IP
(http://www.ti.com/lit/ug/spruhz6g/spruhz6g.pdf). So in your testing does the EP access RC memory? i.e the driver in the RC allocates memory from it's DDR and gives it's DDR address to the EP. The EP then transfers data to this address. (This is a typical use case with ethernet PCIe cards). IIUC that's not simple with configurable EPs. I'd like to know more about your testing though.

Hi Kishon,

This is a typical user case for EP to use DMA transfer data to/from RC memory. In our case, we implement ring (like BD ring) or register in EP to communicate The address allocated in RC memory, then EP can transfer data to/from RC memory.

Hi,

Quoted 75 lines · Mingkai Hu

Quoted 68 lines

-----Original Message-----
From: Kishon Vijay Abraham I [mailto:kishon at ti.com]
Sent: Thursday, August 04, 2016 6:02 PM
To: Joao Pinto <[email protected]>; bhelgaas at google.com; linux- pci at vger.kernel.org; arnd at arndb.de; Jingoo Han <[email protected]>; Pratyush Anand <[email protected]>
Cc: Ley Foon Tan <[email protected]>; Rob Herring <[email protected]>; Tanmay Inamdar <[email protected]>; Roy Zang <tie-
fei.zang at freescale.com>; Mingkai Hu <[email protected]>; Minghuan Lian <[email protected]>; Richard Zhu <[email protected]>; Lucas Stach <[email protected]>; Murali Karicheri <[email protected]>; Thomas Petazzoni <[email protected]>; Jason Cooper <[email protected]>; Thierry Reding <[email protected]>; Simon Horman <[email protected]>; Zhou Wang <[email protected]>; Gabriele Paoloni <[email protected]>; Stanimir Varbanov <svarbanov@mm- sol.com>; David Daney <[email protected]>; linux-
kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux- omap at vger.kernel.org; Carlos Palminha <[email protected]>
Subject: Re: Support for configurable PCIe endpoint

Hi,

Quoted 35 lines · Joao Pinto

Hi Kishon,

Quoted 20 lines · Kishon Vijay Abraham I

Hi,

The PCIe controller present in TI's DRA7 SoC is capable of operating either in Root Complex mode or Endpoint mode. (It uses Synopsys Designware Core). I'd assume most of the PCIe controllers on other platforms that use Designware core should also be capable to operate in endpoint mode. But linux kernel right now supports only RC mode.

PCIe endpoint support discussion came up briefly before [1] but it was felt the practical use case will find firmware more suitable and endpoint support in kernel can be used only for validation or demo.

*) Modify platform driver to support EP mode (in my case pci-dra7xx.c).

*) dt binding specific to EP mode should be created.

Once I complete the implementation and start posting RFC patches, a lot of these will become clear. But I want to check if this sounds okay to you guys before starting the implementation.

Quoted 7 lines

Let me know if you have some other ideas too.

Cheers
Kishon

[1] -> http://www.spinics.net/lists/linux-pci/msg26026.html

You are rising a topic that we are also addressing in Synopsys.

For the PCIe RC hardware validation we are currently using the standard pcie-designware and pcie-designware-plat drivers.

Quoted 6 lines

For the Endpoint we have to use an internal software package. Its main purpose is to initialize the IP registers, eDMA channels and make data transfer to prove that the everything is working properly. This is done in 2 levels, a custom driver built and loaded and an application that makes some ioctl to the driver executing some interesting functions to check the Endpoint status and make some data exchange.

Quoted 7 lines

hmm.. the platform I have doesn't have a DMA in PCIe IP
(http://www.ti.com/lit/ug/spruhz6g/spruhz6g.pdf). So in your testing does the EP access RC memory? i.e the driver in the RC allocates memory from it's DDR and gives it's DDR address to the EP. The EP then transfers data to this address. (This is a typical use case with ethernet PCIe cards). IIUC that's not simple with configurable EPs. I'd like to know more about your testing though.

Quoted 5 lines

Hi Kishon,

This is a typical user case for EP to use DMA transfer data to/from RC memory. In our case, we implement ring (like BD ring) or register in EP to communicate The address allocated in RC memory, then EP can transfer data to/from RC memory.

Initially I had some confusion w.r.t this because the address allocated in RC memory can also be an address in EP system. For example let's assume we connect two similar systems one configured as RC and the other configured as EP. The PCI driver in the RC allocates memory in it's DDR (say 0x80000000) and programs this address in the EP. Since it's a similar system, 0x80000000 will also be an address in the EPs DDR. This will result in EP transferring data to it's own DDR (at 0x80000000) instead of the same address in RC.

But later realized instead of directly using the DDR address given by RC, this address should only be used to program the outbound window. That way the target of the outbound window can be an address given by the RC and source should be an address from the address space in the EP's system.

Do you also use the RC memory address to program the outbound window?