[PATCH 0/4] Add R5F nodes on TI K3 AM64x SoCs

[PATCH 0/4] Add R5F nodes on TI K3 AM64x SoCs

[Suman Anna]

Hi Nishanth,

The TI K3 R5F remoteproc driver support for the R5F instances on AM64x
SoCs will be merged for 5.14-rc1, and this series adds the corresponding
base dt nodes for the R5F remote processors on TI K3 AM64x SoCs. This
series along with the corresponding driver changes allows to boot these
processors successfully on applicable TI K3 AM64x EVM and SK boards. The
series uses previously merged mailbox nodes.

The R5Fs on AM64x slightly differ from earlier K3 SoCs in that they support
a new "Single-CPU" mode. Please see the driver changes cover-letter for
additional feature differences [1].

Patches are on top of the latest v5.13-rc1 tag + the AM64 R5F bindings.
Bjorn has staged a tag from remoteproc tree with just the bindings [2]
that you can use for merging this series for v5.14. The driver support
will come through remoteproc tree. The patches follow the same style to
similar patches added for J7200 SoCs [3]. 

I have validated the IPC functionality using System Firmware v2021.01a
and corresponding IPC example firmwares.

regards
Suman

[1] https://patchwork.kernel.org/project/linux-remoteproc/cover/20210318215842.8196-1-s-anna@ti.com/
[2] https://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc.git/log/?h=20210327143117.1840-2-s-anna@ti.com 
[3] https://patchwork.kernel.org/project/linux-arm-kernel/cover/20210111184554.6748-1-s-anna@ti.com/

Suman Anna (4):
  arm64: dts: ti: k3-am64-main: Add MAIN domain R5F cluster nodes
  arm64: dts: ti: k3-am642-evm/sk: Add mailboxes to R5Fs
  arm64: dts: ti: k3-am642-evm/sk: Add DDR carveout memory nodes for
    R5Fs
  arm64: dts: ti: k3-am642-evm/sk: Reserve some on-chip SRAM for R5Fs

 arch/arm64/boot/dts/ti/k3-am64-main.dtsi |  84 +++++++++++++++++++
 arch/arm64/boot/dts/ti/k3-am642-evm.dts  | 100 +++++++++++++++++++++++
 arch/arm64/boot/dts/ti/k3-am642-sk.dts   | 100 +++++++++++++++++++++++
 3 files changed, 284 insertions(+)

-- 
2.30.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/4] arm64: dts: ti: k3-am64-main: Add MAIN domain R5F cluster nodes

[Suman Anna]

The AM64x SoCs have 2 dual-core Arm Cortex-R5F processor (R5FSS)
subsystems/clusters. Both the R5F clusters are present within the
MAIN domain (MAIN_R5FSS0 & MAIN_R5FSS1). Each of these can be
configured at boot time to be either run in a new "Single-CPU" mode
or in an Asymmetric Multi Processing (AMP) fashion in Split-mode.
The mode is restricted to "Single-CPU" on some devices with the
appropriate eFuse bit set, but the most common devices support both
modes. These subsystems have 64 KB each Tightly-Coupled Memory (TCM)
internal memories for each core split between two banks - ATCM and
BTCM (further interleaved into two banks). The TCMs of both Cores
are combined in Single-CPU mode to provide a larger 128 KB of memory.
The other notable difference is that the TCMs are spaced 1 MB apart
on these SoCs unlike the existing SoCs.

Add the DT nodes for both these MAIN domain R5F cluster/subsystems,
the two R5F cores are added as child nodes to each of the corresponding
R5F cluster node. Both the clusters are configured to run in Split mode
by default, with the ATCMs enabled to allow the R5 cores to execute
code from DDR with boot-strapping code from ATCM. The inter-processor
communication between the main A72 cores and these processors is
achieved through shared memory and Mailboxes.

