public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Frank Li <Frank.li@nxp.com>
To: Koichiro Den <den@valinux.co.jp>
Cc: dave.jiang@intel.com, cassel@kernel.org, mani@kernel.org,
	kwilczynski@kernel.org, kishon@kernel.org, bhelgaas@google.com,
	geert+renesas@glider.be, robh@kernel.org, vkoul@kernel.org,
	jdmason@kudzu.us, allenbh@gmail.com, jingoohan1@gmail.com,
	lpieralisi@kernel.org, linux-pci@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org,
	dmaengine@vger.kernel.org, iommu@lists.linux.dev,
	ntb@lists.linux.dev, netdev@vger.kernel.org,
	linux-kselftest@vger.kernel.org, arnd@arndb.de,
	gregkh@linuxfoundation.org, joro@8bytes.org, will@kernel.org,
	robin.murphy@arm.com, magnus.damm@gmail.com, krzk+dt@kernel.org,
	conor+dt@kernel.org, corbet@lwn.net, skhan@linuxfoundation.org,
	andriy.shevchenko@linux.intel.com, jbrunet@baylibre.com,
	utkarsh02t@gmail.com
Subject: Re: [RFC PATCH v4 05/38] dmaengine: dw-edma: Add a helper to query linked-list region
Date: Wed, 21 Jan 2026 20:54:34 -0500	[thread overview]
Message-ID: <aXGDWiAxesCy1/yA@lizhi-Precision-Tower-5810> (raw)
In-Reply-To: <42qzkekk6yqbtcynxny3f7pl3xg6tqkywxvjsgfmrdpnr7zy53@i7ebpgazbi4z>

On Thu, Jan 22, 2026 at 10:19:24AM +0900, Koichiro Den wrote:
> On Wed, Jan 21, 2026 at 10:24:01AM -0500, Frank Li wrote:
> > On Wed, Jan 21, 2026 at 05:41:11PM +0900, Koichiro Den wrote:
> > > On Wed, Jan 21, 2026 at 10:38:53AM +0900, Koichiro Den wrote:
> > > > On Sun, Jan 18, 2026 at 12:05:47PM -0500, Frank Li wrote:
> > > > > On Sun, Jan 18, 2026 at 10:54:07PM +0900, Koichiro Den wrote:
> > > > > > A remote eDMA provider may need to expose the linked-list (LL) memory
> > > > > > region that was configured by platform glue (typically at boot), so the
> > > > > > peer (host) can map it and operate the remote view of the controller.
> > > > > >
> > > > > > Export dw_edma_chan_get_ll_region() to return the LL region associated
> > > > > > with a given dma_chan.
> > > > >
> > > > > This informaiton passed from dwc epc driver. Is it possible to get it from
> > > > > EPC driver.
> > > >
> > > > That makes sense, from an API cleanness perspective, thanks.
> > > > I'll add a helper function dw_pcie_edma_get_ll_region() in
> > > > drivers/pci/controller/dwc/pcie-designware.c, instead of the current
> > > > dw_edma_chan_get_ll_region() in dw-edma-core.c.
> > >
> > > Hi Frank,
> > >
> > > I looked into exposing LL regions from the EPC driver side, but the key
> > > issue is channel identification under possibly concurrent dmaengine users.
> > > In practice, the only stable handle a consumer has is a pointer to struct
> > > dma_chan, and the only reliable way to map that to the eDMA hardware
> > > channel is via dw_edma_chan->id.
> >
> > If possible, I suggest change to one page pre-channel. So there are a fixed
> > ll mapping.
>
> I agree that this would make the LL layout more deterministic and would
> indeed simplify locating the region for a given dw_edma_chan ID. That said,
> my concern was that even with a fixed per-channel layout, we still need a
> reliable way to map a struct dma_chan obtained by a consumer to the
> corresponding dw_edma_chan ID, especially in the presence of potentially
> concurrent dmaengine users.
>
> >
> > > I think an EPC-facing API would still need
> > > that mapping in any case, so keeping the helper in dw-edma seems simpler
> > > and more robust.
> > > If you have another idea, I'd appreciate your insights.
> >
> > I suggest add generally DMA engine API to get such property, some likes
> > a kind ioctrl \ dma_get_config().
>
> I think such a helper, combined with your one page per-channel idea, would
> resolve the issue cleanly. For example, a helper like dma_get_hw_info()
> returning struct dma_hw_info, whose first field is a hw_id, could work
> well. Consumers could then use this helper, and if they know they are
> dealing with a dw-edma channel, they can derive the LL location
> straightforwardly as {hw_id * fixed_stride (e.g. PAGE_SIZE)}. Adding hw_id
> to struct dma_slave_caps would make the necessary diff smaller, but I think
> it would not semantically fit in the structure.

