drivers/dma-buf/dma-heap.c | 1 + drivers/dma-buf/heaps/Kconfig | 4 ++-- drivers/dma-buf/heaps/cma_heap.c | 21 +++++---------------- drivers/dma-buf/heaps/system_heap.c | 5 +++++ include/linux/dma-map-ops.h | 18 ++++++++++-------- kernel/dma/contiguous.c | 37 ++++++++++++++++++++++++++++++++++--- mm/cma.c | 3 +++ 7 files changed, 60 insertions(+), 29 deletions(-)
Hi,
The recent introduction of heaps in the optee driver [1] made possible
the creation of heaps as modules.
It's generally a good idea if possible, including for the already
existing system and CMA heaps.
The system one is pretty trivial, the CMA one is a bit more involved,
especially since we have a call from kernel/dma/contiguous.c to the CMA
heap code. This was solved by turning the logic around and making the
CMA heap call into the contiguous DMA code.
Let me know what you think,
Maxime
1: https://lore.kernel.org/dri-devel/20250911135007.1275833-4-jens.wiklander@linaro.org/
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
Changes in v3:
- Squashed cma_get_name and cma_alloc/release patches
- Fixed typo in Export dev_get_cma_area commit title
- Fixed compilation failure with DMA_CMA but not OF_RESERVED_MEM
- Link to v2: https://lore.kernel.org/r/20260227-dma-buf-heaps-as-modules-v2-0-454aee7e06cc@kernel.org
Changes in v2:
- Collect tags
- Don't export dma_contiguous_default_area anymore, but export
dev_get_cma_area instead
- Mentioned that heap modules can't be removed
- Link to v1: https://lore.kernel.org/r/20260225-dma-buf-heaps-as-modules-v1-0-2109225a090d@kernel.org
---
Maxime Ripard (8):
dma: contiguous: Turn heap registration logic around
dma: contiguous: Make dev_get_cma_area() a proper function
dma: contiguous: Make dma_contiguous_default_area static
dma: contiguous: Export dev_get_cma_area()
mm: cma: Export cma_alloc(), cma_release() and cma_get_name()
dma-buf: heaps: Export mem_accounting parameter
dma-buf: heaps: cma: Turn the heap into a module
dma-buf: heaps: system: Turn the heap into a module
drivers/dma-buf/dma-heap.c | 1 +
drivers/dma-buf/heaps/Kconfig | 4 ++--
drivers/dma-buf/heaps/cma_heap.c | 21 +++++----------------
drivers/dma-buf/heaps/system_heap.c | 5 +++++
include/linux/dma-map-ops.h | 18 ++++++++++--------
kernel/dma/contiguous.c | 37 ++++++++++++++++++++++++++++++++++---
mm/cma.c | 3 +++
7 files changed, 60 insertions(+), 29 deletions(-)
---
base-commit: 499a718536dc0e1c1d1b6211847207d58acd9916
change-id: 20260225-dma-buf-heaps-as-modules-1034b3ec9f2a
Best regards,
--
Maxime Ripard <mripard@kernel.org>
Hi Maxime, On 03.03.2026 11:13, Maxime Ripard wrote: > The recent introduction of heaps in the optee driver [1] made possible > the creation of heaps as modules. > > It's generally a good idea if possible, including for the already > existing system and CMA heaps. > > The system one is pretty trivial, the CMA one is a bit more involved, > especially since we have a call from kernel/dma/contiguous.c to the CMA > heap code. This was solved by turning the logic around and making the > CMA heap call into the contiguous DMA code. > > Let me know what you think, > Maxime > > 1: https://lore.kernel.org/dri-devel/20250911135007.1275833-4-jens.wiklander@linaro.org/ > > Signed-off-by: Maxime Ripard <mripard@kernel.org> I'm okay with the kernel/dma/contiguous.c changes. I only wonder how to properly merge them. There are other pending changes to kernel/dma/contiguous.c file [1] and if they finally get reviewed, I would like to merge both via dma-mapping-for-next tree. Then I can provide a stable branch for merging the remaining dma-buf pathes. Is it okay for You? 1. https://lore.kernel.org/all/20260313150802.1121442-1-m.szyprowski@samsung.com/ > --- > Changes in v3: > - Squashed cma_get_name and cma_alloc/release patches > - Fixed typo in Export dev_get_cma_area commit title > - Fixed compilation failure with DMA_CMA but not OF_RESERVED_MEM > - Link to v2: https://lore.kernel.org/r/20260227-dma-buf-heaps-as-modules-v2-0-454aee7e06cc@kernel.org > > Changes in v2: > - Collect tags > - Don't export dma_contiguous_default_area anymore, but export > dev_get_cma_area instead > - Mentioned that heap modules can't be removed > - Link to v1: https://lore.kernel.org/r/20260225-dma-buf-heaps-as-modules-v1-0-2109225a090d@kernel.org > > --- > Maxime Ripard (8): > dma: contiguous: Turn heap registration logic around > dma: contiguous: Make dev_get_cma_area() a proper function > dma: contiguous: Make dma_contiguous_default_area static > dma: contiguous: Export dev_get_cma_area() > mm: cma: Export cma_alloc(), cma_release() and cma_get_name() > dma-buf: heaps: Export mem_accounting parameter > dma-buf: heaps: cma: Turn the heap into a module > dma-buf: heaps: system: Turn the heap into a module > > drivers/dma-buf/dma-heap.c | 1 + > drivers/dma-buf/heaps/Kconfig | 4 ++-- > drivers/dma-buf/heaps/cma_heap.c | 21 +++++---------------- > drivers/dma-buf/heaps/system_heap.c | 5 +++++ > include/linux/dma-map-ops.h | 18 ++++++++++-------- > kernel/dma/contiguous.c | 37 ++++++++++++++++++++++++++++++++++--- > mm/cma.c | 3 +++ > 7 files changed, 60 insertions(+), 29 deletions(-) > --- > base-commit: 499a718536dc0e1c1d1b6211847207d58acd9916 > change-id: 20260225-dma-buf-heaps-as-modules-1034b3ec9f2a > > Best regards, Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
Hi Marek, On Fri, Mar 20, 2026 at 01:24:18PM +0100, Marek Szyprowski wrote: > On 03.03.2026 11:13, Maxime Ripard wrote: > > The recent introduction of heaps in the optee driver [1] made possible > > the creation of heaps as modules. > > > > It's generally a good idea if possible, including for the already > > existing system and CMA heaps. > > > > The system one is pretty trivial, the CMA one is a bit more involved, > > especially since we have a call from kernel/dma/contiguous.c to the CMA > > heap code. This was solved by turning the logic around and making the > > CMA heap call into the contiguous DMA code. > > > > Let me know what you think, > > Maxime > > > > 1: https://lore.kernel.org/dri-devel/20250911135007.1275833-4-jens.wiklander@linaro.org/ > > > > Signed-off-by: Maxime Ripard <mripard@kernel.org> > > I'm okay with the kernel/dma/contiguous.c changes. I only wonder how to > properly merge them. There are other pending changes to > kernel/dma/contiguous.c file [1] and if they finally get reviewed, I > would like to merge both via dma-mapping-for-next tree. Then I can > provide a stable branch for merging the remaining dma-buf pathes. Is it > okay for You? That sounds reasonable to media Thanks! Maxime
On 20.03.2026 14:09, Maxime Ripard wrote: > On Fri, Mar 20, 2026 at 01:24:18PM +0100, Marek Szyprowski wrote: >> On 03.03.2026 11:13, Maxime Ripard wrote: >>> The recent introduction of heaps in the optee driver [1] made possible >>> the creation of heaps as modules. >>> >>> It's generally a good idea if possible, including for the already >>> existing system and CMA heaps. >>> >>> The system one is pretty trivial, the CMA one is a bit more involved, >>> especially since we have a call from kernel/dma/contiguous.c to the CMA >>> heap code. This was solved by turning the logic around and making the >>> CMA heap call into the contiguous DMA code. >>> >>> Let me know what you think, >>> Maxime >>> >>> 1: https://lore.kernel.org/dri-devel/20250911135007.1275833-4-jens.wiklander@linaro.org/ >>> >>> Signed-off-by: Maxime Ripard <mripard@kernel.org> >> I'm okay with the kernel/dma/contiguous.c changes. I only wonder how to >> properly merge them. There are other pending changes to >> kernel/dma/contiguous.c file [1] and if they finally get reviewed, I >> would like to merge both via dma-mapping-for-next tree. Then I can >> provide a stable branch for merging the remaining dma-buf pathes. Is it >> okay for You? > That sounds reasonable to me I've applied patches 1-5 to my dma-mapping-for-next branch and resolved conflicts in the mentioned kernel/dma/contiguous.c file. Here is a stable branch to apply remaining dma-buf heaps patches: https://web.git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux.git/log/?h=dma-contig-for-7.1-modules-prep Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
© 2016 - 2026 Red Hat, Inc.