[PATCH v7 00/11] Add R5F and C7xv device nodes

[PATCH v7 00/11] Add R5F and C7xv device nodes

[Judith Mendez]

For am62x and am62ax devices, this patch series adds device nodes
for the R5F subsystem and C7xv DSP subsystem found in their
respective voltage domain, based on the device TRMs [0][1].

This patch series also includes patches for enabling IPC for am62x SK,
am62ax SK, and am62px SK by reserving memory and binding the mailbox
assignments for each remote core.

Also reserve timers used by C7x DSP for am62ax SK board and timers used
by MCU FW for AM642 SK and EVM boards as per firmware requirements.

Changes since v6:
- Fix comments in patch 11/11 (no functional change)
- Pick up review tags

Links
v6: https://lore.kernel.org/linux-devicetree/20250405001518.1315273-1-jm@ti.com/
v5: https://lore.kernel.org/linux-devicetree/20250210221530.1234009-1-jm@ti.com/
v4: https://lore.kernel.org/linux-devicetree/20250206235200.3128163-1-jm@ti.com/
v3: https://lore.kernel.org/linux-devicetree/20250204011641.1523561-1-jm@ti.com/
v2: https://lore.kernel.org/linux-devicetree/20250131214611.3288742-1-jm@ti.com/
v1: https://lore.kernel.org/linux-devicetree/20250127221631.3974583-1-jm@ti.com/

[0] https://www.ti.com/lit/pdf/spruj16
[1] https://www.ti.com/lit/pdf/spruiv7
[2] https://lore.kernel.org/linux-devicetree/04e77daf-e775-44fa-82bf-8b6ebf73bcef@ti.com/
[3] https://lore.kernel.org/linux-devicetree/4740c3f8-5051-4e25-af91-b45735ffef31@ti.com/

Devarsh Thakkar (3):
  arm64: dts: ti: k3-am62a-wakeup: Add R5F device node
  arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors
  arm64: dts: ti: k3-am62p5-sk: Enable IPC with remote processors

Hari Nagalla (6):
  arm64: dts: ti: k3-am62-wakeup: Add wakeup R5F node
  arm64: dts: ti: k3-am62a-mcu: Add R5F remote proc node
  arm64: dts: ti: k3-am62x-sk-common: Enable IPC with remote processors
  arm64: dts: ti: k3-am62a7-sk: Reserve main_timer2 for C7x DSP
  arm64: dts: ti: k3-am62a7-sk: Reserve main_rti4 for C7x DSP
  arm64: dts: ti: k3-am64: Reserve timers used by MCU FW

Jai Luthra (1):
  arm64: dts: ti: k3-am62a-main: Add C7xv device node

Judith Mendez (1):
  arm64: dts: ti: k3-am62: Add ATCM and BTCM cbass ranges

 arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi    |  25 +++++
 arch/arm64/boot/dts/ti/k3-am62.dtsi           |   8 +-
 arch/arm64/boot/dts/ti/k3-am62a-main.dtsi     |  12 ++
 arch/arm64/boot/dts/ti/k3-am62a-mcu.dtsi      |  25 +++++
 arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi   |  25 +++++
 arch/arm64/boot/dts/ti/k3-am62a7-sk.dts       | 106 +++++++++++++++++-
 arch/arm64/boot/dts/ti/k3-am62p5-sk.dts       |  50 ++++++++-
 .../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi |  34 +++++-
 arch/arm64/boot/dts/ti/k3-am642-evm.dts       |  20 ++++
 arch/arm64/boot/dts/ti/k3-am642-sk.dts        |  20 ++++
 10 files changed, 306 insertions(+), 19 deletions(-)


base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8
-- 
2.49.0

[PATCH v7 01/11] arm64: dts: ti: k3-am62: Add ATCM and BTCM cbass ranges

[Judith Mendez]

Add cbass ranges for ATCM and BTCM on am62x device, without
these, remoteproc driver fails to probe and attach to the DM
r5 core and IPC communication is broken.

