From: Baruch Siach <baruch@tkos.co.il>
To: Christoph Hellwig <hch@lst.de>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>
Cc: linux-s390@vger.kernel.org, "Baruch Siach" <baruch@tkos.co.il>,
"Ramon Fried" <ramon@neureality.ai>,
"Petr Tesařík" <petr@tesarici.cz>,
"Robin Murphy" <robin.murphy@arm.com>,
linux-kernel@vger.kernel.org, iommu@lists.linux.dev,
"Elad Nachman" <enachman@marvell.com>,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 RESED 0/2] dma: support DMA zone starting above 4GB
Date: Sun, 11 Aug 2024 10:09:34 +0300 [thread overview]
Message-ID: <cover.1723359916.git.baruch@tkos.co.il> (raw)
[ Resend series with correct Cc list. Sorry for the spam. ]
DMA zones code assumes that DMA lower limit is zero. When there is no RAM
below 4GB, arm64 platform code sets DMA/DMA32 zone limits to cover the entire
RAM[0].
My target platform has RAM starting at 32GB. Devices with 30-bit DMA mask are
mapped to 1GB at the bottom of RAM, between 32GB - 33GB. DMA zone over the
entire RAM breaks DMA allocation for these devices.
In response to a previous RFC hack[1] Catalin Marinas suggested to add a
separate offset value as base address for the DMA zone, and then refined the
suggestion to use start of RAM[3]. This series attempts to implement that
suggestion.
With this series applied, the DMA zone covers the right RAM range for my
platform.
v6:
* Drop the first patch; existing logic is just fine
* Modify powerpc code to avoid off by one issue
v5:
* Test the correct kernel
* Add missing patch that actually makes DMA zone work
* Extend the treatment of zone_dma_limit > DMA_BIT_MASK(32)
* Use max() to make the code somewhat more readable
* Change zone_dma_limit type to u64 to match DMA_BIT_MASK()
v4:
* Drop last patch. zone_dma_limit includes RAM base address.
* Adjust DMA zone selection in swiotlb as well.
* Don't change max_zone_phys() behaviour
* Update code to fallback to DMA zone when zone_dma_limit > DMA_BIT_MASK(32)
v3:
* Rebase on v6.11-rc1.
* Drop zone_dma_base. Use memblock_start_of_DRAM() instead.
* Drop DT patches. Low DMA range limit no longer needed.
* Add patch to improve dma_direct_optimal_gfp_mask() heuristics as Catalin
suggested.
RFC v2:
* Add patch from Catalin[2] changing zone_dma_bits to zone_dma_limit to
simplify subsequent patches
* Test on real hardware
RFC v1: https://lore.kernel.org/all/cover.1703683642.git.baruch@tkos.co.il/
[0] See commit 791ab8b2e3db ("arm64: Ignore any DMA offsets in the
max_zone_phys() calculation")
[1] https://lore.kernel.org/all/9af8a19c3398e7dc09cfc1fbafed98d795d9f83e.1699464622.git.baruch@tkos.co.il/
[2] https://lore.kernel.org/all/ZZ2HnHJV3gdzu1Aj@arm.com/
[3] https://lore.kernel.org/all/ZnH-VU2iz9Q2KLbr@arm.com/
Catalin Marinas (2):
dma: replace zone_dma_bits by zone_dma_limit
arm64: support DMA zone above 4GB
arch/arm64/mm/init.c | 32 ++++++++++----------------------
arch/powerpc/mm/mem.c | 5 ++++-
arch/s390/mm/init.c | 2 +-
include/linux/dma-direct.h | 2 +-
kernel/dma/direct.c | 6 +++---
kernel/dma/pool.c | 4 ++--
kernel/dma/swiotlb.c | 6 +++---
7 files changed, 24 insertions(+), 33 deletions(-)
base-commit: 8400291e289ee6b2bf9779ff1c83a291501f017b
--
2.43.0
next reply other threads:[~2024-08-11 7:10 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-11 7:09 Baruch Siach [this message]
2024-08-11 7:09 ` [PATCH v6 RESED 1/2] dma: replace zone_dma_bits by zone_dma_limit Baruch Siach
2024-08-12 5:52 ` Petr Tesarik
2024-08-12 11:22 ` Catalin Marinas
2024-08-16 11:52 ` Will Deacon
2024-08-16 14:37 ` Petr Tesařík
2024-08-26 19:28 ` Marek Szyprowski
2024-08-27 4:52 ` Baruch Siach
2024-08-27 6:14 ` Marek Szyprowski
2024-08-27 7:03 ` Baruch Siach
2024-08-27 7:46 ` Marek Szyprowski
2024-08-29 13:42 ` Neil Armstrong
2024-08-29 14:38 ` Robin Murphy
2024-08-29 14:54 ` neil.armstrong
2024-08-11 7:09 ` [PATCH v6 RESED 2/2] arm64: support DMA zone above 4GB Baruch Siach
2024-08-12 5:54 ` Petr Tesarik
2024-08-22 4:18 ` [PATCH v6 RESED 0/2] dma: support DMA zone starting " Christoph Hellwig
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=cover.1723359916.git.baruch@tkos.co.il \
--to=baruch@tkos.co.il \
--cc=catalin.marinas@arm.com \
--cc=enachman@marvell.com \
--cc=hch@lst.de \
--cc=iommu@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=m.szyprowski@samsung.com \
--cc=petr@tesarici.cz \
--cc=ramon@neureality.ai \
--cc=robin.murphy@arm.com \
--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;
as well as URLs for NNTP newsgroup(s).