The following firmware names are used by default for these cores, and
can be overridden in a board dts file if desired:
  MAIN R5FSS0 Core0: am64-main-r5f0_0-fw (both in Single-CPU & Split modes)
  MAIN R5FSS0 Core1: am64-main-r5f0_1-fw (needed only in Split mode)
  MAIN R5FSS1 Core0: am64-main-r5f1_0-fw (both in Single-CPU & Split modes)
  MAIN R5FSS1 Core1: am64-main-r5f1_1-fw (needed only in Split mode)

NOTE:
A R5FSS cluster can be configured in "Single-CPU" mode by using a
value of 2 for the "ti,cluster-mode" property. Value of 1 is not
permitted (fails the dtbs_check).

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 84 ++++++++++++++++++++++++
 1 file changed, 84 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
index b2bcbf23eefd..65e34916c717 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
@@ -672,4 +672,88 @@ mailbox0_cluster7: mailbox@29070000 {
 		ti,mbox-num-users = <4>;
 		ti,mbox-num-fifos = <16>;
 	};
+
+	main_r5fss0: r5fss@78000000 {
+		compatible = "ti,am64-r5fss";
+		ti,cluster-mode = <0>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x78000000 0x00 0x78000000 0x10000>,
+			 <0x78100000 0x00 0x78100000 0x10000>,
+			 <0x78200000 0x00 0x78200000 0x08000>,
+			 <0x78300000 0x00 0x78300000 0x08000>;
+		power-domains = <&k3_pds 119 TI_SCI_PD_EXCLUSIVE>;
+
+		main_r5fss0_core0: r5f@78000000 {
+			compatible = "ti,am64-r5f";
+			reg = <0x78000000 0x00010000>,
+			      <0x78100000 0x00010000>;
+			reg-names = "atcm", "btcm";
+			ti,sci = <&dmsc>;
+			ti,sci-dev-id = <121>;
+			ti,sci-proc-ids = <0x01 0xff>;
+			resets = <&k3_reset 121 1>;
+			firmware-name = "am64-main-r5f0_0-fw";
+			ti,atcm-enable = <1>;
+			ti,btcm-enable = <1>;
+			ti,loczrama = <1>;
+		};
+
+		main_r5fss0_core1: r5f@78200000 {
+			compatible = "ti,am64-r5f";
+			reg = <0x78200000 0x00008000>,
+			      <0x78300000 0x00008000>;
+			reg-names = "atcm", "btcm";
+			ti,sci = <&dmsc>;
+			ti,sci-dev-id = <122>;
+			ti,sci-proc-ids = <0x02 0xff>;
+			resets = <&k3_reset 122 1>;
+			firmware-name = "am64-main-r5f0_1-fw";
+			ti,atcm-enable = <1>;
+			ti,btcm-enable = <1>;
+			ti,loczrama = <1>;
+		};
+	};
+
+	main_r5fss1: r5fss@78400000 {
+		compatible = "ti,am64-r5fss";
+		ti,cluster-mode = <0>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x78400000 0x00 0x78400000 0x10000>,
+			 <0x78500000 0x00 0x78500000 0x10000>,
+			 <0x78600000 0x00 0x78600000 0x08000>,
+			 <0x78700000 0x00 0x78700000 0x08000>;
+		power-domains = <&k3_pds 120 TI_SCI_PD_EXCLUSIVE>;
+
+		main_r5fss1_core0: r5f@78400000 {
+			compatible = "ti,am64-r5f";
+			reg = <0x78400000 0x00010000>,
+			      <0x78500000 0x00010000>;
+			reg-names = "atcm", "btcm";
+			ti,sci = <&dmsc>;
+			ti,sci-dev-id = <123>;
+			ti,sci-proc-ids = <0x06 0xff>;
+			resets = <&k3_reset 123 1>;
+			firmware-name = "am64-main-r5f1_0-fw";
+			ti,atcm-enable = <1>;
+			ti,btcm-enable = <1>;
+			ti,loczrama = <1>;
+		};
+
+		main_r5fss1_core1: r5f@78600000 {
+			compatible = "ti,am64-r5f";
+			reg = <0x78600000 0x00008000>,
+			      <0x78700000 0x00008000>;
+			reg-names = "atcm", "btcm";
+			ti,sci = <&dmsc>;
+			ti,sci-dev-id = <124>;
+			ti,sci-proc-ids = <0x07 0xff>;
+			resets = <&k3_reset 124 1>;
+			firmware-name = "am64-main-r5f1_1-fw";
+			ti,atcm-enable = <1>;
+			ti,btcm-enable = <1>;
+			ti,loczrama = <1>;
+		};
+	};
 };
