On Wed, 15 Oct 2025 at 13:53, Sumit Semwal <[email protected]> wrote: > > 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.
Thank you; it's merged to drm-misc-next now. > > > 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 -- Thanks and regards, Sumit Semwal (he / him) Senior Tech Lead - Android, Platforms and Virtualisation Linaro.org │ Arm Solutions at Light Speed
