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: "Baruch Siach" <baruch@tkos.co.il>,
"Robin Murphy" <robin.murphy@arm.com>,
iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-s390@vger.kernel.org, "Petr Tesařík" <petr@tesarici.cz>,
"Ramon Fried" <ramon@neureality.ai>,
"Elad Nachman" <enachman@marvell.com>
Subject: [PATCH v5 0/3] dma: support DMA zone starting above 4GB
Date: Fri, 2 Aug 2024 09:03:45 +0300 [thread overview]
Message-ID: <cover.1722578375.git.baruch@tkos.co.il> (raw)
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.
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/
Baruch Siach (1):
dma: improve DMA zone selection
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 | 9 ++++-----
arch/s390/mm/init.c | 2 +-
include/linux/dma-direct.h | 2 +-
kernel/dma/direct.c | 10 +++++-----
kernel/dma/pool.c | 4 ++--
kernel/dma/swiotlb.c | 8 ++++----
7 files changed, 27 insertions(+), 40 deletions(-)
base-commit: 8400291e289ee6b2bf9779ff1c83a291501f017b
--
2.43.0
next reply other threads:[~2024-08-02 6:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-02 6:03 Baruch Siach [this message]
2024-08-02 6:03 ` [PATCH v5 1/3] dma: improve DMA zone selection Baruch Siach
2024-08-07 12:04 ` kernel test robot
2024-08-07 13:13 ` Robin Murphy
2024-08-07 13:58 ` Catalin Marinas
2024-08-07 14:12 ` Petr Tesařík
2024-08-07 16:40 ` kernel test robot
2024-08-02 6:03 ` [PATCH v5 2/3] dma: replace zone_dma_bits by zone_dma_limit Baruch Siach
2024-08-02 9:37 ` Catalin Marinas
2024-08-07 14:19 ` Petr Tesařík
2024-08-07 18:14 ` Catalin Marinas
2024-08-08 9:35 ` Petr Tesařík
2024-08-08 10:01 ` Robin Murphy
2024-08-08 13:46 ` Catalin Marinas
2024-08-07 14:30 ` Petr Tesařík
2024-08-02 6:03 ` [PATCH v5 3/3] arm64: support DMA zone above 4GB Baruch Siach
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.1722578375.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).