-- 
2.30.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 2/4] arm64: dts: ti: k3-am642-evm/sk: Add mailboxes to R5Fs

[Suman Anna]

Add the required 'mboxes' property to all the R5F processors for the
TI AM642 EVM and SK boards. The mailboxes and some shared memory are
required for running the Remote Processor Messaging (RPMsg) stack
between the host processor and each of the R5Fs.

The chosen sub-mailboxes match the values used in the current firmware
images. This can be changed, if needed, as per the system integration
needs after making appropriate changes on the firmware side as well.

Note that any R5F Core1 resources are needed and used only when that
R5F cluster is configured for Split-mode.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am642-evm.dts | 16 ++++++++++++++++
 arch/arm64/boot/dts/ti/k3-am642-sk.dts  | 16 ++++++++++++++++
 2 files changed, 32 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index dad0efa961ed..c542a648231f 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
@@ -130,6 +130,22 @@ cpsw3g_phy3: ethernet-phy@3 {
 	};
 };
 
+&main_r5fss0_core0 {
+	mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core0>;
+};
+
+&main_r5fss0_core1 {
+	mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core1>;
+};
+
+&main_r5fss1_core0 {
+	mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core0>;
+};
+
+&main_r5fss1_core1 {
+	mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core1>;
+};
+
 &main_pmx0 {
 	main_mmc1_pins_default: main-mmc1-pins-default {
 		pinctrl-single,pins = <
diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
index 8424cd071955..1540a4c39b86 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
@@ -332,3 +332,19 @@ mbox_m4_0: mbox-m4-0 {
 &mailbox0_cluster7 {
 	status = "disabled";
 };
+
+&main_r5fss0_core0 {
+	mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core0>;
+};
+
+&main_r5fss0_core1 {
+	mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core1>;
+};
+
+&main_r5fss1_core0 {
+	mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core0>;
+};
+
+&main_r5fss1_core1 {
+	mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core1>;
+};
-- 
2.30.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 3/4] arm64: dts: ti: k3-am642-evm/sk: Add DDR carveout memory nodes for R5Fs

[Suman Anna]

Two carveout reserved memory nodes each have been added for each of the
R5F remote processor devices within the MAIN domain on the TI AM642 EVM
and SK boards. These nodes are assigned to the respective rproc device
nodes as well. The first region will be used as the DMA pool for the rproc
devices, and the second region will furnish the static carveout regions
for the firmware memory.

An additional reserved memory node is also added to reserve a portion of
the DDR memory to be used for performing inter-processor communication
between all the remote processors running RTOS or baremetal firmwares.
8 MB of memory is reserved for this purpose, and this accounts for all
the vrings and vring buffers between all the possible pairs of remote
processors.

The current carveout addresses and sizes are defined statically for each
rproc device. The R5F processors do not have an MMU, and as such require
the exact memory used by the firmwares to be set-aside. The firmware
images do not require any RSC_CARVEOUT entries in their resource tables
to allocate the memory for firmware memory segments.

NOTE:
1. The R5F1 carveouts are needed only if the R5F cluster is running in
   Split (non Single-CPU) mode. The reserved memory nodes can be disabled
   later on if there is no use-case defined to use the corresponding
   remote processor.
2. The AM64x SoCs do not have any DSPs and one less R5F cluster compared
   to J721E SoCs. So, while the carveout memories reserved for the R5F
   clusters present on the SoC match to those on J721E, the overall
   memory map reserved for firmwares is quite different. The number of
   R5F clusters on AM64x SoCs are same as on J7200 SoCs, but the AM64x
   SoCs also have an additional M4F core, so the RTOS IPC memory region
   is 1 MB higher than on J7200 SoCs.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am642-evm.dts | 62 +++++++++++++++++++++++++
 arch/arm64/boot/dts/ti/k3-am642-sk.dts  | 62 +++++++++++++++++++++++++
 2 files changed, 124 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index c542a648231f..4d0b3f86525e 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
@@ -36,6 +36,60 @@ secure_ddr: optee@9e800000 {
 			alignment = <0x1000>;
 			no-map;
 		};
+
+		main_r5fss0_core0_dma_memory_region: r5f-dma-memory@a0000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa0000000 0x00 0x100000>;
+			no-map;
+		};
+
+		main_r5fss0_core0_memory_region: r5f-memory@a0100000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa0100000 0x00 0xf00000>;
+			no-map;
+		};
+
+		main_r5fss0_core1_dma_memory_region: r5f-dma-memory@a1000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa1000000 0x00 0x100000>;
+			no-map;
+		};
+
+		main_r5fss0_core1_memory_region: r5f-memory@a1100000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa1100000 0x00 0xf00000>;
+			no-map;
+		};
+
+		main_r5fss1_core0_dma_memory_region: r5f-dma-memory@a2000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa2000000 0x00 0x100000>;
+			no-map;
+		};
+
+		main_r5fss1_core0_memory_region: r5f-memory@a2100000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa2100000 0x00 0xf00000>;
+			no-map;
+		};
+
+		main_r5fss1_core1_dma_memory_region: r5f-dma-memory@a3000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa3000000 0x00 0x100000>;
+			no-map;
+		};
+
+		main_r5fss1_core1_memory_region: r5f-memory@a3100000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa3100000 0x00 0xf00000>;
+			no-map;
+		};
+
+		rtos_ipc_memory_region: ipc-memories@a5000000 {
+			reg = <0x00 0xa5000000 0x00 0x00800000>;
+			alignment = <0x1000>;
+			no-map;
+		};
 	};
 
 	evm_12v0: fixedregulator-evm12v0 {
@@ -132,18 +186,26 @@ cpsw3g_phy3: ethernet-phy@3 {
 
 &main_r5fss0_core0 {
 	mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core0>;
+	memory-region = <&main_r5fss0_core0_dma_memory_region>,
+			<&main_r5fss0_core0_memory_region>;
 };
 
 &main_r5fss0_core1 {
 	mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core1>;
+	memory-region = <&main_r5fss0_core1_dma_memory_region>,
+			<&main_r5fss0_core1_memory_region>;
 };
 
 &main_r5fss1_core0 {
 	mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core0>;
+	memory-region = <&main_r5fss1_core0_dma_memory_region>,
+			<&main_r5fss1_core0_memory_region>;
 };
 
 &main_r5fss1_core1 {
 	mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core1>;
+	memory-region = <&main_r5fss1_core1_dma_memory_region>,
+			<&main_r5fss1_core1_memory_region>;
 };
 
 &main_pmx0 {
diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
index 1540a4c39b86..5891e6a05ddf 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
@@ -35,6 +35,60 @@ secure_ddr: optee@9e800000 {
 			alignment = <0x1000>;
 			no-map;
 		};
+
+		main_r5fss0_core0_dma_memory_region: r5f-dma-memory@a0000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa0000000 0x00 0x100000>;
+			no-map;
+		};
+
+		main_r5fss0_core0_memory_region: r5f-memory@a0100000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa0100000 0x00 0xf00000>;
+			no-map;
+		};
+
+		main_r5fss0_core1_dma_memory_region: r5f-dma-memory@a1000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa1000000 0x00 0x100000>;
+			no-map;
+		};
+
+		main_r5fss0_core1_memory_region: r5f-memory@a1100000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa1100000 0x00 0xf00000>;
+			no-map;
+		};
+
+		main_r5fss1_core0_dma_memory_region: r5f-dma-memory@a2000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa2000000 0x00 0x100000>;
+			no-map;
+		};
+
+		main_r5fss1_core0_memory_region: r5f-memory@a2100000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa2100000 0x00 0xf00000>;
+			no-map;
+		};
+
+		main_r5fss1_core1_dma_memory_region: r5f-dma-memory@a3000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa3000000 0x00 0x100000>;
+			no-map;
+		};
+
+		main_r5fss1_core1_memory_region: r5f-memory@a3100000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa3100000 0x00 0xf00000>;
+			no-map;
+		};
+
+		rtos_ipc_memory_region: ipc-memories@a5000000 {
+			reg = <0x00 0xa5000000 0x00 0x00800000>;
+			alignment = <0x1000>;
+			no-map;
+		};
 	};
 
 	vusb_main: fixed-regulator-vusb-main5v0 {
@@ -335,16 +389,24 @@ &mailbox0_cluster7 {
 
 &main_r5fss0_core0 {
 	mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core0>;
+	memory-region = <&main_r5fss0_core0_dma_memory_region>,
+			<&main_r5fss0_core0_memory_region>;
 };
 
 &main_r5fss0_core1 {
 	mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core1>;
+	memory-region = <&main_r5fss0_core1_dma_memory_region>,
+			<&main_r5fss0_core1_memory_region>;
 };
 
 &main_r5fss1_core0 {
 	mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core0>;
+	memory-region = <&main_r5fss1_core0_dma_memory_region>,
+			<&main_r5fss1_core0_memory_region>;
 };
 
 &main_r5fss1_core1 {
 	mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core1>;
+	memory-region = <&main_r5fss1_core1_dma_memory_region>,
+			<&main_r5fss1_core1_memory_region>;
 };
-- 
2.30.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 4/4] arm64: dts: ti: k3-am642-evm/sk: Reserve some on-chip SRAM for R5Fs

[Suman Anna]

Reserve some portions of the MAIN domain on-chip SRAM for use by various
R5F cores on AM642 EVM and SK boards. A bank (256 KB) each is reserved
from the on-chip SRAM for each R5F core. This is done through specific
child SRAM nodes in the board dts file.

The memory regions are also assigned to each R5F remoteproc node using
the sram property. The reserved SRAM banks are as follows for each core:
  Main R5FSS0 Core0 : OCSRAM1
  Main R5FSS0 Core1 : OCSRAM2
  Main R5FSS1 Core0 : OCSRAM3
  Main R5FSS1 Core1 : OCSRAM4

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Ming Wei <mwei@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am642-evm.dts | 22 ++++++++++++++++++++++
 arch/arm64/boot/dts/ti/k3-am642-sk.dts  | 22 ++++++++++++++++++++++
 2 files changed, 44 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index 4d0b3f86525e..083df636d7ff 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
@@ -184,28 +184,50 @@ cpsw3g_phy3: ethernet-phy@3 {
 	};
 };
 
