Support for configurable PCIe endpoint

On Thursday, August 18, 2016 6:44:09 PM CEST Kishon Vijay Abraham I wrote:

Hi Arnd,

On Thursday 04 August 2016 04:43 PM, Arnd Bergmann wrote:

quoted

On Thursday, August 4, 2016 3:32:01 PM CEST Kishon Vijay Abraham I wrote:

quoted

On Wednesday 03 August 2016 07:09 PM, Joao Pinto wrote:

quoted

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.

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?

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.

	Arnd