Repository navigation
Enable per-region CMA DMA-BUF heaps for audio ML offload - #1363
qti-sbojja wants to merge 3 commits into
Conversation
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>
|
Merge Check Failed: CR Not Eligible for Merge CR 4613255 is not eligible for merge. The parent software image for kernel.qli.2.0 is not development complete. Entity: Please ensure the CR passes both CCT (ComponentChangeTasks) and ICT (Integration Change Tasks) validations. |
|
Merge Check Failed: CR Not Eligible for Merge CR 4727557 is not eligible for merge. The parent software image for kernel.qli.2.0 is not development complete. Entity: Please ensure the CR passes both CCT (ComponentChangeTasks) and ICT (Integration Change Tasks) validations. |
PR #1363 — validate-patchPR: #1363
Final Summary
|
PR #1363 — checker-log-analyzerPR: #1363
Detailed report: Full report
|
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: 4727557