Hi,

This series lets an RC use endpoint-local DesignWare eDMA read channels
through vNTB. It keeps the export within pci-epf-vntb and ntb_hw_epf
rather than defining a generic remote-DMA ABI or using a separate PCI
DMA function.

On the endpoint, pci-epf-vntb reserves the complete eDMA read direction
and exposes those channels as a group. HDMA is not yet supported,
keeping the series minimal.

The DMA feature is opt-in through the pci-epf-vntb configfs attribute
'dma_bar', which is -1 by default. Without it, no DMA extension is
exported. pci-epf-ntb is unchanged.

Base and dependency
===================

This series is based on next-20260827 (3d83758432b5) plus:

  [PATCH v2 0/3] dmaengine: dw-edma: Prepare channels for remote use
  https://lore.kernel.org/r/20260828163611.2691264-1-den@valinux.co.jp/

The prerequisite is for the dmaengine tree and is not part of
pci/endpoint. linux-next provides a common buildable base for both
series. Once the prerequisite lands, this series can be rebased onto
pci/endpoint.

Best regards,
Koichiro
---
Changes in v3:
  - Rework DMA BAR setup around pci_epf_assign_bar_space() and submaps.
    Allocate backing only for uncovered BAR ranges. This handles the BAR
    backing alignment issue in pci-epf-vntb instead of adding a generic
    pci_epf_alloc_space() workaround. (Sashiko)
    https://lore.kernel.org/r/nvgnu3enktslxuiv7kdapcotoaxlfqhivar4jbf2tqvrk4otz5@exapzemrq37q/
  - Set up a shared DMA/MW BAR only once, preserve MW translations, and
    simplify error paths. (Sashiko)
  - Make dma_bar the explicit opt-in and drop use_dma and automatic BAR
    selection. Split BAR sharing into its own patch, then document the
    final interface at the end of the series instead of updating the
    documentation twice.
  - Validate peer-provided DW eDMA region offsets before MMIO mapping.
    (Sashiko)
  - Include several other minor cleanups and refactorings.

Changes in v2:
  - Rewrite most of v1 and move the dw-edma preparation into the
    companion series. Drop the generic pci-ep-dma API, auxiliary-bus
    child/frontend, test ntb client, and preparatory MW-state
    refactoring.
    See individual patch trailers for provenance.
  - Replace v1's post-registration channel-ID cache with driver-supplied
    static IDs. (Frank)
    https://lore.kernel.org/r/abMcgQOHDD55Yv0e@lizhi-Precision-Tower-5810/
  - Let pci-epf-vntb reserve channels with dma_request_channel() and
    configure interrupt routing with dmaengine_slave_config(). This
    removes the PCI EPC DMA delegation API. (Frank)
    https://lore.kernel.org/r/ao2nHoCwfTEEiFSr@SMW015318/
  - Drop v1's dma_offset and dma_num_chans attributes. use_dma now enables
    export of the complete eDMA read direction as a group.

v2: https://lore.kernel.org/r/20260828170932.2735807-1-den@valinux.co.jp/
v1: https://lore.kernel.org/r/20260312165005.1148676-1-den@valinux.co.jp/

Related PCI DMA EPF v7:
  https://lore.kernel.org/r/20260813063757.3131865-1-den@valinux.co.jp/


Koichiro Den (7):
  PCI: endpoint: Add DMA auxiliary resource metadata
  PCI: dwc: Expose endpoint DMA resources
  PCI: endpoint: pci-epf-vntb: Move epf_ntb_is_bar_used() up
  PCI: endpoint: pci-epf-vntb: Export endpoint DMA channels
  PCI: endpoint: pci-epf-vntb: Allow DMA and MW to share a BAR
  NTB: ntb_hw_epf: Discover vNTB-embedded DMA
  Documentation: PCI: endpoint: Document vNTB DMA export

 Documentation/PCI/endpoint/pci-vntb-howto.rst |  24 +-
 drivers/ntb/hw/epf/ntb_hw_epf.c               | 362 ++++++++-
 .../pci/controller/dwc/pcie-designware-ep.c   | 107 ++-
 drivers/pci/endpoint/functions/pci-epf-vntb.c | 716 ++++++++++++++++--
 include/linux/pci-epc.h                       |  34 +-
 5 files changed, 1166 insertions(+), 77 deletions(-)