It is worth to try.

Frank
>
> Thanks,
> Koichiro
>
> >
> > Frank
> >
> > >
> > > Regards,
> > > Koichiro
> > >
> > > >
> > > > Thanks for the review,
> > > > Koichiro
> > > >
> > > > >
> > > > > Frank
> > > > > >
> > > > > > Signed-off-by: Koichiro Den <den@valinux.co.jp>
> > > > > > ---
> > > > > >  drivers/dma/dw-edma/dw-edma-core.c | 26 ++++++++++++++++++++++++++
> > > > > >  include/linux/dma/edma.h           | 14 ++++++++++++++
> > > > > >  2 files changed, 40 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c
> > > > > > index 0eb8fc1dcc34..c4fb66a9b5f5 100644
> > > > > > --- a/drivers/dma/dw-edma/dw-edma-core.c
> > > > > > +++ b/drivers/dma/dw-edma/dw-edma-core.c
> > > > > > @@ -1209,6 +1209,32 @@ int dw_edma_chan_register_notify(struct dma_chan *dchan,
> > > > > >  }
> > > > > >  EXPORT_SYMBOL_GPL(dw_edma_chan_register_notify);
> > > > > >
> > > > > > +int dw_edma_chan_get_ll_region(struct dma_chan *dchan,
> > > > > > +			       struct dw_edma_region *region)
> > > > > > +{
> > > > > > +	struct dw_edma_chip *chip;
> > > > > > +	struct dw_edma_chan *chan;
> > > > > > +
> > > > > > +	if (!dchan || !region || !dchan->device)
> > > > > > +		return -ENODEV;
> > > > > > +
> > > > > > +	chan = dchan2dw_edma_chan(dchan);
> > > > > > +	if (!chan)
> > > > > > +		return -ENODEV;
> > > > > > +
> > > > > > +	chip = chan->dw->chip;
> > > > > > +	if (!(chip->flags & DW_EDMA_CHIP_LOCAL))
> > > > > > +		return -EINVAL;
> > > > > > +
> > > > > > +	if (chan->dir == EDMA_DIR_WRITE)
> > > > > > +		*region = chip->ll_region_wr[chan->id];
> > > > > > +	else
> > > > > > +		*region = chip->ll_region_rd[chan->id];
> > > > > > +
> > > > > > +	return 0;
> > > > > > +}
> > > > > > +EXPORT_SYMBOL_GPL(dw_edma_chan_get_ll_region);
> > > > > > +
> > > > > >  MODULE_LICENSE("GPL v2");
> > > > > >  MODULE_DESCRIPTION("Synopsys DesignWare eDMA controller core driver");
> > > > > >  MODULE_AUTHOR("Gustavo Pimentel <gustavo.pimentel@synopsys.com>");
> > > > > > diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h
> > > > > > index 3c538246de07..c9ec426e27ec 100644
> > > > > > --- a/include/linux/dma/edma.h
> > > > > > +++ b/include/linux/dma/edma.h
> > > > > > @@ -153,6 +153,14 @@ bool dw_edma_chan_ignore_irq(struct dma_chan *chan);
> > > > > >  int dw_edma_chan_register_notify(struct dma_chan *chan,
> > > > > >  				 void (*cb)(struct dma_chan *chan, void *user),
> > > > > >  				 void *user);
> > > > > > +
> > > > > > +/**
> > > > > > + * dw_edma_chan_get_ll_region - get linked list (LL) memory for a dma_chan
> > > > > > + * @chan: the target DMA channel
> > > > > > + * @region: output parameter returning the corresponding LL region
> > > > > > + */
> > > > > > +int dw_edma_chan_get_ll_region(struct dma_chan *chan,
> > > > > > +			       struct dw_edma_region *region);
> > > > > >  #else
> > > > > >  static inline int dw_edma_probe(struct dw_edma_chip *chip)
> > > > > >  {
> > > > > > @@ -182,6 +190,12 @@ static inline int dw_edma_chan_register_notify(struct dma_chan *chan,
> > > > > >  {
> > > > > >  	return -ENODEV;
> > > > > >  }
> > > > > > +
> > > > > > +static inline int dw_edma_chan_get_ll_region(struct dma_chan *chan,
> > > > > > +					     struct dw_edma_region *region)
> > > > > > +{
> > > > > > +	return -EINVAL;
> > > > > > +}
> > > > > >  #endif /* CONFIG_DW_EDMA */
> > > > > >
> > > > > >  struct pci_epc;
> > > > > > --
> > > > > > 2.51.0
> > > > > >

  reply	other threads:[~2026-01-22  1:54 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-18 13:54 [RFC PATCH v4 00/38] NTB transport backed by PCI EP embedded DMA Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 01/38] dmaengine: dw-edma: Export helper to get integrated register window Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 02/38] dmaengine: dw-edma: Add per-channel interrupt routing control Koichiro Den
2026-01-18 17:03   ` Frank Li
2026-01-19 14:26     ` Koichiro Den
2026-01-21 16:02       ` Vinod Koul
2026-01-22  2:44         ` Koichiro Den
2026-01-23 15:44         ` Frank Li
2026-01-18 13:54 ` [RFC PATCH v4 03/38] dmaengine: dw-edma: Poll completion when local IRQ handling is disabled Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 04/38] dmaengine: dw-edma: Add notify-only channels support Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 05/38] dmaengine: dw-edma: Add a helper to query linked-list region Koichiro Den
2026-01-18 17:05   ` Frank Li
2026-01-21  1:38     ` Koichiro Den
2026-01-21  8:41       ` Koichiro Den
2026-01-21 15:24         ` Frank Li
2026-01-22  1:19           ` Koichiro Den
2026-01-22  1:54             ` Frank Li [this message]
2026-01-18 13:54 ` [RFC PATCH v4 06/38] NTB: epf: Add mwN_offset support and config region versioning Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 07/38] NTB: epf: Reserve a subset of MSI vectors for non-NTB users Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 08/38] NTB: epf: Provide db_vector_count/db_vector_mask callbacks Koichiro Den
2026-01-19 20:03   ` Frank Li
2026-01-21  1:41     ` Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 09/38] NTB: core: Add mw_set_trans_ranges() for subrange programming Koichiro Den
2026-01-19 20:07   ` Frank Li
2026-01-18 13:54 ` [RFC PATCH v4 10/38] NTB: core: Add .get_private_data() to ntb_dev_ops Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 11/38] NTB: core: Add .get_dma_dev() " Koichiro Den
2026-01-19 20:09   ` Frank Li
2026-01-21  1:44     ` Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 12/38] NTB: core: Add driver_override support for NTB devices Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 13/38] PCI: endpoint: pci-epf-vntb: Support BAR subrange mappings for MWs Koichiro Den
2026-01-19 20:26   ` Frank Li
2026-01-21  2:08     ` Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 14/38] PCI: endpoint: pci-epf-vntb: Implement .get_private_data() callback Koichiro Den
2026-01-19 20:27   ` Frank Li
2026-01-18 13:54 ` [RFC PATCH v4 15/38] PCI: endpoint: pci-epf-vntb: Implement .get_dma_dev() Koichiro Den
2026-01-19 20:30   ` Frank Li
2026-01-22 14:58     ` Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 16/38] NTB: ntb_transport: Move TX memory window setup into setup_qp_mw() Koichiro Den
2026-01-19 20:36   ` Frank Li
2026-01-21  2:15     ` Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 17/38] NTB: ntb_transport: Dynamically determine qp count Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 18/38] NTB: ntb_transport: Use ntb_get_dma_dev() Koichiro Den
2026-01-19 20:38   ` Frank Li
2026-01-18 13:54 ` [RFC PATCH v4 19/38] NTB: ntb_transport: Rename ntb_transport.c to ntb_transport_core.c Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 20/38] NTB: ntb_transport: Move internal types to ntb_transport_internal.h Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 21/38] NTB: ntb_transport: Export common helpers for modularization Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 22/38] NTB: ntb_transport: Split core library and default NTB client Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 23/38] NTB: ntb_transport: Add transport backend infrastructure Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 24/38] NTB: ntb_transport: Run ntb_set_mw() before link-up negotiation Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 25/38] NTB: hw: Add remote eDMA backend registry and DesignWare backend Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 26/38] NTB: ntb_transport: Add remote embedded-DMA transport client Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 27/38] ntb_netdev: Multi-queue support Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 28/38] iommu: ipmmu-vmsa: Add PCIe ch0 to devices_allowlist Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 29/38] iommu: ipmmu-vmsa: Add support for reserved regions Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 30/38] arm64: dts: renesas: Add Spider RC/EP DTs for NTB with remote DW PCIe eDMA Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 31/38] NTB: epf: Add per-SoC quirk to cap MRRS for DWC eDMA (128B for R-Car) Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 32/38] NTB: epf: Add an additional memory window (MW2) barno mapping on Renesas R-Car Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 33/38] Documentation: PCI: endpoint: pci-epf-vntb: Update and add mwN_offset usage Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 34/38] Documentation: driver-api: ntb: Document remote embedded-DMA transport Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 35/38] PCI: endpoint: pci-epf-test: Add pci_epf_test_next_free_bar() helper Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 36/38] PCI: endpoint: pci-epf-test: Add remote eDMA-backed mode Koichiro Den
2026-01-19 20:47   ` Frank Li
2026-01-22 14:54     ` Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 37/38] misc: pci_endpoint_test: Add remote eDMA transfer test mode Koichiro Den
2026-01-18 13:54 ` [RFC PATCH v4 38/38] selftests: pci_endpoint: Add remote eDMA transfer coverage Koichiro Den
2026-01-20 18:30 ` [RFC PATCH v4 00/38] NTB transport backed by PCI EP embedded DMA Dave Jiang
2026-01-20 18:47   ` Dave Jiang
2026-01-21  2:40     ` 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=aXGDWiAxesCy1/yA@lizhi-Precision-Tower-5810 \
    --to=frank.li@nxp.com \
    --cc=allenbh@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=cassel@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=corbet@lwn.net \
    --cc=dave.jiang@intel.com \
    --cc=den@valinux.co.jp \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=geert+renesas@glider.be \
    --cc=gregkh@linuxfoundation.org \
    --cc=iommu@lists.linux.dev \
    --cc=jbrunet@baylibre.com \
    --cc=jdmason@kudzu.us \
    --cc=jingoohan1@gmail.com \
    --cc=joro@8bytes.org \
    --cc=kishon@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=kwilczynski@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=mani@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=ntb@lists.linux.dev \
    --cc=robh@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=skhan@linuxfoundation.org \
    --cc=utkarsh02t@gmail.com \
    --cc=vkoul@kernel.org \
    --cc=will@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox