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 <mripard@kernel.org>
---
.../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: |
+ 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.
+
+maintainers:
+ - Maxime Ripard <mripard@kernel.org>
+
+properties:
+ compatible:
+ const: carved-out
+
+ reg:
+ description: region of memory that is carved out.
+
+allOf:
+ - $ref: reserved-memory.yaml
+ - not:
+ required:
+ - reusable
+ - not:
+ required:
+ - no-map
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ memory@12340000 {
+ compatible = "carved-out";
+ reg = <0x12340000 0x00800000>;
+ };
+ };
--
2.49.0On 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 <mripard@kernel.org>
> ---
> .../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.
This description applies to CMA area as well. So what's the difference?
> +
> +maintainers:
> + - Maxime Ripard <mripard@kernel.org>
> +
> +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.
> +
> + reg:
> + description: region of memory that is carved out.
Can be multiple regions? If not, need 'maxItems: 1'.
> +
> +allOf:
> + - $ref: reserved-memory.yaml
> + - not:
> + required:
> + - reusable
> + - not:
> + required:
> + - no-map
> +
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + memory@12340000 {
> + compatible = "carved-out";
> + reg = <0x12340000 0x00800000>;
> + };
> + };
>
> --
> 2.49.0
>
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 <mripard@kernel.org> > > --- > > .../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 <mripard@kernel.org> > > + > > +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
On Mon, Jun 30, 2025 at 06:41:38PM +0200, Maxime Ripard wrote: > 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 <mripard@kernel.org> > > > --- > > > .../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. But they do because you use one carve out for one thing and another carve out for another purpose and they probably aren't interchangeable. For the most part, everything in /reserved-memory is a carve out from regular memory though we failed to enforce that. > > 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. My issues with properties is we have to support N factorial cases for combinations of N properties. It's already fragile. Whereas a compatible is (hopefully) well defined as to what's needed and is only 1 more case to support. Rob
On Mon, Jun 30, 2025 at 05:08:19PM -0500, Rob Herring wrote: > On Mon, Jun 30, 2025 at 06:41:38PM +0200, Maxime Ripard wrote: > > 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 <mripard@kernel.org> > > > > --- > > > > .../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. > > But they do because you use one carve out for one thing and another > carve out for another purpose and they probably aren't interchangeable. That was also my initial thought, but it was then discussed that the name of the region is enough of a discriminant. And it makes sense too, it's a sufficient discriminant for the device tree to uniquely identify a given memory region on a given platform already, so we don't really need anything else. > For the most part, everything in /reserved-memory is a carve out from > regular memory though we failed to enforce that. > > > > 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. > > My issues with properties is we have to support N factorial cases for > combinations of N properties. It's already fragile. Whereas a compatible > is (hopefully) well defined as to what's needed and is only 1 more case > to support. I think that's also what John especially wanted to avoid. If we have a generic compatible, but the attributes/properties/whatever of the buffers allocated from that region differ (like ecc vs non-ecc, protected vs non-protected, etc.) we will need properties in the device tree to describe them too. Maxime
Hi Rob, On Tue, Jul 01, 2025 at 09:12:18AM +0200, Maxime Ripard wrote: > On Mon, Jun 30, 2025 at 05:08:19PM -0500, Rob Herring wrote: > > On Mon, Jun 30, 2025 at 06:41:38PM +0200, Maxime Ripard wrote: > > > 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 <mripard@kernel.org> > > > > > --- > > > > > .../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. > > > > But they do because you use one carve out for one thing and another > > carve out for another purpose and they probably aren't interchangeable. > > That was also my initial thought, but it was then discussed that the > name of the region is enough of a discriminant. And it makes sense too, > it's a sufficient discriminant for the device tree to uniquely identify > a given memory region on a given platform already, so we don't really > need anything else. > > > For the most part, everything in /reserved-memory is a carve out from > > regular memory though we failed to enforce that. > > > > > > 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. > > > > My issues with properties is we have to support N factorial cases for > > combinations of N properties. It's already fragile. Whereas a compatible > > is (hopefully) well defined as to what's needed and is only 1 more case > > to support. > > I think that's also what John especially wanted to avoid. If we have a > generic compatible, but the attributes/properties/whatever of the > buffers allocated from that region differ (like ecc vs non-ecc, > protected vs non-protected, etc.) we will need properties in the device > tree to describe them too. I thought about it some more over the weekend, but if a compatible isn't a great solution either, would it make sense to just create a heap for each shared-dma-pool region, and thus we just wouldn't need any extra compatible or property? Maxime
© 2016 - 2026 Red Hat, Inc.