kernel/linux.git/drivers/dma-buf/heaps, branch v6.19.11

dma-buf: system_heap: use larger contiguous mappings instead of per-page mmap

2025-11-21T05:18:00+00:00

We can allocate high-order pages, but mapping them one by one is inefficient. This patch changes the code to map as large a chunk as possible. The code looks somewhat complicated mainly because supporting mmap with a non-zero offset is a bit tricky. Using the micro-benchmark below, we see that mmap becomes 35X faster: #include #include #include #include #include #include #include #include #define SIZE (512UL * 1024 * 1024) #define PAGE 4096 #define STRIDE (PAGE/sizeof(int)) #define PAGES (SIZE/PAGE) int main(void) { int heap = open("/dev/dma_heap/system", O_RDONLY); struct dma_heap_allocation_data d = { .len = SIZE, .fd_flags = O_RDWR|O_CLOEXEC }; ioctl(heap, DMA_HEAP_IOCTL_ALLOC, &d); struct timespec t0, t1; clock_gettime(CLOCK_MONOTONIC, &t0); int *p = mmap(NULL, SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, d.fd, 0); clock_gettime(CLOCK_MONOTONIC, &t1); for (int i = 0; i < PAGES; i++) p[i*STRIDE] = i; for (int i = 0; i < PAGES; i++) if (p[i*STRIDE] != i) { fprintf(stderr, "mismatch at page %d\n", i); exit(1); } long ns = (t1.tv_sec-t0.tv_sec)*1000000000L + (t1.tv_nsec-t0.tv_nsec); printf("mmap 512MB took %.3f us, verify OK\n", ns/1000.0); return 0; } W/ patch: ~ # ./a.out mmap 512MB took 200266.000 us, verify OK ~ # ./a.out mmap 512MB took 198151.000 us, verify OK ~ # ./a.out mmap 512MB took 197069.000 us, verify OK ~ # ./a.out mmap 512MB took 196781.000 us, verify OK ~ # ./a.out mmap 512MB took 198102.000 us, verify OK ~ # ./a.out mmap 512MB took 195552.000 us, verify OK W/o patch: ~ # ./a.out mmap 512MB took 6987470.000 us, verify OK ~ # ./a.out mmap 512MB took 6970739.000 us, verify OK ~ # ./a.out mmap 512MB took 6984383.000 us, verify OK ~ # ./a.out mmap 512MB took 6971311.000 us, verify OK ~ # ./a.out mmap 512MB took 6991680.000 us, verify OK Signed-off-by: Barry Song Acked-by: John Stultz Reviewed-by: Maxime Ripard Signed-off-by: Sumit Semwal [sumits: correct from 3.5x to 35x] Link: https://patch.msgid.link/20251021042022.47919-1-21cnbao@gmail.com

dma-buf: heaps: cma: Create CMA heap for each CMA reserved region

2025-10-18T16:01:22+00:00

Aside from the main CMA region, it can be useful to allow userspace to allocate from the other CMA reserved regions. Indeed, those regions can have specific properties that can be useful to a specific us-case. For example, one of them platform I've been with has ECC enabled on the entire memory but for a specific region. Using that region to allocate framebuffers can be particular beneficial because enabling the ECC has a performance and memory footprint cost. Thus, exposing these regions as heaps user-space can allocate from and import wherever needed allows to cover that use-case. For now, only shared-dma-pools regions with the reusable property (ie, backed by CMA) are supported, but eventually we'll want to support other DMA pools types. Since we collected all the CMA regions created during boot, we can simply iterate over all of them to create the heaps. This has a weird interaction with the recent work on the CMA name, in particular the backward compatibility code created by commit 854acbe75ff4 ("dma-buf: heaps: Give default CMA heap a fixed name"). Indeed, the old name was either 'reserved', or the name of the reserved-memory region device tree node if the linux,cma-default property was set. In both these cases, we have now collected this region during boot, and we're using the same name. So we're now largely redundant with the code to handle backward compatibility code, and we can thus remove it and the associated Kconfig option. Reviewed-by: T.J. Mercier Signed-off-by: Maxime Ripard Signed-off-by: Sumit Semwal [sumits: rebased the doc to latest] Link: https://lore.kernel.org/r/20251013-dma-buf-ecc-heap-v8-5-04ce150ea3d9@kernel.org

dma-buf: heaps: cma: Register list of CMA regions at boot

2025-10-18T16:01:21+00:00

