Re: [PATCH v7 0/5] dma-buf: heaps: Create a CMA heap for each CMA reserved region

[Maxime Ripard <mripard@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2381 bytes --]

On Tue, Aug 26, 2025 at 09:36:03AM +0200, Maxime Ripard wrote:
> Hi,
> 
> On Mon, Jul 21, 2025 at 01:17:29PM +0200, Maxime Ripard wrote:
> > Here's another attempt at supporting user-space allocations from a
> > specific carved-out reserved memory region.
> > 
> > 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
> 
> Any chance we can get this merged?

Guys, can we move forward on this?

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]