+&oc_sram {
+	main_r5fss0_core0_sram: r5f-sram@40000 {
+		reg = <0x40000 0x40000>;
+	};
+
+	main_r5fss0_core1_sram: r5f-sram@80000 {
+		reg = <0x80000 0x40000>;
+	};
+
+	main_r5fss1_core0_sram: r5f-sram@c0000 {
+		reg = <0xc0000 0x40000>;
+	};
+
+	main_r5fss1_core1_sram: r5f-sram@100000 {
+		reg = <0x100000 0x40000>;
+	};
+};
+
 &main_r5fss0_core0 {
 	mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core0>;
 	memory-region = <&main_r5fss0_core0_dma_memory_region>,
 			<&main_r5fss0_core0_memory_region>;
+	sram = <&main_r5fss0_core0_sram>;
 };
 
 &main_r5fss0_core1 {
 	mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core1>;
 	memory-region = <&main_r5fss0_core1_dma_memory_region>,
 			<&main_r5fss0_core1_memory_region>;
+	sram = <&main_r5fss0_core1_sram>;
 };
 
 &main_r5fss1_core0 {
 	mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core0>;
 	memory-region = <&main_r5fss1_core0_dma_memory_region>,
 			<&main_r5fss1_core0_memory_region>;
+	sram = <&main_r5fss1_core0_sram>;
 };
 
 &main_r5fss1_core1 {
 	mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core1>;
 	memory-region = <&main_r5fss1_core1_dma_memory_region>,
 			<&main_r5fss1_core1_memory_region>;
+	sram = <&main_r5fss1_core1_sram>;
 };
 
 &main_pmx0 {
diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
index 5891e6a05ddf..b388b3ca210a 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
@@ -387,26 +387,48 @@ &mailbox0_cluster7 {
 	status = "disabled";
 };
 
+&oc_sram {
+	main_r5fss0_core0_sram: r5f-sram@40000 {
+		reg = <0x40000 0x40000>;
+	};
+
+	main_r5fss0_core1_sram: r5f-sram@80000 {
+		reg = <0x80000 0x40000>;
+	};
+
+	main_r5fss1_core0_sram: r5f-sram@c0000 {
+		reg = <0xc0000 0x40000>;
+	};
+
+	main_r5fss1_core1_sram: r5f-sram@100000 {
+		reg = <0x100000 0x40000>;
+	};
+};
+
 &main_r5fss0_core0 {
 	mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core0>;
 	memory-region = <&main_r5fss0_core0_dma_memory_region>,
 			<&main_r5fss0_core0_memory_region>;
+	sram = <&main_r5fss0_core0_sram>;
 };
 
 &main_r5fss0_core1 {
 	mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core1>;
 	memory-region = <&main_r5fss0_core1_dma_memory_region>,
 			<&main_r5fss0_core1_memory_region>;
+	sram = <&main_r5fss0_core1_sram>;
 };
 
 &main_r5fss1_core0 {
 	mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core0>;
 	memory-region = <&main_r5fss1_core0_dma_memory_region>,
 			<&main_r5fss1_core0_memory_region>;
+	sram = <&main_r5fss1_core0_sram>;
 };
 
 &main_r5fss1_core1 {
 	mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core1>;
 	memory-region = <&main_r5fss1_core1_dma_memory_region>,
 			<&main_r5fss1_core1_memory_region>;
+	sram = <&main_r5fss1_core1_sram>;
 };
-- 
2.30.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/4] arm64: dts: ti: k3-am642-evm/sk: Reserve some on-chip SRAM for R5Fs

