Hi, On Mon, Apr 07, 2025 at 06:29:06PM +0200, Maxime Ripard wrote: > Hi, > > This series is the follow-up of the discussion that John and I had some > time ago here: > > https://lore.kernel.org/all/candhncqujn6bh3kxkf65bwitylvqsd9892-xtfdhhqqyrro...@mail.gmail.com/ > > 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 has been dropped in this second > version, we still need 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. > > I submitted a draft PR to the DT schema for the bindings used in this > PR: > https://github.com/devicetree-org/dt-schema/pull/138
One thing the discussion about the CMA heap naming[1] with John made me
realize is that if we have both a region that is exported as a
carved-out heap, and with devices pointing to it with reserved-memory,
we wouldn't use the same allocator in both cases.
It looks like we have four cases:
- We have a shared-dma-pool region with the reusable property: the
region is registered as a CMA area, the devices will allocate from
that.
- We have a shared-dma-pool region without the reusable property: the
region is registered as a coherent DMA area, and the devices will
allocate from that pool.
- We have a restricted-dma-pool region, devices will allocate from
swiotlb
- We have any other region, we can do whatever.
So, the driver only supports the fourth case, and should be
significantly more complicated.
I'll work on that.
Maxime
1: https://lore.kernel.org/dri-devel/20250422191939.555963-1-jkan...@redhat.com/
signature.asc
Description: PGP signature
