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
signature.asc
Description: PGP signature
