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 RFC series attempts to implement that
suggestion.
With this series applied, the DMA zone covers the right RAM range for my
platform.
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@xxxxxxxxxx/
[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@xxxxxxxxxx/
[2] https://lore.kernel.org/all/ZZ2HnHJV3gdzu1Aj@xxxxxxx/
[3] https://lore.kernel.org/all/ZnH-VU2iz9Q2KLbr@xxxxxxx/
Baruch Siach (2):
dma-mapping: improve DMA zone selection
dma-direct: use RAM start to offset zone_dma_limit
Catalin Marinas (1):
dma-mapping: replace zone_dma_bits by zone_dma_limit
arch/arm64/mm/init.c | 34 +++++++++++++---------------------
arch/powerpc/mm/mem.c | 9 ++++-----
arch/s390/mm/init.c | 2 +-
include/linux/dma-direct.h | 2 +-
kernel/dma/direct.c | 15 ++++++++-------
kernel/dma/pool.c | 3 ++-
kernel/dma/swiotlb.c | 4 ++--
7 files changed, 31 insertions(+), 38 deletions(-)
--
2.43.0
