[PATCH v11 0/9] TI K3 M4F support on AM62 and AM64 SoCs

[PATCH v11 0/9] TI K3 M4F support on AM62 and AM64 SoCs

[Andrew Davis]

Hello all,

This is the continuation of the M4F RProc support series from here[0].
I'm helping out with the upstream task for Hari and so versions (v8+)
is a little different than the previous(v7-) postings[0]. Most notable
change I've introduced being the patches factoring out common support
from the current K3 R5 and DSP drivers have been dropped. I'd like
to do that re-factor *after* getting this driver in shape, that way
we have 3 similar drivers to factor out from vs trying to make those
changes in parallel with the series adding M4 support.

Anyway, details on our M4F subsystem can be found the
the AM62 TRM in the section on the same:

AM62x Technical Reference Manual (SPRUIV7A – MAY 2022)
https://www.ti.com/lit/pdf/SPRUIV7A

Thanks,
Andrew

[0] https://lore.kernel.org/linux-arm-kernel/20240202175538.1705-5-hnagalla@ti.com/T/

Changes for v11:
 - Added patch [2/9] factoring out a common function
 - Addressed comments by Mathieu from v10
 - Rebased on v6.11-rc1
 - Small reworks in driver for readability

Changes for v10:
 - Rebased on v6.10-rc3
 - Added AM64 M4 support in DT
 - Addressed comments by Mathieu from v9

Changes for v9:
 - Fixed reserved-memory.yaml text in [1/5]
 - Split dts patch into one for SoC and one for board enable
 - Corrected DT property order and formatting [4/5][5/5]

Andrew Davis (1):
  remoteproc: k3: Factor out TI-SCI processor control OF get function

Hari Nagalla (7):
  dt-bindings: remoteproc: k3-m4f: Add K3 AM64x SoCs
  arm64: dts: ti: k3-am62: Add M4F remoteproc node
  arm64: dts: ti: k3-am625-sk: Add M4F remoteproc node
  arm64: dts: ti: k3-am64: Add M4F remoteproc node
  arm64: dts: ti: k3-am642-sk: Add M4F remoteproc node
  arm64: dts: ti: k3-am642-evm: Add M4F remoteproc node
  arm64: defconfig: Enable TI K3 M4 remoteproc driver

Martyn Welch (1):
  remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem

 .../bindings/remoteproc/ti,k3-m4f-rproc.yaml  | 125 ++++
 arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi       |  13 +
 .../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi |  19 +
 arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi       |  13 +
 arch/arm64/boot/dts/ti/k3-am642-evm.dts       |  19 +
 arch/arm64/boot/dts/ti/k3-am642-sk.dts        |  19 +
 arch/arm64/configs/defconfig                  |   1 +
 drivers/remoteproc/Kconfig                    |  13 +
 drivers/remoteproc/Makefile                   |   1 +
 drivers/remoteproc/ti_k3_dsp_remoteproc.c     |  28 +-
 drivers/remoteproc/ti_k3_m4_remoteproc.c      | 667 ++++++++++++++++++
 drivers/remoteproc/ti_k3_r5_remoteproc.c      |  28 +-
 drivers/remoteproc/ti_sci_proc.h              |  26 +
 13 files changed, 918 insertions(+), 54 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
 create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c

-- 
2.39.2

[PATCH v11 1/9] dt-bindings: remoteproc: k3-m4f: Add K3 AM64x SoCs

[Andrew Davis]

From: Hari Nagalla <hnagalla@ti.com>

K3 AM64x SoC has a Cortex M4F subsystem in the MCU voltage domain.
The remote processor's life cycle management and IPC mechanisms are
similar across the R5F and M4F cores from remote processor driver
point of view. However, there are subtle differences in image loading
and starting the M4F subsystems.

The YAML binding document provides the various node properties to be
configured by the consumers of the M4F subsystem.

Signed-off-by: Martyn Welch <martyn.welch@collabora.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
---
 .../bindings/remoteproc/ti,k3-m4f-rproc.yaml  | 125 ++++++++++++++++++
 1 file changed, 125 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml

diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
new file mode 100644
index 0000000000000..2bd0752b6ba9e
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
@@ -0,0 +1,125 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/ti,k3-m4f-rproc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI K3 M4F processor subsystems
+
+maintainers:
+  - Hari Nagalla <hnagalla@ti.com>
+  - Mathieu Poirier <mathieu.poirier@linaro.org>
+
+description: |
+  Some K3 family SoCs have Arm Cortex M4F cores. AM64x is a SoC in K3
+  family with a M4F core. Typically safety oriented applications may use
+  the M4F core in isolation without an IPC. Where as some industrial and
+  home automation applications, may use the M4F core as a remote processor
+  with IPC communications.
+
+$ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
+
+properties:
+  compatible:
+    enum:
+      - ti,am64-m4fss
+
+  power-domains:
+    maxItems: 1
+
+  "#address-cells":
+    const: 2
+
+  "#size-cells":
+    const: 2
+
+  reg:
+    items:
+      - description: IRAM internal memory region
+      - description: DRAM internal memory region
+
+  reg-names:
+    items:
+      - const: iram
+      - const: dram
+
+  resets:
+    maxItems: 1
+
+  firmware-name:
+    maxItems: 1
+    description: Name of firmware to load for the M4F core
+
+  mboxes:
+    description:
+      OMAP Mailbox specifier denoting the sub-mailbox, to be used for
+      communication with the remote processor. This property should match
+      with the sub-mailbox node used in the firmware image.
+    maxItems: 1
+
+  memory-region:
+    description:
+      phandle to the reserved memory nodes to be associated with the
+      remoteproc device. Optional memory regions available for firmware
+      specific purposes.
+      (see reserved-memory/reserved-memory.yaml in dtschema project)
+    maxItems: 8
+    items:
+      - description: regions used for DMA allocations like vrings, vring buffers
+                     and memory dedicated to firmware's specific purposes.
+    additionalItems: true
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - ti,sci
+  - ti,sci-dev-id
+  - ti,sci-proc-ids
+  - resets
+  - firmware-name
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    reserved-memory {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        mcu_m4fss_dma_memory_region: m4f-dma-memory@9cb00000 {
+            compatible = "shared-dma-pool";
+            reg = <0x00 0x9cb00000 0x00 0x100000>;
+            no-map;
+        };
+
+        mcu_m4fss_memory_region: m4f-memory@9cc00000 {
+            compatible = "shared-dma-pool";
+            reg = <0x00 0x9cc00000 0x00 0xe00000>;
+            no-map;
+        };
+    };
+
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        mailbox0_cluster0: mailbox-0 {
+            #mbox-cells = <1>;
+        };
+
+        remoteproc@5000000 {
+            compatible = "ti,am64-m4fss";
+            reg = <0x00 0x5000000 0x00 0x30000>,
+                  <0x00 0x5040000 0x00 0x10000>;
+            reg-names = "iram", "dram";
+            resets = <&k3_reset 9 1>;
+            firmware-name = "am62-mcu-m4f0_0-fw";
+            mboxes = <&mailbox0_cluster0>, <&mbox_m4_0>;
+            memory-region = <&mcu_m4fss_dma_memory_region>,
+                            <&mcu_m4fss_memory_region>;
+            ti,sci = <&dmsc>;
+            ti,sci-dev-id = <9>;
+            ti,sci-proc-ids = <0x18 0xff>;
+         };
+    };
-- 
2.39.2

[PATCH v11 2/9] remoteproc: k3: Factor out TI-SCI processor control OF get function

[Andrew Davis]

Building the TSP structure is common for users of the TI-SCI processor
control interface. Factor out this function and put it with the rest
of the TI-SCI processor control functions.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/remoteproc/ti_k3_dsp_remoteproc.c | 28 +----------------------
 drivers/remoteproc/ti_k3_r5_remoteproc.c  | 28 +----------------------
 drivers/remoteproc/ti_sci_proc.h          | 26 +++++++++++++++++++++
 3 files changed, 28 insertions(+), 54 deletions(-)

diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
index a22d41689a7d2..1585769092924 100644
--- a/drivers/remoteproc/ti_k3_dsp_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
@@ -636,32 +636,6 @@ static void k3_dsp_release_tsp(void *data)
 	ti_sci_proc_release(tsp);
 }
 
-static
-struct ti_sci_proc *k3_dsp_rproc_of_get_tsp(struct device *dev,
-					    const struct ti_sci_handle *sci)
-{
-	struct ti_sci_proc *tsp;
-	u32 temp[2];
-	int ret;
-
-	ret = of_property_read_u32_array(dev->of_node, "ti,sci-proc-ids",
-					 temp, 2);
-	if (ret < 0)
-		return ERR_PTR(ret);
-
-	tsp = devm_kzalloc(dev, sizeof(*tsp), GFP_KERNEL);
-	if (!tsp)
-		return ERR_PTR(-ENOMEM);
-
-	tsp->dev = dev;
-	tsp->sci = sci;
-	tsp->ops = &sci->ops.proc_ops;
-	tsp->proc_id = temp[0];
-	tsp->host_id = temp[1];
-
-	return tsp;
-}
-
 static int k3_dsp_rproc_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -711,7 +685,7 @@ static int k3_dsp_rproc_probe(struct platform_device *pdev)
 		return dev_err_probe(dev, PTR_ERR(kproc->reset),
 				     "failed to get reset\n");
 
-	kproc->tsp = k3_dsp_rproc_of_get_tsp(dev, kproc->ti_sci);
+	kproc->tsp = ti_sci_proc_of_get_tsp(dev, kproc->ti_sci);
 	if (IS_ERR(kproc->tsp))
 		return dev_err_probe(dev, PTR_ERR(kproc->tsp),
 				     "failed to construct ti-sci proc control\n");
diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/ti_k3_r5_remoteproc.c
index 39a47540c5900..dd6294ab81e2e 100644
--- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
@@ -1533,32 +1533,6 @@ static int k3_r5_core_of_get_sram_memories(struct platform_device *pdev,
 	return 0;
 }
 
-static
-struct ti_sci_proc *k3_r5_core_of_get_tsp(struct device *dev,
-					  const struct ti_sci_handle *sci)
-{
-	struct ti_sci_proc *tsp;
-	u32 temp[2];
-	int ret;
-
-	ret = of_property_read_u32_array(dev_of_node(dev), "ti,sci-proc-ids",
-					 temp, 2);
-	if (ret < 0)
-		return ERR_PTR(ret);
-
-	tsp = devm_kzalloc(dev, sizeof(*tsp), GFP_KERNEL);
-	if (!tsp)
-		return ERR_PTR(-ENOMEM);
-
-	tsp->dev = dev;
-	tsp->sci = sci;
-	tsp->ops = &sci->ops.proc_ops;
-	tsp->proc_id = temp[0];
-	tsp->host_id = temp[1];
-
-	return tsp;
-}
-
 static int k3_r5_core_of_init(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -1633,7 +1607,7 @@ static int k3_r5_core_of_init(struct platform_device *pdev)
 		goto err;
 	}
 
