All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank Li <Frank.li@oss.nxp.com>
To: Koichiro Den <den@valinux.co.jp>
Cc: "Manivannan Sadhasivam" <mani@kernel.org>,
	"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
	"Kishon Vijay Abraham I" <kishon@kernel.org>,
	"Frank Li" <Frank.Li@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Shuah Khan" <skhan@linuxfoundation.org>,
	"Randy Dunlap" <rdunlap@infradead.org>,
	"Vinod Koul" <vkoul@kernel.org>,
	"Jingoo Han" <jingoohan1@gmail.com>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Niklas Cassel" <cassel@kernel.org>,
	"Damien Le Moal" <dlemoal@kernel.org>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Marek Vasut" <marek.vasut+renesas@mailbox.org>,
	"Yoshihiro Shimoda" <yoshihiro.shimoda.uh@renesas.com>,
	linux-pci@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org
Subject: Re: [PATCH v7 06/10] PCI: dwc: Implement endpoint DMA channel delegation
Date: Tue, 25 Aug 2026 09:30:54 -0500	[thread overview]
Message-ID: <ao2nHoCwfTEEiFSr@SMW015318> (raw)
In-Reply-To: <w223tumnzi3zircm4tnv4b7cug2g23z52xris7fcrhxyr6knvr@cw6meanwd5e3>

On Tue, Aug 25, 2026 at 05:16:50PM +0900, Koichiro Den wrote:
> On Tue, Aug 25, 2026 at 11:36:54AM +0900, Koichiro Den wrote:
> > On Thu, Aug 13, 2026 at 02:09:26PM -0500, Frank Li wrote:
> > > On Thu, Aug 13, 2026 at 03:37:53PM +0900, Koichiro Den wrote:
> > > > Implement the EPC DMA channel delegation operations for DesignWare
> > > > endpoint controllers. Verify that the DMA engine channel reserved by the
> > > > endpoint function belongs to the integrated DesignWare eDMA instance,
> > > > then hand its interrupt routing to the host.
> > > >
> > > > The DWC eDMA/HDMA engine generates DMA requests with a programmable
> > > > requester function number. For delegated channels, the host-side
> > > > dw-edma-pcie instance bound to the exposed DMA function programs its own
> > > > PCI_FUNC() into the per-channel requester field; the endpoint-side chip
> > > > func_no does
> > > > not participate in that handoff.
> > > >
> > > > Reject VF requests because the RC-programmable DWC eDMA/HDMA register
> > > > window is assigned to a PF BAR only.
> > > >
> > > > Reclaim returns interrupt routing to endpoint ownership. Propagate the
> > > > EPC quiesce request so bind failure paths can reclaim unexposed channels
> > > > without quiescing the DMA engine.
> > > >
> > > > Signed-off-by: Koichiro Den <den@valinux.co.jp>
> > > > ---
> > > > Changes in v7:
> > > >   - Delegate the DMA engine channel already reserved by the endpoint
> > > >     function, matching the API and helper changes in patches 4 and 5.
> > > >
> > > >  .../pci/controller/dwc/pcie-designware-ep.c   | 42 +++++++++++++++++++
> > > >  1 file changed, 42 insertions(+)
> > > >
> > > > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > > index 0b915824963a..a74d3896e436 100644
> > > > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > > @@ -858,6 +858,18 @@ dw_pcie_ep_find_bar_rsvd_region(struct dw_pcie_ep *ep,
> > > >  	return NULL;
> > > >  }
> > > >
> > > > +static int dw_pcie_ep_check_edma_vfunc(u8 vfunc_no)
> > > > +{
> > > > +	/*
> > > > +	 * The DWC endpoint databook says it is not possible to assign the
> > > > +	 * DMA/HDMA registers to any Virtual Function.
> > > > +	 */
> > > > +	if (vfunc_no)
> > > > +		return -EOPNOTSUPP;
> > > > +
> > > > +	return 0;
> > > > +}
> > > > +
> > > >  static int
> > > >  dw_pcie_ep_get_aux_resources_count(struct pci_epc *epc, u8 func_no,
> > > >  				   u8 vfunc_no)
> > > > @@ -933,6 +945,34 @@ dw_pcie_ep_get_aux_resources(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> > > >  	return 0;
> > > >  }
> > > >
> > > > +static int dw_pcie_ep_delegate_dma_chan(struct pci_epc *epc, u8 func_no,
> > > > +					u8 vfunc_no, struct dma_chan *chan)
> > > > +{
> > > > +	struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > > > +	struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > > +	struct dw_edma_chip *edma = &pci->edma;
> > > > +	int ret;
> > > > +
> > > > +	ret = dw_pcie_ep_check_edma_vfunc(vfunc_no);
> > > > +	if (ret)
> > > > +		return ret;
> > > > +
> > > > +	if (!edma->dw)
> > > > +		return -ENODEV;
> > > > +
> > > > +	if (!chan || chan->device->dev != edma->dev)
> > > > +		return -EINVAL;
> > > > +
> > > > +	return dw_edma_delegate_chan(chan);
> > > > +}
> > > > +
> > > > +static void dw_pcie_ep_reclaim_dma_chan(struct pci_epc *epc, u8 func_no,
> > > > +					u8 vfunc_no, struct dma_chan *chan,
> > > > +					bool quiesce)
> > > > +{
> > > > +	dw_edma_reclaim_chan(chan, quiesce);
> > > > +}
> > > > +
> > >
> > > After use fixed chan_ids, needn't these functins. EPF driver already
> > > find expected dma channel and config it remote only by standard API.
> >
> > (I've been somewhat holding this thread, sorry. I'm still unsure whether the
> > separate PCI DMA EPF idea will survive, or whether making it much smaller and
> > initially limiting it to a test endpoint for dw-edma-pcie would make it
> > acceptable. AFAICT, Mani has not answered that point yet. Still, I think I
> > should reply here in case the idea survives in some form and v8 becomes much
> > simpler.)
> >
> > I agree fixed chan_id removes the private channel lookup. In v7, the EPF already
> > reserves the channels to delegate through dma_request_channel(), so Patch 4 may
> > look like a leftover. Its remaining benefit is to hide dw-edma-specific
> > interrupt-routing semantics from the generic EPF.
>
> Let me correct myself.
>
> On second thought, that "benefit" is really superficial. If we ever want a
> generic abstraction for that purpose, it should belong in dmaengine, not PCI
> EPC.
>
> Now that the EPF reserves channels through standard dma_request_channel(), it
> owns them until dma_release_channel(). Going thought PCI EPC just to change
> their interrupt routing (in the dw-edma case) is odd.

