Hi Maxime, On Mon, 13 Oct 2025 at 14:05, Maxime Ripard <[email protected]> wrote: > > Hi, > > Here's another attempt at supporting user-space allocations from a > specific carved-out reserved memory region.
Thank you for the series - I think it looks pretty decent, and with Marek's Acked-by for the cma patch [1], I'm inclined to merge it. I'll wait till today evening, in case there are any more comments, and then go ahead and merge it. Best, Sumit. > > The initial problem we were discussing was that I'm currently working on > a platform which has a memory layout with ECC enabled. However, enabling > the ECC has a number of drawbacks on that platform: lower performance, > increased memory usage, etc. So for things like framebuffers, the > trade-off isn't great and thus there's a memory region with ECC disabled > to allocate from for such use cases. > > After a suggestion from John, I chose to first start using heap > allocations flags to allow for userspace to ask for a particular ECC > setup. This is then backed by a new heap type that runs from reserved > memory chunks flagged as such, and the existing DT properties to specify > the ECC properties. > > After further discussion, it was considered that flags were not the > right solution, and relying on the names of the heaps would be enough to > let userspace know the kind of buffer it deals with. > > Thus, even though the uAPI part of it had been dropped in this second > version, we still needed a driver to create heaps out of carved-out memory > regions. In addition to the original usecase, a similar driver can be > found in BSPs from most vendors, so I believe it would be a useful > addition to the kernel. > > Some extra discussion with Rob Herring [1] came to the conclusion that > some specific compatible for this is not great either, and as such an > new driver probably isn't called for either. > > Some other discussions we had with John [2] also dropped some hints that > multiple CMA heaps might be a good idea, and some vendors seem to do > that too. > > So here's another attempt that doesn't affect the device tree at all and > will just create a heap for every CMA reserved memory region. > > It also falls nicely into the current plan we have to support cgroups in > DRM/KMS and v4l2, which is an additional benefit. > > Let me know what you think, > Maxime > > 1: https://lore.kernel.org/all/20250707-cobalt-dingo-of-serenity-dbf92c@houat/ > 2: > https://lore.kernel.org/all/CANDhNCroe6ZBtN_o=c71kzffawk-ff5rcdnr9p5h1sgpows...@mail.gmail.com/ > > Let me know what you think, > Maxime > > Signed-off-by: Maxime Ripard <[email protected]> > --- > Changes in v8: > - Rebased on top of 6.18-rc1 > - Added TJ R-b > - Link to v7: > https://lore.kernel.org/r/[email protected] > > Changes in v7: > - Invert the logic and register CMA heap from the reserved memory / > dma contiguous code, instead of iterating over them from the CMA heap. > - Link to v6: > https://lore.kernel.org/r/[email protected] > > Changes in v6: > - Drop the new driver and allocate a CMA heap for each region now > - Dropped the binding > - Rebased on 6.16-rc5 > - Link to v5: > https://lore.kernel.org/r/[email protected] > > Changes in v5: > - Rebased on 6.16-rc2 > - Switch from property to dedicated binding > - Link to v4: > https://lore.kernel.org/r/[email protected] > > Changes in v4: > - Rebased on 6.15-rc7 > - Map buffers only when map is actually called, not at allocation time > - Deal with restricted-dma-pool and shared-dma-pool > - Reword Kconfig options > - Properly report dma_map_sgtable failures > - Link to v3: > https://lore.kernel.org/r/[email protected] > > Changes in v3: > - Reworked global variable patch > - Link to v2: > https://lore.kernel.org/r/[email protected] > > Changes in v2: > - Add vmap/vunmap operations > - Drop ECC flags uapi > - Rebase on top of 6.14 > - Link to v1: > https://lore.kernel.org/r/[email protected] > > --- > Maxime Ripard (5): > doc: dma-buf: List the heaps by name > dma-buf: heaps: cma: Register list of CMA regions at boot > dma: contiguous: Register reusable CMA regions at boot > dma: contiguous: Reserve default CMA heap > dma-buf: heaps: cma: Create CMA heap for each CMA reserved region > > Documentation/userspace-api/dma-buf-heaps.rst | 24 ++++++++------ > MAINTAINERS | 1 + > drivers/dma-buf/heaps/Kconfig | 10 ------ > drivers/dma-buf/heaps/cma_heap.c | 47 > +++++++++++++++++---------- > include/linux/dma-buf/heaps/cma.h | 16 +++++++++ > kernel/dma/contiguous.c | 11 +++++++ > 6 files changed, 72 insertions(+), 37 deletions(-) > --- > base-commit: 47633099a672fc7bfe604ef454e4f116e2c954b1 > change-id: 20240515-dma-buf-ecc-heap-28a311d2c94e > prerequisite-message-id: <[email protected]> > prerequisite-patch-id: bc44be5968feb187f2bc1b8074af7209462b18e7 > prerequisite-patch-id: f02a91b723e5ec01fbfedf3c3905218b43d432da > prerequisite-patch-id: e944d0a3e22f2cdf4d3b3906e5603af934696deb > > Best regards, > -- > Maxime Ripard <[email protected]> > -- Thanks and regards, Sumit Semwal (he / him) Senior Tech Lead - Android, Platforms and Virtualisation Linaro.org │ Arm Solutions at Light Speed
