[PATCH v4 0/5] remoteproc: imx_rproc: Support i.MX95

[PATCH v4 0/5] remoteproc: imx_rproc: Support i.MX95

[Peng Fan]

i.MX95 features a Cortex-M33 core, six Cortex-A55 cores, and
one Cortex-M7 core. The System Control Management Interface(SCMI)
firmware runs on the M33 core. The i.MX95 SCMI firmware named System
Manager(SM) includes vendor extension protocols, Logical Machine
Management(LMM) protocol and CPU protocol and etc.

There are three cases for M7:
(1) M7 in a separate Logical Machine(LM) that Linux couldn't control it.
(2) M7 in a separate Logical Machine that Linux could control it using
    LMM protocol
(3) M7 runs in same Logical Machine as A55, so Linux could control it
    using CPU protocol

In patch 2, Use LMM and CPU protocol to manage M7. More info could be
found in the patch commit log

Current setup relies on pre-Linux software(U-Boot) to do
M7 TCM ECC initialization. In future, we could add the support in Linux
to decouple U-Boot and Linux.

Patchset was tested with below boot images when the patchset based on next-20250526:
imx-boot-variant-rpmsg-imx95-19x19-lpddr5-evk-sd.bin-flash_lpboot_sm_a55 (Use LMM protocol)
imx-boot-variant-alt-imx95-19x19-lpddr5-evk-sd.bin-flash_alt (Use CPU protocol)
imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_a55 (M7 not under A55 control)
imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_all (M7 not under A55 control)

Patchset was tested again with rebase on next-20250623
Patchset was tested again with rebase on next-20250710

Patchset is re-based on next-20250603.

Thanks for Daniel/Frank helping review the patchset before posting out to list.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Changes in v4:
- Move the lmm permission check code to a separate
  function(imx_rproc_sm_lmm_prepare) in patch 3.
- Check return value of scmi_imx_cpu_started in patch 3
- Rebased to next-20250710 and tested on i.MX95-19x19-EVK
- Add R-b from Frank for patch 1-4 and A-b from Krzysztof for patch 1
- Drop mu7 from patch 5, because mu7 status was already okay.
- Link to v3: https://lore.kernel.org/r/20250625-imx95-rproc-1-v3-0-699031f5926d@nxp.com

Changes in v3:
- Drop fsl,lmm-id and fsl,cpu-id for binding in patch 1
- Add lmid and cpuid in driver patch 2.
- Add i.MX95 lmid and cpuid in patch 3
- Rebased to linux-next-6-23 and tested with this new rebased version
- Add dtsi/dts patch 4,5 to give people a view on how it is used per Krzysztof
- Daniel's R-b are still kept after talk with Daniel
- Link to v2: https://lore.kernel.org/r/20250606-imx95-rproc-1-v2-0-a2bd64438be9@nxp.com

Changes in v2:
- Typo fix in patch 2 commit message
- Move the m7 address mapping array from patch 2 to patch 3
- Add R-b from Daniel to patch 3
- Link to v1: https://lore.kernel.org/r/20250604-imx95-rproc-1-v1-0-a6e5f512731c@nxp.com

---
Peng Fan (5):
      dt-bindings: remoteproc: fsl,imx-rproc: Add support for i.MX95
      remoteproc: imx_rproc: Add support for System Manager API
      remoteproc: imx_rproc: Add support for i.MX95
      arm64: dts: imx95: Add SCMI LMM/CPU nodes
      arm64: dts: imx95-19x19-evk: Add CM7 nodes and vdev related memory regions

 .../bindings/remoteproc/fsl,imx-rproc.yaml         |   1 +
 arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts  |  41 ++++++
 arch/arm64/boot/dts/freescale/imx95.dtsi           |   8 ++
 drivers/remoteproc/imx_rproc.c                     | 147 ++++++++++++++++++++-
 drivers/remoteproc/imx_rproc.h                     |   5 +
 5 files changed, 199 insertions(+), 3 deletions(-)
---
base-commit: 78863a3617803fcc11f7f7432efc9f74d4ca3105
change-id: 20250525-imx95-rproc-1-20bb74ddc8af

Best regards,
-- 
Peng Fan <peng.fan@nxp.com>

[PATCH v4 1/5] dt-bindings: remoteproc: fsl,imx-rproc: Add support for i.MX95

[Peng Fan]

Add compatible string for the Cortex-M7 core in i.MX95

Reviewed-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index 57d75acb0b5e52ca49d1361176fdebc18a0bf7a2..ce8ec0119469c8fc0979a192b6e3d3a03108d7d2 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -28,6 +28,7 @@ properties:
       - fsl,imx8qxp-cm4
       - fsl,imx8ulp-cm33
       - fsl,imx93-cm33
+      - fsl,imx95-cm7
 
   clocks:
     maxItems: 1

-- 
2.37.1

[PATCH v4 2/5] remoteproc: imx_rproc: Add support for System Manager API

[Peng Fan]

i.MX95 features a Cortex-M33 core, six Cortex-A55 cores, and
one Cortex-M7 core. The System Control Management Interface(SCMI)
firmware runs on the M33 core. The i.MX95 SCMI firmware named System
Manager(SM) includes vendor extension protocols, Logical Machine
Management(LMM) protocol and CPU protocol and etc.

There are three cases for M7:
 (1) M7 in a separate Logical Machine(LM) that Linux can't control it.
 (2) M7 in a separate Logical Machine that Linux can control it using
     LMM protocol
 (3) M7 runs in same Logical Machine as A55, so Linux can control it
     using CPU protocol

So extend the driver to using LMM and CPU protocol to manage the M7 core.
 - Add IMX_RPROC_SM to indicate the remote core runs on a SoC that
   has System Manager.
 - Compare linux LM ID(got using scmi_imx_lmm_info) and M7 LM ID(the ID
   is fixed as 1 in SM firmware if M7 is in a seprate LM),
   if Linux LM ID equals M7 LM ID(linux and M7 in same LM), use CPU
   protocol to start/stop. Otherwise, use LMM protocol to start/stop.
   Whether using CPU or LMM protocol to start/stop, the M7 status
   detection could use CPU protocol to detect started or not. So
   in imx_rproc_detect_mode, use scmi_imx_cpu_started to check the
   status of M7.
 - For above case 1 and 2, Use SCMI_IMX_LMM_POWER_ON to detect whether
   the M7 LM is under control of A55 LM.

