Skip to content

Enable per-region CMA DMA-BUF heaps for audio ML offload#839

Open
qti-sbojja wants to merge 3 commits into
qualcomm-linux:qcom-6.18.yfrom
qti-sbojja:dma_support
Open

Enable per-region CMA DMA-BUF heaps for audio ML offload#839
qti-sbojja wants to merge 3 commits into
qualcomm-linux:qcom-6.18.yfrom
qti-sbojja:dma_support

Conversation

@qti-sbojja

@qti-sbojja qti-sbojja commented Jul 17, 2026

Copy link
Copy Markdown

Backports the upstream per-region CMA DMA-BUF heap support (heap registration rework + one heap per CMA reserved region) and enables CONFIG_DMA_CMA in qcom.config so the DMA-BUF heap configs can be selected. Enables allocating from a dedicated CMA region for the audio ML offload use case.

CRs-Fixed: 4613255

Maxime Ripard (mripard) and others added 3 commits July 17, 2026 16:03
The CMA heap instantiation was initially developed by having the
contiguous DMA code call into the CMA heap to create a new instance
every time a reserved memory area is probed.

Turning the CMA heap into a module would create a dependency of the
kernel on a module, which doesn't work.

Let's turn the logic around and do the opposite: store all the reserved
memory CMA regions into the contiguous DMA code, and provide an iterator
for the heap to use when it probes.

Signed-off-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20260331-dma-buf-heaps-as-modules-v4-1-e18fda504419@kernel.org
…egion

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
854acbe ("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 <tjmercier@google.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Link: https://lore.kernel.org/r/20251013-dma-buf-ecc-heap-v8-5-04ce150ea3d9@kernel.org
Enable CONFIG_DMA_CMA as a dependency to allow the DMA-BUF heap
configs (DMABUF_HEAPS, DMABUF_HEAPS_CMA, DMABUF_HEAPS_SYSTEM) to
be selected in qcom.config.

Link: qualcomm-linux/kernel-topics#1452
Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants