* [PATCH 0/5] firmware: scmi/imx: Add i.MX95 LMM/CPU Protocol
@ 2025-01-21 15:08 Peng Fan (OSS)
2025-01-21 15:08 ` [PATCH 1/5] firmware: arm_scmi: imx: Add i.MX95 LMM protocol Peng Fan (OSS)
` (7 more replies)
0 siblings, 8 replies; 23+ messages in thread
From: Peng Fan (OSS) @ 2025-01-21 15:08 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-kernel, arm-scmi, linux-arm-kernel, imx, Peng Fan
i.MX95 System Manager(SM) implements Logical Machine Management(LMM) and
CPU protocol to manage Logical Machine(LM) and CPUs(eg, M7).
To manage M7 in a separate LM or in same LM as Linux itself. LMM APIs
and CPU APIs are needed.
When M7 is in LM 'lm-m7', and this LM is managable by 'linux-lm',
linux could use LMM_BOOT, LMM_SHUTDOWN and etc to manage 'lm-m7'.
If in same LM, use CPU_START, CPU_STOP, CPU_RESET_VECTOR_SET and etc to
manage M7.
Both LMM/CPU APIs will be used by remoteproc driver. The remoteproc
patchset will be posted out after this patchset gets reviewed or in
good shape per Maitainer's view.
Build pass with COMPILE_TEST
Tested with remoteproc on i.MX95
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Peng Fan (5):
firmware: arm_scmi: imx: Add i.MX95 LMM protocol
firmware: arm_scmi: imx: Add i.MX95 CPU Protocol
firmware: arm_scmi: imx: Add LMM and CPU documentation
firmware: imx: Add i.MX95 SCMI LMM driver
firmware: imx: Add i.MX95 SCMI CPU driver
drivers/firmware/arm_scmi/vendors/imx/Kconfig | 22 +
drivers/firmware/arm_scmi/vendors/imx/Makefile | 2 +
drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c | 283 +++++++++
drivers/firmware/arm_scmi/vendors/imx/imx-sm-lmm.c | 235 +++++++
drivers/firmware/arm_scmi/vendors/imx/imx95.rst | 692 +++++++++++++++++++++
drivers/firmware/imx/Kconfig | 22 +
drivers/firmware/imx/Makefile | 2 +
drivers/firmware/imx/sm-cpu.c | 91 +++
drivers/firmware/imx/sm-lmm.c | 89 +++
include/linux/firmware/imx/sm.h | 56 ++
include/linux/scmi_imx_protocol.h | 39 ++
11 files changed, 1533 insertions(+)
---
base-commit: 0907e7fb35756464aa34c35d6abb02998418164b
change-id: 20250120-imx-lmm-cpu-418daaa257e2
Best regards,
--
Peng Fan <peng.fan@nxp.com>
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 1/5] firmware: arm_scmi: imx: Add i.MX95 LMM protocol
2025-01-21 15:08 [PATCH 0/5] firmware: scmi/imx: Add i.MX95 LMM/CPU Protocol Peng Fan (OSS)
@ 2025-01-21 15:08 ` Peng Fan (OSS)
2025-01-24 2:43 ` kernel test robot
2025-01-21 15:08 ` [PATCH 2/5] firmware: arm_scmi: imx: Add i.MX95 CPU Protocol Peng Fan (OSS)
` (6 subsequent siblings)
7 siblings, 1 reply; 23+ messages in thread
From: Peng Fan (OSS) @ 2025-01-21 15:08 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-kernel, arm-scmi, linux-arm-kernel, imx, Peng Fan
From: Peng Fan <peng.fan@nxp.com>
Add Logical Machine Management(LMM) protocol which is intended for boot,
shutdown, and reset of other logical machines (LM). It is usually used to
allow one LM to manager another used as an offload or accelerator engine.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/firmware/arm_scmi/vendors/imx/Kconfig | 11 +
drivers/firmware/arm_scmi/vendors/imx/Makefile | 1 +
drivers/firmware/arm_scmi/vendors/imx/imx-sm-lmm.c | 235 +++++++++++++++++++++
include/linux/scmi_imx_protocol.h | 29 +++
4 files changed, 276 insertions(+)
diff --git a/drivers/firmware/arm_scmi/vendors/imx/Kconfig b/drivers/firmware/arm_scmi/vendors/imx/Kconfig
index a01bf5e47301d2f93c9bfc7eebc77e083ea4ed75..1a936fc87d2350e2a21bccd45dfbeebfa3b90286 100644
--- a/drivers/firmware/arm_scmi/vendors/imx/Kconfig
+++ b/drivers/firmware/arm_scmi/vendors/imx/Kconfig
@@ -12,6 +12,17 @@ config IMX_SCMI_BBM_EXT
To compile this driver as a module, choose M here: the
module will be called imx-sm-bbm.
+config IMX_SCMI_LMM_EXT
+ tristate "i.MX SCMI LMM EXTENSION"
+ depends on ARM_SCMI_PROTOCOL || (COMPILE_TEST && OF)
+ default y if ARCH_MXC
+ help
+ This enables i.MX System Logical Machine Protocol to
+ manage Logical Machines boot, shutdown and etc.
+
+ To compile this driver as a module, choose M here: the
+ module will be called imx-sm-lmm.
+
config IMX_SCMI_MISC_EXT
tristate "i.MX SCMI MISC EXTENSION"
depends on ARM_SCMI_PROTOCOL || (COMPILE_TEST && OF)
diff --git a/drivers/firmware/arm_scmi/vendors/imx/Makefile b/drivers/firmware/arm_scmi/vendors/imx/Makefile
index d3ee6d5449244a4f5cdf6abcf1845f312c512325..f39a99ccaf9af757475e8b112d224669444d7ddc 100644
--- a/drivers/firmware/arm_scmi/vendors/imx/Makefile
+++ b/drivers/firmware/arm_scmi/vendors/imx/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_IMX_SCMI_BBM_EXT) += imx-sm-bbm.o
+obj-$(CONFIG_IMX_SCMI_LMM_EXT) += imx-sm-lmm.o
obj-$(CONFIG_IMX_SCMI_MISC_EXT) += imx-sm-misc.o
diff --git a/drivers/firmware/arm_scmi/vendors/imx/imx-sm-lmm.c b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-lmm.c
new file mode 100644
index 0000000000000000000000000000000000000000..808cbedba5de4b4314948c06c60bebea057efbe7
--- /dev/null
+++ b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-lmm.c
@@ -0,0 +1,235 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * System control and Management Interface (SCMI) NXP LMM Protocol
+ *
+ * Copyright 2025 NXP
+ */
+
+#include <linux/bits.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/scmi_protocol.h>
+#include <linux/scmi_imx_protocol.h>
+
+#include "../../protocols.h"
+#include "../../notify.h"
+
+#define SCMI_PROTOCOL_SUPPORTED_VERSION 0x10000
+
+enum scmi_imx_lmm_protocol_cmd {
+ SCMI_IMX_LMM_ATTRIBUTES = 0x3,
+ SCMI_IMX_LMM_BOOT = 0x4,
+ SCMI_IMX_LMM_RESET = 0x5,
+ SCMI_IMX_LMM_SHUTDOWN = 0x6,
+ SCMI_IMX_LMM_WAKE = 0x7,
+ SCMI_IMX_LMM_SUSPEND = 0x8,
+ SCMI_IMX_LMM_NOTIFY = 0x9,
+ SCMI_IMX_LMM_RESET_REASON = 0xA,
+ SCMI_IMX_LMM_POWER_ON = 0xB,
+};
+
+struct scmi_imx_lmm_priv {
+ u32 nr_lmm;
+};
+
+#define SCMI_IMX_LMM_PROTO_ATTR_NUM_LM(x) (((x) & 0xFFU))
+struct scmi_msg_imx_lmm_protocol_attributes {
+ __le32 attributes;
+};
+
+struct scmi_msg_imx_lmm_attributes_out {
+ __le32 lmid;
+ __le32 attributes;
+ __le32 state;
+ __le32 errstatus;
+ u8 name[LMM_MAX_NAME];
+};
+
+struct scmi_imx_lmm_shutdown_in {
+ __le32 lmid;
+#define LMM_FLAGS_GRACEFUL(x) ((x) & BIT(0))
+ __le32 flags;
+};
+
+static int scmi_imx_lmm_validate_lmid(const struct scmi_protocol_handle *ph, u32 lmid)
+{
+ struct scmi_imx_lmm_priv *priv = ph->get_priv(ph);
+
+ if (lmid >= priv->nr_lmm)
+ return -EINVAL;
+
+ return 0;
+}
+
+static int scmi_imx_lmm_attributes(const struct scmi_protocol_handle *ph,
+ u32 lmid, struct scmi_imx_lmm_info *info)
+{
+ struct scmi_msg_imx_lmm_attributes_out *out;
+ struct scmi_xfer *t;
+ int ret;
+
+ ret = ph->xops->xfer_get_init(ph, SCMI_IMX_LMM_ATTRIBUTES, sizeof(u32), 0, &t);
+ if (ret)
+ return ret;
+
+ put_unaligned_le32(lmid, t->tx.buf);
+ ret = ph->xops->do_xfer(ph, t);
+ if (!ret) {
+ out = t->rx.buf;
+ info->lmid = le32_to_cpu(out->lmid);
+ info->state = le32_to_cpu(out->state);
+ info->errstatus = le32_to_cpu(out->errstatus);
+ strscpy(info->name, out->name);
+ dev_dbg(ph->dev, "i.MX LMM: Logical Machine(%d), name: %s\n",
+ info->lmid, out->name);
+ } else {
+ dev_err(ph->dev, "i.MX LMM: Failed to get info of Logical Machine(%u)\n", lmid);
+ }
+
+ ph->xops->xfer_put(ph, t);
+
+ return ret;
+}
+
+static int scmi_imx_lmm_boot(const struct scmi_protocol_handle *ph, u32 lmid)
+{
+ struct scmi_xfer *t;
+ int ret;
+
+ ret = scmi_imx_lmm_validate_lmid(ph, lmid);
+ if (ret)
+ return ret;
+
+ ret = ph->xops->xfer_get_init(ph, SCMI_IMX_LMM_BOOT, sizeof(u32),
+ 0, &t);
+ if (ret)
+ return ret;
+
+ put_unaligned_le32(lmid, t->tx.buf);
+ ret = ph->xops->do_xfer(ph, t);
+
+ ph->xops->xfer_put(ph, t);
+
+ return ret;
+}
+
+static int scmi_imx_lmm_power_on(const struct scmi_protocol_handle *ph, u32 lmid)
+{
+ struct scmi_xfer *t;
+ int ret;
+
+ ret = scmi_imx_lmm_validate_lmid(ph, lmid);
+ if (ret)
+ return ret;
+
+ ret = ph->xops->xfer_get_init(ph, SCMI_IMX_LMM_POWER_ON, sizeof(u32),
+ 0, &t);
+ if (ret)
+ return ret;
+
+ put_unaligned_le32(lmid, t->tx.buf);
+ ret = ph->xops->do_xfer(ph, t);
+
+ ph->xops->xfer_put(ph, t);
+
+ return ret;
+}
+
+static int scmi_imx_lmm_shutdown(const struct scmi_protocol_handle *ph, u32 lmid,
+ u32 flags)
+{
+ struct scmi_imx_lmm_shutdown_in *in;
+ struct scmi_xfer *t;
+ int ret;
+
+ ret = scmi_imx_lmm_validate_lmid(ph, lmid);
+ if (ret)
+ return ret;
+
+ ret = ph->xops->xfer_get_init(ph, SCMI_IMX_LMM_SHUTDOWN, sizeof(*in),
+ 0, &t);
+ if (ret)
+ return ret;
+
+ in = t->tx.buf;
+ in->lmid = cpu_to_le32(lmid);
+ in->flags = cpu_to_le32(flags);
+ ret = ph->xops->do_xfer(ph, t);
+
+ ph->xops->xfer_put(ph, t);
+
+ return ret;
+}
+
+static const struct scmi_imx_lmm_proto_ops scmi_imx_lmm_proto_ops = {
+ .lmm_boot = scmi_imx_lmm_boot,
+ .lmm_info = scmi_imx_lmm_attributes,
+ .lmm_power_on = scmi_imx_lmm_power_on,
+ .lmm_shutdown = scmi_imx_lmm_shutdown,
+};
+
+static int scmi_imx_lmm_protocol_attributes_get(const struct scmi_protocol_handle *ph,
+ struct scmi_imx_lmm_priv *priv)
+{
+ struct scmi_msg_imx_lmm_protocol_attributes *attr;
+ struct scmi_xfer *t;
+ int ret;
+
+ ret = ph->xops->xfer_get_init(ph, PROTOCOL_ATTRIBUTES, 0,
+ sizeof(*attr), &t);
+ if (ret)
+ return ret;
+
+ attr = t->rx.buf;
+
+ ret = ph->xops->do_xfer(ph, t);
+ if (!ret) {
+ priv->nr_lmm = SCMI_IMX_LMM_PROTO_ATTR_NUM_LM(attr->attributes);
+ dev_info(ph->dev, "i.MX LMM: %d Logical Machines\n",
+ priv->nr_lmm);
+ }
+
+ ph->xops->xfer_put(ph, t);
+
+ return ret;
+}
+
+static int scmi_imx_lmm_protocol_init(const struct scmi_protocol_handle *ph)
+{
+ struct scmi_imx_lmm_priv *info;
+ u32 version;
+ int ret;
+
+ ret = ph->xops->version_get(ph, &version);
+ if (ret)
+ return ret;
+
+ dev_info(ph->dev, "NXP SM LMM Version %d.%d\n",
+ PROTOCOL_REV_MAJOR(version), PROTOCOL_REV_MINOR(version));
+
+ info = devm_kzalloc(ph->dev, sizeof(*info), GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
+
+ ret = scmi_imx_lmm_protocol_attributes_get(ph, info);
+ if (ret)
+ return ret;
+
+ return ph->set_priv(ph, info, version);
+}
+
+static const struct scmi_protocol scmi_imx_lmm = {
+ .id = SCMI_PROTOCOL_IMX_LMM,
+ .owner = THIS_MODULE,
+ .instance_init = &scmi_imx_lmm_protocol_init,
+ .ops = &scmi_imx_lmm_proto_ops,
+ .supported_version = SCMI_PROTOCOL_SUPPORTED_VERSION,
+ .vendor_id = SCMI_IMX_VENDOR,
+ .sub_vendor_id = SCMI_IMX_SUBVENDOR,
+};
+module_scmi_protocol(scmi_imx_lmm);
+
+MODULE_DESCRIPTION("i.MX SCMI LMM driver");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/scmi_imx_protocol.h b/include/linux/scmi_imx_protocol.h
index 53b356a26414279f4aaaa8287c32209ed1ad57b4..456559f021696ae51f40ed11e6f85089d430ce71 100644
--- a/include/linux/scmi_imx_protocol.h
+++ b/include/linux/scmi_imx_protocol.h
@@ -11,8 +11,10 @@
#include <linux/bitfield.h>
#include <linux/device.h>
#include <linux/notifier.h>
+#include <linux/scmi_protocol.h>
#include <linux/types.h>
+#define SCMI_PROTOCOL_IMX_LMM 0x80
#define SCMI_PROTOCOL_IMX_BBM 0x81
#define SCMI_PROTOCOL_IMX_MISC 0x84
@@ -57,4 +59,31 @@ struct scmi_imx_misc_proto_ops {
int (*misc_ctrl_req_notify)(const struct scmi_protocol_handle *ph,
u32 ctrl_id, u32 evt_id, u32 flags);
};
+
+#define LMM_ID_DISCOVER 0xFFFFFFFFU
+#define LMM_MAX_NAME 16
+
+enum scmi_imx_lmm_state {
+ LMM_STATE_LM_OFF,
+ LMM_STATE_LM_ON,
+ LMM_STATE_LM_SUSPEND,
+ LMM_STATE_LM_POWERED,
+};
+
+struct scmi_imx_lmm_info {
+ u32 lmid;
+ enum scmi_imx_lmm_state state;
+ u32 errstatus;
+ u8 name[LMM_MAX_NAME];
+};
+
+struct scmi_imx_lmm_proto_ops {
+ int (*lmm_boot)(const struct scmi_protocol_handle *ph, u32 lmid);
+ int (*lmm_info)(const struct scmi_protocol_handle *ph, u32 lmid,
+ struct scmi_imx_lmm_info *info);
+ int (*lmm_power_on)(const struct scmi_protocol_handle *ph, u32 lmid);
+ int (*lmm_shutdown)(const struct scmi_protocol_handle *ph, u32 lmid,
+ u32 flags);
+};
+
#endif
--
2.37.1
^ permalink raw reply related [flat|nested] 23+ messages in thread
* [PATCH 2/5] firmware: arm_scmi: imx: Add i.MX95 CPU Protocol
2025-01-21 15:08 [PATCH 0/5] firmware: scmi/imx: Add i.MX95 LMM/CPU Protocol Peng Fan (OSS)
2025-01-21 15:08 ` [PATCH 1/5] firmware: arm_scmi: imx: Add i.MX95 LMM protocol Peng Fan (OSS)
@ 2025-01-21 15:08 ` Peng Fan (OSS)
2025-01-22 8:48 ` Dan Carpenter
2025-01-24 4:11 ` kernel test robot
2025-01-21 15:08 ` [PATCH 3/5] firmware: arm_scmi: imx: Add LMM and CPU documentation Peng Fan (OSS)
` (5 subsequent siblings)
7 siblings, 2 replies; 23+ messages in thread
From: Peng Fan (OSS) @ 2025-01-21 15:08 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-kernel, arm-scmi, linux-arm-kernel, imx, Peng Fan
From: Peng Fan <peng.fan@nxp.com>
This protocol allows an agent to start, stop a CPU or set reset vector. It
is used to manage auxiliary CPUs in an LM (e.g. additional cores in an AP
cluster).
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/firmware/arm_scmi/vendors/imx/Kconfig | 13 +-
drivers/firmware/arm_scmi/vendors/imx/Makefile | 1 +
drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c | 283 +++++++++++++++++++++
include/linux/scmi_imx_protocol.h | 10 +
4 files changed, 306 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_scmi/vendors/imx/Kconfig b/drivers/firmware/arm_scmi/vendors/imx/Kconfig
index 1a936fc87d2350e2a21bccd45dfbeebfa3b90286..9070522510e4d3f3d7276a7581f8676006d20f90 100644
--- a/drivers/firmware/arm_scmi/vendors/imx/Kconfig
+++ b/drivers/firmware/arm_scmi/vendors/imx/Kconfig
@@ -12,6 +12,17 @@ config IMX_SCMI_BBM_EXT
To compile this driver as a module, choose M here: the
module will be called imx-sm-bbm.
+config IMX_SCMI_CPU_EXT
+ tristate "i.MX SCMI CPU EXTENSION"
+ depends on ARM_SCMI_PROTOCOL || (COMPILE_TEST && OF)
+ default y if ARCH_MXC
+ help
+ This enables i.MX System CPU Protocol to manage cpu
+ start, stop and etc.
+
+ To compile this driver as a module, choose M here: the
+ module will be called imx-sm-cpu.
+
config IMX_SCMI_LMM_EXT
tristate "i.MX SCMI LMM EXTENSION"
depends on ARM_SCMI_PROTOCOL || (COMPILE_TEST && OF)
@@ -21,7 +32,7 @@ config IMX_SCMI_LMM_EXT
manage Logical Machines boot, shutdown and etc.
To compile this driver as a module, choose M here: the
- module will be called imx-sm-lmm.
+ module will be called imx-sm-cpu.
config IMX_SCMI_MISC_EXT
tristate "i.MX SCMI MISC EXTENSION"
diff --git a/drivers/firmware/arm_scmi/vendors/imx/Makefile b/drivers/firmware/arm_scmi/vendors/imx/Makefile
index f39a99ccaf9af757475e8b112d224669444d7ddc..e3a5ea46345c89da1afae25e55698044672b7c28 100644
--- a/drivers/firmware/arm_scmi/vendors/imx/Makefile
+++ b/drivers/firmware/arm_scmi/vendors/imx/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_IMX_SCMI_BBM_EXT) += imx-sm-bbm.o
+obj-$(CONFIG_IMX_SCMI_CPU_EXT) += imx-sm-cpu.o
obj-$(CONFIG_IMX_SCMI_LMM_EXT) += imx-sm-lmm.o
obj-$(CONFIG_IMX_SCMI_MISC_EXT) += imx-sm-misc.o
diff --git a/drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c
new file mode 100644
index 0000000000000000000000000000000000000000..e3f294c2cb69a5b5a916d55984f4a63539937d02
--- /dev/null
+++ b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c
@@ -0,0 +1,283 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * System control and Management Interface (SCMI) NXP CPU Protocol
+ *
+ * Copyright 2025 NXP
+ */
+
+#include <linux/bits.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/scmi_protocol.h>
+#include <linux/scmi_imx_protocol.h>
+
+#include "../../protocols.h"
+#include "../../notify.h"
+
+#define SCMI_PROTOCOL_SUPPORTED_VERSION 0x10000
+
+enum scmi_imx_cpu_protocol_cmd {
+ SCMI_IMX_CPU_ATTRIBUTES = 0x3,
+ SCMI_IMX_CPU_START = 0x4,
+ SCMI_IMX_CPU_STOP = 0x5,
+ SCMI_IMX_CPU_RESET_VECTOR_SET = 0x6,
+ SCMI_IMX_CPU_INFO_GET = 0xC,
+};
+
+struct scmi_imx_cpu_info {
+ u32 nr_cpu;
+};
+
+#define SCMI_IMX_CPU_PROTO_ATTR_NUM_CPUS(x) ((x) & 0xFFFF)
+struct scmi_msg_imx_cpu_protocol_attributes {
+ __le32 attributes;
+};
+
+struct scmi_msg_imx_cpu_attributes_out {
+ __le32 attributes;
+#define CPU_MAX_NAME 16
+ u8 name[CPU_MAX_NAME];
+};
+
+struct scmi_imx_cpu_reset_vector_set_in {
+ __le32 cpuid;
+#define CPU_VEC_FLAGS_RESUME BIT(31)
+#define CPU_VEC_FLAGS_START BIT(30)
+#define CPU_VEC_FLAGS_BOOT BIT(29)
+ __le32 flags;
+ __le32 resetvectorlow;
+ __le32 resetvectorhigh;
+};
+
+struct scmi_imx_cpu_info_get_out {
+#define CPU_RUN_MODE_START 0
+#define CPU_RUN_MODE_HOLD 1
+#define CPU_RUN_MODE_STOP 2
+#define CPU_RUN_MODE_SLEEP 3
+ __le32 runmode;
+ __le32 sleepmode;
+ __le32 resetvectorlow;
+ __le32 resetvectorhigh;
+};
+
+static int scmi_imx_cpu_validate_cpuid(const struct scmi_protocol_handle *ph,
+ u32 cpuid)
+{
+ struct scmi_imx_cpu_info *info = ph->get_priv(ph);
+
+ if (cpuid >= info->nr_cpu)
+ return -EINVAL;
+
+ return 0;
+}
+
+static int scmi_imx_cpu_start(const struct scmi_protocol_handle *ph, u32 cpuid)
+{
+ struct scmi_xfer *t;
+ int ret;
+
+ ret = scmi_imx_cpu_validate_cpuid(ph, cpuid);
+ if (ret)
+ return ret;
+
+ ret = ph->xops->xfer_get_init(ph, SCMI_IMX_CPU_START, sizeof(u32),
+ 0, &t);
+ if (ret)
+ return ret;
+
+ put_unaligned_le32(cpuid, t->tx.buf);
+ ret = ph->xops->do_xfer(ph, t);
+
+ ph->xops->xfer_put(ph, t);
+
+ return ret;
+}
+
+static int scmi_imx_cpu_stop(const struct scmi_protocol_handle *ph, u32 cpuid)
+{
+ struct scmi_xfer *t;
+ int ret;
+
+ ret = scmi_imx_cpu_validate_cpuid(ph, cpuid);
+ if (ret)
+ return ret;
+
+ ret = ph->xops->xfer_get_init(ph, SCMI_IMX_CPU_STOP, sizeof(u32),
+ 0, &t);
+ if (ret)
+ return ret;
+
+ put_unaligned_le32(cpuid, t->tx.buf);
+ ret = ph->xops->do_xfer(ph, t);
+
+ ph->xops->xfer_put(ph, t);
+
+ return ret;
+}
+
+static int scmi_imx_cpu_reset_vector_set(const struct scmi_protocol_handle *ph,
+ u32 cpuid, u64 vector, bool start,
+ bool boot, bool resume)
+{
+ struct scmi_imx_cpu_reset_vector_set_in *in;
+ struct scmi_xfer *t;
+ int ret;
+
+ ret = scmi_imx_cpu_validate_cpuid(ph, cpuid);
+ if (ret)
+ return ret;
+
+ ret = ph->xops->xfer_get_init(ph, SCMI_IMX_CPU_RESET_VECTOR_SET, sizeof(*in),
+ 0, &t);
+ if (ret)
+ return ret;
+
+ in = t->tx.buf;
+ in->cpuid = cpu_to_le32(cpuid);
+ in->flags = start ? CPU_VEC_FLAGS_START : 0;
+ in->flags |= boot ? CPU_VEC_FLAGS_BOOT : 0;
+ in->flags |= resume ? CPU_VEC_FLAGS_BOOT : 0;
+ in->resetvectorlow = cpu_to_le32(lower_32_bits(vector));
+ in->resetvectorhigh = cpu_to_le32(upper_32_bits(vector));
+ ret = ph->xops->do_xfer(ph, t);
+
+ ph->xops->xfer_put(ph, t);
+
+ return ret;
+}
+
+static int scmi_imx_cpu_started(const struct scmi_protocol_handle *ph, u32 cpuid,
+ bool *started)
+{
+ struct scmi_imx_cpu_info_get_out *out;
+ struct scmi_xfer *t;
+ int ret;
+
+ *started = false;
+ ret = scmi_imx_cpu_validate_cpuid(ph, cpuid);
+ if (ret)
+ return ret;
+
+ ret = ph->xops->xfer_get_init(ph, SCMI_IMX_CPU_INFO_GET, sizeof(u32),
+ 0, &t);
+ if (ret)
+ return ret;
+
+ put_unaligned_le32(cpuid, t->tx.buf);
+ ret = ph->xops->do_xfer(ph, t);
+ if (!ret) {
+ out = t->rx.buf;
+ if ((out->runmode == CPU_RUN_MODE_START) ||
+ (out->runmode == CPU_RUN_MODE_SLEEP))
+ *started = true;
+ }
+
+ ph->xops->xfer_put(ph, t);
+
+ return ret;
+}
+
+static const struct scmi_imx_cpu_proto_ops scmi_imx_cpu_proto_ops = {
+ .cpu_reset_vector_set = scmi_imx_cpu_reset_vector_set,
+ .cpu_start = scmi_imx_cpu_start,
+ .cpu_started = scmi_imx_cpu_started,
+ .cpu_stop = scmi_imx_cpu_stop,
+};
+
+static int scmi_imx_cpu_protocol_attributes_get(const struct scmi_protocol_handle *ph,
+ struct scmi_imx_cpu_info *info)
+{
+ struct scmi_msg_imx_cpu_protocol_attributes *attr;
+ struct scmi_xfer *t;
+ int ret;
+
+ ret = ph->xops->xfer_get_init(ph, PROTOCOL_ATTRIBUTES, 0,
+ sizeof(*attr), &t);
+ if (ret)
+ return ret;
+
+ attr = t->rx.buf;
+
+ ret = ph->xops->do_xfer(ph, t);
+ if (!ret) {
+ info->nr_cpu = SCMI_IMX_CPU_PROTO_ATTR_NUM_CPUS(attr->attributes);
+ dev_info(ph->dev, "i.MX SM CPU: %d cpus\n",
+ info->nr_cpu);
+ }
+
+ ph->xops->xfer_put(ph, t);
+
+ return ret;
+}
+
+static int scmi_imx_cpu_attributes_get(const struct scmi_protocol_handle *ph,
+ u32 cpuid, struct scmi_imx_cpu_info *info)
+{
+ struct scmi_msg_imx_cpu_attributes_out *out;
+ struct scmi_xfer *t;
+ int ret;
+
+ ret = ph->xops->xfer_get_init(ph, SCMI_IMX_CPU_ATTRIBUTES, sizeof(u32), 0, &t);
+ if (ret)
+ return ret;
+
+ put_unaligned_le32(cpuid, t->tx.buf);
+ ret = ph->xops->do_xfer(ph, t);
+ if (!ret) {
+ out = t->rx.buf;
+ dev_info(ph->dev, "i.MX CPU: name: %s\n", out->name);
+ } else {
+ dev_err(ph->dev, "i.MX cpu: Failed to get info of cpu(%u)\n", cpuid);
+ }
+
+ ph->xops->xfer_put(ph, t);
+
+ return ret;
+}
+
+
+static int scmi_imx_cpu_protocol_init(const struct scmi_protocol_handle *ph)
+{
+ struct scmi_imx_cpu_info *info;
+ u32 version;
+ int ret, i;
+
+ ret = ph->xops->version_get(ph, &version);
+ if (ret)
+ return ret;
+
+ dev_info(ph->dev, "NXP SM CPU Protocol Version %d.%d\n",
+ PROTOCOL_REV_MAJOR(version), PROTOCOL_REV_MINOR(version));
+
+ info = devm_kzalloc(ph->dev, sizeof(*info), GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
+
+ ret = scmi_imx_cpu_protocol_attributes_get(ph, info);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < info->nr_cpu; i++) {
+ ret = scmi_imx_cpu_attributes_get(ph, i, info);
+ if (ret)
+ return ret;
+ }
+
+ return ph->set_priv(ph, info, version);
+}
+
+static const struct scmi_protocol scmi_imx_cpu = {
+ .id = SCMI_PROTOCOL_IMX_CPU,
+ .owner = THIS_MODULE,
+ .instance_init = &scmi_imx_cpu_protocol_init,
+ .ops = &scmi_imx_cpu_proto_ops,
+ .supported_version = SCMI_PROTOCOL_SUPPORTED_VERSION,
+ .vendor_id = SCMI_IMX_VENDOR,
+ .sub_vendor_id = SCMI_IMX_SUBVENDOR,
+};
+module_scmi_protocol(scmi_imx_cpu);
+
+MODULE_DESCRIPTION("i.MX SCMI CPU driver");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/scmi_imx_protocol.h b/include/linux/scmi_imx_protocol.h
index 456559f021696ae51f40ed11e6f85089d430ce71..6521199cdab67c7e751e850def221d89898cd0f2 100644
--- a/include/linux/scmi_imx_protocol.h
+++ b/include/linux/scmi_imx_protocol.h
@@ -16,6 +16,7 @@
#define SCMI_PROTOCOL_IMX_LMM 0x80
#define SCMI_PROTOCOL_IMX_BBM 0x81
+#define SCMI_PROTOCOL_IMX_CPU 0x82
#define SCMI_PROTOCOL_IMX_MISC 0x84
#define SCMI_IMX_VENDOR "NXP"
@@ -86,4 +87,13 @@ struct scmi_imx_lmm_proto_ops {
u32 flags);
};
+struct scmi_imx_cpu_proto_ops {
+ int (*cpu_reset_vector_set)(const struct scmi_protocol_handle *ph,
+ u32 cpuid, u64 vector, bool start,
+ bool boot, bool resume);
+ int (*cpu_start)(const struct scmi_protocol_handle *ph, u32 cpuid);
+ int (*cpu_started)(const struct scmi_protocol_handle *ph, u32 cpuid,
+ bool *started);
+ int (*cpu_stop)(const struct scmi_protocol_handle *ph, u32 cpuid);
+};
#endif
--
2.37.1
^ permalink raw reply related [flat|nested] 23+ messages in thread
* [PATCH 3/5] firmware: arm_scmi: imx: Add LMM and CPU documentation
2025-01-21 15:08 [PATCH 0/5] firmware: scmi/imx: Add i.MX95 LMM/CPU Protocol Peng Fan (OSS)
2025-01-21 15:08 ` [PATCH 1/5] firmware: arm_scmi: imx: Add i.MX95 LMM protocol Peng Fan (OSS)
2025-01-21 15:08 ` [PATCH 2/5] firmware: arm_scmi: imx: Add i.MX95 CPU Protocol Peng Fan (OSS)
@ 2025-01-21 15:08 ` Peng Fan (OSS)
2025-01-22 12:14 ` Sudeep Holla
2025-01-21 15:08 ` [PATCH 4/5] firmware: imx: Add i.MX95 SCMI LMM driver Peng Fan (OSS)
` (4 subsequent siblings)
7 siblings, 1 reply; 23+ messages in thread
From: Peng Fan (OSS) @ 2025-01-21 15:08 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-kernel, arm-scmi, linux-arm-kernel, imx, Peng Fan
From: Peng Fan <peng.fan@nxp.com>
Add i.MX95 Logical Machine Management and CPU Protocol documentation.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/firmware/arm_scmi/vendors/imx/imx95.rst | 692 ++++++++++++++++++++++++
1 file changed, 692 insertions(+)
diff --git a/drivers/firmware/arm_scmi/vendors/imx/imx95.rst b/drivers/firmware/arm_scmi/vendors/imx/imx95.rst
index b2dfd6c46ca2f5f12f0475c24cb54c060e9fa421..384d4f9c27e489a9c54cdde79c9f03a6f5979630 100644
--- a/drivers/firmware/arm_scmi/vendors/imx/imx95.rst
+++ b/drivers/firmware/arm_scmi/vendors/imx/imx95.rst
@@ -32,6 +32,419 @@ port, and deploy the SM on supported processors.
The SM implements an interface compliant with the Arm SCMI Specification
with additional vendor specific extensions.
+SCMI_LMM: System Control and Management Logical Machine Management Vendor Protocol
+==================================================================================
+
+This protocol is intended for boot, shutdown, and reset of other logical
+machines (LM). It is usually used to allow one LM to manager another used
+as an offload or accelerator engine. Notifications from this protocol can
+also be used to manage a communication link to another LM. The LMM protocol
+provides functions to:
+
+- Describe the protocol version.
+- Discover implementation attributes.
+- Discover the LMs defined in the system.
+- Boot an LM.
+- Shut down an LM.
+- Reset an LM.
+- Wake an LM from suspend.
+- Suspend an LM (gracefully).
+- Request a graceful shutdown or reset of an LM.
+- Allow an agent to forcibly power down or reset an LM.
+- Read boot/shutdown/reset information for an LM.
+- Get notifications when an LM boots or shuts down.
+
+Commands:
+_________
+
+PROTOCOL_VERSION
+~~~~~~~~~~~~~~~~
+
+message_id: 0x0
+protocol_id: 0x80
+
++---------------+--------------------------------------------------------------+
+|Return values |
++---------------+--------------------------------------------------------------+
+|Name |Description |
++---------------+--------------------------------------------------------------+
+|int32 status | See ARM SCMI Specification for status code definitions. |
++---------------+--------------------------------------------------------------+
+|uint32 version | For this revision of the specification, this value must be |
+| | 0x10000. |
++---------------+--------------------------------------------------------------+
+
+PROTOCOL_ATTRIBUTES
+~~~~~~~~~~~~~~~~~~~
+
+message_id: 0x1
+protocol_id: 0x80
+
++------------------+-----------------------------------------------------------+
+|Return values |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|int32 status | See ARM SCMI Specification for status code definitions. |
++------------------+-----------------------------------------------------------+
+|uint32 attributes |Protocol attributes: |
+| |Bits[31:8] Reserved, must be zero. |
+| |Bits[7:0] Number of Logical Machines |
++------------------+-----------------------------------------------------------+
+
+PROTOCOL_MESSAGE_ATTRIBUTES
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+message_id: 0x2
+protocol_id: 0x80
+
++------------------+-----------------------------------------------------------+
+|Return values |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|int32 status |SUCCESS: in case the message is implemented and available |
+| |to use. |
+| |NOT_FOUND: if the message identified by message_id is |
+| |invalid or not implemented |
++------------------+-----------------------------------------------------------+
+|uint32 attributes |Flags that are associated with a specific function in the |
+| |protocol. For all functions in this protocol, this |
+| |parameter has a value of 0 |
++------------------+-----------------------------------------------------------+
+
+LMM_ATTRIBUTES
+~~~~~~~~~~~~~~
+
+message_id: 0x3
+protocol_id: 0x80
+
++------------------+-----------------------------------------------------------+
+|Parameters |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|uint32 lmid |ID of the Logical Machine |
++------------------+-----------------------------------------------------------+
+|Return values |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|int32 status |SUCCESS: if valid attributes are returned. |
+| |NOT_FOUND: if lmId not points to a valid logical machine. |
+| |DENIED: if the agent does not have permission to get info |
+| |for the LM specified by lmid. |
++------------------+-----------------------------------------------------------+
+
+LMM_BOOT
+~~~~~~~~
+
+message_id: 0x4
+protocol_id: 0x80
+
++------------------+-----------------------------------------------------------+
+|Parameters |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|uint32 lmid |ID of the Logical Machine |
++------------------+-----------------------------------------------------------+
+|Return values |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|int32 status |SUCCESS: if LM successfully booted. |
+| |NOT_FOUND: if lmId not points to a valid logical machine. |
+| |INVALID_PARAMETERS: if lmId is same as the caller. |
+| |DENIED: if the agent does not have permission to manage the|
+| |the LM specified by lmid. |
++------------------+-----------------------------------------------------------+
+
+LMM_RESET
+~~~~~~~~~
+
+message_id: 0x5
+protocol_id: 0x80
+
++------------------+-----------------------------------------------------------+
+|Parameters |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|uint32 lmid |ID of the Logical Machine |
++------------------+-----------------------------------------------------------+
+|uint32 flags |Reset flags: |
+| |Bits[31:1] Reserved, must be zero. |
+| |Bit[0] Graceful request: |
+| |Set to 1 if the request is a graceful request. |
+| |Set to 0 if the request is a forceful request. |
++------------------+-----------------------------------------------------------+
+|Return values |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|int32 status |SUCCESS: if LM successfully resets. |
+| |NOT_FOUND: if lmId not points to a valid logical machine. |
+| |INVALID_PARAMETERS: if lmId is same as the caller. |
+| |DENIED: if the agent does not have permission to manage the|
+| |the LM specified by lmid. |
++------------------+-----------------------------------------------------------+
+
+LMM_SHUTDOWN
+~~~~~~~~~~~~
+
+message_id: 0x6
+protocol_id: 0x80
+
++------------------+-----------------------------------------------------------+
+|Parameters |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|uint32 lmid |ID of the Logical Machine |
++------------------+-----------------------------------------------------------+
+|uint32 flags |Reset flags: |
+| |Bits[31:1] Reserved, must be zero. |
+| |Bit[0] Graceful request: |
+| |Set to 1 if the request is a graceful request. |
+| |Set to 0 if the request is a forceful request. |
++------------------+-----------------------------------------------------------+
+|Return values |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|int32 status |SUCCESS: if LM successfully shutdowns. |
+| |NOT_FOUND: if lmId not points to a valid logical machine. |
+| |INVALID_PARAMETERS: if lmId is same as the caller. |
+| |DENIED: if the agent does not have permission to manage the|
+| |the LM specified by lmid. |
++------------------+-----------------------------------------------------------+
+
+LMM_WAKE
+~~~~~~~~
+
+message_id: 0x7
+protocol_id: 0x80
+
++------------------+-----------------------------------------------------------+
+|Parameters |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|uint32 lmid |ID of the Logical Machine |
++------------------+-----------------------------------------------------------+
+|Return values |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|int32 status |SUCCESS: if LM successfully wakes. |
+| |NOT_FOUND: if lmId not points to a valid logical machine. |
+| |INVALID_PARAMETERS: if lmId is same as the caller. |
+| |DENIED: if the agent does not have permission to manage the|
+| |the LM specified by lmid. |
++------------------+-----------------------------------------------------------+
+
+LMM_SUSPEND
+~~~~~~~~~~~
+
+message_id: 0x8
+protocol_id: 0x80
+
++------------------+-----------------------------------------------------------+
+|Parameters |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|uint32 lmid |ID of the Logical Machine |
++------------------+-----------------------------------------------------------+
+|Return values |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|int32 status |SUCCESS: if LM successfully suspends. |
+| |NOT_FOUND: if lmId not points to a valid logical machine. |
+| |INVALID_PARAMETERS: if lmId is same as the caller. |
+| |DENIED: if the agent does not have permission to manage the|
+| |the LM specified by lmid. |
++------------------+-----------------------------------------------------------+
+
+LMM_NOTIFY
+~~~~~~~~~~
+
+message_id: 0x9
+protocol_id: 0x80
+
++------------------+-----------------------------------------------------------+
+|Parameters |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|uint32 lmid |ID of the Logical Machine |
++------------------+-----------------------------------------------------------+
+|uint32 flags |Notification flags: |
+| |Bits[31:3] Reserved, must be zero. |
+| |Bit[3] Wake (resume) notification: |
+| |Set to 1 to send notification. |
+| |Set to 0 if no notification. |
+| |Bit[2] Suspend (sleep) notification: |
+| |Set to 1 to send notification. |
+| |Set to 0 if no notification. |
+| |Bit[1] Shutdown (off) notification: |
+| |Set to 1 to send notification. |
+| |Set to 0 if no notification. |
+| |Bit[0] Boot (on) notification: |
+| |Set to 1 to send notification. |
+| |Set to 0 if no notification |
++------------------+-----------------------------------------------------------+
+|Return values |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|int32 status |SUCCESS: if the notification state successfully updated. |
+| |NOT_FOUND: if lmId not points to a valid logical machine. |
+| |INVALID_PARAMETERS: if input attributes flag specifies |
+| |unsupported or invalid configurations. |
+| |DENIED: if the agent does not have permission to request |
+| |the notification. |
++------------------+-----------------------------------------------------------+
+
+LMM_RESET_REASON
+~~~~~~~~~~~~~~~~
+
+message_id: 0xA
+protocol_id: 0x80
+
++---------------------+--------------------------------------------------------+
+|Parameters |
++---------------------+--------------------------------------------------------+
+|Name |Description |
++---------------------+--------------------------------------------------------+
+|uint32 lmid |ID of the Logical Machine |
++---------------------+--------------------------------------------------------+
+|Return values |
++---------------------+--------------------------------------------------------+
+|Name |Description |
++---------------------+--------------------------------------------------------+
+|int32 status |SUCCESS: if LM successfully suspends. |
+| |NOT_FOUND: if lmId not points to a valid logical machine|
+| |DENIED: if the agent does not have permission to request|
+| |the reset reason. |
++---------------------+--------------------------------------------------------+
+|uint32 bootflags |Boot reason flags. This parameter has the format: |
+| |Bits[31] Valid. |
+| |Set to 1 if the entire reason is valid. |
+| |Set to 0 if the entire reason is not valid. |
+| |Bits[30:29] Reserved, must be zero. |
+| |Bit[28] Valid origin: |
+| |Set to 1 if the origin field is valid. |
+| |Set to 0 if the origin field is not valid. |
+| |Bits[27:24] Origin. |
+| |Bit[23] Valid err ID: |
+| |Set to 1 if the error ID field is valid. |
+| |Set to 0 if the error ID field is not valid. |
+| |Bits[22:8] Error ID. |
+| |Bit[7:0] Reason |
++---------------------+--------------------------------------------------------+
+|uint32 shutdownflags |Shutdown reason flags. This parameter has the format: |
+| |Bits[31] Valid. |
+| |Set to 1 if the entire reason is valid. |
+| |Set to 0 if the entire reason is not valid. |
+| |Bits[30:29] Number of valid extended info words. |
+| |Bit[28] Valid origin: |
+| |Set to 1 if the origin field is valid. |
+| |Set to 0 if the origin field is not valid. |
+| |Bits[27:24] Origin. |
+| |Bit[23] Valid err ID: |
+| |Set to 1 if the error ID field is valid. |
+| |Set to 0 if the error ID field is not valid. |
+| |Bits[22:8] Error ID. |
+| |Bit[7:0] Reason |
++---------------------+--------------------------------------------------------+
+|uint32 extinfo[0,20] |Array of extended info words |
++---------------------+--------------------------------------------------------+
+
+LMM_POWER_ON
+~~~~~~~~~~~~
+
+message_id: 0xB
+protocol_id: 0x80
+
++------------------+-----------------------------------------------------------+
+|Parameters |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|uint32 lmid |ID of the Logical Machine |
++------------------+-----------------------------------------------------------+
+|Return values |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|int32 status |SUCCESS: if LM successfully suspends. |
+| |NOT_FOUND: if lmId not points to a valid logical machine. |
+| |INVALID_PARAMETERS: if lmId is same as the caller. |
+| |DENIED: if the agent does not have permission to manage the|
+| |the LM specified by lmid. |
++------------------+-----------------------------------------------------------+
+
+NEGOTIATE_PROTOCOL_VERSION
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+message_id: 0x10
+protocol_id: 0x80
+
++--------------------+---------------------------------------------------------+
+|Parameters |
++--------------------+---------------------------------------------------------+
+|Name |Description |
++--------------------+---------------------------------------------------------+
+|uint32 version |The negotiated protocol version the agent intends to use |
++--------------------+---------------------------------------------------------+
+|Return values |
++--------------------+---------------------------------------------------------+
+|Name |Description |
++--------------------+---------------------------------------------------------+
+|int32 status |SUCCESS: if the negotiated protocol version is supported |
+| |by the platform. All commands, responses, and |
+| |notifications post successful return of this command must|
+| |comply with the negotiated version. |
+| |NOT_SUPPORTED: if the protocol version is not supported. |
++--------------------+---------------------------------------------------------+
+
+Notifications
+_____________
+
+LMM_EVENT
+~~~~~~~~~
+
+message_id: 0x0
+protocol_id: 0x80
+
++------------------+-----------------------------------------------------------+
+|Parameters |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|uint32 lmid |Identifier for the LM that caused the transition. |
++------------------+-----------------------------------------------------------+
+|uint32 eventlm |Identifier for the LM the event is for. |
++------------------+-----------------------------------------------------------+
+|uint32 flags |LM events: |
+| |Bits[31:3] Reserved, must be zero. |
+| |Bit[3] Wake (resume) event: |
+| |1 LM has awakened. |
+| |0 not a wake event. |
+| |Bit[2] Suspend (sleep) event: |
+| |1 LM has suspended. |
+| |0 not a suspend event. |
+| |Bit[1] Shutdown (off) event: |
+| |1 LM has shutdown. |
+| |0 not a shutdown event. |
+| |Bit[0] Boot (on) event: |
+| |1 LM has booted. |
+| |0 not a boot event. |
++------------------+-----------------------------------------------------------+
+
SCMI_BBM: System Control and Management BBM Vendor Protocol
==============================================================
@@ -436,6 +849,285 @@ protocol_id: 0x81
| |0 no button change detected. |
+------------------+-----------------------------------------------------------+
+SCMI_CPU: System Control and Management CPU Vendor Protocol
+==============================================================
+
+This protocol allows an agent to start or stop a CPU. It is used to manage
+auxiliary CPUs in an LM (e.g. additional cores in an AP cluster), The CPU
+protocol provides functions to:
+
+- Describe the protocol version.
+- Discover implementation attributes.
+- Discover the CPUs defined in the system.
+- Start a CPU.
+- Stop a CPU.
+- Set the boot and resume addresses for a CPU.
+- Set the sleep mode of a CPU.
+- Configure wake-up sources for a CPU.
+- Configure power domain reactions (LPM mode and retention mask) for a CPU.
+- The CPU IDs can be found in the CPU section of the SoC DEVICE: SM Device
+ Interface. They can also be found in the SoC RM. See the CPU Mode Control
+ (CMC) list in General Power Controller (GPC) section.
+
+CPU settings are not aggregated and setting their state is normally exclusive
+to one client.
+
+Commands:
+_________
+
+PROTOCOL_VERSION
+~~~~~~~~~~~~~~~~
+
+message_id: 0x0
+protocol_id: 0x82
+
++---------------+--------------------------------------------------------------+
+|Return values |
++---------------+--------------------------------------------------------------+
+|Name |Description |
++---------------+--------------------------------------------------------------+
+|int32 status | See ARM SCMI Specification for status code definitions. |
++---------------+--------------------------------------------------------------+
+|uint32 version | For this revision of the specification, this value must be |
+| | 0x10000. |
++---------------+--------------------------------------------------------------+
+
+PROTOCOL_ATTRIBUTES
+~~~~~~~~~~~~~~~~~~~
+
+message_id: 0x1
+protocol_id: 0x82
+
++---------------+--------------------------------------------------------------+
+|Return values |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|int32 status | See ARM SCMI Specification for status code definitions. |
++------------------+-----------------------------------------------------------+
+|uint32 attributes |Protocol attributes: |
+| |Bits[31:16] Reserved, must be zero. |
+| |Bits[15:0] Number of CPUs |
++------------------+-----------------------------------------------------------+
+
+PROTOCOL_MESSAGE_ATTRIBUTES
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+message_id: 0x2
+protocol_id: 0x82
+
++---------------+--------------------------------------------------------------+
+|Return values |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|int32 status |SUCCESS: in case the message is implemented and available |
+| |to use. |
+| |NOT_FOUND: if the message identified by message_id is |
+| |invalid or not implemented |
++------------------+-----------------------------------------------------------+
+|uint32 attributes |Flags that are associated with a specific function in the |
+| |protocol. For all functions in this protocol, this |
+| |parameter has a value of 0 |
++------------------+-----------------------------------------------------------+
+
+CPU_ATTRIBUTES
+~~~~~~~~~~~~~~
+
+message_id: 0x4
+protocol_id: 0x82
+
++------------------+-----------------------------------------------------------+
+|Parameters |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|uint32 cpuid |Identifier for the CPU |
++------------------+-----------------------------------------------------------+
+|Return values |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|int32 status |SUCCESS: if valid attributes are returned successfully. |
+| |NOT_FOUND: if the cpuid is not valid. |
++------------------+-----------------------------------------------------------+
+|uint32 attributes |Bits[31:0] Reserved, must be zero |
++------------------+-----------------------------------------------------------+
+|char name[16] |NULL terminated ASCII string with CPU name up to 16 bytes |
++------------------+-----------------------------------------------------------+
+
+CPU_START
+~~~~~~~~~
+
+message_id: 0x4
+protocol_id: 0x82
+
++------------------+-----------------------------------------------------------+
+|Parameters |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|uint32 cpuid |Identifier for the CPU |
++------------------+-----------------------------------------------------------+
+|Return values |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|int32 status |SUCCESS: if the cpu is started successfully. |
+| |NOT_FOUND: if cpuid is not valid. |
+| |DENIED: the calling agent is not allowed to start this CPU.|
++------------------+-----------------------------------------------------------+
+
+CPU_STOP
+~~~~~~~~
+
+message_id: 0x5
+protocol_id: 0x82
+
++------------------+-----------------------------------------------------------+
+|Parameters |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|uint32 cpuid |Identifier for the CPU |
++------------------+-----------------------------------------------------------+
+|Return values |
++------------------+-----------------------------------------------------------+
+|Name |Description |
++------------------+-----------------------------------------------------------+
+|int32 status |SUCCESS: if the cpu is started successfully. |
+| |NOT_FOUND: if cpuid is not valid. |
+| |DENIED: the calling agent is not allowed to stop this CPU. |
++------------------+-----------------------------------------------------------+
+
+CPU_RESET_VECTOR_SET
+~~~~~~~~~~~~~~~~~~~~
+
+message_id: 0x6
+protocol_id: 0x82
+
++----------------------+-------------------------------------------------------+
+|Parameters |
++----------------------+-------------------------------------------------------+
+|Name |Description |
++----------------------+-------------------------------------------------------+
+|uint32 cpuid |Identifier for the CPU |
++----------------------+-------------------------------------------------------+
+|uint32 flags |Reset vector flags: |
+| |Bit[31] Resume flag. |
+| |Set to 1 to update the reset vector used on resume. |
+| |Bit[30] Boot flag. |
+| |Set to 1 to update the reset vector used for boot. |
+| |Bits[29:1] Reserved, must be zero. |
+| |Bit[0] Table flag. |
+| |Set to 1 if vector is the vector table base address. |
++----------------------+-------------------------------------------------------+
+|uint32 resetVectorLow |Lower vector: |
+| |If bit[0] of flags is 0, the lower 32 bits of the |
+| |physical address where the CPU should execute from on |
+| |reset. If bit[0] of flags is 1, the lower 32 bits of |
+| |the vector table base address |
++----------------------+-------------------------------------------------------+
+|uint32 resetVectorhigh|Upper vector: |
+| |If bit[0] of flags is 0, the upper 32 bits of the |
+| |physical address where the CPU should execute from on |
+| |reset. If bit[0] of flags is 1, the upper 32 bits of |
+| |the vector table base address |
++----------------------+-------------------------------------------------------+
+|Return values |
++----------------------+-------------------------------------------------------+
+|Name |Description |
++----------------------+-------------------------------------------------------+
+|int32 status |SUCCESS: if the CPU reset vector is set successfully. |
+| |NOT_FOUND: if cpuId does not point to a valid CPU. |
+| |INVALID_PARAMETERS: the requested vector type is not |
+| |supported by this CPU. |
+| |DENIED: the calling agent is not allowed to set the |
+| |reset vector of this CPU |
++----------------------+-------------------------------------------------------+
+
+CPU_SLEEP_MODE_SET
+~~~~~~~~~~~~~~~~~~
+message_id: 0x7
+protocol_id: 0x82
+
++----------------------+-------------------------------------------------------+
+|Parameters |
++----------------------+-------------------------------------------------------+
+|Name |Description |
++----------------------+-------------------------------------------------------+
+|uint32 cpuid |Identifier for the CPU |
++----------------------+-------------------------------------------------------+
+|uint32 flags |Sleep mode flags: |
+| |Bits[31:1] Reserved, must be zero. |
+| |Bit[0] IRQ mux: |
+| |If set to 1 the wakeup mux source is the GIC, else if 0|
+| |then the GPC |
++----------------------+-------------------------------------------------------+
+|uint32 sleepmode |target sleep mode |
++----------------------+-------------------------------------------------------+
+|Return values |
++----------------------+-------------------------------------------------------+
+|Name |Description |
++----------------------+-------------------------------------------------------+
+|int32 status |SUCCESS: if the CPU sleep mode is set successfully. |
+| |NOT_FOUND: if cpuId does not point to a valid CPU. |
+| |INVALID_PARAMETERS: the sleepmode or flags is invalid. |
+| |DENIED: the calling agent is not allowed to configure |
+| |the CPU |
++----------------------+-------------------------------------------------------+
+
+CPU_INFO_GET
+~~~~~~~~~~~~
+message_id: 0xC
+protocol_id: 0x82
+
++----------------------+-------------------------------------------------------+
+|Parameters |
++----------------------+-------------------------------------------------------+
+|Name |Description |
++----------------------+-------------------------------------------------------+
+|uint32 cpuid |Identifier for the CPU |
++----------------------+-------------------------------------------------------+
+|Return values |
++----------------------+-------------------------------------------------------+
+|Name |Description |
++----------------------+-------------------------------------------------------+
+|int32 status |SUCCESS: if valid attributes are returned successfully.|
+| |NOT_FOUND: if the cpuid is not valid. |
++----------------------+-------------------------------------------------------+
+|uint32 runmode |Run mode for the CPU |
++----------------------+-------------------------------------------------------+
+|uint32 sleepmode |Sleep mode for the CPU |
++----------------------+-------------------------------------------------------+
+|uint32 resetvectorlow |Reset vector low 32 bits for the CPU |
++----------------------+-------------------------------------------------------+
+|uint32 resetvecothigh |Reset vector high 32 bits for the CPU |
++----------------------+-------------------------------------------------------+
+
+NEGOTIATE_PROTOCOL_VERSION
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+message_id: 0x10
+protocol_id: 0x82
+
++--------------------+---------------------------------------------------------+
+|Parameters |
++--------------------+---------------------------------------------------------+
+|Name |Description |
++--------------------+---------------------------------------------------------+
+|uint32 version |The negotiated protocol version the agent intends to use |
++--------------------+---------------------------------------------------------+
+|Return values |
++--------------------+---------------------------------------------------------+
+|Name |Description |
++--------------------+---------------------------------------------------------+
+|int32 status |SUCCESS: if the negotiated protocol version is supported |
+| |by the platform. All commands, responses, and |
+| |notifications post successful return of this command must|
+| |comply with the negotiated version. |
+| |NOT_SUPPORTED: if the protocol version is not supported. |
++--------------------+---------------------------------------------------------+
+
SCMI_MISC: System Control and Management MISC Vendor Protocol
================================================================
--
2.37.1
^ permalink raw reply related [flat|nested] 23+ messages in thread
* [PATCH 4/5] firmware: imx: Add i.MX95 SCMI LMM driver
2025-01-21 15:08 [PATCH 0/5] firmware: scmi/imx: Add i.MX95 LMM/CPU Protocol Peng Fan (OSS)
` (2 preceding siblings ...)
2025-01-21 15:08 ` [PATCH 3/5] firmware: arm_scmi: imx: Add LMM and CPU documentation Peng Fan (OSS)
@ 2025-01-21 15:08 ` Peng Fan (OSS)
2025-01-21 15:08 ` [PATCH 5/5] firmware: imx: Add i.MX95 SCMI CPU driver Peng Fan (OSS)
` (3 subsequent siblings)
7 siblings, 0 replies; 23+ messages in thread
From: Peng Fan (OSS) @ 2025-01-21 15:08 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-kernel, arm-scmi, linux-arm-kernel, imx, Peng Fan
From: Peng Fan <peng.fan@nxp.com>
The i.MX95 System manager exports SCMI LMM protocol for linux to manage
Logical Machines. The driver is to use the LMM Protocol interface to
boot, shutdown a LM.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/firmware/imx/Kconfig | 11 +++++
drivers/firmware/imx/Makefile | 1 +
drivers/firmware/imx/sm-lmm.c | 89 +++++++++++++++++++++++++++++++++++++++++
include/linux/firmware/imx/sm.h | 27 +++++++++++++
4 files changed, 128 insertions(+)
diff --git a/drivers/firmware/imx/Kconfig b/drivers/firmware/imx/Kconfig
index 907cd149c40a8b5f1b14c53e1c315ff4a28f32ac..c3e344d6ecc645df1f0e3ee8078934c47f347fd7 100644
--- a/drivers/firmware/imx/Kconfig
+++ b/drivers/firmware/imx/Kconfig
@@ -23,6 +23,17 @@ config IMX_SCU
This driver manages the IPC interface between host CPU and the
SCU firmware running on M4.
+config IMX_SCMI_LMM_DRV
+ tristate "IMX SCMI LMM Protocol driver"
+ depends on IMX_SCMI_LMM_EXT || COMPILE_TEST
+ default y if ARCH_MXC
+ help
+ The System Controller Management Interface firmware (SCMI FW) is
+ a low-level system function which runs on a dedicated Cortex-M
+ core that could provide Logical Machine management features.
+
+ This driver can also be built as a module.
+
config IMX_SCMI_MISC_DRV
tristate "IMX SCMI MISC Protocol driver"
default y if ARCH_MXC
diff --git a/drivers/firmware/imx/Makefile b/drivers/firmware/imx/Makefile
index 8d046c341be878bb6dd1e6277992ff66ae90e292..7762855d2a771169d4f1867d27e0d51be7c9ad03 100644
--- a/drivers/firmware/imx/Makefile
+++ b/drivers/firmware/imx/Makefile
@@ -2,3 +2,4 @@
obj-$(CONFIG_IMX_DSP) += imx-dsp.o
obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o imx-scu-irq.o rm.o imx-scu-soc.o
obj-${CONFIG_IMX_SCMI_MISC_DRV} += sm-misc.o
+obj-${CONFIG_IMX_SCMI_LMM_DRV} += sm-lmm.o
diff --git a/drivers/firmware/imx/sm-lmm.c b/drivers/firmware/imx/sm-lmm.c
new file mode 100644
index 0000000000000000000000000000000000000000..91a504e7f0d99089d3c2250a7918fb2fe99e991d
--- /dev/null
+++ b/drivers/firmware/imx/sm-lmm.c
@@ -0,0 +1,89 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2025 NXP
+ */
+
+#include <linux/firmware/imx/sm.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/scmi_protocol.h>
+#include <linux/scmi_imx_protocol.h>
+
+static const struct scmi_imx_lmm_proto_ops *imx_lmm_ops;
+static struct scmi_protocol_handle *ph;
+
+int scmi_imx_lmm_boot(u32 lmid)
+{
+ if (!ph)
+ return -EPROBE_DEFER;
+
+ return imx_lmm_ops->lmm_boot(ph, lmid);
+};
+EXPORT_SYMBOL(scmi_imx_lmm_boot);
+
+int scmi_imx_lmm_info(u32 lmid, struct scmi_imx_lmm_info *info)
+{
+ if (!ph)
+ return -EPROBE_DEFER;
+
+ if (!info)
+ return -EINVAL;
+
+ return imx_lmm_ops->lmm_info(ph, lmid, info);
+};
+EXPORT_SYMBOL(scmi_imx_lmm_info);
+
+int scmi_imx_lmm_power_on(u32 lmid)
+{
+ if (!ph)
+ return -EPROBE_DEFER;
+
+ return imx_lmm_ops->lmm_power_on(ph, lmid);
+};
+EXPORT_SYMBOL(scmi_imx_lmm_power_on);
+
+int scmi_imx_lmm_shutdown(u32 lmid, u32 flags)
+{
+ if (!ph)
+ return -EPROBE_DEFER;
+
+ return imx_lmm_ops->lmm_shutdown(ph, lmid, flags);
+};
+EXPORT_SYMBOL(scmi_imx_lmm_shutdown);
+
+static int scmi_imx_lmm_probe(struct scmi_device *sdev)
+{
+ const struct scmi_handle *handle = sdev->handle;
+
+ if (!handle)
+ return -ENODEV;
+
+ if (imx_lmm_ops) {
+ dev_err(&sdev->dev, "lmm already initialized\n");
+ return -EEXIST;
+ }
+
+ imx_lmm_ops = handle->devm_protocol_get(sdev, SCMI_PROTOCOL_IMX_LMM, &ph);
+ if (IS_ERR(imx_lmm_ops))
+ return PTR_ERR(imx_lmm_ops);
+
+ return 0;
+}
+
+static const struct scmi_device_id scmi_id_table[] = {
+ { SCMI_PROTOCOL_IMX_LMM, "imx-lmm" },
+ { },
+};
+MODULE_DEVICE_TABLE(scmi, scmi_id_table);
+
+static struct scmi_driver scmi_imx_lmm_driver = {
+ .name = "scmi-imx-lmm",
+ .probe = scmi_imx_lmm_probe,
+ .id_table = scmi_id_table,
+};
+module_scmi_driver(scmi_imx_lmm_driver);
+
+MODULE_AUTHOR("Peng Fan <peng.fan@nxp.com>");
+MODULE_DESCRIPTION("IMX SM LMM driver");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/firmware/imx/sm.h b/include/linux/firmware/imx/sm.h
index 9b85a3f028d1b0a5287b453eb3ad8412a363fe6c..1e58ffaa81acd757d9e6a992a2f2df663681c08a 100644
--- a/include/linux/firmware/imx/sm.h
+++ b/include/linux/firmware/imx/sm.h
@@ -8,6 +8,7 @@
#include <linux/bitfield.h>
#include <linux/errno.h>
+#include <linux/scmi_imx_protocol.h>
#include <linux/types.h>
#define SCMI_IMX_CTRL_PDM_CLK_SEL 0 /* AON PDM clock sel */
@@ -20,4 +21,30 @@
int scmi_imx_misc_ctrl_get(u32 id, u32 *num, u32 *val);
int scmi_imx_misc_ctrl_set(u32 id, u32 val);
+#if IS_ENABLED(CONFIG_IMX_SCMI_LMM_DRV) || IS_ENABLED(CONFIG_COMPILE_TEST)
+int scmi_imx_lmm_boot(u32 lmid);
+int scmi_imx_lmm_info(u32 lmid, struct scmi_imx_lmm_info *info);
+int scmi_imx_lmm_power_on(u32 lmid);
+int scmi_imx_lmm_shutdown(u32 lmid, u32 flags);
+#else
+static inline int scmi_imx_lmm_boot(u32 lmid)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline int scmi_imx_lmm_info(u32 lmid, struct scmi_imx_lmm_info *info)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline int scmi_imx_lmm_power_on(u32 lmid)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline int scmi_imx_lmm_shutdown(u32 lmid, u32 flags)
+{
+ return -EOPNOTSUPP;
+}
+#endif
#endif
--
2.37.1
^ permalink raw reply related [flat|nested] 23+ messages in thread
* [PATCH 5/5] firmware: imx: Add i.MX95 SCMI CPU driver
2025-01-21 15:08 [PATCH 0/5] firmware: scmi/imx: Add i.MX95 LMM/CPU Protocol Peng Fan (OSS)
` (3 preceding siblings ...)
2025-01-21 15:08 ` [PATCH 4/5] firmware: imx: Add i.MX95 SCMI LMM driver Peng Fan (OSS)
@ 2025-01-21 15:08 ` Peng Fan (OSS)
2025-01-21 15:31 ` [PATCH 0/5] firmware: scmi/imx: Add i.MX95 LMM/CPU Protocol Cristian Marussi
` (2 subsequent siblings)
7 siblings, 0 replies; 23+ messages in thread
From: Peng Fan (OSS) @ 2025-01-21 15:08 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-kernel, arm-scmi, linux-arm-kernel, imx, Peng Fan
From: Peng Fan <peng.fan@nxp.com>
The i.MX95 System manager exports SCMI CPU protocol for linux to manage
cpu cores. The driver is to use the cpu Protocol interface to
start, stop a cpu cores (eg, M7).
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/firmware/imx/Kconfig | 11 +++++
drivers/firmware/imx/Makefile | 1 +
drivers/firmware/imx/sm-cpu.c | 91 +++++++++++++++++++++++++++++++++++++++++
include/linux/firmware/imx/sm.h | 29 +++++++++++++
4 files changed, 132 insertions(+)
diff --git a/drivers/firmware/imx/Kconfig b/drivers/firmware/imx/Kconfig
index c3e344d6ecc645df1f0e3ee8078934c47f347fd7..91c753921dffbe16ced8c10565d44c15b66b2797 100644
--- a/drivers/firmware/imx/Kconfig
+++ b/drivers/firmware/imx/Kconfig
@@ -23,6 +23,17 @@ config IMX_SCU
This driver manages the IPC interface between host CPU and the
SCU firmware running on M4.
+config IMX_SCMI_CPU_DRV
+ tristate "IMX SCMI CPU Protocol driver"
+ depends on IMX_SCMI_CPU_EXT || COMPILE_TEST
+ default y if ARCH_MXC
+ help
+ The System Controller Management Interface firmware (SCMI FW) is
+ a low-level system function which runs on a dedicated Cortex-M
+ core that could provide cpu management features.
+
+ This driver can also be built as a module.
+
config IMX_SCMI_LMM_DRV
tristate "IMX SCMI LMM Protocol driver"
depends on IMX_SCMI_LMM_EXT || COMPILE_TEST
diff --git a/drivers/firmware/imx/Makefile b/drivers/firmware/imx/Makefile
index 7762855d2a771169d4f1867d27e0d51be7c9ad03..3bbaffa6e3478112638ed031375602389f18ef09 100644
--- a/drivers/firmware/imx/Makefile
+++ b/drivers/firmware/imx/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_IMX_DSP) += imx-dsp.o
obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o imx-scu-irq.o rm.o imx-scu-soc.o
+obj-${CONFIG_IMX_SCMI_CPU_DRV} += sm-cpu.o
obj-${CONFIG_IMX_SCMI_MISC_DRV} += sm-misc.o
obj-${CONFIG_IMX_SCMI_LMM_DRV} += sm-lmm.o
diff --git a/drivers/firmware/imx/sm-cpu.c b/drivers/firmware/imx/sm-cpu.c
new file mode 100644
index 0000000000000000000000000000000000000000..1ce694a34b22843db5c1697ecb33c0479edb2ed9
--- /dev/null
+++ b/drivers/firmware/imx/sm-cpu.c
@@ -0,0 +1,91 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2025 NXP
+ */
+
+#include <linux/firmware/imx/sm.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/scmi_protocol.h>
+#include <linux/scmi_imx_protocol.h>
+
+static const struct scmi_imx_cpu_proto_ops *imx_cpu_ops;
+static struct scmi_protocol_handle *ph;
+
+int scmi_imx_cpu_reset_vector_set(u32 cpuid, u64 vector, bool start, bool boot,
+ bool resume)
+{
+ if (!ph)
+ return -EPROBE_DEFER;
+
+ return imx_cpu_ops->cpu_reset_vector_set(ph, cpuid, vector, start,
+ boot, resume);
+}
+EXPORT_SYMBOL(scmi_imx_cpu_reset_vector_set);
+
+int scmi_imx_cpu_start(u32 cpuid)
+{
+ if (!ph)
+ return -EPROBE_DEFER;
+
+ return imx_cpu_ops->cpu_start(ph, cpuid);
+};
+EXPORT_SYMBOL(scmi_imx_cpu_start);
+
+int scmi_imx_cpu_started(u32 cpuid, bool *started)
+{
+ if (!ph)
+ return -EPROBE_DEFER;
+
+ if (!started)
+ return -EINVAL;
+
+ return imx_cpu_ops->cpu_started(ph, cpuid, started);
+};
+EXPORT_SYMBOL(scmi_imx_cpu_started);
+
+int scmi_imx_cpu_stop(u32 cpuid)
+{
+ if (!ph)
+ return -EPROBE_DEFER;
+
+ return imx_cpu_ops->cpu_stop(ph, cpuid);
+};
+EXPORT_SYMBOL(scmi_imx_cpu_stop);
+
+static int scmi_imx_cpu_probe(struct scmi_device *sdev)
+{
+ const struct scmi_handle *handle = sdev->handle;
+
+ if (!handle)
+ return -ENODEV;
+
+ if (imx_cpu_ops) {
+ dev_err(&sdev->dev, "sm cpu already initialized\n");
+ return -EEXIST;
+ }
+
+ imx_cpu_ops = handle->devm_protocol_get(sdev, SCMI_PROTOCOL_IMX_CPU, &ph);
+ if (IS_ERR(imx_cpu_ops))
+ return PTR_ERR(imx_cpu_ops);
+
+ return 0;
+}
+
+static const struct scmi_device_id scmi_id_table[] = {
+ { SCMI_PROTOCOL_IMX_CPU, "imx-cpu" },
+ { },
+};
+MODULE_DEVICE_TABLE(scmi, scmi_id_table);
+
+static struct scmi_driver scmi_imx_cpu_driver = {
+ .name = "scmi-imx-cpu",
+ .probe = scmi_imx_cpu_probe,
+ .id_table = scmi_id_table,
+};
+module_scmi_driver(scmi_imx_cpu_driver);
+
+MODULE_AUTHOR("Peng Fan <peng.fan@nxp.com>");
+MODULE_DESCRIPTION("IMX SM CPU driver");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/firmware/imx/sm.h b/include/linux/firmware/imx/sm.h
index 1e58ffaa81acd757d9e6a992a2f2df663681c08a..d12d5323cf842343e5d470b2aac01a9e4e269c30 100644
--- a/include/linux/firmware/imx/sm.h
+++ b/include/linux/firmware/imx/sm.h
@@ -21,6 +21,35 @@
int scmi_imx_misc_ctrl_get(u32 id, u32 *num, u32 *val);
int scmi_imx_misc_ctrl_set(u32 id, u32 val);
+#if IS_ENABLED(CONFIG_IMX_SCMI_CPU_DRV) || IS_ENABLED(CONFIG_COMPILE_TEST)
+int scmi_imx_cpu_start(u32 cpuid);
+int scmi_imx_cpu_started(u32 cpuid, bool *started);
+int scmi_imx_cpu_stop(u32 cpuid);
+int scmi_imx_cpu_reset_vector_set(u32 cpuid, u64 vector, bool start, bool boot,
+ bool resume);
+#else
+static inline int scmi_imx_cpu_start(u32 cpuid)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline int scmi_imx_cpu_started(u32 cpuid, bool *started)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline int scmi_imx_cpu_stop(u32 cpuid)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline int scmi_imx_cpu_reset_vector_set(u32 cpuid, u64 vector,
+ bool start, bool boot, bool resume)
+{
+ return -EOPNOTSUPP;
+}
+#endif
+
#if IS_ENABLED(CONFIG_IMX_SCMI_LMM_DRV) || IS_ENABLED(CONFIG_COMPILE_TEST)
int scmi_imx_lmm_boot(u32 lmid);
int scmi_imx_lmm_info(u32 lmid, struct scmi_imx_lmm_info *info);
--
2.37.1
^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [PATCH 0/5] firmware: scmi/imx: Add i.MX95 LMM/CPU Protocol
2025-01-21 15:08 [PATCH 0/5] firmware: scmi/imx: Add i.MX95 LMM/CPU Protocol Peng Fan (OSS)
` (4 preceding siblings ...)
2025-01-21 15:08 ` [PATCH 5/5] firmware: imx: Add i.MX95 SCMI CPU driver Peng Fan (OSS)
@ 2025-01-21 15:31 ` Cristian Marussi
2025-01-22 5:31 ` Peng Fan
2025-01-25 1:00 ` Peng Fan
2025-02-06 2:40 ` Peng Fan
7 siblings, 1 reply; 23+ messages in thread
From: Cristian Marussi @ 2025-01-21 15:31 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Sudeep Holla, Cristian Marussi, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-kernel, arm-scmi,
linux-arm-kernel, imx, Peng Fan
On Tue, Jan 21, 2025 at 11:08:10PM +0800, Peng Fan (OSS) wrote:
> i.MX95 System Manager(SM) implements Logical Machine Management(LMM) and
> CPU protocol to manage Logical Machine(LM) and CPUs(eg, M7).
>
> To manage M7 in a separate LM or in same LM as Linux itself. LMM APIs
> and CPU APIs are needed.
>
Hi Peng,
I see that you are really starting to like vendor extensions
capabilities :P ... jokes apart I'll have a deeper look at this in the
next days (togetehr with your other pending patches...), BUT in the
meantime a quick one...where are the bindings for these additional
vendor protocols...seems like a patch is missing to add those in
Documentation/devicetree/bindings/firmware/nxp,imx95-scmi.yaml
...even if bare simple protocol numbers (like existing protocol@81)
currently these are needed for the protocol to be initialized by the
core.
Thanks,
Cristian
^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: [PATCH 0/5] firmware: scmi/imx: Add i.MX95 LMM/CPU Protocol
2025-01-21 15:31 ` [PATCH 0/5] firmware: scmi/imx: Add i.MX95 LMM/CPU Protocol Cristian Marussi
@ 2025-01-22 5:31 ` Peng Fan
0 siblings, 0 replies; 23+ messages in thread
From: Peng Fan @ 2025-01-22 5:31 UTC (permalink / raw)
To: Cristian Marussi, Peng Fan (OSS)
Cc: Sudeep Holla, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-kernel@vger.kernel.org,
arm-scmi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
imx@lists.linux.dev
Hi Cristian,
> Subject: Re: [PATCH 0/5] firmware: scmi/imx: Add i.MX95 LMM/CPU
> Protocol
>
> On Tue, Jan 21, 2025 at 11:08:10PM +0800, Peng Fan (OSS) wrote:
> > i.MX95 System Manager(SM) implements Logical Machine
> Management(LMM)
> > and CPU protocol to manage Logical Machine(LM) and CPUs(eg, M7).
> >
> > To manage M7 in a separate LM or in same LM as Linux itself. LMM
> APIs
> > and CPU APIs are needed.
> >
>
> Hi Peng,
>
> I see that you are really starting to like vendor extensions
> capabilities :P ... jokes apart
I not like vendor extensions (:
I'll have a deeper look at this in the next
> days (togetehr with your other pending patches...),
Thanks for helping reviewing patches.
BUT in the
> meantime a quick one...where are the bindings for these additional
> vendor protocols...seems like a patch is missing to add those in
>
> Documentation/devicetree/bindings/firmware/nxp,imx95-scmi.yaml
>
> ...even if bare simple protocol numbers (like existing protocol@81)
> currently these are needed for the protocol to be initialized by the core.
I missed that. Thanks for pointing out. I will include the binding in V2.
V2 will be post out later after collecting some comments on V1.
Thanks,
Peng.
>
> Thanks,
> Cristian
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 2/5] firmware: arm_scmi: imx: Add i.MX95 CPU Protocol
2025-01-21 15:08 ` [PATCH 2/5] firmware: arm_scmi: imx: Add i.MX95 CPU Protocol Peng Fan (OSS)
@ 2025-01-22 8:48 ` Dan Carpenter
2025-01-22 12:22 ` Cristian Marussi
2025-01-24 4:11 ` kernel test robot
1 sibling, 1 reply; 23+ messages in thread
From: Dan Carpenter @ 2025-01-22 8:48 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Sudeep Holla, Cristian Marussi, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-kernel, arm-scmi,
linux-arm-kernel, imx, Peng Fan
On Tue, Jan 21, 2025 at 11:08:12PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> This protocol allows an agent to start, stop a CPU or set reset vector. It
> is used to manage auxiliary CPUs in an LM (e.g. additional cores in an AP
> cluster).
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> drivers/firmware/arm_scmi/vendors/imx/Kconfig | 13 +-
> drivers/firmware/arm_scmi/vendors/imx/Makefile | 1 +
> drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c | 283 +++++++++++++++++++++
> include/linux/scmi_imx_protocol.h | 10 +
> 4 files changed, 306 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/arm_scmi/vendors/imx/Kconfig b/drivers/firmware/arm_scmi/vendors/imx/Kconfig
> index 1a936fc87d2350e2a21bccd45dfbeebfa3b90286..9070522510e4d3f3d7276a7581f8676006d20f90 100644
> --- a/drivers/firmware/arm_scmi/vendors/imx/Kconfig
> +++ b/drivers/firmware/arm_scmi/vendors/imx/Kconfig
> @@ -12,6 +12,17 @@ config IMX_SCMI_BBM_EXT
> To compile this driver as a module, choose M here: the
> module will be called imx-sm-bbm.
>
> +config IMX_SCMI_CPU_EXT
> + tristate "i.MX SCMI CPU EXTENSION"
> + depends on ARM_SCMI_PROTOCOL || (COMPILE_TEST && OF)
> + default y if ARCH_MXC
> + help
> + This enables i.MX System CPU Protocol to manage cpu
> + start, stop and etc.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called imx-sm-cpu.
> +
> config IMX_SCMI_LMM_EXT
> tristate "i.MX SCMI LMM EXTENSION"
> depends on ARM_SCMI_PROTOCOL || (COMPILE_TEST && OF)
> @@ -21,7 +32,7 @@ config IMX_SCMI_LMM_EXT
> manage Logical Machines boot, shutdown and etc.
>
> To compile this driver as a module, choose M here: the
> - module will be called imx-sm-lmm.
> + module will be called imx-sm-cpu.
>
It's supposed to be called imx-sm-lmm.
> config IMX_SCMI_MISC_EXT
> tristate "i.MX SCMI MISC EXTENSION"
> diff --git a/drivers/firmware/arm_scmi/vendors/imx/Makefile b/drivers/firmware/arm_scmi/vendors/imx/Makefile
> index f39a99ccaf9af757475e8b112d224669444d7ddc..e3a5ea46345c89da1afae25e55698044672b7c28 100644
> --- a/drivers/firmware/arm_scmi/vendors/imx/Makefile
> +++ b/drivers/firmware/arm_scmi/vendors/imx/Makefile
> @@ -1,4 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0-only
> obj-$(CONFIG_IMX_SCMI_BBM_EXT) += imx-sm-bbm.o
> +obj-$(CONFIG_IMX_SCMI_CPU_EXT) += imx-sm-cpu.o
> obj-$(CONFIG_IMX_SCMI_LMM_EXT) += imx-sm-lmm.o
> obj-$(CONFIG_IMX_SCMI_MISC_EXT) += imx-sm-misc.o
> diff --git a/drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..e3f294c2cb69a5b5a916d55984f4a63539937d02
> --- /dev/null
> +++ b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c
> @@ -0,0 +1,283 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * System control and Management Interface (SCMI) NXP CPU Protocol
> + *
> + * Copyright 2025 NXP
> + */
> +
> +#include <linux/bits.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/scmi_protocol.h>
> +#include <linux/scmi_imx_protocol.h>
> +
> +#include "../../protocols.h"
> +#include "../../notify.h"
> +
> +#define SCMI_PROTOCOL_SUPPORTED_VERSION 0x10000
> +
> +enum scmi_imx_cpu_protocol_cmd {
> + SCMI_IMX_CPU_ATTRIBUTES = 0x3,
> + SCMI_IMX_CPU_START = 0x4,
> + SCMI_IMX_CPU_STOP = 0x5,
> + SCMI_IMX_CPU_RESET_VECTOR_SET = 0x6,
> + SCMI_IMX_CPU_INFO_GET = 0xC,
> +};
> +
> +struct scmi_imx_cpu_info {
> + u32 nr_cpu;
> +};
> +
> +#define SCMI_IMX_CPU_PROTO_ATTR_NUM_CPUS(x) ((x) & 0xFFFF)
> +struct scmi_msg_imx_cpu_protocol_attributes {
> + __le32 attributes;
> +};
> +
> +struct scmi_msg_imx_cpu_attributes_out {
> + __le32 attributes;
> +#define CPU_MAX_NAME 16
> + u8 name[CPU_MAX_NAME];
char is always unsigned in the kernel these days but strings should
still always be char. Same thing in patch 1, there were a couple u8
names.
> +};
> +
> +struct scmi_imx_cpu_reset_vector_set_in {
> + __le32 cpuid;
> +#define CPU_VEC_FLAGS_RESUME BIT(31)
> +#define CPU_VEC_FLAGS_START BIT(30)
> +#define CPU_VEC_FLAGS_BOOT BIT(29)
> + __le32 flags;
> + __le32 resetvectorlow;
> + __le32 resetvectorhigh;
> +};
> +
> +struct scmi_imx_cpu_info_get_out {
> +#define CPU_RUN_MODE_START 0
> +#define CPU_RUN_MODE_HOLD 1
> +#define CPU_RUN_MODE_STOP 2
> +#define CPU_RUN_MODE_SLEEP 3
> + __le32 runmode;
> + __le32 sleepmode;
> + __le32 resetvectorlow;
> + __le32 resetvectorhigh;
> +};
> +
> +static int scmi_imx_cpu_validate_cpuid(const struct scmi_protocol_handle *ph,
> + u32 cpuid)
> +{
> + struct scmi_imx_cpu_info *info = ph->get_priv(ph);
> +
> + if (cpuid >= info->nr_cpu)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int scmi_imx_cpu_start(const struct scmi_protocol_handle *ph, u32 cpuid)
> +{
> + struct scmi_xfer *t;
> + int ret;
> +
> + ret = scmi_imx_cpu_validate_cpuid(ph, cpuid);
> + if (ret)
> + return ret;
> +
> + ret = ph->xops->xfer_get_init(ph, SCMI_IMX_CPU_START, sizeof(u32),
> + 0, &t);
> + if (ret)
> + return ret;
> +
> + put_unaligned_le32(cpuid, t->tx.buf);
> + ret = ph->xops->do_xfer(ph, t);
> +
> + ph->xops->xfer_put(ph, t);
> +
> + return ret;
> +}
> +
> +static int scmi_imx_cpu_stop(const struct scmi_protocol_handle *ph, u32 cpuid)
> +{
> + struct scmi_xfer *t;
> + int ret;
> +
> + ret = scmi_imx_cpu_validate_cpuid(ph, cpuid);
> + if (ret)
> + return ret;
> +
> + ret = ph->xops->xfer_get_init(ph, SCMI_IMX_CPU_STOP, sizeof(u32),
> + 0, &t);
> + if (ret)
> + return ret;
> +
> + put_unaligned_le32(cpuid, t->tx.buf);
> + ret = ph->xops->do_xfer(ph, t);
> +
> + ph->xops->xfer_put(ph, t);
> +
> + return ret;
> +}
> +
> +static int scmi_imx_cpu_reset_vector_set(const struct scmi_protocol_handle *ph,
> + u32 cpuid, u64 vector, bool start,
> + bool boot, bool resume)
> +{
> + struct scmi_imx_cpu_reset_vector_set_in *in;
> + struct scmi_xfer *t;
> + int ret;
> +
> + ret = scmi_imx_cpu_validate_cpuid(ph, cpuid);
> + if (ret)
> + return ret;
> +
> + ret = ph->xops->xfer_get_init(ph, SCMI_IMX_CPU_RESET_VECTOR_SET, sizeof(*in),
> + 0, &t);
> + if (ret)
> + return ret;
> +
> + in = t->tx.buf;
> + in->cpuid = cpu_to_le32(cpuid);
> + in->flags = start ? CPU_VEC_FLAGS_START : 0;
> + in->flags |= boot ? CPU_VEC_FLAGS_BOOT : 0;
> + in->flags |= resume ? CPU_VEC_FLAGS_BOOT : 0;
s/CPU_VEC_FLAGS_BOOT/CPU_VEC_FLAGS_RESUME/
> + in->resetvectorlow = cpu_to_le32(lower_32_bits(vector));
> + in->resetvectorhigh = cpu_to_le32(upper_32_bits(vector));
> + ret = ph->xops->do_xfer(ph, t);
> +
> + ph->xops->xfer_put(ph, t);
> +
> + return ret;
> +}
> +
> +static int scmi_imx_cpu_started(const struct scmi_protocol_handle *ph, u32 cpuid,
> + bool *started)
> +{
> + struct scmi_imx_cpu_info_get_out *out;
> + struct scmi_xfer *t;
> + int ret;
> +
> + *started = false;
> + ret = scmi_imx_cpu_validate_cpuid(ph, cpuid);
> + if (ret)
> + return ret;
> +
> + ret = ph->xops->xfer_get_init(ph, SCMI_IMX_CPU_INFO_GET, sizeof(u32),
> + 0, &t);
> + if (ret)
> + return ret;
> +
> + put_unaligned_le32(cpuid, t->tx.buf);
> + ret = ph->xops->do_xfer(ph, t);
> + if (!ret) {
> + out = t->rx.buf;
> + if ((out->runmode == CPU_RUN_MODE_START) ||
> + (out->runmode == CPU_RUN_MODE_SLEEP))
> + *started = true;
> + }
> +
> + ph->xops->xfer_put(ph, t);
> +
> + return ret;
> +}
> +
> +static const struct scmi_imx_cpu_proto_ops scmi_imx_cpu_proto_ops = {
> + .cpu_reset_vector_set = scmi_imx_cpu_reset_vector_set,
> + .cpu_start = scmi_imx_cpu_start,
> + .cpu_started = scmi_imx_cpu_started,
> + .cpu_stop = scmi_imx_cpu_stop,
> +};
> +
> +static int scmi_imx_cpu_protocol_attributes_get(const struct scmi_protocol_handle *ph,
> + struct scmi_imx_cpu_info *info)
> +{
> + struct scmi_msg_imx_cpu_protocol_attributes *attr;
> + struct scmi_xfer *t;
> + int ret;
> +
> + ret = ph->xops->xfer_get_init(ph, PROTOCOL_ATTRIBUTES, 0,
> + sizeof(*attr), &t);
> + if (ret)
> + return ret;
> +
> + attr = t->rx.buf;
> +
> + ret = ph->xops->do_xfer(ph, t);
> + if (!ret) {
> + info->nr_cpu = SCMI_IMX_CPU_PROTO_ATTR_NUM_CPUS(attr->attributes);
> + dev_info(ph->dev, "i.MX SM CPU: %d cpus\n",
> + info->nr_cpu);
This can fit in 80 characters:
dev_info(ph->dev, "i.MX SM CPU: %d cpus\n", info->nr_cpu);
> + }
> +
> + ph->xops->xfer_put(ph, t);
> +
> + return ret;
> +}
> +
> +static int scmi_imx_cpu_attributes_get(const struct scmi_protocol_handle *ph,
> + u32 cpuid, struct scmi_imx_cpu_info *info)
No need to pass the "info" pointer.
> +{
> + struct scmi_msg_imx_cpu_attributes_out *out;
> + struct scmi_xfer *t;
> + int ret;
> +
> + ret = ph->xops->xfer_get_init(ph, SCMI_IMX_CPU_ATTRIBUTES, sizeof(u32), 0, &t);
> + if (ret)
> + return ret;
> +
> + put_unaligned_le32(cpuid, t->tx.buf);
> + ret = ph->xops->do_xfer(ph, t);
> + if (!ret) {
> + out = t->rx.buf;
> + dev_info(ph->dev, "i.MX CPU: name: %s\n", out->name);
> + } else {
> + dev_err(ph->dev, "i.MX cpu: Failed to get info of cpu(%u)\n", cpuid);
> + }
> +
> + ph->xops->xfer_put(ph, t);
> +
> + return ret;
> +}
> +
> +
Multiple blank lines (checkpatch.pl --strict).
> +static int scmi_imx_cpu_protocol_init(const struct scmi_protocol_handle *ph)
> +{
regards,
dan carpenter
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 3/5] firmware: arm_scmi: imx: Add LMM and CPU documentation
2025-01-21 15:08 ` [PATCH 3/5] firmware: arm_scmi: imx: Add LMM and CPU documentation Peng Fan (OSS)
@ 2025-01-22 12:14 ` Sudeep Holla
2025-01-23 1:30 ` Peng Fan
0 siblings, 1 reply; 23+ messages in thread
From: Sudeep Holla @ 2025-01-22 12:14 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Cristian Marussi, Sudeep Holla, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-kernel, arm-scmi,
linux-arm-kernel, imx, Peng Fan
On Tue, Jan 21, 2025 at 11:08:13PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> Add i.MX95 Logical Machine Management and CPU Protocol documentation.
>
Please make this the first patch when you need to respin this(which is
clearly not yet 😁)
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> drivers/firmware/arm_scmi/vendors/imx/imx95.rst | 692 ++++++++++++++++++++++++
> 1 file changed, 692 insertions(+)
>
> diff --git a/drivers/firmware/arm_scmi/vendors/imx/imx95.rst b/drivers/firmware/arm_scmi/vendors/imx/imx95.rst
> index b2dfd6c46ca2f5f12f0475c24cb54c060e9fa421..384d4f9c27e489a9c54cdde79c9f03a6f5979630 100644
> --- a/drivers/firmware/arm_scmi/vendors/imx/imx95.rst
> +++ b/drivers/firmware/arm_scmi/vendors/imx/imx95.rst
> @@ -32,6 +32,419 @@ port, and deploy the SM on supported processors.
> The SM implements an interface compliant with the Arm SCMI Specification
> with additional vendor specific extensions.
>
> +SCMI_LMM: System Control and Management Logical Machine Management Vendor Protocol
> +==================================================================================
> +
> +This protocol is intended for boot, shutdown, and reset of other logical
> +machines (LM). It is usually used to allow one LM to manager another used
> +as an offload or accelerator engine.
The above statement is very hard to parse. Can it be
"
It is usually used to allow one LM(e.g. OSPM) to manage another LM which
is usually an offload or accelerator engine.
"
if I understood it correctly ?
> Notifications from this protocol can
> +also be used to manage a communication link to another LM. The LMM protocol
> +provides functions to:
> +
> +- Describe the protocol version.
> +- Discover implementation attributes.
> +- Discover the LMs defined in the system.
> +- Boot an LM.
> +- Shut down an LM.
> +- Reset an LM.
> +- Wake an LM from suspend.
> +- Suspend an LM (gracefully).
> +- Request a graceful shutdown or reset of an LM.
Does that mean above "Shut down an LM" and "Reset an LM" are forced ones ?
> +- Allow an agent to forcibly power down or reset an LM.
How is this different from the above ?
> +- Read boot/shutdown/reset information for an LM.
> +- Get notifications when an LM boots or shuts down.
> +
> +Commands:
> +_________
> +
> +PROTOCOL_VERSION
> +~~~~~~~~~~~~~~~~
> +
> +message_id: 0x0
> +protocol_id: 0x80
> +
> ++---------------+--------------------------------------------------------------+
> +|Return values |
> ++---------------+--------------------------------------------------------------+
> +|Name |Description |
> ++---------------+--------------------------------------------------------------+
> +|int32 status | See ARM SCMI Specification for status code definitions. |
> ++---------------+--------------------------------------------------------------+
> +|uint32 version | For this revision of the specification, this value must be |
> +| | 0x10000. |
> ++---------------+--------------------------------------------------------------+
> +
> +PROTOCOL_ATTRIBUTES
> +~~~~~~~~~~~~~~~~~~~
> +
> +message_id: 0x1
> +protocol_id: 0x80
> +
> ++------------------+-----------------------------------------------------------+
> +|Return values |
> ++------------------+-----------------------------------------------------------+
> +|Name |Description |
> ++------------------+-----------------------------------------------------------+
> +|int32 status | See ARM SCMI Specification for status code definitions. |
> ++------------------+-----------------------------------------------------------+
> +|uint32 attributes |Protocol attributes: |
> +| |Bits[31:8] Reserved, must be zero. |
> +| |Bits[7:0] Number of Logical Machines |
> ++------------------+-----------------------------------------------------------+
> +
> +PROTOCOL_MESSAGE_ATTRIBUTES
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +message_id: 0x2
> +protocol_id: 0x80
> +
> ++------------------+-----------------------------------------------------------+
> +|Return values |
> ++------------------+-----------------------------------------------------------+
> +|Name |Description |
> ++------------------+-----------------------------------------------------------+
> +|int32 status |SUCCESS: in case the message is implemented and available |
> +| |to use. |
> +| |NOT_FOUND: if the message identified by message_id is |
> +| |invalid or not implemented |
> ++------------------+-----------------------------------------------------------+
> +|uint32 attributes |Flags that are associated with a specific function in the |
> +| |protocol. For all functions in this protocol, this |
> +| |parameter has a value of 0 |
> ++------------------+-----------------------------------------------------------+
> +
> +LMM_ATTRIBUTES
> +~~~~~~~~~~~~~~
> +
> +message_id: 0x3
> +protocol_id: 0x80
> +
> ++------------------+-----------------------------------------------------------+
> +|Parameters |
> ++------------------+-----------------------------------------------------------+
> +|Name |Description |
> ++------------------+-----------------------------------------------------------+
> +|uint32 lmid |ID of the Logical Machine |
> ++------------------+-----------------------------------------------------------+
> +|Return values |
> ++------------------+-----------------------------------------------------------+
> +|Name |Description |
> ++------------------+-----------------------------------------------------------+
Where are the actual attributes returned ?
> +|int32 status |SUCCESS: if valid attributes are returned. |
> +| |NOT_FOUND: if lmId not points to a valid logical machine. |
> +| |DENIED: if the agent does not have permission to get info |
> +| |for the LM specified by lmid. |
> ++------------------+-----------------------------------------------------------+
> +
> +LMM_BOOT
> +~~~~~~~~
> +
> +message_id: 0x4
> +protocol_id: 0x80
> +
> ++------------------+-----------------------------------------------------------+
> +|Parameters |
> ++------------------+-----------------------------------------------------------+
> +|Name |Description |
> ++------------------+-----------------------------------------------------------+
> +|uint32 lmid |ID of the Logical Machine |
> ++------------------+-----------------------------------------------------------+
> +|Return values |
> ++------------------+-----------------------------------------------------------+
> +|Name |Description |
> ++------------------+-----------------------------------------------------------+
> +|int32 status |SUCCESS: if LM successfully booted. |
> +| |NOT_FOUND: if lmId not points to a valid logical machine. |
> +| |INVALID_PARAMETERS: if lmId is same as the caller. |
> +| |DENIED: if the agent does not have permission to manage the|
> +| |the LM specified by lmid. |
> ++------------------+-----------------------------------------------------------+
> +
Is this synchronous boot ? When will the notifications be used then ?
> +LMM_RESET
> +~~~~~~~~~
> +
> +message_id: 0x5
> +protocol_id: 0x80
> +
> ++------------------+-----------------------------------------------------------+
> +|Parameters |
> ++------------------+-----------------------------------------------------------+
> +|Name |Description |
> ++------------------+-----------------------------------------------------------+
> +|uint32 lmid |ID of the Logical Machine |
> ++------------------+-----------------------------------------------------------+
> +|uint32 flags |Reset flags: |
> +| |Bits[31:1] Reserved, must be zero. |
> +| |Bit[0] Graceful request: |
> +| |Set to 1 if the request is a graceful request. |
> +| |Set to 0 if the request is a forceful request. |
Ah so you have flag here then. I wonder why you need separate command then ?
> ++------------------+-----------------------------------------------------------+
> +|Return values |
> ++------------------+-----------------------------------------------------------+
> +|Name |Description |
> ++------------------+-----------------------------------------------------------+
> +|int32 status |SUCCESS: if LM successfully resets. |
> +| |NOT_FOUND: if lmId not points to a valid logical machine. |
> +| |INVALID_PARAMETERS: if lmId is same as the caller. |
> +| |DENIED: if the agent does not have permission to manage the|
> +| |the LM specified by lmid. |
> ++------------------+-----------------------------------------------------------+
> +
Again, is this done synchronously ?
> +LMM_SHUTDOWN
> +~~~~~~~~~~~~
> +
> +message_id: 0x6
> +protocol_id: 0x80
> +
> ++------------------+-----------------------------------------------------------+
> +|Parameters |
> ++------------------+-----------------------------------------------------------+
> +|Name |Description |
> ++------------------+-----------------------------------------------------------+
> +|uint32 lmid |ID of the Logical Machine |
> ++------------------+-----------------------------------------------------------+
> +|uint32 flags |Reset flags: |
> +| |Bits[31:1] Reserved, must be zero. |
> +| |Bit[0] Graceful request: |
> +| |Set to 1 if the request is a graceful request. |
> +| |Set to 0 if the request is a forceful request. |
> ++------------------+-----------------------------------------------------------+
> +|Return values |
> ++------------------+-----------------------------------------------------------+
> +|Name |Description |
> ++------------------+-----------------------------------------------------------+
> +|int32 status |SUCCESS: if LM successfully shutdowns. |
> +| |NOT_FOUND: if lmId not points to a valid logical machine. |
> +| |INVALID_PARAMETERS: if lmId is same as the caller. |
> +| |DENIED: if the agent does not have permission to manage the|
> +| |the LM specified by lmid. |
> ++------------------+-----------------------------------------------------------+
> +
Ditto, sync ?
> +LMM_WAKE
> +~~~~~~~~
> +
> +message_id: 0x7
> +protocol_id: 0x80
> +
> ++------------------+-----------------------------------------------------------+
> +|Parameters |
> ++------------------+-----------------------------------------------------------+
> +|Name |Description |
> ++------------------+-----------------------------------------------------------+
> +|uint32 lmid |ID of the Logical Machine |
> ++------------------+-----------------------------------------------------------+
> +|Return values |
> ++------------------+-----------------------------------------------------------+
> +|Name |Description |
> ++------------------+-----------------------------------------------------------+
> +|int32 status |SUCCESS: if LM successfully wakes. |
> +| |NOT_FOUND: if lmId not points to a valid logical machine. |
> +| |INVALID_PARAMETERS: if lmId is same as the caller. |
> +| |DENIED: if the agent does not have permission to manage the|
> +| |the LM specified by lmid. |
> ++------------------+-----------------------------------------------------------+
> +
Ditto, sync ?
> +LMM_SUSPEND
> +~~~~~~~~~~~
> +
> +message_id: 0x8
> +protocol_id: 0x80
> +
> ++------------------+-----------------------------------------------------------+
> +|Parameters |
> ++------------------+-----------------------------------------------------------+
> +|Name |Description |
> ++------------------+-----------------------------------------------------------+
> +|uint32 lmid |ID of the Logical Machine |
> ++------------------+-----------------------------------------------------------+
> +|Return values |
> ++------------------+-----------------------------------------------------------+
> +|Name |Description |
> ++------------------+-----------------------------------------------------------+
> +|int32 status |SUCCESS: if LM successfully suspends. |
> +| |NOT_FOUND: if lmId not points to a valid logical machine. |
> +| |INVALID_PARAMETERS: if lmId is same as the caller. |
> +| |DENIED: if the agent does not have permission to manage the|
> +| |the LM specified by lmid. |
> ++------------------+-----------------------------------------------------------+
> +
Ditto, sync ?
> +LMM_NOTIFY
> +~~~~~~~~~~
> +
> +message_id: 0x9
> +protocol_id: 0x80
> +
> ++------------------+-----------------------------------------------------------+
> +|Parameters |
> ++------------------+-----------------------------------------------------------+
> +|Name |Description |
> ++------------------+-----------------------------------------------------------+
> +|uint32 lmid |ID of the Logical Machine |
> ++------------------+-----------------------------------------------------------+
> +|uint32 flags |Notification flags: |
> +| |Bits[31:3] Reserved, must be zero. |
> +| |Bit[3] Wake (resume) notification: |
> +| |Set to 1 to send notification. |
> +| |Set to 0 if no notification. |
> +| |Bit[2] Suspend (sleep) notification: |
> +| |Set to 1 to send notification. |
> +| |Set to 0 if no notification. |
> +| |Bit[1] Shutdown (off) notification: |
> +| |Set to 1 to send notification. |
> +| |Set to 0 if no notification. |
> +| |Bit[0] Boot (on) notification: |
> +| |Set to 1 to send notification. |
> +| |Set to 0 if no notification |
How about reset ?
> ++------------------+-----------------------------------------------------------+
> +|Return values |
> ++------------------+-----------------------------------------------------------+
> +|Name |Description |
> ++------------------+-----------------------------------------------------------+
> +|int32 status |SUCCESS: if the notification state successfully updated. |
> +| |NOT_FOUND: if lmId not points to a valid logical machine. |
> +| |INVALID_PARAMETERS: if input attributes flag specifies |
> +| |unsupported or invalid configurations. |
> +| |DENIED: if the agent does not have permission to request |
> +| |the notification. |
> ++------------------+-----------------------------------------------------------+
> +
> +LMM_RESET_REASON
> +~~~~~~~~~~~~~~~~
> +
> +message_id: 0xA
> +protocol_id: 0x80
> +
> ++---------------------+--------------------------------------------------------+
> +|Parameters |
> ++---------------------+--------------------------------------------------------+
> +|Name |Description |
> ++---------------------+--------------------------------------------------------+
> +|uint32 lmid |ID of the Logical Machine |
> ++---------------------+--------------------------------------------------------+
> +|Return values |
> ++---------------------+--------------------------------------------------------+
> +|Name |Description |
> ++---------------------+--------------------------------------------------------+
> +|int32 status |SUCCESS: if LM successfully suspends. |
> +| |NOT_FOUND: if lmId not points to a valid logical machine|
> +| |DENIED: if the agent does not have permission to request|
> +| |the reset reason. |
> ++---------------------+--------------------------------------------------------+
> +|uint32 bootflags |Boot reason flags. This parameter has the format: |
> +| |Bits[31] Valid. |
> +| |Set to 1 if the entire reason is valid. |
> +| |Set to 0 if the entire reason is not valid. |
> +| |Bits[30:29] Reserved, must be zero. |
> +| |Bit[28] Valid origin: |
Valid with origin ID perhaps ?
> +| |Set to 1 if the origin field is valid. |
> +| |Set to 0 if the origin field is not valid. |
> +| |Bits[27:24] Origin. |
> +| |Bit[23] Valid err ID: |
> +| |Set to 1 if the error ID field is valid. |
> +| |Set to 0 if the error ID field is not valid. |
> +| |Bits[22:8] Error ID. |
> +| |Bit[7:0] Reason |
Reasons definitions are Platform specific ?
> ++---------------------+--------------------------------------------------------+
> +|uint32 shutdownflags |Shutdown reason flags. This parameter has the format: |
> +| |Bits[31] Valid. |
> +| |Set to 1 if the entire reason is valid. |
> +| |Set to 0 if the entire reason is not valid. |
> +| |Bits[30:29] Number of valid extended info words. |
> +| |Bit[28] Valid origin: |
> +| |Set to 1 if the origin field is valid. |
> +| |Set to 0 if the origin field is not valid. |
> +| |Bits[27:24] Origin. |
> +| |Bit[23] Valid err ID: |
> +| |Set to 1 if the error ID field is valid. |
> +| |Set to 0 if the error ID field is not valid. |
> +| |Bits[22:8] Error ID. |
> +| |Bit[7:0] Reason |
Again nothing for reset ? Do you expect reset to be forceful shutdown and
boot in which case both the above are set ?
> ++---------------------+--------------------------------------------------------+
> +|uint32 extinfo[0,20] |Array of extended info words |
What are these ?
> ++---------------------+--------------------------------------------------------+
> +
> +LMM_POWER_ON
> +~~~~~~~~~~~~
> +
> +message_id: 0xB
> +protocol_id: 0x80
> +
> ++------------------+-----------------------------------------------------------+
> +|Parameters |
> ++------------------+-----------------------------------------------------------+
> +|Name |Description |
> ++------------------+-----------------------------------------------------------+
> +|uint32 lmid |ID of the Logical Machine |
> ++------------------+-----------------------------------------------------------+
> +|Return values |
> ++------------------+-----------------------------------------------------------+
> +|Name |Description |
> ++------------------+-----------------------------------------------------------+
> +|int32 status |SUCCESS: if LM successfully suspends. |
/me confused. Is it suspend(which is already defined) ? Or reset(again already
defined) ?
> +| |NOT_FOUND: if lmId not points to a valid logical machine. |
> +| |INVALID_PARAMETERS: if lmId is same as the caller. |
> +| |DENIED: if the agent does not have permission to manage the|
> +| |the LM specified by lmid. |
> ++------------------+-----------------------------------------------------------+
> +
> +NEGOTIATE_PROTOCOL_VERSION
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +message_id: 0x10
> +protocol_id: 0x80
> +
> ++--------------------+---------------------------------------------------------+
> +|Parameters |
> ++--------------------+---------------------------------------------------------+
> +|Name |Description |
> ++--------------------+---------------------------------------------------------+
> +|uint32 version |The negotiated protocol version the agent intends to use |
> ++--------------------+---------------------------------------------------------+
> +|Return values |
> ++--------------------+---------------------------------------------------------+
> +|Name |Description |
> ++--------------------+---------------------------------------------------------+
> +|int32 status |SUCCESS: if the negotiated protocol version is supported |
> +| |by the platform. All commands, responses, and |
> +| |notifications post successful return of this command must|
> +| |comply with the negotiated version. |
> +| |NOT_SUPPORTED: if the protocol version is not supported. |
> ++--------------------+---------------------------------------------------------+
> +
> +Notifications
> +_____________
> +
> +LMM_EVENT
> +~~~~~~~~~
> +
> +message_id: 0x0
> +protocol_id: 0x80
> +
> ++------------------+-----------------------------------------------------------+
> +|Parameters |
> ++------------------+-----------------------------------------------------------+
> +|Name |Description |
> ++------------------+-----------------------------------------------------------+
> +|uint32 lmid |Identifier for the LM that caused the transition. |
> ++------------------+-----------------------------------------------------------+
> +|uint32 eventlm |Identifier for the LM the event is for. |
> ++------------------+-----------------------------------------------------------+
> +|uint32 flags |LM events: |
> +| |Bits[31:3] Reserved, must be zero. |
> +| |Bit[3] Wake (resume) event: |
> +| |1 LM has awakened. |
> +| |0 not a wake event. |
> +| |Bit[2] Suspend (sleep) event: |
> +| |1 LM has suspended. |
> +| |0 not a suspend event. |
> +| |Bit[1] Shutdown (off) event: |
> +| |1 LM has shutdown. |
> +| |0 not a shutdown event. |
> +| |Bit[0] Boot (on) event: |
> +| |1 LM has booted. |
> +| |0 not a boot event. |
> ++------------------+-----------------------------------------------------------+
> +
> SCMI_BBM: System Control and Management BBM Vendor Protocol
> ==============================================================
>
> @@ -436,6 +849,285 @@ protocol_id: 0x81
> | |0 no button change detected. |
> +------------------+-----------------------------------------------------------+
>
> +SCMI_CPU: System Control and Management CPU Vendor Protocol
> +==============================================================
> +
> +This protocol allows an agent to start or stop a CPU. It is used to manage
> +auxiliary CPUs in an LM (e.g. additional cores in an AP cluster), The CPU
> +protocol provides functions to:
> +
Additional CPU in AP cluster ? That sounds alarming. Why not use PSCI ?
Also what other CPUs are we talking here. In general I would like to
explore the possibility of collapsing this with LM protocol. CPUs within
LM is LM's responsibility to bring up. And CPU can be seen as an LM for
sake of this vendor protocol. I am not get into details here yet before
I can understand what these CPUs are really in the system and why we need
this.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 2/5] firmware: arm_scmi: imx: Add i.MX95 CPU Protocol
2025-01-22 8:48 ` Dan Carpenter
@ 2025-01-22 12:22 ` Cristian Marussi
2025-01-22 12:41 ` Dan Carpenter
0 siblings, 1 reply; 23+ messages in thread
From: Cristian Marussi @ 2025-01-22 12:22 UTC (permalink / raw)
To: Dan Carpenter
Cc: Peng Fan (OSS), Sudeep Holla, Cristian Marussi, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
linux-kernel, arm-scmi, linux-arm-kernel, imx, Peng Fan
On Wed, Jan 22, 2025 at 11:48:52AM +0300, Dan Carpenter wrote:
> On Tue, Jan 21, 2025 at 11:08:12PM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > This protocol allows an agent to start, stop a CPU or set reset vector. It
> > is used to manage auxiliary CPUs in an LM (e.g. additional cores in an AP
> > cluster).
> >
Hi,
just a quick one down below.
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> > drivers/firmware/arm_scmi/vendors/imx/Kconfig | 13 +-
> > drivers/firmware/arm_scmi/vendors/imx/Makefile | 1 +
> > drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c | 283 +++++++++++++++++++++
> > include/linux/scmi_imx_protocol.h | 10 +
> > 4 files changed, 306 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/firmware/arm_scmi/vendors/imx/Kconfig b/drivers/firmware/arm_scmi/vendors/imx/Kconfig
> > index 1a936fc87d2350e2a21bccd45dfbeebfa3b90286..9070522510e4d3f3d7276a7581f8676006d20f90 100644
> > --- a/drivers/firmware/arm_scmi/vendors/imx/Kconfig
> > +++ b/drivers/firmware/arm_scmi/vendors/imx/Kconfig
> > @@ -12,6 +12,17 @@ config IMX_SCMI_BBM_EXT
> > To compile this driver as a module, choose M here: the
> > module will be called imx-sm-bbm.
> >
> > +config IMX_SCMI_CPU_EXT
> > + tristate "i.MX SCMI CPU EXTENSION"
> > + depends on ARM_SCMI_PROTOCOL || (COMPILE_TEST && OF)
> > + default y if ARCH_MXC
> > + help
> > + This enables i.MX System CPU Protocol to manage cpu
> > + start, stop and etc.
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called imx-sm-cpu.
> > +
> > config IMX_SCMI_LMM_EXT
> > tristate "i.MX SCMI LMM EXTENSION"
> > depends on ARM_SCMI_PROTOCOL || (COMPILE_TEST && OF)
> > @@ -21,7 +32,7 @@ config IMX_SCMI_LMM_EXT
> > manage Logical Machines boot, shutdown and etc.
> >
> > To compile this driver as a module, choose M here: the
> > - module will be called imx-sm-lmm.
> > + module will be called imx-sm-cpu.
> >
>
> It's supposed to be called imx-sm-lmm.
>
> > config IMX_SCMI_MISC_EXT
> > tristate "i.MX SCMI MISC EXTENSION"
> > diff --git a/drivers/firmware/arm_scmi/vendors/imx/Makefile b/drivers/firmware/arm_scmi/vendors/imx/Makefile
> > index f39a99ccaf9af757475e8b112d224669444d7ddc..e3a5ea46345c89da1afae25e55698044672b7c28 100644
> > --- a/drivers/firmware/arm_scmi/vendors/imx/Makefile
> > +++ b/drivers/firmware/arm_scmi/vendors/imx/Makefile
> > @@ -1,4 +1,5 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> > obj-$(CONFIG_IMX_SCMI_BBM_EXT) += imx-sm-bbm.o
> > +obj-$(CONFIG_IMX_SCMI_CPU_EXT) += imx-sm-cpu.o
> > obj-$(CONFIG_IMX_SCMI_LMM_EXT) += imx-sm-lmm.o
> > obj-$(CONFIG_IMX_SCMI_MISC_EXT) += imx-sm-misc.o
> > diff --git a/drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c
> > new file mode 100644
> > index 0000000000000000000000000000000000000000..e3f294c2cb69a5b5a916d55984f4a63539937d02
> > --- /dev/null
> > +++ b/drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c
> > @@ -0,0 +1,283 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * System control and Management Interface (SCMI) NXP CPU Protocol
> > + *
> > + * Copyright 2025 NXP
> > + */
> > +
> > +#include <linux/bits.h>
> > +#include <linux/io.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/scmi_protocol.h>
> > +#include <linux/scmi_imx_protocol.h>
> > +
> > +#include "../../protocols.h"
> > +#include "../../notify.h"
> > +
> > +#define SCMI_PROTOCOL_SUPPORTED_VERSION 0x10000
> > +
> > +enum scmi_imx_cpu_protocol_cmd {
> > + SCMI_IMX_CPU_ATTRIBUTES = 0x3,
> > + SCMI_IMX_CPU_START = 0x4,
> > + SCMI_IMX_CPU_STOP = 0x5,
> > + SCMI_IMX_CPU_RESET_VECTOR_SET = 0x6,
> > + SCMI_IMX_CPU_INFO_GET = 0xC,
> > +};
> > +
> > +struct scmi_imx_cpu_info {
> > + u32 nr_cpu;
> > +};
> > +
> > +#define SCMI_IMX_CPU_PROTO_ATTR_NUM_CPUS(x) ((x) & 0xFFFF)
> > +struct scmi_msg_imx_cpu_protocol_attributes {
> > + __le32 attributes;
> > +};
> > +
> > +struct scmi_msg_imx_cpu_attributes_out {
> > + __le32 attributes;
> > +#define CPU_MAX_NAME 16
> > + u8 name[CPU_MAX_NAME];
>
> char is always unsigned in the kernel these days but strings should
> still always be char. Same thing in patch 1, there were a couple u8
> names.
>
While it is certainly true that char is the way to go for strings and, as
such, it is used elsewhere to hold the resource names across all SCMI
protocols, in this context it is a field of structure representing
exactly the layout of message reply coming from the server, and defined
in the SCMI spec as a uint8 array, so, we have generally preferred to
used u8 to represent such fixed size array all across the SCMI stack
protocols implementation....
.... not saying that it is necessarily completelt right, but that is the
reason we are guilty :D
Thanks,
Cristian
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 2/5] firmware: arm_scmi: imx: Add i.MX95 CPU Protocol
2025-01-22 12:22 ` Cristian Marussi
@ 2025-01-22 12:41 ` Dan Carpenter
2025-01-22 12:55 ` Cristian Marussi
2025-01-22 13:59 ` Sudeep Holla
0 siblings, 2 replies; 23+ messages in thread
From: Dan Carpenter @ 2025-01-22 12:41 UTC (permalink / raw)
To: Cristian Marussi
Cc: Peng Fan (OSS), Sudeep Holla, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-kernel, arm-scmi,
linux-arm-kernel, imx, Peng Fan
On Wed, Jan 22, 2025 at 12:22:18PM +0000, Cristian Marussi wrote:
> > > +struct scmi_msg_imx_cpu_attributes_out {
> > > + __le32 attributes;
> > > +#define CPU_MAX_NAME 16
> > > + u8 name[CPU_MAX_NAME];
> >
> > char is always unsigned in the kernel these days but strings should
> > still always be char. Same thing in patch 1, there were a couple u8
> > names.
> >
>
> While it is certainly true that char is the way to go for strings and, as
> such, it is used elsewhere to hold the resource names across all SCMI
> protocols, in this context it is a field of structure representing
> exactly the layout of message reply coming from the server, and defined
> in the SCMI spec as a uint8 array, so, we have generally preferred to
> used u8 to represent such fixed size array all across the SCMI stack
> protocols implementation....
>
> .... not saying that it is necessarily completelt right, but that is the
> reason we are guilty :D
Fine. I don't have intense emotions about this.
It does slightly bother me when we assume that the SCMI server NUL
terminates these when we do things like:
dev_info(ph->dev, "i.MX CPU: name: %s\n", out->name);
But from a practical perspective we have to trust the SCMI server.
regards,
dan carpenter
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 2/5] firmware: arm_scmi: imx: Add i.MX95 CPU Protocol
2025-01-22 12:41 ` Dan Carpenter
@ 2025-01-22 12:55 ` Cristian Marussi
2025-01-22 13:59 ` Sudeep Holla
1 sibling, 0 replies; 23+ messages in thread
From: Cristian Marussi @ 2025-01-22 12:55 UTC (permalink / raw)
To: Dan Carpenter
Cc: Cristian Marussi, Peng Fan (OSS), Sudeep Holla, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
linux-kernel, arm-scmi, linux-arm-kernel, imx, Peng Fan
On Wed, Jan 22, 2025 at 03:41:41PM +0300, Dan Carpenter wrote:
> On Wed, Jan 22, 2025 at 12:22:18PM +0000, Cristian Marussi wrote:
> > > > +struct scmi_msg_imx_cpu_attributes_out {
> > > > + __le32 attributes;
> > > > +#define CPU_MAX_NAME 16
> > > > + u8 name[CPU_MAX_NAME];
> > >
> > > char is always unsigned in the kernel these days but strings should
> > > still always be char. Same thing in patch 1, there were a couple u8
> > > names.
> > >
> >
Hi Dan,
> > While it is certainly true that char is the way to go for strings and, as
> > such, it is used elsewhere to hold the resource names across all SCMI
> > protocols, in this context it is a field of structure representing
> > exactly the layout of message reply coming from the server, and defined
> > in the SCMI spec as a uint8 array, so, we have generally preferred to
> > used u8 to represent such fixed size array all across the SCMI stack
> > protocols implementation....
> >
> > .... not saying that it is necessarily completelt right, but that is the
> > reason we are guilty :D
>
> Fine. I don't have intense emotions about this.
>
> It does slightly bother me when we assume that the SCMI server NUL
> terminates these when we do things like:
>
> dev_info(ph->dev, "i.MX CPU: name: %s\n", out->name);
>
Hang on...I have not really done a proper review still on this series...
...and this printout above straight out of the message payload seems very
wrong to me too..
> But from a practical perspective we have to trust the SCMI server.
>
....nope we should NEVER trust the server...and instead assume it can
kill us (kernel) all the time :P
...despite what the spec says, we tend to assume tha the server can be
maliciously wrong (or just crappy), so in other protocols where we do used
an u8[] to describe the resource name field in a message, we have also always
(hopefully :D) taken care to use it ONLY after having processed that field like...
strscpy(dom_info->name, attr->name, SCMI_SHORT_NAME_MAX_SIZE);
...to remove any possible bad outcome from a misbehaving SCMI fw server.
Thanks,
Cristian
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 2/5] firmware: arm_scmi: imx: Add i.MX95 CPU Protocol
2025-01-22 12:41 ` Dan Carpenter
2025-01-22 12:55 ` Cristian Marussi
@ 2025-01-22 13:59 ` Sudeep Holla
1 sibling, 0 replies; 23+ messages in thread
From: Sudeep Holla @ 2025-01-22 13:59 UTC (permalink / raw)
To: Dan Carpenter
Cc: Cristian Marussi, Sudeep Holla, Peng Fan (OSS), Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
linux-kernel, arm-scmi, linux-arm-kernel, imx, Peng Fan
On Wed, Jan 22, 2025 at 03:41:41PM +0300, Dan Carpenter wrote:
> On Wed, Jan 22, 2025 at 12:22:18PM +0000, Cristian Marussi wrote:
> > > > +struct scmi_msg_imx_cpu_attributes_out {
> > > > + __le32 attributes;
> > > > +#define CPU_MAX_NAME 16
> > > > + u8 name[CPU_MAX_NAME];
> > >
> > > char is always unsigned in the kernel these days but strings should
> > > still always be char. Same thing in patch 1, there were a couple u8
> > > names.
> > >
> >
> > While it is certainly true that char is the way to go for strings and, as
> > such, it is used elsewhere to hold the resource names across all SCMI
> > protocols, in this context it is a field of structure representing
> > exactly the layout of message reply coming from the server, and defined
> > in the SCMI spec as a uint8 array, so, we have generally preferred to
> > used u8 to represent such fixed size array all across the SCMI stack
> > protocols implementation....
> >
> > .... not saying that it is necessarily completelt right, but that is the
> > reason we are guilty :D
>
> Fine. I don't have intense emotions about this.
>
> It does slightly bother me when we assume that the SCMI server NUL
> terminates these when we do things like:
>
> dev_info(ph->dev, "i.MX CPU: name: %s\n", out->name);
>
I was about to reply earlier and got distracted. This makes it even better.
I agree with Cristian that we have defined it as u8 when referring to the
payload from the SCMI platform/server. But it should be used only to extract
information from the response payload and copied to OSPM's own buffer before
accessing it like the above dev_info example.
In short, I agree with you Dan that it shouldn't be used in OS like above.
I haven't looked at the implementation patches(just looked at the doc 3/5),
but if they need such logging, they need to copy it to some buffer in the
kernel.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: [PATCH 3/5] firmware: arm_scmi: imx: Add LMM and CPU documentation
2025-01-22 12:14 ` Sudeep Holla
@ 2025-01-23 1:30 ` Peng Fan
2025-02-25 10:21 ` Sudeep Holla
0 siblings, 1 reply; 23+ messages in thread
From: Peng Fan @ 2025-01-23 1:30 UTC (permalink / raw)
To: Sudeep Holla, Peng Fan (OSS), Chuck Cannon
Cc: Cristian Marussi, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
linux-kernel@vger.kernel.org, arm-scmi@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
Hi Sudeep,
> Subject: Re: [PATCH 3/5] firmware: arm_scmi: imx: Add LMM and CPU
> documentation
>
> On Tue, Jan 21, 2025 at 11:08:13PM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > Add i.MX95 Logical Machine Management and CPU Protocol
> documentation.
> >
>
> Please make this the first patch when you need to respin this(which is
> clearly not yet 😁)
Sure.
>
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> > drivers/firmware/arm_scmi/vendors/imx/imx95.rst | 692
> > ++++++++++++++++++++++++
> > 1 file changed, 692 insertions(+)
> >
> > diff --git a/drivers/firmware/arm_scmi/vendors/imx/imx95.rst
> > b/drivers/firmware/arm_scmi/vendors/imx/imx95.rst
> > index
> >
> b2dfd6c46ca2f5f12f0475c24cb54c060e9fa421..384d4f9c27e489a9c5
> 4cdde79c9f
> > 03a6f5979630 100644
> > --- a/drivers/firmware/arm_scmi/vendors/imx/imx95.rst
> > +++ b/drivers/firmware/arm_scmi/vendors/imx/imx95.rst
> > @@ -32,6 +32,419 @@ port, and deploy the SM on supported
> processors.
> > The SM implements an interface compliant with the Arm SCMI
> > Specification with additional vendor specific extensions.
> >
> > +SCMI_LMM: System Control and Management Logical Machine
> Management
> > +Vendor Protocol
> >
> +===========================================================
> ==========
> > +=============
> > +
> > +This protocol is intended for boot, shutdown, and reset of other
> > +logical machines (LM). It is usually used to allow one LM to manager
> > +another used as an offload or accelerator engine.
>
> The above statement is very hard to parse. Can it be "
> It is usually used to allow one LM(e.g. OSPM) to manage another LM
> which is usually an offload or accelerator engine.
> "
> if I understood it correctly ?
Correct. I will update.
>
> > Notifications from this protocol can
> > +also be used to manage a communication link to another LM. The
> LMM
> > +protocol provides functions to:
> > +
> > +- Describe the protocol version.
> > +- Discover implementation attributes.
> > +- Discover the LMs defined in the system.
> > +- Boot an LM.
> > +- Shut down an LM.
> > +- Reset an LM.
> > +- Wake an LM from suspend.
> > +- Suspend an LM (gracefully).
> > +- Request a graceful shutdown or reset of an LM.
>
> Does that mean above "Shut down an LM" and "Reset an LM" are
> forced ones ?
No. Both supports graceful feature.
Forced ones means the System Manager will force shutdown or reset a
LM.
Graceful ones means System Manager will send notification to one LM,
the LM will shutdown or reset itself.
>
> > +- Allow an agent to forcibly power down or reset an LM.
>
> How is this different from the above ?
The above says gracefully shutdown or reset.
Here says forcibly.
Say above about gracefully and forcibly.
>
> > +- Read boot/shutdown/reset information for an LM.
> > +- Get notifications when an LM boots or shuts down.
> > +
> > +Commands:
> > +_________
> > +
> > +PROTOCOL_VERSION
> > +~~~~~~~~~~~~~~~~
> > +
> > +message_id: 0x0
> > +protocol_id: 0x80
> > +
> > ++---------------+--------------------------------------------------------------+
> > +|Return values |
> > ++---------------+--------------------------------------------------------------+
> > +|Name |Description |
> > ++---------------+--------------------------------------------------------------+
> > +|int32 status | See ARM SCMI Specification for status code
> definitions. |
> > ++---------------+--------------------------------------------------------------+
> > +|uint32 version | For this revision of the specification, this value
> must be |
> > +| | 0x10000. |
> > ++---------------+--------------------------------------------------------------+
> > +
> > +PROTOCOL_ATTRIBUTES
> > +~~~~~~~~~~~~~~~~~~~
> > +
> > +message_id: 0x1
> > +protocol_id: 0x80
> > +
> > ++------------------+-----------------------------------------------------------+
> > +|Return values |
> > ++------------------+-----------------------------------------------------------+
> > +|Name |Description |
> > ++------------------+-----------------------------------------------------------+
> > +|int32 status | See ARM SCMI Specification for status code
> definitions. |
> > ++------------------+-----------------------------------------------------------+
> > +|uint32 attributes |Protocol attributes: |
> > +| |Bits[31:8] Reserved, must be zero. |
> > +| |Bits[7:0] Number of Logical Machines |
> > ++------------------+-----------------------------------------------------------+
> > +
> > +PROTOCOL_MESSAGE_ATTRIBUTES
> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +message_id: 0x2
> > +protocol_id: 0x80
> > +
> > ++------------------+-----------------------------------------------------------+
> > +|Return values |
> > ++------------------+-----------------------------------------------------------+
> > +|Name |Description |
> > ++------------------+-----------------------------------------------------------+
> > +|int32 status |SUCCESS: in case the message is implemented and
> available |
> > +| |to use. |
> > +| |NOT_FOUND: if the message identified by message_id
> is |
> > +| |invalid or not implemented |
> > ++------------------+-----------------------------------------------------------+
> > +|uint32 attributes |Flags that are associated with a specific function
> in the |
> > +| |protocol. For all functions in this protocol, this |
> > +| |parameter has a value of 0 |
> > ++------------------+-----------------------------------------------------------+
> > +
> > +LMM_ATTRIBUTES
> > +~~~~~~~~~~~~~~
> > +
> > +message_id: 0x3
> > +protocol_id: 0x80
> > +
> > ++------------------+-----------------------------------------------------------+
> > +|Parameters |
> > ++------------------+-----------------------------------------------------------+
> > +|Name |Description |
> > ++------------------+-----------------------------------------------------------+
> > +|uint32 lmid |ID of the Logical Machine |
> > ++------------------+-----------------------------------------------------------+
> > +|Return values |
> > ++------------------+-----------------------------------------------------------+
> > +|Name |Description |
> > ++------------------+-----------------------------------------------------------+
>
> Where are the actual attributes returned ?
Oh. This was missed. It will return the LM state, name, errstate.
>
> > +|int32 status |SUCCESS: if valid attributes are returned.
> |
> > +| |NOT_FOUND: if lmId not points to a valid logical
> machine. |
> > +| |DENIED: if the agent does not have permission to get
> info |
> > +| |for the LM specified by lmid. |
> > ++------------------+-----------------------------------------------------------+
> > +
> > +LMM_BOOT
> > +~~~~~~~~
> > +
> > +message_id: 0x4
> > +protocol_id: 0x80
> > +
> > ++------------------+-----------------------------------------------------------+
> > +|Parameters |
> > ++------------------+-----------------------------------------------------------+
> > +|Name |Description |
> > ++------------------+-----------------------------------------------------------+
> > +|uint32 lmid |ID of the Logical Machine |
> > ++------------------+-----------------------------------------------------------+
> > +|Return values |
> > ++------------------+-----------------------------------------------------------+
> > +|Name |Description |
> > ++------------------+-----------------------------------------------------------+
> > +|int32 status |SUCCESS: if LM successfully booted.
> |
> > +| |NOT_FOUND: if lmId not points to a valid logical
> machine. |
> > +| |INVALID_PARAMETERS: if lmId is same as the caller.
> |
> > +| |DENIED: if the agent does not have permission to
> manage the|
> > +| |the LM specified by lmid. |
> > ++------------------+-----------------------------------------------------------+
> > +
>
> Is this synchronous boot ? When will the notifications be used then ?
Yes. Sync boot. After the System Manager boots the LM, the System
Manager will send notification to subscribers.
>
> > +LMM_RESET
> > +~~~~~~~~~
> > +
> > +message_id: 0x5
> > +protocol_id: 0x80
> > +
> > ++------------------+-----------------------------------------------------------+
> > +|Parameters |
> > ++------------------+-----------------------------------------------------------+
> > +|Name |Description |
> > ++------------------+-----------------------------------------------------------+
> > +|uint32 lmid |ID of the Logical Machine |
> > ++------------------+-----------------------------------------------------------+
> > +|uint32 flags |Reset flags: |
> > +| |Bits[31:1] Reserved, must be zero. |
> > +| |Bit[0] Graceful request: |
> > +| |Set to 1 if the request is a graceful request. |
> > +| |Set to 0 if the request is a forceful request. |
>
>
> Ah so you have flag here then. I wonder why you need separate
> command then ?
Sorry. I not follow you here.
LMM_Shutdown/LMM_Reset/LMM_DoBoot are the commands
to shutdown/reset/boot one LM.
>
> > ++------------------+-----------------------------------------------------------+
> > +|Return values |
> > ++------------------+-----------------------------------------------------------+
> > +|Name |Description |
> > ++------------------+-----------------------------------------------------------+
> > +|int32 status |SUCCESS: if LM successfully resets. |
> > +| |NOT_FOUND: if lmId not points to a valid logical
> machine. |
> > +| |INVALID_PARAMETERS: if lmId is same as the caller.
> |
> > +| |DENIED: if the agent does not have permission to
> manage the|
> > +| |the LM specified by lmid. |
> > ++------------------+-----------------------------------------------------------+
> > +
>
> Again, is this done synchronously ?
If flag is set graceful, the LM will reset itself, so sync reset from
LM view.
If flag is forced ones, the LM will be forced reset, so async reset
from LM view.
>
> > +LMM_SHUTDOWN
> > +~~~~~~~~~~~~
> > +
> > +message_id: 0x6
> > +protocol_id: 0x80
> > +
> > ++------------------+-----------------------------------------------------------+
> > +|Parameters |
> > ++------------------+-----------------------------------------------------------+
> > +|Name |Description |
> > ++------------------+-----------------------------------------------------------+
> > +|uint32 lmid |ID of the Logical Machine |
> > ++------------------+-----------------------------------------------------------+
> > +|uint32 flags |Reset flags: |
> > +| |Bits[31:1] Reserved, must be zero. |
> > +| |Bit[0] Graceful request: |
> > +| |Set to 1 if the request is a graceful request. |
> > +| |Set to 0 if the request is a forceful request. |
> > ++------------------+-----------------------------------------------------------+
> > +|Return values |
> > ++------------------+-----------------------------------------------------------+
> > +|Name |Description |
> > ++------------------+-----------------------------------------------------------+
> > +|int32 status |SUCCESS: if LM successfully shutdowns.
> |
> > +| |NOT_FOUND: if lmId not points to a valid logical
> machine. |
> > +| |INVALID_PARAMETERS: if lmId is same as the caller.
> |
> > +| |DENIED: if the agent does not have permission to
> manage the|
> > +| |the LM specified by lmid. |
> > ++------------------+-----------------------------------------------------------+
> > +
>
> Ditto, sync ?
Same as above LMM_Reset.
>
> > +LMM_WAKE
> > +~~~~~~~~
> > +
> > +message_id: 0x7
> > +protocol_id: 0x80
> > +
> > ++------------------+-----------------------------------------------------------+
> > +|Parameters |
> > ++------------------+-----------------------------------------------------------+
> > +|Name |Description |
> > ++------------------+-----------------------------------------------------------+
> > +|uint32 lmid |ID of the Logical Machine |
> > ++------------------+-----------------------------------------------------------+
> > +|Return values |
> > ++------------------+-----------------------------------------------------------+
> > +|Name |Description |
> > ++------------------+-----------------------------------------------------------+
> > +|int32 status |SUCCESS: if LM successfully wakes. |
> > +| |NOT_FOUND: if lmId not points to a valid logical
> machine. |
> > +| |INVALID_PARAMETERS: if lmId is same as the caller.
> |
> > +| |DENIED: if the agent does not have permission to
> manage the|
> > +| |the LM specified by lmid. |
> > ++------------------+-----------------------------------------------------------+
> > +
>
> Ditto, sync ?
This is sync. Saying LM is in suspend state, one LM could wake other
LM if permission allowed.
>
> > +LMM_SUSPEND
> > +~~~~~~~~~~~
> > +
> > +message_id: 0x8
> > +protocol_id: 0x80
> > +
> > ++------------------+-----------------------------------------------------------+
> > +|Parameters |
> > ++------------------+-----------------------------------------------------------+
> > +|Name |Description |
> > ++------------------+-----------------------------------------------------------+
> > +|uint32 lmid |ID of the Logical Machine |
> > ++------------------+-----------------------------------------------------------+
> > +|Return values |
> > ++------------------+-----------------------------------------------------------+
> > +|Name |Description |
> > ++------------------+-----------------------------------------------------------+
> > +|int32 status |SUCCESS: if LM successfully suspends.
> |
> > +| |NOT_FOUND: if lmId not points to a valid logical
> machine. |
> > +| |INVALID_PARAMETERS: if lmId is same as the caller.
> |
> > +| |DENIED: if the agent does not have permission to
> manage the|
> > +| |the LM specified by lmid. |
> > ++------------------+-----------------------------------------------------------+
> > +
>
> Ditto, sync ?
Yes. Sync. The LM need suspend itself, SM will send notification to LM.
>
> > +LMM_NOTIFY
> > +~~~~~~~~~~
> > +
> > +message_id: 0x9
> > +protocol_id: 0x80
> > +
> > ++------------------+-----------------------------------------------------------+
> > +|Parameters |
> > ++------------------+-----------------------------------------------------------+
> > +|Name |Description |
> > ++------------------+-----------------------------------------------------------+
> > +|uint32 lmid |ID of the Logical Machine |
> > ++------------------+-----------------------------------------------------------+
> > +|uint32 flags |Notification flags: |
> > +| |Bits[31:3] Reserved, must be zero. |
> > +| |Bit[3] Wake (resume) notification: |
> > +| |Set to 1 to send notification. |
> > +| |Set to 0 if no notification. |
> > +| |Bit[2] Suspend (sleep) notification: |
> > +| |Set to 1 to send notification. |
> > +| |Set to 0 if no notification. |
> > +| |Bit[1] Shutdown (off) notification: |
> > +| |Set to 1 to send notification. |
> > +| |Set to 0 if no notification. |
> > +| |Bit[0] Boot (on) notification: |
> > +| |Set to 1 to send notification. |
> > +| |Set to 0 if no notification |
>
> How about reset ?
The LMM will also send System power management notification.
Reset will use it.
>
> > ++------------------+-----------------------------------------------------------+
> > +|Return values |
> > ++------------------+-----------------------------------------------------------+
> > +|Name |Description |
> > ++------------------+-----------------------------------------------------------+
> > +|int32 status |SUCCESS: if the notification state successfully
> updated. |
> > +| |NOT_FOUND: if lmId not points to a valid logical
> machine. |
> > +| |INVALID_PARAMETERS: if input attributes flag specifies
> |
> > +| |unsupported or invalid configurations. |
> > +| |DENIED: if the agent does not have permission to
> request |
> > +| |the notification. |
> > ++------------------+-----------------------------------------------------------+
> > +
> > +LMM_RESET_REASON
> > +~~~~~~~~~~~~~~~~
> > +
> > +message_id: 0xA
> > +protocol_id: 0x80
> > +
> > ++---------------------+--------------------------------------------------------+
> > +|Parameters |
> > ++---------------------+--------------------------------------------------------+
> > +|Name |Description |
> > ++---------------------+--------------------------------------------------------+
> > +|uint32 lmid |ID of the Logical Machine |
> > ++---------------------+--------------------------------------------------------+
> > +|Return values |
> > ++---------------------+--------------------------------------------------------+
> > +|Name |Description |
> > ++---------------------+--------------------------------------------------------+
> > +|int32 status |SUCCESS: if LM successfully suspends.
> |
> > +| |NOT_FOUND: if lmId not points to a valid logical
> machine|
> > +| |DENIED: if the agent does not have permission to
> request|
> > +| |the reset reason. |
> > ++---------------------+--------------------------------------------------------+
> > +|uint32 bootflags |Boot reason flags. This parameter has the
> format: |
> > +| |Bits[31] Valid. |
> > +| |Set to 1 if the entire reason is valid. |
> > +| |Set to 0 if the entire reason is not valid. |
> > +| |Bits[30:29] Reserved, must be zero. |
> > +| |Bit[28] Valid origin: |
>
> Valid with origin ID perhaps ?
No. This is from SM Doc, it is valid origin, saying valid source.
>
> > +| |Set to 1 if the origin field is valid. |
> > +| |Set to 0 if the origin field is not valid. |
> > +| |Bits[27:24] Origin. |
> > +| |Bit[23] Valid err ID: |
> > +| |Set to 1 if the error ID field is valid. |
> > +| |Set to 0 if the error ID field is not valid. |
> > +| |Bits[22:8] Error ID. |
> > +| |Bit[7:0] Reason |
>
> Reasons definitions are Platform specific ?
Yes. This info is from SOC system reset controller, such as WDOG,
JTAG, POR and etc.
>
> > ++---------------------+--------------------------------------------------------+
> > +|uint32 shutdownflags |Shutdown reason flags. This parameter has
> the format: |
> > +| |Bits[31] Valid. |
> > +| |Set to 1 if the entire reason is valid. |
> > +| |Set to 0 if the entire reason is not valid. |
> > +| |Bits[30:29] Number of valid extended info words.
> |
> > +| |Bit[28] Valid origin: |
> > +| |Set to 1 if the origin field is valid. |
> > +| |Set to 0 if the origin field is not valid. |
> > +| |Bits[27:24] Origin. |
> > +| |Bit[23] Valid err ID: |
> > +| |Set to 1 if the error ID field is valid. |
> > +| |Set to 0 if the error ID field is not valid. |
> > +| |Bits[22:8] Error ID. |
> > +| |Bit[7:0] Reason |
>
> Again nothing for reset ? Do you expect reset to be forceful shutdown
> and boot in which case both the above are set ?
The reset implementation is actually first shutdown, then boot.
I loop our System Manager Owner to help answer. In case My answer is
not correct.
>
> > ++---------------------+--------------------------------------------------------+
> > +|uint32 extinfo[0,20] |Array of extended info words
> |
>
> What are these ?
It depends, such as pmic fault flags, fault pc.
>
> > ++---------------------+--------------------------------------------------------+
> > +
> > +LMM_POWER_ON
> > +~~~~~~~~~~~~
> > +
> > +message_id: 0xB
> > +protocol_id: 0x80
> > +
> > ++------------------+-----------------------------------------------------------+
> > +|Parameters |
> > ++------------------+-----------------------------------------------------------+
> > +|Name |Description |
> > ++------------------+-----------------------------------------------------------+
> > +|uint32 lmid |ID of the Logical Machine |
> > ++------------------+-----------------------------------------------------------+
> > +|Return values |
> > ++------------------+-----------------------------------------------------------+
> > +|Name |Description |
> > ++------------------+-----------------------------------------------------------+
> > +|int32 status |SUCCESS: if LM successfully suspends.
> |
>
> /me confused. Is it suspend(which is already defined) ? Or reset(again
> already
> defined) ?
Sorry. This should be power on.
>
> > +| |NOT_FOUND: if lmId not points to a valid logical
> machine. |
> > +| |INVALID_PARAMETERS: if lmId is same as the caller.
> |
> > +| |DENIED: if the agent does not have permission to
> manage the|
> > +| |the LM specified by lmid. |
> > ++------------------+-----------------------------------------------------------+
> > +
> > +NEGOTIATE_PROTOCOL_VERSION
> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +message_id: 0x10
> > +protocol_id: 0x80
> > +
> > ++--------------------+---------------------------------------------------------+
> > +|Parameters |
> > ++--------------------+---------------------------------------------------------+
> > +|Name |Description |
> > ++--------------------+---------------------------------------------------------+
> > +|uint32 version |The negotiated protocol version the agent
> intends to use |
> > ++--------------------+---------------------------------------------------------+
> > +|Return values |
> > ++--------------------+---------------------------------------------------------+
> > +|Name |Description |
> > ++--------------------+---------------------------------------------------------+
> > +|int32 status |SUCCESS: if the negotiated protocol version is
> supported |
> > +| |by the platform. All commands, responses, and
> |
> > +| |notifications post successful return of this command
> must|
> > +| |comply with the negotiated version. |
> > +| |NOT_SUPPORTED: if the protocol version is not
> > +|supported. |
> > ++--------------------+---------------------------------------------------------+
> > +
> > +Notifications
> > +_____________
> > +
> > +LMM_EVENT
> > +~~~~~~~~~
> > +
> > +message_id: 0x0
> > +protocol_id: 0x80
> > +
> > ++------------------+-----------------------------------------------------------+
> > +|Parameters |
> > ++------------------+-----------------------------------------------------------+
> > +|Name |Description |
> > ++------------------+-----------------------------------------------------------+
> > +|uint32 lmid |Identifier for the LM that caused the transition.
> |
> > ++------------------+-----------------------------------------------------------+
> > +|uint32 eventlm |Identifier for the LM the event is for.
> |
> > ++------------------+-----------------------------------------------------------+
> > +|uint32 flags |LM events: |
> > +| |Bits[31:3] Reserved, must be zero. |
> > +| |Bit[3] Wake (resume) event: |
> > +| |1 LM has awakened. |
> > +| |0 not a wake event. |
> > +| |Bit[2] Suspend (sleep) event: |
> > +| |1 LM has suspended. |
> > +| |0 not a suspend event. |
> > +| |Bit[1] Shutdown (off) event: |
> > +| |1 LM has shutdown. |
> > +| |0 not a shutdown event. |
> > +| |Bit[0] Boot (on) event: |
> > +| |1 LM has booted. |
> > +| |0 not a boot event. |
> > ++------------------+-----------------------------------------------------------+
> > +
> > SCMI_BBM: System Control and Management BBM Vendor Protocol
> >
> ============================================================
> ==
> >
> > @@ -436,6 +849,285 @@ protocol_id: 0x81
> > | |0 no button change detected. |
> >
> > +------------------+--------------------------------------------------
> > ---------+
> >
> > +SCMI_CPU: System Control and Management CPU Vendor Protocol
> >
> +===========================================================
> ===
> > +
> > +This protocol allows an agent to start or stop a CPU. It is used to
> > +manage auxiliary CPUs in an LM (e.g. additional cores in an AP
> > +cluster), The CPU protocol provides functions to:
> > +
>
> Additional CPU in AP cluster ? That sounds alarming. Why not use PSCI ?
This is to manage the M7 core by Linux. I just put more documentation here.
CPU protocol is also used by ATF to manage AP cores.
> Also what other CPUs are we talking here.
M7 core
In general I would like to
> explore the possibility of collapsing this with LM protocol. CPUs within
> LM is LM's responsibility to bring up. And CPU can be seen as an LM for
> sake of this vendor protocol. I am not get into details here yet before I
> can understand what these CPUs are really in the system and why we
> need this.
Our system supports M7 and A55 in one LM, so A55 use CPU protocol to
manage M7. When M7 and A55 in different LM, use LM protocol to
manage M7 LM.
Thanks,
Peng.
>
> --
> Regards,
> Sudeep
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 1/5] firmware: arm_scmi: imx: Add i.MX95 LMM protocol
2025-01-21 15:08 ` [PATCH 1/5] firmware: arm_scmi: imx: Add i.MX95 LMM protocol Peng Fan (OSS)
@ 2025-01-24 2:43 ` kernel test robot
0 siblings, 0 replies; 23+ messages in thread
From: kernel test robot @ 2025-01-24 2:43 UTC (permalink / raw)
To: Peng Fan (OSS), Sudeep Holla, Cristian Marussi, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: oe-kbuild-all, linux-kernel, arm-scmi, linux-arm-kernel, imx,
Peng Fan
Hi Peng,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 0907e7fb35756464aa34c35d6abb02998418164b]
url: https://github.com/intel-lab-lkp/linux/commits/Peng-Fan-OSS/firmware-arm_scmi-imx-Add-i-MX95-LMM-protocol/20250121-231254
base: 0907e7fb35756464aa34c35d6abb02998418164b
patch link: https://lore.kernel.org/r/20250121-imx-lmm-cpu-v1-1-0eab7e073e4e%40nxp.com
patch subject: [PATCH 1/5] firmware: arm_scmi: imx: Add i.MX95 LMM protocol
config: arm64-randconfig-r122-20250124 (https://download.01.org/0day-ci/archive/20250124/202501241025.6reKesXZ-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 14.2.0
reproduce: (https://download.01.org/0day-ci/archive/20250124/202501241025.6reKesXZ-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202501241025.6reKesXZ-lkp@intel.com/
sparse warnings: (new ones prefixed by >>)
>> drivers/firmware/arm_scmi/vendors/imx/imx-sm-lmm.c:189:32: sparse: sparse: restricted __le32 degrades to integer
vim +189 drivers/firmware/arm_scmi/vendors/imx/imx-sm-lmm.c
172
173 static int scmi_imx_lmm_protocol_attributes_get(const struct scmi_protocol_handle *ph,
174 struct scmi_imx_lmm_priv *priv)
175 {
176 struct scmi_msg_imx_lmm_protocol_attributes *attr;
177 struct scmi_xfer *t;
178 int ret;
179
180 ret = ph->xops->xfer_get_init(ph, PROTOCOL_ATTRIBUTES, 0,
181 sizeof(*attr), &t);
182 if (ret)
183 return ret;
184
185 attr = t->rx.buf;
186
187 ret = ph->xops->do_xfer(ph, t);
188 if (!ret) {
> 189 priv->nr_lmm = SCMI_IMX_LMM_PROTO_ATTR_NUM_LM(attr->attributes);
190 dev_info(ph->dev, "i.MX LMM: %d Logical Machines\n",
191 priv->nr_lmm);
192 }
193
194 ph->xops->xfer_put(ph, t);
195
196 return ret;
197 }
198
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 2/5] firmware: arm_scmi: imx: Add i.MX95 CPU Protocol
2025-01-21 15:08 ` [PATCH 2/5] firmware: arm_scmi: imx: Add i.MX95 CPU Protocol Peng Fan (OSS)
2025-01-22 8:48 ` Dan Carpenter
@ 2025-01-24 4:11 ` kernel test robot
1 sibling, 0 replies; 23+ messages in thread
From: kernel test robot @ 2025-01-24 4:11 UTC (permalink / raw)
To: Peng Fan (OSS), Sudeep Holla, Cristian Marussi, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: oe-kbuild-all, linux-kernel, arm-scmi, linux-arm-kernel, imx,
Peng Fan
Hi Peng,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 0907e7fb35756464aa34c35d6abb02998418164b]
url: https://github.com/intel-lab-lkp/linux/commits/Peng-Fan-OSS/firmware-arm_scmi-imx-Add-i-MX95-LMM-protocol/20250121-231254
base: 0907e7fb35756464aa34c35d6abb02998418164b
patch link: https://lore.kernel.org/r/20250121-imx-lmm-cpu-v1-2-0eab7e073e4e%40nxp.com
patch subject: [PATCH 2/5] firmware: arm_scmi: imx: Add i.MX95 CPU Protocol
config: arm64-randconfig-r122-20250124 (https://download.01.org/0day-ci/archive/20250124/202501241148.0CI9mBP5-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 14.2.0
reproduce: (https://download.01.org/0day-ci/archive/20250124/202501241148.0CI9mBP5-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202501241148.0CI9mBP5-lkp@intel.com/
sparse warnings: (new ones prefixed by >>)
>> drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c:139:19: sparse: sparse: incorrect type in assignment (different base types) @@ expected restricted __le32 [usertype] flags @@ got unsigned long @@
drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c:139:19: sparse: expected restricted __le32 [usertype] flags
drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c:139:19: sparse: got unsigned long
>> drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c:140:19: sparse: sparse: invalid assignment: |=
drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c:140:19: sparse: left side has type restricted __le32
drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c:140:19: sparse: right side has type unsigned long
drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c:141:19: sparse: sparse: invalid assignment: |=
drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c:141:19: sparse: left side has type restricted __le32
drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c:141:19: sparse: right side has type unsigned long
>> drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c:173:25: sparse: sparse: restricted __le32 degrades to integer
drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c:205:32: sparse: sparse: restricted __le32 degrades to integer
vim +139 drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c
119
120 static int scmi_imx_cpu_reset_vector_set(const struct scmi_protocol_handle *ph,
121 u32 cpuid, u64 vector, bool start,
122 bool boot, bool resume)
123 {
124 struct scmi_imx_cpu_reset_vector_set_in *in;
125 struct scmi_xfer *t;
126 int ret;
127
128 ret = scmi_imx_cpu_validate_cpuid(ph, cpuid);
129 if (ret)
130 return ret;
131
132 ret = ph->xops->xfer_get_init(ph, SCMI_IMX_CPU_RESET_VECTOR_SET, sizeof(*in),
133 0, &t);
134 if (ret)
135 return ret;
136
137 in = t->tx.buf;
138 in->cpuid = cpu_to_le32(cpuid);
> 139 in->flags = start ? CPU_VEC_FLAGS_START : 0;
> 140 in->flags |= boot ? CPU_VEC_FLAGS_BOOT : 0;
141 in->flags |= resume ? CPU_VEC_FLAGS_BOOT : 0;
142 in->resetvectorlow = cpu_to_le32(lower_32_bits(vector));
143 in->resetvectorhigh = cpu_to_le32(upper_32_bits(vector));
144 ret = ph->xops->do_xfer(ph, t);
145
146 ph->xops->xfer_put(ph, t);
147
148 return ret;
149 }
150
151 static int scmi_imx_cpu_started(const struct scmi_protocol_handle *ph, u32 cpuid,
152 bool *started)
153 {
154 struct scmi_imx_cpu_info_get_out *out;
155 struct scmi_xfer *t;
156 int ret;
157
158 *started = false;
159 ret = scmi_imx_cpu_validate_cpuid(ph, cpuid);
160 if (ret)
161 return ret;
162
163 ret = ph->xops->xfer_get_init(ph, SCMI_IMX_CPU_INFO_GET, sizeof(u32),
164 0, &t);
165 if (ret)
166 return ret;
167
168 put_unaligned_le32(cpuid, t->tx.buf);
169 ret = ph->xops->do_xfer(ph, t);
170 if (!ret) {
171 out = t->rx.buf;
172 if ((out->runmode == CPU_RUN_MODE_START) ||
> 173 (out->runmode == CPU_RUN_MODE_SLEEP))
174 *started = true;
175 }
176
177 ph->xops->xfer_put(ph, t);
178
179 return ret;
180 }
181
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: [PATCH 0/5] firmware: scmi/imx: Add i.MX95 LMM/CPU Protocol
2025-01-21 15:08 [PATCH 0/5] firmware: scmi/imx: Add i.MX95 LMM/CPU Protocol Peng Fan (OSS)
` (5 preceding siblings ...)
2025-01-21 15:31 ` [PATCH 0/5] firmware: scmi/imx: Add i.MX95 LMM/CPU Protocol Cristian Marussi
@ 2025-01-25 1:00 ` Peng Fan
2025-02-06 2:40 ` Peng Fan
7 siblings, 0 replies; 23+ messages in thread
From: Peng Fan @ 2025-01-25 1:00 UTC (permalink / raw)
To: Peng Fan (OSS), Sudeep Holla, Cristian Marussi, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: linux-kernel@vger.kernel.org, arm-scmi@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
> Subject: [PATCH 0/5] firmware: scmi/imx: Add i.MX95 LMM/CPU
> Protocol
Just let you know, our SM has a new ID LMM_RESET_VECTOR_SET
in NXP dev branch, that I overlooked when I developed this patch
set using master branch.
I will include it in v2 later.
Thanks,
Peng.
>
> i.MX95 System Manager(SM) implements Logical Machine
> Management(LMM) and CPU protocol to manage Logical Machine(LM)
> and CPUs(eg, M7).
>
> To manage M7 in a separate LM or in same LM as Linux itself. LMM
> APIs and CPU APIs are needed.
>
> When M7 is in LM 'lm-m7', and this LM is managable by 'linux-lm',
> linux could use LMM_BOOT, LMM_SHUTDOWN and etc to manage
> 'lm-m7'.
>
> If in same LM, use CPU_START, CPU_STOP, CPU_RESET_VECTOR_SET
> and etc to manage M7.
>
> Both LMM/CPU APIs will be used by remoteproc driver. The
> remoteproc patchset will be posted out after this patchset gets
> reviewed or in good shape per Maitainer's view.
>
> Build pass with COMPILE_TEST
> Tested with remoteproc on i.MX95
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> Peng Fan (5):
> firmware: arm_scmi: imx: Add i.MX95 LMM protocol
> firmware: arm_scmi: imx: Add i.MX95 CPU Protocol
> firmware: arm_scmi: imx: Add LMM and CPU documentation
> firmware: imx: Add i.MX95 SCMI LMM driver
> firmware: imx: Add i.MX95 SCMI CPU driver
>
> drivers/firmware/arm_scmi/vendors/imx/Kconfig | 22 +
> drivers/firmware/arm_scmi/vendors/imx/Makefile | 2 +
> drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c | 283
> +++++++++ drivers/firmware/arm_scmi/vendors/imx/imx-sm-lmm.c |
> 235 +++++++
> drivers/firmware/arm_scmi/vendors/imx/imx95.rst | 692
> +++++++++++++++++++++
> drivers/firmware/imx/Kconfig | 22 +
> drivers/firmware/imx/Makefile | 2 +
> drivers/firmware/imx/sm-cpu.c | 91 +++
> drivers/firmware/imx/sm-lmm.c | 89 +++
> include/linux/firmware/imx/sm.h | 56 ++
> include/linux/scmi_imx_protocol.h | 39 ++
> 11 files changed, 1533 insertions(+)
> ---
> base-commit: 0907e7fb35756464aa34c35d6abb02998418164b
> change-id: 20250120-imx-lmm-cpu-418daaa257e2
>
> Best regards,
> --
> Peng Fan <peng.fan@nxp.com>
^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: [PATCH 0/5] firmware: scmi/imx: Add i.MX95 LMM/CPU Protocol
2025-01-21 15:08 [PATCH 0/5] firmware: scmi/imx: Add i.MX95 LMM/CPU Protocol Peng Fan (OSS)
` (6 preceding siblings ...)
2025-01-25 1:00 ` Peng Fan
@ 2025-02-06 2:40 ` Peng Fan
7 siblings, 0 replies; 23+ messages in thread
From: Peng Fan @ 2025-02-06 2:40 UTC (permalink / raw)
To: Peng Fan (OSS), Sudeep Holla, Cristian Marussi, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: linux-kernel@vger.kernel.org, arm-scmi@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
Hi,
> Subject: [PATCH 0/5] firmware: scmi/imx: Add i.MX95 LMM/CPU
> Protocol
I am planning to send V2 out this week if no more comments.
Thanks,
Peng.
>
> i.MX95 System Manager(SM) implements Logical Machine
> Management(LMM) and CPU protocol to manage Logical Machine(LM)
> and CPUs(eg, M7).
>
> To manage M7 in a separate LM or in same LM as Linux itself. LMM
> APIs and CPU APIs are needed.
>
> When M7 is in LM 'lm-m7', and this LM is managable by 'linux-lm',
> linux could use LMM_BOOT, LMM_SHUTDOWN and etc to manage
> 'lm-m7'.
>
> If in same LM, use CPU_START, CPU_STOP, CPU_RESET_VECTOR_SET
> and etc to manage M7.
>
> Both LMM/CPU APIs will be used by remoteproc driver. The
> remoteproc patchset will be posted out after this patchset gets
> reviewed or in good shape per Maitainer's view.
>
> Build pass with COMPILE_TEST
> Tested with remoteproc on i.MX95
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> Peng Fan (5):
> firmware: arm_scmi: imx: Add i.MX95 LMM protocol
> firmware: arm_scmi: imx: Add i.MX95 CPU Protocol
> firmware: arm_scmi: imx: Add LMM and CPU documentation
> firmware: imx: Add i.MX95 SCMI LMM driver
> firmware: imx: Add i.MX95 SCMI CPU driver
>
> drivers/firmware/arm_scmi/vendors/imx/Kconfig | 22 +
> drivers/firmware/arm_scmi/vendors/imx/Makefile | 2 +
> drivers/firmware/arm_scmi/vendors/imx/imx-sm-cpu.c | 283
> +++++++++ drivers/firmware/arm_scmi/vendors/imx/imx-sm-lmm.c |
> 235 +++++++
> drivers/firmware/arm_scmi/vendors/imx/imx95.rst | 692
> +++++++++++++++++++++
> drivers/firmware/imx/Kconfig | 22 +
> drivers/firmware/imx/Makefile | 2 +
> drivers/firmware/imx/sm-cpu.c | 91 +++
> drivers/firmware/imx/sm-lmm.c | 89 +++
> include/linux/firmware/imx/sm.h | 56 ++
> include/linux/scmi_imx_protocol.h | 39 ++
> 11 files changed, 1533 insertions(+)
> ---
> base-commit: 0907e7fb35756464aa34c35d6abb02998418164b
> change-id: 20250120-imx-lmm-cpu-418daaa257e2
>
> Best regards,
> --
> Peng Fan <peng.fan@nxp.com>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 3/5] firmware: arm_scmi: imx: Add LMM and CPU documentation
2025-01-23 1:30 ` Peng Fan
@ 2025-02-25 10:21 ` Sudeep Holla
2025-02-25 12:42 ` Peng Fan
0 siblings, 1 reply; 23+ messages in thread
From: Sudeep Holla @ 2025-02-25 10:21 UTC (permalink / raw)
To: Peng Fan
Cc: Peng Fan (OSS), Chuck Cannon, Sudeep Holla, Cristian Marussi,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
linux-kernel@vger.kernel.org, arm-scmi@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
On Thu, Jan 23, 2025 at 01:30:43AM +0000, Peng Fan wrote:
>
> This is to manage the M7 core by Linux. I just put more documentation here.
> CPU protocol is also used by ATF to manage AP cores.
>
Good
> > Also what other CPUs are we talking here.
>
> M7 core
>
Are they referred by any other name in the system ? I reason I ask is using
plain "CPU" is too generic and confusing. At the same time using "M7" may be
too specific. I am trying to see if there is any middle ground.
> In general I would like to
> > explore the possibility of collapsing this with LM protocol. CPUs within
> > LM is LM's responsibility to bring up. And CPU can be seen as an LM for
> > sake of this vendor protocol. I am not get into details here yet before I
> > can understand what these CPUs are really in the system and why we
> > need this.
>
> Our system supports M7 and A55 in one LM, so A55 use CPU protocol to
> manage M7. When M7 and A55 in different LM, use LM protocol to
> manage M7 LM.
>
The LM(assuming Logical Module/Machine) is an abstract construct, it should
apply to even subset of components within an LM. Just wondering what are
specific reasons do you think applying LM protocol you have on those M7
CPUs alone in A55+M7 LM would not fit well.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 3/5] firmware: arm_scmi: imx: Add LMM and CPU documentation
2025-02-25 12:42 ` Peng Fan
@ 2025-02-25 11:49 ` Sudeep Holla
2025-02-26 3:11 ` Peng Fan
0 siblings, 1 reply; 23+ messages in thread
From: Sudeep Holla @ 2025-02-25 11:49 UTC (permalink / raw)
To: Peng Fan
Cc: Peng Fan, Chuck Cannon, Cristian Marussi, Sudeep Holla, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
linux-kernel@vger.kernel.org, arm-scmi@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
On Tue, Feb 25, 2025 at 08:42:03PM +0800, Peng Fan wrote:
> On Tue, Feb 25, 2025 at 10:21:58AM +0000, Sudeep Holla wrote:
> >On Thu, Jan 23, 2025 at 01:30:43AM +0000, Peng Fan wrote:
> >>
> >> This is to manage the M7 core by Linux. I just put more documentation here.
> >> CPU protocol is also used by ATF to manage AP cores.
> >>
> >
> >Good
> >
> >> > Also what other CPUs are we talking here.
> >>
> >> M7 core
> >>
> >
> >Are they referred by any other name in the system ? I reason I ask is using
> >plain "CPU" is too generic and confusing. At the same time using "M7" may be
> >too specific. I am trying to see if there is any middle ground.
>
> "CPU", if you mean the protocol name SCMI_CPU, there is no good choices.
> I could add a note that "CPU indicates the various cores of i.MX SoC,
> one CPU represents one core"
>
Just a wild suggestion, you don't have to take this. Can it be called
SM CPU or something ? If you can't change the firmware documents which
is understandable, I suggest we call it sm_cpu or something appended before
cpu to distinguish it from the AP CPUs on which Linux runs.
> The documentation origin from https://github.com/nxp-imx/imx-sm
> hard for me to drive a change to use other name.
>
> Anyway if you have ideas, I could bring to our firmware owner.
>
> >
> >> In general I would like to
> >> > explore the possibility of collapsing this with LM protocol. CPUs within
> >> > LM is LM's responsibility to bring up. And CPU can be seen as an LM for
> >> > sake of this vendor protocol. I am not get into details here yet before I
> >> > can understand what these CPUs are really in the system and why we
> >> > need this.
> >>
> >> Our system supports M7 and A55 in one LM, so A55 use CPU protocol to
> >> manage M7. When M7 and A55 in different LM, use LM protocol to
> >> manage M7 LM.
> >>
> >
> >The LM(assuming Logical Module/Machine) is an abstract construct, it should
> >apply to even subset of components within an LM. Just wondering what are
> >specific reasons do you think applying LM protocol you have on those M7
> >CPUs alone in A55+M7 LM would not fit well.
>
> We have internal mail "NXP-ARM SCMI OEM extension" between NXP-ARM that I
> could not post here. In that mail, LM is explained.
>
Fair enough. Please don't share any info that can't be. I understand.
> It is the LM protocol design that it only applies to the whole LM.
> If the LM has A55+M7, A55+M7 will both be handled.
> If the LM only has A55, A55 only be handled.
> If the LM only has M7, M7 only be handled.
>
> When M7 + A55 in one LM, using LM protocol to handle M7 will make A55 not
> work properly. The current linux usecase is remoteproc, that means
> stop M7 will make A55 also stop. So need use CPU protocol here.
>
> When M7 and A55 in separate LM, using LM protocol to handle M7 LM works well.
> The usecase is still remoteproc. In separate LM, A55 CPU protocol will be
> blocked to handle M7 CPU per firmware security.
>
Thanks, I am now clear on LM has A55+M7 and M7 only. However your above
statement relating to LMs with A55 only is not clear. If they run Linux,
they just need to still use PSCI and this CPU protocol shouldn't be used
to control them. Can you clarify on that ?
Other than that, it looks like we do need both LM and CPU. Just asking
all the details so that if in future we have a similar need that needs to
be a standard protocol, it would help us better.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 3/5] firmware: arm_scmi: imx: Add LMM and CPU documentation
2025-02-25 10:21 ` Sudeep Holla
@ 2025-02-25 12:42 ` Peng Fan
2025-02-25 11:49 ` Sudeep Holla
0 siblings, 1 reply; 23+ messages in thread
From: Peng Fan @ 2025-02-25 12:42 UTC (permalink / raw)
To: Sudeep Holla
Cc: Peng Fan, Chuck Cannon, Cristian Marussi, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
linux-kernel@vger.kernel.org, arm-scmi@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
On Tue, Feb 25, 2025 at 10:21:58AM +0000, Sudeep Holla wrote:
>On Thu, Jan 23, 2025 at 01:30:43AM +0000, Peng Fan wrote:
>>
>> This is to manage the M7 core by Linux. I just put more documentation here.
>> CPU protocol is also used by ATF to manage AP cores.
>>
>
>Good
>
>> > Also what other CPUs are we talking here.
>>
>> M7 core
>>
>
>Are they referred by any other name in the system ? I reason I ask is using
>plain "CPU" is too generic and confusing. At the same time using "M7" may be
>too specific. I am trying to see if there is any middle ground.
"CPU", if you mean the protocol name SCMI_CPU, there is no good choices.
I could add a note that "CPU indicates the various cores of i.MX SoC,
one CPU represents one core"
The documentation origin from https://github.com/nxp-imx/imx-sm
hard for me to drive a change to use other name.
Anyway if you have ideas, I could bring to our firmware owner.
>
>> In general I would like to
>> > explore the possibility of collapsing this with LM protocol. CPUs within
>> > LM is LM's responsibility to bring up. And CPU can be seen as an LM for
>> > sake of this vendor protocol. I am not get into details here yet before I
>> > can understand what these CPUs are really in the system and why we
>> > need this.
>>
>> Our system supports M7 and A55 in one LM, so A55 use CPU protocol to
>> manage M7. When M7 and A55 in different LM, use LM protocol to
>> manage M7 LM.
>>
>
>The LM(assuming Logical Module/Machine) is an abstract construct, it should
>apply to even subset of components within an LM. Just wondering what are
>specific reasons do you think applying LM protocol you have on those M7
>CPUs alone in A55+M7 LM would not fit well.
We have internal mail "NXP-ARM SCMI OEM extension" between NXP-ARM that I
could not post here. In that mail, LM is explained.
It is the LM protocol design that it only applies to the whole LM.
If the LM has A55+M7, A55+M7 will both be handled.
If the LM only has A55, A55 only be handled.
If the LM only has M7, M7 only be handled.
When M7 + A55 in one LM, using LM protocol to handle M7 will make A55 not
work properly. The current linux usecase is remoteproc, that means
stop M7 will make A55 also stop. So need use CPU protocol here.
When M7 and A55 in separate LM, using LM protocol to handle M7 LM works well.
The usecase is still remoteproc. In separate LM, A55 CPU protocol will be
blocked to handle M7 CPU per firmware security.
Hope this helps explain.
Regards,
Peng
>
>--
>Regards,
>Sudeep
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 3/5] firmware: arm_scmi: imx: Add LMM and CPU documentation
2025-02-25 11:49 ` Sudeep Holla
@ 2025-02-26 3:11 ` Peng Fan
0 siblings, 0 replies; 23+ messages in thread
From: Peng Fan @ 2025-02-26 3:11 UTC (permalink / raw)
To: Sudeep Holla
Cc: Peng Fan, Chuck Cannon, Cristian Marussi, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
linux-kernel@vger.kernel.org, arm-scmi@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
On Tue, Feb 25, 2025 at 11:49:01AM +0000, Sudeep Holla wrote:
>On Tue, Feb 25, 2025 at 08:42:03PM +0800, Peng Fan wrote:
>> On Tue, Feb 25, 2025 at 10:21:58AM +0000, Sudeep Holla wrote:
>> >On Thu, Jan 23, 2025 at 01:30:43AM +0000, Peng Fan wrote:
>> >>
>> >> This is to manage the M7 core by Linux. I just put more documentation here.
>> >> CPU protocol is also used by ATF to manage AP cores.
>> >>
>> >
>> >Good
>> >
>> >> > Also what other CPUs are we talking here.
>> >>
>> >> M7 core
>> >>
>> >
>> >Are they referred by any other name in the system ? I reason I ask is using
>> >plain "CPU" is too generic and confusing. At the same time using "M7" may be
>> >too specific. I am trying to see if there is any middle ground.
>>
>> "CPU", if you mean the protocol name SCMI_CPU, there is no good choices.
>> I could add a note that "CPU indicates the various cores of i.MX SoC,
>> one CPU represents one core"
>>
>
>Just a wild suggestion, you don't have to take this. Can it be called
>SM CPU or something ? If you can't change the firmware documents which
>is understandable, I suggest we call it sm_cpu or something appended before
>cpu to distinguish it from the AP CPUs on which Linux runs.
ok. Let me try this in v3 and see how it looks like.
>
>> The documentation origin from https://github.com/nxp-imx/imx-sm
>> hard for me to drive a change to use other name.
>>
>> Anyway if you have ideas, I could bring to our firmware owner.
>>
>> >
>> >> In general I would like to
>> >> > explore the possibility of collapsing this with LM protocol. CPUs within
>> >> > LM is LM's responsibility to bring up. And CPU can be seen as an LM for
>> >> > sake of this vendor protocol. I am not get into details here yet before I
>> >> > can understand what these CPUs are really in the system and why we
>> >> > need this.
>> >>
>> >> Our system supports M7 and A55 in one LM, so A55 use CPU protocol to
>> >> manage M7. When M7 and A55 in different LM, use LM protocol to
>> >> manage M7 LM.
>> >>
>> >
>> >The LM(assuming Logical Module/Machine) is an abstract construct, it should
>> >apply to even subset of components within an LM. Just wondering what are
>> >specific reasons do you think applying LM protocol you have on those M7
>> >CPUs alone in A55+M7 LM would not fit well.
>>
>> We have internal mail "NXP-ARM SCMI OEM extension" between NXP-ARM that I
>> could not post here. In that mail, LM is explained.
>>
>
>Fair enough. Please don't share any info that can't be. I understand.
>
>> It is the LM protocol design that it only applies to the whole LM.
>> If the LM has A55+M7, A55+M7 will both be handled.
>> If the LM only has A55, A55 only be handled.
>> If the LM only has M7, M7 only be handled.
>>
>> When M7 + A55 in one LM, using LM protocol to handle M7 will make A55 not
>> work properly. The current linux usecase is remoteproc, that means
>> stop M7 will make A55 also stop. So need use CPU protocol here.
>>
>> When M7 and A55 in separate LM, using LM protocol to handle M7 LM works well.
>> The usecase is still remoteproc. In separate LM, A55 CPU protocol will be
>> blocked to handle M7 CPU per firmware security.
>>
>
>Thanks, I am now clear on LM has A55+M7 and M7 only. However your above
>statement relating to LMs with A55 only is not clear. If they run Linux,
>they just need to still use PSCI and this CPU protocol shouldn't be used
>to control them. Can you clarify on that ?
yes. For A55 only case, the PSCI should be used, and ATF will use CPU
protocol to manage A55 cores when needed.
>
>Other than that, it looks like we do need both LM and CPU. Just asking
>all the details so that if in future we have a similar need that needs to
>be a standard protocol, it would help us better.
Appreciate on help reviewing. Not sure you have time on V2 patchset[1].
I plan to send out V3 early next week(should be before RC5) with your new
comments in V1 and Cristian's comments in V2 addressed. Please let me know
if you have any conern.
[1]https://lore.kernel.org/all/20250212-imx-lmm-cpu-v2-0-3aee005968c1@nxp.com/
Thanks,
Peng
>
>--
>Regards,
>Sudeep
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2025-02-26 2:06 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-01-21 15:08 [PATCH 0/5] firmware: scmi/imx: Add i.MX95 LMM/CPU Protocol Peng Fan (OSS)
2025-01-21 15:08 ` [PATCH 1/5] firmware: arm_scmi: imx: Add i.MX95 LMM protocol Peng Fan (OSS)
2025-01-24 2:43 ` kernel test robot
2025-01-21 15:08 ` [PATCH 2/5] firmware: arm_scmi: imx: Add i.MX95 CPU Protocol Peng Fan (OSS)
2025-01-22 8:48 ` Dan Carpenter
2025-01-22 12:22 ` Cristian Marussi
2025-01-22 12:41 ` Dan Carpenter
2025-01-22 12:55 ` Cristian Marussi
2025-01-22 13:59 ` Sudeep Holla
2025-01-24 4:11 ` kernel test robot
2025-01-21 15:08 ` [PATCH 3/5] firmware: arm_scmi: imx: Add LMM and CPU documentation Peng Fan (OSS)
2025-01-22 12:14 ` Sudeep Holla
2025-01-23 1:30 ` Peng Fan
2025-02-25 10:21 ` Sudeep Holla
2025-02-25 12:42 ` Peng Fan
2025-02-25 11:49 ` Sudeep Holla
2025-02-26 3:11 ` Peng Fan
2025-01-21 15:08 ` [PATCH 4/5] firmware: imx: Add i.MX95 SCMI LMM driver Peng Fan (OSS)
2025-01-21 15:08 ` [PATCH 5/5] firmware: imx: Add i.MX95 SCMI CPU driver Peng Fan (OSS)
2025-01-21 15:31 ` [PATCH 0/5] firmware: scmi/imx: Add i.MX95 LMM/CPU Protocol Cristian Marussi
2025-01-22 5:31 ` Peng Fan
2025-01-25 1:00 ` Peng Fan
2025-02-06 2:40 ` Peng Fan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).