[Vignesh Raghavendra]

Hi Suman,

On 5/28/21 8:17 PM, Suman Anna wrote:
> +&oc_sram {
> +	main_r5fss0_core0_sram: r5f-sram@40000 {
> +		reg = <0x40000 0x40000>;
> +	};
> +
> +	main_r5fss0_core1_sram: r5f-sram@80000 {
> +		reg = <0x80000 0x40000>;
> +	};
> +
> +	main_r5fss1_core0_sram: r5f-sram@c0000 {
> +		reg = <0xc0000 0x40000>;
> +	};
> +
> +	main_r5fss1_core1_sram: r5f-sram@100000 {
> +		reg = <0x100000 0x40000>;
> +	};
> +};
> +

Now that ATF is being moved to end of SRAM[1], is it possible to move
these allocations closer to that ATF reserved location?

This will provide one large contiguouos memory at the beginning of SRAM
which can be used as generic pool. Right now there are two
dis-contiguous pool (256K@0 and ~384K@140000) which is not very
efficient use of SRAM.


[1]
http://kahuna.dhcp.ti.com:8000/project/arm64-ti-dts/patch/20210607133806.18158-1-a-govindraju@ti.com/

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/4] arm64: dts: ti: k3-am642-evm/sk: Reserve some on-chip SRAM for R5Fs