Signed-off-by: Judith Mendez <jm@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am62.dtsi | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am62.dtsi b/arch/arm64/boot/dts/ti/k3-am62.dtsi
index bfb55ca113239..59f6dff552ed4 100644
--- a/arch/arm64/boot/dts/ti/k3-am62.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62.dtsi
@@ -86,7 +86,9 @@ cbass_main: bus@f0000 {
 			 /* Wakeup Domain Range */
 			 <0x00 0x00b00000 0x00 0x00b00000 0x00 0x00002400>, /* VTM */
 			 <0x00 0x2b000000 0x00 0x2b000000 0x00 0x00300400>,
-			 <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>;
+			 <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>,
+			 <0x00 0x78000000 0x00 0x78000000 0x00 0x00008000>, /* DM R5 ATCM*/
+			 <0x00 0x78100000 0x00 0x78100000 0x00 0x00008000>; /* DM R5 BTCM*/
 
 		cbass_mcu: bus@4000000 {
 			bootph-all;
@@ -103,7 +105,9 @@ cbass_wakeup: bus@b00000 {
 			#size-cells = <2>;
 			ranges = <0x00 0x00b00000 0x00 0x00b00000 0x00 0x00002400>, /* VTM */
 				 <0x00 0x2b000000 0x00 0x2b000000 0x00 0x00300400>, /* Peripheral Window */
-				 <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>;
+				 <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>,
+				 <0x00 0x78000000 0x00 0x78000000 0x00 0x00008000>, /* DM R5 ATCM*/
+				 <0x00 0x78100000 0x00 0x78100000 0x00 0x00008000>; /* DM R5 BTCM*/
 		};
 	};
 
-- 
2.49.0

[PATCH v7 02/11] arm64: dts: ti: k3-am62-wakeup: Add wakeup R5F node

[Judith Mendez]

From: Hari Nagalla <hnagalla@ti.com>

AM62 SoC devices have a single core R5F processor in wakeup domain.
The R5F processor in wakeup domain is used as a device manager
for the SoC.

Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi | 25 ++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi
index 9b8a1f85aa15c..6549b7efa6561 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi
@@ -106,6 +106,31 @@ wkup_rti0: watchdog@2b000000 {
 		status = "reserved";
 	};
 
+	wkup_r5fss0: r5fss@78000000 {
+		compatible = "ti,am62-r5fss";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x78000000 0x00 0x78000000 0x8000>,
+			 <0x78100000 0x00 0x78100000 0x8000>;
+		power-domains = <&k3_pds 119 TI_SCI_PD_EXCLUSIVE>;
+		status = "disabled";
+
+		wkup_r5fss0_core0: r5f@78000000 {
+			compatible = "ti,am62-r5f";
+			reg = <0x78000000 0x00008000>,
+			      <0x78100000 0x00008000>;
+			reg-names = "atcm", "btcm";
+			resets = <&k3_reset 121 1>;
+			firmware-name = "am62-wkup-r5f0_0-fw";
+			ti,atcm-enable = <1>;
+			ti,btcm-enable = <1>;
+			ti,loczrama = <1>;
+			ti,sci = <&dmsc>;
+			ti,sci-dev-id = <121>;
+			ti,sci-proc-ids = <0x01 0xff>;
+		};
+	};
+
 	wkup_vtm0: temperature-sensor@b00000 {
 		compatible = "ti,j7200-vtm";
 		reg = <0x00 0xb00000 0x00 0x400>,
-- 
2.49.0

[PATCH v7 03/11] arm64: dts: ti: k3-am62a-mcu: Add R5F remote proc node

[Judith Mendez]

From: Hari Nagalla <hnagalla@ti.com>

AM62A SoCs have a single R5F core in the MCU voltage domain.
Add the R5FSS node with the child node for core0 in MCU voltage
domain .dtsi file.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am62a-mcu.dtsi | 25 ++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am62a-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am62a-mcu.dtsi
index 9ed9d703ff24d..ee961ced7208f 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62a-mcu.dtsi
@@ -174,4 +174,29 @@ mcu_mcan1: can@4e18000 {
 		bosch,mram-cfg = <0x0 128 64 64 64 64 32 32>;
 		status = "disabled";
 	};
+
+	mcu_r5fss0: r5fss@79000000 {
+		compatible = "ti,am62-r5fss";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x79000000 0x00 0x79000000 0x8000>,
+			 <0x79020000 0x00 0x79020000 0x8000>;
+		power-domains = <&k3_pds 7 TI_SCI_PD_EXCLUSIVE>;
+		status = "disabled";
+
+		mcu_r5fss0_core0: r5f@79000000 {
+			compatible = "ti,am62-r5f";
+			reg = <0x79000000 0x00008000>,
+			      <0x79020000 0x00008000>;
+			reg-names = "atcm", "btcm";
+			resets = <&k3_reset 9 1>;
+			firmware-name = "am62a-mcu-r5f0_0-fw";
+			ti,atcm-enable = <0>;
+			ti,btcm-enable = <1>;
+			ti,loczrama = <0>;
+			ti,sci = <&dmsc>;
+			ti,sci-dev-id = <9>;
+			ti,sci-proc-ids = <0x03 0xff>;
+		};
+	};
 };
-- 
2.49.0

[PATCH v7 04/11] arm64: dts: ti: k3-am62a-wakeup: Add R5F device node

[Judith Mendez]

From: Devarsh Thakkar <devarsht@ti.com>

AM62A SoCs have a single R5F core in wakeup domain. This core is
also used as a device manager for the SoC.

Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi | 25 +++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi
index b2c8f53517438..259ae6ebbfb5a 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi
@@ -103,6 +103,31 @@ wkup_rti0: watchdog@2b000000 {
 		status = "reserved";
 	};
 
+	wkup_r5fss0: r5fss@78000000 {
+		compatible = "ti,am62-r5fss";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x78000000 0x00 0x78000000 0x8000>,
+			 <0x78100000 0x00 0x78100000 0x8000>;
+		power-domains = <&k3_pds 119 TI_SCI_PD_EXCLUSIVE>;
+		status = "disabled";
+
+		wkup_r5fss0_core0: r5f@78000000 {
+			compatible = "ti,am62-r5f";
+			reg = <0x78000000 0x00008000>,
+			      <0x78100000 0x00008000>;
+			reg-names = "atcm", "btcm";
+			resets = <&k3_reset 121 1>;
+			firmware-name = "am62a-wkup-r5f0_0-fw";
+			ti,atcm-enable = <1>;
+			ti,btcm-enable = <1>;
+			ti,loczrama = <1>;
+			ti,sci = <&dmsc>;
+			ti,sci-dev-id = <121>;
+			ti,sci-proc-ids = <0x01 0xff>;
+		};
+	};
+
 	wkup_vtm0: temperature-sensor@b00000 {
 		compatible = "ti,j7200-vtm";
 		reg = <0x00 0xb00000 0x00 0x400>,
-- 
2.49.0

[PATCH v7 05/11] arm64: dts: ti: k3-am62a-main: Add C7xv device node

[Judith Mendez]

From: Jai Luthra <j-luthra@ti.com>

AM62A SoCs have a C7xv DSP subsystem with Analytics engine capability.
This subsystem is intended for deep learning purposes. Define the
device node for C7xv DSP.

Signed-off-by: Jai Luthra <j-luthra@ti.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am62a-main.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
index a1daba7b1fad5..d296e9e179738 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
@@ -1123,6 +1123,18 @@ vpu: video-codec@30210000 {
 		power-domains = <&k3_pds 204 TI_SCI_PD_EXCLUSIVE>;
 	};
 
+	c7x_0: dsp@7e000000 {
+		compatible = "ti,am62a-c7xv-dsp";
+		reg = <0x00 0x7e000000 0x00 0x00100000>;
+		reg-names = "l2sram";
+		resets = <&k3_reset 208 1>;
+		firmware-name = "am62a-c71_0-fw";
+		ti,sci = <&dmsc>;
+		ti,sci-dev-id = <208>;
+		ti,sci-proc-ids = <0x04 0xff>;
+		status = "disabled";
+	};
+
 	e5010: jpeg-encoder@fd20000 {
 		compatible = "ti,am62a-jpeg-enc", "img,e5010-jpeg-enc";
 		reg = <0x00 0xfd20000 0x00 0x100>,
-- 
2.49.0

[PATCH v7 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors

[Judith Mendez]

From: Devarsh Thakkar <devarsht@ti.com>

For each remote proc, reserve memory for IPC and bind the mailbox
assignments. Two memory regions are reserved for each remote processor.
The first region of 1MB of memory is used for Vring shared buffers
and the second region is used as external memory to the remote processor
for the resource table and for tracebuffer allocations.

Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Reviewed-by: Beleswar Padhi <b-padhi@ti.com>
Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com>
---
 arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 96 +++++++++++++++++++++++--
 1 file changed, 90 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
index 1c9d95696c839..7d817b447c1d0 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
@@ -52,6 +52,42 @@ linux,cma {
 			linux,cma-default;
 		};
 
+		c7x_0_dma_memory_region: c7x-dma-memory@99800000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x99800000 0x00 0x100000>;
+			no-map;
+		};
+
+		c7x_0_memory_region: c7x-memory@99900000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x99900000 0x00 0xf00000>;
+			no-map;
+		};
+
+		mcu_r5fss0_core0_dma_memory_region: r5f-dma-memory@9b800000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x9b800000 0x00 0x100000>;
+			no-map;
+		};
+
+		mcu_r5fss0_core0_memory_region: r5f-dma-memory@9b900000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x9b900000 0x00 0xf00000>;
+			no-map;
+		};
+
+		wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory@9c800000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x9c800000 0x00 0x100000>;
+			no-map;
+		};
+
+		wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x9c900000 0x00 0xf00000>;
+			no-map;
+		};
+
 		secure_tfa_ddr: tfa@9e780000 {
 			reg = <0x00 0x9e780000 0x00 0x80000>;
 			alignment = <0x1000>;
@@ -63,12 +99,6 @@ secure_ddr: optee@9e800000 {
 			alignment = <0x1000>;
 			no-map;
 		};
-
-		wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
-			compatible = "shared-dma-pool";
-			reg = <0x00 0x9c900000 0x00 0x01e00000>;
-			no-map;
-		};
 	};
 
 	opp-table {
@@ -741,3 +771,57 @@ dpi1_out: endpoint {
 		};
 	};
 };
+
+&mailbox0_cluster0 {
+	status = "okay";
+
+	mbox_r5_0: mbox-r5-0 {
+		ti,mbox-rx = <0 0 0>;
+		ti,mbox-tx = <1 0 0>;
+	};
+};
+
+&mailbox0_cluster1 {
+	status = "okay";
+
+	mbox_c7x_0: mbox-c7x-0 {
+		ti,mbox-rx = <0 0 0>;
+		ti,mbox-tx = <1 0 0>;
+	};
+};
+
+&mailbox0_cluster2 {
+	status = "okay";
+
+	mbox_mcu_r5_0: mbox-mcu-r5-0 {
+		ti,mbox-rx = <0 0 0>;
+		ti,mbox-tx = <1 0 0>;
+	};
+};
+
+&wkup_r5fss0 {
+	status = "okay";
+};
+
+&wkup_r5fss0_core0 {
+	mboxes = <&mailbox0_cluster0>, <&mbox_r5_0>;
+	memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
+			<&wkup_r5fss0_core0_memory_region>;
+};
+
+&mcu_r5fss0 {
+	status = "okay";
+};
+
+&mcu_r5fss0_core0 {
+	mboxes = <&mailbox0_cluster2>, <&mbox_mcu_r5_0>;
+	memory-region = <&mcu_r5fss0_core0_dma_memory_region>,
+			<&mcu_r5fss0_core0_memory_region>;
+};
+
+&c7x_0 {
+	mboxes = <&mailbox0_cluster1>, <&mbox_c7x_0>;
+	memory-region = <&c7x_0_dma_memory_region>,
+			<&c7x_0_memory_region>;
+	status = "okay";
+};
-- 
2.49.0

[PATCH v7 07/11] arm64: dts: ti: k3-am62p5-sk: Enable IPC with remote processors

[Judith Mendez]

From: Devarsh Thakkar <devarsht@ti.com>

For each remote proc, reserve memory for IPC and bind the mailbox
assignments. Two memory regions are reserved for each remote processor.
The first region of 1MB of memory is used for Vring shared buffers
and the second region is used as external memory to the remote processor
for the resource table and for tracebuffer allocations.

Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am62p5-sk.dts | 50 ++++++++++++++++++++++---
 1 file changed, 44 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts b/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts
