Tightly-Coupled Memories(TCMs) are low-latency memory that provides
predictable instruction execution and predictable data load/store
timing. Each Cortex-R5F processor contains exclusive two 64 KB memory
banks on the ATCM and BTCM ports, for a total of 128 KB of memory.
In lockstep mode, both 128KB memory is accessible to the cluster.
As per ZynqMP Ultrascale+ Technical Reference Manual UG1085, following
is address space of TCM memory. The bindings in this patch series
introduces properties to accommodate following address space with
address translation between Linux and Cortex-R5 views.
| | | |
| --- | --- | --- |
| *Mode* | *R5 View* | *Linux view* | Notes |
| *Split Mode* | *start addr*| *start addr* | |
| R5_0 ATCM (64 KB) | 0x0000_0000 | 0xFFE0_0000 | |
| R5_0 BTCM (64 KB) | 0x0002_0000 | 0xFFE2_0000 | |
| R5_1 ATCM (64 KB) | 0x0000_0000 | 0xFFE9_0000 | alias of 0xFFE1_0000 |
| R5_1 BTCM (64 KB) | 0x0002_0000 | 0xFFEB_0000 | alias of 0xFFE3_0000 |
| ___ | ___ | ___ | |
| *Lockstep Mode* | | | |
| R5_0 ATCM (128 KB) | 0x0000_0000 | 0xFFE0_0000 | |
| R5_0 BTCM (128 KB) | 0x0002_0000 | 0xFFE2_0000 | |
References:
UG1085 TCM address space:
https://docs.xilinx.com/r/en-US/ug1085-zynq-ultrascale-trm/Tightly-Coupled-Memory-Address-Map
Changes in v12:
- add "reg", "reg-names" and "power-domains" in pattern properties
- add "reg" and "reg-names" in required list
- keep "power-domains" in required list as it was before the change
Changes in v11:
- Fix yamllint warning and reduce indentation as needed
- Remove redundant initialization of the variable
- Return correct error code if memory allocation failed
Changs in v10:
- Add new patch (1/4) to series that changes hardcode TCM addresses in
lockstep mode and removes separate handling of TCM in lockstep and
split mode
- modify number of "reg", "reg-names" and "power-domains" entries
based on cluster mode
- Add extra optional atcm and btcm in "reg" property for lockstep mode
- Add "reg-names" for extra optional atcm and btcm for lockstep mode
- Drop previous Ack as bindings has new change
- Add individual tcm regions via "reg" and "reg-names" for lockstep mode
- Add each tcm's power-domains in lockstep mode
- Drop previous Ack as new change in dts patchset
- Remove redundant changes in driver to handle TCM in lockstep mode
Changes in v9:
- Fix rproc lockstep dts
- Introduce new API to request and release core1 TCM power-domains in
lockstep mode. This will be used during prepare -> add_tcm_banks
callback to enable TCM in lockstep mode.
- Parse TCM from device-tree in lockstep mode and split mode in
uniform way.
- Fix TCM representation in device-tree in lockstep mode.
- Fix comments as suggested
Changes in v8:
- Remove use of pm_domains framework
- Remove checking of pm_domain_id validation to power on/off tcm
- Remove spurious change
- parse power-domains property from device-tree and use EEMI calls
to power on/off TCM instead of using pm domains framework
Changes in v7:
- %s/pm_dev1/pm_dev_core0/r
- %s/pm_dev_link1/pm_dev_core0_link/r
- %s/pm_dev2/pm_dev_core1/r
- %s/pm_dev_link2/pm_dev_core1_link/r
- remove pm_domain_id check to move next patch
- add comment about how 1st entry in pm domain list is used
- fix loop when jump to fail_add_pm_domains loop
- move checking of pm_domain_id from previous patch
- fix mem_bank_data memory allocation
Changes in v6:
- Introduce new node entry for r5f cluster split mode dts and
keep it disabled by default.
- Keep remoteproc lockstep mode enabled by default to maintian
back compatibility.
- Enable split mode only for zcu102 board to demo split mode use
- Remove spurious change
- Handle errors in add_pm_domains function
- Remove redundant code to handle errors from remove_pm_domains
- Missing . at the end of the commit message
- remove redundant initialization of variables
- remove fail_tcm label and relevant code to free memory
acquired using devm_* API. As this will be freed when device free it
- add extra check to see if "reg" property is supported or not
Changes in v5:
- maintain Rob's Ack on bindings patch as no changes in bindings
- split previous patch into multiple patches
- Use pm domain framework to turn on/off TCM
- Add support of parsing TCM information from device-tree
- maintain backward compatibility with previous bindings without
TCM information available in device-tree
This patch series continues previous effort to upstream ZynqMP
TCM bindings:
Previous v4 version link:
https://lore.kernel.org/all/[email protected]/
Previous v3 version link:
https://lore.kernel.org/all/[email protected]/
Radhey Shyam Pandey (1):
dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings
Radhey Shyam Pandey (1):
dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings
Tanmay Shah (3):
remoteproc: zynqmp: fix lockstep mode memory region
dts: zynqmp: add properties for TCM in remoteproc
remoteproc: zynqmp: parse TCM from device tree
.../remoteproc/xlnx,zynqmp-r5fss.yaml | 188 +++++++++++--
.../boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts | 8 +
arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 65 ++++-
drivers/remoteproc/xlnx_r5_remoteproc.c | 257 ++++++++----------
4 files changed, 355 insertions(+), 163 deletions(-)
base-commit: b401b621758e46812da61fa58a67c3fd8d91de0d
--
2.25.1
Add properties as per new bindings in zynqmp remoteproc node
to represent TCM address and size.
This patch also adds alternative remoteproc node to represent
remoteproc cluster in split mode. By default lockstep mode is
enabled and users should disable it before using split mode
dts. Both device-tree nodes can't be used simultaneously one
of them must be disabled. For zcu102-1.0 and zcu102-1.1 board
remoteproc split mode dts node is enabled and lockstep mode
dts is disabled.
Signed-off-by: Tanmay Shah <[email protected]>
---
.../boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts | 8 +++
arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 65 +++++++++++++++++--
2 files changed, 68 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
index c8f71a1aec89..495ca94b45db 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
@@ -14,6 +14,14 @@ / {
compatible = "xlnx,zynqmp-zcu102-rev1.0", "xlnx,zynqmp-zcu102", "xlnx,zynqmp";
};
+&rproc_split {
+ status = "okay";
+};
+
+&rproc_lockstep {
+ status = "disabled";
+};
+
&eeprom {
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
index eaba466804bc..c8a7fd0f3a1e 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -248,19 +248,74 @@ fpga_full: fpga-full {
ranges;
};
- remoteproc {
+ rproc_lockstep: remoteproc@ffe00000 {
compatible = "xlnx,zynqmp-r5fss";
xlnx,cluster-mode = <1>;
- r5f-0 {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ranges = <0x0 0x0 0x0 0xffe00000 0x0 0x10000>,
+ <0x0 0x20000 0x0 0xffe20000 0x0 0x10000>,
+ <0x0 0x10000 0x0 0xffe10000 0x0 0x10000>,
+ <0x0 0x30000 0x0 0xffe30000 0x0 0x10000>;
+
+ r5f@0 {
+ compatible = "xlnx,zynqmp-r5f";
+ reg = <0x0 0x0 0x0 0x10000>,
+ <0x0 0x20000 0x0 0x10000>,
+ <0x0 0x10000 0x0 0x10000>,
+ <0x0 0x30000 0x0 0x10000>;
+ reg-names = "atcm0", "btcm0", "atcm1", "btcm1";
+ power-domains = <&zynqmp_firmware PD_RPU_0>,
+ <&zynqmp_firmware PD_R5_0_ATCM>,
+ <&zynqmp_firmware PD_R5_0_BTCM>,
+ <&zynqmp_firmware PD_R5_1_ATCM>,
+ <&zynqmp_firmware PD_R5_1_BTCM>;
+ memory-region = <&rproc_0_fw_image>;
+ };
+
+ r5f@1 {
+ compatible = "xlnx,zynqmp-r5f";
+ reg = <0x1 0x0 0x0 0x10000>, <0x1 0x20000 0x0 0x10000>;
+ reg-names = "atcm0", "btcm0";
+ power-domains = <&zynqmp_firmware PD_RPU_1>,
+ <&zynqmp_firmware PD_R5_1_ATCM>,
+ <&zynqmp_firmware PD_R5_1_BTCM>;
+ memory-region = <&rproc_1_fw_image>;
+ };
+ };
+
+ rproc_split: remoteproc-split@ffe00000 {
+ status = "disabled";
+ compatible = "xlnx,zynqmp-r5fss";
+ xlnx,cluster-mode = <0>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ranges = <0x0 0x0 0x0 0xffe00000 0x0 0x10000>,
+ <0x0 0x20000 0x0 0xffe20000 0x0 0x10000>,
+ <0x1 0x0 0x0 0xffe90000 0x0 0x10000>,
+ <0x1 0x20000 0x0 0xffeb0000 0x0 0x10000>;
+
+ r5f@0 {
compatible = "xlnx,zynqmp-r5f";
- power-domains = <&zynqmp_firmware PD_RPU_0>;
+ reg = <0x0 0x0 0x0 0x10000>, <0x0 0x20000 0x0 0x10000>;
+ reg-names = "atcm0", "btcm0";
+ power-domains = <&zynqmp_firmware PD_RPU_0>,
+ <&zynqmp_firmware PD_R5_0_ATCM>,
+ <&zynqmp_firmware PD_R5_0_BTCM>;
memory-region = <&rproc_0_fw_image>;
};
- r5f-1 {
+ r5f@1 {
compatible = "xlnx,zynqmp-r5f";
- power-domains = <&zynqmp_firmware PD_RPU_1>;
+ reg = <0x1 0x0 0x0 0x10000>, <0x1 0x20000 0x0 0x10000>;
+ reg-names = "atcm0", "btcm0";
+ power-domains = <&zynqmp_firmware PD_RPU_1>,
+ <&zynqmp_firmware PD_R5_1_ATCM>,
+ <&zynqmp_firmware PD_R5_1_BTCM>;
memory-region = <&rproc_1_fw_image>;
};
};
--
2.25.1
From: Radhey Shyam Pandey <[email protected]>
Introduce bindings for TCM memory address space on AMD-xilinx Zynq
UltraScale+ platform. It will help in defining TCM in device-tree
and make it's access platform agnostic and data-driven.
Tightly-coupled memories(TCMs) are low-latency memory that provides
predictable instruction execution and predictable data load/store
timing. Each Cortex-R5F processor contains two 64-bit wide 64 KB memory
banks on the ATCM and BTCM ports, for a total of 128 KB of memory.
The TCM resources(reg, reg-names and power-domain) are documented for
each TCM in the R5 node. The reg and reg-names are made as required
properties as we don't want to hardcode TCM addresses for future
platforms and for zu+ legacy implementation will ensure that the
old dts w/o reg/reg-names works and stable ABI is maintained.
It also extends the examples for TCM split and lockstep modes.
Signed-off-by: Radhey Shyam Pandey <[email protected]>
Signed-off-by: Tanmay Shah <[email protected]>
---
Changes in v12:
- add "reg", "reg-names" and "power-domains" in pattern properties
- add "reg" and "reg-names" in required list
- keep "power-domains" in required list as it was before the change
Changes in v11:
- Fix yamllint warning and reduce indentation as needed
.../remoteproc/xlnx,zynqmp-r5fss.yaml | 188 ++++++++++++++++--
1 file changed, 168 insertions(+), 20 deletions(-)
diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
index 78aac69f1060..dc6ce308688f 100644
--- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
@@ -20,9 +20,21 @@ properties:
compatible:
const: xlnx,zynqmp-r5fss
+ "#address-cells":
+ const: 2
+
+ "#size-cells":
+ const: 2
+
+ ranges:
+ description: |
+ Standard ranges definition providing address translations for
+ local R5F TCM address spaces to bus addresses.
+
xlnx,cluster-mode:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2]
+ default: 1
description: |
The RPU MPCore can operate in split mode (Dual-processor performance), Safety
lock-step mode(Both RPU cores execute the same code in lock-step,
@@ -37,7 +49,7 @@ properties:
2: single cpu mode
patternProperties:
- "^r5f-[a-f0-9]+$":
+ "^r5f@[0-9a-f]+$":
type: object
description: |
The RPU is located in the Low Power Domain of the Processor Subsystem.
@@ -54,8 +66,17 @@ patternProperties:
compatible:
const: xlnx,zynqmp-r5f
+ reg:
+ minItems: 1
+ maxItems: 4
+
+ reg-names:
+ minItems: 1
+ maxItems: 4
+
power-domains:
- maxItems: 1
+ minItems: 2
+ maxItems: 5
mboxes:
minItems: 1
@@ -101,35 +122,162 @@ patternProperties:
required:
- compatible
+ - reg
+ - reg-names
- power-domains
- unevaluatedProperties: false
-
required:
- compatible
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+
+allOf:
+ - if:
+ properties:
+ xlnx,cluster-mode:
+ enum:
+ - 1
+ then:
+ patternProperties:
+ "^r5f@[0-9a-f]+$":
+ type: object
+
+ properties:
+ reg:
+ minItems: 1
+ items:
+ - description: ATCM internal memory
+ - description: BTCM internal memory
+ - description: extra ATCM memory in lockstep mode
+ - description: extra BTCM memory in lockstep mode
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: atcm0
+ - const: btcm0
+ - const: atcm1
+ - const: btcm1
+
+ else:
+ patternProperties:
+ "^r5f@[0-9a-f]+$":
+ type: object
+
+ properties:
+ reg:
+ minItems: 1
+ items:
+ - description: ATCM internal memory
+ - description: BTCM internal memory
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: atcm0
+ - const: btcm0
+
+ power-domains:
+ maxItems: 3
additionalProperties: false
examples:
- |
- remoteproc {
- compatible = "xlnx,zynqmp-r5fss";
- xlnx,cluster-mode = <1>;
-
- r5f-0 {
- compatible = "xlnx,zynqmp-r5f";
- power-domains = <&zynqmp_firmware 0x7>;
- memory-region = <&rproc_0_fw_image>, <&rpu0vdev0buffer>, <&rpu0vdev0vring0>, <&rpu0vdev0vring1>;
- mboxes = <&ipi_mailbox_rpu0 0>, <&ipi_mailbox_rpu0 1>;
- mbox-names = "tx", "rx";
+ #include <dt-bindings/power/xlnx-zynqmp-power.h>
+
+ // Split mode configuration
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ remoteproc@ffe00000 {
+ compatible = "xlnx,zynqmp-r5fss";
+ xlnx,cluster-mode = <0>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0x0 0x0 0x0 0xffe00000 0x0 0x10000>,
+ <0x0 0x20000 0x0 0xffe20000 0x0 0x10000>,
+ <0x1 0x0 0x0 0xffe90000 0x0 0x10000>,
+ <0x1 0x20000 0x0 0xffeb0000 0x0 0x10000>;
+
+ r5f@0 {
+ compatible = "xlnx,zynqmp-r5f";
+ reg = <0x0 0x0 0x0 0x10000>, <0x0 0x20000 0x0 0x10000>;
+ reg-names = "atcm0", "btcm0";
+ power-domains = <&zynqmp_firmware PD_RPU_0>,
+ <&zynqmp_firmware PD_R5_0_ATCM>,
+ <&zynqmp_firmware PD_R5_0_BTCM>;
+ memory-region = <&rproc_0_fw_image>, <&rpu0vdev0buffer>,
+ <&rpu0vdev0vring0>, <&rpu0vdev0vring1>;
+ mboxes = <&ipi_mailbox_rpu0 0>, <&ipi_mailbox_rpu0 1>;
+ mbox-names = "tx", "rx";
+ };
+
+ r5f@1 {
+ compatible = "xlnx,zynqmp-r5f";
+ reg = <0x1 0x0 0x0 0x10000>, <0x1 0x20000 0x0 0x10000>;
+ reg-names = "atcm0", "btcm0";
+ power-domains = <&zynqmp_firmware PD_RPU_1>,
+ <&zynqmp_firmware PD_R5_1_ATCM>,
+ <&zynqmp_firmware PD_R5_1_BTCM>;
+ memory-region = <&rproc_1_fw_image>, <&rpu1vdev0buffer>,
+ <&rpu1vdev0vring0>, <&rpu1vdev0vring1>;
+ mboxes = <&ipi_mailbox_rpu1 0>, <&ipi_mailbox_rpu1 1>;
+ mbox-names = "tx", "rx";
+ };
};
+ };
+
+ - |
+ //Lockstep configuration
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ remoteproc@ffe00000 {
+ compatible = "xlnx,zynqmp-r5fss";
+ xlnx,cluster-mode = <1>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0x0 0x0 0x0 0xffe00000 0x0 0x10000>,
+ <0x0 0x20000 0x0 0xffe20000 0x0 0x10000>,
+ <0x0 0x10000 0x0 0xffe10000 0x0 0x10000>,
+ <0x0 0x30000 0x0 0xffe30000 0x0 0x10000>;
+
+ r5f@0 {
+ compatible = "xlnx,zynqmp-r5f";
+ reg = <0x0 0x0 0x0 0x10000>,
+ <0x0 0x20000 0x0 0x10000>,
+ <0x0 0x10000 0x0 0x10000>,
+ <0x0 0x30000 0x0 0x10000>;
+ reg-names = "atcm0", "btcm0", "atcm1", "btcm1";
+ power-domains = <&zynqmp_firmware PD_RPU_0>,
+ <&zynqmp_firmware PD_R5_0_ATCM>,
+ <&zynqmp_firmware PD_R5_0_BTCM>,
+ <&zynqmp_firmware PD_R5_1_ATCM>,
+ <&zynqmp_firmware PD_R5_1_BTCM>;
+ memory-region = <&rproc_0_fw_image>, <&rpu0vdev0buffer>,
+ <&rpu0vdev0vring0>, <&rpu0vdev0vring1>;
+ mboxes = <&ipi_mailbox_rpu0 0>, <&ipi_mailbox_rpu0 1>;
+ mbox-names = "tx", "rx";
+ };
- r5f-1 {
- compatible = "xlnx,zynqmp-r5f";
- power-domains = <&zynqmp_firmware 0x8>;
- memory-region = <&rproc_1_fw_image>, <&rpu1vdev0buffer>, <&rpu1vdev0vring0>, <&rpu1vdev0vring1>;
- mboxes = <&ipi_mailbox_rpu1 0>, <&ipi_mailbox_rpu1 1>;
- mbox-names = "tx", "rx";
+ r5f@1 {
+ compatible = "xlnx,zynqmp-r5f";
+ reg = <0x1 0x0 0x0 0x10000>, <0x1 0x20000 0x0 0x10000>;
+ reg-names = "atcm0", "btcm0";
+ power-domains = <&zynqmp_firmware PD_RPU_1>,
+ <&zynqmp_firmware PD_R5_1_ATCM>,
+ <&zynqmp_firmware PD_R5_1_BTCM>;
+ memory-region = <&rproc_1_fw_image>, <&rpu1vdev0buffer>,
+ <&rpu1vdev0vring0>, <&rpu1vdev0vring1>;
+ mboxes = <&ipi_mailbox_rpu1 0>, <&ipi_mailbox_rpu1 1>;
+ mbox-names = "tx", "rx";
+ };
};
};
...
--
2.25.1
On 01/03/2024 19:16, Tanmay Shah wrote:
> From: Radhey Shyam Pandey <[email protected]>
>
> Introduce bindings for TCM memory address space on AMD-xilinx Zynq
> UltraScale+ platform. It will help in defining TCM in device-tree
> and make it's access platform agnostic and data-driven.
>
> Tightly-coupled memories(TCMs) are low-latency memory that provides
> predictable instruction execution and predictable data load/store
> timing. Each Cortex-R5F processor contains two 64-bit wide 64 KB memory
> banks on the ATCM and BTCM ports, for a total of 128 KB of memory.
>
> The TCM resources(reg, reg-names and power-domain) are documented for
> each TCM in the R5 node. The reg and reg-names are made as required
> properties as we don't want to hardcode TCM addresses for future
> platforms and for zu+ legacy implementation will ensure that the
> old dts w/o reg/reg-names works and stable ABI is maintained.
>
> It also extends the examples for TCM split and lockstep modes.
>
> Signed-off-by: Radhey Shyam Pandey <[email protected]>
> Signed-off-by: Tanmay Shah <[email protected]>
> ---
>
> Changes in v12:
> - add "reg", "reg-names" and "power-domains" in pattern properties
> - add "reg" and "reg-names" in required list
> - keep "power-domains" in required list as it was before the change
>
> Changes in v11:
> - Fix yamllint warning and reduce indentation as needed
>
> .../remoteproc/xlnx,zynqmp-r5fss.yaml | 188 ++++++++++++++++--
> 1 file changed, 168 insertions(+), 20 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
> index 78aac69f1060..dc6ce308688f 100644
> --- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
> @@ -20,9 +20,21 @@ properties:
> compatible:
> const: xlnx,zynqmp-r5fss
>
> + "#address-cells":
> + const: 2
> +
> + "#size-cells":
> + const: 2
> +
> + ranges:
> + description: |
> + Standard ranges definition providing address translations for
> + local R5F TCM address spaces to bus addresses.
> +
> xlnx,cluster-mode:
> $ref: /schemas/types.yaml#/definitions/uint32
> enum: [0, 1, 2]
> + default: 1
> description: |
> The RPU MPCore can operate in split mode (Dual-processor performance), Safety
> lock-step mode(Both RPU cores execute the same code in lock-step,
> @@ -37,7 +49,7 @@ properties:
> 2: single cpu mode
>
> patternProperties:
> - "^r5f-[a-f0-9]+$":
> + "^r5f@[0-9a-f]+$":
> type: object
> description: |
> The RPU is located in the Low Power Domain of the Processor Subsystem.
> @@ -54,8 +66,17 @@ patternProperties:
> compatible:
> const: xlnx,zynqmp-r5f
>
> + reg:
> + minItems: 1
> + maxItems: 4
> +
> + reg-names:
> + minItems: 1
> + maxItems: 4
> +
> power-domains:
> - maxItems: 1
> + minItems: 2
> + maxItems: 5
>
> mboxes:
> minItems: 1
> @@ -101,35 +122,162 @@ patternProperties:
>
> required:
> - compatible
> + - reg
> + - reg-names
> - power-domains
>
> - unevaluatedProperties: false
> -
> required:
> - compatible
> + - "#address-cells"
> + - "#size-cells"
> + - ranges
> +
> +allOf:
> + - if:
> + properties:
> + xlnx,cluster-mode:
> + enum:
> + - 1
> + then:
> + patternProperties:
> + "^r5f@[0-9a-f]+$":
> + type: object
> +
> + properties:
> + reg:
> + minItems: 1
> + items:
> + - description: ATCM internal memory
> + - description: BTCM internal memory
> + - description: extra ATCM memory in lockstep mode
> + - description: extra BTCM memory in lockstep mode
> +
> + reg-names:
> + minItems: 1
> + items:
> + - const: atcm0
> + - const: btcm0
> + - const: atcm1
> + - const: btcm1
Why power domains are flexible?
> +
> + else:
> + patternProperties:
> + "^r5f@[0-9a-f]+$":
> + type: object
> +
> + properties:
> + reg:
> + minItems: 1
> + items:
> + - description: ATCM internal memory
> + - description: BTCM internal memory
> +
> + reg-names:
> + minItems: 1
> + items:
> + - const: atcm0
> + - const: btcm0
> +
> + power-domains:
> + maxItems: 3
Please list power domains.
>
> additionalProperties: false
Best regards,
Krzysztof
Hello Krzysztof,
Thanks for reviews. Please find my comments below.
On 3/9/24 7:25 AM, Krzysztof Kozlowski wrote:
> On 01/03/2024 19:16, Tanmay Shah wrote:
> > From: Radhey Shyam Pandey <[email protected]>
> >
> > Introduce bindings for TCM memory address space on AMD-xilinx Zynq
> > UltraScale+ platform. It will help in defining TCM in device-tree
> > and make it's access platform agnostic and data-driven.
> >
> > Tightly-coupled memories(TCMs) are low-latency memory that provides
> > predictable instruction execution and predictable data load/store
> > timing. Each Cortex-R5F processor contains two 64-bit wide 64 KB memory
> > banks on the ATCM and BTCM ports, for a total of 128 KB of memory.
> >
> > The TCM resources(reg, reg-names and power-domain) are documented for
> > each TCM in the R5 node. The reg and reg-names are made as required
> > properties as we don't want to hardcode TCM addresses for future
> > platforms and for zu+ legacy implementation will ensure that the
> > old dts w/o reg/reg-names works and stable ABI is maintained.
> >
> > It also extends the examples for TCM split and lockstep modes.
> >
> > Signed-off-by: Radhey Shyam Pandey <[email protected]>
> > Signed-off-by: Tanmay Shah <[email protected]>
> > ---
> >
> > Changes in v12:
> > - add "reg", "reg-names" and "power-domains" in pattern properties
> > - add "reg" and "reg-names" in required list
> > - keep "power-domains" in required list as it was before the change
> >
> > Changes in v11:
> > - Fix yamllint warning and reduce indentation as needed
> >
> > .../remoteproc/xlnx,zynqmp-r5fss.yaml | 188 ++++++++++++++++--
> > 1 file changed, 168 insertions(+), 20 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
> > index 78aac69f1060..dc6ce308688f 100644
> > --- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
> > +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
> > @@ -20,9 +20,21 @@ properties:
> > compatible:
> > const: xlnx,zynqmp-r5fss
> >
> > + "#address-cells":
> > + const: 2
> > +
> > + "#size-cells":
> > + const: 2
> > +
> > + ranges:
> > + description: |
> > + Standard ranges definition providing address translations for
> > + local R5F TCM address spaces to bus addresses.
> > +
> > xlnx,cluster-mode:
> > $ref: /schemas/types.yaml#/definitions/uint32
> > enum: [0, 1, 2]
> > + default: 1
> > description: |
> > The RPU MPCore can operate in split mode (Dual-processor performance), Safety
> > lock-step mode(Both RPU cores execute the same code in lock-step,
> > @@ -37,7 +49,7 @@ properties:
> > 2: single cpu mode
> >
> > patternProperties:
> > - "^r5f-[a-f0-9]+$":
> > + "^r5f@[0-9a-f]+$":
> > type: object
> > description: |
> > The RPU is located in the Low Power Domain of the Processor Subsystem.
> > @@ -54,8 +66,17 @@ patternProperties:
> > compatible:
> > const: xlnx,zynqmp-r5f
> >
> > + reg:
> > + minItems: 1
> > + maxItems: 4
> > +
> > + reg-names:
> > + minItems: 1
> > + maxItems: 4
> > +
> > power-domains:
> > - maxItems: 1
> > + minItems: 2
> > + maxItems: 5
> >
> > mboxes:
> > minItems: 1
> > @@ -101,35 +122,162 @@ patternProperties:
> >
> > required:
> > - compatible
> > + - reg
> > + - reg-names
> > - power-domains
> >
> > - unevaluatedProperties: false
> > -
> > required:
> > - compatible
> > + - "#address-cells"
> > + - "#size-cells"
> > + - ranges
> > +
> > +allOf:
> > + - if:
> > + properties:
> > + xlnx,cluster-mode:
> > + enum:
> > + - 1
> > + then:
> > + patternProperties:
> > + "^r5f@[0-9a-f]+$":
> > + type: object
> > +
> > + properties:
> > + reg:
> > + minItems: 1
> > + items:
> > + - description: ATCM internal memory
> > + - description: BTCM internal memory
> > + - description: extra ATCM memory in lockstep mode
> > + - description: extra BTCM memory in lockstep mode
> > +
> > + reg-names:
> > + minItems: 1
> > + items:
> > + - const: atcm0
> > + - const: btcm0
> > + - const: atcm1
> > + - const: btcm1
>
> Why power domains are flexible?
User may not want to use all the TCMs. For example, if users want to turn-on only TCM-A and rest of them want to keep off, then
they can avoid having power-domains of other TCMs in the device-tree. This helps with less power-consumption when needed.
Hence flexible list of power-domains list.
I can certainly mention "items:" under power-domains property.
>
> > +
> > + else:
> > + patternProperties:
> > + "^r5f@[0-9a-f]+$":
> > + type: object
> > +
> > + properties:
> > + reg:
> > + minItems: 1
> > + items:
> > + - description: ATCM internal memory
> > + - description: BTCM internal memory
> > +
> > + reg-names:
> > + minItems: 1
> > + items:
> > + - const: atcm0
> > + - const: btcm0
> > +
> > + power-domains:
> > + maxItems: 3
>
> Please list power domains.
Okay. But minItems will be still what's mentioned above i.e. 2.
I hope it's fine.
>
> >
> > additionalProperties: false
>
>
> Best regards,
> Krzysztof
>
On 3/9/24 7:25 AM, Krzysztof Kozlowski wrote:
> On 01/03/2024 19:16, Tanmay Shah wrote:
> > From: Radhey Shyam Pandey <[email protected]>
> >
> > Introduce bindings for TCM memory address space on AMD-xilinx Zynq
> > UltraScale+ platform. It will help in defining TCM in device-tree
> > and make it's access platform agnostic and data-driven.
> >
> > Tightly-coupled memories(TCMs) are low-latency memory that provides
> > predictable instruction execution and predictable data load/store
> > timing. Each Cortex-R5F processor contains two 64-bit wide 64 KB memory
> > banks on the ATCM and BTCM ports, for a total of 128 KB of memory.
> >
> > The TCM resources(reg, reg-names and power-domain) are documented for
> > each TCM in the R5 node. The reg and reg-names are made as required
> > properties as we don't want to hardcode TCM addresses for future
> > platforms and for zu+ legacy implementation will ensure that the
> > old dts w/o reg/reg-names works and stable ABI is maintained.
> >
> > It also extends the examples for TCM split and lockstep modes.
> >
> > Signed-off-by: Radhey Shyam Pandey <[email protected]>
> > Signed-off-by: Tanmay Shah <[email protected]>
> > ---
> >
> > Changes in v12:
> > - add "reg", "reg-names" and "power-domains" in pattern properties
> > - add "reg" and "reg-names" in required list
> > - keep "power-domains" in required list as it was before the change
> >
> > Changes in v11:
> > - Fix yamllint warning and reduce indentation as needed
> >
> > .../remoteproc/xlnx,zynqmp-r5fss.yaml | 188 ++++++++++++++++--
> > 1 file changed, 168 insertions(+), 20 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
> > index 78aac69f1060..dc6ce308688f 100644
> > --- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
> > +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
> > @@ -20,9 +20,21 @@ properties:
> > compatible:
> > const: xlnx,zynqmp-r5fss
> >
> > + "#address-cells":
> > + const: 2
> > +
> > + "#size-cells":
> > + const: 2
> > +
> > + ranges:
> > + description: |
> > + Standard ranges definition providing address translations for
> > + local R5F TCM address spaces to bus addresses.
> > +
> > xlnx,cluster-mode:
> > $ref: /schemas/types.yaml#/definitions/uint32
> > enum: [0, 1, 2]
> > + default: 1
> > description: |
> > The RPU MPCore can operate in split mode (Dual-processor performance), Safety
> > lock-step mode(Both RPU cores execute the same code in lock-step,
> > @@ -37,7 +49,7 @@ properties:
> > 2: single cpu mode
> >
> > patternProperties:
> > - "^r5f-[a-f0-9]+$":
> > + "^r5f@[0-9a-f]+$":
> > type: object
> > description: |
> > The RPU is located in the Low Power Domain of the Processor Subsystem.
> > @@ -54,8 +66,17 @@ patternProperties:
> > compatible:
> > const: xlnx,zynqmp-r5f
> >
> > + reg:
> > + minItems: 1
> > + maxItems: 4
> > +
> > + reg-names:
> > + minItems: 1
> > + maxItems: 4
> > +
> > power-domains:
> > - maxItems: 1
> > + minItems: 2
> > + maxItems: 5
> >
> > mboxes:
> > minItems: 1
> > @@ -101,35 +122,162 @@ patternProperties:
> >
> > required:
> > - compatible
> > + - reg
> > + - reg-names
> > - power-domains
> >
> > - unevaluatedProperties: false
> > -
> > required:
> > - compatible
> > + - "#address-cells"
> > + - "#size-cells"
> > + - ranges
> > +
> > +allOf:
> > + - if:
> > + properties:
> > + xlnx,cluster-mode:
> > + enum:
> > + - 1
> > + then:
> > + patternProperties:
> > + "^r5f@[0-9a-f]+$":
> > + type: object
> > +
> > + properties:
> > + reg:
> > + minItems: 1
> > + items:
> > + - description: ATCM internal memory
> > + - description: BTCM internal memory
> > + - description: extra ATCM memory in lockstep mode
> > + - description: extra BTCM memory in lockstep mode
> > +
> > + reg-names:
> > + minItems: 1
> > + items:
> > + - const: atcm0
> > + - const: btcm0
> > + - const: atcm1
> > + - const: btcm1
>
> Why power domains are flexible?
>
> > +
> > + else:
> > + patternProperties:
> > + "^r5f@[0-9a-f]+$":
> > + type: object
> > +
> > + properties:
> > + reg:
> > + minItems: 1
> > + items:
> > + - description: ATCM internal memory
> > + - description: BTCM internal memory
> > +
> > + reg-names:
> > + minItems: 1
> > + items:
> > + - const: atcm0
> > + - const: btcm0
> > +
> > + power-domains:
> > + maxItems: 3
>
> Please list power domains.
Hello,
Sent v13 addressing both comments.
Thanks.
> >
> > additionalProperties: false
>
>
> Best regards,
> Krzysztof
>
On 11/03/2024 19:39, Tanmay Shah wrote:
>>> +
>>> + else:
>>> + patternProperties:
>>> + "^r5f@[0-9a-f]+$":
>>> + type: object
>>> +
>>> + properties:
>>> + reg:
>>> + minItems: 1
>>> + items:
>>> + - description: ATCM internal memory
>>> + - description: BTCM internal memory
>>> +
>>> + reg-names:
>>> + minItems: 1
>>> + items:
>>> + - const: atcm0
>>> + - const: btcm0
>>> +
>>> + power-domains:
>>> + maxItems: 3
>>
>> Please list power domains.
>
> Hello,
>
> Sent v13 addressing both comments.
>
And gave me exactly two hours to disagree?
Best regards,
Krzysztof
On 11/03/2024 17:27, Tanmay Shah wrote:
>>> + then:
>>> + patternProperties:
>>> + "^r5f@[0-9a-f]+$":
>>> + type: object
>>> +
>>> + properties:
>>> + reg:
>>> + minItems: 1
>>> + items:
>>> + - description: ATCM internal memory
>>> + - description: BTCM internal memory
>>> + - description: extra ATCM memory in lockstep mode
>>> + - description: extra BTCM memory in lockstep mode
>>> +
>>> + reg-names:
>>> + minItems: 1
>>> + items:
>>> + - const: atcm0
>>> + - const: btcm0
>>> + - const: atcm1
>>> + - const: btcm1
>>
>> Why power domains are flexible?
>
> User may not want to use all the TCMs. For example, if users want to turn-on only TCM-A and rest of them want to keep off, then
>
> they can avoid having power-domains of other TCMs in the device-tree. This helps with less power-consumption when needed.
>
> Hence flexible list of power-domains list.
>
Isn't turning on/off driver's job? Sorry, but what is "user" here? DTS
describes bindings, not OS policy.
Also, please wrap your replies to match email style.
> I can certainly mention "items:" under power-domains property.
>
>
>>
Best regards,
Krzysztof
On 3/12/24 7:10 AM, Krzysztof Kozlowski wrote:
> On 11/03/2024 19:39, Tanmay Shah wrote:
> >>> +
> >>> + else:
> >>> + patternProperties:
> >>> + "^r5f@[0-9a-f]+$":
> >>> + type: object
> >>> +
> >>> + properties:
> >>> + reg:
> >>> + minItems: 1
> >>> + items:
> >>> + - description: ATCM internal memory
> >>> + - description: BTCM internal memory
> >>> +
> >>> + reg-names:
> >>> + minItems: 1
> >>> + items:
> >>> + - const: atcm0
> >>> + - const: btcm0
> >>> +
> >>> + power-domains:
> >>> + maxItems: 3
> >>
> >> Please list power domains.
> >
> > Hello,
> >
> > Sent v13 addressing both comments.
> >
>
> And gave me exactly two hours to disagree?
I am sorry, I thought I was addressing the right comments.
It was minor change tempted me to push new revision, will wait longer next time.
>
> Best regards,
> Krzysztof
>
On 3/12/24 7:10 AM, Krzysztof Kozlowski wrote:
> On 11/03/2024 17:27, Tanmay Shah wrote:
> >>> + then:
> >>> + patternProperties:
> >>> + "^r5f@[0-9a-f]+$":
> >>> + type: object
> >>> +
> >>> + properties:
> >>> + reg:
> >>> + minItems: 1
> >>> + items:
> >>> + - description: ATCM internal memory
> >>> + - description: BTCM internal memory
> >>> + - description: extra ATCM memory in lockstep mode
> >>> + - description: extra BTCM memory in lockstep mode
> >>> +
> >>> + reg-names:
> >>> + minItems: 1
> >>> + items:
> >>> + - const: atcm0
> >>> + - const: btcm0
> >>> + - const: atcm1
> >>> + - const: btcm1
> >>
> >> Why power domains are flexible?
> >
> > User may not want to use all the TCMs. For example, if users want to turn-on only TCM-A and rest of them want to keep off, then
> >
> > they can avoid having power-domains of other TCMs in the device-tree. This helps with less power-consumption when needed.
> >
> > Hence flexible list of power-domains list.
> >
>
> Isn't turning on/off driver's job? Sorry, but what is "user" here? DTS
> describes bindings, not OS policy.
Thanks for reviews.
Correct driver turns on off TCM. However, system designers (users) have option
to not include TCM that is not needed in device-tree. So
power-domains are flexible, same as reg, and reg-names. ATCM is always
needed as vector table is in ATCM. R5 core power domain and ATCM
power-domain for each core is always required so minItems 2.
> Also, please wrap your replies to match email style.
>
> > I can certainly mention "items:" under power-domains property.
> >
> >
> >>
>
>
> Best regards,
> Krzysztof
>