[Nishanth Menon]

On 09:47-20210528, Suman Anna wrote:
> Reserve some portions of the MAIN domain on-chip SRAM for use by various
> R5F cores on AM642 EVM and SK boards. A bank (256 KB) each is reserved
> from the on-chip SRAM for each R5F core. This is done through specific
> child SRAM nodes in the board dts file.
> 
> The memory regions are also assigned to each R5F remoteproc node using
> the sram property. The reserved SRAM banks are as follows for each core:
>   Main R5FSS0 Core0 : OCSRAM1
>   Main R5FSS0 Core1 : OCSRAM2
>   Main R5FSS1 Core0 : OCSRAM3
>   Main R5FSS1 Core1 : OCSRAM4
> 
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Ming Wei <mwei@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> Link: https://lore.kernel.org/r/20210528144718.25132-5-s-anna@ti.com
> ---
>  arch/arm64/boot/dts/ti/k3-am642-evm.dts | 22 ++++++++++++++++++++++
>  arch/arm64/boot/dts/ti/k3-am642-sk.dts  | 22 ++++++++++++++++++++++
>  2 files changed, 44 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> index 4d0b3f86525e..083df636d7ff 100644
> --- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> @@ -184,28 +184,50 @@ cpsw3g_phy3: ethernet-phy@3 {
>  	};
>  };
>  
> +&oc_sram {
> +	main_r5fss0_core0_sram: r5f-sram@40000 {
> +		reg = <0x40000 0x40000>;
> +	};
> +
> +	main_r5fss0_core1_sram: r5f-sram@80000 {
> +		reg = <0x80000 0x40000>;
> +	};
> +
> +	main_r5fss1_core0_sram: r5f-sram@c0000 {
> +		reg = <0xc0000 0x40000>;
> +	};
> +
> +	main_r5fss1_core1_sram: r5f-sram@100000 {
> +		reg = <0x100000 0x40000>;
> +	};
> +};

