dma: support DMA zone starting above 4GB
Status from this message: applied to the dma-mapping tree for Linux 6.12.
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v6 Latest posting 2/22 patches 14 repliesApplied
- v6 posting 1/20 of 2 patches 0 repliesSuperseded
- v53 patches 10 repliesSuperseded
Earlier versions · 4
| Version | Posted | Patches | Replies | Status |
|---|---|---|---|---|
| v4 | 2 patches | 3 replies | Superseded | |
| v3 | 3 patches | 7 replies | Superseded | |
| v2 RFC | 5 patches | 5 replies | Superseded | |
| v1 RFC | 4 patches | 7 replies | Superseded |
Changes in v6 from the cover letter
* Drop the first patch; existing logic is just fine
* Modify powerpc code to avoid off by one issue
Patches in v6 posting 2/2 Applied
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/2 | dma: replace zone_dma_bits by zone_dma_limitarch/ arch/ arch/ +4 more | +29 | 12 replies | |
| 2/2 | arm64: support DMA zone above 4GBarch/ | +0 | 1 reply |
Reviews trailers per patch
All 2 patches have a Reviewed-by or Acked-by.
| Patch | Petr Tesarik | Catalin Marinas | Marek Szyprowski | Neil Armstrong |
|---|---|---|---|---|
| 1/2 | R-b | R-b | T-b | T-b |
| 2/2 | R-b |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes. Scroll the table sideways for all 4 reviewers.
Cover letter [PATCH v6 RESED 0/2] dma: support DMA zone starting above 4GB
[ 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/[email protected]/
[0] See commit 791ab8b2e3db ("arm64: Ignore any DMA offsets in the max_zone_phys() calculation")
[2] https://lore.kernel.org/all/[email protected]/
[3] https://lore.kernel.org/all/[email protected]/
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
Signature · 1 line
2.43.0