Hi Rob, On Fri, Jun 27, 2025 at 02:31:32PM -0500, Rob Herring wrote: > On Tue, Jun 17, 2025 at 02:25:40PM +0200, Maxime Ripard wrote: > > Some parts of the memory can be dedicated to specific purposes and > > exposed as a dedicated memory allocator. > > > > This is especially useful if that particular region has a particular > > properties the rest of the memory doesn't have. For example, some > > platforms have their entire RAM covered by ECC but for a small area > > meant to be used by applications that don't need ECC, and its associated > > overhead. > > > > Let's introduce a binding to describe such a region and allow the OS to > > create a dedicated memory allocator for it. > > > > Signed-off-by: Maxime Ripard <[email protected]> > > --- > > .../bindings/reserved-memory/carved-out.yaml | 49 > > ++++++++++++++++++++++ > > 1 file changed, 49 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/reserved-memory/carved-out.yaml > > b/Documentation/devicetree/bindings/reserved-memory/carved-out.yaml > > new file mode 100644 > > index > > 0000000000000000000000000000000000000000..9ab5d1ebd9ebd9111b7c064fabe1c45e752da83b > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/reserved-memory/carved-out.yaml > > @@ -0,0 +1,49 @@ > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/reserved-memory/carved-out.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Carved-out Memory Region > > + > > +description: | > > Don't need '|'. > > > + Specifies that the reserved memory region has been carved out of the > > + main memory allocator, and is intended to be used by the OS as a > > + dedicated memory allocator. > > Other than the commit msg, it is completely lost that this is for > ECC-less memory.
Because it's not. One of the first feedback I got was that the way to identify what a heap provides was the heap name. So, as far as the binding go, a heap just exposes a chunk of memory the memory allocator wouldn't use. The actual semantics of that chunk of memory don't matter. > This description applies to CMA area as well. So what's the difference? Yeah, I kind of agree, which is why I initially started with a property, and you then asked for a compatible. CMA (assuming you mean the allocator, not the CMA heap) is still more though: it only covers some shared-dma-pool memory regions. > > + > > +maintainers: > > + - Maxime Ripard <[email protected]> > > + > > +properties: > > + compatible: > > + const: carved-out > > Isn't everything in reserved-memory a carve out for some purpose. I'm > not sure if I'd add 'no ECC' or more along the lines of how this is > used. The latter might be useful on platforms which can't disable ECC or > don't have ECC at all. I don't think we need any discriminant for ECC vs non-ECC. It's just a carved-out memory region at some offset, and the system won't use it. Maxime
signature.asc
Description: PGP signature
