Re: [PATCH v7 03/10] PCI: endpoint: Add DMA auxiliary resource metadata

On Thu, Aug 13, 2026 at 03:20:13PM -0500, Frank Li wrote:
> On Thu, Aug 13, 2026 at 03:37:50PM +0900, Koichiro Den wrote:
> > Extend EPC auxiliary resource metadata so endpoint functions can
> > discover controller-owned DMA registers, logical DMA channels, and
> > descriptor memory.
> >
> > The DMA metadata is intentionally generic at the EPC layer. A backend
> > reports the register layout, channel counts, logical channel resources,
> > and descriptor memory resources. Logical channels carry hardware channel
> > numbers, identify their corresponding local DMA engine device and static
> > channel ID, and refer to descriptor memory by ID. Descriptor memory is
> > identified separately so one memory resource can be shared by multiple
> > channels.
> >
> > For DesignWare controllers, reg_layout_data carries the eDMA/HDMA map
> > format so a consumer can distinguish legacy, unroll, HDMA compatible,
> > and HDMA native register layouts without making the EPC API itself
> > DesignWare-specific.
> >
> > Signed-off-by: Koichiro Den <[email protected]>
> > ---
> > Changes in v7:
> >   - Identify each local DMA engine channel by device and static channel ID,
> >     per discussion with Frank on v6 patch 4.
> >
> > @Frank, I haven't picked up your R-b tag because this patch has changed.
> > Please take another look, thanks.
> >
> >  include/linux/pci-epc.h | 48 +++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 48 insertions(+)
> >
> > diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
> > index f247cf9bcf1a..3b60cf6628e2 100644
> > --- a/include/linux/pci-epc.h
> > +++ b/include/linux/pci-epc.h
> > @@ -65,6 +65,9 @@ struct pci_epc_map {
> >   * enum pci_epc_aux_resource_type - auxiliary resource type identifiers
> >   * @PCI_EPC_AUX_DOORBELL_MMIO: Doorbell MMIO, that might be outside the DMA
> >   *                             controller register window
> > + * @PCI_EPC_AUX_DMA_CTRL_MMIO: DMA controller MMIO register window
> > + * @PCI_EPC_AUX_DMA_CHAN: Logical DMA channel
> > + * @PCI_EPC_AUX_DMA_DESC_MEM: DMA descriptor memory
> >   *
> >   * EPC backends may expose auxiliary blocks (e.g. DMA engines) by mapping their
> >   * register windows and descriptor memories into BAR space. This enum
> > @@ -72,6 +75,29 @@ struct pci_epc_map {
> >   */
> >  enum pci_epc_aux_resource_type {
> >  	PCI_EPC_AUX_DOORBELL_MMIO,
> > +	PCI_EPC_AUX_DMA_CTRL_MMIO,
> > +	PCI_EPC_AUX_DMA_CHAN,
> > +	PCI_EPC_AUX_DMA_DESC_MEM,
> > +};
> > +
> > +/**
> > + * enum pci_epc_aux_dma_reg_layout - DMA controller register layout
> > + * @PCI_EPC_AUX_DMA_REG_LAYOUT_UNKNOWN: unknown or uninitialized layout
> > + * @PCI_EPC_AUX_DMA_REG_LAYOUT_DW_EDMA: Synopsys DesignWare eDMA/HDMA layout
> > + */
> > +enum pci_epc_aux_dma_reg_layout {
> > +	PCI_EPC_AUX_DMA_REG_LAYOUT_UNKNOWN = 0,
> > +	PCI_EPC_AUX_DMA_REG_LAYOUT_DW_EDMA,
> > +};
> > +
> > +/**
> > + * enum pci_epc_aux_dma_dir - DMA channel direction relative to the endpoint
> > + * @PCI_EPC_AUX_DMA_EP_TO_RC: channel moves data from endpoint to root complex
> > + * @PCI_EPC_AUX_DMA_RC_TO_EP: channel moves data from root complex to endpoint
> > + */
> > +enum pci_epc_aux_dma_dir {
> > +	PCI_EPC_AUX_DMA_EP_TO_RC,
> > +	PCI_EPC_AUX_DMA_RC_TO_EP,
> >  };
> >
> >  /**
> > @@ -99,6 +125,28 @@ struct pci_epc_aux_resource {
> >  			int irq; /* IRQ number for the doorbell handler */
> >  			u32 data; /* write value to ring the doorbell */
> >  		} db_mmio;
> > +
> > +		/* PCI_EPC_AUX_DMA_CTRL_MMIO */
> > +		struct {
> > +			enum pci_epc_aux_dma_reg_layout reg_layout;
> > +			u32 reg_layout_data;
> > +			u16 ep_to_rc_ch_cnt;
> > +			u16 rc_to_ep_ch_cnt;
> > +		} dma_ctrl;
> > +
> > +		/* PCI_EPC_AUX_DMA_CHAN */
> > +		struct {
> > +			struct device *dma_dev;
> 
> Needn't this information, this struture should only include hareware
> informatin.

Right. dma_dev here would distinguish multiple dma_devices under the same EPC
parent, but in hindsight it seems that we don't need to cover that case right
now. We can extend it when it really is needed. I'll drop it.

> 
> > +			int chan_id; /* Local dmaengine ID, unique within dma_dev */
> > +			enum pci_epc_aux_dma_dir dir;
> > +			u16 hw_ch; /* Direction-local hardware channel exposed to the host */
> 
> should epf driver decide which channel export to host.

Yes. If pci-epf-dma remains generic, though, we still need an explicit mapping
from each local chan_id to its direction, hardware channel and descriptor
memory. (v7 pci-epf-dma has already dense prefixes restriction, but it alone do
not provide that mapping.)

If this EPF is only for testing dw-edma-pcie, we can instead rely on dw-edma's
direction-flattened static ids. DWC uses the same ids for descriptor memory, so
the channel counts are enough and PCI_EPC_AUX_DMA_CHAN itself can go away
entirely.

Is that what you had in mind?

Thanks for the review.
Koichiro

> 
> Frank
> > +			u16 desc_mem_id;
> > +		} dma_chan;
> > +
> > +		/* PCI_EPC_AUX_DMA_DESC_MEM */
> > +		struct {
> > +			u16 id;
> > +		} dma_desc;
> >  	} u;
> >  };
> >
> > --
> > 2.51.0
> >