Message ID | 20230530233643.4044823-2-quic_bjorande@quicinc.com |
---|---|
State | New |
Headers | show |
Series | soc: qcom: rmtfs: Support dynamic allocation | expand |
On Tue, May 30, 2023 at 04:36:41PM -0700, Bjorn Andersson wrote: > On some Qualcomm platforms it's required that the rmtfs memory is not > placed adjacent to allocations performed by other clients. Some > DeviceTree authors have solved this by reserving the space around > the region, but this prevents such author to use rely on the OS to place > the region, through the use of "size" (instead of a fixed location). > > So introduce a flag to indicate that guard pages should be carved at the > beginning and end of the memory region. The user shall account for the > two 4k blocks in the defined size. > > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> > --- > > Changes since v1: > - Drop qcom,alloc-size in favour of using reserved-memory/size > - Introduce explicit property to signal that guard pages should be > carved out from this region (rather than always do it in the dynamic > case). > > .../bindings/reserved-memory/qcom,rmtfs-mem.yaml | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml > index bab982f00485..26e24e7b08cf 100644 > --- a/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml > +++ b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml > @@ -26,6 +26,13 @@ properties: > description: > > identifier of the client to use this region for buffers > > + qcom,use-guard-pages: > + type: boolean > + description: > > + Indicates that the OS should ignore the first and last 4k block of the > + memory region, for the purpose of ensuring that the allocation is not > + adjacent to other protected regions. > + The name "page(s)" is kind of ambiguous nowadays given that systems are configured with a variety of page sizes other than 4k. I wonder if it would be more clear to add the actual size of the guard pages to the device tree, e.g. rmtfs { compatible = "qcom,rmtfs-mem"; size = <(2*1024*1024 + 2*4096)>; qcom,guard-size = <4096>; }; This could also handle a different padding - in the unlikely case that this is needed on some platform... It's probably also fine the way you added it though, this is just a random thought I had. :) Thanks, Stephan
On 31/05/2023 01:36, Bjorn Andersson wrote: > On some Qualcomm platforms it's required that the rmtfs memory is not > placed adjacent to allocations performed by other clients. Some > DeviceTree authors have solved this by reserving the space around > the region, but this prevents such author to use rely on the OS to place > the region, through the use of "size" (instead of a fixed location). > > So introduce a flag to indicate that guard pages should be carved at the > beginning and end of the memory region. The user shall account for the > two 4k blocks in the defined size. > > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> > --- > > Changes since v1: > - Drop qcom,alloc-size in favour of using reserved-memory/size > - Introduce explicit property to signal that guard pages should be > carved out from this region (rather than always do it in the dynamic > case). > > .../bindings/reserved-memory/qcom,rmtfs-mem.yaml | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml > index bab982f00485..26e24e7b08cf 100644 > --- a/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml > +++ b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml > @@ -26,6 +26,13 @@ properties: > description: > > identifier of the client to use this region for buffers > > + qcom,use-guard-pages: > + type: boolean > + description: > > + Indicates that the OS should ignore the first and last 4k block of the > + memory region, for the purpose of ensuring that the allocation is not > + adjacent to other protected regions. Property name and description: do not describe the OS behavior. Describe the hardware or firmware. Describe the actual problem or characteristic which will be then interpreted by OS to do what you want. DT is not for instructing OS what to do. Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml index bab982f00485..26e24e7b08cf 100644 --- a/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml +++ b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml @@ -26,6 +26,13 @@ properties: description: > identifier of the client to use this region for buffers + qcom,use-guard-pages: + type: boolean + description: > + Indicates that the OS should ignore the first and last 4k block of the + memory region, for the purpose of ensuring that the allocation is not + adjacent to other protected regions. + qcom,vmid: $ref: /schemas/types.yaml#/definitions/uint32-array description: >
On some Qualcomm platforms it's required that the rmtfs memory is not placed adjacent to allocations performed by other clients. Some DeviceTree authors have solved this by reserving the space around the region, but this prevents such author to use rely on the OS to place the region, through the use of "size" (instead of a fixed location). So introduce a flag to indicate that guard pages should be carved at the beginning and end of the memory region. The user shall account for the two 4k blocks in the defined size. Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> --- Changes since v1: - Drop qcom,alloc-size in favour of using reserved-memory/size - Introduce explicit property to signal that guard pages should be carved out from this region (rather than always do it in the dynamic case). .../bindings/reserved-memory/qcom,rmtfs-mem.yaml | 7 +++++++ 1 file changed, 7 insertions(+)