Re: [PATCH v2 0/3] PCI: endpoint: Add PCI DMA endpoint function (part 3/3)

[Koichiro Den]

On Mon, May 25, 2026 at 03:34:53PM +0900, Koichiro Den wrote:
> Hi,
> 
> This is v2, part 3 of three series for PCI endpoint DMA.
> 
> The three series are:
> 
>   * part 1: dmaengine: dw-edma: Prepare for PCI EP DMA
>   * part 2: PCI: endpoint: Expose endpoint DMA resources
>   * part 3: PCI: endpoint: Add PCI DMA endpoint function
> 
> This series adds the host-side metadata parser, the pci-epf-dma endpoint
> function driver, and documentation.
> 
> The endpoint function exposes selected endpoint-integrated DMA channels as
> a separate PCI DMA controller function. The host-side dw-edma-pcie driver
> discovers the BAR metadata, requests the final layout, and registers the
> exposed channels with DMAengine. Host clients then submit transfers through
> the regular DMAengine API. The endpoint function keeps the metadata BAR
> stable and uses a separate DMA window BAR for resources that need dynamic
> subrange mappings.
> 
> No fixed PCI ID is assigned by this series. Users provide the PCI
> vendor/device ID through configfs and bind dw-edma-pcie explicitly, for
> example with driver_override.
> 
> 
> Dependencies
> ============
> 
> This series depends on parts 1 and 2, applied on top of pci/endpoint:
> 
>   [PATCH v2 00/12] dmaengine: dw-edma: Prepare for PCI EP DMA (part 1/3)
>   https://lore.kernel.org/dmaengine/20260525062420.3315904-1-den@xxxxxxxxxxxxx/
> 
>   [PATCH v2 0/3] PCI: endpoint: Expose endpoint DMA resources (part 2/3)
>   https://lore.kernel.org/linux-pci/20260525063129.3316894-1-den@xxxxxxxxxxxxx/
> 
> 
> Note
> ====
> 
> This series touches both dmaengine and PCI endpoint code. I kept the
> dw-edma-pcie metadata parser together with the endpoint function so the
> metadata producer and consumer can be reviewed in one place.
> 
> If the general direction looks acceptable, the dw-edma-pcie patch may need
> a dmaengine Ack if this series is routed through the PCI endpoint tree.
> 
> 
> Tested on
> =========
> 
> The RC-to-EP data path was tested with a small out-of-tree DMAengine
> client. The host submits a DMA_MEM_TO_DEV transfer through dw-edma-pcie,
> which uses a DesignWare eDMA read channel to copy host memory into
> endpoint memory.
> 
> Tested with:
> 
>   * R-Car S4 as endpoint and R-Car S4 as root complex
>   * RK3588 as endpoint and CD8180 as root complex
> 
> 
> ---
> Changelog
> =========
> 
> Changes in v2:
>   - Follow the part 1/3 and part 2/3 v2 channel-claim model: pci-epf-dma
>     now claims delegated channels through DMAengine filter information from
>     EPC auxiliary resources.
>   - Select raw-address dw-edma-pcie platform ops from the endpoint DMA
>     match entry instead of using a match flag.
> 
> v1: https://lore.kernel.org/linux-pci/20260521063638.2843021-1-den@xxxxxxxxxxxxx/
> 
> 
> Best regards,
> Koichiro

Hi Mani,

I would like to ask you for your high-level opinion on the direction of this
series.

Previously, I have tried two different approaches for the same objective:
avoiding the extra CPU memcpy (or local DMA memcpy) in NTB transport on both EP
and RC sides.

1. Put dw-edma-specific handling under drivers/ntb/hw and let the (new) NTB
   driver carry the metadata needed for channel delegation.

   [RFC PATCH v4 00/38] NTB transport backed by PCI EP embedded DMA
   https://lore.kernel.org/all/20260118135440.1958279-1-den@xxxxxxxxxxxxx/

2. Treat endpoint DMA as a first-class part of vNTB. The RC-side ntb_hw_epf
   would create an auxiliary device, and a new dw-edma-aux driver would create
   the delegated DMA channels on the RC side.

   [PATCH 00/15] PCI: endpoint: Remote DMA support via vNTB
   https://lore.kernel.org/linux-pci/20260312165005.1148676-1-den@xxxxxxxxxxxxx/

   I added an ASCII diagram for the overview as a follow-up comment here:
   https://lore.kernel.org/all/sn67hi7kljh7cgmgodatb3naz2astlaklqfobdbxyyzgoohxqb@4nnetbhqwba4/)

Now, this v2 series takes a third direction. It moves the DMA controller out of
vNTB/NTB-specific ABI and exposes it as a separate PCI endpoint DMA function.
The host then discovers it as a DMA controller function. The initial host-side
driver is the existing dw-edma-pcie driver, and dw-edma-aux is no longer needed.

My current thinking is that this is the cleanest among the previous attempts.
But this is mostly an architecture question, so I would like to know whether
this direction looks acceptable to you.

In short, do you agree with the direction of this series, that endpoint DMA
channel delegation should be modeled as a separate PCI endpoint DMA function?

If you think the vNTB-integrated direction is preferable, or if this should be
modeled differently in the endpoint framework, I would rather adjust the
direction as early as possible, before building the NTB transport on top of it.

Best regards,
Koichiro

> 
> 
> Koichiro Den (3):
>   dmaengine: dw-edma-pcie: Discover endpoint DMA metadata
>   PCI: endpoint: Add DMA endpoint function
>   Documentation: PCI: Add PCI DMA endpoint function documentation
> 
>  Documentation/PCI/endpoint/index.rst          |    2 +
>  .../PCI/endpoint/pci-dma-function.rst         |  182 +++
>  Documentation/PCI/endpoint/pci-dma-howto.rst  |  200 +++
>  drivers/dma/dw-edma/dw-edma-pcie.c            |  374 ++++-
>  drivers/pci/endpoint/functions/Kconfig        |   14 +
>  drivers/pci/endpoint/functions/Makefile       |    1 +
>  drivers/pci/endpoint/functions/pci-epf-dma.c  | 1366 +++++++++++++++++
>  7 files changed, 2138 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/PCI/endpoint/pci-dma-function.rst
>  create mode 100644 Documentation/PCI/endpoint/pci-dma-howto.rst
>  create mode 100644 drivers/pci/endpoint/functions/pci-epf-dma.c
> 
> -- 
> 2.51.0
>