@@ -52,6 +52,18 @@ properties:
Address and Length pairs. Specifies regions of memory that are
acceptable to allocate from.
+ alloc-bottom-up:
+ type: boolean
+ description: >
+ Specifies that the memory region should be preferably allocated
+ at the lowest available address within the "alloc-ranges" region.
+
+ alloc-top-down:
+ type: boolean
+ description: >
+ Specifies that the memory region should be preferably allocated
+ at the highest available address within the "alloc-ranges" region.
+
iommu-addresses:
$ref: /schemas/types.yaml#/definitions/phandle-array
description: >
@@ -93,6 +105,10 @@ properties:
system can use that region to store volatile or cached data that
can be otherwise regenerated or migrated elsewhere.
+dependencies:
+ alloc-bottom-up: [alloc-ranges]
+ alloc-top-down: [alloc-ranges]
+
allOf:
- if:
required:
@@ -178,4 +194,27 @@ examples:
};
};
};
+
+ - |
+ / {
+ compatible = "foo";
+ model = "foo";
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ adsp_mem: adsp {
+ size = <0x0 0x600000>;
+ alignment = <0x0 0x100000>;
+ alloc-ranges = <0x0 0x86800000 0x0 0x10000000>;
+ alloc-bottom-up;
+ no-map;
+ };
+ };
+ };
...
Right now the allocation behavior for dynamic reserved memory is implementation-defined. On Linux it is dependent on the architecture. This is usually fine if the address is completely arbitrary. However, when using "alloc-ranges" it is helpful to allow controlling this. That way you can make sure that the reservations are placed next to other (static) allocations to keep the free memory contiguous if possible. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> --- .../bindings/reserved-memory/reserved-memory.yaml | 39 ++++++++++++++++++++++ 1 file changed, 39 insertions(+)