We need to relook at these addresses -> please see the series from
Vignesh[1] and Ashwath[2].

0x0 <-> 0x1a0000 is free
0x1a0000 <-> 0x1bc000 -> TF-A
0x1bc000 <-> 0x1c0000 -> Free
0x1c0000 <-> 0x200000 -> Seems to be sysfw?


[1] https://lore.kernel.org/linux-devicetree/20210609140604.9490-1-vigneshr@ti.com/
[2] https://lore.kernel.org/linux-devicetree/162343800075.7434.10921347563461214925.b4-ty@ti.com/

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/4] arm64: dts: ti: k3-am642-evm/sk: Reserve some on-chip SRAM for R5Fs

[Suman Anna]

Hi Vignesh, Nishanth,

On 6/11/21 2:13 PM, Nishanth Menon wrote:
> On 09:47-20210528, Suman Anna wrote:
>> Reserve some portions of the MAIN domain on-chip SRAM for use by various
>> R5F cores on AM642 EVM and SK boards. A bank (256 KB) each is reserved
>> from the on-chip SRAM for each R5F core. This is done through specific
>> child SRAM nodes in the board dts file.
>>
>> The memory regions are also assigned to each R5F remoteproc node using
>> the sram property. The reserved SRAM banks are as follows for each core:
>>   Main R5FSS0 Core0 : OCSRAM1
>>   Main R5FSS0 Core1 : OCSRAM2
>>   Main R5FSS1 Core0 : OCSRAM3
>>   Main R5FSS1 Core1 : OCSRAM4
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> Signed-off-by: Ming Wei <mwei@ti.com>
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>> Link: https://lore.kernel.org/r/20210528144718.25132-5-s-anna@ti.com
>> ---
>>  arch/arm64/boot/dts/ti/k3-am642-evm.dts | 22 ++++++++++++++++++++++
>>  arch/arm64/boot/dts/ti/k3-am642-sk.dts  | 22 ++++++++++++++++++++++
>>  2 files changed, 44 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
>> index 4d0b3f86525e..083df636d7ff 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
>> +++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
>> @@ -184,28 +184,50 @@ cpsw3g_phy3: ethernet-phy@3 {
>>  	};
>>  };
>>  
>> +&oc_sram {
>> +	main_r5fss0_core0_sram: r5f-sram@40000 {
>> +		reg = <0x40000 0x40000>;
>> +	};
>> +
>> +	main_r5fss0_core1_sram: r5f-sram@80000 {
>> +		reg = <0x80000 0x40000>;
>> +	};
>> +
>> +	main_r5fss1_core0_sram: r5f-sram@c0000 {
>> +		reg = <0xc0000 0x40000>;
>> +	};
>> +
>> +	main_r5fss1_core1_sram: r5f-sram@100000 {
>> +		reg = <0x100000 0x40000>;
>> +	};
>> +};
> 