-	core->tsp = k3_r5_core_of_get_tsp(dev, core->ti_sci);
+	core->tsp = ti_sci_proc_of_get_tsp(dev, core->ti_sci);
 	if (IS_ERR(core->tsp)) {
 		ret = PTR_ERR(core->tsp);
 		dev_err(dev, "failed to construct ti-sci proc control, ret = %d\n",
diff --git a/drivers/remoteproc/ti_sci_proc.h b/drivers/remoteproc/ti_sci_proc.h
index 778558abcdcc5..f3911ce75252e 100644
--- a/drivers/remoteproc/ti_sci_proc.h
+++ b/drivers/remoteproc/ti_sci_proc.h
@@ -28,6 +28,32 @@ struct ti_sci_proc {
 	u8 host_id;
 };
 
+static inline
+struct ti_sci_proc *ti_sci_proc_of_get_tsp(struct device *dev,
+					   const struct ti_sci_handle *sci)
+{
+	struct ti_sci_proc *tsp;
+	u32 temp[2];
+	int ret;
+
+	ret = of_property_read_u32_array(dev_of_node(dev), "ti,sci-proc-ids",
+					 temp, 2);
+	if (ret < 0)
+		return ERR_PTR(ret);
+
+	tsp = devm_kzalloc(dev, sizeof(*tsp), GFP_KERNEL);
+	if (!tsp)
+		return ERR_PTR(-ENOMEM);
+
+	tsp->dev = dev;
+	tsp->sci = sci;
+	tsp->ops = &sci->ops.proc_ops;
+	tsp->proc_id = temp[0];
+	tsp->host_id = temp[1];
+
+	return tsp;
+}
+
 static inline int ti_sci_proc_request(struct ti_sci_proc *tsp)
 {
 	int ret;
-- 
2.39.2

[PATCH v11 3/9] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem

[Andrew Davis]

From: Martyn Welch <martyn.welch@collabora.com>

The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
the MCU domain. This core is typically used for safety applications in a
stand alone mode. However, some application (non safety related) may
want to use the M4F core as a generic remote processor with IPC to the
host processor. The M4F core has internal IRAM and DRAM memories and are
exposed to the system bus for code and data loading.

A remote processor driver is added to support this subsystem, including
being able to load and boot the M4F core. Loading includes to M4F
internal memories and predefined external code/data memories. The
carve outs for external contiguous memory is defined in the M4F device
node and should match with the external memory declarations in the M4F
image binary. The M4F subsystem has two resets. One reset is for the
entire subsystem i.e including the internal memories and the other, a
local reset is only for the M4F processing core. When loading the image,
the driver first releases the subsystem reset, loads the firmware image
and then releases the local reset to let the M4F processing core run.

Signed-off-by: Martyn Welch <martyn.welch@collabora.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/remoteproc/Kconfig               |  13 +
 drivers/remoteproc/Makefile              |   1 +
 drivers/remoteproc/ti_k3_m4_remoteproc.c | 667 +++++++++++++++++++++++
 3 files changed, 681 insertions(+)
 create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index dda2ada215b7c..0f0862e20a932 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -340,6 +340,19 @@ config TI_K3_DSP_REMOTEPROC
 	  It's safe to say N here if you're not interested in utilizing
 	  the DSP slave processors.
 
+config TI_K3_M4_REMOTEPROC
+	tristate "TI K3 M4 remoteproc support"
+	depends on ARCH_K3 || COMPILE_TEST
+	select MAILBOX
+	select OMAP2PLUS_MBOX
+	help
+	  Say m here to support TI's M4 remote processor subsystems
+	  on various TI K3 family of SoCs through the remote processor
+	  framework.
+
+	  It's safe to say N here if you're not interested in utilizing
+	  a remote processor.
+
 config TI_K3_R5_REMOTEPROC
 	tristate "TI K3 R5 remoteproc support"
 	depends on ARCH_K3
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 91314a9b43cef..5ff4e2fee4abd 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC)		+= st_remoteproc.o
 obj-$(CONFIG_ST_SLIM_REMOTEPROC)	+= st_slim_rproc.o
 obj-$(CONFIG_STM32_RPROC)		+= stm32_rproc.o
 obj-$(CONFIG_TI_K3_DSP_REMOTEPROC)	+= ti_k3_dsp_remoteproc.o
+obj-$(CONFIG_TI_K3_M4_REMOTEPROC)	+= ti_k3_m4_remoteproc.o
 obj-$(CONFIG_TI_K3_R5_REMOTEPROC)	+= ti_k3_r5_remoteproc.o
 obj-$(CONFIG_XLNX_R5_REMOTEPROC)	+= xlnx_r5_remoteproc.o
diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c b/drivers/remoteproc/ti_k3_m4_remoteproc.c
new file mode 100644
index 0000000000000..09f0484a90e10
--- /dev/null
+++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
@@ -0,0 +1,667 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * TI K3 Cortex-M4 Remote Processor(s) driver
+ *
+ * Copyright (C) 2021-2024 Texas Instruments Incorporated - https://www.ti.com/
+ *	Hari Nagalla <hnagalla@ti.com>
+ */
+
+#include <linux/io.h>
+#include <linux/mailbox_client.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_reserved_mem.h>
+#include <linux/platform_device.h>
+#include <linux/remoteproc.h>
+#include <linux/reset.h>
+#include <linux/slab.h>
+
+#include "omap_remoteproc.h"
+#include "remoteproc_internal.h"
+#include "ti_sci_proc.h"
+
+#define K3_M4_IRAM_DEV_ADDR 0x00000
+#define K3_M4_DRAM_DEV_ADDR 0x30000
+
+/**
+ * struct k3_m4_rproc_mem - internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @dev_addr: Device address of the memory region from remote processor view
+ * @size: Size of the memory region
+ */
+struct k3_m4_rproc_mem {
+	void __iomem *cpu_addr;
+	phys_addr_t bus_addr;
+	u32 dev_addr;
+	size_t size;
+};
+
+/**
+ * struct k3_m4_rproc_mem_data - memory definitions for a remote processor
+ * @name: name for this memory entry
+ * @dev_addr: device address for the memory entry
+ */
+struct k3_m4_rproc_mem_data {
+	const char *name;
+	const u32 dev_addr;
+};
+
+/**
+ * struct k3_m4_rproc - k3 remote processor driver structure
+ * @dev: cached device pointer
+ * @mem: internal memory regions data
+ * @num_mems: number of internal memory regions
+ * @rmem: reserved memory regions data
+ * @num_rmems: number of reserved memory regions
+ * @reset: reset control handle
+ * @tsp: TI-SCI processor control handle
+ * @ti_sci: TI-SCI handle
+ * @ti_sci_id: TI-SCI device identifier
+ * @mbox: mailbox channel handle
+ * @client: mailbox client to request the mailbox channel
+ */
+struct k3_m4_rproc {
+	struct device *dev;
+	struct k3_m4_rproc_mem *mem;
+	int num_mems;
+	struct k3_m4_rproc_mem *rmem;
+	int num_rmems;
+	struct reset_control *reset;
+	struct ti_sci_proc *tsp;
+	const struct ti_sci_handle *ti_sci;
+	u32 ti_sci_id;
+	struct mbox_chan *mbox;
+	struct mbox_client client;
+};
+
+/**
+ * k3_m4_rproc_mbox_callback() - inbound mailbox message handler
+ * @client: mailbox client pointer used for requesting the mailbox channel
+ * @data: mailbox payload
+ *
+ * This handler is invoked by the K3 mailbox driver whenever a mailbox
+ * message is received. Usually, the mailbox payload simply contains
+ * the index of the virtqueue that is kicked by the remote processor,
+ * and we let remoteproc core handle it.
+ *
+ * In addition to virtqueue indices, we also have some out-of-band values
+ * that indicate different events. Those values are deliberately very
+ * large so they don't coincide with virtqueue indices.
+ */
+static void k3_m4_rproc_mbox_callback(struct mbox_client *client, void *data)
+{
+	struct device *dev = client->dev;
+	struct rproc *rproc = dev_get_drvdata(dev);
+	u32 msg = (u32)(uintptr_t)(data);
+
+	dev_dbg(dev, "mbox msg: 0x%x\n", msg);
+
+	switch (msg) {
+	case RP_MBOX_CRASH:
+		/*
+		 * remoteproc detected an exception, but error recovery is not
+		 * supported. So, just log this for now
+		 */
+		dev_err(dev, "K3 rproc %s crashed\n", rproc->name);
+		break;
+	case RP_MBOX_ECHO_REPLY:
+		dev_info(dev, "received echo reply from %s\n", rproc->name);
+		break;
+	default:
+		/* silently handle all other valid messages */
+		if (msg >= RP_MBOX_READY && msg < RP_MBOX_END_MSG)
+			return;
+		if (msg > rproc->max_notifyid) {
+			dev_dbg(dev, "dropping unknown message 0x%x", msg);
+			return;
+		}
+		/* msg contains the index of the triggered vring */
+		if (rproc_vq_interrupt(rproc, msg) == IRQ_NONE)
+			dev_dbg(dev, "no message was found in vqid %d\n", msg);
+	}
+}
+
+/*
+ * Kick the remote processor to notify about pending unprocessed messages.
+ * The vqid usage is not used and is inconsequential, as the kick is performed
+ * through a simulated GPIO (a bit in an IPC interrupt-triggering register),
+ * the remote processor is expected to process both its Tx and Rx virtqueues.
+ */
+static void k3_m4_rproc_kick(struct rproc *rproc, int vqid)
+{
+	struct k3_m4_rproc *kproc = rproc->priv;
+	struct device *dev = kproc->dev;
+	u32 msg = (u32)vqid;
+	int ret;
+
+	/*
+	 * Send the index of the triggered virtqueue in the mailbox payload.
+	 * NOTE: msg is cast to uintptr_t to prevent compiler warnings when
+	 * void* is 64bit. It is safely cast back to u32 in the mailbox driver.
+	 */
+	ret = mbox_send_message(kproc->mbox, (void *)(uintptr_t)msg);
+	if (ret < 0)
+		dev_err(dev, "failed to send mailbox message, status = %d\n",
+			ret);
+}
+
+static int k3_m4_rproc_ping_mbox(struct k3_m4_rproc *kproc)
+{
+	struct device *dev = kproc->dev;
+	int ret;
+
+	/*
+	 * Ping the remote processor, this is only for sanity-sake for now;
+	 * there is no functional effect whatsoever.
+	 *
+	 * Note that the reply will _not_ arrive immediately: this message
+	 * will wait in the mailbox fifo until the remote processor is booted.
+	 */
+	ret = mbox_send_message(kproc->mbox, (void *)RP_MBOX_ECHO_REQUEST);
+	if (ret < 0) {
+		dev_err(dev, "mbox_send_message failed: %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+/*
+ * The M4 cores have a local reset that affects only the CPU, and a
+ * generic module reset that powers on the device and allows the internal
+ * memories to be accessed while the local reset is asserted. This function is
+ * used to release the global reset on remote cores to allow loading into the
+ * internal RAMs. The .prepare() ops is invoked by remoteproc core before any
+ * firmware loading, and is followed by the .start() ops after loading to
+ * actually let the remote cores to run.
+ */
+static int k3_m4_rproc_prepare(struct rproc *rproc)
+{
+	struct k3_m4_rproc *kproc = rproc->priv;
+	struct device *dev = kproc->dev;
+	int ret;
+
+	/* If the core is running already no need to deassert the module reset */
+	if (rproc->state == RPROC_DETACHED)
+		return 0;
+
+	/*
+	 * Ensure the local reset is asserted so the core doesn't
+	 * execute bogus code when the module reset is released.
+	 */
+	ret = reset_control_assert(kproc->reset);
+	if (ret) {
+		dev_err(dev, "could not assert local reset\n");
+		return ret;
+	}
+
+	ret = reset_control_status(kproc->reset);
+	if (ret <= 0) {
+		dev_err(dev, "local reset still not asserted\n");
+		return ret;
+	}
+
+	ret = kproc->ti_sci->ops.dev_ops.get_device(kproc->ti_sci,
+						    kproc->ti_sci_id);
+	if (ret) {
+		dev_err(dev, "could not deassert module-reset for internal RAM loading\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+/*
+ * This function implements the .unprepare() ops and performs the complimentary
+ * operations to that of the .prepare() ops. The function is used to assert the
+ * global reset on applicable cores. This completes the second portion of
+ * powering down the remote core. The cores themselves are only halted in the
+ * .stop() callback through the local reset, and the .unprepare() ops is invoked
+ * by the remoteproc core after the remoteproc is stopped to balance the global
+ * reset.
+ */
+static int k3_m4_rproc_unprepare(struct rproc *rproc)
+{
+	struct k3_m4_rproc *kproc = rproc->priv;
+	struct device *dev = kproc->dev;
+	int ret;
+
+	/* If the core is going to be detached do not assert the module reset */
+	if (rproc->state == RPROC_ATTACHED)
+		return 0;
+
+	ret = kproc->ti_sci->ops.dev_ops.put_device(kproc->ti_sci,
+						    kproc->ti_sci_id);
+	if (ret) {
+		dev_err(dev, "module-reset assert failed\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+/*
+ * This function implements the .get_loaded_rsc_table() callback and is used
+ * to provide the resource table for a booted remote processor in IPC-only
+ * mode. The remote processor firmwares follow a design-by-contract approach
+ * and are expected to have the resource table at the base of the DDR region
+ * reserved for firmware usage. This provides flexibility for the remote
+ * processor to be booted by different bootloaders that may or may not have the
+ * ability to publish the resource table address and size through a DT
+ * property.
+ */
+static struct resource_table *k3_m4_get_loaded_rsc_table(struct rproc *rproc,
+							 size_t *rsc_table_sz)
+{
+	struct k3_m4_rproc *kproc = rproc->priv;
+	struct device *dev = kproc->dev;
+
+	if (!kproc->rmem[0].cpu_addr) {
+		dev_err(dev, "memory-region #1 does not exist, loaded rsc table can't be found");
+		return ERR_PTR(-ENOMEM);
+	}
+
+	/*
+	 * NOTE: The resource table size is currently hard-coded to a maximum
+	 * of 256 bytes. The most common resource table usage for K3 firmwares
+	 * is to only have the vdev resource entry and an optional trace entry.
+	 * The exact size could be computed based on resource table address, but
+	 * the hard-coded value suffices to support the IPC-only mode.
+	 */
+	*rsc_table_sz = 256;
+	return (__force struct resource_table *)kproc->rmem[0].cpu_addr;
+}
+
+/*
+ * Custom function to translate a remote processor device address (internal
+ * RAMs only) to a kernel virtual address.  The remote processors can access
+ * their RAMs at either an internal address visible only from a remote
+ * processor, or at the SoC-level bus address. Both these addresses need to be
+ * looked through for translation. The translated addresses can be used either
+ * by the remoteproc core for loading (when using kernel remoteproc loader), or
+ * by any rpmsg bus drivers.
+ */
+static void *k3_m4_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
+{
+	struct k3_m4_rproc *kproc = rproc->priv;
+	void __iomem *va = NULL;
+	phys_addr_t bus_addr;
+	u32 dev_addr, offset;
+	size_t size;
+	int i;
+
+	if (len == 0)
+		return NULL;
+
+	for (i = 0; i < kproc->num_mems; i++) {
+		bus_addr = kproc->mem[i].bus_addr;
+		dev_addr = kproc->mem[i].dev_addr;
+		size = kproc->mem[i].size;
+
+		/* handle M4-view addresses */
+		if (da >= dev_addr && ((da + len) <= (dev_addr + size))) {
+			offset = da - dev_addr;
+			va = kproc->mem[i].cpu_addr + offset;
+			return (__force void *)va;
+		}
+
+		/* handle SoC-view addresses */
+		if (da >= bus_addr && ((da + len) <= (bus_addr + size))) {
+			offset = da - bus_addr;
+			va = kproc->mem[i].cpu_addr + offset;
+			return (__force void *)va;
+		}
+	}
+
+	/* handle static DDR reserved memory regions */
+	for (i = 0; i < kproc->num_rmems; i++) {
+		dev_addr = kproc->rmem[i].dev_addr;
+		size = kproc->rmem[i].size;
+
+		if (da >= dev_addr && ((da + len) <= (dev_addr + size))) {
+			offset = da - dev_addr;
+			va = kproc->rmem[i].cpu_addr + offset;
+			return (__force void *)va;
+		}
+	}
+
+	return NULL;
+}
+
+static int k3_m4_rproc_of_get_memories(struct platform_device *pdev,
+				       struct k3_m4_rproc *kproc)
+{
+	static const char * const mem_names[] = { "iram", "dram" };
+	static const u32 mem_addrs[] = { K3_M4_IRAM_DEV_ADDR, K3_M4_DRAM_DEV_ADDR };
+	struct device *dev = &pdev->dev;
+	struct resource *res;
+	int num_mems;
+	int i;
+
+	num_mems = ARRAY_SIZE(mem_names);
+	kproc->mem = devm_kcalloc(kproc->dev, num_mems,
+				  sizeof(*kproc->mem), GFP_KERNEL);
+	if (!kproc->mem)
+		return -ENOMEM;
+
+	for (i = 0; i < num_mems; i++) {
+		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+						   mem_names[i]);
+		if (!res) {
+			dev_err(dev, "found no memory resource for %s\n",
+				mem_names[i]);
+			return -EINVAL;
+		}
+		if (!devm_request_mem_region(dev, res->start,
+					     resource_size(res),
+					     dev_name(dev))) {
+			dev_err(dev, "could not request %s region for resource\n",
+				mem_names[i]);
+			return -EBUSY;
+		}
+
+		kproc->mem[i].cpu_addr = devm_ioremap_wc(dev, res->start,
+							 resource_size(res));
+		if (!kproc->mem[i].cpu_addr) {
+			dev_err(dev, "failed to map %s memory\n",
+				mem_names[i]);
+			return -ENOMEM;
+		}
+		kproc->mem[i].bus_addr = res->start;
+		kproc->mem[i].dev_addr = mem_addrs[i];
+		kproc->mem[i].size = resource_size(res);
+
+		dev_dbg(dev, "memory %8s: bus addr %pa size 0x%zx va %pK da 0x%x\n",
+			mem_names[i], &kproc->mem[i].bus_addr,
+			kproc->mem[i].size, kproc->mem[i].cpu_addr,
+			kproc->mem[i].dev_addr);
+	}
+	kproc->num_mems = num_mems;
+
+	return 0;
+}
+
+static void k3_m4_rproc_dev_mem_release(void *data)
+{
+	struct device *dev = data;
+
+	of_reserved_mem_device_release(dev);
+}
+
+static int k3_m4_reserved_mem_init(struct k3_m4_rproc *kproc)
+{
+	struct device *dev = kproc->dev;
+	struct device_node *np = dev->of_node;
+	struct device_node *rmem_np;
+	struct reserved_mem *rmem;
+	int num_rmems;
+	int ret, i;
+
+	num_rmems = of_property_count_elems_of_size(np, "memory-region",
+						    sizeof(phandle));
+	if (num_rmems < 0) {
+		dev_err(dev, "device does not reserved memory regions (%d)\n",
+			num_rmems);
+		return -EINVAL;
+	}
+	if (num_rmems < 2) {
+		dev_err(dev, "device needs at least two memory regions to be defined, num = %d\n",
+			num_rmems);
+		return -EINVAL;
+	}
+
+	/* use reserved memory region 0 for vring DMA allocations */
+	ret = of_reserved_mem_device_init_by_idx(dev, np, 0);
+	if (ret) {
+		dev_err(dev, "device cannot initialize DMA pool (%d)\n", ret);
+		return ret;
+	}
+	ret = devm_add_action_or_reset(dev, k3_m4_rproc_dev_mem_release, dev);
+	if (ret)
+		return ret;
+
+	num_rmems--;
+	kproc->rmem = devm_kcalloc(dev, num_rmems, sizeof(*kproc->rmem), GFP_KERNEL);
+	if (!kproc->rmem)
+		return -ENOMEM;
+
+	/* use remaining reserved memory regions for static carveouts */
+	for (i = 0; i < num_rmems; i++) {
+		rmem_np = of_parse_phandle(np, "memory-region", i + 1);
+		if (!rmem_np)
+			return -EINVAL;
+
+		rmem = of_reserved_mem_lookup(rmem_np);
+		if (!rmem) {
+			of_node_put(rmem_np);
+			return -EINVAL;
+		}
+		of_node_put(rmem_np);
+
+		kproc->rmem[i].bus_addr = rmem->base;
+		/* 64-bit address regions currently not supported */
+		kproc->rmem[i].dev_addr = (u32)rmem->base;
+		kproc->rmem[i].size = rmem->size;
+		kproc->rmem[i].cpu_addr = devm_ioremap_wc(dev, rmem->base, rmem->size);
+		if (!kproc->rmem[i].cpu_addr) {
+			dev_err(dev, "failed to map reserved memory#%d at %pa of size %pa\n",
+				i + 1, &rmem->base, &rmem->size);
+			return -ENOMEM;
+		}
+
+		dev_dbg(dev, "reserved memory%d: bus addr %pa size 0x%zx va %pK da 0x%x\n",
+			i + 1, &kproc->rmem[i].bus_addr,
+			kproc->rmem[i].size, kproc->rmem[i].cpu_addr,
+			kproc->rmem[i].dev_addr);
+	}
+	kproc->num_rmems = num_rmems;
+
+	return 0;
+}
+
+static void k3_m4_release_tsp(void *data)
+{
+	struct ti_sci_proc *tsp = data;
+
+	ti_sci_proc_release(tsp);
+}
+
+/*
+ * Power up the M4 remote processor.
+ *
+ * This function will be invoked only after the firmware for this rproc
+ * was loaded, parsed successfully, and all of its resource requirements
+ * were met. This callback is invoked only in remoteproc mode.
+ */
+static int k3_m4_rproc_start(struct rproc *rproc)
+{
+	struct k3_m4_rproc *kproc = rproc->priv;
+	struct device *dev = kproc->dev;
+	int ret;
+
+	ret = k3_m4_rproc_ping_mbox(kproc);
+	if (ret)
+		return ret;
+
+	ret = reset_control_deassert(kproc->reset);
+	if (ret) {
+		dev_err(dev, "local-reset deassert failed, ret = %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+/*
+ * Stop the M4 remote processor.
+ *
+ * This function puts the M4 processor into reset, and finishes processing
+ * of any pending messages. This callback is invoked only in remoteproc mode.
+ */
+static int k3_m4_rproc_stop(struct rproc *rproc)
+{
+	struct k3_m4_rproc *kproc = rproc->priv;
+	struct device *dev = kproc->dev;
+	int ret;
+
+	ret = reset_control_assert(kproc->reset);
+	if (ret) {
+		dev_err(dev, "local-reset assert failed, ret = %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+/*
+ * Attach to a running M4 remote processor (IPC-only mode)
+ *
+ * The remote processor is already booted, so there is no need to issue any
+ * TI-SCI commands to boot the M4 core. This callback is used only in IPC-only
+ * mode.
+ */
+static int k3_m4_rproc_attach(struct rproc *rproc)
+{
+	struct k3_m4_rproc *kproc = rproc->priv;
+	int ret;
+
+	ret = k3_m4_rproc_ping_mbox(kproc);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+/*
+ * Detach from a running M4 remote processor (IPC-only mode)
+ *
+ * This rproc detach callback performs the opposite operation to attach
+ * callback, the M4 core is not stopped and will be left to continue to
+ * run its booted firmware. This callback is invoked only in IPC-only mode.
+ */
+static int k3_m4_rproc_detach(struct rproc *rproc)
+{
+	return 0;
+}
+
+static const struct rproc_ops k3_m4_rproc_ops = {
+	.prepare = k3_m4_rproc_prepare,
+	.unprepare = k3_m4_rproc_unprepare,
+	.start = k3_m4_rproc_start,
+	.stop = k3_m4_rproc_stop,
+	.attach = k3_m4_rproc_attach,
+	.detach = k3_m4_rproc_detach,
+	.kick = k3_m4_rproc_kick,
+	.da_to_va = k3_m4_rproc_da_to_va,
+	.get_loaded_rsc_table = k3_m4_get_loaded_rsc_table,
+};
+
+static int k3_m4_rproc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct k3_m4_rproc *kproc;
+	struct rproc *rproc;
+	const char *fw_name;
+	bool r_state = false;
+	bool p_state = false;
+	int ret;
+
+	ret = rproc_of_parse_firmware(dev, 0, &fw_name);
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to parse firmware-name property\n");
+
+	rproc = devm_rproc_alloc(dev, dev_name(dev), &k3_m4_rproc_ops, fw_name,
+				 sizeof(*kproc));
+	if (!rproc)
+		return -ENOMEM;
+
+	rproc->has_iommu = false;
+	rproc->recovery_disabled = true;
+	kproc = rproc->priv;
+	kproc->dev = dev;
+	platform_set_drvdata(pdev, rproc);
+
+	kproc->ti_sci = devm_ti_sci_get_by_phandle(dev, "ti,sci");
+	if (IS_ERR(kproc->ti_sci))
+		return dev_err_probe(dev, PTR_ERR(kproc->ti_sci),
+				     "failed to get ti-sci handle\n");
+
+	ret = of_property_read_u32(dev->of_node, "ti,sci-dev-id", &kproc->ti_sci_id);
+	if (ret)
+		return dev_err_probe(dev, ret, "missing 'ti,sci-dev-id' property\n");
+
+	kproc->reset = devm_reset_control_get_exclusive(dev, NULL);
+	if (IS_ERR(kproc->reset))
+		return dev_err_probe(dev, PTR_ERR(kproc->reset), "failed to get reset\n");
+
+	kproc->tsp = ti_sci_proc_of_get_tsp(dev, kproc->ti_sci);
+	if (IS_ERR(kproc->tsp))
+		return dev_err_probe(dev, PTR_ERR(kproc->tsp),
+				     "failed to construct ti-sci proc control\n");
+
+	ret = ti_sci_proc_request(kproc->tsp);
+	if (ret < 0)
+		return dev_err_probe(dev, ret, "ti_sci_proc_request failed\n");
+	ret = devm_add_action_or_reset(dev, k3_m4_release_tsp, kproc->tsp);
+	if (ret)
+		return ret;
+
+	ret = k3_m4_rproc_of_get_memories(pdev, kproc);
+	if (ret)
+		return ret;
+
+	ret = k3_m4_reserved_mem_init(kproc);
+	if (ret)
+		return dev_err_probe(dev, ret, "reserved memory init failed\n");
+
+	ret = kproc->ti_sci->ops.dev_ops.is_on(kproc->ti_sci, kproc->ti_sci_id,
+					       &r_state, &p_state);
+	if (ret)
+		return dev_err_probe(dev, ret,
+				     "failed to get initial state, mode cannot be determined\n");
+
+	/* configure devices for either remoteproc or IPC-only mode */
+	if (p_state) {
+		rproc->state = RPROC_DETACHED;
+		dev_info(dev, "configured M4F for IPC-only mode\n");
+	} else {
+		dev_info(dev, "configured M4F for remoteproc mode\n");
+	}
+
+	kproc->client.dev = dev;
+	kproc->client.tx_done = NULL;
+	kproc->client.rx_callback = k3_m4_rproc_mbox_callback;
+	kproc->client.tx_block = false;
+	kproc->client.knows_txdone = false;
+	kproc->mbox = mbox_request_channel(&kproc->client, 0);
+	if (IS_ERR(kproc->mbox))
+		return dev_err_probe(dev, PTR_ERR(kproc->mbox),
+				     "mbox_request_channel failed\n");
+
+	ret = devm_rproc_add(dev, rproc);
+	if (ret)
+		return dev_err_probe(dev, ret,
+				     "failed to register device with remoteproc core\n");
+
+	return 0;
+}
+
+static const struct of_device_id k3_m4_of_match[] = {
+	{ .compatible = "ti,am64-m4fss", },
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, k3_m4_of_match);
+
+static struct platform_driver k3_m4_rproc_driver = {
+	.probe	= k3_m4_rproc_probe,
+	.driver	= {
+		.name = "k3-m4-rproc",
+		.of_match_table = k3_m4_of_match,
+	},
+};
+module_platform_driver(k3_m4_rproc_driver);
+
+MODULE_AUTHOR("Hari Nagalla <hnagalla@ti.com>");
+MODULE_DESCRIPTION("TI K3 M4 Remoteproc driver");
+MODULE_LICENSE("GPL");
-- 
2.39.2

[PATCH v11 4/9] arm64: dts: ti: k3-am62: Add M4F remoteproc node

[Andrew Davis]

From: Hari Nagalla <hnagalla@ti.com>

The AM62x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed.

Disable by default as this node is not complete until mailbox data
is provided in the board level DT.

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

diff --git a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
index e66d486ef1f21..7f6f0007e8e81 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
@@ -173,4 +173,17 @@ mcu_mcan1: can@4e18000 {
 		bosch,mram-cfg = <0x0 128 64 64 64 64 32 32>;
 		status = "disabled";
 	};
+
+	mcu_m4fss: m4fss@5000000 {
+		compatible = "ti,am64-m4fss";
+		reg = <0x00 0x5000000 0x00 0x30000>,
+		      <0x00 0x5040000 0x00 0x10000>;
+		reg-names = "iram", "dram";
+		resets = <&k3_reset 9 1>;
+		firmware-name = "am62-mcu-m4f0_0-fw";
+		ti,sci = <&dmsc>;
+		ti,sci-dev-id = <9>;
+		ti,sci-proc-ids = <0x18 0xff>;
+		status = "disabled";
+	};
 };
-- 
2.39.2

[PATCH v11 5/9] arm64: dts: ti: k3-am625-sk: Add M4F remoteproc node

[Andrew Davis]

From: Hari Nagalla <hnagalla@ti.com>

The AM62x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed. The first region is used
as a DMA pool for the rproc device, and the second region will furnish
the static carveout regions for the firmware memory.

The current carveout addresses and sizes are defined statically for
each rproc device. The M4F processor does not have an MMU, and as such
requires the exact memory used by the firmware to be set-aside.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Andrew Davis <afd@ti.com>
---
 .../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

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 44ff67b6bf1e4..6957b3e44c82f 100644
--- a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
@@ -56,6 +56,18 @@ linux,cma {
 			linux,cma-default;
 		};
 
+		mcu_m4fss_dma_memory_region: m4f-dma-memory@9cb00000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x9cb00000 0x00 0x100000>;
+			no-map;
+		};
+
+		mcu_m4fss_memory_region: m4f-memory@9cc00000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x9cc00000 0x00 0xe00000>;
+			no-map;
+		};
+
 		secure_tfa_ddr: tfa@9e780000 {
 			reg = <0x00 0x9e780000 0x00 0x80000>;
 			alignment = <0x1000>;
@@ -464,6 +476,13 @@ mbox_m4_0: mbox-m4-0 {
 	};
 };
 
+&mcu_m4fss {
+	mboxes = <&mailbox0_cluster0 &mbox_m4_0>;
+	memory-region = <&mcu_m4fss_dma_memory_region>,
+			<&mcu_m4fss_memory_region>;
+	status = "okay";
+};
+
 &usbss0 {
 	bootph-all;
 	status = "okay";
-- 
2.39.2

[PATCH v11 6/9] arm64: dts: ti: k3-am64: Add M4F remoteproc node

[Andrew Davis]

From: Hari Nagalla <hnagalla@ti.com>

The AM64x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed.

Disable by default as this node is not complete until mailbox data
is provided in the board level DT.

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

diff --git a/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
index ec17285869da6..b98e8ad453289 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
@@ -160,4 +160,17 @@ mcu_esm: esm@4100000 {
 		reg = <0x00 0x4100000 0x00 0x1000>;
 		ti,esm-pins = <0>, <1>;
 	};
+
+	mcu_m4fss: m4fss@5000000 {
+		compatible = "ti,am64-m4fss";
+		reg = <0x00 0x5000000 0x00 0x30000>,
+		      <0x00 0x5040000 0x00 0x10000>;
+		reg-names = "iram", "dram";
+		resets = <&k3_reset 9 1>;
+		firmware-name = "am64-mcu-m4f0_0-fw";
+		ti,sci = <&dmsc>;
+		ti,sci-dev-id = <9>;
+		ti,sci-proc-ids = <0x18 0xff>;
+		status = "disabled";
+	};
 };
-- 
2.39.2

[PATCH v11 7/9] arm64: dts: ti: k3-am642-sk: Add M4F remoteproc node

[Andrew Davis]

From: Hari Nagalla <hnagalla@ti.com>

The AM64x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed. The first region is used
as a DMA pool for the rproc device, and the second region will furnish
the static carveout regions for the firmware memory.

The current carveout addresses and sizes are defined statically for
each rproc device. The M4F processor does not have an MMU, and as such
requires the exact memory used by the firmware to be set-aside.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Andrew Davis <afd@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am642-sk.dts | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
index 44ecbcf1c8447..93e2e6f8a07be 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
@@ -99,6 +99,18 @@ main_r5fss1_core1_memory_region: r5f-memory@a3100000 {
 			no-map;
 		};
 
+		mcu_m4fss_dma_memory_region: m4f-dma-memory@a4000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa4000000 0x00 0x100000>;
+			no-map;
+		};
+
+		mcu_m4fss_memory_region: m4f-memory@a4100000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa4100000 0x00 0xf00000>;
+			no-map;
+		};
+
 		rtos_ipc_memory_region: ipc-memories@a5000000 {
 			reg = <0x00 0xa5000000 0x00 0x00800000>;
 			alignment = <0x1000>;
@@ -678,6 +690,13 @@ &main_r5fss1_core1 {
 			<&main_r5fss1_core1_memory_region>;
 };
 
+&mcu_m4fss {
+	mboxes = <&mailbox0_cluster6 &mbox_m4_0>;
+	memory-region = <&mcu_m4fss_dma_memory_region>,
+			<&mcu_m4fss_memory_region>;
+	status = "okay";
+};
+
 &ecap0 {
 	status = "okay";
 	/* PWM is available on Pin 1 of header J3 */
-- 
2.39.2

[PATCH v11 8/9] arm64: dts: ti: k3-am642-evm: Add M4F remoteproc node

[Andrew Davis]

From: Hari Nagalla <hnagalla@ti.com>

The AM64x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed. The first region is used
as a DMA pool for the rproc device, and the second region will furnish
the static carveout regions for the firmware memory.

The current carveout addresses and sizes are defined statically for
each rproc device. The M4F processor does not have an MMU, and as such
requires the exact memory used by the firmware to be set-aside.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Andrew Davis <afd@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am642-evm.dts | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index 6bb1ad2e56ec2..23915641115b1 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
@@ -101,6 +101,18 @@ main_r5fss1_core1_memory_region: r5f-memory@a3100000 {
 			no-map;
 		};
 
+		mcu_m4fss_dma_memory_region: m4f-dma-memory@a4000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa4000000 0x00 0x100000>;
+			no-map;
+		};
+
+		mcu_m4fss_memory_region: m4f-memory@a4100000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa4100000 0x00 0xf00000>;
+			no-map;
+		};
+
 		rtos_ipc_memory_region: ipc-memories@a5000000 {
 			reg = <0x00 0xa5000000 0x00 0x00800000>;
 			alignment = <0x1000>;
@@ -769,6 +781,13 @@ &main_r5fss1_core1 {
 			<&main_r5fss1_core1_memory_region>;
 };
 
+&mcu_m4fss {
+	mboxes = <&mailbox0_cluster6 &mbox_m4_0>;
+	memory-region = <&mcu_m4fss_dma_memory_region>,
+			<&mcu_m4fss_memory_region>;
+	status = "okay";
+};
+
 &serdes_ln_ctrl {
 	idle-states = <AM64_SERDES0_LANE0_PCIE0>;
 };
-- 
2.39.2

[PATCH v11 9/9] arm64: defconfig: Enable TI K3 M4 remoteproc driver

[Andrew Davis]

From: Hari Nagalla <hnagalla@ti.com>

Some K3 platform devices (AM64x, AM62x) have a Cortex M4 core. Build
the M4 remote proc driver as a module for these platforms.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Andrew Davis <afd@ti.com>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 7d32fca649965..33b0487b0d607 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1383,6 +1383,7 @@ CONFIG_QCOM_Q6V5_PAS=m
 CONFIG_QCOM_SYSMON=m
 CONFIG_QCOM_WCNSS_PIL=m
 CONFIG_TI_K3_DSP_REMOTEPROC=m
+CONFIG_TI_K3_M4_REMOTEPROC=m
 CONFIG_TI_K3_R5_REMOTEPROC=m
 CONFIG_RPMSG_CHAR=m
 CONFIG_RPMSG_CTRL=m
-- 
2.39.2

Re: [PATCH v11 3/9] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem

[Mathieu Poirier]

Hi,

On Fri, Aug 02, 2024 at 10:21:03AM -0500, Andrew Davis wrote:
> From: Martyn Welch <martyn.welch@collabora.com>
> 
> The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
> the MCU domain. This core is typically used for safety applications in a
> stand alone mode. However, some application (non safety related) may
> want to use the M4F core as a generic remote processor with IPC to the
> host processor. The M4F core has internal IRAM and DRAM memories and are
> exposed to the system bus for code and data loading.
> 
> A remote processor driver is added to support this subsystem, including
> being able to load and boot the M4F core. Loading includes to M4F
> internal memories and predefined external code/data memories. The
> carve outs for external contiguous memory is defined in the M4F device
> node and should match with the external memory declarations in the M4F
> image binary. The M4F subsystem has two resets. One reset is for the
> entire subsystem i.e including the internal memories and the other, a
> local reset is only for the M4F processing core. When loading the image,
> the driver first releases the subsystem reset, loads the firmware image
> and then releases the local reset to let the M4F processing core run.
> 
> Signed-off-by: Martyn Welch <martyn.welch@collabora.com>
> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
> Signed-off-by: Andrew Davis <afd@ti.com>
> ---
>  drivers/remoteproc/Kconfig               |  13 +
>  drivers/remoteproc/Makefile              |   1 +
>  drivers/remoteproc/ti_k3_m4_remoteproc.c | 667 +++++++++++++++++++++++
>  3 files changed, 681 insertions(+)
>  create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index dda2ada215b7c..0f0862e20a932 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -340,6 +340,19 @@ config TI_K3_DSP_REMOTEPROC
>  	  It's safe to say N here if you're not interested in utilizing
>  	  the DSP slave processors.
>  
> +config TI_K3_M4_REMOTEPROC
> +	tristate "TI K3 M4 remoteproc support"
> +	depends on ARCH_K3 || COMPILE_TEST
> +	select MAILBOX
> +	select OMAP2PLUS_MBOX
> +	help
> +	  Say m here to support TI's M4 remote processor subsystems
> +	  on various TI K3 family of SoCs through the remote processor
> +	  framework.
> +
> +	  It's safe to say N here if you're not interested in utilizing
> +	  a remote processor.
> +
>  config TI_K3_R5_REMOTEPROC
>  	tristate "TI K3 R5 remoteproc support"
>  	depends on ARCH_K3
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 91314a9b43cef..5ff4e2fee4abd 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC)		+= st_remoteproc.o
>  obj-$(CONFIG_ST_SLIM_REMOTEPROC)	+= st_slim_rproc.o
>  obj-$(CONFIG_STM32_RPROC)		+= stm32_rproc.o
>  obj-$(CONFIG_TI_K3_DSP_REMOTEPROC)	+= ti_k3_dsp_remoteproc.o
> +obj-$(CONFIG_TI_K3_M4_REMOTEPROC)	+= ti_k3_m4_remoteproc.o
>  obj-$(CONFIG_TI_K3_R5_REMOTEPROC)	+= ti_k3_r5_remoteproc.o
>  obj-$(CONFIG_XLNX_R5_REMOTEPROC)	+= xlnx_r5_remoteproc.o
> diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c b/drivers/remoteproc/ti_k3_m4_remoteproc.c
> new file mode 100644
> index 0000000000000..09f0484a90e10
> --- /dev/null
> +++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
> @@ -0,0 +1,667 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * TI K3 Cortex-M4 Remote Processor(s) driver
> + *
> + * Copyright (C) 2021-2024 Texas Instruments Incorporated - https://www.ti.com/
> + *	Hari Nagalla <hnagalla@ti.com>
> + */
> +
> +#include <linux/io.h>
> +#include <linux/mailbox_client.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/of_reserved_mem.h>
> +#include <linux/platform_device.h>
> +#include <linux/remoteproc.h>
> +#include <linux/reset.h>
> +#include <linux/slab.h>
> +
> +#include "omap_remoteproc.h"
> +#include "remoteproc_internal.h"
> +#include "ti_sci_proc.h"
> +
> +#define K3_M4_IRAM_DEV_ADDR 0x00000
> +#define K3_M4_DRAM_DEV_ADDR 0x30000
> +
> +/**
> + * struct k3_m4_rproc_mem - internal memory structure
> + * @cpu_addr: MPU virtual address of the memory region
> + * @bus_addr: Bus address used to access the memory region
> + * @dev_addr: Device address of the memory region from remote processor view
> + * @size: Size of the memory region
> + */
> +struct k3_m4_rproc_mem {
> +	void __iomem *cpu_addr;
> +	phys_addr_t bus_addr;
> +	u32 dev_addr;
> +	size_t size;
> +};
> +
> +/**
> + * struct k3_m4_rproc_mem_data - memory definitions for a remote processor
> + * @name: name for this memory entry
> + * @dev_addr: device address for the memory entry
> + */
> +struct k3_m4_rproc_mem_data {
> +	const char *name;
> +	const u32 dev_addr;
> +};
> +
> +/**
> + * struct k3_m4_rproc - k3 remote processor driver structure
> + * @dev: cached device pointer
> + * @mem: internal memory regions data
> + * @num_mems: number of internal memory regions
> + * @rmem: reserved memory regions data
> + * @num_rmems: number of reserved memory regions
> + * @reset: reset control handle
> + * @tsp: TI-SCI processor control handle
> + * @ti_sci: TI-SCI handle
> + * @ti_sci_id: TI-SCI device identifier
> + * @mbox: mailbox channel handle
> + * @client: mailbox client to request the mailbox channel
> + */
> +struct k3_m4_rproc {
> +	struct device *dev;
> +	struct k3_m4_rproc_mem *mem;
> +	int num_mems;
> +	struct k3_m4_rproc_mem *rmem;
> +	int num_rmems;
> +	struct reset_control *reset;
> +	struct ti_sci_proc *tsp;
> +	const struct ti_sci_handle *ti_sci;
> +	u32 ti_sci_id;
> +	struct mbox_chan *mbox;
> +	struct mbox_client client;
> +};
> +
> +/**
> + * k3_m4_rproc_mbox_callback() - inbound mailbox message handler
> + * @client: mailbox client pointer used for requesting the mailbox channel
> + * @data: mailbox payload
> + *
> + * This handler is invoked by the K3 mailbox driver whenever a mailbox
> + * message is received. Usually, the mailbox payload simply contains
> + * the index of the virtqueue that is kicked by the remote processor,
> + * and we let remoteproc core handle it.
> + *
> + * In addition to virtqueue indices, we also have some out-of-band values
> + * that indicate different events. Those values are deliberately very
> + * large so they don't coincide with virtqueue indices.
> + */
> +static void k3_m4_rproc_mbox_callback(struct mbox_client *client, void *data)
> +{
> +	struct device *dev = client->dev;
> +	struct rproc *rproc = dev_get_drvdata(dev);
> +	u32 msg = (u32)(uintptr_t)(data);
> +
> +	dev_dbg(dev, "mbox msg: 0x%x\n", msg);
> +
> +	switch (msg) {
> +	case RP_MBOX_CRASH:
> +		/*
> +		 * remoteproc detected an exception, but error recovery is not
> +		 * supported. So, just log this for now
> +		 */
> +		dev_err(dev, "K3 rproc %s crashed\n", rproc->name);
> +		break;
> +	case RP_MBOX_ECHO_REPLY:
> +		dev_info(dev, "received echo reply from %s\n", rproc->name);
> +		break;
> +	default:
> +		/* silently handle all other valid messages */
> +		if (msg >= RP_MBOX_READY && msg < RP_MBOX_END_MSG)
> +			return;
> +		if (msg > rproc->max_notifyid) {
> +			dev_dbg(dev, "dropping unknown message 0x%x", msg);
> +			return;
> +		}
> +		/* msg contains the index of the triggered vring */
> +		if (rproc_vq_interrupt(rproc, msg) == IRQ_NONE)
> +			dev_dbg(dev, "no message was found in vqid %d\n", msg);
> +	}
> +}
> +
> +/*
> + * Kick the remote processor to notify about pending unprocessed messages.
> + * The vqid usage is not used and is inconsequential, as the kick is performed
> + * through a simulated GPIO (a bit in an IPC interrupt-triggering register),
> + * the remote processor is expected to process both its Tx and Rx virtqueues.
> + */
> +static void k3_m4_rproc_kick(struct rproc *rproc, int vqid)
> +{
> +	struct k3_m4_rproc *kproc = rproc->priv;
> +	struct device *dev = kproc->dev;
> +	u32 msg = (u32)vqid;
> +	int ret;
> +
> +	/*
> +	 * Send the index of the triggered virtqueue in the mailbox payload.
> +	 * NOTE: msg is cast to uintptr_t to prevent compiler warnings when
> +	 * void* is 64bit. It is safely cast back to u32 in the mailbox driver.
> +	 */
> +	ret = mbox_send_message(kproc->mbox, (void *)(uintptr_t)msg);
> +	if (ret < 0)
> +		dev_err(dev, "failed to send mailbox message, status = %d\n",
> +			ret);
> +}
> +
> +static int k3_m4_rproc_ping_mbox(struct k3_m4_rproc *kproc)
> +{
> +	struct device *dev = kproc->dev;
> +	int ret;
> +
> +	/*
> +	 * Ping the remote processor, this is only for sanity-sake for now;
> +	 * there is no functional effect whatsoever.
> +	 *
> +	 * Note that the reply will _not_ arrive immediately: this message
> +	 * will wait in the mailbox fifo until the remote processor is booted.
> +	 */
> +	ret = mbox_send_message(kproc->mbox, (void *)RP_MBOX_ECHO_REQUEST);
> +	if (ret < 0) {
> +		dev_err(dev, "mbox_send_message failed: %d\n", ret);
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +/*
> + * The M4 cores have a local reset that affects only the CPU, and a
> + * generic module reset that powers on the device and allows the internal
> + * memories to be accessed while the local reset is asserted. This function is
> + * used to release the global reset on remote cores to allow loading into the
> + * internal RAMs. The .prepare() ops is invoked by remoteproc core before any
> + * firmware loading, and is followed by the .start() ops after loading to
> + * actually let the remote cores to run.
> + */
> +static int k3_m4_rproc_prepare(struct rproc *rproc)
> +{
> +	struct k3_m4_rproc *kproc = rproc->priv;
> +	struct device *dev = kproc->dev;
> +	int ret;
> +
> +	/* If the core is running already no need to deassert the module reset */
> +	if (rproc->state == RPROC_DETACHED)
> +		return 0;
> +
> +	/*
> +	 * Ensure the local reset is asserted so the core doesn't
> +	 * execute bogus code when the module reset is released.
> +	 */
> +	ret = reset_control_assert(kproc->reset);
> +	if (ret) {
> +		dev_err(dev, "could not assert local reset\n");
> +		return ret;
> +	}
> +
> +	ret = reset_control_status(kproc->reset);
> +	if (ret <= 0) {
> +		dev_err(dev, "local reset still not asserted\n");
> +		return ret;
> +	}
> +
> +	ret = kproc->ti_sci->ops.dev_ops.get_device(kproc->ti_sci,
> +						    kproc->ti_sci_id);
> +	if (ret) {
> +		dev_err(dev, "could not deassert module-reset for internal RAM loading\n");
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +/*
> + * This function implements the .unprepare() ops and performs the complimentary
> + * operations to that of the .prepare() ops. The function is used to assert the
> + * global reset on applicable cores. This completes the second portion of
> + * powering down the remote core. The cores themselves are only halted in the
> + * .stop() callback through the local reset, and the .unprepare() ops is invoked
> + * by the remoteproc core after the remoteproc is stopped to balance the global
> + * reset.
> + */
> +static int k3_m4_rproc_unprepare(struct rproc *rproc)
> +{
> +	struct k3_m4_rproc *kproc = rproc->priv;
> +	struct device *dev = kproc->dev;
> +	int ret;
> +
> +	/* If the core is going to be detached do not assert the module reset */
> +	if (rproc->state == RPROC_ATTACHED)
> +		return 0;
> +
> +	ret = kproc->ti_sci->ops.dev_ops.put_device(kproc->ti_sci,
> +						    kproc->ti_sci_id);
> +	if (ret) {
> +		dev_err(dev, "module-reset assert failed\n");
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +/*
> + * This function implements the .get_loaded_rsc_table() callback and is used
> + * to provide the resource table for a booted remote processor in IPC-only
> + * mode. The remote processor firmwares follow a design-by-contract approach
> + * and are expected to have the resource table at the base of the DDR region
> + * reserved for firmware usage. This provides flexibility for the remote
> + * processor to be booted by different bootloaders that may or may not have the
> + * ability to publish the resource table address and size through a DT
> + * property.
> + */
> +static struct resource_table *k3_m4_get_loaded_rsc_table(struct rproc *rproc,
> +							 size_t *rsc_table_sz)
> +{
> +	struct k3_m4_rproc *kproc = rproc->priv;
> +	struct device *dev = kproc->dev;
> +
> +	if (!kproc->rmem[0].cpu_addr) {
> +		dev_err(dev, "memory-region #1 does not exist, loaded rsc table can't be found");
> +		return ERR_PTR(-ENOMEM);
> +	}
> +
> +	/*
> +	 * NOTE: The resource table size is currently hard-coded to a maximum
> +	 * of 256 bytes. The most common resource table usage for K3 firmwares
> +	 * is to only have the vdev resource entry and an optional trace entry.
> +	 * The exact size could be computed based on resource table address, but
> +	 * the hard-coded value suffices to support the IPC-only mode.
> +	 */
> +	*rsc_table_sz = 256;
> +	return (__force struct resource_table *)kproc->rmem[0].cpu_addr;
> +}
> +
> +/*
> + * Custom function to translate a remote processor device address (internal
> + * RAMs only) to a kernel virtual address.  The remote processors can access
> + * their RAMs at either an internal address visible only from a remote
> + * processor, or at the SoC-level bus address. Both these addresses need to be
> + * looked through for translation. The translated addresses can be used either
> + * by the remoteproc core for loading (when using kernel remoteproc loader), or
> + * by any rpmsg bus drivers.
> + */
> +static void *k3_m4_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> +{
> +	struct k3_m4_rproc *kproc = rproc->priv;
> +	void __iomem *va = NULL;
> +	phys_addr_t bus_addr;
> +	u32 dev_addr, offset;
> +	size_t size;
> +	int i;
> +
> +	if (len == 0)
> +		return NULL;
> +
> +	for (i = 0; i < kproc->num_mems; i++) {
> +		bus_addr = kproc->mem[i].bus_addr;
> +		dev_addr = kproc->mem[i].dev_addr;
> +		size = kproc->mem[i].size;
> +
> +		/* handle M4-view addresses */
> +		if (da >= dev_addr && ((da + len) <= (dev_addr + size))) {
> +			offset = da - dev_addr;
> +			va = kproc->mem[i].cpu_addr + offset;
> +			return (__force void *)va;
> +		}
> +
> +		/* handle SoC-view addresses */
> +		if (da >= bus_addr && ((da + len) <= (bus_addr + size))) {
> +			offset = da - bus_addr;
> +			va = kproc->mem[i].cpu_addr + offset;
> +			return (__force void *)va;
> +		}
> +	}
> +
> +	/* handle static DDR reserved memory regions */
> +	for (i = 0; i < kproc->num_rmems; i++) {
> +		dev_addr = kproc->rmem[i].dev_addr;
> +		size = kproc->rmem[i].size;
> +
> +		if (da >= dev_addr && ((da + len) <= (dev_addr + size))) {
> +			offset = da - dev_addr;
> +			va = kproc->rmem[i].cpu_addr + offset;
> +			return (__force void *)va;
> +		}
> +	}
> +
> +	return NULL;
> +}
> +
> +static int k3_m4_rproc_of_get_memories(struct platform_device *pdev,
> +				       struct k3_m4_rproc *kproc)
> +{
> +	static const char * const mem_names[] = { "iram", "dram" };
> +	static const u32 mem_addrs[] = { K3_M4_IRAM_DEV_ADDR, K3_M4_DRAM_DEV_ADDR };
> +	struct device *dev = &pdev->dev;
> +	struct resource *res;
> +	int num_mems;
> +	int i;
> +
> +	num_mems = ARRAY_SIZE(mem_names);
> +	kproc->mem = devm_kcalloc(kproc->dev, num_mems,
> +				  sizeof(*kproc->mem), GFP_KERNEL);
> +	if (!kproc->mem)
> +		return -ENOMEM;
> +
> +	for (i = 0; i < num_mems; i++) {
> +		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> +						   mem_names[i]);
> +		if (!res) {
> +			dev_err(dev, "found no memory resource for %s\n",
> +				mem_names[i]);
> +			return -EINVAL;
> +		}
> +		if (!devm_request_mem_region(dev, res->start,
> +					     resource_size(res),
> +					     dev_name(dev))) {
> +			dev_err(dev, "could not request %s region for resource\n",
> +				mem_names[i]);
> +			return -EBUSY;
> +		}
> +
> +		kproc->mem[i].cpu_addr = devm_ioremap_wc(dev, res->start,
> +							 resource_size(res));
> +		if (!kproc->mem[i].cpu_addr) {
> +			dev_err(dev, "failed to map %s memory\n",
> +				mem_names[i]);
> +			return -ENOMEM;
> +		}
> +		kproc->mem[i].bus_addr = res->start;
> +		kproc->mem[i].dev_addr = mem_addrs[i];
> +		kproc->mem[i].size = resource_size(res);
> +
> +		dev_dbg(dev, "memory %8s: bus addr %pa size 0x%zx va %pK da 0x%x\n",
> +			mem_names[i], &kproc->mem[i].bus_addr,
> +			kproc->mem[i].size, kproc->mem[i].cpu_addr,
> +			kproc->mem[i].dev_addr);
> +	}
> +	kproc->num_mems = num_mems;
> +
> +	return 0;
> +}
> +
> +static void k3_m4_rproc_dev_mem_release(void *data)
> +{
> +	struct device *dev = data;
> +
> +	of_reserved_mem_device_release(dev);
> +}
> +
> +static int k3_m4_reserved_mem_init(struct k3_m4_rproc *kproc)
> +{
> +	struct device *dev = kproc->dev;
> +	struct device_node *np = dev->of_node;
> +	struct device_node *rmem_np;
> +	struct reserved_mem *rmem;
> +	int num_rmems;
> +	int ret, i;
> +
> +	num_rmems = of_property_count_elems_of_size(np, "memory-region",
> +						    sizeof(phandle));
> +	if (num_rmems < 0) {
> +		dev_err(dev, "device does not reserved memory regions (%d)\n",
> +			num_rmems);
> +		return -EINVAL;
> +	}
> +	if (num_rmems < 2) {
> +		dev_err(dev, "device needs at least two memory regions to be defined, num = %d\n",
> +			num_rmems);
> +		return -EINVAL;
> +	}
> +
> +	/* use reserved memory region 0 for vring DMA allocations */
> +	ret = of_reserved_mem_device_init_by_idx(dev, np, 0);
> +	if (ret) {
> +		dev_err(dev, "device cannot initialize DMA pool (%d)\n", ret);
> +		return ret;
> +	}
> +	ret = devm_add_action_or_reset(dev, k3_m4_rproc_dev_mem_release, dev);
> +	if (ret)
> +		return ret;
> +
> +	num_rmems--;
> +	kproc->rmem = devm_kcalloc(dev, num_rmems, sizeof(*kproc->rmem), GFP_KERNEL);
> +	if (!kproc->rmem)
> +		return -ENOMEM;
> +
> +	/* use remaining reserved memory regions for static carveouts */
> +	for (i = 0; i < num_rmems; i++) {
> +		rmem_np = of_parse_phandle(np, "memory-region", i + 1);
> +		if (!rmem_np)
> +			return -EINVAL;
> +
> +		rmem = of_reserved_mem_lookup(rmem_np);
> +		if (!rmem) {
> +			of_node_put(rmem_np);
> +			return -EINVAL;
> +		}
> +		of_node_put(rmem_np);
> +
> +		kproc->rmem[i].bus_addr = rmem->base;
> +		/* 64-bit address regions currently not supported */
> +		kproc->rmem[i].dev_addr = (u32)rmem->base;
> +		kproc->rmem[i].size = rmem->size;
> +		kproc->rmem[i].cpu_addr = devm_ioremap_wc(dev, rmem->base, rmem->size);
> +		if (!kproc->rmem[i].cpu_addr) {
> +			dev_err(dev, "failed to map reserved memory#%d at %pa of size %pa\n",
> +				i + 1, &rmem->base, &rmem->size);
> +			return -ENOMEM;
> +		}
> +
> +		dev_dbg(dev, "reserved memory%d: bus addr %pa size 0x%zx va %pK da 0x%x\n",
> +			i + 1, &kproc->rmem[i].bus_addr,
> +			kproc->rmem[i].size, kproc->rmem[i].cpu_addr,
> +			kproc->rmem[i].dev_addr);
> +	}
> +	kproc->num_rmems = num_rmems;
> +
> +	return 0;
> +}
> +
> +static void k3_m4_release_tsp(void *data)
> +{
> +	struct ti_sci_proc *tsp = data;
> +
> +	ti_sci_proc_release(tsp);
> +}
> +
> +/*
> + * Power up the M4 remote processor.
> + *
> + * This function will be invoked only after the firmware for this rproc
> + * was loaded, parsed successfully, and all of its resource requirements
> + * were met. This callback is invoked only in remoteproc mode.
> + */
> +static int k3_m4_rproc_start(struct rproc *rproc)
> +{
> +	struct k3_m4_rproc *kproc = rproc->priv;
> +	struct device *dev = kproc->dev;
> +	int ret;
> +
> +	ret = k3_m4_rproc_ping_mbox(kproc);
> +	if (ret)
> +		return ret;
> +
> +	ret = reset_control_deassert(kproc->reset);
> +	if (ret) {
> +		dev_err(dev, "local-reset deassert failed, ret = %d\n", ret);
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +/*
> + * Stop the M4 remote processor.
> + *
> + * This function puts the M4 processor into reset, and finishes processing
> + * of any pending messages. This callback is invoked only in remoteproc mode.
> + */
> +static int k3_m4_rproc_stop(struct rproc *rproc)
> +{
> +	struct k3_m4_rproc *kproc = rproc->priv;
> +	struct device *dev = kproc->dev;
> +	int ret;
> +
> +	ret = reset_control_assert(kproc->reset);
> +	if (ret) {
> +		dev_err(dev, "local-reset assert failed, ret = %d\n", ret);
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +/*
> + * Attach to a running M4 remote processor (IPC-only mode)
> + *
> + * The remote processor is already booted, so there is no need to issue any
> + * TI-SCI commands to boot the M4 core. This callback is used only in IPC-only
> + * mode.
> + */
> +static int k3_m4_rproc_attach(struct rproc *rproc)
> +{
> +	struct k3_m4_rproc *kproc = rproc->priv;
> +	int ret;
> +
> +	ret = k3_m4_rproc_ping_mbox(kproc);
> +	if (ret)
> +		return ret;
> +
> +	return 0;
> +}
> +
> +/*
> + * Detach from a running M4 remote processor (IPC-only mode)
> + *
> + * This rproc detach callback performs the opposite operation to attach
> + * callback, the M4 core is not stopped and will be left to continue to
> + * run its booted firmware. This callback is invoked only in IPC-only mode.
> + */
> +static int k3_m4_rproc_detach(struct rproc *rproc)
> +{
> +	return 0;
> +}

Please remove.

Other than the above I'm good with this driver.  That said I can't move forward
without a nod from the DT crew.  I also noticed a fair amount of code
duplication with the k3_r5 and k3_dsp drivers.  Dealing with that should not be
part of the current work but will need to be done before another k3 driver can
be merged.

Thanks,
Mathieu

> +
> +static const struct rproc_ops k3_m4_rproc_ops = {
> +	.prepare = k3_m4_rproc_prepare,
> +	.unprepare = k3_m4_rproc_unprepare,
> +	.start = k3_m4_rproc_start,
> +	.stop = k3_m4_rproc_stop,
> +	.attach = k3_m4_rproc_attach,
> +	.detach = k3_m4_rproc_detach,
> +	.kick = k3_m4_rproc_kick,
> +	.da_to_va = k3_m4_rproc_da_to_va,
> +	.get_loaded_rsc_table = k3_m4_get_loaded_rsc_table,
> +};
> +
> +static int k3_m4_rproc_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct k3_m4_rproc *kproc;
> +	struct rproc *rproc;
> +	const char *fw_name;
> +	bool r_state = false;
> +	bool p_state = false;
> +	int ret;
> +
> +	ret = rproc_of_parse_firmware(dev, 0, &fw_name);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "failed to parse firmware-name property\n");
> +
> +	rproc = devm_rproc_alloc(dev, dev_name(dev), &k3_m4_rproc_ops, fw_name,
> +				 sizeof(*kproc));
> +	if (!rproc)
> +		return -ENOMEM;
> +
> +	rproc->has_iommu = false;
> +	rproc->recovery_disabled = true;
> +	kproc = rproc->priv;
> +	kproc->dev = dev;
> +	platform_set_drvdata(pdev, rproc);
> +
> +	kproc->ti_sci = devm_ti_sci_get_by_phandle(dev, "ti,sci");
> +	if (IS_ERR(kproc->ti_sci))
> +		return dev_err_probe(dev, PTR_ERR(kproc->ti_sci),
> +				     "failed to get ti-sci handle\n");
> +
> +	ret = of_property_read_u32(dev->of_node, "ti,sci-dev-id", &kproc->ti_sci_id);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "missing 'ti,sci-dev-id' property\n");
> +
> +	kproc->reset = devm_reset_control_get_exclusive(dev, NULL);
> +	if (IS_ERR(kproc->reset))
> +		return dev_err_probe(dev, PTR_ERR(kproc->reset), "failed to get reset\n");
> +
> +	kproc->tsp = ti_sci_proc_of_get_tsp(dev, kproc->ti_sci);
> +	if (IS_ERR(kproc->tsp))
> +		return dev_err_probe(dev, PTR_ERR(kproc->tsp),
> +				     "failed to construct ti-sci proc control\n");
> +
> +	ret = ti_sci_proc_request(kproc->tsp);
> +	if (ret < 0)
> +		return dev_err_probe(dev, ret, "ti_sci_proc_request failed\n");
> +	ret = devm_add_action_or_reset(dev, k3_m4_release_tsp, kproc->tsp);
> +	if (ret)
> +		return ret;
> +
> +	ret = k3_m4_rproc_of_get_memories(pdev, kproc);
> +	if (ret)
> +		return ret;
> +
> +	ret = k3_m4_reserved_mem_init(kproc);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "reserved memory init failed\n");
> +
> +	ret = kproc->ti_sci->ops.dev_ops.is_on(kproc->ti_sci, kproc->ti_sci_id,
> +					       &r_state, &p_state);
> +	if (ret)
> +		return dev_err_probe(dev, ret,
> +				     "failed to get initial state, mode cannot be determined\n");
> +
> +	/* configure devices for either remoteproc or IPC-only mode */
> +	if (p_state) {
> +		rproc->state = RPROC_DETACHED;
> +		dev_info(dev, "configured M4F for IPC-only mode\n");
> +	} else {
> +		dev_info(dev, "configured M4F for remoteproc mode\n");
> +	}
> +
> +	kproc->client.dev = dev;
> +	kproc->client.tx_done = NULL;
> +	kproc->client.rx_callback = k3_m4_rproc_mbox_callback;
> +	kproc->client.tx_block = false;
> +	kproc->client.knows_txdone = false;
> +	kproc->mbox = mbox_request_channel(&kproc->client, 0);
> +	if (IS_ERR(kproc->mbox))
> +		return dev_err_probe(dev, PTR_ERR(kproc->mbox),
> +				     "mbox_request_channel failed\n");
> +
> +	ret = devm_rproc_add(dev, rproc);
> +	if (ret)
> +		return dev_err_probe(dev, ret,
> +				     "failed to register device with remoteproc core\n");
> +
> +	return 0;
> +}
> +
> +static const struct of_device_id k3_m4_of_match[] = {
> +	{ .compatible = "ti,am64-m4fss", },
> +	{ /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, k3_m4_of_match);
> +
> +static struct platform_driver k3_m4_rproc_driver = {
> +	.probe	= k3_m4_rproc_probe,
> +	.driver	= {
> +		.name = "k3-m4-rproc",
> +		.of_match_table = k3_m4_of_match,
> +	},
> +};
> +module_platform_driver(k3_m4_rproc_driver);
> +
> +MODULE_AUTHOR("Hari Nagalla <hnagalla@ti.com>");
> +MODULE_DESCRIPTION("TI K3 M4 Remoteproc driver");
> +MODULE_LICENSE("GPL");
> -- 
> 2.39.2
> 

Re: [PATCH v11 3/9] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem

[Mathieu Poirier]

On Thu, Aug 15, 2024 at 10:46:41AM -0600, Mathieu Poirier wrote:
> Hi,
> 
> On Fri, Aug 02, 2024 at 10:21:03AM -0500, Andrew Davis wrote:
> > From: Martyn Welch <martyn.welch@collabora.com>
> > 
> > The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
> > the MCU domain. This core is typically used for safety applications in a
> > stand alone mode. However, some application (non safety related) may
> > want to use the M4F core as a generic remote processor with IPC to the
> > host processor. The M4F core has internal IRAM and DRAM memories and are
> > exposed to the system bus for code and data loading.
> > 
> > A remote processor driver is added to support this subsystem, including
> > being able to load and boot the M4F core. Loading includes to M4F
> > internal memories and predefined external code/data memories. The
> > carve outs for external contiguous memory is defined in the M4F device
> > node and should match with the external memory declarations in the M4F
> > image binary. The M4F subsystem has two resets. One reset is for the
> > entire subsystem i.e including the internal memories and the other, a
> > local reset is only for the M4F processing core. When loading the image,
> > the driver first releases the subsystem reset, loads the firmware image
> > and then releases the local reset to let the M4F processing core run.
> > 
> > Signed-off-by: Martyn Welch <martyn.welch@collabora.com>
> > Signed-off-by: Hari Nagalla <hnagalla@ti.com>
> > Signed-off-by: Andrew Davis <afd@ti.com>
> > ---
> >  drivers/remoteproc/Kconfig               |  13 +
> >  drivers/remoteproc/Makefile              |   1 +
> >  drivers/remoteproc/ti_k3_m4_remoteproc.c | 667 +++++++++++++++++++++++
> >  3 files changed, 681 insertions(+)
> >  create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
> > 
> > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > index dda2ada215b7c..0f0862e20a932 100644
> > --- a/drivers/remoteproc/Kconfig
> > +++ b/drivers/remoteproc/Kconfig
> > @@ -340,6 +340,19 @@ config TI_K3_DSP_REMOTEPROC
> >  	  It's safe to say N here if you're not interested in utilizing
> >  	  the DSP slave processors.
> >  
> > +config TI_K3_M4_REMOTEPROC
> > +	tristate "TI K3 M4 remoteproc support"
> > +	depends on ARCH_K3 || COMPILE_TEST
> > +	select MAILBOX
> > +	select OMAP2PLUS_MBOX
> > +	help
> > +	  Say m here to support TI's M4 remote processor subsystems
> > +	  on various TI K3 family of SoCs through the remote processor
> > +	  framework.
> > +
> > +	  It's safe to say N here if you're not interested in utilizing
> > +	  a remote processor.
> > +
> >  config TI_K3_R5_REMOTEPROC
> >  	tristate "TI K3 R5 remoteproc support"
> >  	depends on ARCH_K3
> > diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> > index 91314a9b43cef..5ff4e2fee4abd 100644
> > --- a/drivers/remoteproc/Makefile
> > +++ b/drivers/remoteproc/Makefile
> > @@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC)		+= st_remoteproc.o
> >  obj-$(CONFIG_ST_SLIM_REMOTEPROC)	+= st_slim_rproc.o
> >  obj-$(CONFIG_STM32_RPROC)		+= stm32_rproc.o
> >  obj-$(CONFIG_TI_K3_DSP_REMOTEPROC)	+= ti_k3_dsp_remoteproc.o
> > +obj-$(CONFIG_TI_K3_M4_REMOTEPROC)	+= ti_k3_m4_remoteproc.o
> >  obj-$(CONFIG_TI_K3_R5_REMOTEPROC)	+= ti_k3_r5_remoteproc.o
> >  obj-$(CONFIG_XLNX_R5_REMOTEPROC)	+= xlnx_r5_remoteproc.o
> > diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c b/drivers/remoteproc/ti_k3_m4_remoteproc.c
> > new file mode 100644
> > index 0000000000000..09f0484a90e10
> > --- /dev/null
> > +++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
> > @@ -0,0 +1,667 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * TI K3 Cortex-M4 Remote Processor(s) driver
> > + *
> > + * Copyright (C) 2021-2024 Texas Instruments Incorporated - https://www.ti.com/
> > + *	Hari Nagalla <hnagalla@ti.com>
> > + */
> > +
> > +#include <linux/io.h>
> > +#include <linux/mailbox_client.h>
> > +#include <linux/module.h>
> > +#include <linux/of_address.h>
> > +#include <linux/of_reserved_mem.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/remoteproc.h>
> > +#include <linux/reset.h>
> > +#include <linux/slab.h>
> > +
> > +#include "omap_remoteproc.h"
> > +#include "remoteproc_internal.h"
> > +#include "ti_sci_proc.h"
> > +
> > +#define K3_M4_IRAM_DEV_ADDR 0x00000
> > +#define K3_M4_DRAM_DEV_ADDR 0x30000
> > +
> > +/**
> > + * struct k3_m4_rproc_mem - internal memory structure
> > + * @cpu_addr: MPU virtual address of the memory region
> > + * @bus_addr: Bus address used to access the memory region
> > + * @dev_addr: Device address of the memory region from remote processor view
> > + * @size: Size of the memory region
> > + */
> > +struct k3_m4_rproc_mem {
> > +	void __iomem *cpu_addr;
> > +	phys_addr_t bus_addr;
> > +	u32 dev_addr;
> > +	size_t size;
> > +};
> > +
> > +/**
> > + * struct k3_m4_rproc_mem_data - memory definitions for a remote processor
> > + * @name: name for this memory entry
> > + * @dev_addr: device address for the memory entry
> > + */
> > +struct k3_m4_rproc_mem_data {
> > +	const char *name;
> > +	const u32 dev_addr;
> > +};
> > +
> > +/**
> > + * struct k3_m4_rproc - k3 remote processor driver structure
> > + * @dev: cached device pointer
> > + * @mem: internal memory regions data
> > + * @num_mems: number of internal memory regions
> > + * @rmem: reserved memory regions data
> > + * @num_rmems: number of reserved memory regions
> > + * @reset: reset control handle
> > + * @tsp: TI-SCI processor control handle
> > + * @ti_sci: TI-SCI handle
> > + * @ti_sci_id: TI-SCI device identifier
> > + * @mbox: mailbox channel handle
> > + * @client: mailbox client to request the mailbox channel
> > + */
> > +struct k3_m4_rproc {
> > +	struct device *dev;
> > +	struct k3_m4_rproc_mem *mem;
> > +	int num_mems;
> > +	struct k3_m4_rproc_mem *rmem;
> > +	int num_rmems;
> > +	struct reset_control *reset;
> > +	struct ti_sci_proc *tsp;
> > +	const struct ti_sci_handle *ti_sci;
> > +	u32 ti_sci_id;
> > +	struct mbox_chan *mbox;
> > +	struct mbox_client client;
> > +};
> > +
> > +/**
> > + * k3_m4_rproc_mbox_callback() - inbound mailbox message handler
> > + * @client: mailbox client pointer used for requesting the mailbox channel
> > + * @data: mailbox payload
> > + *
> > + * This handler is invoked by the K3 mailbox driver whenever a mailbox
> > + * message is received. Usually, the mailbox payload simply contains
> > + * the index of the virtqueue that is kicked by the remote processor,
> > + * and we let remoteproc core handle it.
> > + *
> > + * In addition to virtqueue indices, we also have some out-of-band values
> > + * that indicate different events. Those values are deliberately very
> > + * large so they don't coincide with virtqueue indices.
> > + */
> > +static void k3_m4_rproc_mbox_callback(struct mbox_client *client, void *data)
> > +{
> > +	struct device *dev = client->dev;
> > +	struct rproc *rproc = dev_get_drvdata(dev);
> > +	u32 msg = (u32)(uintptr_t)(data);
> > +
> > +	dev_dbg(dev, "mbox msg: 0x%x\n", msg);
> > +
> > +	switch (msg) {
> > +	case RP_MBOX_CRASH:
> > +		/*
> > +		 * remoteproc detected an exception, but error recovery is not
> > +		 * supported. So, just log this for now
> > +		 */
> > +		dev_err(dev, "K3 rproc %s crashed\n", rproc->name);
> > +		break;
> > +	case RP_MBOX_ECHO_REPLY:
> > +		dev_info(dev, "received echo reply from %s\n", rproc->name);
> > +		break;
> > +	default:
> > +		/* silently handle all other valid messages */
> > +		if (msg >= RP_MBOX_READY && msg < RP_MBOX_END_MSG)
> > +			return;
> > +		if (msg > rproc->max_notifyid) {
> > +			dev_dbg(dev, "dropping unknown message 0x%x", msg);
> > +			return;
> > +		}
> > +		/* msg contains the index of the triggered vring */
> > +		if (rproc_vq_interrupt(rproc, msg) == IRQ_NONE)
> > +			dev_dbg(dev, "no message was found in vqid %d\n", msg);
> > +	}
> > +}
> > +
> > +/*
> > + * Kick the remote processor to notify about pending unprocessed messages.
> > + * The vqid usage is not used and is inconsequential, as the kick is performed
> > + * through a simulated GPIO (a bit in an IPC interrupt-triggering register),
> > + * the remote processor is expected to process both its Tx and Rx virtqueues.
> > + */
> > +static void k3_m4_rproc_kick(struct rproc *rproc, int vqid)
> > +{
> > +	struct k3_m4_rproc *kproc = rproc->priv;
> > +	struct device *dev = kproc->dev;
> > +	u32 msg = (u32)vqid;
> > +	int ret;
> > +
> > +	/*
> > +	 * Send the index of the triggered virtqueue in the mailbox payload.
> > +	 * NOTE: msg is cast to uintptr_t to prevent compiler warnings when
> > +	 * void* is 64bit. It is safely cast back to u32 in the mailbox driver.
> > +	 */
> > +	ret = mbox_send_message(kproc->mbox, (void *)(uintptr_t)msg);
> > +	if (ret < 0)
> > +		dev_err(dev, "failed to send mailbox message, status = %d\n",
> > +			ret);
> > +}
> > +
> > +static int k3_m4_rproc_ping_mbox(struct k3_m4_rproc *kproc)
> > +{
> > +	struct device *dev = kproc->dev;
> > +	int ret;
> > +
> > +	/*
> > +	 * Ping the remote processor, this is only for sanity-sake for now;
> > +	 * there is no functional effect whatsoever.
> > +	 *
> > +	 * Note that the reply will _not_ arrive immediately: this message
> > +	 * will wait in the mailbox fifo until the remote processor is booted.
> > +	 */
> > +	ret = mbox_send_message(kproc->mbox, (void *)RP_MBOX_ECHO_REQUEST);
> > +	if (ret < 0) {
> > +		dev_err(dev, "mbox_send_message failed: %d\n", ret);
> > +		return ret;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +/*
> > + * The M4 cores have a local reset that affects only the CPU, and a
> > + * generic module reset that powers on the device and allows the internal
> > + * memories to be accessed while the local reset is asserted. This function is
> > + * used to release the global reset on remote cores to allow loading into the
> > + * internal RAMs. The .prepare() ops is invoked by remoteproc core before any
> > + * firmware loading, and is followed by the .start() ops after loading to
> > + * actually let the remote cores to run.
> > + */
> > +static int k3_m4_rproc_prepare(struct rproc *rproc)
> > +{
> > +	struct k3_m4_rproc *kproc = rproc->priv;
> > +	struct device *dev = kproc->dev;
> > +	int ret;
> > +
> > +	/* If the core is running already no need to deassert the module reset */
> > +	if (rproc->state == RPROC_DETACHED)
> > +		return 0;
> > +
> > +	/*
> > +	 * Ensure the local reset is asserted so the core doesn't
> > +	 * execute bogus code when the module reset is released.
> > +	 */
> > +	ret = reset_control_assert(kproc->reset);
> > +	if (ret) {
> > +		dev_err(dev, "could not assert local reset\n");
> > +		return ret;
> > +	}
> > +
> > +	ret = reset_control_status(kproc->reset);
> > +	if (ret <= 0) {
> > +		dev_err(dev, "local reset still not asserted\n");
> > +		return ret;
> > +	}
> > +
> > +	ret = kproc->ti_sci->ops.dev_ops.get_device(kproc->ti_sci,
> > +						    kproc->ti_sci_id);
> > +	if (ret) {
> > +		dev_err(dev, "could not deassert module-reset for internal RAM loading\n");
> > +		return ret;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +/*
> > + * This function implements the .unprepare() ops and performs the complimentary
> > + * operations to that of the .prepare() ops. The function is used to assert the
> > + * global reset on applicable cores. This completes the second portion of
> > + * powering down the remote core. The cores themselves are only halted in the
> > + * .stop() callback through the local reset, and the .unprepare() ops is invoked
> > + * by the remoteproc core after the remoteproc is stopped to balance the global
> > + * reset.
> > + */
> > +static int k3_m4_rproc_unprepare(struct rproc *rproc)
> > +{
> > +	struct k3_m4_rproc *kproc = rproc->priv;
> > +	struct device *dev = kproc->dev;
> > +	int ret;
> > +
> > +	/* If the core is going to be detached do not assert the module reset */
> > +	if (rproc->state == RPROC_ATTACHED)
> > +		return 0;
> > +
> > +	ret = kproc->ti_sci->ops.dev_ops.put_device(kproc->ti_sci,
> > +						    kproc->ti_sci_id);
> > +	if (ret) {
> > +		dev_err(dev, "module-reset assert failed\n");
> > +		return ret;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +/*
> > + * This function implements the .get_loaded_rsc_table() callback and is used
> > + * to provide the resource table for a booted remote processor in IPC-only
> > + * mode. The remote processor firmwares follow a design-by-contract approach
> > + * and are expected to have the resource table at the base of the DDR region
> > + * reserved for firmware usage. This provides flexibility for the remote
> > + * processor to be booted by different bootloaders that may or may not have the
> > + * ability to publish the resource table address and size through a DT
> > + * property.
> > + */
> > +static struct resource_table *k3_m4_get_loaded_rsc_table(struct rproc *rproc,
> > +							 size_t *rsc_table_sz)
> > +{
> > +	struct k3_m4_rproc *kproc = rproc->priv;
> > +	struct device *dev = kproc->dev;
> > +
> > +	if (!kproc->rmem[0].cpu_addr) {
> > +		dev_err(dev, "memory-region #1 does not exist, loaded rsc table can't be found");
> > +		return ERR_PTR(-ENOMEM);
> > +	}
> > +
> > +	/*
> > +	 * NOTE: The resource table size is currently hard-coded to a maximum
> > +	 * of 256 bytes. The most common resource table usage for K3 firmwares
> > +	 * is to only have the vdev resource entry and an optional trace entry.
> > +	 * The exact size could be computed based on resource table address, but
> > +	 * the hard-coded value suffices to support the IPC-only mode.
> > +	 */
> > +	*rsc_table_sz = 256;
> > +	return (__force struct resource_table *)kproc->rmem[0].cpu_addr;
> > +}
> > +
> > +/*
> > + * Custom function to translate a remote processor device address (internal
> > + * RAMs only) to a kernel virtual address.  The remote processors can access
> > + * their RAMs at either an internal address visible only from a remote
> > + * processor, or at the SoC-level bus address. Both these addresses need to be
> > + * looked through for translation. The translated addresses can be used either
> > + * by the remoteproc core for loading (when using kernel remoteproc loader), or
> > + * by any rpmsg bus drivers.
> > + */
> > +static void *k3_m4_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> > +{
> > +	struct k3_m4_rproc *kproc = rproc->priv;
> > +	void __iomem *va = NULL;
> > +	phys_addr_t bus_addr;
> > +	u32 dev_addr, offset;
> > +	size_t size;
> > +	int i;
> > +
> > +	if (len == 0)
> > +		return NULL;
> > +
> > +	for (i = 0; i < kproc->num_mems; i++) {
> > +		bus_addr = kproc->mem[i].bus_addr;
> > +		dev_addr = kproc->mem[i].dev_addr;
> > +		size = kproc->mem[i].size;
> > +
> > +		/* handle M4-view addresses */
> > +		if (da >= dev_addr && ((da + len) <= (dev_addr + size))) {
> > +			offset = da - dev_addr;
> > +			va = kproc->mem[i].cpu_addr + offset;
> > +			return (__force void *)va;
> > +		}
> > +
> > +		/* handle SoC-view addresses */
> > +		if (da >= bus_addr && ((da + len) <= (bus_addr + size))) {
> > +			offset = da - bus_addr;
> > +			va = kproc->mem[i].cpu_addr + offset;
> > +			return (__force void *)va;
> > +		}
> > +	}
> > +
> > +	/* handle static DDR reserved memory regions */
> > +	for (i = 0; i < kproc->num_rmems; i++) {
> > +		dev_addr = kproc->rmem[i].dev_addr;
> > +		size = kproc->rmem[i].size;
> > +
> > +		if (da >= dev_addr && ((da + len) <= (dev_addr + size))) {
> > +			offset = da - dev_addr;
> > +			va = kproc->rmem[i].cpu_addr + offset;
> > +			return (__force void *)va;
> > +		}
> > +	}
> > +
> > +	return NULL;
> > +}
> > +
> > +static int k3_m4_rproc_of_get_memories(struct platform_device *pdev,
> > +				       struct k3_m4_rproc *kproc)
> > +{
> > +	static const char * const mem_names[] = { "iram", "dram" };
> > +	static const u32 mem_addrs[] = { K3_M4_IRAM_DEV_ADDR, K3_M4_DRAM_DEV_ADDR };
> > +	struct device *dev = &pdev->dev;
> > +	struct resource *res;
> > +	int num_mems;
> > +	int i;
> > +
> > +	num_mems = ARRAY_SIZE(mem_names);
> > +	kproc->mem = devm_kcalloc(kproc->dev, num_mems,
> > +				  sizeof(*kproc->mem), GFP_KERNEL);
> > +	if (!kproc->mem)
> > +		return -ENOMEM;
> > +
> > +	for (i = 0; i < num_mems; i++) {
> > +		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > +						   mem_names[i]);
> > +		if (!res) {
> > +			dev_err(dev, "found no memory resource for %s\n",
> > +				mem_names[i]);
> > +			return -EINVAL;
> > +		}
> > +		if (!devm_request_mem_region(dev, res->start,
> > +					     resource_size(res),
> > +					     dev_name(dev))) {
> > +			dev_err(dev, "could not request %s region for resource\n",
> > +				mem_names[i]);
> > +			return -EBUSY;
> > +		}
> > +
> > +		kproc->mem[i].cpu_addr = devm_ioremap_wc(dev, res->start,
> > +							 resource_size(res));
> > +		if (!kproc->mem[i].cpu_addr) {
> > +			dev_err(dev, "failed to map %s memory\n",
> > +				mem_names[i]);
> > +			return -ENOMEM;
> > +		}
> > +		kproc->mem[i].bus_addr = res->start;
> > +		kproc->mem[i].dev_addr = mem_addrs[i];
> > +		kproc->mem[i].size = resource_size(res);
> > +
> > +		dev_dbg(dev, "memory %8s: bus addr %pa size 0x%zx va %pK da 0x%x\n",
> > +			mem_names[i], &kproc->mem[i].bus_addr,
> > +			kproc->mem[i].size, kproc->mem[i].cpu_addr,
> > +			kproc->mem[i].dev_addr);
> > +	}
> > +	kproc->num_mems = num_mems;
> > +
> > +	return 0;
> > +}
> > +
> > +static void k3_m4_rproc_dev_mem_release(void *data)
> > +{
> > +	struct device *dev = data;
> > +
> > +	of_reserved_mem_device_release(dev);
> > +}
> > +
> > +static int k3_m4_reserved_mem_init(struct k3_m4_rproc *kproc)
> > +{
> > +	struct device *dev = kproc->dev;
> > +	struct device_node *np = dev->of_node;
> > +	struct device_node *rmem_np;
> > +	struct reserved_mem *rmem;
> > +	int num_rmems;
> > +	int ret, i;
> > +
> > +	num_rmems = of_property_count_elems_of_size(np, "memory-region",
> > +						    sizeof(phandle));
> > +	if (num_rmems < 0) {
> > +		dev_err(dev, "device does not reserved memory regions (%d)\n",
> > +			num_rmems);
> > +		return -EINVAL;
> > +	}
> > +	if (num_rmems < 2) {
> > +		dev_err(dev, "device needs at least two memory regions to be defined, num = %d\n",
> > +			num_rmems);
> > +		return -EINVAL;
> > +	}
> > +
> > +	/* use reserved memory region 0 for vring DMA allocations */
> > +	ret = of_reserved_mem_device_init_by_idx(dev, np, 0);
> > +	if (ret) {
> > +		dev_err(dev, "device cannot initialize DMA pool (%d)\n", ret);
> > +		return ret;
> > +	}
> > +	ret = devm_add_action_or_reset(dev, k3_m4_rproc_dev_mem_release, dev);
> > +	if (ret)
> > +		return ret;
> > +
> > +	num_rmems--;
> > +	kproc->rmem = devm_kcalloc(dev, num_rmems, sizeof(*kproc->rmem), GFP_KERNEL);
> > +	if (!kproc->rmem)
> > +		return -ENOMEM;
> > +
> > +	/* use remaining reserved memory regions for static carveouts */
> > +	for (i = 0; i < num_rmems; i++) {
> > +		rmem_np = of_parse_phandle(np, "memory-region", i + 1);
> > +		if (!rmem_np)
> > +			return -EINVAL;
> > +
> > +		rmem = of_reserved_mem_lookup(rmem_np);
> > +		if (!rmem) {
> > +			of_node_put(rmem_np);
> > +			return -EINVAL;
> > +		}
> > +		of_node_put(rmem_np);
> > +
> > +		kproc->rmem[i].bus_addr = rmem->base;
> > +		/* 64-bit address regions currently not supported */
> > +		kproc->rmem[i].dev_addr = (u32)rmem->base;
> > +		kproc->rmem[i].size = rmem->size;
> > +		kproc->rmem[i].cpu_addr = devm_ioremap_wc(dev, rmem->base, rmem->size);
> > +		if (!kproc->rmem[i].cpu_addr) {
> > +			dev_err(dev, "failed to map reserved memory#%d at %pa of size %pa\n",
> > +				i + 1, &rmem->base, &rmem->size);
> > +			return -ENOMEM;
> > +		}
> > +
> > +		dev_dbg(dev, "reserved memory%d: bus addr %pa size 0x%zx va %pK da 0x%x\n",
> > +			i + 1, &kproc->rmem[i].bus_addr,
> > +			kproc->rmem[i].size, kproc->rmem[i].cpu_addr,
> > +			kproc->rmem[i].dev_addr);
> > +	}
> > +	kproc->num_rmems = num_rmems;
> > +
> > +	return 0;
> > +}
> > +
> > +static void k3_m4_release_tsp(void *data)
> > +{
> > +	struct ti_sci_proc *tsp = data;
> > +
> > +	ti_sci_proc_release(tsp);
> > +}
> > +
> > +/*
> > + * Power up the M4 remote processor.
> > + *
> > + * This function will be invoked only after the firmware for this rproc
> > + * was loaded, parsed successfully, and all of its resource requirements
> > + * were met. This callback is invoked only in remoteproc mode.
> > + */
> > +static int k3_m4_rproc_start(struct rproc *rproc)
> > +{
> > +	struct k3_m4_rproc *kproc = rproc->priv;
> > +	struct device *dev = kproc->dev;
> > +	int ret;
> > +
> > +	ret = k3_m4_rproc_ping_mbox(kproc);
> > +	if (ret)
> > +		return ret;
> > +
> > +	ret = reset_control_deassert(kproc->reset);
> > +	if (ret) {
> > +		dev_err(dev, "local-reset deassert failed, ret = %d\n", ret);
> > +		return ret;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +/*
> > + * Stop the M4 remote processor.
> > + *
> > + * This function puts the M4 processor into reset, and finishes processing
> > + * of any pending messages. This callback is invoked only in remoteproc mode.
> > + */
> > +static int k3_m4_rproc_stop(struct rproc *rproc)
> > +{
> > +	struct k3_m4_rproc *kproc = rproc->priv;
> > +	struct device *dev = kproc->dev;
> > +	int ret;
> > +
> > +	ret = reset_control_assert(kproc->reset);
> > +	if (ret) {
> > +		dev_err(dev, "local-reset assert failed, ret = %d\n", ret);
> > +		return ret;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +/*
> > + * Attach to a running M4 remote processor (IPC-only mode)
> > + *
> > + * The remote processor is already booted, so there is no need to issue any
> > + * TI-SCI commands to boot the M4 core. This callback is used only in IPC-only
> > + * mode.
> > + */
> > +static int k3_m4_rproc_attach(struct rproc *rproc)
> > +{
> > +	struct k3_m4_rproc *kproc = rproc->priv;
> > +	int ret;
> > +
> > +	ret = k3_m4_rproc_ping_mbox(kproc);
> > +	if (ret)
> > +		return ret;
> > +
> > +	return 0;
> > +}
> > +
> > +/*
> > + * Detach from a running M4 remote processor (IPC-only mode)
> > + *
> > + * This rproc detach callback performs the opposite operation to attach
> > + * callback, the M4 core is not stopped and will be left to continue to
> > + * run its booted firmware. This callback is invoked only in IPC-only mode.
> > + */
> > +static int k3_m4_rproc_detach(struct rproc *rproc)
> > +{
> > +	return 0;
> > +}
> 
> Please remove.

Forget this comment since it would cause an error in __rproc_detach().  

> 
> Other than the above I'm good with this driver.  That said I can't move forward
> without a nod from the DT crew.  I also noticed a fair amount of code
> duplication with the k3_r5 and k3_dsp drivers.  Dealing with that should not be
> part of the current work but will need to be done before another k3 driver can
> be merged.
> 

The above still apply though.

> Thanks,
> Mathieu
> 
> > +
> > +static const struct rproc_ops k3_m4_rproc_ops = {
> > +	.prepare = k3_m4_rproc_prepare,
> > +	.unprepare = k3_m4_rproc_unprepare,
> > +	.start = k3_m4_rproc_start,
> > +	.stop = k3_m4_rproc_stop,
> > +	.attach = k3_m4_rproc_attach,
> > +	.detach = k3_m4_rproc_detach,
> > +	.kick = k3_m4_rproc_kick,
> > +	.da_to_va = k3_m4_rproc_da_to_va,
> > +	.get_loaded_rsc_table = k3_m4_get_loaded_rsc_table,
> > +};
> > +
> > +static int k3_m4_rproc_probe(struct platform_device *pdev)
> > +{
> > +	struct device *dev = &pdev->dev;
> > +	struct k3_m4_rproc *kproc;
> > +	struct rproc *rproc;
> > +	const char *fw_name;
> > +	bool r_state = false;
> > +	bool p_state = false;
> > +	int ret;
> > +
> > +	ret = rproc_of_parse_firmware(dev, 0, &fw_name);
> > +	if (ret)
> > +		return dev_err_probe(dev, ret, "failed to parse firmware-name property\n");
> > +
> > +	rproc = devm_rproc_alloc(dev, dev_name(dev), &k3_m4_rproc_ops, fw_name,
> > +				 sizeof(*kproc));
> > +	if (!rproc)
> > +		return -ENOMEM;
> > +
> > +	rproc->has_iommu = false;
> > +	rproc->recovery_disabled = true;
> > +	kproc = rproc->priv;
> > +	kproc->dev = dev;
> > +	platform_set_drvdata(pdev, rproc);
> > +
> > +	kproc->ti_sci = devm_ti_sci_get_by_phandle(dev, "ti,sci");
> > +	if (IS_ERR(kproc->ti_sci))
> > +		return dev_err_probe(dev, PTR_ERR(kproc->ti_sci),
> > +				     "failed to get ti-sci handle\n");
> > +
> > +	ret = of_property_read_u32(dev->of_node, "ti,sci-dev-id", &kproc->ti_sci_id);
> > +	if (ret)
> > +		return dev_err_probe(dev, ret, "missing 'ti,sci-dev-id' property\n");
> > +
> > +	kproc->reset = devm_reset_control_get_exclusive(dev, NULL);
> > +	if (IS_ERR(kproc->reset))
> > +		return dev_err_probe(dev, PTR_ERR(kproc->reset), "failed to get reset\n");
> > +
> > +	kproc->tsp = ti_sci_proc_of_get_tsp(dev, kproc->ti_sci);
> > +	if (IS_ERR(kproc->tsp))
> > +		return dev_err_probe(dev, PTR_ERR(kproc->tsp),
> > +				     "failed to construct ti-sci proc control\n");
> > +
> > +	ret = ti_sci_proc_request(kproc->tsp);
> > +	if (ret < 0)
> > +		return dev_err_probe(dev, ret, "ti_sci_proc_request failed\n");
> > +	ret = devm_add_action_or_reset(dev, k3_m4_release_tsp, kproc->tsp);
> > +	if (ret)
> > +		return ret;
> > +
> > +	ret = k3_m4_rproc_of_get_memories(pdev, kproc);
> > +	if (ret)
> > +		return ret;
> > +
> > +	ret = k3_m4_reserved_mem_init(kproc);
> > +	if (ret)
> > +		return dev_err_probe(dev, ret, "reserved memory init failed\n");
> > +
> > +	ret = kproc->ti_sci->ops.dev_ops.is_on(kproc->ti_sci, kproc->ti_sci_id,
> > +					       &r_state, &p_state);
> > +	if (ret)
> > +		return dev_err_probe(dev, ret,
> > +				     "failed to get initial state, mode cannot be determined\n");
> > +
> > +	/* configure devices for either remoteproc or IPC-only mode */
> > +	if (p_state) {
> > +		rproc->state = RPROC_DETACHED;
> > +		dev_info(dev, "configured M4F for IPC-only mode\n");
> > +	} else {
> > +		dev_info(dev, "configured M4F for remoteproc mode\n");
> > +	}
> > +
> > +	kproc->client.dev = dev;
> > +	kproc->client.tx_done = NULL;
> > +	kproc->client.rx_callback = k3_m4_rproc_mbox_callback;
> > +	kproc->client.tx_block = false;
> > +	kproc->client.knows_txdone = false;
> > +	kproc->mbox = mbox_request_channel(&kproc->client, 0);
> > +	if (IS_ERR(kproc->mbox))
> > +		return dev_err_probe(dev, PTR_ERR(kproc->mbox),
> > +				     "mbox_request_channel failed\n");
> > +
> > +	ret = devm_rproc_add(dev, rproc);
> > +	if (ret)
> > +		return dev_err_probe(dev, ret,
> > +				     "failed to register device with remoteproc core\n");
> > +
> > +	return 0;
> > +}
> > +
> > +static const struct of_device_id k3_m4_of_match[] = {
> > +	{ .compatible = "ti,am64-m4fss", },
> > +	{ /* sentinel */ },
> > +};
> > +MODULE_DEVICE_TABLE(of, k3_m4_of_match);
> > +
> > +static struct platform_driver k3_m4_rproc_driver = {
> > +	.probe	= k3_m4_rproc_probe,
> > +	.driver	= {
> > +		.name = "k3-m4-rproc",
> > +		.of_match_table = k3_m4_of_match,
> > +	},
> > +};
> > +module_platform_driver(k3_m4_rproc_driver);
> > +
> > +MODULE_AUTHOR("Hari Nagalla <hnagalla@ti.com>");
> > +MODULE_DESCRIPTION("TI K3 M4 Remoteproc driver");
> > +MODULE_LICENSE("GPL");
> > -- 
> > 2.39.2
> > 

Re: [PATCH v11 3/9] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem

[Vignesh Raghavendra]

[...]

Hi Mathieu

On 16/08/24 20:06, Mathieu Poirier wrote:
>>> +/*
>>> + * Attach to a running M4 remote processor (IPC-only mode)
>>> + *
>>> + * The remote processor is already booted, so there is no need to issue any
>>> + * TI-SCI commands to boot the M4 core. This callback is used only in IPC-only
>>> + * mode.
>>> + */
>>> +static int k3_m4_rproc_attach(struct rproc *rproc)
>>> +{
>>> +	struct k3_m4_rproc *kproc = rproc->priv;
>>> +	int ret;
>>> +
>>> +	ret = k3_m4_rproc_ping_mbox(kproc);
>>> +	if (ret)
>>> +		return ret;
>>> +
>>> +	return 0;
>>> +}
>>> +
>>> +/*
>>> + * Detach from a running M4 remote processor (IPC-only mode)
>>> + *
>>> + * This rproc detach callback performs the opposite operation to attach
>>> + * callback, the M4 core is not stopped and will be left to continue to
>>> + * run its booted firmware. This callback is invoked only in IPC-only mode.
>>> + */
>>> +static int k3_m4_rproc_detach(struct rproc *rproc)
>>> +{
>>> +	return 0;
>>> +}
>> Please remove.
> Forget this comment since it would cause an error in __rproc_detach().  
> 
>> Other than the above I'm good with this driver.  That said I can't move forward
>> without a nod from the DT crew.  I also noticed a fair amount of code
>> duplication with the k3_r5 and k3_dsp drivers.  Dealing with that should not be
>> part of the current work but will need to be done before another k3 driver can
>> be merged.
>>

> The above still apply though.

Me or Nishanth will pick up the SoC DT patches via TI SoC tree, once the
driver patches are merged. Feel free to ignore those but queue
dt-bindings (already has DT maintainers ack) and driver patches via
rproc tree.


-- 
Regards
Vignesh

Re: [PATCH v11 0/9] TI K3 M4F support on AM62 and AM64 SoCs

[Wadim Egorov]

Am 02.08.24 um 17:21 schrieb Andrew Davis:
> Hello all,
> 
> This is the continuation of the M4F RProc support series from here[0].
> I'm helping out with the upstream task for Hari and so versions (v8+)
> is a little different than the previous(v7-) postings[0]. Most notable
> change I've introduced being the patches factoring out common support
> from the current K3 R5 and DSP drivers have been dropped. I'd like
> to do that re-factor *after* getting this driver in shape, that way
> we have 3 similar drivers to factor out from vs trying to make those
> changes in parallel with the series adding M4 support.
> 
> Anyway, details on our M4F subsystem can be found the
> the AM62 TRM in the section on the same:
> 
> AM62x Technical Reference Manual (SPRUIV7A – MAY 2022)
> https://www.ti.com/lit/pdf/SPRUIV7A
> 
> Thanks,
> Andrew
> 
> [0] https://lore.kernel.org/linux-arm-kernel/20240202175538.1705-5-hnagalla@ti.com/T/
> 
> Changes for v11:
>   - Added patch [2/9] factoring out a common function
>   - Addressed comments by Mathieu from v10
>   - Rebased on v6.11-rc1
>   - Small reworks in driver for readability

Tested on a AM62x & AM64x using phycore-am62x & phycore-am64x, so

Tested-by: Wadim Egorov <w.egorov@phytec.de>

> 
> Changes for v10:
>   - Rebased on v6.10-rc3
>   - Added AM64 M4 support in DT
>   - Addressed comments by Mathieu from v9
> 
> Changes for v9:
>   - Fixed reserved-memory.yaml text in [1/5]
>   - Split dts patch into one for SoC and one for board enable
>   - Corrected DT property order and formatting [4/5][5/5]
> 
> Andrew Davis (1):
>    remoteproc: k3: Factor out TI-SCI processor control OF get function
> 
> Hari Nagalla (7):
>    dt-bindings: remoteproc: k3-m4f: Add K3 AM64x SoCs
>    arm64: dts: ti: k3-am62: Add M4F remoteproc node
>    arm64: dts: ti: k3-am625-sk: Add M4F remoteproc node
>    arm64: dts: ti: k3-am64: Add M4F remoteproc node
>    arm64: dts: ti: k3-am642-sk: Add M4F remoteproc node
>    arm64: dts: ti: k3-am642-evm: Add M4F remoteproc node
>    arm64: defconfig: Enable TI K3 M4 remoteproc driver
> 
> Martyn Welch (1):
>    remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
> 
>   .../bindings/remoteproc/ti,k3-m4f-rproc.yaml  | 125 ++++
>   arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi       |  13 +
>   .../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi |  19 +
>   arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi       |  13 +
>   arch/arm64/boot/dts/ti/k3-am642-evm.dts       |  19 +
>   arch/arm64/boot/dts/ti/k3-am642-sk.dts        |  19 +
>   arch/arm64/configs/defconfig                  |   1 +
>   drivers/remoteproc/Kconfig                    |  13 +
>   drivers/remoteproc/Makefile                   |   1 +
>   drivers/remoteproc/ti_k3_dsp_remoteproc.c     |  28 +-
>   drivers/remoteproc/ti_k3_m4_remoteproc.c      | 667 ++++++++++++++++++
>   drivers/remoteproc/ti_k3_r5_remoteproc.c      |  28 +-
>   drivers/remoteproc/ti_sci_proc.h              |  26 +
>   13 files changed, 918 insertions(+), 54 deletions(-)
>   create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
>   create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
> 

Re: [PATCH v11 3/9] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem

[Wadim Egorov]

Am 02.08.24 um 17:21 schrieb Andrew Davis:
> From: Martyn Welch <martyn.welch@collabora.com>
> 
> The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
> the MCU domain. This core is typically used for safety applications in a
> stand alone mode. However, some application (non safety related) may
> want to use the M4F core as a generic remote processor with IPC to the
> host processor. The M4F core has internal IRAM and DRAM memories and are
> exposed to the system bus for code and data loading.
> 
> A remote processor driver is added to support this subsystem, including
> being able to load and boot the M4F core. Loading includes to M4F
> internal memories and predefined external code/data memories. The
> carve outs for external contiguous memory is defined in the M4F device
> node and should match with the external memory declarations in the M4F
> image binary. The M4F subsystem has two resets. One reset is for the
> entire subsystem i.e including the internal memories and the other, a
> local reset is only for the M4F processing core. When loading the image,
> the driver first releases the subsystem reset, loads the firmware image
> and then releases the local reset to let the M4F processing core run.
> 
> Signed-off-by: Martyn Welch <martyn.welch@collabora.com>
> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
> Signed-off-by: Andrew Davis <afd@ti.com>

Tested-by: Wadim Egorov <w.egorov@phytec.de>

> ---
>   drivers/remoteproc/Kconfig               |  13 +
>   drivers/remoteproc/Makefile              |   1 +
>   drivers/remoteproc/ti_k3_m4_remoteproc.c | 667 +++++++++++++++++++++++
>   3 files changed, 681 insertions(+)
>   create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index dda2ada215b7c..0f0862e20a932 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -340,6 +340,19 @@ config TI_K3_DSP_REMOTEPROC
>   	  It's safe to say N here if you're not interested in utilizing
>   	  the DSP slave processors.
>   
> +config TI_K3_M4_REMOTEPROC
> +	tristate "TI K3 M4 remoteproc support"
> +	depends on ARCH_K3 || COMPILE_TEST
> +	select MAILBOX
> +	select OMAP2PLUS_MBOX
> +	help
> +	  Say m here to support TI's M4 remote processor subsystems
> +	  on various TI K3 family of SoCs through the remote processor
> +	  framework.
> +
> +	  It's safe to say N here if you're not interested in utilizing
> +	  a remote processor.
> +
>   config TI_K3_R5_REMOTEPROC
>   	tristate "TI K3 R5 remoteproc support"
>   	depends on ARCH_K3
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 91314a9b43cef..5ff4e2fee4abd 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC)		+= st_remoteproc.o
>   obj-$(CONFIG_ST_SLIM_REMOTEPROC)	+= st_slim_rproc.o
>   obj-$(CONFIG_STM32_RPROC)		+= stm32_rproc.o
>   obj-$(CONFIG_TI_K3_DSP_REMOTEPROC)	+= ti_k3_dsp_remoteproc.o
> +obj-$(CONFIG_TI_K3_M4_REMOTEPROC)	+= ti_k3_m4_remoteproc.o
>   obj-$(CONFIG_TI_K3_R5_REMOTEPROC)	+= ti_k3_r5_remoteproc.o
>   obj-$(CONFIG_XLNX_R5_REMOTEPROC)	+= xlnx_r5_remoteproc.o
> diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c b/drivers/remoteproc/ti_k3_m4_remoteproc.c
> new file mode 100644
> index 0000000000000..09f0484a90e10
> --- /dev/null
> +++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
> @@ -0,0 +1,667 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * TI K3 Cortex-M4 Remote Processor(s) driver
> + *
> + * Copyright (C) 2021-2024 Texas Instruments Incorporated - https://www.ti.com/
> + *	Hari Nagalla <hnagalla@ti.com>
> + */
> +
> +#include <linux/io.h>
> +#include <linux/mailbox_client.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/of_reserved_mem.h>
> +#include <linux/platform_device.h>
> +#include <linux/remoteproc.h>
> +#include <linux/reset.h>
> +#include <linux/slab.h>
> +
> +#include "omap_remoteproc.h"
> +#include "remoteproc_internal.h"
> +#include "ti_sci_proc.h"
> +
> +#define K3_M4_IRAM_DEV_ADDR 0x00000
> +#define K3_M4_DRAM_DEV_ADDR 0x30000
> +
> +/**
> + * struct k3_m4_rproc_mem - internal memory structure
> + * @cpu_addr: MPU virtual address of the memory region
> + * @bus_addr: Bus address used to access the memory region
> + * @dev_addr: Device address of the memory region from remote processor view
> + * @size: Size of the memory region
> + */
> +struct k3_m4_rproc_mem {
> +	void __iomem *cpu_addr;
> +	phys_addr_t bus_addr;
> +	u32 dev_addr;
> +	size_t size;
> +};
> +
> +/**
> + * struct k3_m4_rproc_mem_data - memory definitions for a remote processor
> + * @name: name for this memory entry
> + * @dev_addr: device address for the memory entry
> + */
> +struct k3_m4_rproc_mem_data {
> +	const char *name;
> +	const u32 dev_addr;
> +};
> +
> +/**
> + * struct k3_m4_rproc - k3 remote processor driver structure
> + * @dev: cached device pointer
> + * @mem: internal memory regions data
> + * @num_mems: number of internal memory regions
> + * @rmem: reserved memory regions data
> + * @num_rmems: number of reserved memory regions
> + * @reset: reset control handle
> + * @tsp: TI-SCI processor control handle
> + * @ti_sci: TI-SCI handle
> + * @ti_sci_id: TI-SCI device identifier
> + * @mbox: mailbox channel handle
> + * @client: mailbox client to request the mailbox channel
> + */
> +struct k3_m4_rproc {
> +	struct device *dev;
> +	struct k3_m4_rproc_mem *mem;
> +	int num_mems;
> +	struct k3_m4_rproc_mem *rmem;
> +	int num_rmems;
> +	struct reset_control *reset;
> +	struct ti_sci_proc *tsp;
> +	const struct ti_sci_handle *ti_sci;
> +	u32 ti_sci_id;
> +	struct mbox_chan *mbox;
> +	struct mbox_client client;
> +};
> +
> +/**
> + * k3_m4_rproc_mbox_callback() - inbound mailbox message handler
> + * @client: mailbox client pointer used for requesting the mailbox channel
> + * @data: mailbox payload
> + *
> + * This handler is invoked by the K3 mailbox driver whenever a mailbox
> + * message is received. Usually, the mailbox payload simply contains
> + * the index of the virtqueue that is kicked by the remote processor,
> + * and we let remoteproc core handle it.
> + *
> + * In addition to virtqueue indices, we also have some out-of-band values
> + * that indicate different events. Those values are deliberately very
> + * large so they don't coincide with virtqueue indices.
> + */
> +static void k3_m4_rproc_mbox_callback(struct mbox_client *client, void *data)
> +{
> +	struct device *dev = client->dev;
> +	struct rproc *rproc = dev_get_drvdata(dev);
> +	u32 msg = (u32)(uintptr_t)(data);
> +
> +	dev_dbg(dev, "mbox msg: 0x%x\n", msg);
> +
> +	switch (msg) {
> +	case RP_MBOX_CRASH:
> +		/*
> +		 * remoteproc detected an exception, but error recovery is not
> +		 * supported. So, just log this for now
> +		 */
> +		dev_err(dev, "K3 rproc %s crashed\n", rproc->name);
> +		break;
> +	case RP_MBOX_ECHO_REPLY:
> +		dev_info(dev, "received echo reply from %s\n", rproc->name);
> +		break;
> +	default:
> +		/* silently handle all other valid messages */
> +		if (msg >= RP_MBOX_READY && msg < RP_MBOX_END_MSG)
> +			return;
> +		if (msg > rproc->max_notifyid) {
> +			dev_dbg(dev, "dropping unknown message 0x%x", msg);
> +			return;
> +		}
> +		/* msg contains the index of the triggered vring */
> +		if (rproc_vq_interrupt(rproc, msg) == IRQ_NONE)
> +			dev_dbg(dev, "no message was found in vqid %d\n", msg);
> +	}
> +}
> +
> +/*
> + * Kick the remote processor to notify about pending unprocessed messages.
> + * The vqid usage is not used and is inconsequential, as the kick is performed
> + * through a simulated GPIO (a bit in an IPC interrupt-triggering register),
> + * the remote processor is expected to process both its Tx and Rx virtqueues.
> + */
> +static void k3_m4_rproc_kick(struct rproc *rproc, int vqid)
> +{
> +	struct k3_m4_rproc *kproc = rproc->priv;
> +	struct device *dev = kproc->dev;
> +	u32 msg = (u32)vqid;
> +	int ret;
> +
> +	/*
> +	 * Send the index of the triggered virtqueue in the mailbox payload.
> +	 * NOTE: msg is cast to uintptr_t to prevent compiler warnings when
> +	 * void* is 64bit. It is safely cast back to u32 in the mailbox driver.
> +	 */
> +	ret = mbox_send_message(kproc->mbox, (void *)(uintptr_t)msg);
> +	if (ret < 0)
> +		dev_err(dev, "failed to send mailbox message, status = %d\n",
> +			ret);
> +}
> +
> +static int k3_m4_rproc_ping_mbox(struct k3_m4_rproc *kproc)
> +{
> +	struct device *dev = kproc->dev;
> +	int ret;
> +
> +	/*
> +	 * Ping the remote processor, this is only for sanity-sake for now;
> +	 * there is no functional effect whatsoever.
> +	 *
> +	 * Note that the reply will _not_ arrive immediately: this message
> +	 * will wait in the mailbox fifo until the remote processor is booted.
> +	 */
> +	ret = mbox_send_message(kproc->mbox, (void *)RP_MBOX_ECHO_REQUEST);
> +	if (ret < 0) {
> +		dev_err(dev, "mbox_send_message failed: %d\n", ret);
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +/*
> + * The M4 cores have a local reset that affects only the CPU, and a
> + * generic module reset that powers on the device and allows the internal
> + * memories to be accessed while the local reset is asserted. This function is
> + * used to release the global reset on remote cores to allow loading into the
> + * internal RAMs. The .prepare() ops is invoked by remoteproc core before any
> + * firmware loading, and is followed by the .start() ops after loading to
> + * actually let the remote cores to run.
> + */
> +static int k3_m4_rproc_prepare(struct rproc *rproc)
> +{
> +	struct k3_m4_rproc *kproc = rproc->priv;
> +	struct device *dev = kproc->dev;
> +	int ret;
> +
> +	/* If the core is running already no need to deassert the module reset */
> +	if (rproc->state == RPROC_DETACHED)
> +		return 0;
> +
> +	/*
> +	 * Ensure the local reset is asserted so the core doesn't
> +	 * execute bogus code when the module reset is released.
> +	 */
> +	ret = reset_control_assert(kproc->reset);
> +	if (ret) {
> +		dev_err(dev, "could not assert local reset\n");
> +		return ret;
> +	}
> +
> +	ret = reset_control_status(kproc->reset);
> +	if (ret <= 0) {
> +		dev_err(dev, "local reset still not asserted\n");
> +		return ret;
> +	}
> +
> +	ret = kproc->ti_sci->ops.dev_ops.get_device(kproc->ti_sci,
> +						    kproc->ti_sci_id);
> +	if (ret) {
> +		dev_err(dev, "could not deassert module-reset for internal RAM loading\n");
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +/*
> + * This function implements the .unprepare() ops and performs the complimentary
> + * operations to that of the .prepare() ops. The function is used to assert the
> + * global reset on applicable cores. This completes the second portion of
> + * powering down the remote core. The cores themselves are only halted in the
> + * .stop() callback through the local reset, and the .unprepare() ops is invoked
> + * by the remoteproc core after the remoteproc is stopped to balance the global
> + * reset.
> + */
> +static int k3_m4_rproc_unprepare(struct rproc *rproc)
> +{
> +	struct k3_m4_rproc *kproc = rproc->priv;
> +	struct device *dev = kproc->dev;
> +	int ret;
> +
> +	/* If the core is going to be detached do not assert the module reset */
> +	if (rproc->state == RPROC_ATTACHED)
> +		return 0;
> +
> +	ret = kproc->ti_sci->ops.dev_ops.put_device(kproc->ti_sci,
> +						    kproc->ti_sci_id);
> +	if (ret) {
> +		dev_err(dev, "module-reset assert failed\n");
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +/*
> + * This function implements the .get_loaded_rsc_table() callback and is used
> + * to provide the resource table for a booted remote processor in IPC-only
> + * mode. The remote processor firmwares follow a design-by-contract approach
> + * and are expected to have the resource table at the base of the DDR region
> + * reserved for firmware usage. This provides flexibility for the remote
> + * processor to be booted by different bootloaders that may or may not have the
> + * ability to publish the resource table address and size through a DT
> + * property.
> + */
> +static struct resource_table *k3_m4_get_loaded_rsc_table(struct rproc *rproc,
> +							 size_t *rsc_table_sz)
> +{
> +	struct k3_m4_rproc *kproc = rproc->priv;
> +	struct device *dev = kproc->dev;
> +
> +	if (!kproc->rmem[0].cpu_addr) {
> +		dev_err(dev, "memory-region #1 does not exist, loaded rsc table can't be found");
> +		return ERR_PTR(-ENOMEM);
> +	}
> +
> +	/*
> +	 * NOTE: The resource table size is currently hard-coded to a maximum
> +	 * of 256 bytes. The most common resource table usage for K3 firmwares
> +	 * is to only have the vdev resource entry and an optional trace entry.
> +	 * The exact size could be computed based on resource table address, but
> +	 * the hard-coded value suffices to support the IPC-only mode.
> +	 */
> +	*rsc_table_sz = 256;
> +	return (__force struct resource_table *)kproc->rmem[0].cpu_addr;
> +}
> +
> +/*
> + * Custom function to translate a remote processor device address (internal
> + * RAMs only) to a kernel virtual address.  The remote processors can access
> + * their RAMs at either an internal address visible only from a remote
> + * processor, or at the SoC-level bus address. Both these addresses need to be
> + * looked through for translation. The translated addresses can be used either
> + * by the remoteproc core for loading (when using kernel remoteproc loader), or
> + * by any rpmsg bus drivers.
> + */
> +static void *k3_m4_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
> +{
> +	struct k3_m4_rproc *kproc = rproc->priv;
> +	void __iomem *va = NULL;
> +	phys_addr_t bus_addr;
> +	u32 dev_addr, offset;
> +	size_t size;
> +	int i;
> +
> +	if (len == 0)
> +		return NULL;
> +
> +	for (i = 0; i < kproc->num_mems; i++) {
> +		bus_addr = kproc->mem[i].bus_addr;
> +		dev_addr = kproc->mem[i].dev_addr;
> +		size = kproc->mem[i].size;
> +
> +		/* handle M4-view addresses */
> +		if (da >= dev_addr && ((da + len) <= (dev_addr + size))) {
> +			offset = da - dev_addr;
> +			va = kproc->mem[i].cpu_addr + offset;
> +			return (__force void *)va;
> +		}
> +
> +		/* handle SoC-view addresses */
> +		if (da >= bus_addr && ((da + len) <= (bus_addr + size))) {
> +			offset = da - bus_addr;
> +			va = kproc->mem[i].cpu_addr + offset;
> +			return (__force void *)va;
> +		}
> +	}
> +
> +	/* handle static DDR reserved memory regions */
> +	for (i = 0; i < kproc->num_rmems; i++) {
> +		dev_addr = kproc->rmem[i].dev_addr;
> +		size = kproc->rmem[i].size;
> +
> +		if (da >= dev_addr && ((da + len) <= (dev_addr + size))) {
> +			offset = da - dev_addr;
> +			va = kproc->rmem[i].cpu_addr + offset;
> +			return (__force void *)va;
> +		}
> +	}
> +
> +	return NULL;
> +}
> +
> +static int k3_m4_rproc_of_get_memories(struct platform_device *pdev,
> +				       struct k3_m4_rproc *kproc)
> +{
> +	static const char * const mem_names[] = { "iram", "dram" };
> +	static const u32 mem_addrs[] = { K3_M4_IRAM_DEV_ADDR, K3_M4_DRAM_DEV_ADDR };
> +	struct device *dev = &pdev->dev;
> +	struct resource *res;
> +	int num_mems;
> +	int i;
> +
> +	num_mems = ARRAY_SIZE(mem_names);
> +	kproc->mem = devm_kcalloc(kproc->dev, num_mems,
> +				  sizeof(*kproc->mem), GFP_KERNEL);
> +	if (!kproc->mem)
> +		return -ENOMEM;
> +
> +	for (i = 0; i < num_mems; i++) {
> +		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> +						   mem_names[i]);
> +		if (!res) {
> +			dev_err(dev, "found no memory resource for %s\n",
> +				mem_names[i]);
> +			return -EINVAL;
> +		}
> +		if (!devm_request_mem_region(dev, res->start,
> +					     resource_size(res),
> +					     dev_name(dev))) {
> +			dev_err(dev, "could not request %s region for resource\n",
> +				mem_names[i]);
> +			return -EBUSY;
> +		}
> +
> +		kproc->mem[i].cpu_addr = devm_ioremap_wc(dev, res->start,
> +							 resource_size(res));
> +		if (!kproc->mem[i].cpu_addr) {
> +			dev_err(dev, "failed to map %s memory\n",
> +				mem_names[i]);
> +			return -ENOMEM;
> +		}
> +		kproc->mem[i].bus_addr = res->start;
> +		kproc->mem[i].dev_addr = mem_addrs[i];
> +		kproc->mem[i].size = resource_size(res);
> +
> +		dev_dbg(dev, "memory %8s: bus addr %pa size 0x%zx va %pK da 0x%x\n",
> +			mem_names[i], &kproc->mem[i].bus_addr,
> +			kproc->mem[i].size, kproc->mem[i].cpu_addr,
> +			kproc->mem[i].dev_addr);
> +	}
> +	kproc->num_mems = num_mems;
> +
> +	return 0;
> +}
> +
> +static void k3_m4_rproc_dev_mem_release(void *data)
> +{
> +	struct device *dev = data;
> +
> +	of_reserved_mem_device_release(dev);
> +}
> +
> +static int k3_m4_reserved_mem_init(struct k3_m4_rproc *kproc)
> +{
> +	struct device *dev = kproc->dev;
> +	struct device_node *np = dev->of_node;
> +	struct device_node *rmem_np;
> +	struct reserved_mem *rmem;
> +	int num_rmems;
> +	int ret, i;
> +
> +	num_rmems = of_property_count_elems_of_size(np, "memory-region",
> +						    sizeof(phandle));
> +	if (num_rmems < 0) {
> +		dev_err(dev, "device does not reserved memory regions (%d)\n",
> +			num_rmems);
> +		return -EINVAL;
> +	}
> +	if (num_rmems < 2) {
> +		dev_err(dev, "device needs at least two memory regions to be defined, num = %d\n",
> +			num_rmems);
> +		return -EINVAL;
> +	}
> +
> +	/* use reserved memory region 0 for vring DMA allocations */
> +	ret = of_reserved_mem_device_init_by_idx(dev, np, 0);
> +	if (ret) {
> +		dev_err(dev, "device cannot initialize DMA pool (%d)\n", ret);
> +		return ret;
> +	}
> +	ret = devm_add_action_or_reset(dev, k3_m4_rproc_dev_mem_release, dev);
> +	if (ret)
> +		return ret;
> +
> +	num_rmems--;
> +	kproc->rmem = devm_kcalloc(dev, num_rmems, sizeof(*kproc->rmem), GFP_KERNEL);
> +	if (!kproc->rmem)
> +		return -ENOMEM;
> +
> +	/* use remaining reserved memory regions for static carveouts */
> +	for (i = 0; i < num_rmems; i++) {
> +		rmem_np = of_parse_phandle(np, "memory-region", i + 1);
> +		if (!rmem_np)
> +			return -EINVAL;
> +
> +		rmem = of_reserved_mem_lookup(rmem_np);
> +		if (!rmem) {
> +			of_node_put(rmem_np);
> +			return -EINVAL;
> +		}
> +		of_node_put(rmem_np);
> +
> +		kproc->rmem[i].bus_addr = rmem->base;
> +		/* 64-bit address regions currently not supported */
> +		kproc->rmem[i].dev_addr = (u32)rmem->base;
> +		kproc->rmem[i].size = rmem->size;
> +		kproc->rmem[i].cpu_addr = devm_ioremap_wc(dev, rmem->base, rmem->size);
> +		if (!kproc->rmem[i].cpu_addr) {
> +			dev_err(dev, "failed to map reserved memory#%d at %pa of size %pa\n",
> +				i + 1, &rmem->base, &rmem->size);
> +			return -ENOMEM;
> +		}
> +
> +		dev_dbg(dev, "reserved memory%d: bus addr %pa size 0x%zx va %pK da 0x%x\n",
> +			i + 1, &kproc->rmem[i].bus_addr,
> +			kproc->rmem[i].size, kproc->rmem[i].cpu_addr,
> +			kproc->rmem[i].dev_addr);
> +	}
> +	kproc->num_rmems = num_rmems;
> +
> +	return 0;
> +}
> +
> +static void k3_m4_release_tsp(void *data)
> +{
> +	struct ti_sci_proc *tsp = data;
> +
> +	ti_sci_proc_release(tsp);
> +}
> +
> +/*
> + * Power up the M4 remote processor.
> + *
> + * This function will be invoked only after the firmware for this rproc
> + * was loaded, parsed successfully, and all of its resource requirements
> + * were met. This callback is invoked only in remoteproc mode.
> + */
> +static int k3_m4_rproc_start(struct rproc *rproc)
> +{
> +	struct k3_m4_rproc *kproc = rproc->priv;
> +	struct device *dev = kproc->dev;
> +	int ret;
> +
> +	ret = k3_m4_rproc_ping_mbox(kproc);
> +	if (ret)
> +		return ret;
> +
> +	ret = reset_control_deassert(kproc->reset);
> +	if (ret) {
> +		dev_err(dev, "local-reset deassert failed, ret = %d\n", ret);
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +/*
> + * Stop the M4 remote processor.
> + *
> + * This function puts the M4 processor into reset, and finishes processing
> + * of any pending messages. This callback is invoked only in remoteproc mode.
> + */
> +static int k3_m4_rproc_stop(struct rproc *rproc)
> +{
> +	struct k3_m4_rproc *kproc = rproc->priv;
> +	struct device *dev = kproc->dev;
> +	int ret;
> +
> +	ret = reset_control_assert(kproc->reset);
> +	if (ret) {
> +		dev_err(dev, "local-reset assert failed, ret = %d\n", ret);
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +/*
> + * Attach to a running M4 remote processor (IPC-only mode)
> + *
> + * The remote processor is already booted, so there is no need to issue any
> + * TI-SCI commands to boot the M4 core. This callback is used only in IPC-only
> + * mode.
> + */
> +static int k3_m4_rproc_attach(struct rproc *rproc)
> +{
> +	struct k3_m4_rproc *kproc = rproc->priv;
> +	int ret;
> +
> +	ret = k3_m4_rproc_ping_mbox(kproc);
> +	if (ret)
> +		return ret;
> +
> +	return 0;
> +}
> +
> +/*
> + * Detach from a running M4 remote processor (IPC-only mode)
> + *
> + * This rproc detach callback performs the opposite operation to attach
> + * callback, the M4 core is not stopped and will be left to continue to
> + * run its booted firmware. This callback is invoked only in IPC-only mode.
> + */
> +static int k3_m4_rproc_detach(struct rproc *rproc)
> +{
> +	return 0;
> +}
> +
> +static const struct rproc_ops k3_m4_rproc_ops = {
> +	.prepare = k3_m4_rproc_prepare,
> +	.unprepare = k3_m4_rproc_unprepare,
> +	.start = k3_m4_rproc_start,
> +	.stop = k3_m4_rproc_stop,
> +	.attach = k3_m4_rproc_attach,
> +	.detach = k3_m4_rproc_detach,
> +	.kick = k3_m4_rproc_kick,
> +	.da_to_va = k3_m4_rproc_da_to_va,
> +	.get_loaded_rsc_table = k3_m4_get_loaded_rsc_table,
> +};
> +
> +static int k3_m4_rproc_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct k3_m4_rproc *kproc;
> +	struct rproc *rproc;
> +	const char *fw_name;
> +	bool r_state = false;
> +	bool p_state = false;
> +	int ret;
> +
> +	ret = rproc_of_parse_firmware(dev, 0, &fw_name);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "failed to parse firmware-name property\n");
> +
> +	rproc = devm_rproc_alloc(dev, dev_name(dev), &k3_m4_rproc_ops, fw_name,
> +				 sizeof(*kproc));
> +	if (!rproc)
> +		return -ENOMEM;
> +
> +	rproc->has_iommu = false;
> +	rproc->recovery_disabled = true;
> +	kproc = rproc->priv;
> +	kproc->dev = dev;
> +	platform_set_drvdata(pdev, rproc);
> +
> +	kproc->ti_sci = devm_ti_sci_get_by_phandle(dev, "ti,sci");
> +	if (IS_ERR(kproc->ti_sci))
> +		return dev_err_probe(dev, PTR_ERR(kproc->ti_sci),
> +				     "failed to get ti-sci handle\n");
> +
> +	ret = of_property_read_u32(dev->of_node, "ti,sci-dev-id", &kproc->ti_sci_id);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "missing 'ti,sci-dev-id' property\n");
> +
> +	kproc->reset = devm_reset_control_get_exclusive(dev, NULL);
> +	if (IS_ERR(kproc->reset))
> +		return dev_err_probe(dev, PTR_ERR(kproc->reset), "failed to get reset\n");
> +
> +	kproc->tsp = ti_sci_proc_of_get_tsp(dev, kproc->ti_sci);
> +	if (IS_ERR(kproc->tsp))
> +		return dev_err_probe(dev, PTR_ERR(kproc->tsp),
> +				     "failed to construct ti-sci proc control\n");
> +
> +	ret = ti_sci_proc_request(kproc->tsp);
> +	if (ret < 0)
> +		return dev_err_probe(dev, ret, "ti_sci_proc_request failed\n");
> +	ret = devm_add_action_or_reset(dev, k3_m4_release_tsp, kproc->tsp);
> +	if (ret)
> +		return ret;
> +
> +	ret = k3_m4_rproc_of_get_memories(pdev, kproc);
> +	if (ret)
> +		return ret;
> +
> +	ret = k3_m4_reserved_mem_init(kproc);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "reserved memory init failed\n");
> +
> +	ret = kproc->ti_sci->ops.dev_ops.is_on(kproc->ti_sci, kproc->ti_sci_id,
> +					       &r_state, &p_state);
> +	if (ret)
> +		return dev_err_probe(dev, ret,
> +				     "failed to get initial state, mode cannot be determined\n");
> +
> +	/* configure devices for either remoteproc or IPC-only mode */
> +	if (p_state) {
> +		rproc->state = RPROC_DETACHED;
> +		dev_info(dev, "configured M4F for IPC-only mode\n");
> +	} else {
> +		dev_info(dev, "configured M4F for remoteproc mode\n");
> +	}
> +
> +	kproc->client.dev = dev;
> +	kproc->client.tx_done = NULL;
> +	kproc->client.rx_callback = k3_m4_rproc_mbox_callback;
> +	kproc->client.tx_block = false;
> +	kproc->client.knows_txdone = false;
> +	kproc->mbox = mbox_request_channel(&kproc->client, 0);
> +	if (IS_ERR(kproc->mbox))
> +		return dev_err_probe(dev, PTR_ERR(kproc->mbox),
> +				     "mbox_request_channel failed\n");
> +
> +	ret = devm_rproc_add(dev, rproc);
> +	if (ret)
> +		return dev_err_probe(dev, ret,
> +				     "failed to register device with remoteproc core\n");
> +
> +	return 0;
> +}
> +
> +static const struct of_device_id k3_m4_of_match[] = {
> +	{ .compatible = "ti,am64-m4fss", },
> +	{ /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, k3_m4_of_match);
> +
> +static struct platform_driver k3_m4_rproc_driver = {
> +	.probe	= k3_m4_rproc_probe,
> +	.driver	= {
> +		.name = "k3-m4-rproc",
> +		.of_match_table = k3_m4_of_match,
> +	},
> +};
> +module_platform_driver(k3_m4_rproc_driver);
> +
> +MODULE_AUTHOR("Hari Nagalla <hnagalla@ti.com>");
> +MODULE_DESCRIPTION("TI K3 M4 Remoteproc driver");
> +MODULE_LICENSE("GPL");

Re: [PATCH v11 4/9] arm64: dts: ti: k3-am62: Add M4F remoteproc node

[Wadim Egorov]

Am 02.08.24 um 17:21 schrieb Andrew Davis:
> From: Hari Nagalla <hnagalla@ti.com>
> 
> The AM62x SoCs of the TI K3 family have a Cortex M4F core in the MCU
> domain. This core can be used by non safety applications as a remote
> processor. When used as a remote processor with virtio/rpmessage IPC,
> two carveout reserved memory nodes are needed.
> 
> Disable by default as this node is not complete until mailbox data
> is provided in the board level DT.
> 
> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
> Signed-off-by: Andrew Davis <afd@ti.com>

Tested-by: Wadim Egorov <w.egorov@phytec.de>

> ---
>   arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 13 +++++++++++++
>   1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
> index e66d486ef1f21..7f6f0007e8e81 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
> @@ -173,4 +173,17 @@ mcu_mcan1: can@4e18000 {
>   		bosch,mram-cfg = <0x0 128 64 64 64 64 32 32>;
>   		status = "disabled";
>   	};
> +
> +	mcu_m4fss: m4fss@5000000 {
> +		compatible = "ti,am64-m4fss";
> +		reg = <0x00 0x5000000 0x00 0x30000>,
> +		      <0x00 0x5040000 0x00 0x10000>;
> +		reg-names = "iram", "dram";
> +		resets = <&k3_reset 9 1>;
> +		firmware-name = "am62-mcu-m4f0_0-fw";
> +		ti,sci = <&dmsc>;
> +		ti,sci-dev-id = <9>;
> +		ti,sci-proc-ids = <0x18 0xff>;
> +		status = "disabled";
> +	};
>   };

Re: [PATCH v11 2/9] remoteproc: k3: Factor out TI-SCI processor control OF get function

[Wadim Egorov]

Am 02.08.24 um 17:21 schrieb Andrew Davis:
> Building the TSP structure is common for users of the TI-SCI processor
> control interface. Factor out this function and put it with the rest
> of the TI-SCI processor control functions.
> 
> Signed-off-by: Andrew Davis <afd@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>

> ---
>   drivers/remoteproc/ti_k3_dsp_remoteproc.c | 28 +----------------------
>   drivers/remoteproc/ti_k3_r5_remoteproc.c  | 28 +----------------------
>   drivers/remoteproc/ti_sci_proc.h          | 26 +++++++++++++++++++++
>   3 files changed, 28 insertions(+), 54 deletions(-)
> 
> diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> index a22d41689a7d2..1585769092924 100644
> --- a/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> @@ -636,32 +636,6 @@ static void k3_dsp_release_tsp(void *data)
>   	ti_sci_proc_release(tsp);
>   }
>   
> -static
> -struct ti_sci_proc *k3_dsp_rproc_of_get_tsp(struct device *dev,
> -					    const struct ti_sci_handle *sci)
> -{
> -	struct ti_sci_proc *tsp;
> -	u32 temp[2];
> -	int ret;
> -
> -	ret = of_property_read_u32_array(dev->of_node, "ti,sci-proc-ids",
> -					 temp, 2);
> -	if (ret < 0)
> -		return ERR_PTR(ret);
> -
> -	tsp = devm_kzalloc(dev, sizeof(*tsp), GFP_KERNEL);
> -	if (!tsp)
> -		return ERR_PTR(-ENOMEM);
> -
> -	tsp->dev = dev;
> -	tsp->sci = sci;
> -	tsp->ops = &sci->ops.proc_ops;
> -	tsp->proc_id = temp[0];
> -	tsp->host_id = temp[1];
> -
> -	return tsp;
> -}
> -
>   static int k3_dsp_rproc_probe(struct platform_device *pdev)
>   {
>   	struct device *dev = &pdev->dev;
> @@ -711,7 +685,7 @@ static int k3_dsp_rproc_probe(struct platform_device *pdev)
>   		return dev_err_probe(dev, PTR_ERR(kproc->reset),
>   				     "failed to get reset\n");
>   
> -	kproc->tsp = k3_dsp_rproc_of_get_tsp(dev, kproc->ti_sci);
> +	kproc->tsp = ti_sci_proc_of_get_tsp(dev, kproc->ti_sci);
>   	if (IS_ERR(kproc->tsp))
>   		return dev_err_probe(dev, PTR_ERR(kproc->tsp),
>   				     "failed to construct ti-sci proc control\n");
> diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> index 39a47540c5900..dd6294ab81e2e 100644
> --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> @@ -1533,32 +1533,6 @@ static int k3_r5_core_of_get_sram_memories(struct platform_device *pdev,
>   	return 0;
>   }
>   
> -static
> -struct ti_sci_proc *k3_r5_core_of_get_tsp(struct device *dev,
> -					  const struct ti_sci_handle *sci)
> -{
> -	struct ti_sci_proc *tsp;
> -	u32 temp[2];
> -	int ret;
> -
> -	ret = of_property_read_u32_array(dev_of_node(dev), "ti,sci-proc-ids",
> -					 temp, 2);
> -	if (ret < 0)
> -		return ERR_PTR(ret);
> -
> -	tsp = devm_kzalloc(dev, sizeof(*tsp), GFP_KERNEL);
> -	if (!tsp)
> -		return ERR_PTR(-ENOMEM);
> -
> -	tsp->dev = dev;
> -	tsp->sci = sci;
> -	tsp->ops = &sci->ops.proc_ops;
> -	tsp->proc_id = temp[0];
> -	tsp->host_id = temp[1];
> -
> -	return tsp;
> -}
> -
>   static int k3_r5_core_of_init(struct platform_device *pdev)
>   {
>   	struct device *dev = &pdev->dev;
> @@ -1633,7 +1607,7 @@ static int k3_r5_core_of_init(struct platform_device *pdev)
>   		goto err;
>   	}
>   
> -	core->tsp = k3_r5_core_of_get_tsp(dev, core->ti_sci);
> +	core->tsp = ti_sci_proc_of_get_tsp(dev, core->ti_sci);
>   	if (IS_ERR(core->tsp)) {
>   		ret = PTR_ERR(core->tsp);
>   		dev_err(dev, "failed to construct ti-sci proc control, ret = %d\n",
> diff --git a/drivers/remoteproc/ti_sci_proc.h b/drivers/remoteproc/ti_sci_proc.h
> index 778558abcdcc5..f3911ce75252e 100644
> --- a/drivers/remoteproc/ti_sci_proc.h
> +++ b/drivers/remoteproc/ti_sci_proc.h
> @@ -28,6 +28,32 @@ struct ti_sci_proc {
>   	u8 host_id;
>   };
>   
> +static inline
> +struct ti_sci_proc *ti_sci_proc_of_get_tsp(struct device *dev,
> +					   const struct ti_sci_handle *sci)
> +{
> +	struct ti_sci_proc *tsp;
> +	u32 temp[2];
> +	int ret;
> +
> +	ret = of_property_read_u32_array(dev_of_node(dev), "ti,sci-proc-ids",
> +					 temp, 2);
> +	if (ret < 0)
> +		return ERR_PTR(ret);
> +
> +	tsp = devm_kzalloc(dev, sizeof(*tsp), GFP_KERNEL);
> +	if (!tsp)
> +		return ERR_PTR(-ENOMEM);
> +
> +	tsp->dev = dev;
> +	tsp->sci = sci;
> +	tsp->ops = &sci->ops.proc_ops;
> +	tsp->proc_id = temp[0];
> +	tsp->host_id = temp[1];
> +
> +	return tsp;
> +}
> +
>   static inline int ti_sci_proc_request(struct ti_sci_proc *tsp)
>   {
>   	int ret;

Re: [PATCH v11 3/9] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem

[Mathieu Poirier]

Hey Vignesh.

On Mon, Aug 19, 2024 at 02:02:31PM +0530, Vignesh Raghavendra wrote:
> [...]
> 
> Hi Mathieu
> 
> On 16/08/24 20:06, Mathieu Poirier wrote:
> >>> +/*
> >>> + * Attach to a running M4 remote processor (IPC-only mode)
> >>> + *
> >>> + * The remote processor is already booted, so there is no need to issue any
> >>> + * TI-SCI commands to boot the M4 core. This callback is used only in IPC-only
> >>> + * mode.
> >>> + */
> >>> +static int k3_m4_rproc_attach(struct rproc *rproc)
> >>> +{
> >>> +	struct k3_m4_rproc *kproc = rproc->priv;
> >>> +	int ret;
> >>> +
> >>> +	ret = k3_m4_rproc_ping_mbox(kproc);
> >>> +	if (ret)
> >>> +		return ret;
> >>> +
> >>> +	return 0;
> >>> +}
> >>> +
> >>> +/*
> >>> + * Detach from a running M4 remote processor (IPC-only mode)
> >>> + *
> >>> + * This rproc detach callback performs the opposite operation to attach
> >>> + * callback, the M4 core is not stopped and will be left to continue to
> >>> + * run its booted firmware. This callback is invoked only in IPC-only mode.
> >>> + */
> >>> +static int k3_m4_rproc_detach(struct rproc *rproc)
> >>> +{
> >>> +	return 0;
> >>> +}
> >> Please remove.
> > Forget this comment since it would cause an error in __rproc_detach().  
> > 
> >> Other than the above I'm good with this driver.  That said I can't move forward
> >> without a nod from the DT crew.  I also noticed a fair amount of code
> >> duplication with the k3_r5 and k3_dsp drivers.  Dealing with that should not be
> >> part of the current work but will need to be done before another k3 driver can
> >> be merged.
> >>
> 
> > The above still apply though.
> 
> Me or Nishanth will pick up the SoC DT patches via TI SoC tree, once the
> driver patches are merged. Feel free to ignore those but queue
> dt-bindings (already has DT maintainers ack) and driver patches via
> rproc tree.
> 

Can you provide a link where the DT maintainers have acknowledged the bindings?

> 
> -- 
> Regards
> Vignesh

Re: [PATCH v11 3/9] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem

[Krzysztof Kozlowski]

On 19/08/2024 17:32, Mathieu Poirier wrote:

>>>> Please remove.
>>> Forget this comment since it would cause an error in __rproc_detach().  
>>>
>>>> Other than the above I'm good with this driver.  That said I can't move forward
>>>> without a nod from the DT crew.  I also noticed a fair amount of code
>>>> duplication with the k3_r5 and k3_dsp drivers.  Dealing with that should not be
>>>> part of the current work but will need to be done before another k3 driver can
>>>> be merged.
>>>>
>>
>>> The above still apply though.
>>
>> Me or Nishanth will pick up the SoC DT patches via TI SoC tree, once the
>> driver patches are merged. Feel free to ignore those but queue
>> dt-bindings (already has DT maintainers ack) and driver patches via
>> rproc tree.
>>
> 
> Can you provide a link where the DT maintainers have acknowledged the bindings?

The reviewed-by tag serves as acknowledgment as well and the binding
patch has it. Conor gave it on some earlier version of the patchset. I
did not check if there were any significant changes in the meantime, though.


Best regards,
Krzysztof

Re: [PATCH v11 3/9] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem

[Andrew Davis]

On 8/19/24 10:39 AM, Krzysztof Kozlowski wrote:
> On 19/08/2024 17:32, Mathieu Poirier wrote:
> 
>>>>> Please remove.
>>>> Forget this comment since it would cause an error in __rproc_detach().
>>>>
>>>>> Other than the above I'm good with this driver.  That said I can't move forward
>>>>> without a nod from the DT crew.  I also noticed a fair amount of code
>>>>> duplication with the k3_r5 and k3_dsp drivers.  Dealing with that should not be
>>>>> part of the current work but will need to be done before another k3 driver can
>>>>> be merged.
>>>>>
>>>
>>>> The above still apply though.
>>>
>>> Me or Nishanth will pick up the SoC DT patches via TI SoC tree, once the
>>> driver patches are merged. Feel free to ignore those but queue
>>> dt-bindings (already has DT maintainers ack) and driver patches via
>>> rproc tree.
>>>
>>
>> Can you provide a link where the DT maintainers have acknowledged the bindings?
> 
> The reviewed-by tag serves as acknowledgment as well and the binding
> patch has it. Conor gave it on some earlier version of the patchset. I
> did not check if there were any significant changes in the meantime, though.
> 

Was reviewed in v8:
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240424190612.17349-2-afd@ti.com/#3302840

If there was any significant changes since I would have dropped the tag.

Andrew

> 
> Best regards,
> Krzysztof
> 

Re: [PATCH v11 3/9] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem

[Mathieu Poirier]

On Mon, Aug 19, 2024 at 10:54:11AM -0500, Andrew Davis wrote:
> On 8/19/24 10:39 AM, Krzysztof Kozlowski wrote:
> > On 19/08/2024 17:32, Mathieu Poirier wrote:
> > 
> > > > > > Please remove.
> > > > > Forget this comment since it would cause an error in __rproc_detach().
> > > > > 
> > > > > > Other than the above I'm good with this driver.  That said I can't move forward
> > > > > > without a nod from the DT crew.  I also noticed a fair amount of code
> > > > > > duplication with the k3_r5 and k3_dsp drivers.  Dealing with that should not be
> > > > > > part of the current work but will need to be done before another k3 driver can
> > > > > > be merged.
> > > > > > 
> > > > 
> > > > > The above still apply though.
> > > > 
> > > > Me or Nishanth will pick up the SoC DT patches via TI SoC tree, once the
> > > > driver patches are merged. Feel free to ignore those but queue
> > > > dt-bindings (already has DT maintainers ack) and driver patches via
> > > > rproc tree.
> > > > 
> > > 
> > > Can you provide a link where the DT maintainers have acknowledged the bindings?
> > 
> > The reviewed-by tag serves as acknowledgment as well and the binding
> > patch has it. Conor gave it on some earlier version of the patchset. I
> > did not check if there were any significant changes in the meantime, though.
> > 
> 
> Was reviewed in v8:
> https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240424190612.17349-2-afd@ti.com/#3302840
>

I didn't notice Conor had joined the DT crew and as such was expecting something
from either Rob or Krzysztof.  I am applying this set.

Thanks,
Mathieu

> If there was any significant changes since I would have dropped the tag.
> 
> Andrew
> 
> > 
> > Best regards,
> > Krzysztof
> > 

Re: [PATCH v11 9/9] arm64: defconfig: Enable TI K3 M4 remoteproc driver

[Daniel Schultz]

Hey,

it looks like this patch is missing in 6.13-rc6 while the driver and DTS 
changes got merged. Gentle ping if it's not somewhere else in a queue 
for 6.14.

- Daniel

On 02.08.24 17:21, Andrew Davis wrote:
> From: Hari Nagalla <hnagalla@ti.com>
>
> Some K3 platform devices (AM64x, AM62x) have a Cortex M4 core. Build
> the M4 remote proc driver as a module for these platforms.
>
> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
> Signed-off-by: Andrew Davis <afd@ti.com>
> ---
>   arch/arm64/configs/defconfig | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 7d32fca649965..33b0487b0d607 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -1383,6 +1383,7 @@ CONFIG_QCOM_Q6V5_PAS=m
>   CONFIG_QCOM_SYSMON=m
>   CONFIG_QCOM_WCNSS_PIL=m
>   CONFIG_TI_K3_DSP_REMOTEPROC=m
> +CONFIG_TI_K3_M4_REMOTEPROC=m
>   CONFIG_TI_K3_R5_REMOTEPROC=m
>   CONFIG_RPMSG_CHAR=m
>   CONFIG_RPMSG_CTRL=m

Re: (subset) [PATCH v11 0/9] TI K3 M4F support on AM62 and AM64 SoCs

[Nishanth Menon]

Hi Andrew Davis,

On Fri, 02 Aug 2024 10:21:00 -0500, Andrew Davis wrote:
> This is the continuation of the M4F RProc support series from here[0].
> I'm helping out with the upstream task for Hari and so versions (v8+)
> is a little different than the previous(v7-) postings[0]. Most notable
> change I've introduced being the patches factoring out common support
> from the current K3 R5 and DSP drivers have been dropped. I'd like
> to do that re-factor *after* getting this driver in shape, that way
> we have 3 similar drivers to factor out from vs trying to make those
> changes in parallel with the series adding M4 support.
> 
> [...]

I have applied the following to branch ti-k3-config-next on [1].
Thank you!

[9/9] arm64: defconfig: Enable TI K3 M4 remoteproc driver
      commit: 184caba444cfd4b90231de7d071b9966c115c29f

Thanks for the headsup Daniel.

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D