index d29f524600af0..05760507da4ed 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts
@@ -49,6 +49,30 @@ reserved-memory {
 		#size-cells = <2>;
 		ranges;
 
+		mcu_r5fss0_core0_dma_memory_region: mcu-r5fss-dma-memory-region@9b800000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x9b800000 0x00 0x100000>;
+			no-map;
+		};
+
+		mcu_r5fss0_core0_memory_region: mcu-r5fss-memory-region@9b900000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x9b900000 0x00 0xf00000>;
+			no-map;
+		};
+
+		wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory@9c800000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x9c800000 0x00 0x100000>;
+			no-map;
+		};
+
+		wkup_r5fss0_core0_memory_region: r5f-memory@9c900000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x9c900000 0x00 0xf00000>;
+			no-map;
+		};
+
 		secure_tfa_ddr: tfa@9e780000 {
 			reg = <0x00 0x9e780000 0x00 0x80000>;
 			no-map;
@@ -58,12 +82,6 @@ secure_ddr: optee@9e800000 {
 			reg = <0x00 0x9e800000 0x00 0x01800000>; /* for OP-TEE */
 			no-map;
 		};
-
-		wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
-			compatible = "shared-dma-pool";
-			reg = <0x00 0x9c900000 0x00 0x01e00000>;
-			no-map;
-		};
 	};
 
 	vmain_pd: regulator-0 {
@@ -640,6 +658,26 @@ mbox_mcu_r5_0: mbox-mcu-r5-0 {
 	};
 };
 
+&wkup_r5fss0 {
+	status = "okay";
+};
+
+&wkup_r5fss0_core0 {
+	mboxes = <&mailbox0_cluster0 &mbox_r5_0>;
+	memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
+			<&wkup_r5fss0_core0_memory_region>;
+};
+
+&mcu_r5fss0 {
+	status = "okay";
+};
+
+&mcu_r5fss0_core0 {
+	mboxes = <&mailbox0_cluster1 &mbox_mcu_r5_0>;
+	memory-region = <&mcu_r5fss0_core0_dma_memory_region>,
+			<&mcu_r5fss0_core0_memory_region>;
+};
+
 &main_uart0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&main_uart0_pins_default>;
-- 
2.49.0

[PATCH v7 08/11] arm64: dts: ti: k3-am62x-sk-common: Enable IPC with remote processors

[Judith Mendez]

From: Hari Nagalla <hnagalla@ti.com>

For each remote proc, reserve memory for IPC and bind the mailbox
assignments. Two memory regions are reserved for each remote processor.
The first region of 1MB of memory is used for Vring shared buffers
and the second region is used as external memory to the remote processor
for the resource table and for tracebuffer allocations.

Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
---
 .../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 34 ++++++++++++++++---
 1 file changed, 29 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
index d52cb2a5a589a..364b2ba6af958 100644
--- a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
@@ -70,6 +70,18 @@ mcu_m4fss_memory_region: m4f-memory@9cc00000 {
 			no-map;
 		};
 
