Re: [PATCH v8 2/3] dts: zynqmp: add properties for TCM in remoteproc

[Tanmay Shah]

On 1/3/24 11:54 AM, Mathieu Poirier wrote:
> Hi Tanmay,
>
> On Fri, Dec 15, 2023 at 03:57:24PM -0800, Tanmay Shah wrote:
> > 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 
> > ---
> >  .../boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts  |  8 +++
> >  arch/arm64/boot/dts/xilinx/zynqmp.dtsi| 60 +--
> >  2 files changed, 63 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 b61fc99cd911..602e6aba7ac5 100644
> > --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> > +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> > @@ -247,19 +247,69 @@ fpga_full: fpga-full {
> > ranges;
> > };
> >  
> > -   remoteproc {
> > +   rproc_lockstep: remoteproc@ffe0 {
> > compatible = "xlnx,zynqmp-r5fss";
> > xlnx,cluster-mode = <1>;
> >  
> > -   r5f-0 {
> > +   #address-cells = <2>;
> > +   #size-cells = <2>;
> > +
> > +   ranges = <0x0 0x0 0x0 0xffe0 0x0 0x2>,
> > +<0x0 0x2 0x0 0xffe2 0x0 0x2>,
> > +<0x1 0x0 0x0 0xffe9 0x0 0x1>,
> > +<0x1 0x2 0x0 0xffeb 0x0 0x1>;
>
> As far as I can tell, in lockstep mode the last two entries are not needed.
> This is also contrasting with that is in the bindings, which is quite 
> confusing.

Hi Mathieu,

Yes I agree. I think it should be same as of bindings example.

However, I will have to test and make sure no impact on driver. I will fix it 
in next revision.

Meanwhile, are you going to review driver changes as well or do you want to 
wait for next revision ?

Tanmay


> > +
> > +   r5f@0 {
> > +   compatible = "xlnx,zynqmp-r5f";
> > +   reg = <0x0 0x0 0x0 0x2>, <0x0 0x2 0x0 0x2>;
> > +   reg-names = "atcm", "btcm";
> > +   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 {
> > +   compatible = "xlnx,zynqmp-r5f";
> > +   reg = <0x1 0x0 0x0 0x1>, <0x1 0x2 0x0 0x1>;
> > +   reg-names = "atcm", "btcm";
> > +   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@ffe0 {
> > +   status = "disabled";
> > +   compatible = "xlnx,zynqmp-r5fss";
> > +   xlnx,cluster-mode = <0>;
> > +
> > +   #address-cells = <2>;
> > +   #size-cell

Re: [PATCH v8 3/3] remoteproc: zynqmp: parse TCM from device tree

[Tanmay Shah]

On 1/3/24 12:17 PM, Mathieu Poirier wrote:
> On Fri, Dec 15, 2023 at 03:57:25PM -0800, Tanmay Shah wrote:
> > ZynqMP TCM information is fixed in driver. Now ZynqMP TCM information
>
> s/"is fixed in driver"/"was fixed in driver"
>
> > is available in device-tree. Parse TCM information in driver
> > as per new bindings.
> > 
> > Signed-off-by: Tanmay Shah 
> > ---
> > 
> > Changes in v8:
> >   - parse power-domains property from device-tree and use EEMI calls
> > to power on/off TCM instead of using pm domains framework
> >   - Remove checking of pm_domain_id validation to power on/off tcm
> >   - Remove spurious change
> > 
> > Changes in v7:
> >   - move checking of pm_domain_id from previous patch
> >   - fix mem_bank_data memory allocation
> > 
> >  drivers/remoteproc/xlnx_r5_remoteproc.c | 154 +++-
> >  1 file changed, 148 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
> > b/drivers/remoteproc/xlnx_r5_remoteproc.c
> > index 4395edea9a64..36d73dcd93f0 100644
> > --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> > +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> > @@ -74,8 +74,8 @@ struct mbox_info {
> >  };
> >  
> >  /*
> > - * Hardcoded TCM bank values. This will be removed once TCM bindings are
> > - * accepted for system-dt specifications and upstreamed in linux kernel
> > + * Hardcoded TCM bank values. This will stay in driver to maintain backward
> > + * compatibility with device-tree that does not have TCM information.
> >   */
> >  static const struct mem_bank_data zynqmp_tcm_banks_split[] = {
> > {0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each 
> > */
> > @@ -878,6 +878,139 @@ static struct zynqmp_r5_core 
> > *zynqmp_r5_add_rproc_core(struct device *cdev)
> > return ERR_PTR(ret);
> >  }
> >  
> > +static int zynqmp_r5_get_tcm_node_from_dt(struct zynqmp_r5_cluster 
> > *cluster)
> > +{
> > +   struct of_phandle_args out_args;
> > +   int tcm_reg_per_r5, tcm_pd_idx;
> > +   struct zynqmp_r5_core *r5_core;
> > +   int i, j, tcm_bank_count, ret;
> > +   struct platform_device *cpdev;
> > +   struct mem_bank_data *tcm;
> > +   struct device_node *np;
> > +   struct resource *res;
> > +   u64 abs_addr, size;
> > +   struct device *dev;
> > +
> > +   for (i = 0; i < cluster->core_count; i++) {
> > +   r5_core = cluster->r5_cores[i];
> > +   dev = r5_core->dev;
> > +   np = of_node_get(dev_of_node(dev));
> > +   tcm_pd_idx = 1;
> > +
> > +   /* we have address cell 2 and size cell as 2 */
> > +   tcm_reg_per_r5 = of_property_count_elems_of_size(np, "reg",
> > +4 * 
> > sizeof(u32));
> > +   if (tcm_reg_per_r5 <= 0) {
> > +   dev_err(dev, "can't get reg property err %d\n", 
> > tcm_reg_per_r5);
> > +   return -EINVAL;
> > +   }
> > +
> > +   /*
> > +* In lockstep mode, r5 core 0 will use r5 core 1 TCM
> > +* power domains as well. so allocate twice of per core TCM
>
> Twice of what?  Please use proper english in your multi line comments, i.e a
> capital letter for the first word and a dot at the end.  
>
> > +*/
> > +   if (cluster->mode == LOCKSTEP_MODE)
> > +   tcm_bank_count = tcm_reg_per_r5 * 2;
> > +   else
> > +   tcm_bank_count = tcm_reg_per_r5;
> > +
> > +   r5_core->tcm_banks = devm_kcalloc(dev, tcm_bank_count,
> > + sizeof(struct mem_bank_data 
> > *),
> > + GFP_KERNEL);
> > +   if (!r5_core->tcm_banks)
> > +   ret = -ENOMEM;
> > +
> > +   r5_core->tcm_bank_count = tcm_bank_count;
> > +   for (j = 0; j < tcm_bank_count; j++) {
> > +   tcm = devm_kzalloc(dev, sizeof(struct mem_bank_data),
> > +  GFP_KERNEL);
> > +   if (!tcm)
> > +   return -ENOMEM;
> > +
> > +   r5_core->tcm_banks[j] = tcm;
> > +
> > +   /*
> > +* In lockstep mode, get

[PATCH v4 0/2] remoteproc: get rproc devices for clusters

[Tanmay Shah]

This series extends original patch and makes rproc_put() work
for clusters along with rprog_get_by_phandle().

Changes in v4:
  - Retrieve cluster device using rproc->dev.parent->parent relation

Changes in v3:
  - remove module_put call that was introduced in the patch by mistake
  - remove redundant check in rproc_put
  - Add inline comments in rproc_put that explains functionality

Changes in v2:
  - Introduce patch to fix rproc_put as per modified rproc_get_by_phandle

v1: 
https://lore.kernel.org/all/20221214221643.1286585-1-mathieu.poir...@linaro.org/

Mathieu Poirier (1):
  remoteproc: Make rproc_get_by_phandle() work for clusters

Tanmay Shah (1):
  remoteproc: enhance rproc_put() for clusters

 drivers/remoteproc/remoteproc_core.c | 29 ++--
 1 file changed, 27 insertions(+), 2 deletions(-)


base-commit: ff9af5732fe761fa8e7aa66cb482f93a37e284ee
-- 
2.25.1

[PATCH v4 1/2] remoteproc: Make rproc_get_by_phandle() work for clusters

[Tanmay Shah]

From: Mathieu Poirier 

Multi-cluster remoteproc designs typically have the following DT
declaration:

remoteproc_cluster {
compatible = "soc,remoteproc-cluster";

core0: core0 {
compatible = "soc,remoteproc-core"
memory-region;
sram;
};

core1: core1 {
compatible = "soc,remoteproc-core"
memory-region;
sram;
}
};

A driver exists for the cluster rather than the individual cores
themselves so that operation mode and HW specific configurations
applicable to the cluster can be made.

Because the driver exists at the cluster level and not the individual
core level, function rproc_get_by_phandle() fails to return the
remoteproc associated with the phandled it is called for.

This patch enhances rproc_get_by_phandle() by looking for the cluster's
driver when the driver for the immediate remoteproc's parent is not
found.

Reported-by: Ben Levinsky 
Signed-off-by: Mathieu Poirier 
---
 drivers/remoteproc/remoteproc_core.c | 23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/remoteproc_core.c 
b/drivers/remoteproc/remoteproc_core.c
index 695cce218e8c..0b3b34085e2f 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2112,6 +2113,7 @@ EXPORT_SYMBOL(rproc_detach);
 struct rproc *rproc_get_by_phandle(phandle phandle)
 {
struct rproc *rproc = NULL, *r;
+   struct device_driver *driver;
struct device_node *np;
 
np = of_find_node_by_phandle(phandle);
@@ -2122,7 +2124,26 @@ struct rproc *rproc_get_by_phandle(phandle phandle)
list_for_each_entry_rcu(r, &rproc_list, node) {
if (r->dev.parent && device_match_of_node(r->dev.parent, np)) {
/* prevent underlying implementation from being removed 
*/
-   if (!try_module_get(r->dev.parent->driver->owner)) {
+
+   /*
+* If the remoteproc's parent has a driver, the
+* remoteproc is not part of a cluster and we can use
+* that driver.
+*/
+   driver = r->dev.parent->driver;
+
+   /*
+* If the remoteproc's parent does not have a driver,
+* look for the driver associated with the cluster.
+*/
+   if (!driver) {
+   if (r->dev.parent->parent)
+   driver = r->dev.parent->parent->driver;
+   if (!driver)
+   break;
+   }
+
+   if (!try_module_get(driver->owner)) {
dev_err(&r->dev, "can't get owner\n");
break;
}
-- 
2.25.1

[PATCH v4 2/2] remoteproc: enhance rproc_put() for clusters

[Tanmay Shah]

This patch enhances rproc_put() to support remoteproc clusters
with multiple child nodes as in rproc_get_by_phandle().

Signed-off-by: Tarak Reddy 
Signed-off-by: Tanmay Shah 
---
 drivers/remoteproc/remoteproc_core.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/remoteproc_core.c 
b/drivers/remoteproc/remoteproc_core.c
index 0b3b34085e2f..f276956f2c5c 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -2554,7 +2554,11 @@ EXPORT_SYMBOL(rproc_free);
  */
 void rproc_put(struct rproc *rproc)
 {
-   module_put(rproc->dev.parent->driver->owner);
+   if (rproc->dev.parent->driver)
+   module_put(rproc->dev.parent->driver->owner);
+   else
+   module_put(rproc->dev.parent->parent->driver->owner);
+
put_device(&rproc->dev);
 }
 EXPORT_SYMBOL(rproc_put);
-- 
2.25.1

Re: [PATCH v8 3/3] remoteproc: zynqmp: parse TCM from device tree

[Tanmay Shah]

On 1/3/24 12:17 PM, Mathieu Poirier wrote:
> On Fri, Dec 15, 2023 at 03:57:25PM -0800, Tanmay Shah wrote:
> > ZynqMP TCM information is fixed in driver. Now ZynqMP TCM information
>
> s/"is fixed in driver"/"was fixed in driver"
>
> > is available in device-tree. Parse TCM information in driver
> > as per new bindings.
> > 
> > Signed-off-by: Tanmay Shah 
> > ---
> > 
> > Changes in v8:
> >   - parse power-domains property from device-tree and use EEMI calls
> > to power on/off TCM instead of using pm domains framework
> >   - Remove checking of pm_domain_id validation to power on/off tcm
> >   - Remove spurious change
> > 
> > Changes in v7:
> >   - move checking of pm_domain_id from previous patch
> >   - fix mem_bank_data memory allocation
> > 
> >  drivers/remoteproc/xlnx_r5_remoteproc.c | 154 +++-
> >  1 file changed, 148 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
> > b/drivers/remoteproc/xlnx_r5_remoteproc.c
> > index 4395edea9a64..36d73dcd93f0 100644
> > --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> > +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> > @@ -74,8 +74,8 @@ struct mbox_info {
> >  };
> >  
> >  /*
> > - * Hardcoded TCM bank values. This will be removed once TCM bindings are
> > - * accepted for system-dt specifications and upstreamed in linux kernel
> > + * Hardcoded TCM bank values. This will stay in driver to maintain backward
> > + * compatibility with device-tree that does not have TCM information.
> >   */
> >  static const struct mem_bank_data zynqmp_tcm_banks_split[] = {
> > {0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each 
> > */
> > @@ -878,6 +878,139 @@ static struct zynqmp_r5_core 
> > *zynqmp_r5_add_rproc_core(struct device *cdev)
> > return ERR_PTR(ret);
> >  }
> >  
> > +static int zynqmp_r5_get_tcm_node_from_dt(struct zynqmp_r5_cluster 
> > *cluster)
> > +{
> > +   struct of_phandle_args out_args;
> > +   int tcm_reg_per_r5, tcm_pd_idx;
> > +   struct zynqmp_r5_core *r5_core;
> > +   int i, j, tcm_bank_count, ret;
> > +   struct platform_device *cpdev;
> > +   struct mem_bank_data *tcm;
> > +   struct device_node *np;
> > +   struct resource *res;
> > +   u64 abs_addr, size;
> > +   struct device *dev;
> > +
> > +   for (i = 0; i < cluster->core_count; i++) {
> > +   r5_core = cluster->r5_cores[i];
> > +   dev = r5_core->dev;
> > +   np = of_node_get(dev_of_node(dev));
> > +   tcm_pd_idx = 1;
> > +
> > +   /* we have address cell 2 and size cell as 2 */
> > +   tcm_reg_per_r5 = of_property_count_elems_of_size(np, "reg",
> > +4 * 
> > sizeof(u32));
> > +   if (tcm_reg_per_r5 <= 0) {
> > +   dev_err(dev, "can't get reg property err %d\n", 
> > tcm_reg_per_r5);
> > +   return -EINVAL;
> > +   }
> > +
> > +   /*
> > +* In lockstep mode, r5 core 0 will use r5 core 1 TCM
> > +* power domains as well. so allocate twice of per core TCM
>
> Twice of what?  Please use proper english in your multi line comments, i.e a
> capital letter for the first word and a dot at the end.  
>
> > +*/
> > +   if (cluster->mode == LOCKSTEP_MODE)
> > +   tcm_bank_count = tcm_reg_per_r5 * 2;
> > +   else
> > +   tcm_bank_count = tcm_reg_per_r5;
> > +
> > +   r5_core->tcm_banks = devm_kcalloc(dev, tcm_bank_count,
> > + sizeof(struct mem_bank_data 
> > *),
> > + GFP_KERNEL);
> > +   if (!r5_core->tcm_banks)
> > +   ret = -ENOMEM;
> > +
> > +   r5_core->tcm_bank_count = tcm_bank_count;
> > +   for (j = 0; j < tcm_bank_count; j++) {
> > +   tcm = devm_kzalloc(dev, sizeof(struct mem_bank_data),
> > +  GFP_KERNEL);
> > +   if (!tcm)
> > +   return -ENOMEM;
> > +
> > +   r5_core->tcm_banks[j] = tcm;
> > +
> > +   /*
> > +* In lockstep mode, get

[PATCH v9 1/3] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings

[Tanmay Shah]

From: Radhey Shyam Pandey 

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 
Signed-off-by: Tanmay Shah 
Acked-by: Rob Herring 
---
 .../remoteproc/xlnx,zynqmp-r5fss.yaml | 131 +++---
 1 file changed, 113 insertions(+), 18 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml 
b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
index 78aac69f1060..9ecd63ea1b38 100644
--- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
@@ -20,6 +20,17 @@ 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]
@@ -37,7 +48,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 +65,19 @@ patternProperties:
   compatible:
 const: xlnx,zynqmp-r5f
 
+  reg:
+items:
+  - description: ATCM internal memory region
+  - description: BTCM internal memory region
+
+  reg-names:
+items:
+  - const: atcm
+  - const: btcm
+
   power-domains:
-maxItems: 1
+minItems: 1
+maxItems: 3
 
   mboxes:
 minItems: 1
@@ -102,34 +124,107 @@ patternProperties:
 required:
   - compatible
   - power-domains
+  - reg
+  - reg-names
 
 unevaluatedProperties: false
 
 required:
   - compatible
+  - "#address-cells"
+  - "#size-cells"
+  - ranges
 
 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 
+
+//Split mode configuration
+soc {
+#address-cells = <2>;
+#size-cells = <2>;
+
+remoteproc@ffe0 {
+compatible = "xlnx,zynqmp-r5fss";
+xlnx,cluster-mode = <0>;
+
+#address-cells = <2>;
+#size-cells = <2>;
+ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+ <0x0 0x2 0x0 0xffe2 0x0 0x1>,
+ <0x1 0x0 0x0 0xffe9 0x0 0x1>,
+ <0x1 0x2 0x0 0xffeb 0x0 0x1>;
+
+r5f@0 {
+compatible = "xlnx,zynqmp-r5f";
+reg = <0x0 0x0 0x0 0x1>, <0x0 0x2 0x0 0x1>;
+reg-names = "atcm", "btcm";
+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 0x100

[PATCH v9 0/3] add zynqmp TCM bindings

[Tanmay Shah]

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)  | 0x_ | 0xFFE0_  |  |
| R5_0 BTCM (64 KB)  | 0x0002_ | 0xFFE2_  |  |
| R5_1 ATCM (64 KB)  | 0x_ | 0xFFE9_  | alias of 0xFFE1_ |
| R5_1 BTCM (64 KB)  | 0x0002_ | 0xFFEB_  | alias of 0xFFE3_ |
|  ___   | ___ |___   |  |
| *Lockstep Mode*| |  |  |
| R5_0 ATCM (128 KB) | 0x_ | 0xFFE0_  |  |
| R5_0 BTCM (128 KB) | 0x0002_ | 0xFFE2_  |  |

References:
UG1085 TCM address space:
https://docs.xilinx.com/r/en-US/ug1085-zynq-ultrascale-trm/Tightly-Coupled-Memory-Address-Map

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/20230829181900.2561194-1-tanmay.s...@amd.com/

Previous v3 version link:
https://lore.kernel.org/all/1689964908-22371-1-git-send-email-radhey.shyam.pan...@amd.com/
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 (2):
  dts: zynqmp: add properties for TCM in remoteproc
  remoteproc: zynqmp: parse TCM from device tree

 .../remoteproc/xlnx,zynqmp-r5fss.yaml | 131 --
 .../boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts  |   8 +
 arch/arm64/boot/dts/xilinx/zynqmp.dtsi|  58 -
 drivers/remoteproc/xlnx_r5_remoteproc.c   | 245 +-
 4 files changed, 413 insertions(+), 29 deletions(-)


base-commit: ff9af5732fe761fa8e7aa66cb482f93a37e284ee
-- 
2.25.1

[PATCH v9 2/3] dts: zynqmp: add properties for TCM in remoteproc

[Tanmay Shah]

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 
---

Changes in v9:
  - fix rproc lockstep dts


 .../boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts  |  8 +++
 arch/arm64/boot/dts/xilinx/zynqmp.dtsi| 58 +--
 2 files changed, 61 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 b61fc99cd911..cfdd1f68501f 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -247,19 +247,67 @@ fpga_full: fpga-full {
ranges;
};
 
-   remoteproc {
+   rproc_lockstep: remoteproc@ffe0 {
compatible = "xlnx,zynqmp-r5fss";
xlnx,cluster-mode = <1>;
 
-   r5f-0 {
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   ranges = <0x0 0x0 0x0 0xffe0 0x0 0x2>,
+<0x0 0x2 0x0 0xffe2 0x0 0x2>;
+
+   r5f@0 {
+   compatible = "xlnx,zynqmp-r5f";
+   reg = <0x0 0x0 0x0 0x2>, <0x0 0x2 0x0 0x2>;
+   reg-names = "atcm", "btcm";
+   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 {
+   compatible = "xlnx,zynqmp-r5f";
+   reg = <0x1 0x0 0x0 0x1>, <0x1 0x2 0x0 0x1>;
+   reg-names = "atcm", "btcm";
+   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@ffe0 {
+   status = "disabled";
+   compatible = "xlnx,zynqmp-r5fss";
+   xlnx,cluster-mode = <0>;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x1 0x0 0x0 0xffe9 0x0 0x1>,
+<0x1 0x2 0x0 0xffeb 0x0 0x1>;
+
+   r5f@0 {
compatible = "xlnx,zynqmp-r5f";
-   power-domains = <&zynqmp_firmware PD_RPU_0>;
+   reg = <0x0 0x0 0x0 0x1>, <0x0 0x2 0x0 0x1>;
+   reg-names = "atcm", "btcm";
+   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 0x1>, <0x1 0x2 0x0 0x1>;
+   reg-names = "atcm", "btcm";
+   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

[PATCH v9 3/3] remoteproc: zynqmp: parse TCM from device tree

[Tanmay Shah]

ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
is available in device-tree. Parse TCM information in driver
as per new bindings.

Signed-off-by: Tanmay Shah 
---

Changes in v9:
  - 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.

Changes in v8:
  - Remove 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:
  - move checking of pm_domain_id from previous patch
  - fix mem_bank_data memory allocation

 drivers/remoteproc/xlnx_r5_remoteproc.c | 245 +++-
 1 file changed, 239 insertions(+), 6 deletions(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 4395edea9a64..0f87b984850b 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -74,8 +74,8 @@ struct mbox_info {
 };
 
 /*
- * Hardcoded TCM bank values. This will be removed once TCM bindings are
- * accepted for system-dt specifications and upstreamed in linux kernel
+ * Hardcoded TCM bank values. This will stay in driver to maintain backward
+ * compatibility with device-tree that does not have TCM information.
  */
 static const struct mem_bank_data zynqmp_tcm_banks_split[] = {
{0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each 
*/
@@ -102,6 +102,7 @@ static const struct mem_bank_data 
zynqmp_tcm_banks_lockstep[] = {
  * @rproc: rproc handle
  * @pm_domain_id: RPU CPU power domain id
  * @ipi: pointer to mailbox information
+ * @lockstep_core1_np: second core's device_node to use in lockstep mode
  */
 struct zynqmp_r5_core {
struct device *dev;
@@ -111,6 +112,7 @@ struct zynqmp_r5_core {
struct rproc *rproc;
u32 pm_domain_id;
struct mbox_info *ipi;
+   struct device_node *lockstep_core1_np;
 };
 
 /**
@@ -539,6 +541,110 @@ static int tcm_mem_map(struct rproc *rproc,
return 0;
 }
 
+int request_core1_tcm_lockstep(struct rproc *rproc)
+{
+   struct zynqmp_r5_core *r5_core = rproc->priv;
+   struct of_phandle_args out_args = {0};
+   int ret, i, num_pd, pd_id, ret_err;
+   struct device_node *np;
+
+   np = r5_core->lockstep_core1_np;
+
+   /* Get number of power-domains */
+   num_pd = of_count_phandle_with_args(np, "power-domains",
+   "#power-domain-cells");
+   if (num_pd <= 0)
+   return -EINVAL;
+
+   /* Get individual power-domain id and enable TCM */
+   for (i = 1; i < num_pd; i++) {
+   ret = of_parse_phandle_with_args(np, "power-domains",
+"#power-domain-cells",
+i, &out_args);
+   if (ret) {
+   dev_warn(r5_core->dev,
+"failed to get tcm %d in power-domains list, 
ret %d\n",
+i, ret);
+   goto fail_request_core1_tcm;
+   }
+
+   pd_id = out_args.args[0];
+   of_node_put(out_args.np);
+
+   ret = zynqmp_pm_request_node(pd_id, 
ZYNQMP_PM_CAPABILITY_ACCESS, 0,
+ZYNQMP_PM_REQUEST_ACK_BLOCKING);
+   if (ret) {
+   dev_err(r5_core->dev, "failed to request TCM node 
0x%x\n",
+   pd_id);
+   goto fail_request_core1_tcm;
+   }
+   }
+
+   return 0;
+
+fail_request_core1_tcm:
+
+   /* Cache actual error to return later */
+   ret_err = ret;
+
+   /* Release previously requested TCM in case of failure */
+   while (--i > 0) {
+   ret = of_parse_phandle_with_args(np, "power-domains",
+"#power-domain-cells",
+i, &out_args);
+   if (ret)
+   return ret;
+   pd_id = out_args.args[0];
+   of_node_put(out_args.np);
+   zynqmp_pm_release_node(pd_id);
+   }
+
+   return ret_err;
+}
+
+void release_core1_tcm_lockstep(struct rproc *rproc)
+{
+   struct zynqmp_r5_core *r5_core = rproc->priv;
+   struct of_phandle_args out_args = {0};
+   struct zynqmp_r5_cluster *cluster;
+   int ret, i, num_pd, pd_id;
+   struct devic

Re: [PATCH v4 2/2] remoteproc: enhance rproc_put() for clusters

[Tanmay Shah]

On 1/26/24 11:38 AM, Bjorn Andersson wrote:
> On Wed, Jan 03, 2024 at 02:11:25PM -0800, Tanmay Shah wrote:
> > This patch enhances rproc_put() to support remoteproc clusters
> > with multiple child nodes as in rproc_get_by_phandle().
> > 
> > Signed-off-by: Tarak Reddy 
> > Signed-off-by: Tanmay Shah 
>
> As described in the first patch, this documents that Tarak first
> certified the origin of this patch, then you certify the origin as you
> handle the patch.
>
> But according to From: you're the author, so how could Tarak have
> certified the origin before you authored the patch?
>
> Either correct the author, or add Co-developed-by, if that's what
> happened.
>
> > ---
> >  drivers/remoteproc/remoteproc_core.c | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/remoteproc/remoteproc_core.c 
> > b/drivers/remoteproc/remoteproc_core.c
> > index 0b3b34085e2f..f276956f2c5c 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -2554,7 +2554,11 @@ EXPORT_SYMBOL(rproc_free);
> >   */
> >  void rproc_put(struct rproc *rproc)
> >  {
> > -   module_put(rproc->dev.parent->driver->owner);
> > +   if (rproc->dev.parent->driver)
> > +   module_put(rproc->dev.parent->driver->owner);
> > +   else
> > +   module_put(rproc->dev.parent->parent->driver->owner);
> > +
>
> This does however highlight a bug that was introduced by patch 1, please
> avoid this by squashing the two patches together (and use
> Co-developed-by as needed).

Thanks Bjorn for catching this. This change originally was developed by Tarak, 
but I sent upstream based on his patch so I missed

to update his name as author. I should update author name.

However, if we are going to squash this in first patch, then I think, first 
patch's author will stay as it is.

Following Action Item on me for v5:

1) Fix commit text in first patch.

2) Squash second patch in first.

3) Add my s-o-b signature after Mathieu's

4) Add Tarak's s-o-b as well. As he developed second patch.

Hope got it all.


Thanks,

Tanmay

>
> Regards,
> Bjorn
>
> > put_device(&rproc->dev);
> >  }
> >  EXPORT_SYMBOL(rproc_put);
> > -- 
> > 2.25.1
> > 

[PATCH v5] remoteproc: Make rproc_get_by_phandle() work for clusters

[Tanmay Shah]

From: Mathieu Poirier 

Multi-cluster remoteproc designs typically have the following DT
declaration:

remoteproc-cluster {
compatible = "soc,remoteproc-cluster";

core0: core0 {
compatible = "soc,remoteproc-core"
memory-region;
sram;
};

core1: core1 {
compatible = "soc,remoteproc-core"
memory-region;
sram;
}
};

A driver exists for the cluster rather than the individual cores
themselves so that operation mode and HW specific configurations
applicable to the cluster can be made.

Because the driver exists at the cluster level and not the individual
core level, function rproc_get_by_phandle() fails to return the
remoteproc associated with the phandled it is called for.

This patch enhances rproc_get_by_phandle() by looking for the cluster's
driver when the driver for the immediate remoteproc's parent is not
found.

Reported-by: Ben Levinsky 
Signed-off-by: Mathieu Poirier 
Co-developed-by: Tarak Reddy 
Signed-off-by: Tarak Reddy 
Co-developed-by: Tanmay Shah 
Signed-off-by: Tanmay Shah 
---
 drivers/remoteproc/remoteproc_core.c | 29 ++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/remoteproc_core.c 
b/drivers/remoteproc/remoteproc_core.c
index 695cce218e8c..f276956f2c5c 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2112,6 +2113,7 @@ EXPORT_SYMBOL(rproc_detach);
 struct rproc *rproc_get_by_phandle(phandle phandle)
 {
struct rproc *rproc = NULL, *r;
+   struct device_driver *driver;
struct device_node *np;
 
np = of_find_node_by_phandle(phandle);
@@ -2122,7 +2124,26 @@ struct rproc *rproc_get_by_phandle(phandle phandle)
list_for_each_entry_rcu(r, &rproc_list, node) {
if (r->dev.parent && device_match_of_node(r->dev.parent, np)) {
/* prevent underlying implementation from being removed 
*/
-   if (!try_module_get(r->dev.parent->driver->owner)) {
+
+   /*
+* If the remoteproc's parent has a driver, the
+* remoteproc is not part of a cluster and we can use
+* that driver.
+*/
+   driver = r->dev.parent->driver;
+
+   /*
+* If the remoteproc's parent does not have a driver,
+* look for the driver associated with the cluster.
+*/
+   if (!driver) {
+   if (r->dev.parent->parent)
+   driver = r->dev.parent->parent->driver;
+   if (!driver)
+   break;
+   }
+
+   if (!try_module_get(driver->owner)) {
dev_err(&r->dev, "can't get owner\n");
break;
}
@@ -2533,7 +2554,11 @@ EXPORT_SYMBOL(rproc_free);
  */
 void rproc_put(struct rproc *rproc)
 {
-   module_put(rproc->dev.parent->driver->owner);
+   if (rproc->dev.parent->driver)
+   module_put(rproc->dev.parent->driver->owner);
+   else
+   module_put(rproc->dev.parent->parent->driver->owner);
+
put_device(&rproc->dev);
 }
 EXPORT_SYMBOL(rproc_put);

base-commit: 99f59b148871dadb9104366e3d25b120a97f897b
-- 
2.25.1

Re: [PATCH v9 3/3] remoteproc: zynqmp: parse TCM from device tree

[Tanmay Shah]

On 1/17/24 12:58 PM, Mathieu Poirier wrote:
> Alright, I spent several hours looking at this patchset and the driver as a
> whole.  I certainly salute your efforts to heed my advice and make the code 
> less
> brittle but I'm afraid we are not there.

Hi Mathieu,

I am back from vacation. Started looking into this. Thanks for spending time on 
this and helping

to make clean design of the driver. Please find my comments below.

> See below for a different way to proceed.
>
> On Wed, Jan 10, 2024 at 01:35:05PM -0800, Tanmay Shah wrote:
> > ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
> > is available in device-tree. Parse TCM information in driver
> > as per new bindings.
> > 
> > Signed-off-by: Tanmay Shah 
> > ---
> > 
> > Changes in v9:
> >   - 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.
> > 
> > Changes in v8:
> >   - Remove 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:
> >   - move checking of pm_domain_id from previous patch
> >   - fix mem_bank_data memory allocation
> > 
> >  drivers/remoteproc/xlnx_r5_remoteproc.c | 245 +++-
> >  1 file changed, 239 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
> > b/drivers/remoteproc/xlnx_r5_remoteproc.c
> > index 4395edea9a64..0f87b984850b 100644
> > --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> > +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> > @@ -74,8 +74,8 @@ struct mbox_info {
> >  };
> >  
> >  /*
> > - * Hardcoded TCM bank values. This will be removed once TCM bindings are
> > - * accepted for system-dt specifications and upstreamed in linux kernel
> > + * Hardcoded TCM bank values. This will stay in driver to maintain backward
> > + * compatibility with device-tree that does not have TCM information.
> >   */
> >  static const struct mem_bank_data zynqmp_tcm_banks_split[] = {
> > {0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each 
> > */
> > @@ -102,6 +102,7 @@ static const struct mem_bank_data 
> > zynqmp_tcm_banks_lockstep[] = {
> >   * @rproc: rproc handle
> >   * @pm_domain_id: RPU CPU power domain id
> >   * @ipi: pointer to mailbox information
> > + * @lockstep_core1_np: second core's device_node to use in lockstep mode
> >   */
> >  struct zynqmp_r5_core {
> > struct device *dev;
> > @@ -111,6 +112,7 @@ struct zynqmp_r5_core {
> > struct rproc *rproc;
> > u32 pm_domain_id;
> > struct mbox_info *ipi;
> > +   struct device_node *lockstep_core1_np;
> >  };
> >  
> >  /**
> > @@ -539,6 +541,110 @@ static int tcm_mem_map(struct rproc *rproc,
> > return 0;
> >  }
> >  
> > +int request_core1_tcm_lockstep(struct rproc *rproc)
> > +{
> > +   struct zynqmp_r5_core *r5_core = rproc->priv;
> > +   struct of_phandle_args out_args = {0};
> > +   int ret, i, num_pd, pd_id, ret_err;
> > +   struct device_node *np;
> > +
> > +   np = r5_core->lockstep_core1_np;
> > +
> > +   /* Get number of power-domains */
> > +   num_pd = of_count_phandle_with_args(np, "power-domains",
> > +   "#power-domain-cells");
> > +   if (num_pd <= 0)
> > +   return -EINVAL;
> > +
> > +   /* Get individual power-domain id and enable TCM */
> > +   for (i = 1; i < num_pd; i++) {
> > +   ret = of_parse_phandle_with_args(np, "power-domains",
> > +"#power-domain-cells",
> > +i, &out_args);
> > +   if (ret) {
> > +   dev_warn(r5_core->dev,
> > +"failed to get tcm %d in power-domains list, 
> > ret %d\n",
> > +i, ret);
> > +   goto fail_request_core1_tcm;
> > +   }
> > +
> > +   pd_id = out_args.ar

[PATCH] remoteproc: zynqmp: fix lockstep mode memory region

[Tanmay Shah]

In lockstep mode, r5 core0 uses TCM of R5 core1. Following is lockstep
mode memory region as per hardware reference manual.

|  *TCM* |   *R5 View* | *Linux view* |
| R5_0 ATCM (128 KB) | 0x_ | 0xFFE0_  |
| R5_0 BTCM (128 KB) | 0x0002_ | 0xFFE2_  |

However, driver shouldn't model it as above because R5 core0 TCM and core1
TCM has different power-domains mapped to it.
Hence, TCM address space in lockstep mode should be modeled as 64KB
regions only where each region has its own power-domain as following:

|  *TCM* |   *R5 View* | *Linux view* |
| R5_0 ATCM0 (64 KB) | 0x_ | 0xFFE0_  |
| R5_0 BTCM0 (64 KB) | 0x0002_ | 0xFFE2_  |
| R5_0 ATCM1 (64 KB) | 0x0001_ | 0xFFE1_  |
| R5_0 BTCM1 (64 KB) | 0x0003_ | 0xFFE3_  |

This fix makes driver maintanance easy and makes design robust for future
platorms as well.

Fixes: 9af45bbdcbbb ("remoteproc: zynqmp: fix TCM carveouts in lockstep mode")
Signed-off-by: Tanmay Shah 
---
 drivers/remoteproc/xlnx_r5_remoteproc.c | 145 ++--
 1 file changed, 12 insertions(+), 133 deletions(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 4395edea9a64..42b0384d34f2 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -84,12 +84,12 @@ static const struct mem_bank_data zynqmp_tcm_banks_split[] 
= {
{0xffebUL, 0x2, 0x1UL, PD_R5_1_BTCM, "btcm1"},
 };
 
-/* In lockstep mode cluster combines each 64KB TCM and makes 128KB TCM */
+/* In lockstep mode cluster uses each 64KB TCM from second core as well */
 static const struct mem_bank_data zynqmp_tcm_banks_lockstep[] = {
-   {0xffe0UL, 0x0, 0x2UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 128KB 
each */
-   {0xffe2UL, 0x2, 0x2UL, PD_R5_0_BTCM, "btcm0"},
-   {0, 0, 0, PD_R5_1_ATCM, ""},
-   {0, 0, 0, PD_R5_1_BTCM, ""},
+   {0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each 
*/
+   {0xffe2UL, 0x2, 0x1UL, PD_R5_0_BTCM, "btcm0"},
+   {0xffe1UL, 0x1, 0x1UL, PD_R5_1_ATCM, "atcm1"},
+   {0xffe3UL, 0x3, 0x1UL, PD_R5_1_BTCM, "btcm1"},
 };
 
 /**
@@ -540,14 +540,14 @@ static int tcm_mem_map(struct rproc *rproc,
 }
 
 /*
- * add_tcm_carveout_split_mode()
+ * add_tcm_banks()
  * @rproc: single R5 core's corresponding rproc instance
  *
- * allocate and add remoteproc carveout for TCM memory in split mode
+ * allocate and add remoteproc carveout for TCM memory
  *
  * return 0 on success, otherwise non-zero value on failure
  */
-static int add_tcm_carveout_split_mode(struct rproc *rproc)
+static int add_tcm_banks(struct rproc *rproc)
 {
struct rproc_mem_entry *rproc_mem;
struct zynqmp_r5_core *r5_core;
@@ -580,10 +580,10 @@ static int add_tcm_carveout_split_mode(struct rproc 
*rproc)
 ZYNQMP_PM_REQUEST_ACK_BLOCKING);
if (ret < 0) {
dev_err(dev, "failed to turn on TCM 0x%x", 
pm_domain_id);
-   goto release_tcm_split;
+   goto release_tcm;
}
 
-   dev_dbg(dev, "TCM carveout split mode %s addr=%llx, da=0x%x, 
size=0x%lx",
+   dev_dbg(dev, "TCM carveout %s addr=%llx, da=0x%x, size=0x%lx",
bank_name, bank_addr, da, bank_size);
 
rproc_mem = rproc_mem_entry_init(dev, NULL, bank_addr,
@@ -593,7 +593,7 @@ static int add_tcm_carveout_split_mode(struct rproc *rproc)
if (!rproc_mem) {
ret = -ENOMEM;
zynqmp_pm_release_node(pm_domain_id);
-   goto release_tcm_split;
+   goto release_tcm;
}
 
rproc_add_carveout(rproc, rproc_mem);
@@ -601,7 +601,7 @@ static int add_tcm_carveout_split_mode(struct rproc *rproc)
 
return 0;
 
-release_tcm_split:
+release_tcm:
/* If failed, Turn off all TCM banks turned on before */
for (i--; i >= 0; i--) {
pm_domain_id = r5_core->tcm_banks[i]->pm_domain_id;
@@ -610,127 +610,6 @@ static int add_tcm_carveout_split_mode(struct rproc 
*rproc)
return ret;
 }
 
-/*
- * add_tcm_carveout_lockstep_mode()
- * @rproc: single R5 core's corresponding rproc instance
- *
- * allocate and add remoteproc carveout for TCM memory in lockstep mode
- *
- * return 0 on success, otherwise non-zero value on failure
- */
-static int add_tcm_carveout_lockstep_mode(struct rproc *rproc)
-{
-   struct rproc_mem_entry *rproc_mem;
-   struct zynqmp_r5_core *r5_core;
-   int i, num_banks, ret;
-   phys_addr_t bank_addr;
-   size_t bank_size = 

Re: [PATCH] remoteproc: zynqmp: fix lockstep mode memory region

[Tanmay Shah]

On 2/6/24 11:39 AM, Mathieu Poirier wrote:
> On Wed, Jan 31, 2024 at 04:48:12PM -0800, Tanmay Shah wrote:
> > In lockstep mode, r5 core0 uses TCM of R5 core1. Following is lockstep
> > mode memory region as per hardware reference manual.
> > 
> > |  *TCM* |   *R5 View* | *Linux view* |
> > | R5_0 ATCM (128 KB) | 0x_ | 0xFFE0_  |
> > | R5_0 BTCM (128 KB) | 0x0002_ | 0xFFE2_  |
> > 
> > However, driver shouldn't model it as above because R5 core0 TCM and core1
> > TCM has different power-domains mapped to it.
> > Hence, TCM address space in lockstep mode should be modeled as 64KB
> > regions only where each region has its own power-domain as following:
> > 
> > |  *TCM* |   *R5 View* | *Linux view* |
> > | R5_0 ATCM0 (64 KB) | 0x_ | 0xFFE0_  |
> > | R5_0 BTCM0 (64 KB) | 0x0002_ | 0xFFE2_  |
> > | R5_0 ATCM1 (64 KB) | 0x0001_ | 0xFFE1_  |
> > | R5_0 BTCM1 (64 KB) | 0x0003_ | 0xFFE3_  |
> > 
> > This fix makes driver maintanance easy and makes design robust for future
> > platorms as well.
> > 
> > Fixes: 9af45bbdcbbb ("remoteproc: zynqmp: fix TCM carveouts in lockstep 
> > mode")
>
> This patch doesn't fix a bug, i.e users won't see any changes once this patch
> gets applied.  As such there is no need for a "Fixes" tag.  When you resend 
> this
> patch (see below), please remove the line.

Ack.


> > Signed-off-by: Tanmay Shah 
> > ---
> >  drivers/remoteproc/xlnx_r5_remoteproc.c | 145 ++--
> >  1 file changed, 12 insertions(+), 133 deletions(-)
> >
>
> I am happy with this patch but won't apply it because I want to see what comes
> next.  Please include it in your next patchet.

Thanks. Sure, I will include this with zynqmp tcm bindings patch series.


> Reviewed-by: Mathieu Poirier 
>
> > diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
> > b/drivers/remoteproc/xlnx_r5_remoteproc.c
> > index 4395edea9a64..42b0384d34f2 100644
> > --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> > +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> > @@ -84,12 +84,12 @@ static const struct mem_bank_data 
> > zynqmp_tcm_banks_split[] = {
> > {0xffebUL, 0x2, 0x1UL, PD_R5_1_BTCM, "btcm1"},
> >  };
> >  
> > -/* In lockstep mode cluster combines each 64KB TCM and makes 128KB TCM */
> > +/* In lockstep mode cluster uses each 64KB TCM from second core as well */
> >  static const struct mem_bank_data zynqmp_tcm_banks_lockstep[] = {
> > -   {0xffe0UL, 0x0, 0x2UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 128KB 
> > each */
> > -   {0xffe2UL, 0x2, 0x2UL, PD_R5_0_BTCM, "btcm0"},
> > -   {0, 0, 0, PD_R5_1_ATCM, ""},
> > -   {0, 0, 0, PD_R5_1_BTCM, ""},
> > +   {0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each 
> > */
> > +   {0xffe2UL, 0x2, 0x1UL, PD_R5_0_BTCM, "btcm0"},
> > +   {0xffe1UL, 0x1, 0x1UL, PD_R5_1_ATCM, "atcm1"},
> > +   {0xffe3UL, 0x3, 0x1UL, PD_R5_1_BTCM, "btcm1"},
> >  };
> >  
> >  /**
> > @@ -540,14 +540,14 @@ static int tcm_mem_map(struct rproc *rproc,
> >  }
> >  
> >  /*
> > - * add_tcm_carveout_split_mode()
> > + * add_tcm_banks()
> >   * @rproc: single R5 core's corresponding rproc instance
> >   *
> > - * allocate and add remoteproc carveout for TCM memory in split mode
> > + * allocate and add remoteproc carveout for TCM memory
> >   *
> >   * return 0 on success, otherwise non-zero value on failure
> >   */
> > -static int add_tcm_carveout_split_mode(struct rproc *rproc)
> > +static int add_tcm_banks(struct rproc *rproc)
> >  {
> > struct rproc_mem_entry *rproc_mem;
> > struct zynqmp_r5_core *r5_core;
> > @@ -580,10 +580,10 @@ static int add_tcm_carveout_split_mode(struct rproc 
> > *rproc)
> >  ZYNQMP_PM_REQUEST_ACK_BLOCKING);
> > if (ret < 0) {
> > dev_err(dev, "failed to turn on TCM 0x%x", 
> > pm_domain_id);
> > -   goto release_tcm_split;
> > +   goto release_tcm;
> > }
> >  
> > -   dev_dbg(dev, "TCM carveout split mode %s addr=%llx, da=0x%x, 
> > size=0x%lx",
> > +   dev_dbg(dev, "TCM carveout %s addr=%llx, da=0x%x, size=0x%lx",
> >

Re: [PATCH v5] remoteproc: Make rproc_get_by_phandle() work for clusters

[Tanmay Shah]

Rejected-by: Tanmay Shah 

I will send new v5 with change long included.

On 1/30/24 9:48 AM, Tanmay Shah wrote:
> From: Mathieu Poirier 
>
> Multi-cluster remoteproc designs typically have the following DT
> declaration:
>
> remoteproc-cluster {
> compatible = "soc,remoteproc-cluster";
>
> core0: core0 {
> compatible = "soc,remoteproc-core"
> memory-region;
> sram;
> };
>
> core1: core1 {
> compatible = "soc,remoteproc-core"
> memory-region;
> sram;
> }
> };
>
> A driver exists for the cluster rather than the individual cores
> themselves so that operation mode and HW specific configurations
> applicable to the cluster can be made.
>
> Because the driver exists at the cluster level and not the individual
> core level, function rproc_get_by_phandle() fails to return the
> remoteproc associated with the phandled it is called for.
>
> This patch enhances rproc_get_by_phandle() by looking for the cluster's
> driver when the driver for the immediate remoteproc's parent is not
> found.
>
> Reported-by: Ben Levinsky 
> Signed-off-by: Mathieu Poirier 
> Co-developed-by: Tarak Reddy 
> Signed-off-by: Tarak Reddy 
> Co-developed-by: Tanmay Shah 
> Signed-off-by: Tanmay Shah 
> ---
>  drivers/remoteproc/remoteproc_core.c | 29 ++--
>  1 file changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index 695cce218e8c..f276956f2c5c 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -33,6 +33,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -2112,6 +2113,7 @@ EXPORT_SYMBOL(rproc_detach);
>  struct rproc *rproc_get_by_phandle(phandle phandle)
>  {
>   struct rproc *rproc = NULL, *r;
> + struct device_driver *driver;
>   struct device_node *np;
>  
>   np = of_find_node_by_phandle(phandle);
> @@ -2122,7 +2124,26 @@ struct rproc *rproc_get_by_phandle(phandle phandle)
>   list_for_each_entry_rcu(r, &rproc_list, node) {
>   if (r->dev.parent && device_match_of_node(r->dev.parent, np)) {
>   /* prevent underlying implementation from being removed 
> */
> - if (!try_module_get(r->dev.parent->driver->owner)) {
> +
> + /*
> +  * If the remoteproc's parent has a driver, the
> +  * remoteproc is not part of a cluster and we can use
> +  * that driver.
> +  */
> + driver = r->dev.parent->driver;
> +
> + /*
> +  * If the remoteproc's parent does not have a driver,
> +  * look for the driver associated with the cluster.
> +  */
> + if (!driver) {
> + if (r->dev.parent->parent)
> + driver = r->dev.parent->parent->driver;
> + if (!driver)
> + break;
> + }
> +
> + if (!try_module_get(driver->owner)) {
>   dev_err(&r->dev, "can't get owner\n");
>   break;
>   }
> @@ -2533,7 +2554,11 @@ EXPORT_SYMBOL(rproc_free);
>   */
>  void rproc_put(struct rproc *rproc)
>  {
> - module_put(rproc->dev.parent->driver->owner);
> + if (rproc->dev.parent->driver)
> + module_put(rproc->dev.parent->driver->owner);
> + else
> + module_put(rproc->dev.parent->parent->driver->owner);
> +
>   put_device(&rproc->dev);
>  }
>  EXPORT_SYMBOL(rproc_put);
>
> base-commit: 99f59b148871dadb9104366e3d25b120a97f897b

Re: [PATCH v5] remoteproc: Make rproc_get_by_phandle() work for clusters

[Tanmay Shah]

I am sorry, I missed the fact that this patch was picked up and available on 
for-next branch.

Won't be sending new one now.

Thanks,

Tanmay

On 2/7/24 4:18 PM, Tanmay Shah wrote:
> Rejected-by: Tanmay Shah 
>
> I will send new v5 with change long included.
>
> On 1/30/24 9:48 AM, Tanmay Shah wrote:
> > From: Mathieu Poirier 
> >
> > Multi-cluster remoteproc designs typically have the following DT
> > declaration:
> >
> > remoteproc-cluster {
> > compatible = "soc,remoteproc-cluster";
> >
> > core0: core0 {
> > compatible = "soc,remoteproc-core"
> > memory-region;
> > sram;
> > };
> >
> > core1: core1 {
> > compatible = "soc,remoteproc-core"
> > memory-region;
> > sram;
> > }
> > };
> >
> > A driver exists for the cluster rather than the individual cores
> > themselves so that operation mode and HW specific configurations
> > applicable to the cluster can be made.
> >
> > Because the driver exists at the cluster level and not the individual
> > core level, function rproc_get_by_phandle() fails to return the
> > remoteproc associated with the phandled it is called for.
> >
> > This patch enhances rproc_get_by_phandle() by looking for the cluster's
> > driver when the driver for the immediate remoteproc's parent is not
> > found.
> >
> > Reported-by: Ben Levinsky 
> > Signed-off-by: Mathieu Poirier 
> > Co-developed-by: Tarak Reddy 
> > Signed-off-by: Tarak Reddy 
> > Co-developed-by: Tanmay Shah 
> > Signed-off-by: Tanmay Shah 
> > ---
> >  drivers/remoteproc/remoteproc_core.c | 29 ++--
> >  1 file changed, 27 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/remoteproc/remoteproc_core.c 
> > b/drivers/remoteproc/remoteproc_core.c
> > index 695cce218e8c..f276956f2c5c 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -33,6 +33,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -2112,6 +2113,7 @@ EXPORT_SYMBOL(rproc_detach);
> >  struct rproc *rproc_get_by_phandle(phandle phandle)
> >  {
> > struct rproc *rproc = NULL, *r;
> > +   struct device_driver *driver;
> > struct device_node *np;
> >  
> > np = of_find_node_by_phandle(phandle);
> > @@ -2122,7 +2124,26 @@ struct rproc *rproc_get_by_phandle(phandle phandle)
> > list_for_each_entry_rcu(r, &rproc_list, node) {
> > if (r->dev.parent && device_match_of_node(r->dev.parent, np)) {
> > /* prevent underlying implementation from being removed 
> > */
> > -   if (!try_module_get(r->dev.parent->driver->owner)) {
> > +
> > +   /*
> > +* If the remoteproc's parent has a driver, the
> > +* remoteproc is not part of a cluster and we can use
> > +* that driver.
> > +*/
> > +   driver = r->dev.parent->driver;
> > +
> > +   /*
> > +* If the remoteproc's parent does not have a driver,
> > +* look for the driver associated with the cluster.
> > +*/
> > +   if (!driver) {
> > +   if (r->dev.parent->parent)
> > +   driver = r->dev.parent->parent->driver;
> > +   if (!driver)
> > +   break;
> > +   }
> > +
> > +   if (!try_module_get(driver->owner)) {
> > dev_err(&r->dev, "can't get owner\n");
> > break;
> > }
> > @@ -2533,7 +2554,11 @@ EXPORT_SYMBOL(rproc_free);
> >   */
> >  void rproc_put(struct rproc *rproc)
> >  {
> > -   module_put(rproc->dev.parent->driver->owner);
> > +   if (rproc->dev.parent->driver)
> > +   module_put(rproc->dev.parent->driver->owner);
> > +   else
> > +   module_put(rproc->dev.parent->parent->driver->owner);
> > +
> > put_device(&rproc->dev);
> >  }
> >  EXPORT_SYMBOL(rproc_put);
> >
> > base-commit: 99f59b148871dadb9104366e3d25b120a97f897b

[PATCH v10 1/4] remoteproc: zynqmp: fix lockstep mode memory region

[Tanmay Shah]

In lockstep mode, r5 core0 uses TCM of R5 core1. Following is lockstep
mode memory region as per hardware reference manual.

|  *TCM* |   *R5 View* | *Linux view* |
| R5_0 ATCM (128 KB) | 0x_ | 0xFFE0_  |
| R5_0 BTCM (128 KB) | 0x0002_ | 0xFFE2_  |

However, driver shouldn't model it as above because R5 core0 TCM and core1
TCM has different power-domains mapped to it.
Hence, TCM address space in lockstep mode should be modeled as 64KB
regions only where each region has its own power-domain as following:

|  *TCM* |   *R5 View* | *Linux view* |
| R5_0 ATCM0 (64 KB) | 0x_ | 0xFFE0_  |
| R5_0 BTCM0 (64 KB) | 0x0002_ | 0xFFE2_  |
| R5_0 ATCM1 (64 KB) | 0x0001_ | 0xFFE1_  |
| R5_0 BTCM1 (64 KB) | 0x0003_ | 0xFFE3_  |

This makes driver maintanance easy and makes design robust for future
platorms as well.

Signed-off-by: Tanmay Shah 
---
 drivers/remoteproc/xlnx_r5_remoteproc.c | 145 ++--
 1 file changed, 12 insertions(+), 133 deletions(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 4395edea9a64..42b0384d34f2 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -84,12 +84,12 @@ static const struct mem_bank_data zynqmp_tcm_banks_split[] 
= {
{0xffebUL, 0x2, 0x1UL, PD_R5_1_BTCM, "btcm1"},
 };
 
-/* In lockstep mode cluster combines each 64KB TCM and makes 128KB TCM */
+/* In lockstep mode cluster uses each 64KB TCM from second core as well */
 static const struct mem_bank_data zynqmp_tcm_banks_lockstep[] = {
-   {0xffe0UL, 0x0, 0x2UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 128KB 
each */
-   {0xffe2UL, 0x2, 0x2UL, PD_R5_0_BTCM, "btcm0"},
-   {0, 0, 0, PD_R5_1_ATCM, ""},
-   {0, 0, 0, PD_R5_1_BTCM, ""},
+   {0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each 
*/
+   {0xffe2UL, 0x2, 0x1UL, PD_R5_0_BTCM, "btcm0"},
+   {0xffe1UL, 0x1, 0x1UL, PD_R5_1_ATCM, "atcm1"},
+   {0xffe3UL, 0x3, 0x1UL, PD_R5_1_BTCM, "btcm1"},
 };
 
 /**
@@ -540,14 +540,14 @@ static int tcm_mem_map(struct rproc *rproc,
 }
 
 /*
- * add_tcm_carveout_split_mode()
+ * add_tcm_banks()
  * @rproc: single R5 core's corresponding rproc instance
  *
- * allocate and add remoteproc carveout for TCM memory in split mode
+ * allocate and add remoteproc carveout for TCM memory
  *
  * return 0 on success, otherwise non-zero value on failure
  */
-static int add_tcm_carveout_split_mode(struct rproc *rproc)
+static int add_tcm_banks(struct rproc *rproc)
 {
struct rproc_mem_entry *rproc_mem;
struct zynqmp_r5_core *r5_core;
@@ -580,10 +580,10 @@ static int add_tcm_carveout_split_mode(struct rproc 
*rproc)
 ZYNQMP_PM_REQUEST_ACK_BLOCKING);
if (ret < 0) {
dev_err(dev, "failed to turn on TCM 0x%x", 
pm_domain_id);
-   goto release_tcm_split;
+   goto release_tcm;
}
 
-   dev_dbg(dev, "TCM carveout split mode %s addr=%llx, da=0x%x, 
size=0x%lx",
+   dev_dbg(dev, "TCM carveout %s addr=%llx, da=0x%x, size=0x%lx",
bank_name, bank_addr, da, bank_size);
 
rproc_mem = rproc_mem_entry_init(dev, NULL, bank_addr,
@@ -593,7 +593,7 @@ static int add_tcm_carveout_split_mode(struct rproc *rproc)
if (!rproc_mem) {
ret = -ENOMEM;
zynqmp_pm_release_node(pm_domain_id);
-   goto release_tcm_split;
+   goto release_tcm;
}
 
rproc_add_carveout(rproc, rproc_mem);
@@ -601,7 +601,7 @@ static int add_tcm_carveout_split_mode(struct rproc *rproc)
 
return 0;
 
-release_tcm_split:
+release_tcm:
/* If failed, Turn off all TCM banks turned on before */
for (i--; i >= 0; i--) {
pm_domain_id = r5_core->tcm_banks[i]->pm_domain_id;
@@ -610,127 +610,6 @@ static int add_tcm_carveout_split_mode(struct rproc 
*rproc)
return ret;
 }
 
-/*
- * add_tcm_carveout_lockstep_mode()
- * @rproc: single R5 core's corresponding rproc instance
- *
- * allocate and add remoteproc carveout for TCM memory in lockstep mode
- *
- * return 0 on success, otherwise non-zero value on failure
- */
-static int add_tcm_carveout_lockstep_mode(struct rproc *rproc)
-{
-   struct rproc_mem_entry *rproc_mem;
-   struct zynqmp_r5_core *r5_core;
-   int i, num_banks, ret;
-   phys_addr_t bank_addr;
-   size_t bank_size = 0;
-   struct device *dev;
-   u32 pm_domain_id;
-   char *bank_name;
-   u

[PATCH v10 0/4] add zynqmp TCM bindings

[Tanmay Shah]

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)  | 0x_ | 0xFFE0_  |  |
| R5_0 BTCM (64 KB)  | 0x0002_ | 0xFFE2_  |  |
| R5_1 ATCM (64 KB)  | 0x_ | 0xFFE9_  | alias of 0xFFE1_ |
| R5_1 BTCM (64 KB)  | 0x0002_ | 0xFFEB_  | alias of 0xFFE3_ |
|  ___   | ___ |___   |  |
| *Lockstep Mode*| |  |  |
| R5_0 ATCM (128 KB) | 0x_ | 0xFFE0_  |  |
| R5_0 BTCM (128 KB) | 0x0002_ | 0xFFE2_  |  |

References:
UG1085 TCM address space:
https://docs.xilinx.com/r/en-US/ug1085-zynq-ultrascale-trm/Tightly-Coupled-Memory-Address-Map

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/20230829181900.2561194-1-tanmay.s...@amd.com/

Previous v3 version link:
https://lore.kernel.org/all/1689964908-22371-1-git-send-email-radhey.shyam.pan...@amd.com/
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

[PATCH v10 4/4] remoteproc: zynqmp: parse TCM from device tree

[Tanmay Shah]

ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
is available in device-tree. Parse TCM information in driver
as per new bindings.

Signed-off-by: Tanmay Shah 
---

Changes in v10:
  - Remove redundant changes to handle TCM in lockstep mode

Changes in v9:
  - 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.

Changes in v8:
  - Remove 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:
  - move checking of pm_domain_id from previous patch
  - fix mem_bank_data memory allocation

 drivers/remoteproc/xlnx_r5_remoteproc.c | 112 ++--
 1 file changed, 107 insertions(+), 5 deletions(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 42b0384d34f2..49e8eaf83fce 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -74,8 +74,8 @@ struct mbox_info {
 };
 
 /*
- * Hardcoded TCM bank values. This will be removed once TCM bindings are
- * accepted for system-dt specifications and upstreamed in linux kernel
+ * Hardcoded TCM bank values. This will stay in driver to maintain backward
+ * compatibility with device-tree that does not have TCM information.
  */
 static const struct mem_bank_data zynqmp_tcm_banks_split[] = {
{0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each 
*/
@@ -757,6 +757,103 @@ static struct zynqmp_r5_core 
*zynqmp_r5_add_rproc_core(struct device *cdev)
return ERR_PTR(ret);
 }
 
+static int zynqmp_r5_get_tcm_node_from_dt(struct zynqmp_r5_cluster *cluster)
+{
+   int i, j, tcm_bank_count, ret, tcm_pd_idx, pd_count;
+   struct of_phandle_args out_args = {0};
+   struct zynqmp_r5_core *r5_core;
+   struct platform_device *cpdev;
+   struct mem_bank_data *tcm;
+   struct device_node *np;
+   struct resource *res;
+   u64 abs_addr, size;
+   struct device *dev;
+
+   for (i = 0; i < cluster->core_count; i++) {
+   r5_core = cluster->r5_cores[i];
+   dev = r5_core->dev;
+   np = r5_core->np;
+
+   pd_count = of_count_phandle_with_args(np, "power-domains",
+ "#power-domain-cells");
+
+   if (pd_count <= 0) {
+   dev_err(dev, "invalid power-domains property, %d\n", 
pd_count);
+   return -EINVAL;
+   }
+
+   /* First entry in power-domains list is for r5 core, rest for 
TCM. */
+   tcm_bank_count = pd_count - 1;
+
+   if (tcm_bank_count <= 0) {
+   dev_err(dev, "invalid TCM count %d\n", tcm_bank_count);
+   return -EINVAL;
+   }
+
+   r5_core->tcm_banks = devm_kcalloc(dev, tcm_bank_count,
+ sizeof(struct mem_bank_data 
*),
+ GFP_KERNEL);
+   if (!r5_core->tcm_banks)
+   ret = -ENOMEM;
+
+   r5_core->tcm_bank_count = tcm_bank_count;
+   for (j = 0, tcm_pd_idx = 1; j < tcm_bank_count; j++, 
tcm_pd_idx++) {
+   tcm = devm_kzalloc(dev, sizeof(struct mem_bank_data),
+  GFP_KERNEL);
+   if (!tcm)
+   return -ENOMEM;
+
+   r5_core->tcm_banks[j] = tcm;
+
+   /* Get power-domains id of TCM. */
+   ret = of_parse_phandle_with_args(np, "power-domains",
+"#power-domain-cells",
+tcm_pd_idx, &out_args);
+   if (ret) {
+   dev_err(r5_core->dev,
+   "failed to get tcm %d pm domain, ret 
%d\n",
+   tcm_pd_idx, ret);
+   return ret;
+   }
+   tcm->pm_domain_id = out_args.args[0];
+   of_node_put(out_args.np);
+
+   /* Get TCM address without translation. */
+   ret = of_property_read_reg(np, j, &abs_addr, &size);
+ 

[PATCH v10 3/4] dts: zynqmp: add properties for TCM in remoteproc

[Tanmay Shah]

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 
---

Changes in v10:
  - 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 this patchset

Changes in v9:
  - fix rproc lockstep dts


 .../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@ffe0 {
compatible = "xlnx,zynqmp-r5fss";
xlnx,cluster-mode = <1>;
 
-   r5f-0 {
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x0 0x1 0x0 0xffe1 0x0 0x1>,
+<0x0 0x3 0x0 0xffe3 0x0 0x1>;
+
+   r5f@0 {
+   compatible = "xlnx,zynqmp-r5f";
+   reg = <0x0 0x0 0x0 0x1>,
+ <0x0 0x2 0x0 0x1>,
+ <0x0 0x1 0x0 0x1>,
+ <0x0 0x3 0x0 0x1>;
+   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 0x1>, <0x1 0x2 0x0 0x1>;
+   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@ffe0 {
+   status = "disabled";
+   compatible = "xlnx,zynqmp-r5fss";
+   xlnx,cluster-mode = <0>;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x1 0x0 0x0 0xffe9 0x0 0x1>,
+<0x1 0x2 0x0 0xffeb 0x0 0x1>;
+
+   r5f@0 {
compatible = "xlnx,zynqmp-r5f";
-   power-domains = <&zynqmp_firmware PD_RPU_0>;
+   reg = <0x0 0x0 0x0 0x1>, <0x0 0x2 0x0 0x1>;
+   reg-names = "atcm0", "btcm0";
+   power-domains = &

[PATCH v10 2/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings

[Tanmay Shah]

From: Radhey Shyam Pandey 

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 
Signed-off-by: Tanmay Shah 
---

Changes in v10:
  - 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

Changes in v9:
  - None
Changes in v8:
  - None
Changes in v7:
  - None
Changes in v6:
  - None
Changes in v5:
  - None

Changes in v4:
  - Use address-cells and size-cells value 2
  - Modify ranges property as per new value of address-cells
and size-cells
  - Modify child node "reg" property accordingly 
  - Remove previous ack for further review

v4 link: 
https://lore.kernel.org/all/20230829181900.2561194-2-tanmay.s...@amd.com/

 .../remoteproc/xlnx,zynqmp-r5fss.yaml | 192 --
 1 file changed, 170 insertions(+), 22 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml 
b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
index 78aac69f1060..2de74307821e 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,9 +66,6 @@ patternProperties:
   compatible:
 const: xlnx,zynqmp-r5f
 
-  power-domains:
-maxItems: 1
-
   mboxes:
 minItems: 1
 items:
@@ -101,35 +110,174 @@ patternProperties:
 
 required:
   - compatible
-  - power-domains
 
-unevaluatedProperties: false
+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
+
+power-domains:
+  minItems: 2
+  maxItems: 5
+
+  required:
+- reg
+- reg-names
+- power-domains
+
+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:
+  minItems: 2
+  maxItems: 3
+
+  required:
+- reg
+- reg-names
+- power-domains
 
 required:
   - 

Re: [PATCH v10 2/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings

[Tanmay Shah]

Hello,

Thanks for reviews please find my comments below.

On 2/13/24 1:20 PM, Rob Herring wrote:
> On Tue, 13 Feb 2024 09:54:48 -0800, Tanmay Shah wrote:
> > From: Radhey Shyam Pandey 
> > 
> > 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 
> > Signed-off-by: Tanmay Shah 
> > ---
> > 
> > Changes in v10:
> >   - 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
> > 
> > Changes in v9:
> >   - None
> > Changes in v8:
> >   - None
> > Changes in v7:
> >   - None
> > Changes in v6:
> >   - None
> > Changes in v5:
> >   - None
> > 
> > Changes in v4:
> >   - Use address-cells and size-cells value 2
> >   - Modify ranges property as per new value of address-cells
> > and size-cells
> >   - Modify child node "reg" property accordingly
> >   - Remove previous ack for further review
> > 
> > v4 link: 
> > https://lore.kernel.org/all/20230829181900.2561194-2-tanmay.s...@amd.com/
> > 
> >  .../remoteproc/xlnx,zynqmp-r5fss.yaml | 192 --
> >  1 file changed, 170 insertions(+), 22 deletions(-)
> > 
>
> My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> on your patch (DT_CHECKER_FLAGS is new in v5.13):
>
> yamllint warnings/errors:
> ./Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml:118:13: 
> [warning] wrong indentation: expected 10 but found 12 (indentation)
Ack. I will fix this.

However, can I still get reviews on patch itself so if something else needs to 
be fixed I can fix in next revision as well.

Also, I tried to run yamllint with following command:

make DT_CHECKER_FLAGS=-m dt_binding_check 
DT_SCHEMA_FILES=Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
 O=../build/zynqmp/linux-next/


However, I see following logs without any error on bindings:

  LINT    Documentation/devicetree/bindings
invalid config: unknown option "required" for rule "quoted-strings"
*xargs: /usr/bin/yamllint: exited with status 255; aborting*
  CHKDT   Documentation/devicetree/bindings/processed-schema.json
  SCHEMA  Documentation/devicetree/bindings/processed-schema.json
  DTEX    
Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.example.dts
  DTC_CHK 
Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.example.dtb

I am not sure if my system is missing something but, yamllint tool is failing.

I appreciate if someone can point to quick fix if this is known issue and is 
already resolved.

Thanks,

Tanmay

> dtschema/dtc warnings/errors:
>
> doc reference errors (make refcheckdocs):
>
> See 
> https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240213175450.3097308-3-tanmay.s...@amd.com
>
> The base for the series is generally the latest rc1. A different dependency
> should be noted in *this* patch.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
> Please check and re-submit after running the above command yourself. Note
> that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> your schema. However, it must be unset to test all examples with your schema.
>

Re: [PATCH v10 2/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings

[Tanmay Shah]

On 2/15/24 3:06 AM, Krzysztof Kozlowski wrote:
> On 13/02/2024 21:37, Tanmay Shah wrote:
> > Hello,
> > 
> > Thanks for reviews please find my comments below.
> > 
> > On 2/13/24 1:20 PM, Rob Herring wrote:
> >> On Tue, 13 Feb 2024 09:54:48 -0800, Tanmay Shah wrote:
> >>> From: Radhey Shyam Pandey 
> >>>
> >>> 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 
> >>> Signed-off-by: Tanmay Shah 
> >>> ---
> >>>
> >>> Changes in v10:
> >>>   - 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
> >>>
> >>> Changes in v9:
> >>>   - None
> >>> Changes in v8:
> >>>   - None
> >>> Changes in v7:
> >>>   - None
> >>> Changes in v6:
> >>>   - None
> >>> Changes in v5:
> >>>   - None
> >>>
> >>> Changes in v4:
> >>>   - Use address-cells and size-cells value 2
> >>>   - Modify ranges property as per new value of address-cells
> >>> and size-cells
> >>>   - Modify child node "reg" property accordingly
> >>>   - Remove previous ack for further review
> >>>
> >>> v4 link: 
> >>> https://lore.kernel.org/all/20230829181900.2561194-2-tanmay.s...@amd.com/
> >>>
> >>>  .../remoteproc/xlnx,zynqmp-r5fss.yaml | 192 --
> >>>  1 file changed, 170 insertions(+), 22 deletions(-)
> >>>
> >>
> >> My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> >> on your patch (DT_CHECKER_FLAGS is new in v5.13):
> >>
> >> yamllint warnings/errors:
> >> ./Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml:118:13:
> >>  [warning] wrong indentation: expected 10 but found 12 (indentation)
> > Ack. I will fix this.
> > 
> > However, can I still get reviews on patch itself so if something else needs 
> > to be fixed I can fix in next revision as well.
>
> Sorry, I have too many patches to review to provide feedback on work
> which does not build/compile/test. First use automated tooling, like
> building a C code, to detect as many issues as possible then ask for
> reviewing. Not the other way around.

Ack. I will send new revision fixing the warning.

Thanks.


>
> Best regards,
> Krzysztof

[PATCH v11 0/4] add zynqmp TCM bindings

[Tanmay Shah]

moteproc: 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 | 192 +++--
 .../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, 357 insertions(+), 165 deletions(-)


base-commit: 929654e8f1add50b01d5a56171a31c311b0a739a
-- 
2.25.1

[PATCH v11 2/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings

[Tanmay Shah]

From: Radhey Shyam Pandey 

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 
Signed-off-by: Tanmay Shah 
---

Changes in v11:
  - Fix yamllint warning and reduce indentation as needed

 .../remoteproc/xlnx,zynqmp-r5fss.yaml | 192 --
 1 file changed, 170 insertions(+), 22 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml 
b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
index 78aac69f1060..77030edf41fa 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,9 +66,6 @@ patternProperties:
   compatible:
 const: xlnx,zynqmp-r5f
 
-  power-domains:
-maxItems: 1
-
   mboxes:
 minItems: 1
 items:
@@ -101,35 +110,174 @@ patternProperties:
 
 required:
   - compatible
-  - power-domains
 
-unevaluatedProperties: false
+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
+
+power-domains:
+  minItems: 2
+  maxItems: 5
+
+  required:
+- reg
+- reg-names
+- power-domains
+
+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:
+  minItems: 2
+  maxItems: 3
+
+  required:
+- reg
+- reg-names
+- power-domains
 
 required:
   - compatible
+  - "#address-cells"
+  - "#size-cells"
+  - ranges
 
 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 
+
+// Split mode configuration
+soc {
+

[PATCH v11 1/4] remoteproc: zynqmp: fix lockstep mode memory region

[Tanmay Shah]

In lockstep mode, r5 core0 uses TCM of R5 core1. Following is lockstep
mode memory region as per hardware reference manual.

|  *TCM* |   *R5 View* | *Linux view* |
| R5_0 ATCM (128 KB) | 0x_ | 0xFFE0_  |
| R5_0 BTCM (128 KB) | 0x0002_ | 0xFFE2_  |

However, driver shouldn't model it as above because R5 core0 TCM and core1
TCM has different power-domains mapped to it.
Hence, TCM address space in lockstep mode should be modeled as 64KB
regions only where each region has its own power-domain as following:

|  *TCM* |   *R5 View* | *Linux view* |
| R5_0 ATCM0 (64 KB) | 0x_ | 0xFFE0_  |
| R5_0 BTCM0 (64 KB) | 0x0002_ | 0xFFE2_  |
| R5_0 ATCM1 (64 KB) | 0x0001_ | 0xFFE1_  |
| R5_0 BTCM1 (64 KB) | 0x0003_ | 0xFFE3_  |

This makes driver maintanance easy and makes design robust for future
platorms as well.

Signed-off-by: Tanmay Shah 
---
 drivers/remoteproc/xlnx_r5_remoteproc.c | 145 ++--
 1 file changed, 12 insertions(+), 133 deletions(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 4395edea9a64..42b0384d34f2 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -84,12 +84,12 @@ static const struct mem_bank_data zynqmp_tcm_banks_split[] 
= {
{0xffebUL, 0x2, 0x1UL, PD_R5_1_BTCM, "btcm1"},
 };
 
-/* In lockstep mode cluster combines each 64KB TCM and makes 128KB TCM */
+/* In lockstep mode cluster uses each 64KB TCM from second core as well */
 static const struct mem_bank_data zynqmp_tcm_banks_lockstep[] = {
-   {0xffe0UL, 0x0, 0x2UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 128KB 
each */
-   {0xffe2UL, 0x2, 0x2UL, PD_R5_0_BTCM, "btcm0"},
-   {0, 0, 0, PD_R5_1_ATCM, ""},
-   {0, 0, 0, PD_R5_1_BTCM, ""},
+   {0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each 
*/
+   {0xffe2UL, 0x2, 0x1UL, PD_R5_0_BTCM, "btcm0"},
+   {0xffe1UL, 0x1, 0x1UL, PD_R5_1_ATCM, "atcm1"},
+   {0xffe3UL, 0x3, 0x1UL, PD_R5_1_BTCM, "btcm1"},
 };
 
 /**
@@ -540,14 +540,14 @@ static int tcm_mem_map(struct rproc *rproc,
 }
 
 /*
- * add_tcm_carveout_split_mode()
+ * add_tcm_banks()
  * @rproc: single R5 core's corresponding rproc instance
  *
- * allocate and add remoteproc carveout for TCM memory in split mode
+ * allocate and add remoteproc carveout for TCM memory
  *
  * return 0 on success, otherwise non-zero value on failure
  */
-static int add_tcm_carveout_split_mode(struct rproc *rproc)
+static int add_tcm_banks(struct rproc *rproc)
 {
struct rproc_mem_entry *rproc_mem;
struct zynqmp_r5_core *r5_core;
@@ -580,10 +580,10 @@ static int add_tcm_carveout_split_mode(struct rproc 
*rproc)
 ZYNQMP_PM_REQUEST_ACK_BLOCKING);
if (ret < 0) {
dev_err(dev, "failed to turn on TCM 0x%x", 
pm_domain_id);
-   goto release_tcm_split;
+   goto release_tcm;
}
 
-   dev_dbg(dev, "TCM carveout split mode %s addr=%llx, da=0x%x, 
size=0x%lx",
+   dev_dbg(dev, "TCM carveout %s addr=%llx, da=0x%x, size=0x%lx",
bank_name, bank_addr, da, bank_size);
 
rproc_mem = rproc_mem_entry_init(dev, NULL, bank_addr,
@@ -593,7 +593,7 @@ static int add_tcm_carveout_split_mode(struct rproc *rproc)
if (!rproc_mem) {
ret = -ENOMEM;
zynqmp_pm_release_node(pm_domain_id);
-   goto release_tcm_split;
+   goto release_tcm;
}
 
rproc_add_carveout(rproc, rproc_mem);
@@ -601,7 +601,7 @@ static int add_tcm_carveout_split_mode(struct rproc *rproc)
 
return 0;
 
-release_tcm_split:
+release_tcm:
/* If failed, Turn off all TCM banks turned on before */
for (i--; i >= 0; i--) {
pm_domain_id = r5_core->tcm_banks[i]->pm_domain_id;
@@ -610,127 +610,6 @@ static int add_tcm_carveout_split_mode(struct rproc 
*rproc)
return ret;
 }
 
-/*
- * add_tcm_carveout_lockstep_mode()
- * @rproc: single R5 core's corresponding rproc instance
- *
- * allocate and add remoteproc carveout for TCM memory in lockstep mode
- *
- * return 0 on success, otherwise non-zero value on failure
- */
-static int add_tcm_carveout_lockstep_mode(struct rproc *rproc)
-{
-   struct rproc_mem_entry *rproc_mem;
-   struct zynqmp_r5_core *r5_core;
-   int i, num_banks, ret;
-   phys_addr_t bank_addr;
-   size_t bank_size = 0;
-   struct device *dev;
-   u32 pm_domain_id;
-   char *bank_name;
-   u

[PATCH v11 3/4] dts: zynqmp: add properties for TCM in remoteproc

[Tanmay Shah]

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 
---
 .../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@ffe0 {
compatible = "xlnx,zynqmp-r5fss";
xlnx,cluster-mode = <1>;
 
-   r5f-0 {
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x0 0x1 0x0 0xffe1 0x0 0x1>,
+<0x0 0x3 0x0 0xffe3 0x0 0x1>;
+
+   r5f@0 {
+   compatible = "xlnx,zynqmp-r5f";
+   reg = <0x0 0x0 0x0 0x1>,
+ <0x0 0x2 0x0 0x1>,
+ <0x0 0x1 0x0 0x1>,
+ <0x0 0x3 0x0 0x1>;
+   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 0x1>, <0x1 0x2 0x0 0x1>;
+   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@ffe0 {
+   status = "disabled";
+   compatible = "xlnx,zynqmp-r5fss";
+   xlnx,cluster-mode = <0>;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x1 0x0 0x0 0xffe9 0x0 0x1>,
+<0x1 0x2 0x0 0xffeb 0x0 0x1>;
+
+   r5f@0 {
compatible = "xlnx,zynqmp-r5f";
-   power-domains = <&zynqmp_firmware PD_RPU_0>;
+   reg = <0x0 0x0 0x0 0x1>, <0x0 0x2 0x0 0x1>;
+   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

[PATCH v11 4/4] remoteproc: zynqmp: parse TCM from device tree

[Tanmay Shah]

ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
is available in device-tree. Parse TCM information in driver
as per new bindings.

Signed-off-by: Tanmay Shah 
---

Changes in v11:
  - Remove redundant initialization of the variable
  - return correct error code if memory allocation failed

 drivers/remoteproc/xlnx_r5_remoteproc.c | 112 ++--
 1 file changed, 107 insertions(+), 5 deletions(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 42b0384d34f2..d4a22caebaad 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -74,8 +74,8 @@ struct mbox_info {
 };
 
 /*
- * Hardcoded TCM bank values. This will be removed once TCM bindings are
- * accepted for system-dt specifications and upstreamed in linux kernel
+ * Hardcoded TCM bank values. This will stay in driver to maintain backward
+ * compatibility with device-tree that does not have TCM information.
  */
 static const struct mem_bank_data zynqmp_tcm_banks_split[] = {
{0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each 
*/
@@ -757,6 +757,103 @@ static struct zynqmp_r5_core 
*zynqmp_r5_add_rproc_core(struct device *cdev)
return ERR_PTR(ret);
 }
 
+static int zynqmp_r5_get_tcm_node_from_dt(struct zynqmp_r5_cluster *cluster)
+{
+   int i, j, tcm_bank_count, ret, tcm_pd_idx, pd_count;
+   struct of_phandle_args out_args;
+   struct zynqmp_r5_core *r5_core;
+   struct platform_device *cpdev;
+   struct mem_bank_data *tcm;
+   struct device_node *np;
+   struct resource *res;
+   u64 abs_addr, size;
+   struct device *dev;
+
+   for (i = 0; i < cluster->core_count; i++) {
+   r5_core = cluster->r5_cores[i];
+   dev = r5_core->dev;
+   np = r5_core->np;
+
+   pd_count = of_count_phandle_with_args(np, "power-domains",
+ "#power-domain-cells");
+
+   if (pd_count <= 0) {
+   dev_err(dev, "invalid power-domains property, %d\n", 
pd_count);
+   return -EINVAL;
+   }
+
+   /* First entry in power-domains list is for r5 core, rest for 
TCM. */
+   tcm_bank_count = pd_count - 1;
+
+   if (tcm_bank_count <= 0) {
+   dev_err(dev, "invalid TCM count %d\n", tcm_bank_count);
+   return -EINVAL;
+   }
+
+   r5_core->tcm_banks = devm_kcalloc(dev, tcm_bank_count,
+ sizeof(struct mem_bank_data 
*),
+ GFP_KERNEL);
+   if (!r5_core->tcm_banks)
+   return -ENOMEM;
+
+   r5_core->tcm_bank_count = tcm_bank_count;
+   for (j = 0, tcm_pd_idx = 1; j < tcm_bank_count; j++, 
tcm_pd_idx++) {
+   tcm = devm_kzalloc(dev, sizeof(struct mem_bank_data),
+  GFP_KERNEL);
+   if (!tcm)
+   return -ENOMEM;
+
+   r5_core->tcm_banks[j] = tcm;
+
+   /* Get power-domains id of TCM. */
+   ret = of_parse_phandle_with_args(np, "power-domains",
+"#power-domain-cells",
+tcm_pd_idx, &out_args);
+   if (ret) {
+   dev_err(r5_core->dev,
+   "failed to get tcm %d pm domain, ret 
%d\n",
+   tcm_pd_idx, ret);
+   return ret;
+   }
+   tcm->pm_domain_id = out_args.args[0];
+   of_node_put(out_args.np);
+
+   /* Get TCM address without translation. */
+   ret = of_property_read_reg(np, j, &abs_addr, &size);
+   if (ret) {
+   dev_err(dev, "failed to get reg property\n");
+   return ret;
+   }
+
+   /*
+* Remote processor can address only 32 bits
+* so convert 64-bits into 32-bits. This will discard
+* any unwanted upper 32-bits.
+*/
+   tcm->da = (u32)abs_addr;
+   tcm->size = (u32)size;
+
+   cpdev = to_platform_device(dev);
+   res = platform_get_resource(cpdev, IORESOURCE_MEM, j);
+ 

[PATCH v11 1/4] remoteproc: zynqmp: fix lockstep mode memory region

[Tanmay Shah]

In lockstep mode, r5 core0 uses TCM of R5 core1. Following is lockstep
mode memory region as per hardware reference manual.

|  *TCM* |   *R5 View* | *Linux view* |
| R5_0 ATCM (128 KB) | 0x_ | 0xFFE0_  |
| R5_0 BTCM (128 KB) | 0x0002_ | 0xFFE2_  |

However, driver shouldn't model it as above because R5 core0 TCM and core1
TCM has different power-domains mapped to it.
Hence, TCM address space in lockstep mode should be modeled as 64KB
regions only where each region has its own power-domain as following:

|  *TCM* |   *R5 View* | *Linux view* |
| R5_0 ATCM0 (64 KB) | 0x_ | 0xFFE0_  |
| R5_0 BTCM0 (64 KB) | 0x0002_ | 0xFFE2_  |
| R5_0 ATCM1 (64 KB) | 0x0001_ | 0xFFE1_  |
| R5_0 BTCM1 (64 KB) | 0x0003_ | 0xFFE3_  |

This makes driver maintanance easy and makes design robust for future
platorms as well.

Signed-off-by: Tanmay Shah 
---
 drivers/remoteproc/xlnx_r5_remoteproc.c | 145 ++--
 1 file changed, 12 insertions(+), 133 deletions(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 4395edea9a64..42b0384d34f2 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -84,12 +84,12 @@ static const struct mem_bank_data zynqmp_tcm_banks_split[] 
= {
{0xffebUL, 0x2, 0x1UL, PD_R5_1_BTCM, "btcm1"},
 };
 
-/* In lockstep mode cluster combines each 64KB TCM and makes 128KB TCM */
+/* In lockstep mode cluster uses each 64KB TCM from second core as well */
 static const struct mem_bank_data zynqmp_tcm_banks_lockstep[] = {
-   {0xffe0UL, 0x0, 0x2UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 128KB 
each */
-   {0xffe2UL, 0x2, 0x2UL, PD_R5_0_BTCM, "btcm0"},
-   {0, 0, 0, PD_R5_1_ATCM, ""},
-   {0, 0, 0, PD_R5_1_BTCM, ""},
+   {0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each 
*/
+   {0xffe2UL, 0x2, 0x1UL, PD_R5_0_BTCM, "btcm0"},
+   {0xffe1UL, 0x1, 0x1UL, PD_R5_1_ATCM, "atcm1"},
+   {0xffe3UL, 0x3, 0x1UL, PD_R5_1_BTCM, "btcm1"},
 };
 
 /**
@@ -540,14 +540,14 @@ static int tcm_mem_map(struct rproc *rproc,
 }
 
 /*
- * add_tcm_carveout_split_mode()
+ * add_tcm_banks()
  * @rproc: single R5 core's corresponding rproc instance
  *
- * allocate and add remoteproc carveout for TCM memory in split mode
+ * allocate and add remoteproc carveout for TCM memory
  *
  * return 0 on success, otherwise non-zero value on failure
  */
-static int add_tcm_carveout_split_mode(struct rproc *rproc)
+static int add_tcm_banks(struct rproc *rproc)
 {
struct rproc_mem_entry *rproc_mem;
struct zynqmp_r5_core *r5_core;
@@ -580,10 +580,10 @@ static int add_tcm_carveout_split_mode(struct rproc 
*rproc)
 ZYNQMP_PM_REQUEST_ACK_BLOCKING);
if (ret < 0) {
dev_err(dev, "failed to turn on TCM 0x%x", 
pm_domain_id);
-   goto release_tcm_split;
+   goto release_tcm;
}
 
-   dev_dbg(dev, "TCM carveout split mode %s addr=%llx, da=0x%x, 
size=0x%lx",
+   dev_dbg(dev, "TCM carveout %s addr=%llx, da=0x%x, size=0x%lx",
bank_name, bank_addr, da, bank_size);
 
rproc_mem = rproc_mem_entry_init(dev, NULL, bank_addr,
@@ -593,7 +593,7 @@ static int add_tcm_carveout_split_mode(struct rproc *rproc)
if (!rproc_mem) {
ret = -ENOMEM;
zynqmp_pm_release_node(pm_domain_id);
-   goto release_tcm_split;
+   goto release_tcm;
}
 
rproc_add_carveout(rproc, rproc_mem);
@@ -601,7 +601,7 @@ static int add_tcm_carveout_split_mode(struct rproc *rproc)
 
return 0;
 
-release_tcm_split:
+release_tcm:
/* If failed, Turn off all TCM banks turned on before */
for (i--; i >= 0; i--) {
pm_domain_id = r5_core->tcm_banks[i]->pm_domain_id;
@@ -610,127 +610,6 @@ static int add_tcm_carveout_split_mode(struct rproc 
*rproc)
return ret;
 }
 
-/*
- * add_tcm_carveout_lockstep_mode()
- * @rproc: single R5 core's corresponding rproc instance
- *
- * allocate and add remoteproc carveout for TCM memory in lockstep mode
- *
- * return 0 on success, otherwise non-zero value on failure
- */
-static int add_tcm_carveout_lockstep_mode(struct rproc *rproc)
-{
-   struct rproc_mem_entry *rproc_mem;
-   struct zynqmp_r5_core *r5_core;
-   int i, num_banks, ret;
-   phys_addr_t bank_addr;
-   size_t bank_size = 0;
-   struct device *dev;
-   u32 pm_domain_id;
-   char *bank_name;
-   u

[PATCH v11 0/4] add zynqmp TCM bindings

[Tanmay Shah]

moteproc: 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 | 192 +++--
 .../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, 357 insertions(+), 165 deletions(-)


base-commit: 929654e8f1add50b01d5a56171a31c311b0a739a
-- 
2.25.1

[PATCH v11 2/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings

[Tanmay Shah]

From: Radhey Shyam Pandey 

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 
Signed-off-by: Tanmay Shah 
---

Changes in v11:
  - Fix yamllint warning and reduce indentation as needed

 .../remoteproc/xlnx,zynqmp-r5fss.yaml | 192 --
 1 file changed, 170 insertions(+), 22 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml 
b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
index 78aac69f1060..77030edf41fa 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,9 +66,6 @@ patternProperties:
   compatible:
 const: xlnx,zynqmp-r5f
 
-  power-domains:
-maxItems: 1
-
   mboxes:
 minItems: 1
 items:
@@ -101,35 +110,174 @@ patternProperties:
 
 required:
   - compatible
-  - power-domains
 
-unevaluatedProperties: false
+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
+
+power-domains:
+  minItems: 2
+  maxItems: 5
+
+  required:
+- reg
+- reg-names
+- power-domains
+
+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:
+  minItems: 2
+  maxItems: 3
+
+  required:
+- reg
+- reg-names
+- power-domains
 
 required:
   - compatible
+  - "#address-cells"
+  - "#size-cells"
+  - ranges
 
 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 
+
+// Split mode configuration
+soc {
+

[PATCH v11 3/4] dts: zynqmp: add properties for TCM in remoteproc

[Tanmay Shah]

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 
---
 .../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@ffe0 {
compatible = "xlnx,zynqmp-r5fss";
xlnx,cluster-mode = <1>;
 
-   r5f-0 {
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x0 0x1 0x0 0xffe1 0x0 0x1>,
+<0x0 0x3 0x0 0xffe3 0x0 0x1>;
+
+   r5f@0 {
+   compatible = "xlnx,zynqmp-r5f";
+   reg = <0x0 0x0 0x0 0x1>,
+ <0x0 0x2 0x0 0x1>,
+ <0x0 0x1 0x0 0x1>,
+ <0x0 0x3 0x0 0x1>;
+   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 0x1>, <0x1 0x2 0x0 0x1>;
+   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@ffe0 {
+   status = "disabled";
+   compatible = "xlnx,zynqmp-r5fss";
+   xlnx,cluster-mode = <0>;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x1 0x0 0x0 0xffe9 0x0 0x1>,
+<0x1 0x2 0x0 0xffeb 0x0 0x1>;
+
+   r5f@0 {
compatible = "xlnx,zynqmp-r5f";
-   power-domains = <&zynqmp_firmware PD_RPU_0>;
+   reg = <0x0 0x0 0x0 0x1>, <0x0 0x2 0x0 0x1>;
+   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

[PATCH v11 4/4] remoteproc: zynqmp: parse TCM from device tree

[Tanmay Shah]

ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
is available in device-tree. Parse TCM information in driver
as per new bindings.

Signed-off-by: Tanmay Shah 
---

Changes in v11:
  - Remove redundant initialization of the variable
  - return correct error code if memory allocation failed

 drivers/remoteproc/xlnx_r5_remoteproc.c | 112 ++--
 1 file changed, 107 insertions(+), 5 deletions(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 42b0384d34f2..d4a22caebaad 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -74,8 +74,8 @@ struct mbox_info {
 };
 
 /*
- * Hardcoded TCM bank values. This will be removed once TCM bindings are
- * accepted for system-dt specifications and upstreamed in linux kernel
+ * Hardcoded TCM bank values. This will stay in driver to maintain backward
+ * compatibility with device-tree that does not have TCM information.
  */
 static const struct mem_bank_data zynqmp_tcm_banks_split[] = {
{0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each 
*/
@@ -757,6 +757,103 @@ static struct zynqmp_r5_core 
*zynqmp_r5_add_rproc_core(struct device *cdev)
return ERR_PTR(ret);
 }
 
+static int zynqmp_r5_get_tcm_node_from_dt(struct zynqmp_r5_cluster *cluster)
+{
+   int i, j, tcm_bank_count, ret, tcm_pd_idx, pd_count;
+   struct of_phandle_args out_args;
+   struct zynqmp_r5_core *r5_core;
+   struct platform_device *cpdev;
+   struct mem_bank_data *tcm;
+   struct device_node *np;
+   struct resource *res;
+   u64 abs_addr, size;
+   struct device *dev;
+
+   for (i = 0; i < cluster->core_count; i++) {
+   r5_core = cluster->r5_cores[i];
+   dev = r5_core->dev;
+   np = r5_core->np;
+
+   pd_count = of_count_phandle_with_args(np, "power-domains",
+ "#power-domain-cells");
+
+   if (pd_count <= 0) {
+   dev_err(dev, "invalid power-domains property, %d\n", 
pd_count);
+   return -EINVAL;
+   }
+
+   /* First entry in power-domains list is for r5 core, rest for 
TCM. */
+   tcm_bank_count = pd_count - 1;
+
+   if (tcm_bank_count <= 0) {
+   dev_err(dev, "invalid TCM count %d\n", tcm_bank_count);
+   return -EINVAL;
+   }
+
+   r5_core->tcm_banks = devm_kcalloc(dev, tcm_bank_count,
+ sizeof(struct mem_bank_data 
*),
+ GFP_KERNEL);
+   if (!r5_core->tcm_banks)
+   return -ENOMEM;
+
+   r5_core->tcm_bank_count = tcm_bank_count;
+   for (j = 0, tcm_pd_idx = 1; j < tcm_bank_count; j++, 
tcm_pd_idx++) {
+   tcm = devm_kzalloc(dev, sizeof(struct mem_bank_data),
+  GFP_KERNEL);
+   if (!tcm)
+   return -ENOMEM;
+
+   r5_core->tcm_banks[j] = tcm;
+
+   /* Get power-domains id of TCM. */
+   ret = of_parse_phandle_with_args(np, "power-domains",
+"#power-domain-cells",
+tcm_pd_idx, &out_args);
+   if (ret) {
+   dev_err(r5_core->dev,
+   "failed to get tcm %d pm domain, ret 
%d\n",
+   tcm_pd_idx, ret);
+   return ret;
+   }
+   tcm->pm_domain_id = out_args.args[0];
+   of_node_put(out_args.np);
+
+   /* Get TCM address without translation. */
+   ret = of_property_read_reg(np, j, &abs_addr, &size);
+   if (ret) {
+   dev_err(dev, "failed to get reg property\n");
+   return ret;
+   }
+
+   /*
+* Remote processor can address only 32 bits
+* so convert 64-bits into 32-bits. This will discard
+* any unwanted upper 32-bits.
+*/
+   tcm->da = (u32)abs_addr;
+   tcm->size = (u32)size;
+
+   cpdev = to_platform_device(dev);
+   res = platform_get_resource(cpdev, IORESOURCE_MEM, j);
+ 

Re: [PATCH v11 0/4] add zynqmp TCM bindings

[Tanmay Shah]

Hello,

By mistake same set of patches were sent twice in same git send-email command.

Anyone can be reviewed. Please let me know if I need to take any action to fix 
it.

Thanks.

On 2/19/24 11:44 AM, Tanmay Shah wrote:
> 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)  | 0x_ | 0xFFE0_  |  |
> | R5_0 BTCM (64 KB)  | 0x0002_ | 0xFFE2_  |  |
> | R5_1 ATCM (64 KB)  | 0x_ | 0xFFE9_  | alias of 0xFFE1_ |
> | R5_1 BTCM (64 KB)  | 0x0002_ | 0xFFEB_  | alias of 0xFFE3_ |
> |  ___   | ___ |___   |  |
> | *Lockstep Mode*| |  |  |
> | R5_0 ATCM (128 KB) | 0x_ | 0xFFE0_  |  |
> | R5_0 BTCM (128 KB) | 0x0002_ | 0xFFE2_  |  |
>
> References:
> UG1085 TCM address space:
> https://docs.xilinx.com/r/en-US/ug1085-zynq-ultrascale-trm/Tightly-Coupled-Memory-Address-Map
>
> 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:
>   - mainta

Re: [PATCH v11 4/4] remoteproc: zynqmp: parse TCM from device tree

[Tanmay Shah]

On 2/28/24 11:06 AM, Mathieu Poirier wrote:
> On Mon, Feb 19, 2024 at 09:44:37AM -0800, Tanmay Shah wrote:
> > ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
> > is available in device-tree. Parse TCM information in driver
> > as per new bindings.
> > 
> > Signed-off-by: Tanmay Shah 
> > ---
> > 
> > Changes in v11:
> >   - Remove redundant initialization of the variable
> >   - return correct error code if memory allocation failed
>
> Where is that?  I looked really hard but couldn't find it.

Hi Mathieu,

Thanks for reviews. Please find my comment below.

>
> > 
> >  drivers/remoteproc/xlnx_r5_remoteproc.c | 112 ++--
> >  1 file changed, 107 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
> > b/drivers/remoteproc/xlnx_r5_remoteproc.c
> > index 42b0384d34f2..d4a22caebaad 100644
> > --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> > +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> > @@ -74,8 +74,8 @@ struct mbox_info {
> >  };
> >  
> >  /*
> > - * Hardcoded TCM bank values. This will be removed once TCM bindings are
> > - * accepted for system-dt specifications and upstreamed in linux kernel
> > + * Hardcoded TCM bank values. This will stay in driver to maintain backward
> > + * compatibility with device-tree that does not have TCM information.
> >   */
> >  static const struct mem_bank_data zynqmp_tcm_banks_split[] = {
> > {0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each 
> > */
> > @@ -757,6 +757,103 @@ static struct zynqmp_r5_core 
> > *zynqmp_r5_add_rproc_core(struct device *cdev)
> > return ERR_PTR(ret);
> >  }
> >  
> > +static int zynqmp_r5_get_tcm_node_from_dt(struct zynqmp_r5_cluster 
> > *cluster)
> > +{
> > +   int i, j, tcm_bank_count, ret, tcm_pd_idx, pd_count;
> > +   struct of_phandle_args out_args;
> > +   struct zynqmp_r5_core *r5_core;
> > +   struct platform_device *cpdev;
> > +   struct mem_bank_data *tcm;
> > +   struct device_node *np;
> > +   struct resource *res;
> > +   u64 abs_addr, size;
> > +   struct device *dev;
> > +
> > +   for (i = 0; i < cluster->core_count; i++) {
> > +   r5_core = cluster->r5_cores[i];
> > +   dev = r5_core->dev;
> > +   np = r5_core->np;
> > +
> > +   pd_count = of_count_phandle_with_args(np, "power-domains",
> > + "#power-domain-cells");
> > +
> > +   if (pd_count <= 0) {
> > +   dev_err(dev, "invalid power-domains property, %d\n", 
> > pd_count);
> > +   return -EINVAL;
> > +   }
> > +
> > +   /* First entry in power-domains list is for r5 core, rest for 
> > TCM. */
> > +   tcm_bank_count = pd_count - 1;
> > +
> > +   if (tcm_bank_count <= 0) {
> > +   dev_err(dev, "invalid TCM count %d\n", tcm_bank_count);
> > +   return -EINVAL;
> > +   }
> > +
> > +   r5_core->tcm_banks = devm_kcalloc(dev, tcm_bank_count,
> > + sizeof(struct mem_bank_data 
> > *),
> > + GFP_KERNEL);
> > +   if (!r5_core->tcm_banks)
> > +   return -ENOMEM;

Hi Mathiue,

Here: in v10 it was following:

+   if (!r5_core->tcm_banks)
+   ret = -ENOMEM;

Which is not correct. Somehow I missed to return the error code instead it was 
just storing the error in variable.


> > +
> > +   r5_core->tcm_bank_count = tcm_bank_count;
> > +   for (j = 0, tcm_pd_idx = 1; j < tcm_bank_count; j++, 
> > tcm_pd_idx++) {
> > +   tcm = devm_kzalloc(dev, sizeof(struct mem_bank_data),
> > +  GFP_KERNEL);
> > +   if (!tcm)
> > +   return -ENOMEM;
> > +
> > +   r5_core->tcm_banks[j] = tcm;
> > +
> > +   /* Get power-domains id of TCM. */
> > +   ret = of_parse_phandle_with_args(np, "power-domains",
> > +"#power-domain-cells",
> > +tcm_pd_idx, &out_args);
> > +   if (r

Re: [PATCH v11 2/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings

[Tanmay Shah]

Hi Krzysztof,

Ping for reviews. Also have question.

I am referring this patch from patchwork link: 
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240219174437.3722620-8-tanmay.s...@amd.com/

Patchwork shows that dtbs-check was failed, but I am sending dts changes in 
next patch. So dtbs-check failure only with bindings patch is expected.

How to resolve this? Should I send dtb changes same as bindings? Or we can 
ignore dtbs-check errors for now?

Thanks,

Tanmay

On 2/19/24 11:44 AM, Tanmay Shah wrote:
> From: Radhey Shyam Pandey 
>
> 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 
> Signed-off-by: Tanmay Shah 
> ---
>
> Changes in v11:
>   - Fix yamllint warning and reduce indentation as needed
>
>  .../remoteproc/xlnx,zynqmp-r5fss.yaml | 192 --
>  1 file changed, 170 insertions(+), 22 deletions(-)
>
> diff --git 
> a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml 
> b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
> index 78aac69f1060..77030edf41fa 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,9 +66,6 @@ patternProperties:
>compatible:
>  const: xlnx,zynqmp-r5f
>  
> -  power-domains:
> -maxItems: 1
> -
>mboxes:
>  minItems: 1
>  items:
> @@ -101,35 +110,174 @@ patternProperties:
>  
>  required:
>- compatible
> -  - power-domains
>  
> -unevaluatedProperties: false
> +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
> +
> +power-domains:
> +  minItems: 2
> +  maxItems: 5
> +
> +  required:
> +- reg
> +- reg-names
> +- power-domains
> +
> +else:
> +  patternProperties:
> +"^r5f@[0-9a-f]+$":
> +  type: object
> +
> +  properties:
> +reg:
> +  minItems: 1
> +  items:
> +

Re: [PATCH v11 1/4] remoteproc: zynqmp: fix lockstep mode memory region

[Tanmay Shah]

On 2/28/24 11:08 AM, Mathieu Poirier wrote:
> On Mon, Feb 19, 2024 at 09:44:34AM -0800, Tanmay Shah wrote:
> > In lockstep mode, r5 core0 uses TCM of R5 core1. Following is lockstep
> > mode memory region as per hardware reference manual.
> > 
> > |  *TCM* |   *R5 View* | *Linux view* |
> > | R5_0 ATCM (128 KB) | 0x_ | 0xFFE0_  |
> > | R5_0 BTCM (128 KB) | 0x0002_ | 0xFFE2_  |
> > 
> > However, driver shouldn't model it as above because R5 core0 TCM and core1
> > TCM has different power-domains mapped to it.
> > Hence, TCM address space in lockstep mode should be modeled as 64KB
> > regions only where each region has its own power-domain as following:
> > 
> > |  *TCM* |   *R5 View* | *Linux view* |
> > | R5_0 ATCM0 (64 KB) | 0x_ | 0xFFE0_  |
> > | R5_0 BTCM0 (64 KB) | 0x0002_ | 0xFFE2_  |
> > | R5_0 ATCM1 (64 KB) | 0x0001_ | 0xFFE1_  |
> > | R5_0 BTCM1 (64 KB) | 0x0003_ | 0xFFE3_  |
> > 
> > This makes driver maintanance easy and makes design robust for future
> > platorms as well.
> > 
> > Signed-off-by: Tanmay Shah 
>
> Now that I have a clearer picture of where things are going, I am adding this
> patch to rproc-next.
>
> I'll wait for the DT crew for the rest of this set.

Hi Mathieu,

Is it okay if we wait for DT crew to clear new bindings as well before taking 
this one to rproc-next ?

Just in case any modifications needed further?


Tanmay


>
> Thanks,
> Mathieu
>
> > ---
> >  drivers/remoteproc/xlnx_r5_remoteproc.c | 145 ++--
> >  1 file changed, 12 insertions(+), 133 deletions(-)
> > 
> > diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
> > b/drivers/remoteproc/xlnx_r5_remoteproc.c
> > index 4395edea9a64..42b0384d34f2 100644
> > --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> > +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> > @@ -84,12 +84,12 @@ static const struct mem_bank_data 
> > zynqmp_tcm_banks_split[] = {
> > {0xffebUL, 0x2, 0x1UL, PD_R5_1_BTCM, "btcm1"},
> >  };
> >  
> > -/* In lockstep mode cluster combines each 64KB TCM and makes 128KB TCM */
> > +/* In lockstep mode cluster uses each 64KB TCM from second core as well */
> >  static const struct mem_bank_data zynqmp_tcm_banks_lockstep[] = {
> > -   {0xffe0UL, 0x0, 0x2UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 128KB 
> > each */
> > -   {0xffe2UL, 0x2, 0x2UL, PD_R5_0_BTCM, "btcm0"},
> > -   {0, 0, 0, PD_R5_1_ATCM, ""},
> > -   {0, 0, 0, PD_R5_1_BTCM, ""},
> > +   {0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each 
> > */
> > +   {0xffe2UL, 0x2, 0x1UL, PD_R5_0_BTCM, "btcm0"},
> > +   {0xffe1UL, 0x1, 0x1UL, PD_R5_1_ATCM, "atcm1"},
> > +   {0xffe3UL, 0x3, 0x1UL, PD_R5_1_BTCM, "btcm1"},
> >  };
> >  
> >  /**
> > @@ -540,14 +540,14 @@ static int tcm_mem_map(struct rproc *rproc,
> >  }
> >  
> >  /*
> > - * add_tcm_carveout_split_mode()
> > + * add_tcm_banks()
> >   * @rproc: single R5 core's corresponding rproc instance
> >   *
> > - * allocate and add remoteproc carveout for TCM memory in split mode
> > + * allocate and add remoteproc carveout for TCM memory
> >   *
> >   * return 0 on success, otherwise non-zero value on failure
> >   */
> > -static int add_tcm_carveout_split_mode(struct rproc *rproc)
> > +static int add_tcm_banks(struct rproc *rproc)
> >  {
> > struct rproc_mem_entry *rproc_mem;
> > struct zynqmp_r5_core *r5_core;
> > @@ -580,10 +580,10 @@ static int add_tcm_carveout_split_mode(struct rproc 
> > *rproc)
> >  ZYNQMP_PM_REQUEST_ACK_BLOCKING);
> > if (ret < 0) {
> > dev_err(dev, "failed to turn on TCM 0x%x", 
> > pm_domain_id);
> > -   goto release_tcm_split;
> > +   goto release_tcm;
> > }
> >  
> > -   dev_dbg(dev, "TCM carveout split mode %s addr=%llx, da=0x%x, 
> > size=0x%lx",
> > +   dev_dbg(dev, "TCM carveout %s addr=%llx, da=0x%x, size=0x%lx",
> > bank_name, bank_addr, da, bank_size);
> >  
> > rproc_mem = rproc_mem_entry_init(dev, NULL, bank_addr,
> > @@ -593,7 +593,7 @@ static int add_tcm_carveout_split_mode(struct rproc 
> > *rproc)
> 

Re: [PATCH v11 2/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings

[Tanmay Shah]

Thanks for reviews.

Ack to all comments, I will address in next revision.


Tanmay

On 2/29/24 3:59 AM, Krzysztof Kozlowski wrote:
> On 19/02/2024 18:44, Tanmay Shah wrote:
> > From: Radhey Shyam Pandey 
> > 
> > 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 
> > Signed-off-by: Tanmay Shah 
> > ---
> > 
> > Changes in v11:
> >   - Fix yamllint warning and reduce indentation as needed
> > 
> >  .../remoteproc/xlnx,zynqmp-r5fss.yaml | 192 --
> >  1 file changed, 170 insertions(+), 22 deletions(-)
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml 
> > b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
> > index 78aac69f1060..77030edf41fa 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,9 +66,6 @@ patternProperties:
> >compatible:
> >  const: xlnx,zynqmp-r5f
> >  
> > -  power-domains:
> > -maxItems: 1
>
> Why power-domains are being dropped? This should have widest constraints
> if you later customize it.
>
> > -
> >mboxes:
> >  minItems: 1
> >  items:
> > @@ -101,35 +110,174 @@ patternProperties:
> >  
> >  required:
> >- compatible
> > -  - power-domains
>
> Don't drop power domains.
>
>
> >  
> > -unevaluatedProperties: false
> > +allOf:
>
> allOf block goes after required:
>
> > +  - if:
> > +  properties:
> > +xlnx,cluster-mode:
> > +  enum:
> > +- 1
> > +then:
> > +  patternProperties:
> > +"^r5f@[0-9a-f]+$":
> > +  type: object
> > +
> > +  properties:
> > +reg:
>
> reg is missing in your patternProperties earlier.
>
>
>
> Best regards,
> Krzysztof
>

[PATCH v12 0/4] add zynqmp TCM bindings

[Tanmay Shah]

revious v4 version link:
https://lore.kernel.org/all/20230829181900.2561194-1-tanmay.s...@amd.com/

Previous v3 version link:
https://lore.kernel.org/all/1689964908-22371-1-git-send-email-radhey.shyam.pan...@amd.com/
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

[PATCH v12 1/4] remoteproc: zynqmp: fix lockstep mode memory region

[Tanmay Shah]

In lockstep mode, r5 core0 uses TCM of R5 core1. Following is lockstep
mode memory region as per hardware reference manual.

|  *TCM* |   *R5 View* | *Linux view* |
| R5_0 ATCM (128 KB) | 0x_ | 0xFFE0_  |
| R5_0 BTCM (128 KB) | 0x0002_ | 0xFFE2_  |

However, driver shouldn't model it as above because R5 core0 TCM and core1
TCM has different power-domains mapped to it.
Hence, TCM address space in lockstep mode should be modeled as 64KB
regions only where each region has its own power-domain as following:

|  *TCM* |   *R5 View* | *Linux view* |
| R5_0 ATCM0 (64 KB) | 0x_ | 0xFFE0_  |
| R5_0 BTCM0 (64 KB) | 0x0002_ | 0xFFE2_  |
| R5_0 ATCM1 (64 KB) | 0x0001_ | 0xFFE1_  |
| R5_0 BTCM1 (64 KB) | 0x0003_ | 0xFFE3_  |

This makes driver maintanance easy and makes design robust for future
platorms as well.

Signed-off-by: Tanmay Shah 
---

Changes in v12:
  - None

 drivers/remoteproc/xlnx_r5_remoteproc.c | 145 ++--
 1 file changed, 12 insertions(+), 133 deletions(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 4395edea9a64..42b0384d34f2 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -84,12 +84,12 @@ static const struct mem_bank_data zynqmp_tcm_banks_split[] 
= {
{0xffebUL, 0x2, 0x1UL, PD_R5_1_BTCM, "btcm1"},
 };
 
-/* In lockstep mode cluster combines each 64KB TCM and makes 128KB TCM */
+/* In lockstep mode cluster uses each 64KB TCM from second core as well */
 static const struct mem_bank_data zynqmp_tcm_banks_lockstep[] = {
-   {0xffe0UL, 0x0, 0x2UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 128KB 
each */
-   {0xffe2UL, 0x2, 0x2UL, PD_R5_0_BTCM, "btcm0"},
-   {0, 0, 0, PD_R5_1_ATCM, ""},
-   {0, 0, 0, PD_R5_1_BTCM, ""},
+   {0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each 
*/
+   {0xffe2UL, 0x2, 0x1UL, PD_R5_0_BTCM, "btcm0"},
+   {0xffe1UL, 0x1, 0x1UL, PD_R5_1_ATCM, "atcm1"},
+   {0xffe3UL, 0x3, 0x1UL, PD_R5_1_BTCM, "btcm1"},
 };
 
 /**
@@ -540,14 +540,14 @@ static int tcm_mem_map(struct rproc *rproc,
 }
 
 /*
- * add_tcm_carveout_split_mode()
+ * add_tcm_banks()
  * @rproc: single R5 core's corresponding rproc instance
  *
- * allocate and add remoteproc carveout for TCM memory in split mode
+ * allocate and add remoteproc carveout for TCM memory
  *
  * return 0 on success, otherwise non-zero value on failure
  */
-static int add_tcm_carveout_split_mode(struct rproc *rproc)
+static int add_tcm_banks(struct rproc *rproc)
 {
struct rproc_mem_entry *rproc_mem;
struct zynqmp_r5_core *r5_core;
@@ -580,10 +580,10 @@ static int add_tcm_carveout_split_mode(struct rproc 
*rproc)
 ZYNQMP_PM_REQUEST_ACK_BLOCKING);
if (ret < 0) {
dev_err(dev, "failed to turn on TCM 0x%x", 
pm_domain_id);
-   goto release_tcm_split;
+   goto release_tcm;
}
 
-   dev_dbg(dev, "TCM carveout split mode %s addr=%llx, da=0x%x, 
size=0x%lx",
+   dev_dbg(dev, "TCM carveout %s addr=%llx, da=0x%x, size=0x%lx",
bank_name, bank_addr, da, bank_size);
 
rproc_mem = rproc_mem_entry_init(dev, NULL, bank_addr,
@@ -593,7 +593,7 @@ static int add_tcm_carveout_split_mode(struct rproc *rproc)
if (!rproc_mem) {
ret = -ENOMEM;
zynqmp_pm_release_node(pm_domain_id);
-   goto release_tcm_split;
+   goto release_tcm;
}
 
rproc_add_carveout(rproc, rproc_mem);
@@ -601,7 +601,7 @@ static int add_tcm_carveout_split_mode(struct rproc *rproc)
 
return 0;
 
-release_tcm_split:
+release_tcm:
/* If failed, Turn off all TCM banks turned on before */
for (i--; i >= 0; i--) {
pm_domain_id = r5_core->tcm_banks[i]->pm_domain_id;
@@ -610,127 +610,6 @@ static int add_tcm_carveout_split_mode(struct rproc 
*rproc)
return ret;
 }
 
-/*
- * add_tcm_carveout_lockstep_mode()
- * @rproc: single R5 core's corresponding rproc instance
- *
- * allocate and add remoteproc carveout for TCM memory in lockstep mode
- *
- * return 0 on success, otherwise non-zero value on failure
- */
-static int add_tcm_carveout_lockstep_mode(struct rproc *rproc)
-{
-   struct rproc_mem_entry *rproc_mem;
-   struct zynqmp_r5_core *r5_core;
-   int i, num_banks, ret;
-   phys_addr_t bank_addr;
-   size_t bank_size = 0;
-   struct device *dev;
-   u32 pm_domain_id;
-  

[PATCH v12 4/4] remoteproc: zynqmp: parse TCM from device tree

[Tanmay Shah]

ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
is available in device-tree. Parse TCM information in driver
as per new bindings.

Signed-off-by: Tanmay Shah 
---

Changes in v12:
  - None

Changes in v11:
  - Remove redundant initialization of the variable
  - return correct error code if memory allocation failed

 drivers/remoteproc/xlnx_r5_remoteproc.c | 112 ++--
 1 file changed, 107 insertions(+), 5 deletions(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 42b0384d34f2..d4a22caebaad 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -74,8 +74,8 @@ struct mbox_info {
 };
 
 /*
- * Hardcoded TCM bank values. This will be removed once TCM bindings are
- * accepted for system-dt specifications and upstreamed in linux kernel
+ * Hardcoded TCM bank values. This will stay in driver to maintain backward
+ * compatibility with device-tree that does not have TCM information.
  */
 static const struct mem_bank_data zynqmp_tcm_banks_split[] = {
{0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each 
*/
@@ -757,6 +757,103 @@ static struct zynqmp_r5_core 
*zynqmp_r5_add_rproc_core(struct device *cdev)
return ERR_PTR(ret);
 }
 
+static int zynqmp_r5_get_tcm_node_from_dt(struct zynqmp_r5_cluster *cluster)
+{
+   int i, j, tcm_bank_count, ret, tcm_pd_idx, pd_count;
+   struct of_phandle_args out_args;
+   struct zynqmp_r5_core *r5_core;
+   struct platform_device *cpdev;
+   struct mem_bank_data *tcm;
+   struct device_node *np;
+   struct resource *res;
+   u64 abs_addr, size;
+   struct device *dev;
+
+   for (i = 0; i < cluster->core_count; i++) {
+   r5_core = cluster->r5_cores[i];
+   dev = r5_core->dev;
+   np = r5_core->np;
+
+   pd_count = of_count_phandle_with_args(np, "power-domains",
+ "#power-domain-cells");
+
+   if (pd_count <= 0) {
+   dev_err(dev, "invalid power-domains property, %d\n", 
pd_count);
+   return -EINVAL;
+   }
+
+   /* First entry in power-domains list is for r5 core, rest for 
TCM. */
+   tcm_bank_count = pd_count - 1;
+
+   if (tcm_bank_count <= 0) {
+   dev_err(dev, "invalid TCM count %d\n", tcm_bank_count);
+   return -EINVAL;
+   }
+
+   r5_core->tcm_banks = devm_kcalloc(dev, tcm_bank_count,
+ sizeof(struct mem_bank_data 
*),
+ GFP_KERNEL);
+   if (!r5_core->tcm_banks)
+   return -ENOMEM;
+
+   r5_core->tcm_bank_count = tcm_bank_count;
+   for (j = 0, tcm_pd_idx = 1; j < tcm_bank_count; j++, 
tcm_pd_idx++) {
+   tcm = devm_kzalloc(dev, sizeof(struct mem_bank_data),
+  GFP_KERNEL);
+   if (!tcm)
+   return -ENOMEM;
+
+   r5_core->tcm_banks[j] = tcm;
+
+   /* Get power-domains id of TCM. */
+   ret = of_parse_phandle_with_args(np, "power-domains",
+"#power-domain-cells",
+tcm_pd_idx, &out_args);
+   if (ret) {
+   dev_err(r5_core->dev,
+   "failed to get tcm %d pm domain, ret 
%d\n",
+   tcm_pd_idx, ret);
+   return ret;
+   }
+   tcm->pm_domain_id = out_args.args[0];
+   of_node_put(out_args.np);
+
+   /* Get TCM address without translation. */
+   ret = of_property_read_reg(np, j, &abs_addr, &size);
+   if (ret) {
+   dev_err(dev, "failed to get reg property\n");
+   return ret;
+   }
+
+   /*
+* Remote processor can address only 32 bits
+* so convert 64-bits into 32-bits. This will discard
+* any unwanted upper 32-bits.
+*/
+   tcm->da = (u32)abs_addr;
+   tcm->size = (u32)size;
+
+   cpdev = to_platform_device(dev);
+   res = platform_get_resource(cpdev, IORESOURCE_MEM, j);
+ 

[PATCH v12 2/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings

[Tanmay Shah]

From: Radhey Shyam Pandey 

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 
Signed-off-by: Tanmay Shah 
---

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_mai

[PATCH v12 3/4] dts: zynqmp: add properties for TCM in remoteproc

[Tanmay Shah]

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 
---
 .../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@ffe0 {
compatible = "xlnx,zynqmp-r5fss";
xlnx,cluster-mode = <1>;
 
-   r5f-0 {
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x0 0x1 0x0 0xffe1 0x0 0x1>,
+<0x0 0x3 0x0 0xffe3 0x0 0x1>;
+
+   r5f@0 {
+   compatible = "xlnx,zynqmp-r5f";
+   reg = <0x0 0x0 0x0 0x1>,
+ <0x0 0x2 0x0 0x1>,
+ <0x0 0x1 0x0 0x1>,
+ <0x0 0x3 0x0 0x1>;
+   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 0x1>, <0x1 0x2 0x0 0x1>;
+   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@ffe0 {
+   status = "disabled";
+   compatible = "xlnx,zynqmp-r5fss";
+   xlnx,cluster-mode = <0>;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x1 0x0 0x0 0xffe9 0x0 0x1>,
+<0x1 0x2 0x0 0xffeb 0x0 0x1>;
+
+   r5f@0 {
compatible = "xlnx,zynqmp-r5f";
-   power-domains = <&zynqmp_firmware PD_RPU_0>;
+   reg = <0x0 0x0 0x0 0x1>, <0x0 0x2 0x0 0x1>;
+   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

Re: [PATCH v12 2/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings

[Tanmay Shah]

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 
> > 
> > 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 
> > Signed-off-by: Tanmay Shah 
> > ---
> > 
> > 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 memor

[PATCH v13 0/4] add zynqmp TCM bindings

[Tanmay Shah]

 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/20230829181900.2561194-1-tanmay.s...@amd.com/

Previous v3 version link:
https://lore.kernel.org/all/1689964908-22371-1-git-send-email-radhey.shyam.pan...@amd.com/

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 | 201 --
 .../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, 368 insertions(+), 163 deletions(-)


base-commit: b401b621758e46812da61fa58a67c3fd8d91de0d
-- 
2.25.1

[PATCH v13 1/4] remoteproc: zynqmp: fix lockstep mode memory region

[Tanmay Shah]

In lockstep mode, r5 core0 uses TCM of R5 core1. Following is lockstep
mode memory region as per hardware reference manual.

|  *TCM* |   *R5 View* | *Linux view* |
| R5_0 ATCM (128 KB) | 0x_ | 0xFFE0_  |
| R5_0 BTCM (128 KB) | 0x0002_ | 0xFFE2_  |

However, driver shouldn't model it as above because R5 core0 TCM and core1
TCM has different power-domains mapped to it.
Hence, TCM address space in lockstep mode should be modeled as 64KB
regions only where each region has its own power-domain as following:

|  *TCM* |   *R5 View* | *Linux view* |
| R5_0 ATCM0 (64 KB) | 0x_ | 0xFFE0_  |
| R5_0 BTCM0 (64 KB) | 0x0002_ | 0xFFE2_  |
| R5_0 ATCM1 (64 KB) | 0x0001_ | 0xFFE1_  |
| R5_0 BTCM1 (64 KB) | 0x0003_ | 0xFFE3_  |

This makes driver maintanance easy and makes design robust for future
platorms as well.

Signed-off-by: Tanmay Shah 
---
 drivers/remoteproc/xlnx_r5_remoteproc.c | 145 ++--
 1 file changed, 12 insertions(+), 133 deletions(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 4395edea9a64..42b0384d34f2 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -84,12 +84,12 @@ static const struct mem_bank_data zynqmp_tcm_banks_split[] 
= {
{0xffebUL, 0x2, 0x1UL, PD_R5_1_BTCM, "btcm1"},
 };
 
-/* In lockstep mode cluster combines each 64KB TCM and makes 128KB TCM */
+/* In lockstep mode cluster uses each 64KB TCM from second core as well */
 static const struct mem_bank_data zynqmp_tcm_banks_lockstep[] = {
-   {0xffe0UL, 0x0, 0x2UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 128KB 
each */
-   {0xffe2UL, 0x2, 0x2UL, PD_R5_0_BTCM, "btcm0"},
-   {0, 0, 0, PD_R5_1_ATCM, ""},
-   {0, 0, 0, PD_R5_1_BTCM, ""},
+   {0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each 
*/
+   {0xffe2UL, 0x2, 0x1UL, PD_R5_0_BTCM, "btcm0"},
+   {0xffe1UL, 0x1, 0x1UL, PD_R5_1_ATCM, "atcm1"},
+   {0xffe3UL, 0x3, 0x1UL, PD_R5_1_BTCM, "btcm1"},
 };
 
 /**
@@ -540,14 +540,14 @@ static int tcm_mem_map(struct rproc *rproc,
 }
 
 /*
- * add_tcm_carveout_split_mode()
+ * add_tcm_banks()
  * @rproc: single R5 core's corresponding rproc instance
  *
- * allocate and add remoteproc carveout for TCM memory in split mode
+ * allocate and add remoteproc carveout for TCM memory
  *
  * return 0 on success, otherwise non-zero value on failure
  */
-static int add_tcm_carveout_split_mode(struct rproc *rproc)
+static int add_tcm_banks(struct rproc *rproc)
 {
struct rproc_mem_entry *rproc_mem;
struct zynqmp_r5_core *r5_core;
@@ -580,10 +580,10 @@ static int add_tcm_carveout_split_mode(struct rproc 
*rproc)
 ZYNQMP_PM_REQUEST_ACK_BLOCKING);
if (ret < 0) {
dev_err(dev, "failed to turn on TCM 0x%x", 
pm_domain_id);
-   goto release_tcm_split;
+   goto release_tcm;
}
 
-   dev_dbg(dev, "TCM carveout split mode %s addr=%llx, da=0x%x, 
size=0x%lx",
+   dev_dbg(dev, "TCM carveout %s addr=%llx, da=0x%x, size=0x%lx",
bank_name, bank_addr, da, bank_size);
 
rproc_mem = rproc_mem_entry_init(dev, NULL, bank_addr,
@@ -593,7 +593,7 @@ static int add_tcm_carveout_split_mode(struct rproc *rproc)
if (!rproc_mem) {
ret = -ENOMEM;
zynqmp_pm_release_node(pm_domain_id);
-   goto release_tcm_split;
+   goto release_tcm;
}
 
rproc_add_carveout(rproc, rproc_mem);
@@ -601,7 +601,7 @@ static int add_tcm_carveout_split_mode(struct rproc *rproc)
 
return 0;
 
-release_tcm_split:
+release_tcm:
/* If failed, Turn off all TCM banks turned on before */
for (i--; i >= 0; i--) {
pm_domain_id = r5_core->tcm_banks[i]->pm_domain_id;
@@ -610,127 +610,6 @@ static int add_tcm_carveout_split_mode(struct rproc 
*rproc)
return ret;
 }
 
-/*
- * add_tcm_carveout_lockstep_mode()
- * @rproc: single R5 core's corresponding rproc instance
- *
- * allocate and add remoteproc carveout for TCM memory in lockstep mode
- *
- * return 0 on success, otherwise non-zero value on failure
- */
-static int add_tcm_carveout_lockstep_mode(struct rproc *rproc)
-{
-   struct rproc_mem_entry *rproc_mem;
-   struct zynqmp_r5_core *r5_core;
-   int i, num_banks, ret;
-   phys_addr_t bank_addr;
-   size_t bank_size = 0;
-   struct device *dev;
-   u32 pm_domain_id;
-   char *bank_name;
-   u

[PATCH v13 2/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings

[Tanmay Shah]

From: Radhey Shyam Pandey 

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 
Signed-off-by: Tanmay Shah 
---

Changes in v13:
  - Have power-domains property for lockstep case instead of
keeping it flexible.
  - Add "items:" list in power-domains property

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

 .../remoteproc/xlnx,zynqmp-r5fss.yaml | 201 --
 1 file changed, 181 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..629084a84ce6 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,175 @@ 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
+
+power-domains:
+  minItems: 2
+  items:
+- description: RPU core power domain
+- description: ATCM power domain
+- description: BTCM power domain
+- description: second ATCM power domain
+- description: second BTCM power domain
+
+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:
+  minItems: 2
+  items:
+- description: RPU core power domain
+ 

[PATCH v13 3/4] dts: zynqmp: add properties for TCM in remoteproc

[Tanmay Shah]

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 
---
 .../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@ffe0 {
compatible = "xlnx,zynqmp-r5fss";
xlnx,cluster-mode = <1>;
 
-   r5f-0 {
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x0 0x1 0x0 0xffe1 0x0 0x1>,
+<0x0 0x3 0x0 0xffe3 0x0 0x1>;
+
+   r5f@0 {
+   compatible = "xlnx,zynqmp-r5f";
+   reg = <0x0 0x0 0x0 0x1>,
+ <0x0 0x2 0x0 0x1>,
+ <0x0 0x1 0x0 0x1>,
+ <0x0 0x3 0x0 0x1>;
+   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 0x1>, <0x1 0x2 0x0 0x1>;
+   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@ffe0 {
+   status = "disabled";
+   compatible = "xlnx,zynqmp-r5fss";
+   xlnx,cluster-mode = <0>;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x1 0x0 0x0 0xffe9 0x0 0x1>,
+<0x1 0x2 0x0 0xffeb 0x0 0x1>;
+
+   r5f@0 {
compatible = "xlnx,zynqmp-r5f";
-   power-domains = <&zynqmp_firmware PD_RPU_0>;
+   reg = <0x0 0x0 0x0 0x1>, <0x0 0x2 0x0 0x1>;
+   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

[PATCH v13 4/4] remoteproc: zynqmp: parse TCM from device tree

[Tanmay Shah]

ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
is available in device-tree. Parse TCM information in driver
as per new bindings.

Signed-off-by: Tanmay Shah 
---
 drivers/remoteproc/xlnx_r5_remoteproc.c | 112 ++--
 1 file changed, 107 insertions(+), 5 deletions(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 42b0384d34f2..d4a22caebaad 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -74,8 +74,8 @@ struct mbox_info {
 };
 
 /*
- * Hardcoded TCM bank values. This will be removed once TCM bindings are
- * accepted for system-dt specifications and upstreamed in linux kernel
+ * Hardcoded TCM bank values. This will stay in driver to maintain backward
+ * compatibility with device-tree that does not have TCM information.
  */
 static const struct mem_bank_data zynqmp_tcm_banks_split[] = {
{0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each 
*/
@@ -757,6 +757,103 @@ static struct zynqmp_r5_core 
*zynqmp_r5_add_rproc_core(struct device *cdev)
return ERR_PTR(ret);
 }
 
+static int zynqmp_r5_get_tcm_node_from_dt(struct zynqmp_r5_cluster *cluster)
+{
+   int i, j, tcm_bank_count, ret, tcm_pd_idx, pd_count;
+   struct of_phandle_args out_args;
+   struct zynqmp_r5_core *r5_core;
+   struct platform_device *cpdev;
+   struct mem_bank_data *tcm;
+   struct device_node *np;
+   struct resource *res;
+   u64 abs_addr, size;
+   struct device *dev;
+
+   for (i = 0; i < cluster->core_count; i++) {
+   r5_core = cluster->r5_cores[i];
+   dev = r5_core->dev;
+   np = r5_core->np;
+
+   pd_count = of_count_phandle_with_args(np, "power-domains",
+ "#power-domain-cells");
+
+   if (pd_count <= 0) {
+   dev_err(dev, "invalid power-domains property, %d\n", 
pd_count);
+   return -EINVAL;
+   }
+
+   /* First entry in power-domains list is for r5 core, rest for 
TCM. */
+   tcm_bank_count = pd_count - 1;
+
+   if (tcm_bank_count <= 0) {
+   dev_err(dev, "invalid TCM count %d\n", tcm_bank_count);
+   return -EINVAL;
+   }
+
+   r5_core->tcm_banks = devm_kcalloc(dev, tcm_bank_count,
+ sizeof(struct mem_bank_data 
*),
+ GFP_KERNEL);
+   if (!r5_core->tcm_banks)
+   return -ENOMEM;
+
+   r5_core->tcm_bank_count = tcm_bank_count;
+   for (j = 0, tcm_pd_idx = 1; j < tcm_bank_count; j++, 
tcm_pd_idx++) {
+   tcm = devm_kzalloc(dev, sizeof(struct mem_bank_data),
+  GFP_KERNEL);
+   if (!tcm)
+   return -ENOMEM;
+
+   r5_core->tcm_banks[j] = tcm;
+
+   /* Get power-domains id of TCM. */
+   ret = of_parse_phandle_with_args(np, "power-domains",
+"#power-domain-cells",
+tcm_pd_idx, &out_args);
+   if (ret) {
+   dev_err(r5_core->dev,
+   "failed to get tcm %d pm domain, ret 
%d\n",
+   tcm_pd_idx, ret);
+   return ret;
+   }
+   tcm->pm_domain_id = out_args.args[0];
+   of_node_put(out_args.np);
+
+   /* Get TCM address without translation. */
+   ret = of_property_read_reg(np, j, &abs_addr, &size);
+   if (ret) {
+   dev_err(dev, "failed to get reg property\n");
+   return ret;
+   }
+
+   /*
+* Remote processor can address only 32 bits
+* so convert 64-bits into 32-bits. This will discard
+* any unwanted upper 32-bits.
+*/
+   tcm->da = (u32)abs_addr;
+   tcm->size = (u32)size;
+
+   cpdev = to_platform_device(dev);
+   res = platform_get_resource(cpdev, IORESOURCE_MEM, j);
+   if (!res) {
+   dev_err(dev, "failed to get tcm resource\n");
+   return -EINVAL;
+   

Re: [PATCH v12 2/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings

[Tanmay Shah]

On 3/9/24 7:25 AM, Krzysztof Kozlowski wrote:
> On 01/03/2024 19:16, Tanmay Shah wrote:
> > From: Radhey Shyam Pandey 
> > 
> > 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 
> > Signed-off-by: Tanmay Shah 
> > ---
> > 
> > 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 i

Re: [PATCH v12 2/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings

[Tanmay Shah]

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
>

Re: [PATCH v12 2/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings

[Tanmay Shah]

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
>

Re: [PATCH v13 2/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings

[Tanmay Shah]

On 3/12/24 7:13 AM, Krzysztof Kozlowski wrote:
> On 11/03/2024 18:59, Tanmay Shah wrote:
>> From: Radhey Shyam Pandey 
>> 
>> 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 
>> Signed-off-by: Tanmay Shah 
>> ---
>> 
>> Changes in v13:
>>   - Have power-domains property for lockstep case instead of
>> keeping it flexible.
>>   - Add "items:" list in power-domains property
> 
> 
> Reviewed-by: Krzysztof Kozlowski 

Hi Krzysztof,

Thanks for RB. I provided explanation of flexible power-domains in
previous patchset. I am happy to send new revision removing
minItems if you dis-agree.

Thanks.

> 
> Best regards,
> Krzysztof
> 

[PATCH 0/3] Add Versal and Versal-NET platform support

[Tanmay Shah]

AMD-Xilinx Versal platform is successor of ZynqMP platform. Real-time
Processing Unit R5 cluster IP on Versal is same as of ZynqMP Platform.
Add bindings example for Versal remoteproc node. ZynqMP driver is
comatible for Versal's RPU unit.

AMD-Xilinx Versal-NET platform is successor of Versal platform.
Versal-NET Real-Time Processing Unit has two clusters and each cluster
contains dual core ARM Cortex-R52 processors. Each R52 core is
assigned 128KB of TCM memory.
Add bindings and example node of Versal-NET RPU. Add Versal-NET support
in ZynqMP remoteproc driver.

This series depends on follwoing series:
Link: https://lore.kernel.org/all/20240311175926.1625180-1-tanmay.s...@amd.com/
title: add zynqmp TCM bindings

Tanmay Shah (3):
  dt-bindings: remoteproc: add Versal platform support
  dt-bindings: remoteproc: add Versal-NET platform
  drivers: remoteproc: add Versal and Versal-NET support

 .../remoteproc/xlnx,zynqmp-r5fss.yaml | 313 --
 drivers/remoteproc/xlnx_r5_remoteproc.c   |  19 +-
 2 files changed, 292 insertions(+), 40 deletions(-)

base-commit: e8f897f4afef0031fe618a8e94127a0934896aba
prerequisite-patch-id: ecf2ff9fd2f2a9a39f55f961b52a5414ea2f2962
prerequisite-patch-id: ff02d06bb3dbd13258cd5748c7486c363bd60478
prerequisite-patch-id: 4869c001ae65dfedaa2e481a3119de03b44a31c5
prerequisite-patch-id: 95e214bf94bce74d86972ea229186f602b5375ae
-- 
2.25.1

[PATCH 2/3] dt-bindings: remoteproc: add Versal-NET platform

[Tanmay Shah]

AMD-Xilinx Versal-NET platform is successor of Versal platform. It
contains multiple clusters of cortex-R52 real-time processing units.
Each cluster contains two cores of cortex-R52 processors. Each cluster
can be configured in lockstep mode or split mode.

Each R52 core is assigned 128KB of TCM memory. ATCM memory is 64KB, BTCM
and CTCM memoreis are 32KB each. Each TCM memory has its own dedicated
power-domain that needs to be requested before using it.

Signed-off-by: Tanmay Shah 
---
 .../remoteproc/xlnx,zynqmp-r5fss.yaml | 220 +++---
 1 file changed, 184 insertions(+), 36 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml 
b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
index 711da0272250..55654ee02eef 100644
--- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
@@ -18,7 +18,9 @@ description: |
 
 properties:
   compatible:
-const: xlnx,zynqmp-r5fss
+enum:
+  - xlnx,zynqmp-r5fss
+  - xlnx,versal-net-r52fss
 
   "#address-cells":
 const: 2
@@ -64,7 +66,9 @@ patternProperties:
 
 properties:
   compatible:
-const: xlnx,zynqmp-r5f
+enum:
+  - xlnx,zynqmp-r5f
+  - xlnx,versal-net-r52f
 
   reg:
 minItems: 1
@@ -135,9 +139,11 @@ required:
 allOf:
   - if:
   properties:
-xlnx,cluster-mode:
-  enum:
-- 1
+compatible:
+  contains:
+enum:
+  - xlnx,versal-net-r52fss
+
 then:
   patternProperties:
 "^r5f@[0-9a-f]+$":
@@ -149,16 +155,14 @@ allOf:
   items:
 - description: ATCM internal memory
 - description: BTCM internal memory
-- description: extra ATCM memory in lockstep mode
-- description: extra BTCM memory in lockstep mode
+- description: CTCM internal memory
 
 reg-names:
   minItems: 1
   items:
-- const: atcm0
-- const: btcm0
-- const: atcm1
-- const: btcm1
+- const: atcm
+- const: btcm
+- const: ctcm
 
 power-domains:
   minItems: 2
@@ -166,33 +170,70 @@ allOf:
 - description: RPU core power domain
 - description: ATCM power domain
 - description: BTCM power domain
-- description: second ATCM power domain
-- description: second BTCM power domain
+- description: CTCM power domain
 
 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:
-  minItems: 2
-  items:
-- description: RPU core power domain
-- description: ATCM power domain
-- description: BTCM power domain
+  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
+
+  power-domains:
+minItems: 2
+items:
+  - description: RPU core power domain
+  - description: ATCM power domain
+  - description: BTCM power domain
+  - description: second ATCM power domain
+  - description: second BTCM power domain
+
+  else:
+patternProperties:
+  "^r5f@[0-9a-f]+$":
+type: object
+
+properties:
+  reg:
+minItems: 1
+items:
+  - description: ATCM internal memory
+   

[PATCH 3/3] drivers: remoteproc: add Versal and Versal-NET support

[Tanmay Shah]

AMD-Xilinx Versal and Versal-NET are successor of ZynqMP platform. ZynqMP
remoteproc driver is mostly compatible with new platforms except few
platform specific differences.

Versal has same IP of cortex-R5 cores hence maintained compatible string
same as ZynqMP platform. However, hardcode TCM addresses are not
supported for new platforms and must be provided in device-tree as per
new bindings. This makes TCM representation data-driven and easy to
maintain. This check is provided in the driver.

For Versal-NET platform, TCM doesn't need to be configured in lockstep
mode or split mode. Hence that call to PMC firmware is avoided in the
driver for Versal-NET platform.

Signed-off-by: Tanmay Shah 
---
 drivers/remoteproc/xlnx_r5_remoteproc.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index d4a22caebaad..193bc159d1b4 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -323,9 +323,12 @@ static int zynqmp_r5_set_mode(struct zynqmp_r5_core 
*r5_core,
return ret;
}
 
-   ret = zynqmp_pm_set_tcm_config(r5_core->pm_domain_id, tcm_mode);
-   if (ret < 0)
-   dev_err(r5_core->dev, "failed to configure TCM\n");
+   /* TCM configuration is not needed in versal-net */
+   if (device_is_compatible(r5_core->dev, "xlnx,zynqmp-r5f")) {
+   ret = zynqmp_pm_set_tcm_config(r5_core->pm_domain_id, tcm_mode);
+   if (ret < 0)
+   dev_err(r5_core->dev, "failed to configure TCM\n");
+   }
 
return ret;
 }
@@ -933,10 +936,17 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster 
*cluster,
int ret, i;
 
r5_core = cluster->r5_cores[0];
+
+   /*
+* New platforms must use device tree for TCM parsing.
+* Only ZynqMP uses hardcode TCM.
+*/
if (of_find_property(r5_core->np, "reg", NULL))
ret = zynqmp_r5_get_tcm_node_from_dt(cluster);
-   else
+   else if (of_machine_is_compatible("xlnx,zynqmp"))
ret = zynqmp_r5_get_tcm_node(cluster);
+   else
+   ret = -EINVAL;
 
if (ret) {
dev_err(dev, "can't get tcm, err %d\n", ret);
@@ -1198,6 +1208,7 @@ static int zynqmp_r5_remoteproc_probe(struct 
platform_device *pdev)
 /* Match table for OF platform binding */
 static const struct of_device_id zynqmp_r5_remoteproc_match[] = {
{ .compatible = "xlnx,zynqmp-r5fss", },
+   { .compatible = "xlnx,versal-net-r52fss", },
{ /* end of list */ },
 };
 MODULE_DEVICE_TABLE(of, zynqmp_r5_remoteproc_match);
-- 
2.25.1

[PATCH 1/3] dt-bindings: remoteproc: add Versal platform support

[Tanmay Shah]

AMD-Xilinx Versal platform is successor of ZynqMP platform. Real-time
Processor Unit R5 cluster IP on Versal is same as of ZynqMP Platform.
Only difference is power-domains ID needed by power management firmware.
Hence, keeping the compatible property same as of zynqmp node.

Signed-off-by: Tanmay Shah 
---
 .../remoteproc/xlnx,zynqmp-r5fss.yaml | 93 +++
 1 file changed, 93 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml 
b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
index 629084a84ce6..711da0272250 100644
--- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
@@ -293,4 +293,97 @@ examples:
 };
 };
 };
+
+  - |
+// Versal Split mode configuration
+soc {
+#address-cells = <2>;
+#size-cells = <2>;
+
+remoteproc@ffe0 {
+compatible = "xlnx,zynqmp-r5fss";
+xlnx,cluster-mode = <0>;
+
+#address-cells = <2>;
+#size-cells = <2>;
+ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+ <0x0 0x2 0x0 0xffe2 0x0 0x1>,
+ <0x1 0x0 0x0 0xffe9 0x0 0x1>,
+ <0x1 0x2 0x0 0xffeb 0x0 0x1>;
+
+r5f@0 {
+compatible = "xlnx,zynqmp-r5f";
+reg = <0x0 0x0 0x0 0x1>, <0x0 0x2 0x0 0x1>;
+reg-names = "atcm0", "btcm0";
+power-domains = <&versal_firmware 0x18110005>,
+<&versal_firmware 0x1831800b>,
+<&versal_firmware 0x1831800c>;
+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 0x1>, <0x1 0x2 0x0 0x1>;
+reg-names = "atcm0", "btcm0";
+power-domains = <&versal_firmware 0x18110006>,
+<&versal_firmware 0x1831800d>,
+<&versal_firmware 0x1831800e>;
+memory-region = <&rproc_1_fw_image>, <&rpu1vdev0buffer>,
+<&rpu1vdev0vring0>, <&rpu1vdev0vring1>;
+mboxes = <&ipi_mailbox_rpu1 0>, <&ipi_mailbox_rpu1 1>;
+mbox-names = "tx", "rx";
+};
+};
+};
+
+  - |
+// Versal Lockstep configuration
+soc {
+#address-cells = <2>;
+#size-cells = <2>;
+
+remoteproc@ffe0 {
+compatible = "xlnx,zynqmp-r5fss";
+xlnx,cluster-mode = <1>;
+
+#address-cells = <2>;
+#size-cells = <2>;
+ranges = <0x0 0x0 0x0 0xffe0 0x0 0x2>,
+ <0x0 0x2 0x0 0xffe2 0x0 0x2>;
+
+r5f@0 {
+compatible = "xlnx,zynqmp-r5f";
+reg = <0x0 0x0 0x0 0x1>,
+  <0x0 0x2 0x0 0x1>,
+  <0x0 0x1 0x0 0x1>,
+  <0x0 0x3 0x0 0x1>;
+reg-names = "atcm0", "btcm0", "atcm1", "btcm1";
+power-domains = <&versal_firmware 0x18110005>,
+<&versal_firmware 0x1831800b>,
+<&versal_firmware 0x1831800c>,
+<&versal_firmware 0x1831800d>,
+<&versal_firmware 0x1831800e>;
+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 0x1>, <0x1 0x2 0x0 0x1>;
+reg-names = "atcm0", "btcm0";
+power-domains = <&versal_firmware 0x18110006>,
+<&versal_firmware 0x1831800d>,
+<&versal_firmware 0x1831800e>;
+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

Re: [PATCH 1/3] dt-bindings: remoteproc: add Versal platform support

[Tanmay Shah]

Hello,

Thanks for reviews, please find my comments below.

On 3/17/24 9:50 AM, Conor Dooley wrote:
> On Fri, Mar 15, 2024 at 02:15:31PM -0700, Tanmay Shah wrote:
>> AMD-Xilinx Versal platform is successor of ZynqMP platform. Real-time
>> Processor Unit R5 cluster IP on Versal is same as of ZynqMP Platform.
> 
>> Only difference is power-domains ID needed by power management firmware.
>> Hence, keeping the compatible property same as of zynqmp node.
> 
> No, don't be lazy. Add a compatible with a fallback please.

It's same IP on different platform. I am not sure how adding compatible string
adds value. I will refactor this series based on other comments provided.

> This doesn't apply to linux-next either FYI.

Actually cover-letter contains dependent series link that is needed for this
patch. That series was acked recently but hasn't made to linux-next yet.

I may be missing something in the process. In such case there is no other way
to send patch except for waiting?

Thanks,
Tanmay

Re: [PATCH 1/3] dt-bindings: remoteproc: add Versal platform support

[Tanmay Shah]

On 3/17/24 1:50 PM, Krzysztof Kozlowski wrote:
> On 15/03/2024 22:15, Tanmay Shah wrote:
>> AMD-Xilinx Versal platform is successor of ZynqMP platform. Real-time
>> Processor Unit R5 cluster IP on Versal is same as of ZynqMP Platform.
>> Only difference is power-domains ID needed by power management firmware.
>> Hence, keeping the compatible property same as of zynqmp node.
>> 
>> Signed-off-by: Tanmay Shah 
> 
> There is no binding change, so NAK. Platform is not being added to
> examples. You changed nothing in  Versal support...

Thanks for reviews.

Okay got it. That means I don't really need to add anything related to Versal.
I will get rid of patch that says "Versal support". Looks like it's not needed
at all.

Thanks.

> 
> Best regards,
> Krzysztof
> 

Re: [PATCH 2/3] dt-bindings: remoteproc: add Versal-NET platform

[Tanmay Shah]

Hello Krzysztof,

Thanks for reviews. Please find my comments below.

On 3/17/24 1:53 PM, Krzysztof Kozlowski wrote:
> On 15/03/2024 22:15, Tanmay Shah wrote:
>> AMD-Xilinx Versal-NET platform is successor of Versal platform. It
>> contains multiple clusters of cortex-R52 real-time processing units.
>> Each cluster contains two cores of cortex-R52 processors. Each cluster
>> can be configured in lockstep mode or split mode.
>> 
>> Each R52 core is assigned 128KB of TCM memory. ATCM memory is 64KB, BTCM
>> and CTCM memoreis are 32KB each. Each TCM memory has its own dedicated
>> power-domain that needs to be requested before using it.
>> 
>> Signed-off-by: Tanmay Shah 
>> ---
>>  .../remoteproc/xlnx,zynqmp-r5fss.yaml | 220 +++---
>>  1 file changed, 184 insertions(+), 36 deletions(-)
>> 
>> diff --git 
>> a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml 
>> b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>> index 711da0272250..55654ee02eef 100644
>> --- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>> +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>> @@ -18,7 +18,9 @@ description: |
>>  
>>  properties:
>>compatible:
>> -const: xlnx,zynqmp-r5fss
>> +enum:
>> +  - xlnx,zynqmp-r5fss
>> +  - xlnx,versal-net-r52fss
>>  
>>"#address-cells":
>>  const: 2
>> @@ -64,7 +66,9 @@ patternProperties:
>>  
>>  properties:
>>compatible:
>> -const: xlnx,zynqmp-r5f
>> +enum:
>> +  - xlnx,zynqmp-r5f
>> +  - xlnx,versal-net-r52f
>>  
>>reg:
>>  minItems: 1
>> @@ -135,9 +139,11 @@ required:
>>  allOf:
>>- if:
>>properties:
>> -xlnx,cluster-mode:
>> -  enum:
>> -- 1
>> +compatible:
>> +  contains:
>> +enum:
>> +  - xlnx,versal-net-r52fss
> 
> Why do you touch these lines?
> 
>> +
>>  then:
>>patternProperties:
>>  "^r5f@[0-9a-f]+$":
>> @@ -149,16 +155,14 @@ allOf:
>>items:
>>  - description: ATCM internal memory
>>  - description: BTCM internal memory
>> -- description: extra ATCM memory in lockstep mode
>> -- description: extra BTCM memory in lockstep mode
>> +- description: CTCM internal memory
>>  
>>  reg-names:
>>minItems: 1
>>items:
>> -- const: atcm0
>> -- const: btcm0
>> -- const: atcm1
>> -- const: btcm1
>> +- const: atcm
>> +- const: btcm
>> +- const: ctcm
>>  
>>  power-domains:
>>minItems: 2
>> @@ -166,33 +170,70 @@ allOf:
>>  - description: RPU core power domain
>>  - description: ATCM power domain
>>  - description: BTCM power domain
>> -- description: second ATCM power domain
>> -- description: second BTCM power domain
>> +- description: CTCM power domain
>>  
>>  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:
>> -  minItems: 2
>> -  items:
>> -- description: RPU core power domain
>> -- description: ATCM power domain
>> -- description: BTCM power domain
>> +  allOf:
>> +- if:
>> +properties:
>> +  xlnx,cluster-mode:
>> +enum:
>> +  - 1
> 
> Whatever you did here, is not really readable. You have now multiple
> if:then:if:then embedded.

For ZynqMP platform, TCM can be configured differently in lockste

Re: [PATCH 3/3] drivers: remoteproc: add Versal and Versal-NET support

[Tanmay Shah]

On 3/17/24 1:55 PM, Krzysztof Kozlowski wrote:
> On 15/03/2024 22:15, Tanmay Shah wrote:
>> AMD-Xilinx Versal and Versal-NET are successor of ZynqMP platform. ZynqMP
>> remoteproc driver is mostly compatible with new platforms except few
>> platform specific differences.
>> 
>> Versal has same IP of cortex-R5 cores hence maintained compatible string
>> same as ZynqMP platform. However, hardcode TCM addresses are not
>> supported for new platforms and must be provided in device-tree as per
>> new bindings. This makes TCM representation data-driven and easy to
>> maintain. This check is provided in the driver.
>> 
>> For Versal-NET platform, TCM doesn't need to be configured in lockstep
>> mode or split mode. Hence that call to PMC firmware is avoided in the
>> driver for Versal-NET platform.
>> 
>> Signed-off-by: Tanmay Shah 
>> ---
>>  drivers/remoteproc/xlnx_r5_remoteproc.c | 19 +++
>>  1 file changed, 15 insertions(+), 4 deletions(-)
>> 
>> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
>> b/drivers/remoteproc/xlnx_r5_remoteproc.c
>> index d4a22caebaad..193bc159d1b4 100644
>> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
>> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
>> @@ -323,9 +323,12 @@ static int zynqmp_r5_set_mode(struct zynqmp_r5_core 
>> *r5_core,
>>  return ret;
>>  }
>>  
>> -ret = zynqmp_pm_set_tcm_config(r5_core->pm_domain_id, tcm_mode);
>> -if (ret < 0)
>> -dev_err(r5_core->dev, "failed to configure TCM\n");
>> +/* TCM configuration is not needed in versal-net */
>> +if (device_is_compatible(r5_core->dev, "xlnx,zynqmp-r5f")) {
>> +ret = zynqmp_pm_set_tcm_config(r5_core->pm_domain_id, tcm_mode);
>> +if (ret < 0)
>> +dev_err(r5_core->dev, "failed to configure TCM\n");
>> +}
>>  
>>  return ret;
>>  }
>> @@ -933,10 +936,17 @@ static int zynqmp_r5_core_init(struct 
>> zynqmp_r5_cluster *cluster,
>>  int ret, i;
>>  
>>  r5_core = cluster->r5_cores[0];
>> +
>> +/*
>> + * New platforms must use device tree for TCM parsing.
>> + * Only ZynqMP uses hardcode TCM.
>> + */
>>  if (of_find_property(r5_core->np, "reg", NULL))
>>  ret = zynqmp_r5_get_tcm_node_from_dt(cluster);
>> -else
>> +else if (of_machine_is_compatible("xlnx,zynqmp"))
>>  ret = zynqmp_r5_get_tcm_node(cluster);
> 
> That's poor code. Your drivers should not depend on platform. I don't
> understand why you need to do this and how is even related to this patch.

You are correct, ideally this shouldn't be needed. However, this driver contains
hardcode TCM addresses that were used before TCM bindings were designed and 
available in
device-tree. This check is provided to maintain backward compatibility with 
device-tree
where TCM isn't expected.

For new platforms (Versal and Versal-NET) TCM must be provided in device-tree 
and for
ZynqMP if it's not in device-tree then to maintain backward compatibility 
hardcode
addresses are used.

Thanks.


> 
> 
> Best regards,
> Krzysztof
> 

Re: [PATCH 2/3] dt-bindings: remoteproc: add Versal-NET platform

[Tanmay Shah]

On 3/19/24 12:30 AM, Krzysztof Kozlowski wrote:
> On 19/03/2024 01:51, Tanmay Shah wrote:
>> Hello Krzysztof,
>> 
>> Thanks for reviews. Please find my comments below.
>> 
>> On 3/17/24 1:53 PM, Krzysztof Kozlowski wrote:
>>> On 15/03/2024 22:15, Tanmay Shah wrote:
>>>> AMD-Xilinx Versal-NET platform is successor of Versal platform. It
>>>> contains multiple clusters of cortex-R52 real-time processing units.
>>>> Each cluster contains two cores of cortex-R52 processors. Each cluster
>>>> can be configured in lockstep mode or split mode.
>>>>
>>>> Each R52 core is assigned 128KB of TCM memory. ATCM memory is 64KB, BTCM
>>>> and CTCM memoreis are 32KB each. Each TCM memory has its own dedicated
>>>> power-domain that needs to be requested before using it.
>>>>
>>>> Signed-off-by: Tanmay Shah 
>>>> ---
>>>>  .../remoteproc/xlnx,zynqmp-r5fss.yaml | 220 +++---
>>>>  1 file changed, 184 insertions(+), 36 deletions(-)
>>>>
>>>> diff --git 
>>>> a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml 
>>>> b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>> index 711da0272250..55654ee02eef 100644
>>>> --- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>> +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>> @@ -18,7 +18,9 @@ description: |
>>>>  
>>>>  properties:
>>>>compatible:
>>>> -const: xlnx,zynqmp-r5fss
>>>> +enum:
>>>> +  - xlnx,zynqmp-r5fss
>>>> +  - xlnx,versal-net-r52fss
>>>>  
>>>>"#address-cells":
>>>>  const: 2
>>>> @@ -64,7 +66,9 @@ patternProperties:
>>>>  
>>>>  properties:
>>>>compatible:
>>>> -const: xlnx,zynqmp-r5f
>>>> +enum:
>>>> +  - xlnx,zynqmp-r5f
>>>> +  - xlnx,versal-net-r52f
>>>>  
>>>>reg:
>>>>  minItems: 1
>>>> @@ -135,9 +139,11 @@ required:
>>>>  allOf:
>>>>- if:
>>>>properties:
>>>> -xlnx,cluster-mode:
>>>> -  enum:
>>>> -- 1
>>>> +compatible:
>>>> +  contains:
>>>> +enum:
>>>> +  - xlnx,versal-net-r52fss
>>>
>>> Why do you touch these lines?
>>>
>>>> +
>>>>  then:
>>>>patternProperties:
>>>>  "^r5f@[0-9a-f]+$":
>>>> @@ -149,16 +155,14 @@ allOf:
>>>>items:
>>>>  - description: ATCM internal memory
>>>>  - description: BTCM internal memory
>>>> -- description: extra ATCM memory in lockstep mode
>>>> -- description: extra BTCM memory in lockstep mode
>>>> +- description: CTCM internal memory
>>>>  
>>>>  reg-names:
>>>>minItems: 1
>>>>items:
>>>> -- const: atcm0
>>>> -- const: btcm0
>>>> -- const: atcm1
>>>> -- const: btcm1
>>>> +- const: atcm
>>>> +- const: btcm
>>>> +- const: ctcm
>>>>  
>>>>  power-domains:
>>>>minItems: 2
>>>> @@ -166,33 +170,70 @@ allOf:
>>>>  - description: RPU core power domain
>>>>  - description: ATCM power domain
>>>>  - description: BTCM power domain
>>>> -- description: second ATCM power domain
>>>> -- description: second BTCM power domain
>>>> +- description: CTCM power domain
>>>>  
>>>>  else:
>>>> -  patternProperties:
>>>> -"^r5f@[0-9a-f]+$":
>>>> -  type: object
>>>> -
>>>> -  properties:
>>>> -reg:
>>>> -  minItems: 1
>>>> -  items:
>>>> -- description: ATCM internal memory

Re: [PATCH 3/3] drivers: remoteproc: add Versal and Versal-NET support

[Tanmay Shah]

On 3/19/24 12:25 AM, Krzysztof Kozlowski wrote:
> On 19/03/2024 02:06, Tanmay Shah wrote:
>> 
>> 
>> On 3/17/24 1:55 PM, Krzysztof Kozlowski wrote:
>>> On 15/03/2024 22:15, Tanmay Shah wrote:
>>>> AMD-Xilinx Versal and Versal-NET are successor of ZynqMP platform. ZynqMP
>>>> remoteproc driver is mostly compatible with new platforms except few
>>>> platform specific differences.
>>>>
>>>> Versal has same IP of cortex-R5 cores hence maintained compatible string
>>>> same as ZynqMP platform. However, hardcode TCM addresses are not
>>>> supported for new platforms and must be provided in device-tree as per
>>>> new bindings. This makes TCM representation data-driven and easy to
>>>> maintain. This check is provided in the driver.
>>>>
>>>> For Versal-NET platform, TCM doesn't need to be configured in lockstep
>>>> mode or split mode. Hence that call to PMC firmware is avoided in the
>>>> driver for Versal-NET platform.
>>>>
>>>> Signed-off-by: Tanmay Shah 
>>>> ---
>>>>  drivers/remoteproc/xlnx_r5_remoteproc.c | 19 +++
>>>>  1 file changed, 15 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
>>>> b/drivers/remoteproc/xlnx_r5_remoteproc.c
>>>> index d4a22caebaad..193bc159d1b4 100644
>>>> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
>>>> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
>>>> @@ -323,9 +323,12 @@ static int zynqmp_r5_set_mode(struct zynqmp_r5_core 
>>>> *r5_core,
>>>>return ret;
>>>>}
>>>>  
>>>> -  ret = zynqmp_pm_set_tcm_config(r5_core->pm_domain_id, tcm_mode);
>>>> -  if (ret < 0)
>>>> -  dev_err(r5_core->dev, "failed to configure TCM\n");
>>>> +  /* TCM configuration is not needed in versal-net */
>>>> +  if (device_is_compatible(r5_core->dev, "xlnx,zynqmp-r5f")) {
>>>> +  ret = zynqmp_pm_set_tcm_config(r5_core->pm_domain_id, tcm_mode);
>>>> +  if (ret < 0)
>>>> +  dev_err(r5_core->dev, "failed to configure TCM\n");
>>>> +  }
>>>>  
>>>>return ret;
>>>>  }
>>>> @@ -933,10 +936,17 @@ static int zynqmp_r5_core_init(struct 
>>>> zynqmp_r5_cluster *cluster,
>>>>int ret, i;
>>>>  
>>>>r5_core = cluster->r5_cores[0];
>>>> +
>>>> +  /*
>>>> +   * New platforms must use device tree for TCM parsing.
>>>> +   * Only ZynqMP uses hardcode TCM.
>>>> +   */
>>>>if (of_find_property(r5_core->np, "reg", NULL))
>>>>ret = zynqmp_r5_get_tcm_node_from_dt(cluster);
>>>> -  else
>>>> +  else if (of_machine_is_compatible("xlnx,zynqmp"))
>>>>ret = zynqmp_r5_get_tcm_node(cluster);
>>>
>>> That's poor code. Your drivers should not depend on platform. I don't
>>> understand why you need to do this and how is even related to this patch.
>> 
>> You are correct, ideally this shouldn't be needed. However, this driver 
>> contains
>> hardcode TCM addresses that were used before TCM bindings were designed and 
>> available in
>> device-tree. This check is provided to maintain backward compatibility with 
>> device-tree
>> where TCM isn't expected.
>> 
>> For new platforms (Versal and Versal-NET) TCM must be provided in 
>> device-tree and for
>> ZynqMP if it's not in device-tree then to maintain backward compatibility 
>> hardcode
>> addresses are used.
> 
> That does not work like this. You cannot bind to some sort of different
> compatible. If you disagree, please list the compatibles the driver
> binds to.

Okay understood. I believe then removing hardcode addresses makes more sense in 
that
case. So, driver will become same for all the devices.

> 
> Best regards,
> Krzysztof
> 

Re: [PATCH v13 2/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings

[Tanmay Shah]

On 3/19/24 12:29 AM, Krzysztof Kozlowski wrote:
> On 11/03/2024 18:59, Tanmay Shah wrote:
>> From: Radhey Shyam Pandey 
>> 
>> 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 
>> Signed-off-by: Tanmay Shah 
>> ---
> 
> I responded under my reviewed-tag, but to be clear, also here:
> 
> This patch has is not ready. Please do not merge.
> 

Glad we could catch this before merging this.
I will wait for your reply on other thread for refactoring.

> Best regards,
> Krzysztof
> 

Re: [PATCH 2/3] dt-bindings: remoteproc: add Versal-NET platform

[Tanmay Shah]

On 3/20/24 2:40 AM, Krzysztof Kozlowski wrote:
> On 19/03/2024 15:42, Tanmay Shah wrote:
>> 
>> 
>> On 3/19/24 12:30 AM, Krzysztof Kozlowski wrote:
>>> On 19/03/2024 01:51, Tanmay Shah wrote:
>>>> Hello Krzysztof,
>>>>
>>>> Thanks for reviews. Please find my comments below.
>>>>
>>>> On 3/17/24 1:53 PM, Krzysztof Kozlowski wrote:
>>>>> On 15/03/2024 22:15, Tanmay Shah wrote:
>>>>>> AMD-Xilinx Versal-NET platform is successor of Versal platform. It
>>>>>> contains multiple clusters of cortex-R52 real-time processing units.
>>>>>> Each cluster contains two cores of cortex-R52 processors. Each cluster
>>>>>> can be configured in lockstep mode or split mode.
>>>>>>
>>>>>> Each R52 core is assigned 128KB of TCM memory. ATCM memory is 64KB, BTCM
>>>>>> and CTCM memoreis are 32KB each. Each TCM memory has its own dedicated
>>>>>> power-domain that needs to be requested before using it.
>>>>>>
>>>>>> Signed-off-by: Tanmay Shah 
>>>>>> ---
>>>>>>  .../remoteproc/xlnx,zynqmp-r5fss.yaml | 220 +++---
>>>>>>  1 file changed, 184 insertions(+), 36 deletions(-)
>>>>>>
>>>>>> diff --git 
>>>>>> a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml 
>>>>>> b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>>>> index 711da0272250..55654ee02eef 100644
>>>>>> --- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>>>> @@ -18,7 +18,9 @@ description: |
>>>>>>  
>>>>>>  properties:
>>>>>>compatible:
>>>>>> -const: xlnx,zynqmp-r5fss
>>>>>> +enum:
>>>>>> +  - xlnx,zynqmp-r5fss
>>>>>> +  - xlnx,versal-net-r52fss
>>>>>>  
>>>>>>"#address-cells":
>>>>>>  const: 2
>>>>>> @@ -64,7 +66,9 @@ patternProperties:
>>>>>>  
>>>>>>  properties:
>>>>>>compatible:
>>>>>> -const: xlnx,zynqmp-r5f
>>>>>> +enum:
>>>>>> +  - xlnx,zynqmp-r5f
>>>>>> +  - xlnx,versal-net-r52f
>>>>>>  
>>>>>>reg:
>>>>>>  minItems: 1
>>>>>> @@ -135,9 +139,11 @@ required:
>>>>>>  allOf:
>>>>>>- if:
>>>>>>properties:
>>>>>> -xlnx,cluster-mode:
>>>>>> -  enum:
>>>>>> -- 1
>>>>>> +compatible:
>>>>>> +  contains:
>>>>>> +enum:
>>>>>> +  - xlnx,versal-net-r52fss
>>>>>
>>>>> Why do you touch these lines?
>>>>>
>>>>>> +
>>>>>>  then:
>>>>>>patternProperties:
>>>>>>  "^r5f@[0-9a-f]+$":
>>>>>> @@ -149,16 +155,14 @@ allOf:
>>>>>>items:
>>>>>>  - description: ATCM internal memory
>>>>>>  - description: BTCM internal memory
>>>>>> -- description: extra ATCM memory in lockstep mode
>>>>>> -- description: extra BTCM memory in lockstep mode
>>>>>> +- description: CTCM internal memory
>>>>>>  
>>>>>>  reg-names:
>>>>>>minItems: 1
>>>>>>items:
>>>>>> -- const: atcm0
>>>>>> -- const: btcm0
>>>>>> -- const: atcm1
>>>>>> -- const: btcm1
>>>>>> +- const: atcm
>>>>>> +- const: btcm
>>>>>> +- const: ctcm
>>>>>>  
>>>>>>  power-domains:
>>>>>>minItems: 2
>>>>>> @@ -166,33 +170,70 @@ allOf:
>>>>>>

Re: [PATCH 2/3] dt-bindings: remoteproc: add Versal-NET platform

[Tanmay Shah]

On 3/21/24 2:39 AM, Krzysztof Kozlowski wrote:
> On 20/03/2024 16:14, Tanmay Shah wrote:
>> 
>> 
>> On 3/20/24 2:40 AM, Krzysztof Kozlowski wrote:
>>> On 19/03/2024 15:42, Tanmay Shah wrote:
>>>>
>>>>
>>>> On 3/19/24 12:30 AM, Krzysztof Kozlowski wrote:
>>>>> On 19/03/2024 01:51, Tanmay Shah wrote:
>>>>>> Hello Krzysztof,
>>>>>>
>>>>>> Thanks for reviews. Please find my comments below.
>>>>>>
>>>>>> On 3/17/24 1:53 PM, Krzysztof Kozlowski wrote:
>>>>>>> On 15/03/2024 22:15, Tanmay Shah wrote:
>>>>>>>> AMD-Xilinx Versal-NET platform is successor of Versal platform. It
>>>>>>>> contains multiple clusters of cortex-R52 real-time processing units.
>>>>>>>> Each cluster contains two cores of cortex-R52 processors. Each cluster
>>>>>>>> can be configured in lockstep mode or split mode.
>>>>>>>>
>>>>>>>> Each R52 core is assigned 128KB of TCM memory. ATCM memory is 64KB, 
>>>>>>>> BTCM
>>>>>>>> and CTCM memoreis are 32KB each. Each TCM memory has its own dedicated
>>>>>>>> power-domain that needs to be requested before using it.
>>>>>>>>
>>>>>>>> Signed-off-by: Tanmay Shah 
>>>>>>>> ---
>>>>>>>>  .../remoteproc/xlnx,zynqmp-r5fss.yaml | 220 +++---
>>>>>>>>  1 file changed, 184 insertions(+), 36 deletions(-)
>>>>>>>>
>>>>>>>> diff --git 
>>>>>>>> a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml 
>>>>>>>> b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>>>>>> index 711da0272250..55654ee02eef 100644
>>>>>>>> --- 
>>>>>>>> a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>>>>>> +++ 
>>>>>>>> b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>>>>>> @@ -18,7 +18,9 @@ description: |
>>>>>>>>  
>>>>>>>>  properties:
>>>>>>>>compatible:
>>>>>>>> -const: xlnx,zynqmp-r5fss
>>>>>>>> +enum:
>>>>>>>> +  - xlnx,zynqmp-r5fss
>>>>>>>> +  - xlnx,versal-net-r52fss
>>>>>>>>  
>>>>>>>>"#address-cells":
>>>>>>>>  const: 2
>>>>>>>> @@ -64,7 +66,9 @@ patternProperties:
>>>>>>>>  
>>>>>>>>  properties:
>>>>>>>>compatible:
>>>>>>>> -const: xlnx,zynqmp-r5f
>>>>>>>> +enum:
>>>>>>>> +  - xlnx,zynqmp-r5f
>>>>>>>> +  - xlnx,versal-net-r52f
>>>>>>>>  
>>>>>>>>reg:
>>>>>>>>  minItems: 1
>>>>>>>> @@ -135,9 +139,11 @@ required:
>>>>>>>>  allOf:
>>>>>>>>- if:
>>>>>>>>properties:
>>>>>>>> -xlnx,cluster-mode:
>>>>>>>> -  enum:
>>>>>>>> -- 1
>>>>>>>> +compatible:
>>>>>>>> +  contains:
>>>>>>>> +enum:
>>>>>>>> +  - xlnx,versal-net-r52fss
>>>>>>>
>>>>>>> Why do you touch these lines?
>>>>>>>
>>>>>>>> +
>>>>>>>>  then:
>>>>>>>>patternProperties:
>>>>>>>>  "^r5f@[0-9a-f]+$":
>>>>>>>> @@ -149,16 +155,14 @@ allOf:
>>>>>>>>items:
>>>>>>>>  - description: ATCM internal memory
>>>>>>>>  - description: BTCM internal memory
>>>>>>>> -- description: extra ATCM memory in lockstep mode
>>>>>>>> -- description: extra BTCM memory in lockstep mode
>>>>>>

Re: [PATCH 2/3] dt-bindings: remoteproc: add Versal-NET platform

[Tanmay Shah]

On 3/22/24 12:44 AM, Krzysztof Kozlowski wrote:
> On 21/03/2024 16:13, Tanmay Shah wrote:
>> 
>> 
>> On 3/21/24 2:39 AM, Krzysztof Kozlowski wrote:
>>> On 20/03/2024 16:14, Tanmay Shah wrote:
>>>>
>>>>
>>>> On 3/20/24 2:40 AM, Krzysztof Kozlowski wrote:
>>>>> On 19/03/2024 15:42, Tanmay Shah wrote:
>>>>>>
>>>>>>
>>>>>> On 3/19/24 12:30 AM, Krzysztof Kozlowski wrote:
>>>>>>> On 19/03/2024 01:51, Tanmay Shah wrote:
>>>>>>>> Hello Krzysztof,
>>>>>>>>
>>>>>>>> Thanks for reviews. Please find my comments below.
>>>>>>>>
>>>>>>>> On 3/17/24 1:53 PM, Krzysztof Kozlowski wrote:
>>>>>>>>> On 15/03/2024 22:15, Tanmay Shah wrote:
>>>>>>>>>> AMD-Xilinx Versal-NET platform is successor of Versal platform. It
>>>>>>>>>> contains multiple clusters of cortex-R52 real-time processing units.
>>>>>>>>>> Each cluster contains two cores of cortex-R52 processors. Each 
>>>>>>>>>> cluster
>>>>>>>>>> can be configured in lockstep mode or split mode.
>>>>>>>>>>
>>>>>>>>>> Each R52 core is assigned 128KB of TCM memory. ATCM memory is 64KB, 
>>>>>>>>>> BTCM
>>>>>>>>>> and CTCM memoreis are 32KB each. Each TCM memory has its own 
>>>>>>>>>> dedicated
>>>>>>>>>> power-domain that needs to be requested before using it.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Tanmay Shah 
>>>>>>>>>> ---
>>>>>>>>>>  .../remoteproc/xlnx,zynqmp-r5fss.yaml | 220 
>>>>>>>>>> +++---
>>>>>>>>>>  1 file changed, 184 insertions(+), 36 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git 
>>>>>>>>>> a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>>>>>>>>  
>>>>>>>>>> b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>>>>>>>> index 711da0272250..55654ee02eef 100644
>>>>>>>>>> --- 
>>>>>>>>>> a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>>>>>>>> +++ 
>>>>>>>>>> b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>>>>>>>> @@ -18,7 +18,9 @@ description: |
>>>>>>>>>>  
>>>>>>>>>>  properties:
>>>>>>>>>>compatible:
>>>>>>>>>> -const: xlnx,zynqmp-r5fss
>>>>>>>>>> +enum:
>>>>>>>>>> +  - xlnx,zynqmp-r5fss
>>>>>>>>>> +  - xlnx,versal-net-r52fss
>>>>>>>>>>  
>>>>>>>>>>"#address-cells":
>>>>>>>>>>  const: 2
>>>>>>>>>> @@ -64,7 +66,9 @@ patternProperties:
>>>>>>>>>>  
>>>>>>>>>>  properties:
>>>>>>>>>>compatible:
>>>>>>>>>> -const: xlnx,zynqmp-r5f
>>>>>>>>>> +enum:
>>>>>>>>>> +  - xlnx,zynqmp-r5f
>>>>>>>>>> +  - xlnx,versal-net-r52f
>>>>>>>>>>  
>>>>>>>>>>reg:
>>>>>>>>>>  minItems: 1
>>>>>>>>>> @@ -135,9 +139,11 @@ required:
>>>>>>>>>>  allOf:
>>>>>>>>>>- if:
>>>>>>>>>>properties:
>>>>>>>>>> -xlnx,cluster-mode:
>>>>>>>>>> -  enum:
>>>>>>>>>> -- 1
>>>>>>>>>> +compatible:
>>>>>>>>>> +  contains:
>>>>>>>>>> +enum:
>>>>>>>&

[PATCH v14 1/4] remoteproc: zynqmp: fix lockstep mode memory region

[Tanmay Shah]

In lockstep mode, r5 core0 uses TCM of R5 core1. Following is lockstep
mode memory region as per hardware reference manual.

|  *TCM* |   *R5 View* | *Linux view* |
| R5_0 ATCM (128 KB) | 0x_ | 0xFFE0_  |
| R5_0 BTCM (128 KB) | 0x0002_ | 0xFFE2_  |

However, driver shouldn't model it as above because R5 core0 TCM and core1
TCM has different power-domains mapped to it.
Hence, TCM address space in lockstep mode should be modeled as 64KB
regions only where each region has its own power-domain as following:

|  *TCM* |   *R5 View* | *Linux view* |
| R5_0 ATCM0 (64 KB) | 0x_ | 0xFFE0_  |
| R5_0 BTCM0 (64 KB) | 0x0002_ | 0xFFE2_  |
| R5_0 ATCM1 (64 KB) | 0x0001_ | 0xFFE1_  |
| R5_0 BTCM1 (64 KB) | 0x0003_ | 0xFFE3_  |

This makes driver maintanance easy and makes design robust for future
platorms as well.

Signed-off-by: Tanmay Shah 
---
 drivers/remoteproc/xlnx_r5_remoteproc.c | 146 ++--
 1 file changed, 12 insertions(+), 134 deletions(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index cfbd97b89c26..0f942440b4e2 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -84,12 +84,12 @@ static const struct mem_bank_data zynqmp_tcm_banks_split[] 
= {
{0xffebUL, 0x2, 0x1UL, PD_R5_1_BTCM, "btcm1"},
 };
 
-/* In lockstep mode cluster combines each 64KB TCM and makes 128KB TCM */
+/* In lockstep mode cluster uses each 64KB TCM from second core as well */
 static const struct mem_bank_data zynqmp_tcm_banks_lockstep[] = {
-   {0xffe0UL, 0x0, 0x2UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 128KB 
each */
-   {0xffe2UL, 0x2, 0x2UL, PD_R5_0_BTCM, "btcm0"},
-   {0, 0, 0, PD_R5_1_ATCM, ""},
-   {0, 0, 0, PD_R5_1_BTCM, ""},
+   {0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each 
*/
+   {0xffe2UL, 0x2, 0x1UL, PD_R5_0_BTCM, "btcm0"},
+   {0xffe1UL, 0x1, 0x1UL, PD_R5_1_ATCM, "atcm1"},
+   {0xffe3UL, 0x3, 0x1UL, PD_R5_1_BTCM, "btcm1"},
 };
 
 /**
@@ -541,14 +541,14 @@ static int tcm_mem_map(struct rproc *rproc,
 }
 
 /*
- * add_tcm_carveout_split_mode()
+ * add_tcm_banks()
  * @rproc: single R5 core's corresponding rproc instance
  *
- * allocate and add remoteproc carveout for TCM memory in split mode
+ * allocate and add remoteproc carveout for TCM memory
  *
  * return 0 on success, otherwise non-zero value on failure
  */
-static int add_tcm_carveout_split_mode(struct rproc *rproc)
+static int add_tcm_banks(struct rproc *rproc)
 {
struct rproc_mem_entry *rproc_mem;
struct zynqmp_r5_core *r5_core;
@@ -581,10 +581,10 @@ static int add_tcm_carveout_split_mode(struct rproc 
*rproc)
 ZYNQMP_PM_REQUEST_ACK_BLOCKING);
if (ret < 0) {
dev_err(dev, "failed to turn on TCM 0x%x", 
pm_domain_id);
-   goto release_tcm_split;
+   goto release_tcm;
}
 
-   dev_dbg(dev, "TCM carveout split mode %s addr=%llx, da=0x%x, 
size=0x%lx",
+   dev_dbg(dev, "TCM carveout %s addr=%llx, da=0x%x, size=0x%lx",
bank_name, bank_addr, da, bank_size);
 
rproc_mem = rproc_mem_entry_init(dev, NULL, bank_addr,
@@ -594,99 +594,16 @@ static int add_tcm_carveout_split_mode(struct rproc 
*rproc)
if (!rproc_mem) {
ret = -ENOMEM;
zynqmp_pm_release_node(pm_domain_id);
-   goto release_tcm_split;
-   }
-
-   rproc_add_carveout(rproc, rproc_mem);
-   rproc_coredump_add_segment(rproc, da, bank_size);
-   }
-
-   return 0;
-
-release_tcm_split:
-   /* If failed, Turn off all TCM banks turned on before */
-   for (i--; i >= 0; i--) {
-   pm_domain_id = r5_core->tcm_banks[i]->pm_domain_id;
-   zynqmp_pm_release_node(pm_domain_id);
-   }
-   return ret;
-}
-
-/*
- * add_tcm_carveout_lockstep_mode()
- * @rproc: single R5 core's corresponding rproc instance
- *
- * allocate and add remoteproc carveout for TCM memory in lockstep mode
- *
- * return 0 on success, otherwise non-zero value on failure
- */
-static int add_tcm_carveout_lockstep_mode(struct rproc *rproc)
-{
-   struct rproc_mem_entry *rproc_mem;
-   struct zynqmp_r5_core *r5_core;
-   int i, num_banks, ret;
-   phys_addr_t bank_addr;
-   size_t bank_size = 0;
-   struct device *dev;
-   u32 pm_domain_id;
-   char *bank_name;
-   u32 da;
-
-   r5_core = rproc->priv;
-   dev = r5_core->dev;
-
-   

[PATCH v14 0/4] add zynqmp TCM bindings

[Tanmay Shah]

  - 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/20230829181900.2561194-1-tanmay.s...@amd.com/

Previous v3 version link:
https://lore.kernel.org/all/1689964908-22371-1-git-send-email-radhey.shyam.pan...@amd.com/

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 | 279 +--
 .../boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts  |   8 +
 arch/arm64/boot/dts/xilinx/zynqmp.dtsi|  67 +++-
 drivers/remoteproc/xlnx_r5_remoteproc.c   | 319 --
 4 files changed, 471 insertions(+), 202 deletions(-)


base-commit: 39cd87c4eb2b893354f3b850f916353f2658ae6f
prerequisite-patch-id: f6c4bf78d30a332948d38e5c937f031496cd3b5a
-- 
2.25.1

[PATCH v14 2/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings

[Tanmay Shah]

From: Radhey Shyam Pandey 

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 
Signed-off-by: Tanmay Shah 

---

Changes in v14:
  - Remove previous RB tag
  - Add xlnx,tcm-mode property
  - Add Versal platform support
  - Add Versal-NET platform support

 .../remoteproc/xlnx,zynqmp-r5fss.yaml | 279 --
 1 file changed, 257 insertions(+), 22 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml 
b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
index 78aac69f1060..6f13da11f593 100644
--- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
@@ -18,11 +18,26 @@ description: |
 
 properties:
   compatible:
-const: xlnx,zynqmp-r5fss
+enum:
+  - xlnx,zynqmp-r5fss
+  - xlnx,versal-r5fss
+  - xlnx,versal-net-r52fss
+
+  "#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,
@@ -36,8 +51,16 @@ properties:
   1: lockstep mode (default)
   2: single cpu mode
 
+  xlnx,tcm-mode:
+$ref: /schemas/types.yaml#/definitions/uint32
+enum: [0, 1]
+description: |
+  Configure RPU TCM
+  0: split mode
+  1: lockstep mode
+
 patternProperties:
-  "^r5f-[a-f0-9]+$":
+  "^r(.*)@[0-9a-f]+$":
 type: object
 description: |
   The RPU is located in the Low Power Domain of the Processor Subsystem.
@@ -52,10 +75,22 @@ patternProperties:
 
 properties:
   compatible:
-const: xlnx,zynqmp-r5f
+enum:
+  - xlnx,zynqmp-r5f
+  - xlnx,versal-r5f
+  - xlnx,versal-net-r52f
+
+  reg:
+minItems: 1
+maxItems: 4
+
+  reg-names:
+minItems: 1
+maxItems: 4
 
   power-domains:
-maxItems: 1
+minItems: 2
+maxItems: 5
 
   mboxes:
 minItems: 1
@@ -101,35 +136,235 @@ patternProperties:
 
 required:
   - compatible
+  - reg
+  - reg-names
   - power-domains
 
-unevaluatedProperties: false
-
 required:
   - compatible
+  - "#address-cells"
+  - "#size-cells"
+  - ranges
+
+allOf:
+  - if:
+  properties:
+compatible:
+  contains:
+enum:
+  - xlnx,versal-net-r52fss
+then:
+  properties:
+xlnx,tcm-mode: false
+
+  patternProperties:
+"^r52f@[0-9a-f]+$":
+  type: object
+
+  properties:
+reg:
+  minItems: 1
+  items:
+- description: ATCM internal memory
+- description: BTCM internal memory
+- description: CTCM internal memory
+
+reg-names:
+  minItems: 1
+  items:
+- const: atcm0
+- const: btcm0
+- const: ctcm0
+
+power-domains:
+  minItems: 2
+  items:
+- description: RPU core power domain
+- description: ATCM power domain
+- description: BTCM power domain
+- description: CTCM power domain
+
+  - if:
+  properties:
+compatible:
+  contains:
+enum:
+  - xlnx,zynqmp-r5fss
+  - xlnx,versal-r5fss
+then:
+  if:
+properties:
+  xlnx,cluster-mode:
+enum: [1, 2]
+  then:
+properties:
+  xlnx,tcm-mode:
+enum: [1]
+
+patternProperties:
+  "^r5f@[0-9a-f]+$":
+type: object
+
+properties:
+  reg:
+

[PATCH v14 3/4] dts: zynqmp: add properties for TCM in remoteproc

[Tanmay Shah]

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 
---

Changes in v14:
  - Add xlnx,tcm-mode property in remoteproc node

 .../boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts  |  8 +++
 arch/arm64/boot/dts/xilinx/zynqmp.dtsi| 67 +--
 2 files changed, 70 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 25d20d803230..ef31b0fc73d1 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -260,19 +260,76 @@ fpga_full: fpga-full {
ranges;
};
 
-   remoteproc {
+   rproc_lockstep: remoteproc@ffe0 {
compatible = "xlnx,zynqmp-r5fss";
xlnx,cluster-mode = <1>;
+   xlnx,tcm-mode = <1>;
 
-   r5f-0 {
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x0 0x1 0x0 0xffe1 0x0 0x1>,
+<0x0 0x3 0x0 0xffe3 0x0 0x1>;
+
+   r5f@0 {
+   compatible = "xlnx,zynqmp-r5f";
+   reg = <0x0 0x0 0x0 0x1>,
+ <0x0 0x2 0x0 0x1>,
+ <0x0 0x1 0x0 0x1>,
+ <0x0 0x3 0x0 0x1>;
+   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 0x1>, <0x1 0x2 0x0 0x1>;
+   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@ffe0 {
+   status = "disabled";
+   compatible = "xlnx,zynqmp-r5fss";
+   xlnx,cluster-mode = <0>;
+   xlnx,tcm-mode = <0>;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x1 0x0 0x0 0xffe9 0x0 0x1>,
+<0x1 0x2 0x0 0xffeb 0x0 0x1>;
+
+   r5f@0 {
compatible = "xlnx,zynqmp-r5f";
-   power-domains = <&zynqmp_firmware PD_RPU_0>;
+   reg = <0x0 0x0 0x0 0x1>, <0x0 0x2 0x0 0x1>;
+   reg-names = "atcm0", "btcm0";
+   power-domains = <&zynqmp_firmware PD_RPU_0>,
+   <&

[PATCH v14 4/4] remoteproc: zynqmp: parse TCM from device tree

[Tanmay Shah]

ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
is available in device-tree. Parse TCM information in driver
as per new bindings.

Signed-off-by: Tanmay Shah 
---

Changes in v14:
  - Add Versal platform support
  - Add Versal-NET platform support
  - Maintain backward compatibility for ZynqMP platform and use hardcode
TCM addresses
  - Configure TCM based on xlnx,tcm-mode property for Versal
  - Avoid TCM configuration if that property isn't available in DT 

 drivers/remoteproc/xlnx_r5_remoteproc.c | 173 ++--
 1 file changed, 132 insertions(+), 41 deletions(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 0f942440b4e2..504492f930ac 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -74,8 +74,8 @@ struct mbox_info {
 };
 
 /*
- * Hardcoded TCM bank values. This will be removed once TCM bindings are
- * accepted for system-dt specifications and upstreamed in linux kernel
+ * Hardcoded TCM bank values. This will stay in driver to maintain backward
+ * compatibility with device-tree that does not have TCM information.
  */
 static const struct mem_bank_data zynqmp_tcm_banks_split[] = {
{0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each 
*/
@@ -300,36 +300,6 @@ static void zynqmp_r5_rproc_kick(struct rproc *rproc, int 
vqid)
dev_warn(dev, "failed to send message\n");
 }
 
-/*
- * zynqmp_r5_set_mode()
- *
- * set RPU cluster and TCM operation mode
- *
- * @r5_core: pointer to zynqmp_r5_core type object
- * @fw_reg_val: value expected by firmware to configure RPU cluster mode
- * @tcm_mode: value expected by fw to configure TCM mode (lockstep or split)
- *
- * Return: 0 for success and < 0 for failure
- */
-static int zynqmp_r5_set_mode(struct zynqmp_r5_core *r5_core,
- enum rpu_oper_mode fw_reg_val,
- enum rpu_tcm_comb tcm_mode)
-{
-   int ret;
-
-   ret = zynqmp_pm_set_rpu_mode(r5_core->pm_domain_id, fw_reg_val);
-   if (ret < 0) {
-   dev_err(r5_core->dev, "failed to set RPU mode\n");
-   return ret;
-   }
-
-   ret = zynqmp_pm_set_tcm_config(r5_core->pm_domain_id, tcm_mode);
-   if (ret < 0)
-   dev_err(r5_core->dev, "failed to configure TCM\n");
-
-   return ret;
-}
-
 /*
  * zynqmp_r5_rproc_start()
  * @rproc: single R5 core's corresponding rproc instance
@@ -761,6 +731,103 @@ static struct zynqmp_r5_core 
*zynqmp_r5_add_rproc_core(struct device *cdev)
return ERR_PTR(ret);
 }
 
+static int zynqmp_r5_get_tcm_node_from_dt(struct zynqmp_r5_cluster *cluster)
+{
+   int i, j, tcm_bank_count, ret, tcm_pd_idx, pd_count;
+   struct of_phandle_args out_args;
+   struct zynqmp_r5_core *r5_core;
+   struct platform_device *cpdev;
+   struct mem_bank_data *tcm;
+   struct device_node *np;
+   struct resource *res;
+   u64 abs_addr, size;
+   struct device *dev;
+
+   for (i = 0; i < cluster->core_count; i++) {
+   r5_core = cluster->r5_cores[i];
+   dev = r5_core->dev;
+   np = r5_core->np;
+
+   pd_count = of_count_phandle_with_args(np, "power-domains",
+ "#power-domain-cells");
+
+   if (pd_count <= 0) {
+   dev_err(dev, "invalid power-domains property, %d\n", 
pd_count);
+   return -EINVAL;
+   }
+
+   /* First entry in power-domains list is for r5 core, rest for 
TCM. */
+   tcm_bank_count = pd_count - 1;
+
+   if (tcm_bank_count <= 0) {
+   dev_err(dev, "invalid TCM count %d\n", tcm_bank_count);
+   return -EINVAL;
+   }
+
+   r5_core->tcm_banks = devm_kcalloc(dev, tcm_bank_count,
+ sizeof(struct mem_bank_data 
*),
+ GFP_KERNEL);
+   if (!r5_core->tcm_banks)
+   return -ENOMEM;
+
+   r5_core->tcm_bank_count = tcm_bank_count;
+   for (j = 0, tcm_pd_idx = 1; j < tcm_bank_count; j++, 
tcm_pd_idx++) {
+   tcm = devm_kzalloc(dev, sizeof(struct mem_bank_data),
+  GFP_KERNEL);
+   if (!tcm)
+   return -ENOMEM;
+
+   r5_core->tcm_banks[j] = tcm;
+
+   /* Get power-domains id of TCM. */
+   ret = of_parse_phandle_with_args(np, "power-domains",
+"#power-domain-cells&quo

Re: [PATCH v14 4/4] remoteproc: zynqmp: parse TCM from device tree

[Tanmay Shah]

On 4/10/24 11:59 AM, Mathieu Poirier wrote:
> On Mon, Apr 08, 2024 at 01:53:14PM -0700, Tanmay Shah wrote:
>> ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
>> is available in device-tree. Parse TCM information in driver
>> as per new bindings.
>> 
>> Signed-off-by: Tanmay Shah 
>> ---
>> 
>> Changes in v14:
>>   - Add Versal platform support
>>   - Add Versal-NET platform support
>>   - Maintain backward compatibility for ZynqMP platform and use hardcode
>> TCM addresses
>>   - Configure TCM based on xlnx,tcm-mode property for Versal
>>   - Avoid TCM configuration if that property isn't available in DT 
>> 
>>  drivers/remoteproc/xlnx_r5_remoteproc.c | 173 ++--
>>  1 file changed, 132 insertions(+), 41 deletions(-)
>> 
>> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
>> b/drivers/remoteproc/xlnx_r5_remoteproc.c
>> index 0f942440b4e2..504492f930ac 100644
>> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
>> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
>> @@ -74,8 +74,8 @@ struct mbox_info {
>>  };
>>  
>>  /*
>> - * Hardcoded TCM bank values. This will be removed once TCM bindings are
>> - * accepted for system-dt specifications and upstreamed in linux kernel
>> + * Hardcoded TCM bank values. This will stay in driver to maintain backward
>> + * compatibility with device-tree that does not have TCM information.
>>   */
>>  static const struct mem_bank_data zynqmp_tcm_banks_split[] = {
>>  {0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each 
>> */
>> @@ -300,36 +300,6 @@ static void zynqmp_r5_rproc_kick(struct rproc *rproc, 
>> int vqid)
>>  dev_warn(dev, "failed to send message\n");
>>  }
>>  
>> -/*
>> - * zynqmp_r5_set_mode()
>> - *
>> - * set RPU cluster and TCM operation mode
>> - *
>> - * @r5_core: pointer to zynqmp_r5_core type object
>> - * @fw_reg_val: value expected by firmware to configure RPU cluster mode
>> - * @tcm_mode: value expected by fw to configure TCM mode (lockstep or split)
>> - *
>> - * Return: 0 for success and < 0 for failure
>> - */
>> -static int zynqmp_r5_set_mode(struct zynqmp_r5_core *r5_core,
>> -  enum rpu_oper_mode fw_reg_val,
>> -  enum rpu_tcm_comb tcm_mode)
>> -{
>> -int ret;
>> -
>> -ret = zynqmp_pm_set_rpu_mode(r5_core->pm_domain_id, fw_reg_val);
>> -if (ret < 0) {
>> -dev_err(r5_core->dev, "failed to set RPU mode\n");
>> -return ret;
>> -}
>> -
>> -ret = zynqmp_pm_set_tcm_config(r5_core->pm_domain_id, tcm_mode);
>> -if (ret < 0)
>> -dev_err(r5_core->dev, "failed to configure TCM\n");
>> -
>> -return ret;
>> -}
>> -
>>  /*
>>   * zynqmp_r5_rproc_start()
>>   * @rproc: single R5 core's corresponding rproc instance
>> @@ -761,6 +731,103 @@ static struct zynqmp_r5_core 
>> *zynqmp_r5_add_rproc_core(struct device *cdev)
>>  return ERR_PTR(ret);
>>  }
>>  
>> +static int zynqmp_r5_get_tcm_node_from_dt(struct zynqmp_r5_cluster *cluster)
>> +{
>> +int i, j, tcm_bank_count, ret, tcm_pd_idx, pd_count;
>> +struct of_phandle_args out_args;
>> +struct zynqmp_r5_core *r5_core;
>> +struct platform_device *cpdev;
>> +struct mem_bank_data *tcm;
>> +struct device_node *np;
>> +struct resource *res;
>> +u64 abs_addr, size;
>> +struct device *dev;
>> +
>> +for (i = 0; i < cluster->core_count; i++) {
>> +r5_core = cluster->r5_cores[i];
>> +dev = r5_core->dev;
>> +np = r5_core->np;
>> +
>> +pd_count = of_count_phandle_with_args(np, "power-domains",
>> +  "#power-domain-cells");
>> +
>> +if (pd_count <= 0) {
>> +dev_err(dev, "invalid power-domains property, %d\n", 
>> pd_count);
>> +return -EINVAL;
>> +}
>> +
>> +/* First entry in power-domains list is for r5 core, rest for 
>> TCM. */
>> +tcm_bank_count = pd_count - 1;
>> +
>> +if (tcm_bank_count <= 0) {
>> +dev_err(dev, "invalid TCM count %d\n", tcm_bank_count);
>> +return

Re: [PATCH v14 4/4] remoteproc: zynqmp: parse TCM from device tree

[Tanmay Shah]

On 4/11/24 11:12 AM, Mathieu Poirier wrote:
> On Wed, Apr 10, 2024 at 05:36:30PM -0500, Tanmay Shah wrote:
>> 
>> 
>> On 4/10/24 11:59 AM, Mathieu Poirier wrote:
>> > On Mon, Apr 08, 2024 at 01:53:14PM -0700, Tanmay Shah wrote:
>> >> ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
>> >> is available in device-tree. Parse TCM information in driver
>> >> as per new bindings.
>> >> 
>> >> Signed-off-by: Tanmay Shah 
>> >> ---
>> >> 
>> >> Changes in v14:
>> >>   - Add Versal platform support
>> >>   - Add Versal-NET platform support
>> >>   - Maintain backward compatibility for ZynqMP platform and use hardcode
>> >> TCM addresses
>> >>   - Configure TCM based on xlnx,tcm-mode property for Versal
>> >>   - Avoid TCM configuration if that property isn't available in DT 
>> >> 
>> >>  drivers/remoteproc/xlnx_r5_remoteproc.c | 173 ++--
>> >>  1 file changed, 132 insertions(+), 41 deletions(-)
>> >> 
>> >> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
>> >> b/drivers/remoteproc/xlnx_r5_remoteproc.c
>> >> index 0f942440b4e2..504492f930ac 100644
>> >> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
>> >> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
>> >> @@ -74,8 +74,8 @@ struct mbox_info {
>> >>  };
>> >>  
>> >>  /*
>> >> - * Hardcoded TCM bank values. This will be removed once TCM bindings are
>> >> - * accepted for system-dt specifications and upstreamed in linux kernel
>> >> + * Hardcoded TCM bank values. This will stay in driver to maintain 
>> >> backward
>> >> + * compatibility with device-tree that does not have TCM information.
>> >>   */
>> >>  static const struct mem_bank_data zynqmp_tcm_banks_split[] = {
>> >>   {0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each 
>> >> */
>> >> @@ -300,36 +300,6 @@ static void zynqmp_r5_rproc_kick(struct rproc 
>> >> *rproc, int vqid)
>> >>   dev_warn(dev, "failed to send message\n");
>> >>  }
>> >>  
>> >> -/*
>> >> - * zynqmp_r5_set_mode()
>> >> - *
>> >> - * set RPU cluster and TCM operation mode
>> >> - *
>> >> - * @r5_core: pointer to zynqmp_r5_core type object
>> >> - * @fw_reg_val: value expected by firmware to configure RPU cluster mode
>> >> - * @tcm_mode: value expected by fw to configure TCM mode (lockstep or 
>> >> split)
>> >> - *
>> >> - * Return: 0 for success and < 0 for failure
>> >> - */
>> >> -static int zynqmp_r5_set_mode(struct zynqmp_r5_core *r5_core,
>> >> -   enum rpu_oper_mode fw_reg_val,
>> >> -   enum rpu_tcm_comb tcm_mode)
>> >> -{
>> >> - int ret;
>> >> -
>> >> - ret = zynqmp_pm_set_rpu_mode(r5_core->pm_domain_id, fw_reg_val);
>> >> - if (ret < 0) {
>> >> - dev_err(r5_core->dev, "failed to set RPU mode\n");
>> >> - return ret;
>> >> - }
>> >> -
>> >> - ret = zynqmp_pm_set_tcm_config(r5_core->pm_domain_id, tcm_mode);
>> >> - if (ret < 0)
>> >> - dev_err(r5_core->dev, "failed to configure TCM\n");
>> >> -
>> >> - return ret;
>> >> -}
>> >> -
>> >>  /*
>> >>   * zynqmp_r5_rproc_start()
>> >>   * @rproc: single R5 core's corresponding rproc instance
>> >> @@ -761,6 +731,103 @@ static struct zynqmp_r5_core 
>> >> *zynqmp_r5_add_rproc_core(struct device *cdev)
>> >>   return ERR_PTR(ret);
>> >>  }
>> >>  
>> >> +static int zynqmp_r5_get_tcm_node_from_dt(struct zynqmp_r5_cluster 
>> >> *cluster)
>> >> +{
>> >> + int i, j, tcm_bank_count, ret, tcm_pd_idx, pd_count;
>> >> + struct of_phandle_args out_args;
>> >> + struct zynqmp_r5_core *r5_core;
>> >> + struct platform_device *cpdev;
>> >> + struct mem_bank_data *tcm;
>> >> + struct device_node *np;
>> >> + struct resource *res;
>> >> + u64 abs_addr, size;
>> >> + struct device *dev;
>> >> +
>> >> + for (i = 0; i < cluster->core_count; i+

[PATCH v15 0/4] add zynqmp TCM bindings

[Tanmay Shah]

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)  | 0x_ | 0xFFE0_  |  |
| R5_0 BTCM (64 KB)  | 0x0002_ | 0xFFE2_  |  |
| R5_1 ATCM (64 KB)  | 0x_ | 0xFFE9_  | alias of 0xFFE1_ |
| R5_1 BTCM (64 KB)  | 0x0002_ | 0xFFEB_  | alias of 0xFFE3_ |
|  ___   | ___ |___   |  |
| *Lockstep Mode*| |  |  |
| R5_0 ATCM (128 KB) | 0x_ | 0xFFE0_  |  |
| R5_0 BTCM (128 KB) | 0x0002_ | 0xFFE2_  |  |

References:
UG1085 TCM address space:
https://docs.xilinx.com/r/en-US/ug1085-zynq-ultrascale-trm/Tightly-Coupled-Memory-Address-Map

---

prerequisite-patch-link: 
https://lore.kernel.org/all/d4556268-8274-4089-949f-3b97d6779...@gmail.com/
Base Branch: 6.9.rc2

Changes in v15:
  - Use hardcode TCM addresses as fallback method if "reg" unavailable
  - Use new bindings for r5fss subsystem

Changes in v14:
  - Add xlnx,tcm-mode property and use it for TCM configuration
  - Add Versal and Versal-NET platform support
  - Maintain backward compatibility for ZynqMP platform and use hardcode
TCM addresses

Changes in v13:
  - Have power-domains property for lockstep case instead of
keeping it flexible.
  - Add "items:" list in power-domains property


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 | 279 --
 .../boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts  |   8 +
 arch/arm64/boot/dts/xilinx/zynqmp.dtsi|  67 -
 drivers/remoteproc/xlnx_r5_remoteproc.c   | 273 +
 4 files changed, 459 insertions(+), 168 deletions(-)


base-commit: 4d5aabb6843939fad36912be8bf109adf9af0848
-- 
2.25.1

[PATCH v15 3/4] dts: zynqmp: add properties for TCM in remoteproc

[Tanmay Shah]

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 
---
 .../boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts  |  8 +++
 arch/arm64/boot/dts/xilinx/zynqmp.dtsi| 67 +--
 2 files changed, 70 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 25d20d803230..ef31b0fc73d1 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -260,19 +260,76 @@ fpga_full: fpga-full {
ranges;
};
 
-   remoteproc {
+   rproc_lockstep: remoteproc@ffe0 {
compatible = "xlnx,zynqmp-r5fss";
xlnx,cluster-mode = <1>;
+   xlnx,tcm-mode = <1>;
 
-   r5f-0 {
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x0 0x1 0x0 0xffe1 0x0 0x1>,
+<0x0 0x3 0x0 0xffe3 0x0 0x1>;
+
+   r5f@0 {
+   compatible = "xlnx,zynqmp-r5f";
+   reg = <0x0 0x0 0x0 0x1>,
+ <0x0 0x2 0x0 0x1>,
+ <0x0 0x1 0x0 0x1>,
+ <0x0 0x3 0x0 0x1>;
+   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 0x1>, <0x1 0x2 0x0 0x1>;
+   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@ffe0 {
+   status = "disabled";
+   compatible = "xlnx,zynqmp-r5fss";
+   xlnx,cluster-mode = <0>;
+   xlnx,tcm-mode = <0>;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x1 0x0 0x0 0xffe9 0x0 0x1>,
+<0x1 0x2 0x0 0xffeb 0x0 0x1>;
+
+   r5f@0 {
compatible = "xlnx,zynqmp-r5f";
-   power-domains = <&zynqmp_firmware PD_RPU_0>;
+   reg = <0x0 0x0 0x0 0x1>, <0x0 0x2 0x0 0x1>;
+   reg-names = "atcm0", "btcm0";
+   power-domains = <&zynqmp_firmware PD_RPU_0>,
+   <&zynqmp_firmware PD_R5_0_ATCM>,
+  

[PATCH v15 1/4] remoteproc: zynqmp: fix lockstep mode memory region

[Tanmay Shah]

In lockstep mode, r5 core0 uses TCM of R5 core1. Following is lockstep
mode memory region as per hardware reference manual.

|  *TCM* |   *R5 View* | *Linux view* |
| R5_0 ATCM (128 KB) | 0x_ | 0xFFE0_  |
| R5_0 BTCM (128 KB) | 0x0002_ | 0xFFE2_  |

However, driver shouldn't model it as above because R5 core0 TCM and core1
TCM has different power-domains mapped to it.
Hence, TCM address space in lockstep mode should be modeled as 64KB
regions only where each region has its own power-domain as following:

|  *TCM* |   *R5 View* | *Linux view* |
| R5_0 ATCM0 (64 KB) | 0x_ | 0xFFE0_  |
| R5_0 BTCM0 (64 KB) | 0x0002_ | 0xFFE2_  |
| R5_0 ATCM1 (64 KB) | 0x0001_ | 0xFFE1_  |
| R5_0 BTCM1 (64 KB) | 0x0003_ | 0xFFE3_  |

This makes driver maintanance easy and makes design robust for future
platorms as well.

Signed-off-by: Tanmay Shah 
---
 drivers/remoteproc/xlnx_r5_remoteproc.c | 146 ++--
 1 file changed, 12 insertions(+), 134 deletions(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index cfbd97b89c26..0f942440b4e2 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -84,12 +84,12 @@ static const struct mem_bank_data zynqmp_tcm_banks_split[] 
= {
{0xffebUL, 0x2, 0x1UL, PD_R5_1_BTCM, "btcm1"},
 };
 
-/* In lockstep mode cluster combines each 64KB TCM and makes 128KB TCM */
+/* In lockstep mode cluster uses each 64KB TCM from second core as well */
 static const struct mem_bank_data zynqmp_tcm_banks_lockstep[] = {
-   {0xffe0UL, 0x0, 0x2UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 128KB 
each */
-   {0xffe2UL, 0x2, 0x2UL, PD_R5_0_BTCM, "btcm0"},
-   {0, 0, 0, PD_R5_1_ATCM, ""},
-   {0, 0, 0, PD_R5_1_BTCM, ""},
+   {0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each 
*/
+   {0xffe2UL, 0x2, 0x1UL, PD_R5_0_BTCM, "btcm0"},
+   {0xffe1UL, 0x1, 0x1UL, PD_R5_1_ATCM, "atcm1"},
+   {0xffe3UL, 0x3, 0x1UL, PD_R5_1_BTCM, "btcm1"},
 };
 
 /**
@@ -541,14 +541,14 @@ static int tcm_mem_map(struct rproc *rproc,
 }
 
 /*
- * add_tcm_carveout_split_mode()
+ * add_tcm_banks()
  * @rproc: single R5 core's corresponding rproc instance
  *
- * allocate and add remoteproc carveout for TCM memory in split mode
+ * allocate and add remoteproc carveout for TCM memory
  *
  * return 0 on success, otherwise non-zero value on failure
  */
-static int add_tcm_carveout_split_mode(struct rproc *rproc)
+static int add_tcm_banks(struct rproc *rproc)
 {
struct rproc_mem_entry *rproc_mem;
struct zynqmp_r5_core *r5_core;
@@ -581,10 +581,10 @@ static int add_tcm_carveout_split_mode(struct rproc 
*rproc)
 ZYNQMP_PM_REQUEST_ACK_BLOCKING);
if (ret < 0) {
dev_err(dev, "failed to turn on TCM 0x%x", 
pm_domain_id);
-   goto release_tcm_split;
+   goto release_tcm;
}
 
-   dev_dbg(dev, "TCM carveout split mode %s addr=%llx, da=0x%x, 
size=0x%lx",
+   dev_dbg(dev, "TCM carveout %s addr=%llx, da=0x%x, size=0x%lx",
bank_name, bank_addr, da, bank_size);
 
rproc_mem = rproc_mem_entry_init(dev, NULL, bank_addr,
@@ -594,99 +594,16 @@ static int add_tcm_carveout_split_mode(struct rproc 
*rproc)
if (!rproc_mem) {
ret = -ENOMEM;
zynqmp_pm_release_node(pm_domain_id);
-   goto release_tcm_split;
-   }
-
-   rproc_add_carveout(rproc, rproc_mem);
-   rproc_coredump_add_segment(rproc, da, bank_size);
-   }
-
-   return 0;
-
-release_tcm_split:
-   /* If failed, Turn off all TCM banks turned on before */
-   for (i--; i >= 0; i--) {
-   pm_domain_id = r5_core->tcm_banks[i]->pm_domain_id;
-   zynqmp_pm_release_node(pm_domain_id);
-   }
-   return ret;
-}
-
-/*
- * add_tcm_carveout_lockstep_mode()
- * @rproc: single R5 core's corresponding rproc instance
- *
- * allocate and add remoteproc carveout for TCM memory in lockstep mode
- *
- * return 0 on success, otherwise non-zero value on failure
- */
-static int add_tcm_carveout_lockstep_mode(struct rproc *rproc)
-{
-   struct rproc_mem_entry *rproc_mem;
-   struct zynqmp_r5_core *r5_core;
-   int i, num_banks, ret;
-   phys_addr_t bank_addr;
-   size_t bank_size = 0;
-   struct device *dev;
-   u32 pm_domain_id;
-   char *bank_name;
-   u32 da;
-
-   r5_core = rproc->priv;
-   dev = r5_core->dev;
-
-   

[PATCH v15 2/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings

[Tanmay Shah]

From: Radhey Shyam Pandey 

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 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Tanmay Shah 
---
 .../remoteproc/xlnx,zynqmp-r5fss.yaml | 279 --
 1 file changed, 257 insertions(+), 22 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml 
b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
index 78aac69f1060..6f13da11f593 100644
--- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
@@ -18,11 +18,26 @@ description: |
 
 properties:
   compatible:
-const: xlnx,zynqmp-r5fss
+enum:
+  - xlnx,zynqmp-r5fss
+  - xlnx,versal-r5fss
+  - xlnx,versal-net-r52fss
+
+  "#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,
@@ -36,8 +51,16 @@ properties:
   1: lockstep mode (default)
   2: single cpu mode
 
+  xlnx,tcm-mode:
+$ref: /schemas/types.yaml#/definitions/uint32
+enum: [0, 1]
+description: |
+  Configure RPU TCM
+  0: split mode
+  1: lockstep mode
+
 patternProperties:
-  "^r5f-[a-f0-9]+$":
+  "^r(.*)@[0-9a-f]+$":
 type: object
 description: |
   The RPU is located in the Low Power Domain of the Processor Subsystem.
@@ -52,10 +75,22 @@ patternProperties:
 
 properties:
   compatible:
-const: xlnx,zynqmp-r5f
+enum:
+  - xlnx,zynqmp-r5f
+  - xlnx,versal-r5f
+  - xlnx,versal-net-r52f
+
+  reg:
+minItems: 1
+maxItems: 4
+
+  reg-names:
+minItems: 1
+maxItems: 4
 
   power-domains:
-maxItems: 1
+minItems: 2
+maxItems: 5
 
   mboxes:
 minItems: 1
@@ -101,35 +136,235 @@ patternProperties:
 
 required:
   - compatible
+  - reg
+  - reg-names
   - power-domains
 
-unevaluatedProperties: false
-
 required:
   - compatible
+  - "#address-cells"
+  - "#size-cells"
+  - ranges
+
+allOf:
+  - if:
+  properties:
+compatible:
+  contains:
+enum:
+  - xlnx,versal-net-r52fss
+then:
+  properties:
+xlnx,tcm-mode: false
+
+  patternProperties:
+"^r52f@[0-9a-f]+$":
+  type: object
+
+  properties:
+reg:
+  minItems: 1
+  items:
+- description: ATCM internal memory
+- description: BTCM internal memory
+- description: CTCM internal memory
+
+reg-names:
+  minItems: 1
+  items:
+- const: atcm0
+- const: btcm0
+- const: ctcm0
+
+power-domains:
+  minItems: 2
+  items:
+- description: RPU core power domain
+- description: ATCM power domain
+- description: BTCM power domain
+- description: CTCM power domain
+
+  - if:
+  properties:
+compatible:
+  contains:
+enum:
+  - xlnx,zynqmp-r5fss
+  - xlnx,versal-r5fss
+then:
+  if:
+properties:
+  xlnx,cluster-mode:
+enum: [1, 2]
+  then:
+properties:
+  xlnx,tcm-mode:
+enum: [1]
+
+patternProperties:
+  "^r5f@[0-9a-f]+$":
+type: object
+
+properties:
+  reg:
+minItems: 1
+items:
+  - description: ATCM internal memory
+

[PATCH v15 4/4] remoteproc: zynqmp: parse TCM from device tree

[Tanmay Shah]

ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
is available in device-tree. Parse TCM information in driver
as per new bindings.

Signed-off-by: Tanmay Shah 
---

Changes in v15:
  - Use hardcode TCM addresses as fallback method if "reg" unavailable
  - Remove Versal and Versal-net support

Changes in v14:
  - Add Versal platform support
  - Add Versal-NET platform support
  - Maintain backward compatibility for ZynqMP platform and use hardcode
TCM addresses
  - Configure TCM based on xlnx,tcm-mode property for Versal
  - Avoid TCM configuration if that property isn't available in dt

 drivers/remoteproc/xlnx_r5_remoteproc.c | 127 ++--
 1 file changed, 120 insertions(+), 7 deletions(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 0f942440b4e2..7b1c12108bff 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -74,8 +74,8 @@ struct mbox_info {
 };
 
 /*
- * Hardcoded TCM bank values. This will be removed once TCM bindings are
- * accepted for system-dt specifications and upstreamed in linux kernel
+ * Hardcoded TCM bank values. This will stay in driver to maintain backward
+ * compatibility with device-tree that does not have TCM information.
  */
 static const struct mem_bank_data zynqmp_tcm_banks_split[] = {
{0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each 
*/
@@ -761,6 +761,103 @@ static struct zynqmp_r5_core 
*zynqmp_r5_add_rproc_core(struct device *cdev)
return ERR_PTR(ret);
 }
 
+static int zynqmp_r5_get_tcm_node_from_dt(struct zynqmp_r5_cluster *cluster)
+{
+   int i, j, tcm_bank_count, ret, tcm_pd_idx, pd_count;
+   struct of_phandle_args out_args;
+   struct zynqmp_r5_core *r5_core;
+   struct platform_device *cpdev;
+   struct mem_bank_data *tcm;
+   struct device_node *np;
+   struct resource *res;
+   u64 abs_addr, size;
+   struct device *dev;
+
+   for (i = 0; i < cluster->core_count; i++) {
+   r5_core = cluster->r5_cores[i];
+   dev = r5_core->dev;
+   np = r5_core->np;
+
+   pd_count = of_count_phandle_with_args(np, "power-domains",
+ "#power-domain-cells");
+
+   if (pd_count <= 0) {
+   dev_err(dev, "invalid power-domains property, %d\n", 
pd_count);
+   return -EINVAL;
+   }
+
+   /* First entry in power-domains list is for r5 core, rest for 
TCM. */
+   tcm_bank_count = pd_count - 1;
+
+   if (tcm_bank_count <= 0) {
+   dev_err(dev, "invalid TCM count %d\n", tcm_bank_count);
+   return -EINVAL;
+   }
+
+   r5_core->tcm_banks = devm_kcalloc(dev, tcm_bank_count,
+ sizeof(struct mem_bank_data 
*),
+ GFP_KERNEL);
+   if (!r5_core->tcm_banks)
+   return -ENOMEM;
+
+   r5_core->tcm_bank_count = tcm_bank_count;
+   for (j = 0, tcm_pd_idx = 1; j < tcm_bank_count; j++, 
tcm_pd_idx++) {
+   tcm = devm_kzalloc(dev, sizeof(struct mem_bank_data),
+  GFP_KERNEL);
+   if (!tcm)
+   return -ENOMEM;
+
+   r5_core->tcm_banks[j] = tcm;
+
+   /* Get power-domains id of TCM. */
+   ret = of_parse_phandle_with_args(np, "power-domains",
+"#power-domain-cells",
+tcm_pd_idx, &out_args);
+   if (ret) {
+   dev_err(r5_core->dev,
+   "failed to get tcm %d pm domain, ret 
%d\n",
+   tcm_pd_idx, ret);
+   return ret;
+   }
+   tcm->pm_domain_id = out_args.args[0];
+   of_node_put(out_args.np);
+
+   /* Get TCM address without translation. */
+   ret = of_property_read_reg(np, j, &abs_addr, &size);
+   if (ret) {
+   dev_err(dev, "failed to get reg property\n");
+   return ret;
+   }
+
+   /*
+* Remote processor can address only 32 bits
+* so convert 64-bits into 32-bits. This will discard
+* any unwanted upper 32-bi

[PATCH] drivers: remoteproc: xlnx: Add Versal and Versal-NET support

[Tanmay Shah]

AMD-Xilinx Versal platform is successor of ZynqMP platform.
Real-time Processing Unit R5 cluster IP on Versal is same as
of ZynqMP Platform. Power-domains ids for Versal platform is
different than ZynqMP.

AMD-Xilinx Versal-NET platform is successor of Versal platform.
Versal-NET Real-Time Processing Unit has two clusters and each
cluster contains dual core ARM Cortex-R52 processors. Each R52
core is assigned 128KB of TCM memory.

Signed-off-by: Tanmay Shah 
---
 drivers/remoteproc/xlnx_r5_remoteproc.c | 53 -
 1 file changed, 17 insertions(+), 36 deletions(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 7b1c12108bff..a6d8ac7394e7 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -300,36 +300,6 @@ static void zynqmp_r5_rproc_kick(struct rproc *rproc, int 
vqid)
dev_warn(dev, "failed to send message\n");
 }
 
-/*
- * zynqmp_r5_set_mode()
- *
- * set RPU cluster and TCM operation mode
- *
- * @r5_core: pointer to zynqmp_r5_core type object
- * @fw_reg_val: value expected by firmware to configure RPU cluster mode
- * @tcm_mode: value expected by fw to configure TCM mode (lockstep or split)
- *
- * Return: 0 for success and < 0 for failure
- */
-static int zynqmp_r5_set_mode(struct zynqmp_r5_core *r5_core,
- enum rpu_oper_mode fw_reg_val,
- enum rpu_tcm_comb tcm_mode)
-{
-   int ret;
-
-   ret = zynqmp_pm_set_rpu_mode(r5_core->pm_domain_id, fw_reg_val);
-   if (ret < 0) {
-   dev_err(r5_core->dev, "failed to set RPU mode\n");
-   return ret;
-   }
-
-   ret = zynqmp_pm_set_tcm_config(r5_core->pm_domain_id, tcm_mode);
-   if (ret < 0)
-   dev_err(r5_core->dev, "failed to configure TCM\n");
-
-   return ret;
-}
-
 /*
  * zynqmp_r5_rproc_start()
  * @rproc: single R5 core's corresponding rproc instance
@@ -941,7 +911,7 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster 
*cluster,
/* Maintain backward compatibility for zynqmp by using hardcode TCM 
address. */
if (of_find_property(r5_core->np, "reg", NULL))
ret = zynqmp_r5_get_tcm_node_from_dt(cluster);
-   else
+   else if (device_is_compatible(dev, "xlnx,zynqmp-r5fss"))
ret = zynqmp_r5_get_tcm_node(cluster);
 
if (ret) {
@@ -960,12 +930,21 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster 
*cluster,
return ret;
}
 
-   ret = zynqmp_r5_set_mode(r5_core, fw_reg_val, tcm_mode);
-   if (ret) {
-   dev_err(dev, "failed to set r5 cluster mode %d, err 
%d\n",
-   cluster->mode, ret);
+   ret = zynqmp_pm_set_rpu_mode(r5_core->pm_domain_id, fw_reg_val);
+   if (ret < 0) {
+   dev_err(r5_core->dev, "failed to set RPU mode\n");
return ret;
}
+
+   if (of_find_property(dev_of_node(dev), "xlnx,tcm-mode", NULL) ||
+   device_is_compatible(dev, "xlnx,zynqmp-r5fss")) {
+   ret = zynqmp_pm_set_tcm_config(r5_core->pm_domain_id,
+  tcm_mode);
+   if (ret < 0) {
+   dev_err(r5_core->dev, "failed to configure 
TCM\n");
+   return ret;
+   }
+   }
}
 
return 0;
@@ -1022,7 +1001,7 @@ static int zynqmp_r5_cluster_init(struct 
zynqmp_r5_cluster *cluster)
ret = of_property_read_u32(dev_node, "xlnx,tcm-mode", (u32 
*)&tcm_mode);
if (ret)
return ret;
-   } else {
+   } else if (device_is_compatible(dev, "xlnx,zynqmp-r5fss")) {
if (cluster_mode == LOCKSTEP_MODE)
tcm_mode = PM_RPU_TCM_COMB;
else
@@ -1212,6 +1191,8 @@ static int zynqmp_r5_remoteproc_probe(struct 
platform_device *pdev)
 
 /* Match table for OF platform binding */
 static const struct of_device_id zynqmp_r5_remoteproc_match[] = {
+   { .compatible = "xlnx,versal-net-r52fss", },
+   { .compatible = "xlnx,versal-r5fss", },
{ .compatible = "xlnx,zynqmp-r5fss", },
{ /* end of list */ },
 };

base-commit: 912ebe48bec5927e2049e91b0e8a9cc682a709d2
-- 
2.25.1

Re: [PATCH] drivers: remoteproc: xlnx: Add Versal and Versal-NET support

[Tanmay Shah]

On 4/23/24 11:06 AM, Nathan Chancellor wrote:
> Hi Tanmay,
> 
> On Thu, Apr 18, 2024 at 03:01:25PM -0700, Tanmay Shah wrote:
>> AMD-Xilinx Versal platform is successor of ZynqMP platform.
>> Real-time Processing Unit R5 cluster IP on Versal is same as
>> of ZynqMP Platform. Power-domains ids for Versal platform is
>> different than ZynqMP.
>> 
>> AMD-Xilinx Versal-NET platform is successor of Versal platform.
>> Versal-NET Real-Time Processing Unit has two clusters and each
>> cluster contains dual core ARM Cortex-R52 processors. Each R52
>> core is assigned 128KB of TCM memory.
>> 
>> Signed-off-by: Tanmay Shah 
>> ---
>>  drivers/remoteproc/xlnx_r5_remoteproc.c | 53 -
>>  1 file changed, 17 insertions(+), 36 deletions(-)
>> 
>> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
>> b/drivers/remoteproc/xlnx_r5_remoteproc.c
>> index 7b1c12108bff..a6d8ac7394e7 100644
>> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
>> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
>> @@ -300,36 +300,6 @@ static void zynqmp_r5_rproc_kick(struct rproc *rproc, 
>> int vqid)
>>  dev_warn(dev, "failed to send message\n");
>>  }
>>  
>> -/*
>> - * zynqmp_r5_set_mode()
>> - *
>> - * set RPU cluster and TCM operation mode
>> - *
>> - * @r5_core: pointer to zynqmp_r5_core type object
>> - * @fw_reg_val: value expected by firmware to configure RPU cluster mode
>> - * @tcm_mode: value expected by fw to configure TCM mode (lockstep or split)
>> - *
>> - * Return: 0 for success and < 0 for failure
>> - */
>> -static int zynqmp_r5_set_mode(struct zynqmp_r5_core *r5_core,
>> -  enum rpu_oper_mode fw_reg_val,
>> -  enum rpu_tcm_comb tcm_mode)
>> -{
>> -int ret;
>> -
>> -ret = zynqmp_pm_set_rpu_mode(r5_core->pm_domain_id, fw_reg_val);
>> -if (ret < 0) {
>> -dev_err(r5_core->dev, "failed to set RPU mode\n");
>> -return ret;
>> -}
>> -
>> -ret = zynqmp_pm_set_tcm_config(r5_core->pm_domain_id, tcm_mode);
>> -if (ret < 0)
>> -dev_err(r5_core->dev, "failed to configure TCM\n");
>> -
>> -return ret;
>> -}
>> -
>>  /*
>>   * zynqmp_r5_rproc_start()
>>   * @rproc: single R5 core's corresponding rproc instance
>> @@ -941,7 +911,7 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster 
>> *cluster,
>>  /* Maintain backward compatibility for zynqmp by using hardcode TCM 
>> address. */
>>  if (of_find_property(r5_core->np, "reg", NULL))
>>  ret = zynqmp_r5_get_tcm_node_from_dt(cluster);
>> -else
>> +else if (device_is_compatible(dev, "xlnx,zynqmp-r5fss"))
>>  ret = zynqmp_r5_get_tcm_node(cluster);
> 
> This change breaks the build with clang:
> 
>   drivers/remoteproc/xlnx_r5_remoteproc.c:914:11: error: variable 'ret' is 
> used uninitialized whenever 'if' condition is false 
> [-Werror,-Wsometimes-uninitialized]
> 914 | else if (device_is_compatible(dev, "xlnx,zynqmp-r5fss"))
> |  ^~
>   drivers/remoteproc/xlnx_r5_remoteproc.c:917:6: note: uninitialized use 
> occurs here
> 917 | if (ret) {
> | ^~~
>   drivers/remoteproc/xlnx_r5_remoteproc.c:914:7: note: remove the 'if' if its 
> condition is always true
> 914 | else if (device_is_compatible(dev, "xlnx,zynqmp-r5fss"))
> |  ^~~
> 915 | ret = zynqmp_r5_get_tcm_node(cluster);
>   drivers/remoteproc/xlnx_r5_remoteproc.c:907:9: note: initialize the 
> variable 'ret' to silence this warning
> 907 | int ret, i;
> |^
> | = 0
>   1 error generated.
> 
> Should ret be initialized to zero or should there be an else statement?

Hello,

Thanks for analysis. ret should be initialized with -EINVAL, so else can be 
avoided.
I will send patch by EOD.

Thanks,
Tanmay

> 
> Cheers,
> Nathan
> 
>>  
>>  if (ret) {
>> @@ -960,12 +930,21 @@ static int zynqmp_r5_core_init(struct 
>> zynqmp_r5_cluster *cluster,
>>  return ret;
>>  }
>>  
>> -ret = zynqmp_r5_set_mode(r5_core, fw_reg_val, tcm_mode);
>> -  

[PATCH] drivers: remoteproc: xlnx: fix uninitialize variable use

[Tanmay Shah]

Fix following warning for clang compiler with W=1 option:
initialize the variable 'ret' to silence this warning
 907 | int ret, i;
 |^
 | = 0

Fixes: a6b974b40f94 ("drivers: remoteproc: xlnx: Add Versal and Versal-NET 
support")
Reported-by: kernel test robot 
Closes: 
https://lore.kernel.org/oe-kbuild-all/202404231839.ohiy9lw8-...@intel.com/
Signed-off-by: Tanmay Shah 
---
 drivers/remoteproc/xlnx_r5_remoteproc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index a6d8ac7394e7..d98940d7ef8f 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -904,7 +904,7 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster 
*cluster,
 {
struct device *dev = cluster->dev;
struct zynqmp_r5_core *r5_core;
-   int ret, i;
+   int ret = -EINVAL, i;
 
r5_core = cluster->r5_cores[0];
 

base-commit: e99fcac055b3325283d6c5c61a117651fb147686
-- 
2.25.1

[PATCH] drivers: remoteproc: xlnx: fix uninitialized tcm mode

[Tanmay Shah]

Add "else" case for default tcm mode to silent following static check:

zynqmp_r5_cluster_init()
 error: uninitialized symbol 'tcm_mode'.

Fixes: a6b974b40f94 ("drivers: remoteproc: xlnx: Add Versal and Versal-NET 
support")
Signed-off-by: Tanmay Shah 
---
 drivers/remoteproc/xlnx_r5_remoteproc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index d98940d7ef8f..84243d1dff9f 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -1006,6 +1006,8 @@ static int zynqmp_r5_cluster_init(struct 
zynqmp_r5_cluster *cluster)
tcm_mode = PM_RPU_TCM_COMB;
else
tcm_mode = PM_RPU_TCM_SPLIT;
+   } else {
+   tcm_mode = PM_RPU_TCM_COMB;
}
 
/*

base-commit: a49a6c600193e32123e8885515051b34a5d711ff
-- 
2.25.1

[PATCH 0/2] remoteproc: xlnx: Add attach detach ops and sram support

[Tanmay Shah]

Attach detach ops are needed to connect to remote processor that is
running before remoteproc driver is probed. Implement remoteproc
framework ops that enables such use case on AMD-Xilinx platforms.

Remote processor can also use On Chip sram Memory (OCM) for various
purpose. For example, for fast code execution or data access compare
to DDR memory. Such sram region is made available to remoteproc nodes
via "sram" property. Add support in driver to parse and use OCM memory
via sram property.

Tanmay Shah (2):
  drivers: remoteproc: xlnx: add attach detach support
  drivers: remoteproc: xlnx: add sram support

 drivers/remoteproc/xlnx_r5_remoteproc.c | 385 +++-
 1 file changed, 380 insertions(+), 5 deletions(-)


base-commit: 0496190c4d42965acb31b9da1b6dac3509791062
-- 
2.25.1

[PATCH 1/2] drivers: remoteproc: xlnx: add attach detach support

[Tanmay Shah]

It is possible that remote processor is already running before
linux boot or remoteproc platform driver probe. Implement required
remoteproc framework ops to provide resource table address and
connect or disconnect with remote processor in such case.

Signed-off-by: Tanmay Shah 
---
 drivers/remoteproc/xlnx_r5_remoteproc.c | 164 +++-
 1 file changed, 160 insertions(+), 4 deletions(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 84243d1dff9f..af7aff5e9098 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -25,6 +25,10 @@
 /* RX mailbox client buffer max length */
 #define MBOX_CLIENT_BUF_MAX(IPI_BUF_LEN_MAX + \
 sizeof(struct zynqmp_ipi_message))
+
+#define RSC_TBL_XLNX_MAGIC ((uint32_t)'x' << 24 | (uint32_t)'a' << 16 | \
+(uint32_t)'m' << 8 | (uint32_t)'p')
+
 /*
  * settings for RPU cluster mode which
  * reflects possible values of xlnx,cluster-mode dt-property
@@ -73,6 +77,15 @@ struct mbox_info {
struct mbox_chan *rx_chan;
 };
 
+/* Xilinx Platform specific data structure */
+struct rsc_tbl_data {
+   const int version;
+   const u32 magic_num;
+   const u32 comp_magic_num;
+   const u32 rsc_tbl_size;
+   const uintptr_t rsc_tbl;
+} __packed;
+
 /*
  * Hardcoded TCM bank values. This will stay in driver to maintain backward
  * compatibility with device-tree that does not have TCM information.
@@ -95,20 +108,24 @@ static const struct mem_bank_data 
zynqmp_tcm_banks_lockstep[] = {
 /**
  * struct zynqmp_r5_core
  *
+ * @rsc_tbl_va: resource table virtual address
  * @dev: device of RPU instance
  * @np: device node of RPU instance
  * @tcm_bank_count: number TCM banks accessible to this RPU
  * @tcm_banks: array of each TCM bank data
  * @rproc: rproc handle
+ * @rsc_tbl_size: resource table size retrieved from remote
  * @pm_domain_id: RPU CPU power domain id
  * @ipi: pointer to mailbox information
  */
 struct zynqmp_r5_core {
+   struct resource_table *rsc_tbl_va;
struct device *dev;
struct device_node *np;
int tcm_bank_count;
struct mem_bank_data **tcm_banks;
struct rproc *rproc;
+   u32 rsc_tbl_size;
u32 pm_domain_id;
struct mbox_info *ipi;
 };
@@ -621,10 +638,19 @@ static int zynqmp_r5_rproc_prepare(struct rproc *rproc)
 {
int ret;
 
-   ret = add_tcm_banks(rproc);
-   if (ret) {
-   dev_err(&rproc->dev, "failed to get TCM banks, err %d\n", ret);
-   return ret;
+   /**
+* For attach/detach use case, Firmware is already loaded so
+* TCM isn't really needed at all. Also, for security TCM can be
+* locked in such case and linux may not have access at all.
+* So avoid adding TCM banks. TCM power-domains requested during attach
+* callback.
+*/
+   if (rproc->state != RPROC_DETACHED) {
+   ret = add_tcm_banks(rproc);
+   if (ret) {
+   dev_err(&rproc->dev, "failed to get TCM banks, err 
%d\n", ret);
+   return ret;
+   }
}
 
ret = add_mem_regions_carveout(rproc);
@@ -662,6 +688,123 @@ static int zynqmp_r5_rproc_unprepare(struct rproc *rproc)
return 0;
 }
 
+static struct resource_table *zynqmp_r5_get_loaded_rsc_table(struct rproc 
*rproc,
+size_t *size)
+{
+   struct zynqmp_r5_core *r5_core;
+
+   r5_core = rproc->priv;
+
+   *size = r5_core->rsc_tbl_size;
+
+   return r5_core->rsc_tbl_va;
+}
+
+static int zynqmp_r5_get_rsc_table_va(struct zynqmp_r5_core *r5_core)
+{
+   struct device *dev = r5_core->dev;
+   struct rsc_tbl_data *rsc_data_va;
+   struct resource_table *rsc_addr;
+   struct resource res_mem;
+   struct device_node *np;
+   int ret;
+
+   /**
+* It is expected from remote processor firmware to provide resource
+* table address via struct rsc_tbl_data data structure.
+* Start address of first entry under "memory-region" property list
+* contains that data structure which holds resource table address, size
+* and some magic number to validate correct resource table entry.
+*/
+   np = of_parse_phandle(r5_core->np, "memory-region", 0);
+   if (!np) {
+   dev_err(dev, "failed to get memory region dev node\n");
+   return -EINVAL;
+   }
+
+   ret = of_address_to_resource(np, 0, &res_mem);
+   if (ret) {
+   dev_err(dev, "failed to get memory-region resource addr\n");
+   return -EINVAL;
+   }
+
+   rsc_data_va = devm_ioremap_wc(

[PATCH 2/2] drivers: remoteproc: xlnx: add sram support

[Tanmay Shah]

AMD-Xilinx zynqmp platform contains on-chip sram memory (OCM).
R5 cores can access OCM and access is faster than DDR memory but slower
than TCM memories available. Sram region can have optional multiple
power-domains.

Signed-off-by: Tanmay Shah 
---
 drivers/remoteproc/xlnx_r5_remoteproc.c | 221 +++-
 1 file changed, 220 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index af7aff5e9098..47c08b013152 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -56,6 +56,21 @@ struct mem_bank_data {
char *bank_name;
 };
 
+/**
+ * struct zynqmp_sram_bank - sram bank description
+ *
+ * @sram_res: sram address region information
+ * @power_domains: Array of pm domain id
+ * @num_pd: total pm domain id count
+ * @da: device address of sram
+ */
+struct zynqmp_sram_bank {
+   struct resource sram_res;
+   int *power_domains;
+   int num_pd;
+   u32 da;
+};
+
 /**
  * struct mbox_info
  *
@@ -109,6 +124,8 @@ static const struct mem_bank_data 
zynqmp_tcm_banks_lockstep[] = {
  * struct zynqmp_r5_core
  *
  * @rsc_tbl_va: resource table virtual address
+ * @sram: Array of sram memories assigned to this core
+ * @num_sram: number of sram for this core
  * @dev: device of RPU instance
  * @np: device node of RPU instance
  * @tcm_bank_count: number TCM banks accessible to this RPU
@@ -120,6 +137,8 @@ static const struct mem_bank_data 
zynqmp_tcm_banks_lockstep[] = {
  */
 struct zynqmp_r5_core {
struct resource_table *rsc_tbl_va;
+   struct zynqmp_sram_bank **sram;
+   int num_sram;
struct device *dev;
struct device_node *np;
int tcm_bank_count;
@@ -483,6 +502,69 @@ static int add_mem_regions_carveout(struct rproc *rproc)
return 0;
 }
 
+static int add_sram_carveouts(struct rproc *rproc)
+{
+   struct zynqmp_r5_core *r5_core = rproc->priv;
+   struct rproc_mem_entry *rproc_mem;
+   struct zynqmp_sram_bank *sram;
+   dma_addr_t dma_addr;
+   int da, i, j, ret;
+   size_t len;
+
+   for (i = 0; i < r5_core->num_sram; i++) {
+   sram = r5_core->sram[i];
+
+   dma_addr = (dma_addr_t)sram->sram_res.start;
+   len = resource_size(&sram->sram_res);
+   da = sram->da;
+
+   for (j = 0; j < sram->num_pd; j++) {
+   ret = zynqmp_pm_request_node(sram->power_domains[j],
+
ZYNQMP_PM_CAPABILITY_ACCESS, 0,
+
ZYNQMP_PM_REQUEST_ACK_BLOCKING);
+   if (ret < 0) {
+   dev_err(r5_core->dev,
+   "failed to request on SRAM pd 0x%x",
+   sram->power_domains[j]);
+   goto fail_sram;
+   } else {
+   pr_err("sram pd 0x%x request success\n",
+  sram->power_domains[j]);
+   }
+   }
+
+   /* Register associated reserved memory regions */
+   rproc_mem = rproc_mem_entry_init(&rproc->dev, NULL,
+(dma_addr_t)dma_addr,
+len, da,
+zynqmp_r5_mem_region_map,
+zynqmp_r5_mem_region_unmap,
+sram->sram_res.name);
+
+   rproc_add_carveout(rproc, rproc_mem);
+   rproc_coredump_add_segment(rproc, da, len);
+
+   dev_err(&rproc->dev, "sram carveout %s addr=%llx, da=0x%x, 
size=0x%lx",
+   sram->sram_res.name, dma_addr, da, len);
+   }
+
+   return 0;
+
+fail_sram:
+   /* Release current sram pd. */
+   while (--j >= 0)
+   zynqmp_pm_release_node(sram->power_domains[j]);
+
+   /* Release previously requested sram pd. */
+   while (--i >= 0) {
+   sram = r5_core->sram[i];
+   for (j = 0; j < sram->num_pd; j++)
+   zynqmp_pm_release_node(sram->power_domains[j]);
+   }
+
+   return ret;
+}
+
 /*
  * tcm_mem_unmap()
  * @rproc: single R5 core's corresponding rproc instance
@@ -659,6 +741,12 @@ static int zynqmp_r5_rproc_prepare(struct rproc *rproc)
return ret;
}
 
+   ret = add_sram_carveouts(rproc);
+   if (ret) {
+   dev_err(&rproc->dev, "failed to get sram carveout %d\n", ret);
+   return ret;
+   }
+
return 0;
 }
 
@@ -673,8 +761,9 @@ static int zynqmp_r5_rproc_prepar

[PATCH v2 0/2] remoteproc: xlnx: Add attach detach ops and sram support

[Tanmay Shah]

Attach detach ops are needed to connect to remote processor that is
running before remoteproc driver is probed. Implement remoteproc
framework ops that enables such use case on AMD-Xilinx platforms.

Remote processor can also use On Chip sram Memory (OCM) for various
purpose. For example, for fast code execution or data access compare
to DDR memory. Such sram region is made available to remoteproc nodes
via "sram" property. Add support in driver to parse and use OCM memory
via sram property.

Changes in v2:
  - Fix following sparse warnings

drivers/remoteproc/xlnx_r5_remoteproc.c:827:21: sparse:expected struct 
rsc_tbl_data *rsc_data_va
drivers/remoteproc/xlnx_r5_remoteproc.c:844:18: sparse:expected struct 
resource_table *rsc_addr
drivers/remoteproc/xlnx_r5_remoteproc.c:898:24: sparse:expected void 
volatile [noderef] __iomem *addr
drivers/remoteproc/xlnx_r5_remoteproc.c:995:26: sparse: warning: Using plain 
integer as NULL pointer

Tanmay Shah (2):
  drivers: remoteproc: xlnx: add attach detach support
  drivers: remoteproc: xlnx: add sram support

 drivers/remoteproc/xlnx_r5_remoteproc.c | 385 +++-
 1 file changed, 380 insertions(+), 5 deletions(-)


base-commit: c8d8f841e95bcc07ac8c5621fc171a24f1fd5cdb
-- 
2.25.1

[PATCH v2 1/2] drivers: remoteproc: xlnx: add attach detach support

[Tanmay Shah]

It is possible that remote processor is already running before
linux boot or remoteproc platform driver probe. Implement required
remoteproc framework ops to provide resource table address and
connect or disconnect with remote processor in such case.

Signed-off-by: Tanmay Shah 
---

Changes in v2:
  - Fix following sparse warnings

drivers/remoteproc/xlnx_r5_remoteproc.c:827:21: sparse:expected struct 
rsc_tbl_data *rsc_data_va
drivers/remoteproc/xlnx_r5_remoteproc.c:844:18: sparse:expected struct 
resource_table *rsc_addr
drivers/remoteproc/xlnx_r5_remoteproc.c:898:24: sparse:expected void 
volatile [noderef] __iomem *addr

 drivers/remoteproc/xlnx_r5_remoteproc.c | 164 +++-
 1 file changed, 160 insertions(+), 4 deletions(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 84243d1dff9f..039370cffa32 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -25,6 +25,10 @@
 /* RX mailbox client buffer max length */
 #define MBOX_CLIENT_BUF_MAX(IPI_BUF_LEN_MAX + \
 sizeof(struct zynqmp_ipi_message))
+
+#define RSC_TBL_XLNX_MAGIC ((uint32_t)'x' << 24 | (uint32_t)'a' << 16 | \
+(uint32_t)'m' << 8 | (uint32_t)'p')
+
 /*
  * settings for RPU cluster mode which
  * reflects possible values of xlnx,cluster-mode dt-property
@@ -73,6 +77,15 @@ struct mbox_info {
struct mbox_chan *rx_chan;
 };
 
+/* Xilinx Platform specific data structure */
+struct rsc_tbl_data {
+   const int version;
+   const u32 magic_num;
+   const u32 comp_magic_num;
+   const u32 rsc_tbl_size;
+   const uintptr_t rsc_tbl;
+} __packed;
+
 /*
  * Hardcoded TCM bank values. This will stay in driver to maintain backward
  * compatibility with device-tree that does not have TCM information.
@@ -95,20 +108,24 @@ static const struct mem_bank_data 
zynqmp_tcm_banks_lockstep[] = {
 /**
  * struct zynqmp_r5_core
  *
+ * @rsc_tbl_va: resource table virtual address
  * @dev: device of RPU instance
  * @np: device node of RPU instance
  * @tcm_bank_count: number TCM banks accessible to this RPU
  * @tcm_banks: array of each TCM bank data
  * @rproc: rproc handle
+ * @rsc_tbl_size: resource table size retrieved from remote
  * @pm_domain_id: RPU CPU power domain id
  * @ipi: pointer to mailbox information
  */
 struct zynqmp_r5_core {
+   struct resource_table *rsc_tbl_va;
struct device *dev;
struct device_node *np;
int tcm_bank_count;
struct mem_bank_data **tcm_banks;
struct rproc *rproc;
+   u32 rsc_tbl_size;
u32 pm_domain_id;
struct mbox_info *ipi;
 };
@@ -621,10 +638,19 @@ static int zynqmp_r5_rproc_prepare(struct rproc *rproc)
 {
int ret;
 
-   ret = add_tcm_banks(rproc);
-   if (ret) {
-   dev_err(&rproc->dev, "failed to get TCM banks, err %d\n", ret);
-   return ret;
+   /**
+* For attach/detach use case, Firmware is already loaded so
+* TCM isn't really needed at all. Also, for security TCM can be
+* locked in such case and linux may not have access at all.
+* So avoid adding TCM banks. TCM power-domains requested during attach
+* callback.
+*/
+   if (rproc->state != RPROC_DETACHED) {
+   ret = add_tcm_banks(rproc);
+   if (ret) {
+   dev_err(&rproc->dev, "failed to get TCM banks, err 
%d\n", ret);
+   return ret;
+   }
}
 
ret = add_mem_regions_carveout(rproc);
@@ -662,6 +688,123 @@ static int zynqmp_r5_rproc_unprepare(struct rproc *rproc)
return 0;
 }
 
+static struct resource_table *zynqmp_r5_get_loaded_rsc_table(struct rproc 
*rproc,
+size_t *size)
+{
+   struct zynqmp_r5_core *r5_core;
+
+   r5_core = rproc->priv;
+
+   *size = r5_core->rsc_tbl_size;
+
+   return r5_core->rsc_tbl_va;
+}
+
+static int zynqmp_r5_get_rsc_table_va(struct zynqmp_r5_core *r5_core)
+{
+   struct device *dev = r5_core->dev;
+   struct rsc_tbl_data *rsc_data_va;
+   struct resource_table *rsc_addr;
+   struct resource res_mem;
+   struct device_node *np;
+   int ret;
+
+   /**
+* It is expected from remote processor firmware to provide resource
+* table address via struct rsc_tbl_data data structure.
+* Start address of first entry under "memory-region" property list
+* contains that data structure which holds resource table address, size
+* and some magic number to validate correct resource table entry.
+*/
+   np = of_parse_phandle(r5_core->np, "memory-region", 0);
+   if 

[PATCH v2 2/2] drivers: remoteproc: xlnx: add sram support

[Tanmay Shah]

AMD-Xilinx zynqmp platform contains on-chip sram memory (OCM).
R5 cores can access OCM and access is faster than DDR memory but slower
than TCM memories available. Sram region can have optional multiple
power-domains.

Signed-off-by: Tanmay Shah 
---

Changes in v2:
  - Fix integer assignement to variable that also fixes following sparse 
warnings

drivers/remoteproc/xlnx_r5_remoteproc.c:995:26: sparse: warning: Using plain 
integer as NULL pointer

 drivers/remoteproc/xlnx_r5_remoteproc.c | 221 +++-
 1 file changed, 220 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 039370cffa32..e0a78a5d4ad5 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -56,6 +56,21 @@ struct mem_bank_data {
char *bank_name;
 };
 
+/**
+ * struct zynqmp_sram_bank - sram bank description
+ *
+ * @sram_res: sram address region information
+ * @power_domains: Array of pm domain id
+ * @num_pd: total pm domain id count
+ * @da: device address of sram
+ */
+struct zynqmp_sram_bank {
+   struct resource sram_res;
+   int *power_domains;
+   int num_pd;
+   u32 da;
+};
+
 /**
  * struct mbox_info
  *
@@ -109,6 +124,8 @@ static const struct mem_bank_data 
zynqmp_tcm_banks_lockstep[] = {
  * struct zynqmp_r5_core
  *
  * @rsc_tbl_va: resource table virtual address
+ * @sram: Array of sram memories assigned to this core
+ * @num_sram: number of sram for this core
  * @dev: device of RPU instance
  * @np: device node of RPU instance
  * @tcm_bank_count: number TCM banks accessible to this RPU
@@ -120,6 +137,8 @@ static const struct mem_bank_data 
zynqmp_tcm_banks_lockstep[] = {
  */
 struct zynqmp_r5_core {
struct resource_table *rsc_tbl_va;
+   struct zynqmp_sram_bank **sram;
+   int num_sram;
struct device *dev;
struct device_node *np;
int tcm_bank_count;
@@ -483,6 +502,69 @@ static int add_mem_regions_carveout(struct rproc *rproc)
return 0;
 }
 
+static int add_sram_carveouts(struct rproc *rproc)
+{
+   struct zynqmp_r5_core *r5_core = rproc->priv;
+   struct rproc_mem_entry *rproc_mem;
+   struct zynqmp_sram_bank *sram;
+   dma_addr_t dma_addr;
+   int da, i, j, ret;
+   size_t len;
+
+   for (i = 0; i < r5_core->num_sram; i++) {
+   sram = r5_core->sram[i];
+
+   dma_addr = (dma_addr_t)sram->sram_res.start;
+   len = resource_size(&sram->sram_res);
+   da = sram->da;
+
+   for (j = 0; j < sram->num_pd; j++) {
+   ret = zynqmp_pm_request_node(sram->power_domains[j],
+
ZYNQMP_PM_CAPABILITY_ACCESS, 0,
+
ZYNQMP_PM_REQUEST_ACK_BLOCKING);
+   if (ret < 0) {
+   dev_err(r5_core->dev,
+   "failed to request on SRAM pd 0x%x",
+   sram->power_domains[j]);
+   goto fail_sram;
+   } else {
+   pr_err("sram pd 0x%x request success\n",
+  sram->power_domains[j]);
+   }
+   }
+
+   /* Register associated reserved memory regions */
+   rproc_mem = rproc_mem_entry_init(&rproc->dev, NULL,
+(dma_addr_t)dma_addr,
+len, da,
+zynqmp_r5_mem_region_map,
+zynqmp_r5_mem_region_unmap,
+sram->sram_res.name);
+
+   rproc_add_carveout(rproc, rproc_mem);
+   rproc_coredump_add_segment(rproc, da, len);
+
+   dev_err(&rproc->dev, "sram carveout %s addr=%llx, da=0x%x, 
size=0x%lx",
+   sram->sram_res.name, dma_addr, da, len);
+   }
+
+   return 0;
+
+fail_sram:
+   /* Release current sram pd. */
+   while (--j >= 0)
+   zynqmp_pm_release_node(sram->power_domains[j]);
+
+   /* Release previously requested sram pd. */
+   while (--i >= 0) {
+   sram = r5_core->sram[i];
+   for (j = 0; j < sram->num_pd; j++)
+   zynqmp_pm_release_node(sram->power_domains[j]);
+   }
+
+   return ret;
+}
+
 /*
  * tcm_mem_unmap()
  * @rproc: single R5 core's corresponding rproc instance
@@ -659,6 +741,12 @@ static int zynqmp_r5_rproc_prepare(struct rproc *rproc)
return ret;
}
 
+   ret = add_sram_carveouts(rproc);
+   if (ret) {
+

Re: [PATCH 1/1] rpmsg: virtio: Make buffer size and number configurable

[Tanmay Shah]

Hello,

Thanks for your patch.

Instead of having this in Kconfig, It's better to have buffer size decided 
dynamically. Probably by resource-table.

We still need implementation that achieves that goal. Meanwhile  I think it's 
best to keep buffer size fixed.

Thanks.

On 9/28/23 10:38 AM, Divin Raj wrote:

> CAUTION: This message has originated from an External Source. Please use 
> proper judgment and caution when opening attachments, clicking links, or 
> responding to this email.
>
>
> From: Peter Hoyes 
>
> Replace the MAX_RPMSG_BUF_SIZE and MAX_RPMSG_NUM_BUFS #define in
> virtio_rpmsg_bus.c with the Kconfig parameters CONFIG_RPMSG_VIRTIO_BUF_SIZE
> and CONFIG_RPMSG_VIRTIO_MAX_NUM_BUFS, allowing user-provided customization.
>
> Making both the number of buffers and size configurable facilitates aligning
> memory requirements between vdev-buffer and vdev-vrings for client drivers
> that require larger buffer sizes, for example.
>
> Signed-off-by: Peter Hoyes 
> Signed-off-by: Divin Raj 
> ---
>  drivers/rpmsg/Kconfig| 23 +++
>  drivers/rpmsg/virtio_rpmsg_bus.c | 27 +++
>  2 files changed, 26 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig
> index d3795860f5c0..677f4a1ac8bb 100644
> --- a/drivers/rpmsg/Kconfig
> +++ b/drivers/rpmsg/Kconfig
> @@ -81,4 +81,27 @@ config RPMSG_VIRTIO
> select RPMSG_NS
> select VIRTIO
>
> +config RPMSG_VIRTIO_MAX_BUF_SIZE
> +   int "Virtio RPMSG max buffer size (in bytes)"
> +   default 512
> +   depends on RPMSG_VIRTIO
> +   help
> + This option allows you to configure the maximum buffer size (in 
> bytes)
> + for Virtio RPMSG communications. The number of buffers will be 
> computed
> + based on the number of buffers (CONFIG_RPMSG_VIRTIO_MAX_NUM_BUFS)
> + supported by the vring. By default, it supports up to a maximum of 
> 512
> + buffers (256 in each direction). Each buffer consists of 16 bytes 
> for the
> + message header and the remaining bytes for the payload.The default 
> values
> + will utilize a maximum total space of 256KB for the buffers.
> +
> +config RPMSG_VIRTIO_MAX_NUM_BUFS
> +   int "Virtio RPMSG max buffer count (even number for TX and Rx)"
> +   default 512
> +   depends on RPMSG_VIRTIO
> +   help
> + This option allows you to configure the maximum number of buffers 
> used
> + for Virtio RPMSG communication. By default, it supports up to a 
> maximum
> + of 512 buffers (256 in each direction). Please note that this value
> + should be an even number, as it accounts for both transmit (TX) and
> + receive (Rx) buffers.
>  endmenu
> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c 
> b/drivers/rpmsg/virtio_rpmsg_bus.c
> index 905ac7910c98..87a9a4fa30e0 100644
> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> @@ -109,27 +109,6 @@ struct virtio_rpmsg_channel {
>  #define to_virtio_rpmsg_channel(_rpdev) \
> container_of(_rpdev, struct virtio_rpmsg_channel, rpdev)
>
> -/*
> - * We're allocating buffers of 512 bytes each for communications. The
> - * number of buffers will be computed from the number of buffers supported
> - * by the vring, upto a maximum of 512 buffers (256 in each direction).
> - *
> - * Each buffer will have 16 bytes for the msg header and 496 bytes for
> - * the payload.
> - *
> - * This will utilize a maximum total space of 256KB for the buffers.
> - *
> - * We might also want to add support for user-provided buffers in time.
> - * This will allow bigger buffer size flexibility, and can also be used
> - * to achieve zero-copy messaging.
> - *
> - * Note that these numbers are purely a decision of this driver - we
> - * can change this without changing anything in the firmware of the remote
> - * processor.
> - */
> -#define MAX_RPMSG_NUM_BUFS (512)
> -#define MAX_RPMSG_BUF_SIZE (512)
> -
>  /*
>   * Local addresses are dynamically allocated on-demand.
>   * We do not dynamically assign addresses from the low 1024 range,
> @@ -902,12 +881,12 @@ static int rpmsg_probe(struct virtio_device *vdev)
> virtqueue_get_vring_size(vrp->svq));
>
> /* we need less buffers if vrings are small */
> -   if (virtqueue_get_vring_size(vrp->rvq) < MAX_RPMSG_NUM_BUFS / 2)
> +   if (virtqueue_get_vring_size(vrp->rvq) < 
> CONFIG_RPMSG_VIRTIO_MAX_NUM_BUFS / 2)
> vrp->num_bufs = virtqueue_get_vring_size(vrp->rvq) * 2;
> else
> -   vrp->num_bufs = MAX_RPMSG_NUM_BUFS;
> +   vrp->num_bufs = CONFIG_RPMSG_VIRTIO_MAX_NUM_BUFS;
>
> -   vrp->buf_size = MAX_RPMSG_BUF_SIZE;
> +   vrp->buf_size = CONFIG_RPMSG_VIRTIO_MAX_BUF_SIZE;
>
> total_buf_space = vrp->num_bufs * vrp->buf_size;
>
> --
> 2.25.1
>

Re: [PATCH 1/1] rpmsg: virtio: Make buffer size and number configurable

[Tanmay Shah]

On 10/3/23 10:28 AM, Divin Raj wrote:
> Hello,
>
> Thanks for all review comments.
> It makes sense to incorporate a variable-length buffer size. However, we 
> still require an implementation that can successfully achieve this objective.
>
> We will be investigating this matter and will return with a feasible solution.

Thanks.

Here is the previous effort:

Series: "Enhance virtio rpmsg bus driver buffer allocation"

https://lore.kernel.org/all/1548949280-31794-1-git-send-email-xiaoxi...@xiaomi.com/

There was discussion to revive the patch and the activity is still pending. 
This can be good start if we want to achieve it.

Thanks,

Tanmay


>
> Thanks,
>
> On 9/28/23 5:10 PM, Tanmay Shah wrote:
>
> Hello,
>
> Thanks for your patch.
>
> Instead of having this in Kconfig, It's better to have buffer size decided 
> dynamically. Probably by resource-table.
>
> We still need implementation that achieves that goal. Meanwhile  I think it's 
> best to keep buffer size fixed.
>
> Thanks.
>
> On 9/28/23 10:38 AM, Divin Raj wrote:
>
>
>
> CAUTION: This message has originated from an External Source. Please use 
> proper judgment and caution when opening attachments, clicking links, or 
> responding to this email.
>
>
> From: Peter Hoyes <mailto:peter.ho...@arm.com>
>
> Replace the MAX_RPMSG_BUF_SIZE and MAX_RPMSG_NUM_BUFS #define in
> virtio_rpmsg_bus.c with the Kconfig parameters CONFIG_RPMSG_VIRTIO_BUF_SIZE
> and CONFIG_RPMSG_VIRTIO_MAX_NUM_BUFS, allowing user-provided customization.
>
> Making both the number of buffers and size configurable facilitates aligning
> memory requirements between vdev-buffer and vdev-vrings for client drivers
> that require larger buffer sizes, for example.
>
> Signed-off-by: Peter Hoyes <mailto:peter.ho...@arm.com>
> Signed-off-by: Divin Raj <mailto:divin@arm.com>
> ---
>  drivers/rpmsg/Kconfig| 23 +++
>  drivers/rpmsg/virtio_rpmsg_bus.c | 27 +++
>  2 files changed, 26 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig
> index d3795860f5c0..677f4a1ac8bb 100644
> --- a/drivers/rpmsg/Kconfig
> +++ b/drivers/rpmsg/Kconfig
> @@ -81,4 +81,27 @@ config RPMSG_VIRTIO
> select RPMSG_NS
> select VIRTIO
>
> +config RPMSG_VIRTIO_MAX_BUF_SIZE
> +   int "Virtio RPMSG max buffer size (in bytes)"
> +   default 512
> +   depends on RPMSG_VIRTIO
> +   help
> + This option allows you to configure the maximum buffer size (in 
> bytes)
> + for Virtio RPMSG communications. The number of buffers will be 
> computed
> + based on the number of buffers (CONFIG_RPMSG_VIRTIO_MAX_NUM_BUFS)
> + supported by the vring. By default, it supports up to a maximum of 
> 512
> + buffers (256 in each direction). Each buffer consists of 16 bytes 
> for the
> + message header and the remaining bytes for the payload.The default 
> values
> + will utilize a maximum total space of 256KB for the buffers.
> +
> +config RPMSG_VIRTIO_MAX_NUM_BUFS
> +   int "Virtio RPMSG max buffer count (even number for TX and Rx)"
> +   default 512
> +   depends on RPMSG_VIRTIO
> +   help
> + This option allows you to configure the maximum number of buffers 
> used
> + for Virtio RPMSG communication. By default, it supports up to a 
> maximum
> + of 512 buffers (256 in each direction). Please note that this value
> + should be an even number, as it accounts for both transmit (TX) and
> + receive (Rx) buffers.
>  endmenu
> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c 
> b/drivers/rpmsg/virtio_rpmsg_bus.c
> index 905ac7910c98..87a9a4fa30e0 100644
> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> @@ -109,27 +109,6 @@ struct virtio_rpmsg_channel {
>  #define to_virtio_rpmsg_channel(_rpdev) \
> container_of(_rpdev, struct virtio_rpmsg_channel, rpdev)
>
> -/*
> - * We're allocating buffers of 512 bytes each for communications. The
> - * number of buffers will be computed from the number of buffers supported
> - * by the vring, upto a maximum of 512 buffers (256 in each direction).
> - *
> - * Each buffer will have 16 bytes for the msg header and 496 bytes for
> - * the payload.
> - *
> - * This will utilize a maximum total space of 256KB for the buffers.
> - *
> - * We might also want to add support for user-provided buffers in time.
> - * This will allow bigger buffer size flexibility, and can also be used
> - * to achieve zero-copy messaging.
> - *
> - * Note 

[PATCH v6 0/4] add zynqmp TCM bindings

[Tanmay Shah]

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)  | 0x_ | 0xFFE0_  |  |
| R5_0 BTCM (64 KB)  | 0x0002_ | 0xFFE2_  |  |
| R5_1 ATCM (64 KB)  | 0x_ | 0xFFE9_  | alias of 0xFFE1_ |
| R5_1 BTCM (64 KB)  | 0x0002_ | 0xFFEB_  | alias of 0xFFE3_ |
|  ___   | ___ |___   |  |
| *Lockstep Mode*| |  |  |
| R5_0 ATCM (128 KB) | 0x_ | 0xFFE0_  |  |
| R5_0 BTCM (128 KB) | 0x0002_ | 0xFFE2_  |  |

References:
UG1085 TCM address space:
https://docs.xilinx.com/r/en-US/ug1085-zynq-ultrascale-trm/Tightly-Coupled-Memory-Address-Map

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/20230829181900.2561194-1-tanmay.s...@amd.com/

Previous v3 version link:
https://lore.kernel.org/all/1689964908-22371-1-git-send-email-radhey.shyam.pan...@amd.com/
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):
  dts: zynqmp: add properties for TCM in remoteproc
  remoteproc: zynqmp: add pm domains support
  remoteproc: zynqmp: parse TCM from device tree

 .../remoteproc/xlnx,zynqmp-r5fss.yaml | 131 ++-
 .../boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts  |   8 +
 arch/arm64/boot/dts/xilinx/zynqmp.dtsi|  60 ++-
 drivers/remoteproc/xlnx_r5_remoteproc.c   | 368 --
 4 files changed, 517 insertions(+), 50 deletions(-)


base-commit: a7d272979d3a89b117ca2c547dc8a465c4f28635
-- 
2.25.1

[PATCH v6 1/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings

[Tanmay Shah]

From: Radhey Shyam Pandey 

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 
Signed-off-by: Tanmay Shah 
Acked-by: Rob Herring 
---
 .../remoteproc/xlnx,zynqmp-r5fss.yaml | 131 +++---
 1 file changed, 113 insertions(+), 18 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml 
b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
index 78aac69f1060..9ecd63ea1b38 100644
--- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
@@ -20,6 +20,17 @@ 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]
@@ -37,7 +48,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 +65,19 @@ patternProperties:
   compatible:
 const: xlnx,zynqmp-r5f
 
+  reg:
+items:
+  - description: ATCM internal memory region
+  - description: BTCM internal memory region
+
+  reg-names:
+items:
+  - const: atcm
+  - const: btcm
+
   power-domains:
-maxItems: 1
+minItems: 1
+maxItems: 3
 
   mboxes:
 minItems: 1
@@ -102,34 +124,107 @@ patternProperties:
 required:
   - compatible
   - power-domains
+  - reg
+  - reg-names
 
 unevaluatedProperties: false
 
 required:
   - compatible
+  - "#address-cells"
+  - "#size-cells"
+  - ranges
 
 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 
+
+//Split mode configuration
+soc {
+#address-cells = <2>;
+#size-cells = <2>;
+
+remoteproc@ffe0 {
+compatible = "xlnx,zynqmp-r5fss";
+xlnx,cluster-mode = <0>;
+
+#address-cells = <2>;
+#size-cells = <2>;
+ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+ <0x0 0x2 0x0 0xffe2 0x0 0x1>,
+ <0x1 0x0 0x0 0xffe9 0x0 0x1>,
+ <0x1 0x2 0x0 0xffeb 0x0 0x1>;
+
+r5f@0 {
+compatible = "xlnx,zynqmp-r5f";
+reg = <0x0 0x0 0x0 0x1>, <0x0 0x2 0x0 0x1>;
+reg-names = "atcm", "btcm";
+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 0x100

[PATCH v6 3/4] remoteproc: zynqmp: add pm domains support

[Tanmay Shah]

Use TCM pm domains extracted from device-tree
to power on/off TCM using general pm domain framework.

Signed-off-by: Tanmay Shah 
---

Changes in v6:
  - Remove spurious change
  - Handle errors in add_pm_domains function
  - Remove redundant code to handle errors from remove_pm_domains

 drivers/remoteproc/xlnx_r5_remoteproc.c | 262 ++--
 1 file changed, 243 insertions(+), 19 deletions(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 4395edea9a64..04e95d880184 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "remoteproc_internal.h"
 
@@ -102,6 +103,12 @@ static const struct mem_bank_data 
zynqmp_tcm_banks_lockstep[] = {
  * @rproc: rproc handle
  * @pm_domain_id: RPU CPU power domain id
  * @ipi: pointer to mailbox information
+ * @num_pm_dev: number of tcm pm domain devices for this core
+ * @pm_dev1: pm domain virtual devices for power domain framework
+ * @pm_dev_link1: pm domain device links after registration
+ * @pm_dev2: used only in lockstep mode. second core's pm domain virtual 
devices
+ * @pm_dev_link2: used only in lockstep mode. second core's pm device links 
after
+ * registration
  */
 struct zynqmp_r5_core {
struct device *dev;
@@ -111,6 +118,11 @@ struct zynqmp_r5_core {
struct rproc *rproc;
u32 pm_domain_id;
struct mbox_info *ipi;
+   int num_pm_dev;
+   struct device **pm_dev1;
+   struct device_link **pm_dev_link1;
+   struct device **pm_dev2;
+   struct device_link **pm_dev_link2;
 };
 
 /**
@@ -575,12 +587,21 @@ static int add_tcm_carveout_split_mode(struct rproc 
*rproc)
bank_size = r5_core->tcm_banks[i]->size;
pm_domain_id = r5_core->tcm_banks[i]->pm_domain_id;
 
-   ret = zynqmp_pm_request_node(pm_domain_id,
-ZYNQMP_PM_CAPABILITY_ACCESS, 0,
-ZYNQMP_PM_REQUEST_ACK_BLOCKING);
-   if (ret < 0) {
-   dev_err(dev, "failed to turn on TCM 0x%x", 
pm_domain_id);
-   goto release_tcm_split;
+   /*
+* If TCM information is available in device-tree then
+* in that case, pm domain framework will power on/off TCM.
+* In that case pm_domain_id is set to 0. If hardcode
+* bindings from driver is used, then only this driver will
+* use pm_domain_id.
+*/
+   if (pm_domain_id) {
+   ret = zynqmp_pm_request_node(pm_domain_id,
+
ZYNQMP_PM_CAPABILITY_ACCESS, 0,
+
ZYNQMP_PM_REQUEST_ACK_BLOCKING);
+   if (ret < 0) {
+   dev_err(dev, "failed to turn on TCM 0x%x", 
pm_domain_id);
+   goto release_tcm_split;
+   }
}
 
dev_dbg(dev, "TCM carveout split mode %s addr=%llx, da=0x%x, 
size=0x%lx",
@@ -646,13 +667,16 @@ static int add_tcm_carveout_lockstep_mode(struct rproc 
*rproc)
for (i = 0; i < num_banks; i++) {
pm_domain_id = r5_core->tcm_banks[i]->pm_domain_id;
 
-   /* Turn on each TCM bank individually */
-   ret = zynqmp_pm_request_node(pm_domain_id,
-ZYNQMP_PM_CAPABILITY_ACCESS, 0,
-ZYNQMP_PM_REQUEST_ACK_BLOCKING);
-   if (ret < 0) {
-   dev_err(dev, "failed to turn on TCM 0x%x", 
pm_domain_id);
-   goto release_tcm_lockstep;
+   if (pm_domain_id) {
+   /* Turn on each TCM bank individually */
+   ret = zynqmp_pm_request_node(pm_domain_id,
+
ZYNQMP_PM_CAPABILITY_ACCESS, 0,
+
ZYNQMP_PM_REQUEST_ACK_BLOCKING);
+   if (ret < 0) {
+   dev_err(dev, "failed to turn on TCM 0x%x",
+   pm_domain_id);
+   goto release_tcm_lockstep;
+   }
}
 
bank_size = r5_core->tcm_banks[i]->size;
@@ -687,7 +711,8 @@ static int add_tcm_carveout_lockstep_mode(struct rproc 
*rproc)
/* If failed, Turn off all TCM banks turned on before */
for (i--; i >= 0; i--) {
pm_domain_id = r5_core->tcm_banks[i]->pm_domain_id;
-   zynqmp_pm_release_node(pm_domain_id);
+   if (

[PATCH v6 2/4] dts: zynqmp: add properties for TCM in remoteproc

[Tanmay Shah]

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 
---

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

 .../boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts  |  8 +++
 arch/arm64/boot/dts/xilinx/zynqmp.dtsi| 60 +--
 2 files changed, 63 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 b61fc99cd911..602e6aba7ac5 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -247,19 +247,69 @@ fpga_full: fpga-full {
ranges;
};
 
-   remoteproc {
+   rproc_lockstep: remoteproc@ffe0 {
compatible = "xlnx,zynqmp-r5fss";
xlnx,cluster-mode = <1>;
 
-   r5f-0 {
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   ranges = <0x0 0x0 0x0 0xffe0 0x0 0x2>,
+<0x0 0x2 0x0 0xffe2 0x0 0x2>,
+<0x1 0x0 0x0 0xffe9 0x0 0x1>,
+<0x1 0x2 0x0 0xffeb 0x0 0x1>;
+
+   r5f@0 {
+   compatible = "xlnx,zynqmp-r5f";
+   reg = <0x0 0x0 0x0 0x2>, <0x0 0x2 0x0 0x2>;
+   reg-names = "atcm", "btcm";
+   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 {
+   compatible = "xlnx,zynqmp-r5f";
+   reg = <0x1 0x0 0x0 0x1>, <0x1 0x2 0x0 0x1>;
+   reg-names = "atcm", "btcm";
+   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@ffe0 {
+   status = "disabled";
+   compatible = "xlnx,zynqmp-r5fss";
+   xlnx,cluster-mode = <0>;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x1 0x0 0x0 0xffe9 0x0 0x1>,
+<0x1 0x2 0x0 0xffeb 0x0 0x1>;
+
+   r5f@0 {
compatible = "xlnx,zynqmp-r5f";
-   power-domains = <&zynqmp_firmware PD_RPU_0>;
+   reg = <0x0 0x0 0x0 0x1>, <0x0 0x2 0x0 0x1>;
+   reg-names = "atcm", "btcm";
+   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 {

[PATCH v6 4/4] remoteproc: zynqmp: parse TCM from device tree

[Tanmay Shah]

ZynqMP TCM information is fixed in driver. Now ZynqMP TCM information
is available in device-tree. Parse TCM information in driver
as per new bindings.

Signed-off-by: Tanmay Shah 
---

Changes in v6:
  - 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

 drivers/remoteproc/xlnx_r5_remoteproc.c | 106 ++--
 1 file changed, 98 insertions(+), 8 deletions(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 04e95d880184..8c3575970c1d 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -75,8 +75,8 @@ struct mbox_info {
 };
 
 /*
- * Hardcoded TCM bank values. This will be removed once TCM bindings are
- * accepted for system-dt specifications and upstreamed in linux kernel
+ * Hardcoded TCM bank values. This will stay in driver to maintain backward
+ * compatibility with device-tree that does not have TCM information.
  */
 static const struct mem_bank_data zynqmp_tcm_banks_split[] = {
{0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each 
*/
@@ -613,7 +613,8 @@ static int add_tcm_carveout_split_mode(struct rproc *rproc)
 bank_name);
if (!rproc_mem) {
ret = -ENOMEM;
-   zynqmp_pm_release_node(pm_domain_id);
+   if (pm_domain_id)
+   zynqmp_pm_release_node(pm_domain_id);
goto release_tcm_split;
}
 
@@ -626,7 +627,8 @@ static int add_tcm_carveout_split_mode(struct rproc *rproc)
/* If failed, Turn off all TCM banks turned on before */
for (i--; i >= 0; i--) {
pm_domain_id = r5_core->tcm_banks[i]->pm_domain_id;
-   zynqmp_pm_release_node(pm_domain_id);
+   if (pm_domain_id)
+   zynqmp_pm_release_node(pm_domain_id);
}
return ret;
 }
@@ -940,6 +942,8 @@ static int zynqmp_r5_add_pm_domains(struct rproc *rproc)
}
}
 
+   return 0;
+
 fail_add_pm_domains_lockstep:
while (j >= 1) {
if (r5_core->pm_dev_link2 && 
!IS_ERR_OR_NULL(r5_core->pm_dev_link2[j]))
@@ -1102,6 +1106,83 @@ static struct zynqmp_r5_core 
*zynqmp_r5_add_rproc_core(struct device *cdev)
return ERR_PTR(ret);
 }
 
+static int zynqmp_r5_get_tcm_node_from_dt(struct zynqmp_r5_cluster *cluster)
+{
+   struct zynqmp_r5_core *r5_core;
+   int i, j, tcm_bank_count, ret;
+   struct platform_device *cpdev;
+   struct mem_bank_data *tcm;
+   struct device_node *np;
+   struct resource *res;
+   u64 abs_addr, size;
+   struct device *dev;
+
+   for (i = 0; i < cluster->core_count; i++) {
+   r5_core = cluster->r5_cores[i];
+   dev = r5_core->dev;
+   np = dev_of_node(dev);
+
+   /* we have address cell 2 and size cell as 2 */
+   ret = of_property_count_elems_of_size(np, "reg",
+ 4 * sizeof(u32));
+   if (ret <= 0) {
+   dev_err(dev, "can't get reg property err %d\n", ret);
+   return -EINVAL;
+   }
+
+   tcm_bank_count = ret;
+
+   r5_core->tcm_banks = devm_kcalloc(dev, tcm_bank_count,
+ sizeof(struct mem_bank_data 
*),
+ GFP_KERNEL);
+   if (!r5_core->tcm_banks)
+   ret = -ENOMEM;
+
+   r5_core->tcm_bank_count = tcm_bank_count;
+   for (j = 0; j < tcm_bank_count; j++) {
+   tcm = devm_kzalloc(dev, sizeof(struct mem_bank_data *),
+  GFP_KERNEL);
+   if (!tcm)
+   return -ENOMEM;
+
+   r5_core->tcm_banks[j] = tcm;
+
+   /* get tcm address without translation */
+   ret = of_property_read_reg(np, j, &abs_addr, &size);
+   if (ret) {
+   dev_err(dev, "failed to get reg property\n");
+   return ret;
+   }
+
+   /*
+* remote processor can address only 32 bits
+* so convert 64-bits into 32-bits. This will discard
+* any unwanted upper 32-bits.
+*/
+   tcm->d

[RESEND PATCH v3 0/2] remoteproc: get rproc devices for clusters

[Tanmay Shah]

This series extends original patch and makes rproc_put() work
for clusters along with rprog_get_by_phandle().

Changes in v3:
  - remove module_put call that was introduced in the patch by mistake
  - remove redundant check in rproc_put
  - Add inline comments in rproc_put that explains functionality

Changes in v2:
  - Introduce patch to fix rproc_put as per modified rproc_get_by_phandle

v1 is here: 
https://lore.kernel.org/all/20221214221643.1286585-1-mathieu.poir...@linaro.org/

Mathieu Poirier (1):
  remoteproc: Make rproc_get_by_phandle() work for clusters

Tanmay Shah (1):
  remoteproc: enhance rproc_put() for clusters

 drivers/remoteproc/remoteproc_core.c | 45 ++--
 1 file changed, 43 insertions(+), 2 deletions(-)


base-commit: a7d272979d3a89b117ca2c547dc8a465c4f28635
-- 
2.25.1

[RESEND PATCH v3 1/2] remoteproc: Make rproc_get_by_phandle() work for clusters

[Tanmay Shah]

From: Mathieu Poirier 

Multi-cluster remoteproc designs typically have the following DT
declaration:

remoteproc_cluster {
compatible = "soc,remoteproc-cluster";

core0: core0 {
compatible = "soc,remoteproc-core"
memory-region;
sram;
};

core1: core1 {
compatible = "soc,remoteproc-core"
memory-region;
sram;
}
};

A driver exists for the cluster rather than the individual cores
themselves so that operation mode and HW specific configurations
applicable to the cluster can be made.

Because the driver exists at the cluster level and not the individual
core level, function rproc_get_by_phandle() fails to return the
remoteproc associated with the phandled it is called for.

This patch enhances rproc_get_by_phandle() by looking for the cluster's
driver when the driver for the immediate remoteproc's parent is not
found.

Reported-by: Ben Levinsky 
Signed-off-by: Mathieu Poirier 
Tested-by: Ben Levinsky 
---
 drivers/remoteproc/remoteproc_core.c | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/remoteproc_core.c 
b/drivers/remoteproc/remoteproc_core.c
index 695cce218e8c..3a8191803885 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2111,7 +2112,9 @@ EXPORT_SYMBOL(rproc_detach);
 #ifdef CONFIG_OF
 struct rproc *rproc_get_by_phandle(phandle phandle)
 {
+   struct platform_device *cluster_pdev;
struct rproc *rproc = NULL, *r;
+   struct device_driver *driver;
struct device_node *np;
 
np = of_find_node_by_phandle(phandle);
@@ -2122,7 +2125,30 @@ struct rproc *rproc_get_by_phandle(phandle phandle)
list_for_each_entry_rcu(r, &rproc_list, node) {
if (r->dev.parent && device_match_of_node(r->dev.parent, np)) {
/* prevent underlying implementation from being removed 
*/
-   if (!try_module_get(r->dev.parent->driver->owner)) {
+
+   /*
+* If the remoteproc's parent has a driver, the
+* remoteproc is not part of a cluster and we can use
+* that driver.
+*/
+   driver = r->dev.parent->driver;
+
+   /*
+* If the remoteproc's parent does not have a driver,
+* look for the driver associated with the cluster.
+*/
+   if (!driver) {
+   cluster_pdev = 
of_find_device_by_node(np->parent);
+   if (!cluster_pdev) {
+   dev_err(&r->dev, "can't get parent\n");
+   break;
+   }
+
+   driver = cluster_pdev->dev.driver;
+   put_device(&cluster_pdev->dev);
+   }
+
+   if (!try_module_get(driver->owner)) {
dev_err(&r->dev, "can't get owner\n");
break;
}
-- 
2.25.1

[RESEND PATCH v3 2/2] remoteproc: enhance rproc_put() for clusters

[Tanmay Shah]

This patch enhances rproc_put() to support remoteproc clusters
with multiple child nodes as in rproc_get_by_phandle().

Reported-by: kernel test robot 
Link: https://lore.kernel.org/oe-kbuild-all/202303221441.cubnpvye-...@intel.com/
Signed-off-by: Tarak Reddy 
Signed-off-by: Tanmay Shah 
---
 drivers/remoteproc/remoteproc_core.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/remoteproc_core.c 
b/drivers/remoteproc/remoteproc_core.c
index 3a8191803885..3d95543971b5 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -2559,7 +2559,22 @@ EXPORT_SYMBOL(rproc_free);
  */
 void rproc_put(struct rproc *rproc)
 {
-   module_put(rproc->dev.parent->driver->owner);
+   struct platform_device *cluster_pdev;
+
+   if (rproc->dev.parent->driver) {
+   module_put(rproc->dev.parent->driver->owner);
+   } else {
+   /*
+* If the remoteproc's parent does not have a driver,
+* driver is associated with the cluster.
+*/
+   cluster_pdev = 
of_find_device_by_node(rproc->dev.parent->of_node->parent);
+   if (cluster_pdev) {
+   module_put(cluster_pdev->dev.driver->owner);
+   put_device(&cluster_pdev->dev);
+   }
+   }
+
put_device(&rproc->dev);
 }
 EXPORT_SYMBOL(rproc_put);
-- 
2.25.1