From: Robin Murphy <robin.murphy@arm.com>
To: "Sumit Kumar" <sumit.kumar@oss.qualcomm.com>,
"Krishna Chaitanya Chundru" <krishna.chundru@oss.qualcomm.com>,
"Veerabhadrarao Badiganti"
<veerabhadrarao.badiganti@oss.qualcomm.com>,
"Subramanian Ananthanarayanan"
<subramanian.ananthanarayanan@oss.qualcomm.com>,
"Akhil Vinod" <akhil.vinod@oss.qualcomm.com>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Vinod Koul" <vkoul@kernel.org>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Kishon Vijay Abraham I" <kishon@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>
Cc: dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org,
iommu@lists.linux.dev, linux-pci@vger.kernel.org,
mhi@lists.linux.dev, linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH 1/3] dmaengine: Add multi-buffer support in single DMA transfer
Date: Fri, 13 Mar 2026 15:16:50 +0000 [thread overview]
Message-ID: <ab632240-f4eb-4bcc-8170-2a9a024c1ce7@arm.com> (raw)
In-Reply-To: <20260313-dma_multi_sg-v1-1-8fabb0d1a759@oss.qualcomm.com>
On 2026-03-13 6:49 am, Sumit Kumar wrote:
> Add dmaengine_prep_batch_sg API for batching multiple independent buffers
> in a single DMA transaction. Each scatter-gather entry specifies both
> source and destination addresses. This allows multiple non-contiguous
> memory regions to be transferred in a single DMA transaction instead of
> separate operations, significantly reducing submission overhead and
> interrupt overhead.
>
> Extends struct scatterlist with optional dma_dst_address field
> and implements support in dw-edma driver.
[...]
> diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
> index 29f6ceb98d74b118d08b6a3d4eb7f62dcde0495d..20b65ffcd5e2a65ec5026a29344caf6baa09700b 100644
> --- a/include/linux/scatterlist.h
> +++ b/include/linux/scatterlist.h
> @@ -19,6 +19,9 @@ struct scatterlist {
> #ifdef CONFIG_NEED_SG_DMA_FLAGS
> unsigned int dma_flags;
> #endif
> +#ifdef CONFIG_NEED_SG_DMA_DST_ADDR
> + dma_addr_t dma_dst_address;
> +#endif
Eww, no, what does this even mean? Is the regular dma_addr somehow
implicitly a "source" now? How could the single piece of memory
represented by page_link/offset/length have two different DMA addresses?
How are both the DMA mapping code and users supposed to know which one
is relevant in any particular situation?
If you want to bring back DMA_MEMCPY_SG yet again, and you have an
actual user this time, then do that (although by now it most likely
wants to be a dma_vec version). Don't do whatever this is...
If you want to batch multiple
dmaengine_slave_config()/dma_prep_slave_single() operations into some
many-to-many variant of dmaengine_prep_peripheral_dma_vec(), then surely
that requires actual batching of the config part as well - e.g. passing
an explicit vector of distinct dma_slave_configs corresponding to each
individual dma_vec - in order to be able to work correctly in general?
Thanks,
Robin.
> };
>
> /*
> @@ -36,6 +39,10 @@ struct scatterlist {
> #define sg_dma_len(sg) ((sg)->length)
> #endif
>
> +#ifdef CONFIG_NEED_SG_DMA_DST_ADDR
> +#define sg_dma_dst_address(sg) ((sg)->dma_dst_address)
> +#endif
> +
> struct sg_table {
> struct scatterlist *sgl; /* the list */
> unsigned int nents; /* number of mapped entries */
> diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
> index 31cfdb6b4bc3e33c239111955d97b3ec160baafa..3539b5b1efe27be7ccbfebb358dbb9cad2868f11 100644
> --- a/kernel/dma/Kconfig
> +++ b/kernel/dma/Kconfig
> @@ -32,6 +32,9 @@ config NEED_SG_DMA_LENGTH
> config NEED_DMA_MAP_STATE
> bool
>
> +config NEED_SG_DMA_DST_ADDR
> + bool
> +
> config ARCH_DMA_ADDR_T_64BIT
> def_bool 64BIT || PHYS_ADDR_T_64BIT
>
>
next prev parent reply other threads:[~2026-03-13 15:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-13 6:49 [PATCH 0/3] dmaengine: Add batched scatter-gather DMA support Sumit Kumar
2026-03-13 6:49 ` [PATCH 1/3] dmaengine: Add multi-buffer support in single DMA transfer Sumit Kumar
2026-03-13 15:16 ` Robin Murphy [this message]
2026-03-16 17:05 ` Niklas Cassel
2026-03-17 10:54 ` Vinod Koul
2026-03-30 5:28 ` Sumit Kumar
2026-03-13 6:49 ` [PATCH 2/3] PCI: epf-mhi: Add batched DMA read support Sumit Kumar
2026-03-13 6:49 ` [PATCH 3/3] bus: mhi: ep: Use batched read for ring caching Sumit Kumar
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=ab632240-f4eb-4bcc-8170-2a9a024c1ce7@arm.com \
--to=robin.murphy@arm.com \
--cc=akhil.vinod@oss.qualcomm.com \
--cc=bhelgaas@google.com \
--cc=dmaengine@vger.kernel.org \
--cc=iommu@lists.linux.dev \
--cc=kishon@kernel.org \
--cc=krishna.chundru@oss.qualcomm.com \
--cc=kwilczynski@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mani@kernel.org \
--cc=mhi@lists.linux.dev \
--cc=subramanian.ananthanarayanan@oss.qualcomm.com \
--cc=sumit.kumar@oss.qualcomm.com \
--cc=veerabhadrarao.badiganti@oss.qualcomm.com \
--cc=vkoul@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
all inboxes | Powered by JetHome®