In order to create a CMA heap instance for each CMA region found in the system, we need to register each of these instances. While it would appear trivial, the CMA regions are created super early in the kernel boot process, before most of the subsystems are initialized. Thus, we can't just create an exported function to create a heap from the CMA region being initialized. What we can do however is create a two-step process, where we collect all the CMA regions into an array early on, and then when we initialize the heaps we iterate over that array and create the heaps from the CMA regions we collected. Reviewed-by: T.J. Mercier Signed-off-by: Maxime Ripard Signed-off-by: Sumit Semwal Link: https://lore.kernel.org/r/20251013-dma-buf-ecc-heap-v8-2-04ce150ea3d9@kernel.org

dma-buf: heaps: Give default CMA heap a fixed name

2025-07-09T10:21:40+00:00

The CMA heap's name in devtmpfs can vary depending on how the heap is defined. Its name defaults to "reserved", but if a CMA area is defined in the devicetree, the heap takes on the devicetree node's name, such as "default-pool" or "linux,cma". To simplify naming, unconditionally name it "default_cma_region", but keep a legacy node in place backed by the same underlying allocator for backwards compatibility. Reviewed-by: Maxime Ripard Signed-off-by: Jared Kangas Signed-off-by: Sumit Semwal Link: https://lore.kernel.org/r/20250610131231.1724627-4-jkangas@redhat.com

dma-buf: heaps: Parameterize heap name in __add_cma_heap()

2025-07-09T10:21:39+00:00

Prepare for the introduction of a fixed-name CMA heap by replacing the unused void pointer parameter in __add_cma_heap() with the heap name. Reviewed-by: Maxime Ripard Acked-by: John Stultz Signed-off-by: Jared Kangas Signed-off-by: Sumit Semwal Link: https://lore.kernel.org/r/20250610131231.1724627-3-jkangas@redhat.com

dma-buf: system_heap: No separate allocation for attachment sg_tables

2025-07-09T10:21:39+00:00

struct dma_heap_attachment is a separate allocation from the struct sg_table it contains, but there is no reason for this. Let's use the slab allocator just once instead of twice for dma_heap_attachment. Signed-off-by: T.J. Mercier Reviewed-by: Christian König Signed-off-by: Sumit Semwal Link: https://lore.kernel.org/r/20250417180943.1559755-1-tjmercier@google.com

dma-buf: heaps: system: Remove global variable

2025-04-08T09:48:39+00:00

The system heap is storing its struct dma_heap pointer in a global variable but isn't using it anywhere. Let's move the global variable into system_heap_create() to make it local. Signed-off-by: Maxime Ripard Reviewed-by: Christian König Reviewed-by: Mattijs Korpershoek Link: https://patchwork.freedesktop.org/patch/msgid/20250407-dma-buf-ecc-heap-v3-1-97cdd36a5f29@kernel.org Signed-off-by: Christian König

dma-buf/heaps: replace kmap_atomic with kmap_local_page

2024-10-14T14:46:03+00:00

Use of kmap_atomic/kunmap_atomic is deprecated, use kmap_local_page/kunmap_local instead. This is reported by checkpatch. Also fix repeated word issue. WARNING: Deprecated use of 'kmap_atomic', prefer 'kmap_local_page' instead + void *vaddr = kmap_atomic(page); WARNING: Deprecated use of 'kunmap_atomic', prefer 'kunmap_local' instead + kunmap_atomic(vaddr); WARNING: Possible repeated word: 'by' + * has been killed by by SIGKILL total: 0 errors, 3 warnings, 405 lines checked Signed-off-by: Pintu Kumar Reviewed-by: T.J. Mercier Signed-off-by: Sumit Semwal Link: https://patchwork.freedesktop.org/patch/msgid/20241001175057.27172-1-quic_pintu@quicinc.com

Merge drm/drm-next into drm-misc-next

2024-09-30T08:50:54+00:00

Get drm-misc-next to up v6.12-rc1. Signed-off-by: Thomas Zimmermann

dma-buf: heaps: Add __init to CMA and system heap module_init functions

2024-09-09T10:21:54+00:00

Shrink the kernel .text a bit after successful initialization of the heaps. Signed-off-by: T.J. Mercier Acked-by: John Stultz Signed-off-by: Sumit Semwal Link: https://patchwork.freedesktop.org/patch/msgid/20240906000314.2368749-1-tjmercier@google.com