All of lore.kernel.org
 help / color / mirror / Atom feed
From: Barry Song <21cnbao@gmail.com>
To: m.szyprowski@samsung.com
Cc: v-songbaohua@oppo.com, zhengtangquan@oppo.com,
	ryan.roberts@arm.com, will@kernel.org, anshuman.khandual@arm.com,
	catalin.marinas@arm.com, 21cnbao@gmail.com,
	linux-kernel@vger.kernel.org, surenb@google.com,
	iommu@lists.linux.dev, maz@kernel.org, robin.murphy@arm.com,
	ardb@kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 5/5] dma-mapping: Allow batched DMA sync operations if supported by the arch
Date: Sat, 22 Nov 2025 07:28:07 +0800	[thread overview]
Message-ID: <20251121232807.40491-1-21cnbao@gmail.com> (raw)
In-Reply-To: <253c870f-770b-4102-be47-f8c06e9e6c31@samsung.com>

On Sat, Nov 22, 2025 at 12:09 AM Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>
> Hi Barry,
>
[...]
> This version looks a bit better to me. Similar batching could be added
> also to dma_iova_link()/dma_iova_sync() paths.

Thanks, Marek. I will respin a new version. For dma_iova, I assume you meant
something like the following?

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 7944a3af4545..7bb6ed663236 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -1837,7 +1837,7 @@ static int __dma_iova_link(struct device *dev, dma_addr_t addr,
 	int prot = dma_info_to_prot(dir, coherent, attrs);
 
 	if (!coherent && !(attrs & (DMA_ATTR_SKIP_CPU_SYNC | DMA_ATTR_MMIO)))
-		arch_sync_dma_for_device(phys, size, dir);
+		arch_sync_dma_for_device_batch_add(phys, size, dir);
 
 	return iommu_map_nosync(iommu_get_dma_domain(dev), addr, phys, size,
 			prot, GFP_ATOMIC);
@@ -1980,6 +1980,8 @@ int dma_iova_sync(struct device *dev, struct dma_iova_state *state,
 	dma_addr_t addr = state->addr + offset;
 	size_t iova_start_pad = iova_offset(iovad, addr);
 
+	if (!dev_is_dma_coherent(dev))
+		arch_sync_dma_batch_flush();
 	return iommu_sync_map(domain, addr - iova_start_pad,
 		      iova_align(iovad, size + iova_start_pad));
 }

If so, I don't really have such hardware to test. I wonder if I can make it as
patch 6/6 when respinning, and still mark it as RFC v2. Or should I leave it as
is and expect someone with the hardware to test and send it?

Thanks
Barry


WARNING: multiple messages have this Message-ID (diff)
From: Barry Song <21cnbao@gmail.com>
To: m.szyprowski@samsung.com
Cc: 21cnbao@gmail.com, ada.coupriediaz@arm.com,
	anshuman.khandual@arm.com, ardb@kernel.org,
	catalin.marinas@arm.com, iommu@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, maz@kernel.org,
	robin.murphy@arm.com, ryan.roberts@arm.com, surenb@google.com,
	v-songbaohua@oppo.com, will@kernel.org, zhengtangquan@oppo.com
Subject: Re: [RFC PATCH 5/5] dma-mapping: Allow batched DMA sync operations if supported by the arch
Date: Sat, 22 Nov 2025 07:28:07 +0800	[thread overview]
Message-ID: <20251121232807.40491-1-21cnbao@gmail.com> (raw)
In-Reply-To: <253c870f-770b-4102-be47-f8c06e9e6c31@samsung.com>

On Sat, Nov 22, 2025 at 12:09 AM Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>
> Hi Barry,
>
[...]
> This version looks a bit better to me. Similar batching could be added
> also to dma_iova_link()/dma_iova_sync() paths.

Thanks, Marek. I will respin a new version. For dma_iova, I assume you meant
something like the following?

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 7944a3af4545..7bb6ed663236 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -1837,7 +1837,7 @@ static int __dma_iova_link(struct device *dev, dma_addr_t addr,
 	int prot = dma_info_to_prot(dir, coherent, attrs);
 
 	if (!coherent && !(attrs & (DMA_ATTR_SKIP_CPU_SYNC | DMA_ATTR_MMIO)))
-		arch_sync_dma_for_device(phys, size, dir);
+		arch_sync_dma_for_device_batch_add(phys, size, dir);
 
 	return iommu_map_nosync(iommu_get_dma_domain(dev), addr, phys, size,
 			prot, GFP_ATOMIC);
@@ -1980,6 +1980,8 @@ int dma_iova_sync(struct device *dev, struct dma_iova_state *state,
 	dma_addr_t addr = state->addr + offset;
 	size_t iova_start_pad = iova_offset(iovad, addr);
 
+	if (!dev_is_dma_coherent(dev))
+		arch_sync_dma_batch_flush();
 	return iommu_sync_map(domain, addr - iova_start_pad,
 		      iova_align(iovad, size + iova_start_pad));
 }

If so, I don't really have such hardware to test. I wonder if I can make it as
patch 6/6 when respinning, and still mark it as RFC v2. Or should I leave it as
is and expect someone with the hardware to test and send it?

Thanks
Barry

  reply	other threads:[~2025-11-21 23:28 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-29  2:31 [RFC PATCH 0/5] dma-mapping: arm64: support batched cache sync Barry Song
2025-10-29  2:31 ` Barry Song
2025-10-29  2:31 ` [RFC PATCH 1/5] arm64: Provide dcache_by_myline_op_nosync helper Barry Song
2025-10-29  2:31   ` Barry Song
2025-10-29  2:31 ` [RFC PATCH 2/5] arm64: Provide dcache_clean_poc_nosync helper Barry Song
2025-10-29  2:31   ` Barry Song
2025-10-29  2:31 ` [RFC PATCH 3/5] arm64: Provide dcache_inval_poc_nosync helper Barry Song
2025-10-29  2:31   ` Barry Song
2025-10-29  2:31 ` [RFC PATCH 4/5] arm64: Provide arch_sync_dma_ batched helpers Barry Song
2025-10-29  2:31   ` Barry Song
2025-10-29  2:31 ` [RFC PATCH 5/5] dma-mapping: Allow batched DMA sync operations if supported by the arch Barry Song
2025-10-29  2:31   ` Barry Song
2025-11-13 18:19   ` Catalin Marinas
2025-11-13 18:19     ` Catalin Marinas
2025-11-17 21:12     ` Barry Song
2025-11-17 21:12       ` Barry Song
2025-11-21 16:09       ` Marek Szyprowski
2025-11-21 16:09         ` Marek Szyprowski
2025-11-21 23:28         ` Barry Song [this message]
2025-11-21 23:28           ` Barry Song
2025-11-24 18:11           ` Marek Szyprowski
2025-11-24 18:11             ` Marek Szyprowski
2025-11-06 20:44 ` [RFC PATCH 0/5] dma-mapping: arm64: support batched cache sync Barry Song
2025-11-06 20:44   ` Barry Song

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=20251121232807.40491-1-21cnbao@gmail.com \
    --to=21cnbao@gmail.com \
    --cc=anshuman.khandual@arm.com \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=iommu@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=maz@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=ryan.roberts@arm.com \
    --cc=surenb@google.com \
    --cc=v-songbaohua@oppo.com \
    --cc=will@kernel.org \
    --cc=zhengtangquan@oppo.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.