+		wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory@9da00000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x9da00000 0x00 0x100000>;
+			no-map;
+		};
+
+		wkup_r5fss0_core0_memory_region: r5f-memory@9db00000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x9db00000 0x00 0xc00000>;
+			no-map;
+		};
+
 		secure_tfa_ddr: tfa@9e780000 {
 			reg = <0x00 0x9e780000 0x00 0x80000>;
 			alignment = <0x1000>;
@@ -82,11 +94,6 @@ secure_ddr: optee@9e800000 {
 			no-map;
 		};
 
-		wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory@9db00000 {
-			compatible = "shared-dma-pool";
-			reg = <0x00 0x9db00000 0x00 0xc00000>;
-			no-map;
-		};
 	};
 
 	leds {
@@ -476,10 +483,17 @@ cpsw3g_phy0: ethernet-phy@0 {
 };
 
 &mailbox0_cluster0 {
+	status = "okay";
+
 	mbox_m4_0: mbox-m4-0 {
 		ti,mbox-rx = <0 0 0>;
 		ti,mbox-tx = <1 0 0>;
 	};
+
+	mbox_r5_0: mbox-r5-0 {
+		ti,mbox-rx = <2 0 0>;
+		ti,mbox-tx = <3 0 0>;
+	};
 };
 
 &mcu_m4fss {
@@ -489,6 +503,16 @@ &mcu_m4fss {
 	status = "okay";
 };
 
+&wkup_r5fss0 {
+	status = "okay";
+};
+
+&wkup_r5fss0_core0 {
+	mboxes = <&mailbox0_cluster0 &mbox_r5_0>;
+	memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
+			<&wkup_r5fss0_core0_memory_region>;
+};
+
 &usbss0 {
 	bootph-all;
 	status = "okay";
-- 
2.49.0

[PATCH v7 09/11] arm64: dts: ti: k3-am62a7-sk: Reserve main_timer2 for C7x DSP

[Judith Mendez]

From: Hari Nagalla <hnagalla@ti.com>

C7x DSP uses main_timer2, so mark it as reserved in linux DT.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
index 7d817b447c1d0..8d7645bb90337 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
@@ -682,6 +682,11 @@ &main_uart1 {
 	status = "reserved";
 };
 
+/* main_timer2 is used by C7x DSP */
+&main_timer2 {
+	status = "reserved";
+};
+
 &usbss0 {
 	status = "okay";
 	ti,vbus-divider;
-- 
2.49.0

[PATCH v7 10/11] arm64: dts: ti: k3-am62a7-sk: Reserve main_rti4 for C7x DSP

[Judith Mendez]

From: Hari Nagalla <hnagalla@ti.com>

The main rti4 watchdog timer is used by the C7x DSP, so reserve the
timer in the linux device tree.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
index 8d7645bb90337..032f1f18d184e 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
@@ -830,3 +830,8 @@ &c7x_0 {
 			<&c7x_0_memory_region>;
 	status = "okay";
 };
+
+/* main_rti4 is used by C7x DSP */
+&main_rti4 {
+	status = "reserved";
+};
-- 
2.49.0

[PATCH v7 11/11] arm64: dts: ti: k3-am64: Reserve timers used by MCU FW

[Judith Mendez]

From: Hari Nagalla <hnagalla@ti.com>

AM64x device has 4 R5F cores in the main domain. TI MCU firmware uses
main domain timers as tick timers in these firmwares. Hence keep them
as reserved in the Linux device tree.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am642-evm.dts | 20 ++++++++++++++++++++
 arch/arm64/boot/dts/ti/k3-am642-sk.dts  | 20 ++++++++++++++++++++
 2 files changed, 40 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index f8ec40523254b..5623ab354a1d5 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
@@ -796,6 +796,26 @@ &mcu_m4fss {
 	status = "okay";
 };
 
+/* main_timer8 is used by r5f0-0 */
+&main_timer8 {
+	status = "reserved";
+};
+
+/* main_timer9 is used by r5f0-1 */
+&main_timer9 {
+	status = "reserved";
+};
+
+/* main_timer10 is used by r5f1-0 */
+&main_timer10 {
+	status = "reserved";
+};
+
+/* main_timer11 is used by r5f1-1 */
+&main_timer11 {
+	status = "reserved";
+};
+
 &serdes_ln_ctrl {
 	idle-states = <AM64_SERDES0_LANE0_PCIE0>;
 };
diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
index 33e421ec18abb..1deaa0be0085c 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
@@ -710,6 +710,26 @@ &mcu_m4fss {
 	status = "okay";
 };
 
+/* main_timer8 is used by r5f0-0 */
+&main_timer8 {
+	status = "reserved";
+};
+
+/* main_timer9 is used by r5f0-1 */
+&main_timer9 {
+	status = "reserved";
+};
+
+/* main_timer10 is used by r5f1-0 */
+&main_timer10 {
+	status = "reserved";
+};
+
+/* main_timer11 is used by r5f1-1 */
+&main_timer11 {
+	status = "reserved";
+};
+
 &ecap0 {
 	status = "okay";
 	/* PWM is available on Pin 1 of header J3 */
-- 
2.49.0

Re: [PATCH v7 01/11] arm64: dts: ti: k3-am62: Add ATCM and BTCM cbass ranges

[Andrew Davis]

On 4/15/25 10:31 AM, Judith Mendez wrote:
> Add cbass ranges for ATCM and BTCM on am62x device, without
> these, remoteproc driver fails to probe and attach to the DM
> r5 core and IPC communication is broken.
> 
> Signed-off-by: Judith Mendez <jm@ti.com>
> ---

Acked-by: Andrew Davis <afd@ti.com>

>   arch/arm64/boot/dts/ti/k3-am62.dtsi | 8 ++++++--
>   1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am62.dtsi b/arch/arm64/boot/dts/ti/k3-am62.dtsi
> index bfb55ca113239..59f6dff552ed4 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62.dtsi
> @@ -86,7 +86,9 @@ cbass_main: bus@f0000 {
>   			 /* Wakeup Domain Range */
>   			 <0x00 0x00b00000 0x00 0x00b00000 0x00 0x00002400>, /* VTM */
>   			 <0x00 0x2b000000 0x00 0x2b000000 0x00 0x00300400>,
> -			 <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>;
> +			 <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>,
> +			 <0x00 0x78000000 0x00 0x78000000 0x00 0x00008000>, /* DM R5 ATCM*/
> +			 <0x00 0x78100000 0x00 0x78100000 0x00 0x00008000>; /* DM R5 BTCM*/
>   
>   		cbass_mcu: bus@4000000 {
>   			bootph-all;
> @@ -103,7 +105,9 @@ cbass_wakeup: bus@b00000 {
>   			#size-cells = <2>;
>   			ranges = <0x00 0x00b00000 0x00 0x00b00000 0x00 0x00002400>, /* VTM */
>   				 <0x00 0x2b000000 0x00 0x2b000000 0x00 0x00300400>, /* Peripheral Window */
> -				 <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>;
> +				 <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>,
> +				 <0x00 0x78000000 0x00 0x78000000 0x00 0x00008000>, /* DM R5 ATCM*/
> +				 <0x00 0x78100000 0x00 0x78100000 0x00 0x00008000>; /* DM R5 BTCM*/
>   		};
>   	};
>   

Re: [PATCH v7 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors

[Bryan Brattlof]

On April 15, 2025 thus sayeth Judith Mendez:
> From: Devarsh Thakkar <devarsht@ti.com>
> 
> For each remote proc, reserve memory for IPC and bind the mailbox
> assignments. Two memory regions are reserved for each remote processor.
> The first region of 1MB of memory is used for Vring shared buffers
> and the second region is used as external memory to the remote processor
> for the resource table and for tracebuffer allocations.
> 
> Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
> Signed-off-by: Judith Mendez <jm@ti.com>
> Acked-by: Andrew Davis <afd@ti.com>
> Reviewed-by: Beleswar Padhi <b-padhi@ti.com>
> Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com>
> ---
>  arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 96 +++++++++++++++++++++++--
>  1 file changed, 90 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> index 1c9d95696c839..7d817b447c1d0 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> @@ -52,6 +52,42 @@ linux,cma {
>  			linux,cma-default;
>  		};
>  
> +		c7x_0_dma_memory_region: c7x-dma-memory@99800000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x00 0x99800000 0x00 0x100000>;
> +			no-map;
> +		};
> +
> +		c7x_0_memory_region: c7x-memory@99900000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x00 0x99900000 0x00 0xf00000>;
> +			no-map;
> +		};
> +

I know this has been a push for our IPC and MCU+ teams for a couple 
windows now, though I do want to point out that some AM62A devices 
(AM62A12AQMSIAMBRQ1) will not even have a C7x. 

It's relatively easy to cut nodes out that describe the hardware in the 
bootloaders, but once we start configuring them to demo something it 
becomes impossible to unwind that during boot.

We can clam we only support the superset devices but I just wanted to 
make this email so I could point people to it when they inevitably ask 
why their parts do not work out of the box with Linux.

Naked-by: Bryan Brattlof <bb@ti.com>

~Bryan

> +		mcu_r5fss0_core0_dma_memory_region: r5f-dma-memory@9b800000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x00 0x9b800000 0x00 0x100000>;
> +			no-map;
> +		};
> +
> +		mcu_r5fss0_core0_memory_region: r5f-dma-memory@9b900000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x00 0x9b900000 0x00 0xf00000>;
> +			no-map;
> +		};
> +
> +		wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory@9c800000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x00 0x9c800000 0x00 0x100000>;
> +			no-map;
> +		};
> +
> +		wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x00 0x9c900000 0x00 0xf00000>;
> +			no-map;
> +		};
> +
>  		secure_tfa_ddr: tfa@9e780000 {
>  			reg = <0x00 0x9e780000 0x00 0x80000>;
>  			alignment = <0x1000>;
> @@ -63,12 +99,6 @@ secure_ddr: optee@9e800000 {
>  			alignment = <0x1000>;
>  			no-map;
>  		};
> -
> -		wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
> -			compatible = "shared-dma-pool";
> -			reg = <0x00 0x9c900000 0x00 0x01e00000>;
> -			no-map;
> -		};
>  	};
>  
>  	opp-table {
> @@ -741,3 +771,57 @@ dpi1_out: endpoint {
>  		};
>  	};
>  };
> +
> +&mailbox0_cluster0 {
> +	status = "okay";
> +
> +	mbox_r5_0: mbox-r5-0 {
> +		ti,mbox-rx = <0 0 0>;
> +		ti,mbox-tx = <1 0 0>;
> +	};
> +};
> +
> +&mailbox0_cluster1 {
> +	status = "okay";
> +
> +	mbox_c7x_0: mbox-c7x-0 {
> +		ti,mbox-rx = <0 0 0>;
> +		ti,mbox-tx = <1 0 0>;
> +	};
> +};
> +
> +&mailbox0_cluster2 {
> +	status = "okay";
> +
> +	mbox_mcu_r5_0: mbox-mcu-r5-0 {
> +		ti,mbox-rx = <0 0 0>;
> +		ti,mbox-tx = <1 0 0>;
> +	};
> +};
> +
> +&wkup_r5fss0 {
> +	status = "okay";
> +};
> +
> +&wkup_r5fss0_core0 {
> +	mboxes = <&mailbox0_cluster0>, <&mbox_r5_0>;
> +	memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
> +			<&wkup_r5fss0_core0_memory_region>;
> +};
> +
> +&mcu_r5fss0 {
> +	status = "okay";
> +};
> +
> +&mcu_r5fss0_core0 {
> +	mboxes = <&mailbox0_cluster2>, <&mbox_mcu_r5_0>;
> +	memory-region = <&mcu_r5fss0_core0_dma_memory_region>,
> +			<&mcu_r5fss0_core0_memory_region>;
> +};
> +
> +&c7x_0 {
> +	mboxes = <&mailbox0_cluster1>, <&mbox_c7x_0>;
> +	memory-region = <&c7x_0_dma_memory_region>,
> +			<&c7x_0_memory_region>;
> +	status = "okay";
> +};
> -- 
> 2.49.0
> 