These addresses are currently in sync with the corresponding firmware linker map
files. Any changes needed here should also be aligned and updated with all the
firmwares then.

Nishanth,
How about dropping this patch until we conclude the discussion and picking up
the rest?

> We need to relook at these addresses -> please see the series from
> Vignesh[1] and Ashwath[2].
> 
> 0x0 <-> 0x1a0000 is free
> 0x1a0000 <-> 0x1bc000 -> TF-A
> 0x1bc000 <-> 0x1c0000 -> Free
> 0x1c0000 <-> 0x200000 -> Seems to be sysfw?

Looking at the dicussion on v1, I am confused. Is the default reservation size
for SYSFW 0x40000 (256K) or 0x20000 (128K)? The v2 of the SYSFW SRAM
reservations is still using 256K at 0x1c0000 offset.

> 
> 
> [1] https://lore.kernel.org/linux-devicetree/20210609140604.9490-1-vigneshr@ti.com/
> [2] https://lore.kernel.org/linux-devicetree/162343800075.7434.10921347563461214925.b4-ty@ti.com/
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/4] arm64: dts: ti: k3-am642-evm/sk: Reserve some on-chip SRAM for R5Fs

[Nishanth Menon]

On 13:05-20210614, Suman Anna wrote:
> >> +&oc_sram {
> >> +	main_r5fss0_core0_sram: r5f-sram@40000 {
> >> +		reg = <0x40000 0x40000>;
> >> +	};
> >> +
> >> +	main_r5fss0_core1_sram: r5f-sram@80000 {
> >> +		reg = <0x80000 0x40000>;
> >> +	};
> >> +
> >> +	main_r5fss1_core0_sram: r5f-sram@c0000 {
> >> +		reg = <0xc0000 0x40000>;
> >> +	};
> >> +
> >> +	main_r5fss1_core1_sram: r5f-sram@100000 {
> >> +		reg = <0x100000 0x40000>;
> >> +	};
> >> +};
> > 
> 
> These addresses are currently in sync with the corresponding firmware linker map
> files. Any changes needed here should also be aligned and updated with all the
> firmwares then.
> 
> Nishanth,
> How about dropping this patch until we conclude the discussion and picking up
> the rest?


Lets skip this patch for this merge cycle - aka stay compatible with the
previous reference binaries that do not use OCSRAM (aka not pick up
4x latency improvement), till we figure out a future looking and
relatively stable memory map that considers:

a) R5s IPC RAM
+ future usage:
b) M4F IPC RAM
c) ICSSG buffer RAMs

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel