linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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


             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).