Re: [PATCH v7 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors

[Nishanth Menon]

On 10:04-20250419, Bryan Brattlof wrote:
> On April 15, 2025 thus sayeth Judith Mendez:
> > From: Devarsh Thakkar <devarsht@ti.com>
> > 
> > For each remote proc, reserve memory for IPC and bind the mailbox
> > assignments. Two memory regions are reserved for each remote processor.
> > The first region of 1MB of memory is used for Vring shared buffers
> > and the second region is used as external memory to the remote processor
> > for the resource table and for tracebuffer allocations.
> > 
> > Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
> > Signed-off-by: Hari Nagalla <hnagalla@ti.com>
> > Signed-off-by: Judith Mendez <jm@ti.com>
> > Acked-by: Andrew Davis <afd@ti.com>
> > Reviewed-by: Beleswar Padhi <b-padhi@ti.com>
> > Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com>
> > ---
> >  arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 96 +++++++++++++++++++++++--
> >  1 file changed, 90 insertions(+), 6 deletions(-)
> > 
> > diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> > index 1c9d95696c839..7d817b447c1d0 100644
> > --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> > +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> > @@ -52,6 +52,42 @@ linux,cma {
> >  			linux,cma-default;
> >  		};
> >  
> > +		c7x_0_dma_memory_region: c7x-dma-memory@99800000 {
> > +			compatible = "shared-dma-pool";
> > +			reg = <0x00 0x99800000 0x00 0x100000>;
> > +			no-map;
> > +		};
> > +
> > +		c7x_0_memory_region: c7x-memory@99900000 {
> > +			compatible = "shared-dma-pool";
> > +			reg = <0x00 0x99900000 0x00 0xf00000>;
> > +			no-map;
> > +		};
> > +
> 
> I know this has been a push for our IPC and MCU+ teams for a couple 
> windows now, though I do want to point out that some AM62A devices 
> (AM62A12AQMSIAMBRQ1) will not even have a C7x. 
> 
> It's relatively easy to cut nodes out that describe the hardware in the 
> bootloaders, but once we start configuring them to demo something it 
> becomes impossible to unwind that during boot.
> 
> We can clam we only support the superset devices but I just wanted to 
> make this email so I could point people to it when they inevitably ask 
> why their parts do not work out of the box with Linux.
> 
> Naked-by: Bryan Brattlof <bb@ti.com>


I am confused. I do not see support for AM62A1 in upstream. We have
AM62A7-SK in upstream. I am not sure what direction you are suggesting
here.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D

Re: [PATCH v7 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors

[Bryan Brattlof]

On April 21, 2025 thus sayeth Nishanth Menon:
> On 10:04-20250419, Bryan Brattlof wrote:
> > On April 15, 2025 thus sayeth Judith Mendez:
> > > From: Devarsh Thakkar <devarsht@ti.com>
> > > 
> > > For each remote proc, reserve memory for IPC and bind the mailbox
> > > assignments. Two memory regions are reserved for each remote processor.
> > > The first region of 1MB of memory is used for Vring shared buffers
> > > and the second region is used as external memory to the remote processor
> > > for the resource table and for tracebuffer allocations.
> > > 
> > > Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
> > > Signed-off-by: Hari Nagalla <hnagalla@ti.com>
> > > Signed-off-by: Judith Mendez <jm@ti.com>
> > > Acked-by: Andrew Davis <afd@ti.com>
> > > Reviewed-by: Beleswar Padhi <b-padhi@ti.com>
> > > Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com>
> > > ---
> > >  arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 96 +++++++++++++++++++++++--
> > >  1 file changed, 90 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> > > index 1c9d95696c839..7d817b447c1d0 100644
> > > --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> > > +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> > > @@ -52,6 +52,42 @@ linux,cma {
> > >  			linux,cma-default;
> > >  		};
> > >  
> > > +		c7x_0_dma_memory_region: c7x-dma-memory@99800000 {
> > > +			compatible = "shared-dma-pool";
> > > +			reg = <0x00 0x99800000 0x00 0x100000>;
> > > +			no-map;
> > > +		};
> > > +
> > > +		c7x_0_memory_region: c7x-memory@99900000 {
> > > +			compatible = "shared-dma-pool";
> > > +			reg = <0x00 0x99900000 0x00 0xf00000>;
> > > +			no-map;
> > > +		};
> > > +
> > 
> > I know this has been a push for our IPC and MCU+ teams for a couple 
> > windows now, though I do want to point out that some AM62A devices 
> > (AM62A12AQMSIAMBRQ1) will not even have a C7x. 
> > 
> > It's relatively easy to cut nodes out that describe the hardware in the 
> > bootloaders, but once we start configuring them to demo something it 
> > becomes impossible to unwind that during boot.
> > 
> > We can clam we only support the superset devices but I just wanted to 
> > make this email so I could point people to it when they inevitably ask 
> > why their parts do not work out of the box with Linux.
> > 
> > Naked-by: Bryan Brattlof <bb@ti.com>
> 
> 
> I am confused. I do not see support for AM62A1 in upstream. We have
> AM62A7-SK in upstream. I am not sure what direction you are suggesting
> here.

All I'm trying to point out is for every part we upstream there are >10 
times the number of parts that for one reason or another will not make 
it to these upstream repositories.

Most of these parts will have trivial changes like having lower CPU 
counts, some will not have a GPU, MCU, PRU, or display, or maybe it's 
just a package change and the thermal zones are different, or it's just 
the speeds the IP can confidently run at, or it could be as simple as 
DDR part changes. Each variant will be mostly the superset device with 
one or two nodes disabled or modified in some way.

For a while now, without configuring the remote cores to demo anything, 
it's been relatively seamless to support these variants in the 
bootloaders by disabling or modifying the nodes that do not exist so 
Linux can at least boot to a shell and provides a great foundation for 
others to start their development

If we want to use these boards to demo a advanced usecases we can do 
that but I worry it will come at the cost of supporting all the part 
variants.

My hope was we could define the board as minimally as possible here so 
we can maximize their flexibility with what timers, mailboxes and memory 
carve-outs each remote processor uses.

~Bryan

Re: [PATCH v7 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors

[Judith Mendez]

Hi Bryan,

On 4/21/25 11:26 AM, Bryan Brattlof wrote:
> On April 21, 2025 thus sayeth Nishanth Menon:
>> On 10:04-20250419, Bryan Brattlof wrote:
>>> On April 15, 2025 thus sayeth Judith Mendez:
>>>> From: Devarsh Thakkar <devarsht@ti.com>
>>>>
>>>> For each remote proc, reserve memory for IPC and bind the mailbox
>>>> assignments. Two memory regions are reserved for each remote processor.
>>>> The first region of 1MB of memory is used for Vring shared buffers
>>>> and the second region is used as external memory to the remote processor
>>>> for the resource table and for tracebuffer allocations.
>>>>
>>>> Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
>>>> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
>>>> Signed-off-by: Judith Mendez <jm@ti.com>
>>>> Acked-by: Andrew Davis <afd@ti.com>
>>>> Reviewed-by: Beleswar Padhi <b-padhi@ti.com>
>>>> Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com>
>>>> ---
>>>>   arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 96 +++++++++++++++++++++++--
>>>>   1 file changed, 90 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>> index 1c9d95696c839..7d817b447c1d0 100644
>>>> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>> @@ -52,6 +52,42 @@ linux,cma {
>>>>   			linux,cma-default;
>>>>   		};
>>>>   
>>>> +		c7x_0_dma_memory_region: c7x-dma-memory@99800000 {
>>>> +			compatible = "shared-dma-pool";
>>>> +			reg = <0x00 0x99800000 0x00 0x100000>;
>>>> +			no-map;
>>>> +		};
>>>> +
>>>> +		c7x_0_memory_region: c7x-memory@99900000 {
>>>> +			compatible = "shared-dma-pool";
>>>> +			reg = <0x00 0x99900000 0x00 0xf00000>;
>>>> +			no-map;
>>>> +		};
>>>> +
>>>
>>> I know this has been a push for our IPC and MCU+ teams for a couple
>>> windows now, though I do want to point out that some AM62A devices
>>> (AM62A12AQMSIAMBRQ1) will not even have a C7x.
>>>
>>> It's relatively easy to cut nodes out that describe the hardware in the
>>> bootloaders, but once we start configuring them to demo something it
>>> becomes impossible to unwind that during boot.
>>>
>>> We can clam we only support the superset devices but I just wanted to
>>> make this email so I could point people to it when they inevitably ask
>>> why their parts do not work out of the box with Linux.
>>>
>>> Naked-by: Bryan Brattlof <bb@ti.com>
>>
>>
>> I am confused. I do not see support for AM62A1 in upstream. We have
>> AM62A7-SK in upstream. I am not sure what direction you are suggesting
>> here.
> 
> All I'm trying to point out is for every part we upstream there are >10
> times the number of parts that for one reason or another will not make
> it to these upstream repositories.
> 
> Most of these parts will have trivial changes like having lower CPU
> counts, some will not have a GPU, MCU, PRU, or display, or maybe it's
> just a package change and the thermal zones are different, or it's just
> the speeds the IP can confidently run at, or it could be as simple as
> DDR part changes. Each variant will be mostly the superset device with
> one or two nodes disabled or modified in some way.
> 
> For a while now, without configuring the remote cores to demo anything,
> it's been relatively seamless to support these variants in the
> bootloaders by disabling or modifying the nodes that do not exist so
> Linux can at least boot to a shell and provides a great foundation for
> others to start their development
> 
> If we want to use these boards to demo a advanced usecases we can do
> that but I worry it will come at the cost of supporting all the part
> variants.
> 
> My hope was we could define the board as minimally as possible here so
> we can maximize their flexibility with what timers, mailboxes and memory
> carve-outs each remote processor uses.
> 

Is it not agreed upon to support the superset device upstream? It seems
like what we need is a detailed whitepaper on board bring-up for each
part variant instead of NOT adding support for the superset device
upstream approach.

~ Judith

Re: [PATCH v7 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors

[Andrew Davis]

On 4/21/25 2:05 PM, Judith Mendez wrote:
> Hi Bryan,
> 
> On 4/21/25 11:26 AM, Bryan Brattlof wrote:
>> On April 21, 2025 thus sayeth Nishanth Menon:
>>> On 10:04-20250419, Bryan Brattlof wrote:
>>>> On April 15, 2025 thus sayeth Judith Mendez:
>>>>> From: Devarsh Thakkar <devarsht@ti.com>
>>>>>
>>>>> For each remote proc, reserve memory for IPC and bind the mailbox
>>>>> assignments. Two memory regions are reserved for each remote processor.
>>>>> The first region of 1MB of memory is used for Vring shared buffers
>>>>> and the second region is used as external memory to the remote processor
>>>>> for the resource table and for tracebuffer allocations.
>>>>>
>>>>> Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
>>>>> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
>>>>> Signed-off-by: Judith Mendez <jm@ti.com>
>>>>> Acked-by: Andrew Davis <afd@ti.com>
>>>>> Reviewed-by: Beleswar Padhi <b-padhi@ti.com>
>>>>> Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com>
>>>>> ---
>>>>>   arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 96 +++++++++++++++++++++++--
>>>>>   1 file changed, 90 insertions(+), 6 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>>> index 1c9d95696c839..7d817b447c1d0 100644
>>>>> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>>> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>>> @@ -52,6 +52,42 @@ linux,cma {
>>>>>               linux,cma-default;
>>>>>           };
>>>>> +        c7x_0_dma_memory_region: c7x-dma-memory@99800000 {
>>>>> +            compatible = "shared-dma-pool";
>>>>> +            reg = <0x00 0x99800000 0x00 0x100000>;
>>>>> +            no-map;
>>>>> +        };
>>>>> +
>>>>> +        c7x_0_memory_region: c7x-memory@99900000 {
>>>>> +            compatible = "shared-dma-pool";
>>>>> +            reg = <0x00 0x99900000 0x00 0xf00000>;
>>>>> +            no-map;
>>>>> +        };
>>>>> +
>>>>
>>>> I know this has been a push for our IPC and MCU+ teams for a couple
>>>> windows now, though I do want to point out that some AM62A devices
>>>> (AM62A12AQMSIAMBRQ1) will not even have a C7x.
>>>>
>>>> It's relatively easy to cut nodes out that describe the hardware in the
>>>> bootloaders, but once we start configuring them to demo something it
>>>> becomes impossible to unwind that during boot.
>>>>
>>>> We can clam we only support the superset devices but I just wanted to
>>>> make this email so I could point people to it when they inevitably ask
>>>> why their parts do not work out of the box with Linux.
>>>>
>>>> Naked-by: Bryan Brattlof <bb@ti.com>
>>>
>>>
>>> I am confused. I do not see support for AM62A1 in upstream. We have
>>> AM62A7-SK in upstream. I am not sure what direction you are suggesting
>>> here.
>>
>> All I'm trying to point out is for every part we upstream there are >10
>> times the number of parts that for one reason or another will not make
>> it to these upstream repositories.
>>
>> Most of these parts will have trivial changes like having lower CPU
>> counts, some will not have a GPU, MCU, PRU, or display, or maybe it's
>> just a package change and the thermal zones are different, or it's just
>> the speeds the IP can confidently run at, or it could be as simple as
>> DDR part changes. Each variant will be mostly the superset device with
>> one or two nodes disabled or modified in some way.
>>
>> For a while now, without configuring the remote cores to demo anything,
>> it's been relatively seamless to support these variants in the
>> bootloaders by disabling or modifying the nodes that do not exist so
>> Linux can at least boot to a shell and provides a great foundation for
>> others to start their development
>>
>> If we want to use these boards to demo a advanced usecases we can do
>> that but I worry it will come at the cost of supporting all the part
>> variants.
>>
>> My hope was we could define the board as minimally as possible here so
>> we can maximize their flexibility with what timers, mailboxes and memory
>> carve-outs each remote processor uses.
>>
> 
> Is it not agreed upon to support the superset device upstream? It seems
> like what we need is a detailed whitepaper on board bring-up for each
> part variant instead of NOT adding support for the superset device
> upstream approach.
> 

We would still support the superset device upstream, Bryan is simply
suggesting (correct me if I'm wrong) a different way of supporting
the superset device such that later adding support for the cutdowns
is less painful.

To this I 100% agree, and I've suggested the same before in
cases where we know a subset device is in the works. Sometimes
plans for a cutdown happen after we have added support and that
makes a bit of a mess (see J78424 / J742s2). Even when we know
this is going to happen we still make a mess of DT which we end
up having to clean up later (see AM62p / J722s).

Easy manipulation of the DT in this way was one of the promises
of "System Device Trees". Until we have that, the next best thing
is DT overlays. The solution here then is to factor out the components
we know will be conditional into a device tree overlays. These
overlays will be applied by default to form the superset DT as the
out-of-box supported device, while also allowing easy removal without
having the bootloader perform complex DT surgery. Win-Win

The plan we agreed on for this series (back in v2 IIRC) is to add
these items as part of the base board DT to match what is already
done for all our other devices. *then* we factor it out from all
devices in one go to make that series more coherent.

So if that sounds good, Bryan feel free to un-NAK this and we
we will be sure to make your task of supporting all these subset
devices much easier in the follow up series :)

Andrew

Re: [PATCH v7 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors

[Bryan Brattlof]

On April 21, 2025 thus sayeth Andrew Davis:
> On 4/21/25 2:05 PM, Judith Mendez wrote:
> > Hi Bryan,
> > 
> > On 4/21/25 11:26 AM, Bryan Brattlof wrote:
> > > On April 21, 2025 thus sayeth Nishanth Menon:
> > > > On 10:04-20250419, Bryan Brattlof wrote:
> > > > > On April 15, 2025 thus sayeth Judith Mendez:
> > > > > > From: Devarsh Thakkar <devarsht@ti.com>
> > > > > > 
> > > > > > For each remote proc, reserve memory for IPC and bind the mailbox
> > > > > > assignments. Two memory regions are reserved for each remote processor.
> > > > > > The first region of 1MB of memory is used for Vring shared buffers
> > > > > > and the second region is used as external memory to the remote processor
> > > > > > for the resource table and for tracebuffer allocations.
> > > > > > 
> > > > > > Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
> > > > > > Signed-off-by: Hari Nagalla <hnagalla@ti.com>
> > > > > > Signed-off-by: Judith Mendez <jm@ti.com>
> > > > > > Acked-by: Andrew Davis <afd@ti.com>
> > > > > > Reviewed-by: Beleswar Padhi <b-padhi@ti.com>
> > > > > > Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com>
> > > > > > ---
> > > > > >   arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 96 +++++++++++++++++++++++--
> > > > > >   1 file changed, 90 insertions(+), 6 deletions(-)
> > > > > > 
> > > > > > diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> > > > > > index 1c9d95696c839..7d817b447c1d0 100644
> > > > > > --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> > > > > > +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> > > > > > @@ -52,6 +52,42 @@ linux,cma {
> > > > > >               linux,cma-default;
> > > > > >           };
> > > > > > +        c7x_0_dma_memory_region: c7x-dma-memory@99800000 {
> > > > > > +            compatible = "shared-dma-pool";
> > > > > > +            reg = <0x00 0x99800000 0x00 0x100000>;
> > > > > > +            no-map;
> > > > > > +        };
> > > > > > +
> > > > > > +        c7x_0_memory_region: c7x-memory@99900000 {
> > > > > > +            compatible = "shared-dma-pool";
> > > > > > +            reg = <0x00 0x99900000 0x00 0xf00000>;
> > > > > > +            no-map;
> > > > > > +        };
> > > > > > +
> > > > > 
> > > > > I know this has been a push for our IPC and MCU+ teams for a couple
> > > > > windows now, though I do want to point out that some AM62A devices
> > > > > (AM62A12AQMSIAMBRQ1) will not even have a C7x.
> > > > > 
> > > > > It's relatively easy to cut nodes out that describe the hardware in the
> > > > > bootloaders, but once we start configuring them to demo something it
> > > > > becomes impossible to unwind that during boot.
> > > > > 
> > > > > We can clam we only support the superset devices but I just wanted to
> > > > > make this email so I could point people to it when they inevitably ask
> > > > > why their parts do not work out of the box with Linux.
> > > > > 
> > > > > Naked-by: Bryan Brattlof <bb@ti.com>
> > > > 
> > > > 
> > > > I am confused. I do not see support for AM62A1 in upstream. We have
> > > > AM62A7-SK in upstream. I am not sure what direction you are suggesting
> > > > here.
> > > 
> > > All I'm trying to point out is for every part we upstream there are >10
> > > times the number of parts that for one reason or another will not make
> > > it to these upstream repositories.
> > > 
> > > Most of these parts will have trivial changes like having lower CPU
> > > counts, some will not have a GPU, MCU, PRU, or display, or maybe it's
> > > just a package change and the thermal zones are different, or it's just
> > > the speeds the IP can confidently run at, or it could be as simple as
> > > DDR part changes. Each variant will be mostly the superset device with
> > > one or two nodes disabled or modified in some way.
> > > 
> > > For a while now, without configuring the remote cores to demo anything,
> > > it's been relatively seamless to support these variants in the
> > > bootloaders by disabling or modifying the nodes that do not exist so
> > > Linux can at least boot to a shell and provides a great foundation for
> > > others to start their development
> > > 
> > > If we want to use these boards to demo a advanced usecases we can do
> > > that but I worry it will come at the cost of supporting all the part
> > > variants.
> > > 
> > > My hope was we could define the board as minimally as possible here so
> > > we can maximize their flexibility with what timers, mailboxes and memory
> > > carve-outs each remote processor uses.
> > > 
> > 
> > Is it not agreed upon to support the superset device upstream? It seems
> > like what we need is a detailed whitepaper on board bring-up for each
> > part variant instead of NOT adding support for the superset device
> > upstream approach.
> > 
> 
> We would still support the superset device upstream, Bryan is simply
> suggesting (correct me if I'm wrong) a different way of supporting
> the superset device such that later adding support for the cutdowns
> is less painful.
> 
> To this I 100% agree, and I've suggested the same before in
> cases where we know a subset device is in the works. Sometimes
> plans for a cutdown happen after we have added support and that
> makes a bit of a mess (see J78424 / J742s2). Even when we know
> this is going to happen we still make a mess of DT which we end
> up having to clean up later (see AM62p / J722s).
> 

Exactly. We will typically have the AM62A7 superset plan well in advance 
then as the platform ages we start defining cutdowns that may or may not 
function depending on the behavior of the drivers which creates the 
weird DT layout and even worse some fraction of the subset devices that 
may or may not boot and no indication if it even should.

Separating the core description of the hardware, so Zephyr, U-Boot, 
Coreboot, Barebox and whoever else can use and modify it, from the 
allocation/configuration of the hardware while Linux is running is the 
only way (in my eyes) this can possibly scale.

>
> Easy manipulation of the DT in this way was one of the promises
> of "System Device Trees". Until we have that, the next best thing
> is DT overlays. The solution here then is to factor out the components
> we know will be conditional into a device tree overlays. These
> overlays will be applied by default to form the superset DT as the
> out-of-box supported device, while also allowing easy removal without
> having the bootloader perform complex DT surgery. Win-Win
> 
> The plan we agreed on for this series (back in v2 IIRC) is to add
> these items as part of the base board DT to match what is already
> done for all our other devices. *then* we factor it out from all
> devices in one go to make that series more coherent.
> 
> So if that sounds good, Bryan feel free to un-NAK this and we
> we will be sure to make your task of supporting all these subset
> devices much easier in the follow up series :)

I can get behind that plan but I do still worry about how this scales. 
Many distributions are starting to look at UKIs as the solution to the 
exploding number of DTBs. Adding overlays will just add plutonium to 
this compressed DTB blob best-fit walk.

Un-Naked-by: Bryan Brattlof <bb@ti.com>

~Bryan

Re: [PATCH v7 07/11] arm64: dts: ti: k3-am62p5-sk: Enable IPC with remote processors

[Andrew Davis]

On 4/15/25 10:31 AM, Judith Mendez wrote:
> From: Devarsh Thakkar <devarsht@ti.com>
> 
> For each remote proc, reserve memory for IPC and bind the mailbox
> assignments. Two memory regions are reserved for each remote processor.
> The first region of 1MB of memory is used for Vring shared buffers
> and the second region is used as external memory to the remote processor
> for the resource table and for tracebuffer allocations.
> 
> Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
> Signed-off-by: Judith Mendez <jm@ti.com>
> ---
>   arch/arm64/boot/dts/ti/k3-am62p5-sk.dts | 50 ++++++++++++++++++++++---
>   1 file changed, 44 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts b/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts
> index d29f524600af0..05760507da4ed 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts
> @@ -49,6 +49,30 @@ reserved-memory {
>   		#size-cells = <2>;
>   		ranges;
>   
> +		mcu_r5fss0_core0_dma_memory_region: mcu-r5fss-dma-memory-region@9b800000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x00 0x9b800000 0x00 0x100000>;
> +			no-map;
> +		};
> +
> +		mcu_r5fss0_core0_memory_region: mcu-r5fss-memory-region@9b900000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x00 0x9b900000 0x00 0xf00000>;
> +			no-map;
> +		};
> +
> +		wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory@9c800000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x00 0x9c800000 0x00 0x100000>;
> +			no-map;
> +		};
> +
> +		wkup_r5fss0_core0_memory_region: r5f-memory@9c900000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x00 0x9c900000 0x00 0xf00000>;

Since this size did change we should keep an eye out for any existing firmware
that made use of the top part of this DDR range. I haven't found any yet, but please
do work with the MCU+SDK folks to get this fixed here[0] so no one ever runs into
issues over this someday.

Reviewed-by: Andrew Davis <afd@ti.com>

[0] https://github.com/TexasInstruments/mcupsdk-core-k3/blob/93978d24d1224b43a898e9bc5182569b9abd1545/.project/templates/am62px/common/linker_wkup-r5f.cmd.xdt#L294

> +			no-map;
> +		};
> +
>   		secure_tfa_ddr: tfa@9e780000 {
>   			reg = <0x00 0x9e780000 0x00 0x80000>;
>   			no-map;
> @@ -58,12 +82,6 @@ secure_ddr: optee@9e800000 {
>   			reg = <0x00 0x9e800000 0x00 0x01800000>; /* for OP-TEE */
>   			no-map;
>   		};
> -
> -		wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
> -			compatible = "shared-dma-pool";
> -			reg = <0x00 0x9c900000 0x00 0x01e00000>;
> -			no-map;
> -		};
>   	};
>   
>   	vmain_pd: regulator-0 {
> @@ -640,6 +658,26 @@ mbox_mcu_r5_0: mbox-mcu-r5-0 {
>   	};
>   };
>   
> +&wkup_r5fss0 {
> +	status = "okay";
> +};
> +
> +&wkup_r5fss0_core0 {
> +	mboxes = <&mailbox0_cluster0 &mbox_r5_0>;
> +	memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
> +			<&wkup_r5fss0_core0_memory_region>;
> +};
> +
> +&mcu_r5fss0 {
> +	status = "okay";
> +};
> +
> +&mcu_r5fss0_core0 {
> +	mboxes = <&mailbox0_cluster1 &mbox_mcu_r5_0>;
> +	memory-region = <&mcu_r5fss0_core0_dma_memory_region>,
> +			<&mcu_r5fss0_core0_memory_region>;
> +};
> +
>   &main_uart0 {
>   	pinctrl-names = "default";
>   	pinctrl-0 = <&main_uart0_pins_default>;

Re: [PATCH v7 08/11] arm64: dts: ti: k3-am62x-sk-common: Enable IPC with remote processors

[Andrew Davis]

On 4/15/25 10:31 AM, Judith Mendez wrote:
> From: Hari Nagalla <hnagalla@ti.com>
> 
> For each remote proc, reserve memory for IPC and bind the mailbox
> assignments. Two memory regions are reserved for each remote processor.
> The first region of 1MB of memory is used for Vring shared buffers
> and the second region is used as external memory to the remote processor
> for the resource table and for tracebuffer allocations.
> 
> Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
> Signed-off-by: Judith Mendez <jm@ti.com>
> ---

Acked-by: Andrew Davis <afd@ti.com>

>   .../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 34 ++++++++++++++++---
>   1 file changed, 29 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
> index d52cb2a5a589a..364b2ba6af958 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
> @@ -70,6 +70,18 @@ mcu_m4fss_memory_region: m4f-memory@9cc00000 {
>   			no-map;
>   		};
>   
> +		wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory@9da00000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x00 0x9da00000 0x00 0x100000>;
> +			no-map;
> +		};
> +
> +		wkup_r5fss0_core0_memory_region: r5f-memory@9db00000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x00 0x9db00000 0x00 0xc00000>;
> +			no-map;
> +		};
> +
>   		secure_tfa_ddr: tfa@9e780000 {
>   			reg = <0x00 0x9e780000 0x00 0x80000>;
>   			alignment = <0x1000>;
> @@ -82,11 +94,6 @@ secure_ddr: optee@9e800000 {
>   			no-map;
>   		};
>   
> -		wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory@9db00000 {
> -			compatible = "shared-dma-pool";
> -			reg = <0x00 0x9db00000 0x00 0xc00000>;
> -			no-map;
> -		};
>   	};
>   
>   	leds {
> @@ -476,10 +483,17 @@ cpsw3g_phy0: ethernet-phy@0 {
>   };
>   
>   &mailbox0_cluster0 {
> +	status = "okay";
> +
>   	mbox_m4_0: mbox-m4-0 {
>   		ti,mbox-rx = <0 0 0>;
>   		ti,mbox-tx = <1 0 0>;
>   	};
> +
> +	mbox_r5_0: mbox-r5-0 {
> +		ti,mbox-rx = <2 0 0>;
> +		ti,mbox-tx = <3 0 0>;
> +	};
>   };
>   
>   &mcu_m4fss {
> @@ -489,6 +503,16 @@ &mcu_m4fss {
>   	status = "okay";
>   };
>   
> +&wkup_r5fss0 {
> +	status = "okay";
> +};
> +
> +&wkup_r5fss0_core0 {
> +	mboxes = <&mailbox0_cluster0 &mbox_r5_0>;
> +	memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
> +			<&wkup_r5fss0_core0_memory_region>;
> +};
> +
>   &usbss0 {
>   	bootph-all;
>   	status = "okay";

Re: [PATCH v7 09/11] arm64: dts: ti: k3-am62a7-sk: Reserve main_timer2 for C7x DSP

[Andrew Davis]

On 4/15/25 10:31 AM, Judith Mendez wrote:
> From: Hari Nagalla <hnagalla@ti.com>
> 
> C7x DSP uses main_timer2, so mark it as reserved in linux DT.
> 

The set of peripherals used by this C7x core depends on the firmware
running on the core. Long term we should think on a better way of
communicating this from firmware to Linux. Same goes for the next
two patches.

For now since these timers are always used by all firmware, this
will be safe to do, but for other peripherals we will need that
better solution.

Reviewed-by: Andrew Davis <afd@ti.com>

> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
> Signed-off-by: Judith Mendez <jm@ti.com>
> ---
>   arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> index 7d817b447c1d0..8d7645bb90337 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> @@ -682,6 +682,11 @@ &main_uart1 {
>   	status = "reserved";
>   };
>   
> +/* main_timer2 is used by C7x DSP */
> +&main_timer2 {
> +	status = "reserved";
> +};
> +
>   &usbss0 {
>   	status = "okay";
>   	ti,vbus-divider;

Re: [PATCH v7 10/11] arm64: dts: ti: k3-am62a7-sk: Reserve main_rti4 for C7x DSP

[Andrew Davis]

On 4/15/25 10:31 AM, Judith Mendez wrote:
> From: Hari Nagalla <hnagalla@ti.com>
> 
> The main rti4 watchdog timer is used by the C7x DSP, so reserve the
> timer in the linux device tree.
> 
> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
> Signed-off-by: Judith Mendez <jm@ti.com>
> ---

Reviewed-by: Andrew Davis <afd@ti.com>

>   arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> index 8d7645bb90337..032f1f18d184e 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> @@ -830,3 +830,8 @@ &c7x_0 {
>   			<&c7x_0_memory_region>;
>   	status = "okay";
>   };
> +
> +/* main_rti4 is used by C7x DSP */
> +&main_rti4 {
> +	status = "reserved";
> +};

Re: [PATCH v7 11/11] arm64: dts: ti: k3-am64: Reserve timers used by MCU FW

[Andrew Davis]

On 4/15/25 10:31 AM, Judith Mendez wrote:
> From: Hari Nagalla <hnagalla@ti.com>
> 
> AM64x device has 4 R5F cores in the main domain. TI MCU firmware uses
> main domain timers as tick timers in these firmwares. Hence keep them
> as reserved in the Linux device tree.
> 
> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
> Signed-off-by: Judith Mendez <jm@ti.com>
> ---

Reviewed-by: Andrew Davis <afd@ti.com>

>   arch/arm64/boot/dts/ti/k3-am642-evm.dts | 20 ++++++++++++++++++++
>   arch/arm64/boot/dts/ti/k3-am642-sk.dts  | 20 ++++++++++++++++++++
>   2 files changed, 40 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> index f8ec40523254b..5623ab354a1d5 100644
> --- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> @@ -796,6 +796,26 @@ &mcu_m4fss {
>   	status = "okay";
>   };
>   
> +/* main_timer8 is used by r5f0-0 */
> +&main_timer8 {
> +	status = "reserved";
> +};
> +
> +/* main_timer9 is used by r5f0-1 */
> +&main_timer9 {
> +	status = "reserved";
> +};
> +
> +/* main_timer10 is used by r5f1-0 */
> +&main_timer10 {
> +	status = "reserved";
> +};
> +
> +/* main_timer11 is used by r5f1-1 */
> +&main_timer11 {
> +	status = "reserved";
> +};
> +
>   &serdes_ln_ctrl {
>   	idle-states = <AM64_SERDES0_LANE0_PCIE0>;
>   };
> diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
> index 33e421ec18abb..1deaa0be0085c 100644
> --- a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
> @@ -710,6 +710,26 @@ &mcu_m4fss {
>   	status = "okay";
>   };
>   
> +/* main_timer8 is used by r5f0-0 */
> +&main_timer8 {
> +	status = "reserved";
> +};
> +
> +/* main_timer9 is used by r5f0-1 */
> +&main_timer9 {
> +	status = "reserved";
> +};
> +
> +/* main_timer10 is used by r5f1-0 */
> +&main_timer10 {
> +	status = "reserved";
> +};
> +
> +/* main_timer11 is used by r5f1-1 */
> +&main_timer11 {
> +	status = "reserved";
> +};
> +
>   &ecap0 {
>   	status = "okay";
>   	/* PWM is available on Pin 1 of header J3 */

Re: [PATCH v7 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors

[Nishanth Menon]

On 10:31-20250415, Judith Mendez wrote:
> From: Devarsh Thakkar <devarsht@ti.com>
> 
> For each remote proc, reserve memory for IPC and bind the mailbox
> assignments. Two memory regions are reserved for each remote processor.
> The first region of 1MB of memory is used for Vring shared buffers
> and the second region is used as external memory to the remote processor
> for the resource table and for tracebuffer allocations.
> 
> Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
> Signed-off-by: Judith Mendez <jm@ti.com>
> Acked-by: Andrew Davis <afd@ti.com>
> Reviewed-by: Beleswar Padhi <b-padhi@ti.com>
> Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com>

Could you rebase the series on latest linux-next? it looks like we
picked up a conflict with this series.

---
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D

Re: [PATCH v7 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors

[Judith Mendez]

Hi Nishanth,

On 5/2/25 6:53 AM, Nishanth Menon wrote:
> On 10:31-20250415, Judith Mendez wrote:
>> From: Devarsh Thakkar <devarsht@ti.com>
>>
>> For each remote proc, reserve memory for IPC and bind the mailbox
>> assignments. Two memory regions are reserved for each remote processor.
>> The first region of 1MB of memory is used for Vring shared buffers
>> and the second region is used as external memory to the remote processor
>> for the resource table and for tracebuffer allocations.
>>
>> Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
>> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
>> Signed-off-by: Judith Mendez <jm@ti.com>
>> Acked-by: Andrew Davis <afd@ti.com>
>> Reviewed-by: Beleswar Padhi <b-padhi@ti.com>
>> Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com>
> 
> Could you rebase the series on latest linux-next? it looks like we
> picked up a conflict with this series.

Ok, will rebase and respin, thanks.

~ Judith

> 
> ---
> Regards,
> Nishanth Menon
> Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D