mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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
>   
> 


  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®