Current setup relies on pre-Linux software(U-Boot) to do
M7 TCM ECC initialization. In future, we could add the support in Linux
to decouple U-Boot and Linux.

Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 drivers/remoteproc/imx_rproc.c | 122 ++++++++++++++++++++++++++++++++++++++++-
 drivers/remoteproc/imx_rproc.h |   5 ++
 2 files changed, 124 insertions(+), 3 deletions(-)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 74299af1d7f10a0db794de494c52304b2323b89f..11e911ac80bafbc58e10e6fec9f703a30a686c3f 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -8,6 +8,7 @@
 #include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/firmware/imx/sci.h>
+#include <linux/firmware/imx/sm.h>
 #include <linux/interrupt.h>
 #include <linux/kernel.h>
 #include <linux/mailbox_client.h>
@@ -21,6 +22,7 @@
 #include <linux/reboot.h>
 #include <linux/regmap.h>
 #include <linux/remoteproc.h>
+#include <linux/scmi_imx_protocol.h>
 #include <linux/workqueue.h>
 
 #include "imx_rproc.h"
@@ -91,6 +93,11 @@ struct imx_rproc_mem {
 #define ATT_CORE_MASK   0xffff
 #define ATT_CORE(I)     BIT((I))
 
+/* Logical Machine Operation */
+#define IMX_RPROC_FLAGS_SM_LMM_OP	BIT(0)
+/* Linux has permission to handle the Logical Machine of remote cores */
+#define IMX_RPROC_FLAGS_SM_LMM_AVAIL	BIT(1)
+
 static int imx_rproc_xtr_mbox_init(struct rproc *rproc, bool tx_block);
 static void imx_rproc_free_mbox(struct rproc *rproc);
 
@@ -115,6 +122,8 @@ struct imx_rproc {
 	u32				entry;		/* cpu start address */
 	u32				core_index;
 	struct dev_pm_domain_list	*pd_list;
+	/* For i.MX System Manager based systems */
+	u32				flags;
 };
 
 static const struct imx_rproc_att imx_rproc_att_imx93[] = {
@@ -393,6 +402,30 @@ static int imx_rproc_start(struct rproc *rproc)
 	case IMX_RPROC_SCU_API:
 		ret = imx_sc_pm_cpu_start(priv->ipc_handle, priv->rsrc_id, true, priv->entry);
 		break;
+	case IMX_RPROC_SM:
+		if (priv->flags & IMX_RPROC_FLAGS_SM_LMM_OP) {
+			if (!(priv->flags & IMX_RPROC_FLAGS_SM_LMM_AVAIL))
+				return -EACCES;
+
+			ret = scmi_imx_lmm_reset_vector_set(dcfg->lmid, dcfg->cpuid, 0, 0);
+			if (ret) {
+				dev_err(dev, "Failed to set reset vector lmid(%u), cpuid(%u): %d\n",
+					dcfg->lmid, dcfg->cpuid, ret);
+			}
+
+			ret = scmi_imx_lmm_operation(dcfg->lmid, SCMI_IMX_LMM_BOOT, 0);
+			if (ret)
+				dev_err(dev, "Failed to boot lmm(%d): %d\n", ret, dcfg->lmid);
+		} else {
+			ret = scmi_imx_cpu_reset_vector_set(dcfg->cpuid, 0, true, false, false);
+			if (ret) {
+				dev_err(dev, "Failed to set reset vector cpuid(%u): %d\n",
+					dcfg->cpuid, ret);
+			}
+
+			ret = scmi_imx_cpu_start(dcfg->cpuid, true);
+		}
+		break;
 	default:
 		return -EOPNOTSUPP;
 	}
@@ -435,6 +468,16 @@ static int imx_rproc_stop(struct rproc *rproc)
 	case IMX_RPROC_SCU_API:
 		ret = imx_sc_pm_cpu_start(priv->ipc_handle, priv->rsrc_id, false, priv->entry);
 		break;
+	case IMX_RPROC_SM:
+		if (priv->flags & IMX_RPROC_FLAGS_SM_LMM_OP) {
+			if (priv->flags & IMX_RPROC_FLAGS_SM_LMM_AVAIL)
+				ret = scmi_imx_lmm_operation(dcfg->lmid, SCMI_IMX_LMM_SHUTDOWN, 0);
+			else
+				ret = -EACCES;
+		} else {
+			ret = scmi_imx_cpu_start(dcfg->cpuid, false);
+		}
+		break;
 	default:
 		return -EOPNOTSUPP;
 	}
@@ -545,10 +588,48 @@ static int imx_rproc_mem_release(struct rproc *rproc,
 	return 0;
 }
 
+static int imx_rproc_sm_lmm_prepare(struct rproc *rproc)
+{
+	struct imx_rproc *priv = rproc->priv;
+	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
+	int ret;
+
+	if (!(priv->flags & IMX_RPROC_FLAGS_SM_LMM_OP))
+		return 0;
+
+	/*
+	 * Power on the Logical Machine to make sure TCM is available.
+	 * Also serve as permission check. If in different Logical
+	 * Machine, and linux has permission to handle the Logical
+	 * Machine, set IMX_RPROC_FLAGS_SM_LMM_AVAIL.
+	 */
+	ret = scmi_imx_lmm_operation(dcfg->lmid, SCMI_IMX_LMM_POWER_ON, 0);
+	if (ret == 0) {
+		dev_info(priv->dev, "lmm(%d) powered on\n", dcfg->lmid);
+		priv->flags |= IMX_RPROC_FLAGS_SM_LMM_AVAIL;
+	} else if (ret == -EACCES) {
+		dev_info(priv->dev, "lmm(%d) not under Linux Control\n", dcfg->lmid);
+		/*
+		 * If remote cores boots up in detached mode, continue;
+		 * else linux has no permission, return -EACCES.
+		 */
+		if (priv->rproc->state != RPROC_DETACHED)
+			return -EACCES;
+
+		/* work in state RPROC_DETACHED */
+		ret = 0;
+	} else if (ret) {
+		dev_err(priv->dev, "Failed to power on lmm(%d): %d\n", ret, dcfg->lmid);
+	}
+
+	return ret;
+}
+
 static int imx_rproc_prepare(struct rproc *rproc)
 {
 	struct imx_rproc *priv = rproc->priv;
 	struct device_node *np = priv->dev->of_node;
+	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
 	struct of_phandle_iterator it;
 	struct rproc_mem_entry *mem;
 	struct reserved_mem *rmem;
@@ -592,7 +673,10 @@ static int imx_rproc_prepare(struct rproc *rproc)
 		rproc_add_carveout(rproc, mem);
 	}
 