-- 
2.51.0

On Tue, Sep 01, 2026 at 03:26:50AM +0900, Koichiro Den wrote:
> Hi,
> 
> This series lets an RC use endpoint-local DesignWare eDMA read channels
> through vNTB. It keeps the export within pci-epf-vntb and ntb_hw_epf
> rather than defining a generic remote-DMA ABI or using a separate PCI
> DMA function.
> 
> On the endpoint, pci-epf-vntb reserves the complete eDMA read direction
> and exposes those channels as a group. HDMA is not yet supported,
> keeping the series minimal.
> 
> The DMA feature is opt-in through the pci-epf-vntb configfs attribute
> 'dma_bar', which is -1 by default. Without it, no DMA extension is
> exported. pci-epf-ntb is unchanged.
> 
> Base and dependency
> ===================
> 
> This series is based on next-20260827 (3d83758432b5) plus:
> 
>   [PATCH v2 0/3] dmaengine: dw-edma: Prepare channels for remote use
>   https://lore.kernel.org/r/20260828163611.2691264-1-den@valinux.co.jp/
> 
> The prerequisite is for the dmaengine tree and is not part of
> pci/endpoint. linux-next provides a common buildable base for both
> series. Once the prerequisite lands, this series can be rebased onto
> pci/endpoint.
> 

Just to make it clear. This series has to build time dependency with the above
mentioned dmaengine series, right? The above statement is not very clear.

EPF patches LGTM! I'm waiting for an Ack from NTB maintainer for patch 6.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

On Thu, Sep 03, 2026 at 01:43:45PM +0200, Manivannan Sadhasivam wrote:
> On Tue, Sep 01, 2026 at 03:26:50AM +0900, Koichiro Den wrote:
> > Hi,
> > 
> > This series lets an RC use endpoint-local DesignWare eDMA read channels
> > through vNTB. It keeps the export within pci-epf-vntb and ntb_hw_epf
> > rather than defining a generic remote-DMA ABI or using a separate PCI
> > DMA function.
> > 
> > On the endpoint, pci-epf-vntb reserves the complete eDMA read direction
> > and exposes those channels as a group. HDMA is not yet supported,
> > keeping the series minimal.
> > 
> > The DMA feature is opt-in through the pci-epf-vntb configfs attribute
> > 'dma_bar', which is -1 by default. Without it, no DMA extension is
> > exported. pci-epf-ntb is unchanged.
> > 
> > Base and dependency
> > ===================
> > 
> > This series is based on next-20260827 (3d83758432b5) plus:
> > 
> >   [PATCH v2 0/3] dmaengine: dw-edma: Prepare channels for remote use
> >   https://lore.kernel.org/r/20260828163611.2691264-1-den@valinux.co.jp/
> > 
> > The prerequisite is for the dmaengine tree and is not part of
> > pci/endpoint. linux-next provides a common buildable base for both
> > series. Once the prerequisite lands, this series can be rebased onto
> > pci/endpoint.
> > 
> 
> Just to make it clear. This series has to build time dependency with the above
> mentioned dmaengine series, right? The above statement is not very clear.

Yes, this series strictly depends on the prereq series, and as you pointed out,
it's a built-time dependency as well. Sorry for the ambiguity.

> 
> EPF patches LGTM! I'm waiting for an Ack from NTB maintainer for patch 6.

Thanks for taking a look. Note that I have already sent v4:
https://lore.kernel.org/r/20260903082327.2345602-1-den@valinux.co.jp/
(One more dependency is added as noted in v4 cover letter..)

Best regards,
Koichiro

> 
> - Mani
> 
> -- 
> மணிவண்ணன் சதாசிவம்