Change irq routing should be dma_slave_config(), not go though EPC, which
is DMA behavior.  Or add some argument when looking channel, like DT's
xlate.

Frank

>
> >
> > The EPF could instead do something like this in pci_epf_dma_claim_channel()
> > after extending dw-edma to accept the setting:
> >
> >   config.peripheral_config = ... DW_EDMA_CH_IRQ_REMOTE ...;
> >   dmaengine_slave_config(chan, &config);
> >
> > That would make the EPF depend on dw-edma-specific interrupt routing. However,
> > if the goal is to make the PCI DMA EPF as small as possible and accept that it
> > initially only serves the dw-edma-pcie path, I think that is fine. I think
> > that's your point, but if not, please correct me.
>
> So even in the vNTB-embedded design, your suggestion to use prepheral_config
> fits well. I've now implemented and tested it there, and it works. I'm preparing
> v2 on that basis and hope to send it soon.
>
> Best regards,
> Koichiro
>
> >
> > Thanks for reviewing.
> > Koichiro
> >
> > >
> > > Frank
> > >
> > > >  static const struct pci_epc_ops epc_ops = {
> > > >  	.write_header		= dw_pcie_ep_write_header,
> > > >  	.set_bar		= dw_pcie_ep_set_bar,
> > > > @@ -950,6 +990,8 @@ static const struct pci_epc_ops epc_ops = {
> > > >  	.get_features		= dw_pcie_ep_get_features,
> > > >  	.get_aux_resources_count	= dw_pcie_ep_get_aux_resources_count,
> > > >  	.get_aux_resources	= dw_pcie_ep_get_aux_resources,
> > > > +	.delegate_dma_chan	= dw_pcie_ep_delegate_dma_chan,
> > > > +	.reclaim_dma_chan	= dw_pcie_ep_reclaim_dma_chan,
> > > >  };
> > > >
> > > >  /**
> > > > --
> > > > 2.51.0
> > > >
> >

  reply	other threads:[~2026-08-25 14:31 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-13  6:37 [PATCH v7 00/10] PCI: endpoint: Add PCI DMA endpoint function Koichiro Den
2026-08-13  6:37 ` [PATCH v7 01/10] dmaengine: Allow drivers to assign static channel IDs Koichiro Den
2026-08-13  6:51   ` sashiko-bot
2026-08-13 18:56   ` Frank Li
2026-08-14  2:31     ` Koichiro Den
2026-08-13  6:37 ` [PATCH v7 02/10] PCI: endpoint: Define endpoint DMA BAR metadata format Koichiro Den
2026-08-13  6:40   ` sashiko-bot
2026-08-13 20:32   ` Frank Li
2026-08-13  6:37 ` [PATCH v7 03/10] PCI: endpoint: Add DMA auxiliary resource metadata Koichiro Den
2026-08-13  6:41   ` sashiko-bot
2026-08-13 20:20   ` Frank Li
2026-08-14  5:46     ` Koichiro Den
2026-08-13  6:37 ` [PATCH v7 04/10] PCI: endpoint: Add API to delegate EPC DMA channels to the host Koichiro Den
2026-08-13  6:46   ` sashiko-bot
2026-08-13  6:37 ` [PATCH v7 05/10] dmaengine: dw-edma: Add channel delegation helpers Koichiro Den
2026-08-13  6:50   ` sashiko-bot
2026-08-13 19:11   ` Frank Li
2026-08-13  6:37 ` [PATCH v7 06/10] PCI: dwc: Implement endpoint DMA channel delegation Koichiro Den
2026-08-13  6:47   ` sashiko-bot
2026-08-13 19:09   ` Frank Li
2026-08-25  2:36     ` Koichiro Den
2026-08-25  8:16       ` Koichiro Den
2026-08-25 14:30         ` Frank Li [this message]
2026-08-13  6:37 ` [PATCH v7 07/10] PCI: dwc: Expose endpoint DMA resources Koichiro Den
2026-08-13  6:45   ` sashiko-bot
2026-08-13  6:37 ` [PATCH v7 08/10] dmaengine: dw-edma-pcie: Discover endpoint DMA metadata Koichiro Den
2026-08-13  6:50   ` sashiko-bot
2026-08-13  6:37 ` [PATCH v7 09/10] PCI: endpoint: Add DMA endpoint function Koichiro Den
2026-08-13  6:53   ` sashiko-bot
2026-08-13  6:37 ` [PATCH v7 10/10] Documentation: PCI: Add PCI DMA endpoint function documentation Koichiro Den
2026-08-13  6:46   ` sashiko-bot
2026-08-13 11:46 ` [PATCH v7 00/10] PCI: endpoint: Add PCI DMA endpoint function Niklas Cassel
2026-08-13 12:50   ` Manivannan Sadhasivam
2026-08-13 14:15     ` Koichiro Den
2026-08-13 15:59       ` Frank Li
2026-08-13 17:04         ` Koichiro Den
2026-08-13 19:30           ` Frank Li
2026-08-14  5:27         ` Manivannan Sadhasivam
2026-08-14  5:57           ` Koichiro Den
2026-08-21 15:55             ` Niklas Cassel
2026-08-24  2:12               ` Koichiro Den

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ao2nHoCwfTEEiFSr@SMW015318 \
    --to=frank.li@oss.nxp.com \
    --cc=Frank.Li@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=cassel@kernel.org \
    --cc=corbet@lwn.net \
    --cc=den@valinux.co.jp \
    --cc=dlemoal@kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=jingoohan1@gmail.com \
    --cc=kishon@kernel.org \
    --cc=kwilczynski@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=mani@kernel.org \
    --cc=marek.vasut+renesas@mailbox.org \
    --cc=rdunlap@infradead.org \
    --cc=robh@kernel.org \
    --cc=skhan@linuxfoundation.org \
    --cc=vkoul@kernel.org \
    --cc=yoshihiro.shimoda.uh@renesas.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.