-	return  0;
+	if (dcfg->method == IMX_RPROC_SM)
+		return imx_rproc_sm_lmm_prepare(rproc);
+
+	return 0;
 }
 
 static int imx_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
@@ -911,13 +995,41 @@ static int imx_rproc_detect_mode(struct imx_rproc *priv)
 	struct regmap_config config = { .name = "imx-rproc" };
 	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
 	struct device *dev = priv->dev;
+	struct scmi_imx_lmm_info info;
 	struct regmap *regmap;
 	struct arm_smccc_res res;
+	bool started = false;
 	int ret;
 	u32 val;
 	u8 pt;
 
 	switch (dcfg->method) {
+	case IMX_RPROC_SM:
+		/* Get current Linux Logical Machine ID */
+		ret = scmi_imx_lmm_info(LMM_ID_DISCOVER, &info);
+		if (ret) {
+			dev_err(dev, "Failed to get current LMM ID err: %d\n", ret);
+			return ret;
+		}
+
+		/*
+		 * Check whether remote processor is in same Logical Machine as Linux.
+		 * If no, need use Logical Machine API to manage remote processor, and
+		 * set IMX_RPROC_FLAGS_SM_LMM_OP.
+		 * If yes, use CPU protocol API to manage remote processor.
+		 */
+		if (dcfg->lmid != info.lmid) {
+			priv->flags |= IMX_RPROC_FLAGS_SM_LMM_OP;
+			dev_info(dev, "Using LMM Protocol OPS\n");
+		} else {
+			dev_info(dev, "Using CPU Protocol OPS\n");
+		}
+
+		ret = scmi_imx_cpu_started(dcfg->cpuid, &started);
+		if (ret || started)
+			priv->rproc->state = RPROC_DETACHED;
+
+		return 0;
 	case IMX_RPROC_NONE:
 		priv->rproc->state = RPROC_DETACHED;
 		return 0;
@@ -1029,8 +1141,12 @@ static int imx_rproc_clk_enable(struct imx_rproc *priv)
 	struct device *dev = priv->dev;
 	int ret;
 
-	/* Remote core is not under control of Linux */
-	if (dcfg->method == IMX_RPROC_NONE)
+	/*
+	 * IMX_RPROC_NONE indicates not under control of Linux.
+	 * System Manager(SM) firmware automatically configures clock,
+	 * so bypass the clk settings for IMX_RPROC_SM.
+	 */
+	if (dcfg->method == IMX_RPROC_NONE || dcfg->method == IMX_RPROC_SM)
 		return 0;
 
 	priv->clk = devm_clk_get(dev, NULL);
diff --git a/drivers/remoteproc/imx_rproc.h b/drivers/remoteproc/imx_rproc.h
index cfd38d37e1467d1d9e6f89be146c0b53262b92a0..6fe8d975ed302967f27b7a4319a899e6f0822976 100644
--- a/drivers/remoteproc/imx_rproc.h
+++ b/drivers/remoteproc/imx_rproc.h
@@ -26,6 +26,8 @@ enum imx_rproc_method {
 	IMX_RPROC_SCU_API,
 	/* Through Reset Controller API */
 	IMX_RPROC_RESET_CONTROLLER,
+	/* Through System Manager */
+	IMX_RPROC_SM,
 };
 
 /* dcfg flags */
@@ -42,6 +44,9 @@ struct imx_rproc_dcfg {
 	size_t				att_size;
 	enum imx_rproc_method		method;
 	u32				flags;
+	/* For System Manager(SM) based SoCs, the IDs are from SM firmware */
+	u32				cpuid;
+	u32				lmid;
 };
 
 #endif /* _IMX_RPROC_H */

-- 
2.37.1

[PATCH v4 3/5] remoteproc: imx_rproc: Add support for i.MX95

[Peng Fan]

Add imx_rproc_cfg_imx95_m7 and address(TCM and DDR) mapping.
Add i.MX95 of_device_id entry.

Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 drivers/remoteproc/imx_rproc.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 11e911ac80bafbc58e10e6fec9f703a30a686c3f..e40d40e208e5f485c2da3a0f06d6775a10c2fb47 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -73,6 +73,10 @@
 
 #define IMX_SC_IRQ_GROUP_REBOOTED	5
 
+/* Must align with System Manager Firmware */
+#define IMX95_M7_CPUID			1
+#define IMX95_M7_LMID			1
+
 /**
  * struct imx_rproc_mem - slim internal memory structure
  * @cpu_addr: MPU virtual address of the memory region
@@ -126,6 +130,18 @@ struct imx_rproc {
 	u32				flags;
 };
 
+static const struct imx_rproc_att imx_rproc_att_imx95_m7[] = {
+	/* dev addr , sys addr  , size	    , flags */
+	/* TCM CODE NON-SECURE */
+	{ 0x00000000, 0x203C0000, 0x00040000, ATT_OWN | ATT_IOMEM },
+
+	/* TCM SYS NON-SECURE*/
+	{ 0x20000000, 0x20400000, 0x00040000, ATT_OWN | ATT_IOMEM },
+
+	/* DDR */
+	{ 0x80000000, 0x80000000, 0x50000000, 0 },
+};
+
 static const struct imx_rproc_att imx_rproc_att_imx93[] = {
 	/* dev addr , sys addr  , size	    , flags */
 	/* TCM CODE NON-SECURE */
@@ -372,6 +388,14 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx93 = {
 	.method		= IMX_RPROC_SMC,
 };
 
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx95_m7 = {
+	.att		= imx_rproc_att_imx95_m7,
+	.att_size	= ARRAY_SIZE(imx_rproc_att_imx95_m7),
+	.method		= IMX_RPROC_SM,
+	.cpuid		= IMX95_M7_CPUID,
+	.lmid		= IMX95_M7_LMID,
+};
+
 static int imx_rproc_start(struct rproc *rproc)
 {
 	struct imx_rproc *priv = rproc->priv;
@@ -1308,6 +1332,7 @@ static const struct of_device_id imx_rproc_of_match[] = {
 	{ .compatible = "fsl,imx8qm-cm4", .data = &imx_rproc_cfg_imx8qm },
 	{ .compatible = "fsl,imx8ulp-cm33", .data = &imx_rproc_cfg_imx8ulp },
 	{ .compatible = "fsl,imx93-cm33", .data = &imx_rproc_cfg_imx93 },
+	{ .compatible = "fsl,imx95-cm7", .data = &imx_rproc_cfg_imx95_m7 },
 	{},
 };
 MODULE_DEVICE_TABLE(of, imx_rproc_of_match);

-- 
2.37.1

[PATCH v4 4/5] arm64: dts: imx95: Add SCMI LMM/CPU nodes

[Peng Fan]

Add SCMI LMM/CPU nodes which is for remoteproc to handle remote cores.

Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx95.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
index 7ec30d54d4dfef0f904f5242dd25590e5d2fddd2..ccfe1823178be7c5dcb1534d1a196ec48f61ecbf 100644
--- a/arch/arm64/boot/dts/freescale/imx95.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
@@ -350,10 +350,18 @@ scmi_iomuxc: protocol@19 {
 				reg = <0x19>;
 			};
 
+			scmi_lmm: protocol@80 {
+				reg = <0x80>;
+			};
+
 			scmi_bbm: protocol@81 {
 				reg = <0x81>;
 			};
 
+			scmi_cpu: protocol@82 {
+				reg = <0x82>;
+			};
+
 			scmi_misc: protocol@84 {
 				reg = <0x84>;
 			};

-- 
2.37.1

[PATCH v4 5/5] arm64: dts: imx95-19x19-evk: Add CM7 nodes and vdev related memory regions

[Peng Fan]

Add CM7 nodes, vdev related memory regions for remoteproc.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts | 41 +++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
index 2f949a0d48d2d8066388884703c3b3cd678f16e1..3f047cbba29671fc31c9048a3eb7f0dbef4af613 100644
--- a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
@@ -75,6 +75,37 @@ linux_cma: linux,cma {
 			linux,cma-default;
 			reusable;
 		};
+
+		vdev0vring0: vdev0vring0@88000000 {
+			reg = <0 0x88000000 0 0x8000>;
+			no-map;
+		};
+
+		vdev0vring1: vdev0vring1@88008000 {
+			reg = <0 0x88008000 0 0x8000>;
+			no-map;
+		};
+
+		vdev1vring0: vdev1vring0@88010000 {
+			reg = <0 0x88010000 0 0x8000>;
+			no-map;
+		};
+
+		vdev1vring1: vdev1vring1@88018000 {
+			reg = <0 0x88018000 0 0x8000>;
+			no-map;
+		};
+
+		vdevbuffer: vdevbuffer@88020000 {
+			compatible = "shared-dma-pool";
+			reg = <0 0x88020000 0 0x100000>;
+			no-map;
+		};
+
+		rsc_table: rsc-table@88220000 {
+			reg = <0 0x88220000 0 0x1000>;
+			no-map;
+		};
 	};
 
 	flexcan1_phy: can-phy0 {
@@ -225,6 +256,16 @@ sound-wm8962 {
 				"IN3R", "AMIC",
 				"IN1R", "AMIC";
 	};
+
+	remoteproc-cm7 {
+		compatible = "fsl,imx95-cm7";
+		mbox-names = "tx", "rx", "rxdb";
+		mboxes = <&mu7 0 1>,
+			 <&mu7 1 1>,
+			 <&mu7 3 1>;
+		memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
+				<&vdev1vring0>, <&vdev1vring1>, <&rsc_table>;
+	};
 };
 
 &adc1 {

-- 
2.37.1

Re: [PATCH v4 0/5] remoteproc: imx_rproc: Support i.MX95

[Rob Herring (Arm)]

On Thu, 10 Jul 2025 20:08:00 +0800, Peng Fan wrote:
> i.MX95 features a Cortex-M33 core, six Cortex-A55 cores, and
> one Cortex-M7 core. The System Control Management Interface(SCMI)
> firmware runs on the M33 core. The i.MX95 SCMI firmware named System
> Manager(SM) includes vendor extension protocols, Logical Machine
> Management(LMM) protocol and CPU protocol and etc.
> 
> There are three cases for M7:
> (1) M7 in a separate Logical Machine(LM) that Linux couldn't control it.
> (2) M7 in a separate Logical Machine that Linux could control it using
>     LMM protocol
> (3) M7 runs in same Logical Machine as A55, so Linux could control it
>     using CPU protocol
> 
> In patch 2, Use LMM and CPU protocol to manage M7. More info could be
> found in the patch commit log
> 
> Current setup relies on pre-Linux software(U-Boot) to do
> M7 TCM ECC initialization. In future, we could add the support in Linux
> to decouple U-Boot and Linux.
> 
> Patchset was tested with below boot images when the patchset based on next-20250526:
> imx-boot-variant-rpmsg-imx95-19x19-lpddr5-evk-sd.bin-flash_lpboot_sm_a55 (Use LMM protocol)
> imx-boot-variant-alt-imx95-19x19-lpddr5-evk-sd.bin-flash_alt (Use CPU protocol)
> imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_a55 (M7 not under A55 control)
> imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_all (M7 not under A55 control)
> 
> Patchset was tested again with rebase on next-20250623
> Patchset was tested again with rebase on next-20250710
> 
> Patchset is re-based on next-20250603.
> 
> Thanks for Daniel/Frank helping review the patchset before posting out to list.
> 
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> Changes in v4:
> - Move the lmm permission check code to a separate
>   function(imx_rproc_sm_lmm_prepare) in patch 3.
> - Check return value of scmi_imx_cpu_started in patch 3
> - Rebased to next-20250710 and tested on i.MX95-19x19-EVK
> - Add R-b from Frank for patch 1-4 and A-b from Krzysztof for patch 1
> - Drop mu7 from patch 5, because mu7 status was already okay.
> - Link to v3: https://lore.kernel.org/r/20250625-imx95-rproc-1-v3-0-699031f5926d@nxp.com
> 
> Changes in v3:
> - Drop fsl,lmm-id and fsl,cpu-id for binding in patch 1
> - Add lmid and cpuid in driver patch 2.
> - Add i.MX95 lmid and cpuid in patch 3
> - Rebased to linux-next-6-23 and tested with this new rebased version
> - Add dtsi/dts patch 4,5 to give people a view on how it is used per Krzysztof
> - Daniel's R-b are still kept after talk with Daniel
> - Link to v2: https://lore.kernel.org/r/20250606-imx95-rproc-1-v2-0-a2bd64438be9@nxp.com
> 
> Changes in v2:
> - Typo fix in patch 2 commit message
> - Move the m7 address mapping array from patch 2 to patch 3
> - Add R-b from Daniel to patch 3
> - Link to v1: https://lore.kernel.org/r/20250604-imx95-rproc-1-v1-0-a6e5f512731c@nxp.com
> 
> ---
> Peng Fan (5):
>       dt-bindings: remoteproc: fsl,imx-rproc: Add support for i.MX95
>       remoteproc: imx_rproc: Add support for System Manager API
>       remoteproc: imx_rproc: Add support for i.MX95
>       arm64: dts: imx95: Add SCMI LMM/CPU nodes
>       arm64: dts: imx95-19x19-evk: Add CM7 nodes and vdev related memory regions
> 
>  .../bindings/remoteproc/fsl,imx-rproc.yaml         |   1 +
>  arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts  |  41 ++++++
>  arch/arm64/boot/dts/freescale/imx95.dtsi           |   8 ++
>  drivers/remoteproc/imx_rproc.c                     | 147 ++++++++++++++++++++-
>  drivers/remoteproc/imx_rproc.h                     |   5 +
>  5 files changed, 199 insertions(+), 3 deletions(-)
> ---
> base-commit: 78863a3617803fcc11f7f7432efc9f74d4ca3105
> change-id: 20250525-imx95-rproc-1-20bb74ddc8af
> 
> Best regards,
> --
> Peng Fan <peng.fan@nxp.com>
> 
> 
> 


My bot found new DTB warnings on the .dts files added or changed in this
series.

Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.

If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:

  pip3 install dtschema --upgrade


This patch series was applied (using b4) to base:
 Base: base-commit 78863a3617803fcc11f7f7432efc9f74d4ca3105 not known, ignoring
 Base: attempting to guess base-commit...
 Base: tags/next-20250710 (exact match)

If this is not the correct base, please add 'base-commit' tag
(or use b4 which does this automatically)

New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/freescale/' for 20250710-imx95-rproc-1-v4-0-a7123e857dfb@nxp.com:

arch/arm64/boot/dts/freescale/imx95-tqma9596sa-mb-smarc-2.dtb: scmi (arm,scmi): Unevaluated properties are not allowed ('protocol@80', 'protocol@81', 'protocol@82', 'protocol@84' were unexpected)
	from schema $id: http://devicetree.org/schemas/firmware/arm,scmi.yaml#

RE: [PATCH v4 0/5] remoteproc: imx_rproc: Support i.MX95

[Peng Fan]

> Subject: Re: [PATCH v4 0/5] remoteproc: imx_rproc: Support i.MX95
> 
[...] 
> New warnings running 'make CHECK_DTBS=y for
> arch/arm64/boot/dts/freescale/' for 20250710-imx95-rproc-1-v4-0-
> a7123e857dfb@nxp.com:
> 
> arch/arm64/boot/dts/freescale/imx95-tqma9596sa-mb-smarc-2.dtb:
> scmi (arm,scmi): Unevaluated properties are not allowed
> ('protocol@80', 'protocol@81', 'protocol@82', 'protocol@84' were
> unexpected)

Same as replied in v3.
This is because [1] is still not picked, not because of my patchset.

[1]https://lore.kernel.org/imx/20250513-whimsical-almond-quoll-e3ad5b@sudeepholla/

Thanks,
Peng.

Re: [PATCH v4 0/5] remoteproc: imx_rproc: Support i.MX95

[Mathieu Poirier]

On Mon, Jul 14, 2025 at 11:52:05AM +0000, Peng Fan wrote:
> > Subject: Re: [PATCH v4 0/5] remoteproc: imx_rproc: Support i.MX95
> > 
> [...] 
> > New warnings running 'make CHECK_DTBS=y for
> > arch/arm64/boot/dts/freescale/' for 20250710-imx95-rproc-1-v4-0-
> > a7123e857dfb@nxp.com:
> > 
> > arch/arm64/boot/dts/freescale/imx95-tqma9596sa-mb-smarc-2.dtb:
> > scmi (arm,scmi): Unevaluated properties are not allowed
> > ('protocol@80', 'protocol@81', 'protocol@82', 'protocol@84' were
> > unexpected)
> 
> Same as replied in v3.
> This is because [1] is still not picked, not because of my patchset.

I won't move on this patchset until this is resolved.

> 
> [1]https://lore.kernel.org/imx/20250513-whimsical-almond-quoll-e3ad5b@sudeepholla/
> 
> Thanks,
> Peng.

Re: [PATCH v4 0/5] remoteproc: imx_rproc: Support i.MX95

[Peng Fan]

On Thu, Jul 17, 2025 at 08:48:43AM -0600, Mathieu Poirier wrote:
>On Mon, Jul 14, 2025 at 11:52:05AM +0000, Peng Fan wrote:
>> > Subject: Re: [PATCH v4 0/5] remoteproc: imx_rproc: Support i.MX95
>> > 
>> [...] 
>> > New warnings running 'make CHECK_DTBS=y for
>> > arch/arm64/boot/dts/freescale/' for 20250710-imx95-rproc-1-v4-0-
>> > a7123e857dfb@nxp.com:
>> > 
>> > arch/arm64/boot/dts/freescale/imx95-tqma9596sa-mb-smarc-2.dtb:
>> > scmi (arm,scmi): Unevaluated properties are not allowed
>> > ('protocol@80', 'protocol@81', 'protocol@82', 'protocol@84' were
>> > unexpected)
>> 
>> Same as replied in v3.
>> This is because [1] is still not picked, not because of my patchset.
>
>I won't move on this patchset until this is resolved.
>

Not understand why hold on this patchset. I suppose you may not
understand what the error means. The warning is totally irrelevant
to this patchset, there is no dependency.

Others added a property to arch/arm64/boot/dts/freescale/imx95-tqma9596sa.dtsi
&scmi_bbm {
        linux,code = <KEY_POWER>;
};
But this "linux,code" property not landed(missed to be picked up) to DT binding.

This patchset does not touch scmi_bbm. I could help address the warning
in the other patch, but I do not see why "linux,code" under scmi_bbm node
could block this patchset.

Please help clarify if you still think to hold on this patchset.

BTW: with [1] "remoteproc: imx_rproc: skip clock enable when M-core is managed by the SCU"
merged in Ulf's tree, there is a minor conflict with patch 2. Please suggest
what I should do with this patchset.

[1]https://lore.kernel.org/linux-remoteproc/20250629172512.14857-3-hiagofranco@gmail.com/T/#u

Thanks,
Peng

Re: [PATCH v4 0/5] remoteproc: imx_rproc: Support i.MX95

[Krzysztof Kozlowski]

On 18/07/2025 10:20, Peng Fan wrote:
> On Thu, Jul 17, 2025 at 08:48:43AM -0600, Mathieu Poirier wrote:
>> On Mon, Jul 14, 2025 at 11:52:05AM +0000, Peng Fan wrote:
>>>> Subject: Re: [PATCH v4 0/5] remoteproc: imx_rproc: Support i.MX95
>>>>
>>> [...] 
>>>> New warnings running 'make CHECK_DTBS=y for
>>>> arch/arm64/boot/dts/freescale/' for 20250710-imx95-rproc-1-v4-0-
>>>> a7123e857dfb@nxp.com:
>>>>
>>>> arch/arm64/boot/dts/freescale/imx95-tqma9596sa-mb-smarc-2.dtb:
>>>> scmi (arm,scmi): Unevaluated properties are not allowed
>>>> ('protocol@80', 'protocol@81', 'protocol@82', 'protocol@84' were
>>>> unexpected)
>>>
>>> Same as replied in v3.
>>> This is because [1] is still not picked, not because of my patchset.
>>
>> I won't move on this patchset until this is resolved.
>>
> 
> Not understand why hold on this patchset. I suppose you may not
> understand what the error means. The warning is totally irrelevant
> to this patchset, there is no dependency.
> 
> Others added a property to arch/arm64/boot/dts/freescale/imx95-tqma9596sa.dtsi
> &scmi_bbm {
>         linux,code = <KEY_POWER>;
> };
> But this "linux,code" property not landed(missed to be picked up) to DT binding.
> 
> This patchset does not touch scmi_bbm. I could help address the warning
> in the other patch, but I do not see why "linux,code" under scmi_bbm node
> could block this patchset.


Lack of proper binding for that property might hide other issues with
this patchset, because schema is not evaluated. Make your DTS and
bindings correct, then start growing the device nodes.

Best regards,
Krzysztof

RE: [PATCH v4 0/5] remoteproc: imx_rproc: Support i.MX95

[Peng Fan]

> Subject: Re: [PATCH v4 0/5] remoteproc: imx_rproc: Support i.MX95
> 
> On 18/07/2025 10:20, Peng Fan wrote:
> > On Thu, Jul 17, 2025 at 08:48:43AM -0600, Mathieu Poirier wrote:
> >> On Mon, Jul 14, 2025 at 11:52:05AM +0000, Peng Fan wrote:
> >>>> Subject: Re: [PATCH v4 0/5] remoteproc: imx_rproc: Support
> i.MX95
> >>>>
> >>> [...]
> >>>> New warnings running 'make CHECK_DTBS=y for
> >>>> arch/arm64/boot/dts/freescale/' for 20250710-imx95-rproc-1-v4-
> 0-
> >>>> a7123e857dfb@nxp.com:
> >>>>
> >>>> arch/arm64/boot/dts/freescale/imx95-tqma9596sa-mb-smarc-
> 2.dtb:
> >>>> scmi (arm,scmi): Unevaluated properties are not allowed
> >>>> ('protocol@80', 'protocol@81', 'protocol@82', 'protocol@84'
> were
> >>>> unexpected)
> >>>
> >>> Same as replied in v3.
> >>> This is because [1] is still not picked, not because of my patchset.
> >>
> >> I won't move on this patchset until this is resolved.
> >>
> >
> > Not understand why hold on this patchset. I suppose you may not
> > understand what the error means. The warning is totally irrelevant to
> > this patchset, there is no dependency.
> >
> > Others added a property to
> > arch/arm64/boot/dts/freescale/imx95-tqma9596sa.dtsi
> > &scmi_bbm {
> >         linux,code = <KEY_POWER>;
> > };
> > But this "linux,code" property not landed(missed to be picked up) to
> DT binding.
> >
> > This patchset does not touch scmi_bbm. I could help address the
> > warning in the other patch, but I do not see why "linux,code" under
> > scmi_bbm node could block this patchset.
> 
> 
> Lack of proper binding for that property might hide other issues with
> this patchset, because schema is not evaluated. Make your DTS and
> bindings correct, then start growing the device nodes.

Not NXP board, I could help fix, but that should not block this patchset.

There is no hidden issue. I removed "linux,code" from the tqma9596sa
board dts, and no warning with CHECK_DTBS.

More info:
This patchset does nothing with scmi_bbm nodes and bindings.
The warning triggered by the board which is not NXP
board(arch/arm64/boot/dts/freescale/imx95-tqma9596sa.dtsi).
This patchset does not touch that board dts.

What this patchset added is scmi_cpu and scmi_lmm nodes in
imx95.dtsi. The binding check already pass when I worked
on the scmi lmm/cpu protocol patchset.

Back to DTB check, by removing
linux,code = <KEY_BACK> from 
arch/arm64/boot/dts/freescale/imx95-tqma9596sa.dtsi,
there is no warning.

Regards,
Peng.

> 
> Best regards,
> Krzysztof

Re: [PATCH v4 0/5] remoteproc: imx_rproc: Support i.MX95

[Mathieu Poirier]

On Fri, Jul 18, 2025 at 04:20:34PM +0800, Peng Fan wrote:
> On Thu, Jul 17, 2025 at 08:48:43AM -0600, Mathieu Poirier wrote:
> >On Mon, Jul 14, 2025 at 11:52:05AM +0000, Peng Fan wrote:
> >> > Subject: Re: [PATCH v4 0/5] remoteproc: imx_rproc: Support i.MX95
> >> > 
> >> [...] 
> >> > New warnings running 'make CHECK_DTBS=y for
> >> > arch/arm64/boot/dts/freescale/' for 20250710-imx95-rproc-1-v4-0-
> >> > a7123e857dfb@nxp.com:
> >> > 
> >> > arch/arm64/boot/dts/freescale/imx95-tqma9596sa-mb-smarc-2.dtb:
> >> > scmi (arm,scmi): Unevaluated properties are not allowed
> >> > ('protocol@80', 'protocol@81', 'protocol@82', 'protocol@84' were
> >> > unexpected)
> >> 
> >> Same as replied in v3.
> >> This is because [1] is still not picked, not because of my patchset.
> >
> >I won't move on this patchset until this is resolved.
> >
> 
> Not understand why hold on this patchset. I suppose you may not
> understand what the error means. The warning is totally irrelevant
> to this patchset, there is no dependency.
> 
> Others added a property to arch/arm64/boot/dts/freescale/imx95-tqma9596sa.dtsi
> &scmi_bbm {
>         linux,code = <KEY_POWER>;
> };
> But this "linux,code" property not landed(missed to be picked up) to DT binding.
> 
> This patchset does not touch scmi_bbm. I could help address the warning
> in the other patch, but I do not see why "linux,code" under scmi_bbm node
> could block this patchset.
> 
> Please help clarify if you still think to hold on this patchset.
> 
> BTW: with [1] "remoteproc: imx_rproc: skip clock enable when M-core is managed by the SCU"
> merged in Ulf's tree, there is a minor conflict with patch 2. Please suggest
> what I should do with this patchset.
>

I was afraid of that.  The best way forward with this work is to wait for the
"linux,code" property to be picked up by Sudeep.  I suggest you make sure that
he, or anyone else, picks it up for the next merge window.  If that happens
everything should be set for you to resend this patchset when 6.17-rc1 comes
out.
 
> [1]https://lore.kernel.org/linux-remoteproc/20250629172512.14857-3-hiagofranco@gmail.com/T/#u
> 
> Thanks,
> Peng

Re: [PATCH v4 0/5] remoteproc: imx_rproc: Support i.MX95

[Peng Fan]

On Fri, Jul 18, 2025 at 11:06:04AM -0600, Mathieu Poirier wrote:
>On Fri, Jul 18, 2025 at 04:20:34PM +0800, Peng Fan wrote:
>> On Thu, Jul 17, 2025 at 08:48:43AM -0600, Mathieu Poirier wrote:
>> >On Mon, Jul 14, 2025 at 11:52:05AM +0000, Peng Fan wrote:
>> >> > Subject: Re: [PATCH v4 0/5] remoteproc: imx_rproc: Support i.MX95
>> >> > 
>> >> [...] 
>> >> > New warnings running 'make CHECK_DTBS=y for
>> >> > arch/arm64/boot/dts/freescale/' for 20250710-imx95-rproc-1-v4-0-
>> >> > a7123e857dfb@nxp.com:
>> >> > 
>> >> > arch/arm64/boot/dts/freescale/imx95-tqma9596sa-mb-smarc-2.dtb:
>> >> > scmi (arm,scmi): Unevaluated properties are not allowed
>> >> > ('protocol@80', 'protocol@81', 'protocol@82', 'protocol@84' were
>> >> > unexpected)
>> >> 
>> >> Same as replied in v3.
>> >> This is because [1] is still not picked, not because of my patchset.
>> >
>> >I won't move on this patchset until this is resolved.
>> >
>> 
>> Not understand why hold on this patchset. I suppose you may not
>> understand what the error means. The warning is totally irrelevant
>> to this patchset, there is no dependency.
>> 
>> Others added a property to arch/arm64/boot/dts/freescale/imx95-tqma9596sa.dtsi
>> &scmi_bbm {
>>         linux,code = <KEY_POWER>;
>> };
>> But this "linux,code" property not landed(missed to be picked up) to DT binding.
>> 
>> This patchset does not touch scmi_bbm. I could help address the warning
>> in the other patch, but I do not see why "linux,code" under scmi_bbm node
>> could block this patchset.
>> 
>> Please help clarify if you still think to hold on this patchset.
>> 
>> BTW: with [1] "remoteproc: imx_rproc: skip clock enable when M-core is managed by the SCU"
>> merged in Ulf's tree, there is a minor conflict with patch 2. Please suggest
>> what I should do with this patchset.
>>
>
>I was afraid of that.  The best way forward with this work is to wait for the
>"linux,code" property to be picked up by Sudeep.  I suggest you make sure that
>he, or anyone else, picks it up for the next merge window.  If that happens


I respect you as maintainer, but there is no reason to block this patch
because of "linux,code" property. It is totally irrelevant.

Even if I help to resubmit that "linux,code" patch, there is no chance to
land into 6.17-rc1, both Sudeep and Shawn sent their PR to arm-soc earlier
before your comments. You could raise in V3.. which there was time left.

>everything should be set for you to resend this patchset when 6.17-rc1 comes
>out.

Because of the code conflict in Ulf's tree, I will hold on until 6.17-rc1.
Patch 4 and 5 will be removed from this patchset in V5. The two patches
should go through Shawn's tree, I will resend them in a separate thread
with "linux,code" patch included. There will be no more CHECK_DTBS
warning in V5 for i.MX95 remoteproc support.

If you have concern on patch 1-3 or else, please raise earlier. As of now,
patch 1-3 in V5 will be almost same as V4 with only a minor code
conflict resolved, with below change
@@ -1030,7 +1030,8 @@ static int imx_rproc_clk_enable(struct imx_rproc *priv)
        int ret;

        /* Remote core is not under control of Linux or it is managed by SCU API */
-       if (dcfg->method == IMX_RPROC_NONE || dcfg->method == IMX_RPROC_SCU_API)
+       if (dcfg->method == IMX_RPROC_NONE || dcfg->method == IMX_RPROC_SCU_API ||
+           dcfg->method == IMX_RPROC_SCU_SM)
                return 0;

Regards,
Peng
> 
>> [1]https://lore.kernel.org/linux-remoteproc/20250629172512.14857-3-hiagofranco@gmail.com/T/#u
>> 
>> Thanks,
>> Peng

Re: [PATCH v4 0/5] remoteproc: imx_rproc: Support i.MX95

[Mathieu Poirier]

On Sun, 20 Jul 2025 at 21:08, Peng Fan <peng.fan@oss.nxp.com> wrote:
>
> On Fri, Jul 18, 2025 at 11:06:04AM -0600, Mathieu Poirier wrote:
> >On Fri, Jul 18, 2025 at 04:20:34PM +0800, Peng Fan wrote:
> >> On Thu, Jul 17, 2025 at 08:48:43AM -0600, Mathieu Poirier wrote:
> >> >On Mon, Jul 14, 2025 at 11:52:05AM +0000, Peng Fan wrote:
> >> >> > Subject: Re: [PATCH v4 0/5] remoteproc: imx_rproc: Support i.MX95
> >> >> >
> >> >> [...]
> >> >> > New warnings running 'make CHECK_DTBS=y for
> >> >> > arch/arm64/boot/dts/freescale/' for 20250710-imx95-rproc-1-v4-0-
> >> >> > a7123e857dfb@nxp.com:
> >> >> >
> >> >> > arch/arm64/boot/dts/freescale/imx95-tqma9596sa-mb-smarc-2.dtb:
> >> >> > scmi (arm,scmi): Unevaluated properties are not allowed
> >> >> > ('protocol@80', 'protocol@81', 'protocol@82', 'protocol@84' were
> >> >> > unexpected)
> >> >>
> >> >> Same as replied in v3.
> >> >> This is because [1] is still not picked, not because of my patchset.
> >> >
> >> >I won't move on this patchset until this is resolved.
> >> >
> >>
> >> Not understand why hold on this patchset. I suppose you may not
> >> understand what the error means. The warning is totally irrelevant
> >> to this patchset, there is no dependency.
> >>
> >> Others added a property to arch/arm64/boot/dts/freescale/imx95-tqma9596sa.dtsi
> >> &scmi_bbm {
> >>         linux,code = <KEY_POWER>;
> >> };
> >> But this "linux,code" property not landed(missed to be picked up) to DT binding.
> >>
> >> This patchset does not touch scmi_bbm. I could help address the warning
> >> in the other patch, but I do not see why "linux,code" under scmi_bbm node
> >> could block this patchset.
> >>
> >> Please help clarify if you still think to hold on this patchset.
> >>
> >> BTW: with [1] "remoteproc: imx_rproc: skip clock enable when M-core is managed by the SCU"
> >> merged in Ulf's tree, there is a minor conflict with patch 2. Please suggest
> >> what I should do with this patchset.
> >>
> >
> >I was afraid of that.  The best way forward with this work is to wait for the
> >"linux,code" property to be picked up by Sudeep.  I suggest you make sure that
> >he, or anyone else, picks it up for the next merge window.  If that happens
>
>
> I respect you as maintainer, but there is no reason to block this patch
> because of "linux,code" property. It is totally irrelevant.
>
> Even if I help to resubmit that "linux,code" patch, there is no chance to
> land into 6.17-rc1, both Sudeep and Shawn sent their PR to arm-soc earlier
> before your comments. You could raise in V3.. which there was time left.
>

I don't know what you mean by V3.

> >everything should be set for you to resend this patchset when 6.17-rc1 comes
> >out.
>
> Because of the code conflict in Ulf's tree, I will hold on until 6.17-rc1.

Exactly

> Patch 4 and 5 will be removed from this patchset in V5. The two patches
> should go through Shawn's tree, I will resend them in a separate thread
> with "linux,code" patch included. There will be no more CHECK_DTBS
> warning in V5 for i.MX95 remoteproc support.
>

That is a better way to proceed.

> If you have concern on patch 1-3 or else, please raise earlier. As of now,

If I remember correctly, those patches looked fine to me.

> patch 1-3 in V5 will be almost same as V4 with only a minor code
> conflict resolved, with below change
> @@ -1030,7 +1030,8 @@ static int imx_rproc_clk_enable(struct imx_rproc *priv)
>         int ret;
>
>         /* Remote core is not under control of Linux or it is managed by SCU API */
> -       if (dcfg->method == IMX_RPROC_NONE || dcfg->method == IMX_RPROC_SCU_API)
> +       if (dcfg->method == IMX_RPROC_NONE || dcfg->method == IMX_RPROC_SCU_API ||
> +           dcfg->method == IMX_RPROC_SCU_SM)
>                 return 0;
>
> Regards,
> Peng
> >
> >> [1]https://lore.kernel.org/linux-remoteproc/20250629172512.14857-3-hiagofranco@gmail.com/T/#u
> >>
> >> Thanks,
> >> Peng

Re: [PATCH v4 0/5] remoteproc: imx_rproc: Support i.MX95

[Peng Fan]

On Mon, Jul 21, 2025 at 08:23:42AM -0600, Mathieu Poirier wrote:
>On Sun, 20 Jul 2025 at 21:08, Peng Fan <peng.fan@oss.nxp.com> wrote:
>>
>> On Fri, Jul 18, 2025 at 11:06:04AM -0600, Mathieu Poirier wrote:
>> >On Fri, Jul 18, 2025 at 04:20:34PM +0800, Peng Fan wrote:
>> >> On Thu, Jul 17, 2025 at 08:48:43AM -0600, Mathieu Poirier wrote:
>> >> >On Mon, Jul 14, 2025 at 11:52:05AM +0000, Peng Fan wrote:
>> >> >> > Subject: Re: [PATCH v4 0/5] remoteproc: imx_rproc: Support i.MX95
>> >> >> >
>> >> >> [...]
>> >> >> > New warnings running 'make CHECK_DTBS=y for
>> >> >> > arch/arm64/boot/dts/freescale/' for 20250710-imx95-rproc-1-v4-0-
>> >> >> > a7123e857dfb@nxp.com:
>> >> >> >
>> >> >> > arch/arm64/boot/dts/freescale/imx95-tqma9596sa-mb-smarc-2.dtb:
>> >> >> > scmi (arm,scmi): Unevaluated properties are not allowed
>> >> >> > ('protocol@80', 'protocol@81', 'protocol@82', 'protocol@84' were
>> >> >> > unexpected)
>> >> >>
>> >> >> Same as replied in v3.
>> >> >> This is because [1] is still not picked, not because of my patchset.
>> >> >
>> >> >I won't move on this patchset until this is resolved.
>> >> >
>> >>
>> >> Not understand why hold on this patchset. I suppose you may not
>> >> understand what the error means. The warning is totally irrelevant
>> >> to this patchset, there is no dependency.
>> >>
>> >> Others added a property to arch/arm64/boot/dts/freescale/imx95-tqma9596sa.dtsi
>> >> &scmi_bbm {
>> >>         linux,code = <KEY_POWER>;
>> >> };
>> >> But this "linux,code" property not landed(missed to be picked up) to DT binding.
>> >>
>> >> This patchset does not touch scmi_bbm. I could help address the warning
>> >> in the other patch, but I do not see why "linux,code" under scmi_bbm node
>> >> could block this patchset.
>> >>
>> >> Please help clarify if you still think to hold on this patchset.
>> >>
>> >> BTW: with [1] "remoteproc: imx_rproc: skip clock enable when M-core is managed by the SCU"
>> >> merged in Ulf's tree, there is a minor conflict with patch 2. Please suggest
>> >> what I should do with this patchset.
>> >>
>> >
>> >I was afraid of that.  The best way forward with this work is to wait for the
>> >"linux,code" property to be picked up by Sudeep.  I suggest you make sure that
>> >he, or anyone else, picks it up for the next merge window.  If that happens
>>
>>
>> I respect you as maintainer, but there is no reason to block this patch
>> because of "linux,code" property. It is totally irrelevant.
>>
>> Even if I help to resubmit that "linux,code" patch, there is no chance to
>> land into 6.17-rc1, both Sudeep and Shawn sent their PR to arm-soc earlier
>> before your comments. You could raise in V3.. which there was time left.
>>
>
>I don't know what you mean by V3.

Patch version 3 got same CHECK_DTBS warning.
https://lore.kernel.org/all/20250626035602.GA13855@nxa18884-linux/

Anyway, it doesn't matter now.

Thanks,
Peng