[PATCH v1 00/15] Add support for MT8195 SCP 2nd core

[PATCH v1 00/15] Add support for MT8195 SCP 2nd core

[Tinghan Shen]

The MT8195 System Companion Processor(SCP) is a dual-core RISC-V MCU.
Current mediatek remoteproc driver only supports bring-up single core 
SCP or the 1st core of a dual-core SCP. This series support to bring-up 
the 2nd core of a dual-core SCP.

Tinghan Shen (15):
  dt-binding: remoteproc: mediatek: Support dual-core SCP
  remoteproc: Kconfig: Add mt8195 SCP dual core configuration
  remoteproc: mediatek: Support hanlding scp core 1 wdt timeout
  remoteproc: mediatek: Add SCP core 1 register definitions
  remoteproc: mediatek: Add SCP core 1 driver for dual-core scp
  remoteproc: mediatek: Add SCP core 1 rproc operations
  remoteproc: mediatek: Add SCP core 1 reserved memory support
  remoteproc: mediatek: Add SCP core 1 interrupt support
  remoteproc: mediatek: Register SCP core 1 initialization ipi
  remoteproc: mediatek: Add chip dependent operations for SCP core 1
  remoteproc: mediatek: Add SCP core 1 SRAM offset
  remoteproc: mediatek: SCP core 1 as a rproc subdevice
  remoteproc: mediatek: Wait SCP core 1 probe done
  remoteproc: mediatek: Support rpmsg for SCP core 1
  mfd: cros_ec: Add SCP 2nd core as a new CrOS EC MCU

 .../bindings/remoteproc/mtk,scp.yaml          |  12 +
 drivers/mfd/cros_ec_dev.c                     |   5 +
 drivers/remoteproc/Kconfig                    |  10 +
 drivers/remoteproc/Makefile                   |   1 +
 drivers/remoteproc/mtk_common.h               |  50 +++
 drivers/remoteproc/mtk_scp.c                  |  92 ++++-
 drivers/remoteproc/mtk_scp_dual.c             | 320 ++++++++++++++++++
 drivers/remoteproc/mtk_scp_subdev.c           | 163 +++++++++
 .../linux/platform_data/cros_ec_commands.h    |   2 +
 include/linux/platform_data/cros_ec_proto.h   |   1 +
 10 files changed, 644 insertions(+), 12 deletions(-)
 create mode 100644 drivers/remoteproc/mtk_scp_dual.c
 create mode 100644 drivers/remoteproc/mtk_scp_subdev.c

-- 
2.18.0

[PATCH v1 00/15] Add support for MT8195 SCP 2nd core

[Tinghan Shen]

The MT8195 System Companion Processor(SCP) is a dual-core RISC-V MCU.
Current mediatek remoteproc driver only supports bring-up single core 
SCP or the 1st core of a dual-core SCP. This series support to bring-up 
the 2nd core of a dual-core SCP.

Tinghan Shen (15):
  dt-binding: remoteproc: mediatek: Support dual-core SCP
  remoteproc: Kconfig: Add mt8195 SCP dual core configuration
  remoteproc: mediatek: Support hanlding scp core 1 wdt timeout
  remoteproc: mediatek: Add SCP core 1 register definitions
  remoteproc: mediatek: Add SCP core 1 driver for dual-core scp
  remoteproc: mediatek: Add SCP core 1 rproc operations
  remoteproc: mediatek: Add SCP core 1 reserved memory support
  remoteproc: mediatek: Add SCP core 1 interrupt support
  remoteproc: mediatek: Register SCP core 1 initialization ipi
  remoteproc: mediatek: Add chip dependent operations for SCP core 1
  remoteproc: mediatek: Add SCP core 1 SRAM offset
  remoteproc: mediatek: SCP core 1 as a rproc subdevice
  remoteproc: mediatek: Wait SCP core 1 probe done
  remoteproc: mediatek: Support rpmsg for SCP core 1
  mfd: cros_ec: Add SCP 2nd core as a new CrOS EC MCU

 .../bindings/remoteproc/mtk,scp.yaml          |  12 +
 drivers/mfd/cros_ec_dev.c                     |   5 +
 drivers/remoteproc/Kconfig                    |  10 +
 drivers/remoteproc/Makefile                   |   1 +
 drivers/remoteproc/mtk_common.h               |  50 +++
 drivers/remoteproc/mtk_scp.c                  |  92 ++++-
 drivers/remoteproc/mtk_scp_dual.c             | 320 ++++++++++++++++++
 drivers/remoteproc/mtk_scp_subdev.c           | 163 +++++++++
 .../linux/platform_data/cros_ec_commands.h    |   2 +
 include/linux/platform_data/cros_ec_proto.h   |   1 +
 10 files changed, 644 insertions(+), 12 deletions(-)
 create mode 100644 drivers/remoteproc/mtk_scp_dual.c
 create mode 100644 drivers/remoteproc/mtk_scp_subdev.c

-- 
2.18.0


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH v1 00/15] Add support for MT8195 SCP 2nd core

[Tinghan Shen]

The MT8195 System Companion Processor(SCP) is a dual-core RISC-V MCU.
Current mediatek remoteproc driver only supports bring-up single core 
SCP or the 1st core of a dual-core SCP. This series support to bring-up 
the 2nd core of a dual-core SCP.

Tinghan Shen (15):
  dt-binding: remoteproc: mediatek: Support dual-core SCP
  remoteproc: Kconfig: Add mt8195 SCP dual core configuration
  remoteproc: mediatek: Support hanlding scp core 1 wdt timeout
  remoteproc: mediatek: Add SCP core 1 register definitions
  remoteproc: mediatek: Add SCP core 1 driver for dual-core scp
  remoteproc: mediatek: Add SCP core 1 rproc operations
  remoteproc: mediatek: Add SCP core 1 reserved memory support
  remoteproc: mediatek: Add SCP core 1 interrupt support
  remoteproc: mediatek: Register SCP core 1 initialization ipi
  remoteproc: mediatek: Add chip dependent operations for SCP core 1
  remoteproc: mediatek: Add SCP core 1 SRAM offset
  remoteproc: mediatek: SCP core 1 as a rproc subdevice
  remoteproc: mediatek: Wait SCP core 1 probe done
  remoteproc: mediatek: Support rpmsg for SCP core 1
  mfd: cros_ec: Add SCP 2nd core as a new CrOS EC MCU

 .../bindings/remoteproc/mtk,scp.yaml          |  12 +
 drivers/mfd/cros_ec_dev.c                     |   5 +
 drivers/remoteproc/Kconfig                    |  10 +
 drivers/remoteproc/Makefile                   |   1 +
 drivers/remoteproc/mtk_common.h               |  50 +++
 drivers/remoteproc/mtk_scp.c                  |  92 ++++-
 drivers/remoteproc/mtk_scp_dual.c             | 320 ++++++++++++++++++
 drivers/remoteproc/mtk_scp_subdev.c           | 163 +++++++++
 .../linux/platform_data/cros_ec_commands.h    |   2 +
 include/linux/platform_data/cros_ec_proto.h   |   1 +
 10 files changed, 644 insertions(+), 12 deletions(-)
 create mode 100644 drivers/remoteproc/mtk_scp_dual.c
 create mode 100644 drivers/remoteproc/mtk_scp_subdev.c

-- 
2.18.0


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

[PATCH v1 01/15] dt-binding: remoteproc: mediatek: Support dual-core SCP

[Tinghan Shen]

The SCP co-processor is a dual-core RISC-V MCU on MT8195.

Add a new property to identify each core and helps to find drivers
through device tree API to cooperate with each other, e.g. boot flow and
watchdog timeout flow.

Add a new compatile for the driver of SCP 2nd core.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 .../devicetree/bindings/remoteproc/mtk,scp.yaml      | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
index eec3b9c4c713..b181786d9575 100644
--- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
@@ -20,6 +20,7 @@ properties:
       - mediatek,mt8186-scp
       - mediatek,mt8192-scp
       - mediatek,mt8195-scp
+      - mediatek,mt8195-scp-dual
 
   reg:
     description:
@@ -57,6 +58,16 @@ properties:
   memory-region:
     maxItems: 1
 
+  mediatek,scp-core:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    description:
+      The property value is a list with 2 items, a core id and a phandle
+      to the sibling SCP node. The core id represents the id of the dts node contains
+      this property. The valid values of core id are 0 and 1 for dual-core SCP.
+      The phandle of sibling SCP node is used to find the register settings,
+      trigger core dependent callback, and invoke rproc API.
+    maxItems: 1
+
 required:
   - compatible
   - reg
@@ -115,6 +126,7 @@ examples:
         reg-names = "sram", "cfg", "l1tcm";
         clocks = <&infracfg CLK_INFRA_SCPSYS>;
         clock-names = "main";
+        mediatek,scp-core = <0 &scp_dual>;
 
         cros_ec {
             mediatek,rpmsg-name = "cros-ec-rpmsg";
-- 
2.18.0

[PATCH v1 01/15] dt-binding: remoteproc: mediatek: Support dual-core SCP

[Tinghan Shen]

The SCP co-processor is a dual-core RISC-V MCU on MT8195.

Add a new property to identify each core and helps to find drivers
through device tree API to cooperate with each other, e.g. boot flow and
watchdog timeout flow.

Add a new compatile for the driver of SCP 2nd core.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 .../devicetree/bindings/remoteproc/mtk,scp.yaml      | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
index eec3b9c4c713..b181786d9575 100644
--- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
@@ -20,6 +20,7 @@ properties:
       - mediatek,mt8186-scp
       - mediatek,mt8192-scp
       - mediatek,mt8195-scp
+      - mediatek,mt8195-scp-dual
 
   reg:
     description:
@@ -57,6 +58,16 @@ properties:
   memory-region:
     maxItems: 1
 
+  mediatek,scp-core:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    description:
+      The property value is a list with 2 items, a core id and a phandle
+      to the sibling SCP node. The core id represents the id of the dts node contains
+      this property. The valid values of core id are 0 and 1 for dual-core SCP.
+      The phandle of sibling SCP node is used to find the register settings,
+      trigger core dependent callback, and invoke rproc API.
+    maxItems: 1
+
 required:
   - compatible
   - reg
@@ -115,6 +126,7 @@ examples:
         reg-names = "sram", "cfg", "l1tcm";
         clocks = <&infracfg CLK_INFRA_SCPSYS>;
         clock-names = "main";
+        mediatek,scp-core = <0 &scp_dual>;
 
         cros_ec {
             mediatek,rpmsg-name = "cros-ec-rpmsg";
-- 
2.18.0


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH v1 01/15] dt-binding: remoteproc: mediatek: Support dual-core SCP

[Tinghan Shen]

The SCP co-processor is a dual-core RISC-V MCU on MT8195.

Add a new property to identify each core and helps to find drivers
through device tree API to cooperate with each other, e.g. boot flow and
watchdog timeout flow.

Add a new compatile for the driver of SCP 2nd core.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 .../devicetree/bindings/remoteproc/mtk,scp.yaml      | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
index eec3b9c4c713..b181786d9575 100644
--- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
@@ -20,6 +20,7 @@ properties:
       - mediatek,mt8186-scp
       - mediatek,mt8192-scp
       - mediatek,mt8195-scp
+      - mediatek,mt8195-scp-dual
 
   reg:
     description:
@@ -57,6 +58,16 @@ properties:
   memory-region:
     maxItems: 1
 
+  mediatek,scp-core:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    description:
+      The property value is a list with 2 items, a core id and a phandle
+      to the sibling SCP node. The core id represents the id of the dts node contains
+      this property. The valid values of core id are 0 and 1 for dual-core SCP.
+      The phandle of sibling SCP node is used to find the register settings,
+      trigger core dependent callback, and invoke rproc API.
+    maxItems: 1
+
 required:
   - compatible
   - reg
@@ -115,6 +126,7 @@ examples:
         reg-names = "sram", "cfg", "l1tcm";
         clocks = <&infracfg CLK_INFRA_SCPSYS>;
         clock-names = "main";
+        mediatek,scp-core = <0 &scp_dual>;
 
         cros_ec {
             mediatek,rpmsg-name = "cros-ec-rpmsg";
-- 
2.18.0


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

[PATCH v1 02/15] remoteproc: Kconfig: Add mt8195 SCP dual core configuration

[Tinghan Shen]

MediaTek MT8195 SoC SCP is a dual-core subsystem. Add a remoteproc
configuration to enable support of the 2nd core.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/Kconfig | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 166019786653..bb2960b4ffbd 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -64,6 +64,16 @@ config MTK_SCP
 
 	  It's safe to say N here.
 
+config MTK_SCP_DUALCORE
+	tristate "MediaTek SCP dual-core support"
+	depends on ARCH_MEDIATEK || COMPILE_TEST
+	depends on MTK_SCP
+	help
+	  Say y here to support bring up the 2nd core of the dual-core version of
+	  MediaTek's SCP via the remote processor framework.
+
+	  It's safe to say N here.
+
 config OMAP_REMOTEPROC
 	tristate "OMAP remoteproc support"
 	depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX
-- 
2.18.0

[PATCH v1 02/15] remoteproc: Kconfig: Add mt8195 SCP dual core configuration

[Tinghan Shen]

MediaTek MT8195 SoC SCP is a dual-core subsystem. Add a remoteproc
configuration to enable support of the 2nd core.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/Kconfig | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 166019786653..bb2960b4ffbd 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -64,6 +64,16 @@ config MTK_SCP
 
 	  It's safe to say N here.
 
+config MTK_SCP_DUALCORE
+	tristate "MediaTek SCP dual-core support"
+	depends on ARCH_MEDIATEK || COMPILE_TEST
+	depends on MTK_SCP
+	help
+	  Say y here to support bring up the 2nd core of the dual-core version of
+	  MediaTek's SCP via the remote processor framework.
+
+	  It's safe to say N here.
+
 config OMAP_REMOTEPROC
 	tristate "OMAP remoteproc support"
 	depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX
-- 
2.18.0


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH v1 02/15] remoteproc: Kconfig: Add mt8195 SCP dual core configuration

[Tinghan Shen]

MediaTek MT8195 SoC SCP is a dual-core subsystem. Add a remoteproc
configuration to enable support of the 2nd core.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/Kconfig | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 166019786653..bb2960b4ffbd 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -64,6 +64,16 @@ config MTK_SCP
 
 	  It's safe to say N here.
 
+config MTK_SCP_DUALCORE
+	tristate "MediaTek SCP dual-core support"
+	depends on ARCH_MEDIATEK || COMPILE_TEST
+	depends on MTK_SCP
+	help
+	  Say y here to support bring up the 2nd core of the dual-core version of
+	  MediaTek's SCP via the remote processor framework.
+
+	  It's safe to say N here.
+
 config OMAP_REMOTEPROC
 	tristate "OMAP remoteproc support"
 	depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX
-- 
2.18.0


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

[PATCH v1 03/15] remoteproc: mediatek: Support hanlding scp core 1 wdt timeout

[Tinghan Shen]

MT8195 SCP is a dual-core processor. The SCP core 1 watchdog timeout
interrupt uses the same interrupt line of SCP core 0 watchdog timeout
interrupt.

Add support for handling SCP core 1 watchdog timeout interrupt in the
SCP IRQ handler.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_common.h |  4 ++++
 drivers/remoteproc/mtk_scp.c    | 27 ++++++++++++++++++++++++++-
 2 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index ea6fa1100a00..73e8adf00de3 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -54,6 +54,10 @@
 #define MT8192_CORE0_WDT_IRQ		0x10030
 #define MT8192_CORE0_WDT_CFG		0x10034
 
+#define MT8195_SYS_STATUS		0x4004
+#define MT8195_CORE0_WDT		BIT(16)
+#define MT8195_CORE1_WDT		BIT(17)
+
 #define MT8195_L1TCM_SRAM_PDN_RESERVED_RSI_BITS		GENMASK(7, 4)
 
 #define SCP_FW_VER_LEN			32
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index 47b2a40e1b4a..3510c6d0bbc8 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -212,6 +212,31 @@ static void mt8192_scp_irq_handler(struct mtk_scp *scp)
 	}
 }
 
+static void mt8195_scp_irq_handler(struct mtk_scp *scp)
+{
+	u32 scp_to_host;
+
+	scp_to_host = readl(scp->reg_base + MT8192_SCP2APMCU_IPC_SET);
+
+	if (scp_to_host & MT8192_SCP_IPC_INT_BIT) {
+		scp_ipi_handler(scp);
+
+		/*
+		 * SCP won't send another interrupt until we clear
+		 * MT8192_SCP2APMCU_IPC.
+		 */
+		writel(MT8192_SCP_IPC_INT_BIT,
+		       scp->reg_base + MT8192_SCP2APMCU_IPC_CLR);
+	} else {
+		if (readl(scp->reg_base + MT8195_SYS_STATUS) & MT8195_CORE1_WDT) {
+			writel(1, scp->reg_base + MT8195_CORE1_WDT_IRQ);
+		} else {
+			writel(1, scp->reg_base + MT8192_CORE0_WDT_IRQ);
+			scp_wdt_handler(scp, scp_to_host);
+		}
+	}
+}
+
 static irqreturn_t scp_irq_handler(int irq, void *priv)
 {
 	struct mtk_scp *scp = priv;
@@ -961,7 +986,7 @@ static const struct mtk_scp_of_data mt8192_of_data = {
 static const struct mtk_scp_of_data mt8195_of_data = {
 	.scp_clk_get = mt8195_scp_clk_get,
 	.scp_before_load = mt8195_scp_before_load,
-	.scp_irq_handler = mt8192_scp_irq_handler,
+	.scp_irq_handler = mt8195_scp_irq_handler,
 	.scp_reset_assert = mt8192_scp_reset_assert,
 	.scp_reset_deassert = mt8192_scp_reset_deassert,
 	.scp_stop = mt8195_scp_stop,
-- 
2.18.0

[PATCH v1 03/15] remoteproc: mediatek: Support hanlding scp core 1 wdt timeout

[Tinghan Shen]

MT8195 SCP is a dual-core processor. The SCP core 1 watchdog timeout
interrupt uses the same interrupt line of SCP core 0 watchdog timeout
interrupt.

Add support for handling SCP core 1 watchdog timeout interrupt in the
SCP IRQ handler.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_common.h |  4 ++++
 drivers/remoteproc/mtk_scp.c    | 27 ++++++++++++++++++++++++++-
 2 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index ea6fa1100a00..73e8adf00de3 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -54,6 +54,10 @@
 #define MT8192_CORE0_WDT_IRQ		0x10030
 #define MT8192_CORE0_WDT_CFG		0x10034
 
+#define MT8195_SYS_STATUS		0x4004
+#define MT8195_CORE0_WDT		BIT(16)
+#define MT8195_CORE1_WDT		BIT(17)
+
 #define MT8195_L1TCM_SRAM_PDN_RESERVED_RSI_BITS		GENMASK(7, 4)
 
 #define SCP_FW_VER_LEN			32
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index 47b2a40e1b4a..3510c6d0bbc8 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -212,6 +212,31 @@ static void mt8192_scp_irq_handler(struct mtk_scp *scp)
 	}
 }
 
+static void mt8195_scp_irq_handler(struct mtk_scp *scp)
+{
+	u32 scp_to_host;
+
+	scp_to_host = readl(scp->reg_base + MT8192_SCP2APMCU_IPC_SET);
+
+	if (scp_to_host & MT8192_SCP_IPC_INT_BIT) {
+		scp_ipi_handler(scp);
+
+		/*
+		 * SCP won't send another interrupt until we clear
+		 * MT8192_SCP2APMCU_IPC.
+		 */
+		writel(MT8192_SCP_IPC_INT_BIT,
+		       scp->reg_base + MT8192_SCP2APMCU_IPC_CLR);
+	} else {
+		if (readl(scp->reg_base + MT8195_SYS_STATUS) & MT8195_CORE1_WDT) {
+			writel(1, scp->reg_base + MT8195_CORE1_WDT_IRQ);
+		} else {
+			writel(1, scp->reg_base + MT8192_CORE0_WDT_IRQ);
+			scp_wdt_handler(scp, scp_to_host);
+		}
+	}
+}
+
 static irqreturn_t scp_irq_handler(int irq, void *priv)
 {
 	struct mtk_scp *scp = priv;
@@ -961,7 +986,7 @@ static const struct mtk_scp_of_data mt8192_of_data = {
 static const struct mtk_scp_of_data mt8195_of_data = {
 	.scp_clk_get = mt8195_scp_clk_get,
 	.scp_before_load = mt8195_scp_before_load,
-	.scp_irq_handler = mt8192_scp_irq_handler,
+	.scp_irq_handler = mt8195_scp_irq_handler,
 	.scp_reset_assert = mt8192_scp_reset_assert,
 	.scp_reset_deassert = mt8192_scp_reset_deassert,
 	.scp_stop = mt8195_scp_stop,
-- 
2.18.0


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH v1 03/15] remoteproc: mediatek: Support hanlding scp core 1 wdt timeout

[Tinghan Shen]

MT8195 SCP is a dual-core processor. The SCP core 1 watchdog timeout
interrupt uses the same interrupt line of SCP core 0 watchdog timeout
interrupt.

Add support for handling SCP core 1 watchdog timeout interrupt in the
SCP IRQ handler.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_common.h |  4 ++++
 drivers/remoteproc/mtk_scp.c    | 27 ++++++++++++++++++++++++++-
 2 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index ea6fa1100a00..73e8adf00de3 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -54,6 +54,10 @@
 #define MT8192_CORE0_WDT_IRQ		0x10030
 #define MT8192_CORE0_WDT_CFG		0x10034
 
+#define MT8195_SYS_STATUS		0x4004
+#define MT8195_CORE0_WDT		BIT(16)
+#define MT8195_CORE1_WDT		BIT(17)
+
 #define MT8195_L1TCM_SRAM_PDN_RESERVED_RSI_BITS		GENMASK(7, 4)
 
 #define SCP_FW_VER_LEN			32
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index 47b2a40e1b4a..3510c6d0bbc8 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -212,6 +212,31 @@ static void mt8192_scp_irq_handler(struct mtk_scp *scp)
 	}
 }
 
+static void mt8195_scp_irq_handler(struct mtk_scp *scp)
+{
+	u32 scp_to_host;
+
+	scp_to_host = readl(scp->reg_base + MT8192_SCP2APMCU_IPC_SET);
+
+	if (scp_to_host & MT8192_SCP_IPC_INT_BIT) {
+		scp_ipi_handler(scp);
+
+		/*
+		 * SCP won't send another interrupt until we clear
+		 * MT8192_SCP2APMCU_IPC.
+		 */
+		writel(MT8192_SCP_IPC_INT_BIT,
+		       scp->reg_base + MT8192_SCP2APMCU_IPC_CLR);
+	} else {
+		if (readl(scp->reg_base + MT8195_SYS_STATUS) & MT8195_CORE1_WDT) {
+			writel(1, scp->reg_base + MT8195_CORE1_WDT_IRQ);
+		} else {
+			writel(1, scp->reg_base + MT8192_CORE0_WDT_IRQ);
+			scp_wdt_handler(scp, scp_to_host);
+		}
+	}
+}
+
 static irqreturn_t scp_irq_handler(int irq, void *priv)
 {
 	struct mtk_scp *scp = priv;
@@ -961,7 +986,7 @@ static const struct mtk_scp_of_data mt8192_of_data = {
 static const struct mtk_scp_of_data mt8195_of_data = {
 	.scp_clk_get = mt8195_scp_clk_get,
 	.scp_before_load = mt8195_scp_before_load,
-	.scp_irq_handler = mt8192_scp_irq_handler,
+	.scp_irq_handler = mt8195_scp_irq_handler,
 	.scp_reset_assert = mt8192_scp_reset_assert,
 	.scp_reset_deassert = mt8192_scp_reset_deassert,
 	.scp_stop = mt8195_scp_stop,
-- 
2.18.0


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

[PATCH v1 04/15] remoteproc: mediatek: Add SCP core 1 register definitions

[Tinghan Shen]

Add MT8195 SCP core 1 related register definitions.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_common.h | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index 73e8adf00de3..2eadb0e696a1 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -47,6 +47,7 @@
 #define MT8192_SCP2SPM_IPC_CLR		0x4094
 #define MT8192_GIPC_IN_SET		0x4098
 #define MT8192_HOST_IPC_INT_BIT		BIT(0)
+#define MT8195_HOST_IPC_INT_BIT		BIT(4)
 
 #define MT8192_CORE0_SW_RSTN_CLR	0x10000
 #define MT8192_CORE0_SW_RSTN_SET	0x10004
@@ -60,6 +61,26 @@
 
 #define MT8195_L1TCM_SRAM_PDN_RESERVED_RSI_BITS		GENMASK(7, 4)
 
+#define MT8195_CPU1_SRAM_PD			0x1084
+#define MT8195_SSHUB2APMCU_IPC_SET		0x4088
+#define MT8195_SSHUB2APMCU_IPC_CLR		0x408C
+#define MT8195_CORE1_SW_RSTN_CLR		0x20000
+#define MT8195_CORE1_SW_RSTN_SET		0x20004
+#define MT8195_CORE1_MEM_ATT_PREDEF		0x20008
+#define MT8195_CORE1_WDT_IRQ			0x20030
+#define MT8195_CORE1_WDT_CFG			0x20034
+
+#define MT8195_SEC_CTRL				0x85000
+#define MT8195_CORE_OFFSET_ENABLE_D		BIT(13)
+#define MT8195_CORE_OFFSET_ENABLE_I		BIT(12)
+#define MT8195_L2TCM_OFFSET_RANGE_0_LOW		0x850b0
+#define MT8195_L2TCM_OFFSET_RANGE_0_HIGH	0x850b4
+#define MT8195_L2TCM_OFFSET			0x850d0
+#define SCP_SRAM_REMAP_LOW			0
+#define SCP_SRAM_REMAP_HIGH			1
+#define SCP_SRAM_REMAP_OFFSET			2
+#define SCP_SRAM_REMAP_SIZE			3
+
 #define SCP_FW_VER_LEN			32
 #define SCP_SHARE_BUFFER_SIZE		288
 
-- 
2.18.0

[PATCH v1 04/15] remoteproc: mediatek: Add SCP core 1 register definitions

[Tinghan Shen]

Add MT8195 SCP core 1 related register definitions.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_common.h | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index 73e8adf00de3..2eadb0e696a1 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -47,6 +47,7 @@
 #define MT8192_SCP2SPM_IPC_CLR		0x4094
 #define MT8192_GIPC_IN_SET		0x4098
 #define MT8192_HOST_IPC_INT_BIT		BIT(0)
+#define MT8195_HOST_IPC_INT_BIT		BIT(4)
 
 #define MT8192_CORE0_SW_RSTN_CLR	0x10000
 #define MT8192_CORE0_SW_RSTN_SET	0x10004
@@ -60,6 +61,26 @@
 
 #define MT8195_L1TCM_SRAM_PDN_RESERVED_RSI_BITS		GENMASK(7, 4)
 
+#define MT8195_CPU1_SRAM_PD			0x1084
+#define MT8195_SSHUB2APMCU_IPC_SET		0x4088
+#define MT8195_SSHUB2APMCU_IPC_CLR		0x408C
+#define MT8195_CORE1_SW_RSTN_CLR		0x20000
+#define MT8195_CORE1_SW_RSTN_SET		0x20004
+#define MT8195_CORE1_MEM_ATT_PREDEF		0x20008
+#define MT8195_CORE1_WDT_IRQ			0x20030
+#define MT8195_CORE1_WDT_CFG			0x20034
+
+#define MT8195_SEC_CTRL				0x85000
+#define MT8195_CORE_OFFSET_ENABLE_D		BIT(13)
+#define MT8195_CORE_OFFSET_ENABLE_I		BIT(12)
+#define MT8195_L2TCM_OFFSET_RANGE_0_LOW		0x850b0
+#define MT8195_L2TCM_OFFSET_RANGE_0_HIGH	0x850b4
+#define MT8195_L2TCM_OFFSET			0x850d0
+#define SCP_SRAM_REMAP_LOW			0
+#define SCP_SRAM_REMAP_HIGH			1
+#define SCP_SRAM_REMAP_OFFSET			2
+#define SCP_SRAM_REMAP_SIZE			3
+
 #define SCP_FW_VER_LEN			32
 #define SCP_SHARE_BUFFER_SIZE		288
 
-- 
2.18.0


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH v1 04/15] remoteproc: mediatek: Add SCP core 1 register definitions

[Tinghan Shen]

Add MT8195 SCP core 1 related register definitions.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_common.h | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index 73e8adf00de3..2eadb0e696a1 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -47,6 +47,7 @@
 #define MT8192_SCP2SPM_IPC_CLR		0x4094
 #define MT8192_GIPC_IN_SET		0x4098
 #define MT8192_HOST_IPC_INT_BIT		BIT(0)
+#define MT8195_HOST_IPC_INT_BIT		BIT(4)
 
 #define MT8192_CORE0_SW_RSTN_CLR	0x10000
 #define MT8192_CORE0_SW_RSTN_SET	0x10004
@@ -60,6 +61,26 @@
 
 #define MT8195_L1TCM_SRAM_PDN_RESERVED_RSI_BITS		GENMASK(7, 4)
 
+#define MT8195_CPU1_SRAM_PD			0x1084
+#define MT8195_SSHUB2APMCU_IPC_SET		0x4088
+#define MT8195_SSHUB2APMCU_IPC_CLR		0x408C
+#define MT8195_CORE1_SW_RSTN_CLR		0x20000
+#define MT8195_CORE1_SW_RSTN_SET		0x20004
+#define MT8195_CORE1_MEM_ATT_PREDEF		0x20008
+#define MT8195_CORE1_WDT_IRQ			0x20030
+#define MT8195_CORE1_WDT_CFG			0x20034
+
+#define MT8195_SEC_CTRL				0x85000
+#define MT8195_CORE_OFFSET_ENABLE_D		BIT(13)
+#define MT8195_CORE_OFFSET_ENABLE_I		BIT(12)
+#define MT8195_L2TCM_OFFSET_RANGE_0_LOW		0x850b0
+#define MT8195_L2TCM_OFFSET_RANGE_0_HIGH	0x850b4
+#define MT8195_L2TCM_OFFSET			0x850d0
+#define SCP_SRAM_REMAP_LOW			0
+#define SCP_SRAM_REMAP_HIGH			1
+#define SCP_SRAM_REMAP_OFFSET			2
+#define SCP_SRAM_REMAP_SIZE			3
+
 #define SCP_FW_VER_LEN			32
 #define SCP_SHARE_BUFFER_SIZE		288
 
-- 
2.18.0


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

[PATCH v1 05/15] remoteproc: mediatek: Add SCP core 1 driver for dual-core scp

[Tinghan Shen]

MT8195 SCP is a dual-core processor. The mtk_scp.c driver only controls
SCP core 0. This patch adds a basic driver to control the another core.

Core 1 and core 0 of the SCP are housed in the same subsys.They see
registers and memory in the same way.

Core 1 of the SCP features its own set of core configuration registers,
interrupt controller, timers, and DMAs. The rest of the peripherals
in this subsystem are shared by core 0 and core 1.

As for memory, core 1 has its own cache memory, and the SCP SRAM is shared
by core 0 and core 1.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/Makefile       |  1 +
 drivers/remoteproc/mtk_scp_dual.c | 97 +++++++++++++++++++++++++++++++
 2 files changed, 98 insertions(+)
 create mode 100644 drivers/remoteproc/mtk_scp_dual.c

diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 5478c7cb9e07..84cb687d28da 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_IMX_REMOTEPROC)		+= imx_rproc.o
 obj-$(CONFIG_IMX_DSP_REMOTEPROC)	+= imx_dsp_rproc.o
 obj-$(CONFIG_INGENIC_VPU_RPROC)		+= ingenic_rproc.o
 obj-$(CONFIG_MTK_SCP)			+= mtk_scp.o mtk_scp_ipi.o
+obj-$(CONFIG_MTK_SCP_DUALCORE)		+= mtk_scp_dual.o
 obj-$(CONFIG_OMAP_REMOTEPROC)		+= omap_remoteproc.o
 obj-$(CONFIG_WKUP_M3_RPROC)		+= wkup_m3_rproc.o
 obj-$(CONFIG_DA8XX_REMOTEPROC)		+= da8xx_remoteproc.o
diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
new file mode 100644
index 000000000000..7bc08d26f208
--- /dev/null
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -0,0 +1,97 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2022 MediaTek Inc.
+
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+
+#include "mtk_common.h"
+#include "remoteproc_internal.h"
+
+static const struct rproc_ops scp_ops;
+
+static int scp_dual_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct mtk_scp *scp;
+	struct rproc *rproc;
+	const char *fw_name = "scp-dual.img";
+	int ret, i;
+	struct resource *res;
+
+	ret = rproc_of_parse_firmware(dev, 0, &fw_name);
+	if (ret < 0 && ret != -EINVAL)
+		return ret;
+
+	rproc = devm_rproc_alloc(dev, np->name, &scp_ops, fw_name, sizeof(*scp));
+	if (!rproc) {
+		dev_err(dev, "unable to allocate remoteproc\n");
+		return -ENOMEM;
+	}
+
+	scp = (struct mtk_scp *)rproc->priv;
+	scp->rproc = rproc;
+	scp->dev = dev;
+	platform_set_drvdata(pdev, scp);
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sram");
+	scp->sram_base = devm_ioremap(dev, res->start, resource_size(res));
+	if (IS_ERR(scp->sram_base))
+		return dev_err_probe(dev, PTR_ERR(scp->sram_base),
+				     "Failed to parse and map sram memory\n");
+
+	scp->sram_size = resource_size(res);
+	scp->sram_phys = res->start;
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cfg");
+	scp->reg_base = devm_ioremap(dev, res->start, resource_size(res));
+	if (IS_ERR(scp->reg_base))
+		return dev_err_probe(dev, PTR_ERR(scp->reg_base),
+				     "Failed to parse and map cfg memory\n");
+
+	mutex_init(&scp->send_lock);
+	for (i = 0; i < SCP_IPI_MAX; i++)
+		mutex_init(&scp->ipi_desc[i].lock);
+
+	init_waitqueue_head(&scp->run.wq);
+	init_waitqueue_head(&scp->ack_wq);
+
+	return 0;
+}
+
+static int scp_dual_remove(struct platform_device *pdev)
+{
+	struct mtk_scp *scp = platform_get_drvdata(pdev);
+	int i;
+
+	for (i = 0; i < SCP_IPI_MAX; i++)
+		mutex_destroy(&scp->ipi_desc[i].lock);
+	mutex_destroy(&scp->send_lock);
+
+	return 0;
+}
+
+static const struct of_device_id mtk_scp_dual_of_match[] = {
+	{ .compatible = "mediatek,mt8195-scp-dual" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, mtk_scp_dual_of_match);
+
+static struct platform_driver mtk_scp_dual_driver = {
+	.probe = scp_dual_probe,
+	.remove = scp_dual_remove,
+	.driver = {
+		.name = "mtk-scp-dual",
+		.of_match_table = mtk_scp_dual_of_match,
+	},
+};
+
+module_platform_driver(mtk_scp_dual_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("MediaTek SCP dualcore control driver");
-- 
2.18.0

[PATCH v1 05/15] remoteproc: mediatek: Add SCP core 1 driver for dual-core scp

[Tinghan Shen]

MT8195 SCP is a dual-core processor. The mtk_scp.c driver only controls
SCP core 0. This patch adds a basic driver to control the another core.

Core 1 and core 0 of the SCP are housed in the same subsys.They see
registers and memory in the same way.

Core 1 of the SCP features its own set of core configuration registers,
interrupt controller, timers, and DMAs. The rest of the peripherals
in this subsystem are shared by core 0 and core 1.

As for memory, core 1 has its own cache memory, and the SCP SRAM is shared
by core 0 and core 1.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/Makefile       |  1 +
 drivers/remoteproc/mtk_scp_dual.c | 97 +++++++++++++++++++++++++++++++
 2 files changed, 98 insertions(+)
 create mode 100644 drivers/remoteproc/mtk_scp_dual.c

diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 5478c7cb9e07..84cb687d28da 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_IMX_REMOTEPROC)		+= imx_rproc.o
 obj-$(CONFIG_IMX_DSP_REMOTEPROC)	+= imx_dsp_rproc.o
 obj-$(CONFIG_INGENIC_VPU_RPROC)		+= ingenic_rproc.o
 obj-$(CONFIG_MTK_SCP)			+= mtk_scp.o mtk_scp_ipi.o
+obj-$(CONFIG_MTK_SCP_DUALCORE)		+= mtk_scp_dual.o
 obj-$(CONFIG_OMAP_REMOTEPROC)		+= omap_remoteproc.o
 obj-$(CONFIG_WKUP_M3_RPROC)		+= wkup_m3_rproc.o
 obj-$(CONFIG_DA8XX_REMOTEPROC)		+= da8xx_remoteproc.o
diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
new file mode 100644
index 000000000000..7bc08d26f208
--- /dev/null
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -0,0 +1,97 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2022 MediaTek Inc.
+
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+
+#include "mtk_common.h"
+#include "remoteproc_internal.h"
+
+static const struct rproc_ops scp_ops;
+
+static int scp_dual_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct mtk_scp *scp;
+	struct rproc *rproc;
+	const char *fw_name = "scp-dual.img";
+	int ret, i;
+	struct resource *res;
+
+	ret = rproc_of_parse_firmware(dev, 0, &fw_name);
+	if (ret < 0 && ret != -EINVAL)
+		return ret;
+
+	rproc = devm_rproc_alloc(dev, np->name, &scp_ops, fw_name, sizeof(*scp));
+	if (!rproc) {
+		dev_err(dev, "unable to allocate remoteproc\n");
+		return -ENOMEM;
+	}
+
+	scp = (struct mtk_scp *)rproc->priv;
+	scp->rproc = rproc;
+	scp->dev = dev;
+	platform_set_drvdata(pdev, scp);
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sram");
+	scp->sram_base = devm_ioremap(dev, res->start, resource_size(res));
+	if (IS_ERR(scp->sram_base))
+		return dev_err_probe(dev, PTR_ERR(scp->sram_base),
+				     "Failed to parse and map sram memory\n");
+
+	scp->sram_size = resource_size(res);
+	scp->sram_phys = res->start;
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cfg");
+	scp->reg_base = devm_ioremap(dev, res->start, resource_size(res));
+	if (IS_ERR(scp->reg_base))
+		return dev_err_probe(dev, PTR_ERR(scp->reg_base),
+				     "Failed to parse and map cfg memory\n");
+
+	mutex_init(&scp->send_lock);
+	for (i = 0; i < SCP_IPI_MAX; i++)
+		mutex_init(&scp->ipi_desc[i].lock);
+
+	init_waitqueue_head(&scp->run.wq);
+	init_waitqueue_head(&scp->ack_wq);
+
+	return 0;
+}
+
+static int scp_dual_remove(struct platform_device *pdev)
+{
+	struct mtk_scp *scp = platform_get_drvdata(pdev);
+	int i;
+
+	for (i = 0; i < SCP_IPI_MAX; i++)
+		mutex_destroy(&scp->ipi_desc[i].lock);
+	mutex_destroy(&scp->send_lock);
+
+	return 0;
+}
+
+static const struct of_device_id mtk_scp_dual_of_match[] = {
+	{ .compatible = "mediatek,mt8195-scp-dual" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, mtk_scp_dual_of_match);
+
+static struct platform_driver mtk_scp_dual_driver = {
+	.probe = scp_dual_probe,
+	.remove = scp_dual_remove,
+	.driver = {
+		.name = "mtk-scp-dual",
+		.of_match_table = mtk_scp_dual_of_match,
+	},
+};
+
+module_platform_driver(mtk_scp_dual_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("MediaTek SCP dualcore control driver");
-- 
2.18.0


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH v1 05/15] remoteproc: mediatek: Add SCP core 1 driver for dual-core scp

[Tinghan Shen]

MT8195 SCP is a dual-core processor. The mtk_scp.c driver only controls
SCP core 0. This patch adds a basic driver to control the another core.

Core 1 and core 0 of the SCP are housed in the same subsys.They see
registers and memory in the same way.

Core 1 of the SCP features its own set of core configuration registers,
interrupt controller, timers, and DMAs. The rest of the peripherals
in this subsystem are shared by core 0 and core 1.

As for memory, core 1 has its own cache memory, and the SCP SRAM is shared
by core 0 and core 1.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/Makefile       |  1 +
 drivers/remoteproc/mtk_scp_dual.c | 97 +++++++++++++++++++++++++++++++
 2 files changed, 98 insertions(+)
 create mode 100644 drivers/remoteproc/mtk_scp_dual.c

diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 5478c7cb9e07..84cb687d28da 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_IMX_REMOTEPROC)		+= imx_rproc.o
 obj-$(CONFIG_IMX_DSP_REMOTEPROC)	+= imx_dsp_rproc.o
 obj-$(CONFIG_INGENIC_VPU_RPROC)		+= ingenic_rproc.o
 obj-$(CONFIG_MTK_SCP)			+= mtk_scp.o mtk_scp_ipi.o
+obj-$(CONFIG_MTK_SCP_DUALCORE)		+= mtk_scp_dual.o
 obj-$(CONFIG_OMAP_REMOTEPROC)		+= omap_remoteproc.o
 obj-$(CONFIG_WKUP_M3_RPROC)		+= wkup_m3_rproc.o
 obj-$(CONFIG_DA8XX_REMOTEPROC)		+= da8xx_remoteproc.o
diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
new file mode 100644
index 000000000000..7bc08d26f208
--- /dev/null
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -0,0 +1,97 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2022 MediaTek Inc.
+
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+
+#include "mtk_common.h"
+#include "remoteproc_internal.h"
+
+static const struct rproc_ops scp_ops;
+
+static int scp_dual_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct mtk_scp *scp;
+	struct rproc *rproc;
+	const char *fw_name = "scp-dual.img";
+	int ret, i;
+	struct resource *res;
+
+	ret = rproc_of_parse_firmware(dev, 0, &fw_name);
+	if (ret < 0 && ret != -EINVAL)
+		return ret;
+
+	rproc = devm_rproc_alloc(dev, np->name, &scp_ops, fw_name, sizeof(*scp));
+	if (!rproc) {
+		dev_err(dev, "unable to allocate remoteproc\n");
+		return -ENOMEM;
+	}
+
+	scp = (struct mtk_scp *)rproc->priv;
+	scp->rproc = rproc;
+	scp->dev = dev;
+	platform_set_drvdata(pdev, scp);
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sram");
+	scp->sram_base = devm_ioremap(dev, res->start, resource_size(res));
+	if (IS_ERR(scp->sram_base))
+		return dev_err_probe(dev, PTR_ERR(scp->sram_base),
+				     "Failed to parse and map sram memory\n");
+
+	scp->sram_size = resource_size(res);
+	scp->sram_phys = res->start;
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cfg");
+	scp->reg_base = devm_ioremap(dev, res->start, resource_size(res));
+	if (IS_ERR(scp->reg_base))
+		return dev_err_probe(dev, PTR_ERR(scp->reg_base),
+				     "Failed to parse and map cfg memory\n");
+
+	mutex_init(&scp->send_lock);
+	for (i = 0; i < SCP_IPI_MAX; i++)
+		mutex_init(&scp->ipi_desc[i].lock);
+
+	init_waitqueue_head(&scp->run.wq);
+	init_waitqueue_head(&scp->ack_wq);
+
+	return 0;
+}
+
+static int scp_dual_remove(struct platform_device *pdev)
+{
+	struct mtk_scp *scp = platform_get_drvdata(pdev);
+	int i;
+
+	for (i = 0; i < SCP_IPI_MAX; i++)
+		mutex_destroy(&scp->ipi_desc[i].lock);
+	mutex_destroy(&scp->send_lock);
+
+	return 0;
+}
+
+static const struct of_device_id mtk_scp_dual_of_match[] = {
+	{ .compatible = "mediatek,mt8195-scp-dual" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, mtk_scp_dual_of_match);
+
+static struct platform_driver mtk_scp_dual_driver = {
+	.probe = scp_dual_probe,
+	.remove = scp_dual_remove,
+	.driver = {
+		.name = "mtk-scp-dual",
+		.of_match_table = mtk_scp_dual_of_match,
+	},
+};
+
+module_platform_driver(mtk_scp_dual_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("MediaTek SCP dualcore control driver");
-- 
2.18.0


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

[PATCH v1 06/15] remoteproc: mediatek: Add SCP core 1 rproc operations

[Tinghan Shen]

The firmware load and boot flow of SCP core 1 is almost the same as the
SCP core 0 except the accessed registers. Reuse the core 0 rproc operations
to load and boot SCP core 1.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_common.h   |  5 +++++
 drivers/remoteproc/mtk_scp.c      | 15 ++++++++++-----
 drivers/remoteproc/mtk_scp_dual.c |  8 +++++++-
 3 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index 2eadb0e696a1..2e46be605687 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -163,4 +163,9 @@ void scp_memcpy_aligned(void __iomem *dst, const void *src, unsigned int len);
 void scp_ipi_lock(struct mtk_scp *scp, u32 id);
 void scp_ipi_unlock(struct mtk_scp *scp, u32 id);
 
+int scp_start(struct rproc *rproc);
+int scp_stop(struct rproc *rproc);
+int scp_load(struct rproc *rproc, const struct firmware *fw);
+void *scp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem);
+int scp_parse_fw(struct rproc *rproc, const struct firmware *fw);
 #endif
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index 3510c6d0bbc8..7b9d12ec2d4f 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -470,7 +470,7 @@ static int mt8195_scp_before_load(struct mtk_scp *scp)
 	return 0;
 }
 
-static int scp_load(struct rproc *rproc, const struct firmware *fw)
+int scp_load(struct rproc *rproc, const struct firmware *fw)
 {
 	struct mtk_scp *scp = rproc->priv;
 	struct device *dev = scp->dev;
@@ -495,8 +495,9 @@ static int scp_load(struct rproc *rproc, const struct firmware *fw)
 
 	return ret;
 }
+EXPORT_SYMBOL_GPL(scp_load);
 
-static int scp_parse_fw(struct rproc *rproc, const struct firmware *fw)
+int scp_parse_fw(struct rproc *rproc, const struct firmware *fw)
 {
 	struct mtk_scp *scp = rproc->priv;
 	struct device *dev = scp->dev;
@@ -512,8 +513,9 @@ static int scp_parse_fw(struct rproc *rproc, const struct firmware *fw)
 	clk_disable_unprepare(scp->clk);
 	return ret;
 }
+EXPORT_SYMBOL_GPL(scp_parse_fw);
 
-static int scp_start(struct rproc *rproc)
+int scp_start(struct rproc *rproc)
 {
 	struct mtk_scp *scp = (struct mtk_scp *)rproc->priv;
 	struct device *dev = scp->dev;
@@ -555,6 +557,7 @@ static int scp_start(struct rproc *rproc)
 	clk_disable_unprepare(scp->clk);
 	return ret;
 }
+EXPORT_SYMBOL_GPL(scp_start);
 
 static void *mt8183_scp_da_to_va(struct mtk_scp *scp, u64 da, size_t len)
 {
@@ -602,12 +605,13 @@ static void *mt8192_scp_da_to_va(struct mtk_scp *scp, u64 da, size_t len)
 	return NULL;
 }
 
-static void *scp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
+void *scp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
 {
 	struct mtk_scp *scp = (struct mtk_scp *)rproc->priv;
 
 	return scp->data->scp_da_to_va(scp, da, len);
 }
+EXPORT_SYMBOL_GPL(scp_da_to_va);
 
 static void mt8183_scp_stop(struct mtk_scp *scp)
 {
@@ -642,7 +646,7 @@ static void mt8195_scp_stop(struct mtk_scp *scp)
 	writel(0, scp->reg_base + MT8192_CORE0_WDT_CFG);
 }
 
-static int scp_stop(struct rproc *rproc)
+int scp_stop(struct rproc *rproc)
 {
 	struct mtk_scp *scp = (struct mtk_scp *)rproc->priv;
 	int ret;
@@ -659,6 +663,7 @@ static int scp_stop(struct rproc *rproc)
 
 	return 0;
 }
+EXPORT_SYMBOL_GPL(scp_stop);
 
 static const struct rproc_ops scp_ops = {
 	.start		= scp_start,
diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index 7bc08d26f208..e4ada5696bd7 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -12,7 +12,13 @@
 #include "mtk_common.h"
 #include "remoteproc_internal.h"
 
-static const struct rproc_ops scp_ops;
+static const struct rproc_ops scp_ops = {
+	.start		= scp_start,
+	.stop		= scp_stop,
+	.load		= scp_load,
+	.da_to_va	= scp_da_to_va,
+	.parse_fw	= scp_parse_fw,
+};
 
 static int scp_dual_probe(struct platform_device *pdev)
 {
-- 
2.18.0

[PATCH v1 06/15] remoteproc: mediatek: Add SCP core 1 rproc operations

[Tinghan Shen]

The firmware load and boot flow of SCP core 1 is almost the same as the
SCP core 0 except the accessed registers. Reuse the core 0 rproc operations
to load and boot SCP core 1.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_common.h   |  5 +++++
 drivers/remoteproc/mtk_scp.c      | 15 ++++++++++-----
 drivers/remoteproc/mtk_scp_dual.c |  8 +++++++-
 3 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index 2eadb0e696a1..2e46be605687 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -163,4 +163,9 @@ void scp_memcpy_aligned(void __iomem *dst, const void *src, unsigned int len);
 void scp_ipi_lock(struct mtk_scp *scp, u32 id);
 void scp_ipi_unlock(struct mtk_scp *scp, u32 id);
 
+int scp_start(struct rproc *rproc);
+int scp_stop(struct rproc *rproc);
+int scp_load(struct rproc *rproc, const struct firmware *fw);
+void *scp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem);
+int scp_parse_fw(struct rproc *rproc, const struct firmware *fw);
 #endif
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index 3510c6d0bbc8..7b9d12ec2d4f 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -470,7 +470,7 @@ static int mt8195_scp_before_load(struct mtk_scp *scp)
 	return 0;
 }
 
-static int scp_load(struct rproc *rproc, const struct firmware *fw)
+int scp_load(struct rproc *rproc, const struct firmware *fw)
 {
 	struct mtk_scp *scp = rproc->priv;
 	struct device *dev = scp->dev;
@@ -495,8 +495,9 @@ static int scp_load(struct rproc *rproc, const struct firmware *fw)
 
 	return ret;
 }
+EXPORT_SYMBOL_GPL(scp_load);
 
-static int scp_parse_fw(struct rproc *rproc, const struct firmware *fw)
+int scp_parse_fw(struct rproc *rproc, const struct firmware *fw)
 {
 	struct mtk_scp *scp = rproc->priv;
 	struct device *dev = scp->dev;
@@ -512,8 +513,9 @@ static int scp_parse_fw(struct rproc *rproc, const struct firmware *fw)
 	clk_disable_unprepare(scp->clk);
 	return ret;
 }
+EXPORT_SYMBOL_GPL(scp_parse_fw);
 
-static int scp_start(struct rproc *rproc)
+int scp_start(struct rproc *rproc)
 {
 	struct mtk_scp *scp = (struct mtk_scp *)rproc->priv;
 	struct device *dev = scp->dev;
@@ -555,6 +557,7 @@ static int scp_start(struct rproc *rproc)
 	clk_disable_unprepare(scp->clk);
 	return ret;
 }
+EXPORT_SYMBOL_GPL(scp_start);
 
 static void *mt8183_scp_da_to_va(struct mtk_scp *scp, u64 da, size_t len)
 {
@@ -602,12 +605,13 @@ static void *mt8192_scp_da_to_va(struct mtk_scp *scp, u64 da, size_t len)
 	return NULL;
 }
 
-static void *scp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
+void *scp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
 {
 	struct mtk_scp *scp = (struct mtk_scp *)rproc->priv;
 
 	return scp->data->scp_da_to_va(scp, da, len);
 }
+EXPORT_SYMBOL_GPL(scp_da_to_va);
 
 static void mt8183_scp_stop(struct mtk_scp *scp)
 {
@@ -642,7 +646,7 @@ static void mt8195_scp_stop(struct mtk_scp *scp)
 	writel(0, scp->reg_base + MT8192_CORE0_WDT_CFG);
 }
 
-static int scp_stop(struct rproc *rproc)
+int scp_stop(struct rproc *rproc)
 {
 	struct mtk_scp *scp = (struct mtk_scp *)rproc->priv;
 	int ret;
@@ -659,6 +663,7 @@ static int scp_stop(struct rproc *rproc)
 
 	return 0;
 }
+EXPORT_SYMBOL_GPL(scp_stop);
 
 static const struct rproc_ops scp_ops = {
 	.start		= scp_start,
diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index 7bc08d26f208..e4ada5696bd7 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -12,7 +12,13 @@
 #include "mtk_common.h"
 #include "remoteproc_internal.h"
 
-static const struct rproc_ops scp_ops;
+static const struct rproc_ops scp_ops = {
+	.start		= scp_start,
+	.stop		= scp_stop,
+	.load		= scp_load,
+	.da_to_va	= scp_da_to_va,
+	.parse_fw	= scp_parse_fw,
+};
 
 static int scp_dual_probe(struct platform_device *pdev)
 {
-- 
2.18.0


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH v1 06/15] remoteproc: mediatek: Add SCP core 1 rproc operations

[Tinghan Shen]

The firmware load and boot flow of SCP core 1 is almost the same as the
SCP core 0 except the accessed registers. Reuse the core 0 rproc operations
to load and boot SCP core 1.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_common.h   |  5 +++++
 drivers/remoteproc/mtk_scp.c      | 15 ++++++++++-----
 drivers/remoteproc/mtk_scp_dual.c |  8 +++++++-
 3 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index 2eadb0e696a1..2e46be605687 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -163,4 +163,9 @@ void scp_memcpy_aligned(void __iomem *dst, const void *src, unsigned int len);
 void scp_ipi_lock(struct mtk_scp *scp, u32 id);
 void scp_ipi_unlock(struct mtk_scp *scp, u32 id);
 
+int scp_start(struct rproc *rproc);
+int scp_stop(struct rproc *rproc);
+int scp_load(struct rproc *rproc, const struct firmware *fw);
+void *scp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem);
+int scp_parse_fw(struct rproc *rproc, const struct firmware *fw);
 #endif
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index 3510c6d0bbc8..7b9d12ec2d4f 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -470,7 +470,7 @@ static int mt8195_scp_before_load(struct mtk_scp *scp)
 	return 0;
 }
 
-static int scp_load(struct rproc *rproc, const struct firmware *fw)
+int scp_load(struct rproc *rproc, const struct firmware *fw)
 {
 	struct mtk_scp *scp = rproc->priv;
 	struct device *dev = scp->dev;
@@ -495,8 +495,9 @@ static int scp_load(struct rproc *rproc, const struct firmware *fw)
 
 	return ret;
 }
+EXPORT_SYMBOL_GPL(scp_load);
 
-static int scp_parse_fw(struct rproc *rproc, const struct firmware *fw)
+int scp_parse_fw(struct rproc *rproc, const struct firmware *fw)
 {
 	struct mtk_scp *scp = rproc->priv;
 	struct device *dev = scp->dev;
@@ -512,8 +513,9 @@ static int scp_parse_fw(struct rproc *rproc, const struct firmware *fw)
 	clk_disable_unprepare(scp->clk);
 	return ret;
 }
+EXPORT_SYMBOL_GPL(scp_parse_fw);
 
-static int scp_start(struct rproc *rproc)
+int scp_start(struct rproc *rproc)
 {
 	struct mtk_scp *scp = (struct mtk_scp *)rproc->priv;
 	struct device *dev = scp->dev;
@@ -555,6 +557,7 @@ static int scp_start(struct rproc *rproc)
 	clk_disable_unprepare(scp->clk);
 	return ret;
 }
+EXPORT_SYMBOL_GPL(scp_start);
 
 static void *mt8183_scp_da_to_va(struct mtk_scp *scp, u64 da, size_t len)
 {
@@ -602,12 +605,13 @@ static void *mt8192_scp_da_to_va(struct mtk_scp *scp, u64 da, size_t len)
 	return NULL;
 }
 
-static void *scp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
+void *scp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem)
 {
 	struct mtk_scp *scp = (struct mtk_scp *)rproc->priv;
 
 	return scp->data->scp_da_to_va(scp, da, len);
 }
+EXPORT_SYMBOL_GPL(scp_da_to_va);
 
 static void mt8183_scp_stop(struct mtk_scp *scp)
 {
@@ -642,7 +646,7 @@ static void mt8195_scp_stop(struct mtk_scp *scp)
 	writel(0, scp->reg_base + MT8192_CORE0_WDT_CFG);
 }
 
-static int scp_stop(struct rproc *rproc)
+int scp_stop(struct rproc *rproc)
 {
 	struct mtk_scp *scp = (struct mtk_scp *)rproc->priv;
 	int ret;
@@ -659,6 +663,7 @@ static int scp_stop(struct rproc *rproc)
 
 	return 0;
 }
+EXPORT_SYMBOL_GPL(scp_stop);
 
 static const struct rproc_ops scp_ops = {
 	.start		= scp_start,
diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index 7bc08d26f208..e4ada5696bd7 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -12,7 +12,13 @@
 #include "mtk_common.h"
 #include "remoteproc_internal.h"
 
-static const struct rproc_ops scp_ops;
+static const struct rproc_ops scp_ops = {
+	.start		= scp_start,
+	.stop		= scp_stop,
+	.load		= scp_load,
+	.da_to_va	= scp_da_to_va,
+	.parse_fw	= scp_parse_fw,
+};
 
 static int scp_dual_probe(struct platform_device *pdev)
 {
-- 
2.18.0


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

[PATCH v1 07/15] remoteproc: mediatek: Add SCP core 1 reserved memory support

[Tinghan Shen]

Reuse the SCP core 0 reserved memory API on SCP core 1.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_common.h   | 2 ++
 drivers/remoteproc/mtk_scp.c      | 6 ++++--
 drivers/remoteproc/mtk_scp_dual.c | 5 +++++
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index 2e46be605687..da3ea2243678 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -168,4 +168,6 @@ int scp_stop(struct rproc *rproc);
 int scp_load(struct rproc *rproc, const struct firmware *fw);
 void *scp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem);
 int scp_parse_fw(struct rproc *rproc, const struct firmware *fw);
+int scp_map_memory_region(struct mtk_scp *scp);
+void scp_unmap_memory_region(struct mtk_scp *scp);
 #endif
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index 7b9d12ec2d4f..75d161da0f59 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -747,7 +747,7 @@ void *scp_mapping_dm_addr(struct mtk_scp *scp, u32 mem_addr)
 }
 EXPORT_SYMBOL_GPL(scp_mapping_dm_addr);
 
-static int scp_map_memory_region(struct mtk_scp *scp)
+int scp_map_memory_region(struct mtk_scp *scp)
 {
 	int ret;
 
@@ -773,8 +773,9 @@ static int scp_map_memory_region(struct mtk_scp *scp)
 
 	return 0;
 }
+EXPORT_SYMBOL_GPL(scp_map_memory_region);
 
-static void scp_unmap_memory_region(struct mtk_scp *scp)
+void scp_unmap_memory_region(struct mtk_scp *scp)
 {
 	if (scp->dram_size == 0)
 		return;
@@ -783,6 +784,7 @@ static void scp_unmap_memory_region(struct mtk_scp *scp)
 			  scp->dma_addr);
 	of_reserved_mem_device_release(scp->dev);
 }
+EXPORT_SYMBOL_GPL(scp_unmap_memory_region);
 
 static int scp_register_ipi(struct platform_device *pdev, u32 id,
 			    ipi_handler_t handler, void *priv)
diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index e4ada5696bd7..0f932d26f864 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -60,6 +60,10 @@ static int scp_dual_probe(struct platform_device *pdev)
 		return dev_err_probe(dev, PTR_ERR(scp->reg_base),
 				     "Failed to parse and map cfg memory\n");
 
+	ret = scp_map_memory_region(scp);
+	if (ret)
+		return ret;
+
 	mutex_init(&scp->send_lock);
 	for (i = 0; i < SCP_IPI_MAX; i++)
 		mutex_init(&scp->ipi_desc[i].lock);
@@ -75,6 +79,7 @@ static int scp_dual_remove(struct platform_device *pdev)
 	struct mtk_scp *scp = platform_get_drvdata(pdev);
 	int i;
 
+	scp_unmap_memory_region(scp);
 	for (i = 0; i < SCP_IPI_MAX; i++)
 		mutex_destroy(&scp->ipi_desc[i].lock);
 	mutex_destroy(&scp->send_lock);
-- 
2.18.0

[PATCH v1 07/15] remoteproc: mediatek: Add SCP core 1 reserved memory support

[Tinghan Shen]

Reuse the SCP core 0 reserved memory API on SCP core 1.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_common.h   | 2 ++
 drivers/remoteproc/mtk_scp.c      | 6 ++++--
 drivers/remoteproc/mtk_scp_dual.c | 5 +++++
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index 2e46be605687..da3ea2243678 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -168,4 +168,6 @@ int scp_stop(struct rproc *rproc);
 int scp_load(struct rproc *rproc, const struct firmware *fw);
 void *scp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem);
 int scp_parse_fw(struct rproc *rproc, const struct firmware *fw);
+int scp_map_memory_region(struct mtk_scp *scp);
+void scp_unmap_memory_region(struct mtk_scp *scp);
 #endif
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index 7b9d12ec2d4f..75d161da0f59 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -747,7 +747,7 @@ void *scp_mapping_dm_addr(struct mtk_scp *scp, u32 mem_addr)
 }
 EXPORT_SYMBOL_GPL(scp_mapping_dm_addr);
 
-static int scp_map_memory_region(struct mtk_scp *scp)
+int scp_map_memory_region(struct mtk_scp *scp)
 {
 	int ret;
 
@@ -773,8 +773,9 @@ static int scp_map_memory_region(struct mtk_scp *scp)
 
 	return 0;
 }
+EXPORT_SYMBOL_GPL(scp_map_memory_region);
 
-static void scp_unmap_memory_region(struct mtk_scp *scp)
+void scp_unmap_memory_region(struct mtk_scp *scp)
 {
 	if (scp->dram_size == 0)
 		return;
@@ -783,6 +784,7 @@ static void scp_unmap_memory_region(struct mtk_scp *scp)
 			  scp->dma_addr);
 	of_reserved_mem_device_release(scp->dev);
 }
+EXPORT_SYMBOL_GPL(scp_unmap_memory_region);
 
 static int scp_register_ipi(struct platform_device *pdev, u32 id,
 			    ipi_handler_t handler, void *priv)
diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index e4ada5696bd7..0f932d26f864 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -60,6 +60,10 @@ static int scp_dual_probe(struct platform_device *pdev)
 		return dev_err_probe(dev, PTR_ERR(scp->reg_base),
 				     "Failed to parse and map cfg memory\n");
 
+	ret = scp_map_memory_region(scp);
+	if (ret)
+		return ret;
+
 	mutex_init(&scp->send_lock);
 	for (i = 0; i < SCP_IPI_MAX; i++)
 		mutex_init(&scp->ipi_desc[i].lock);
@@ -75,6 +79,7 @@ static int scp_dual_remove(struct platform_device *pdev)
 	struct mtk_scp *scp = platform_get_drvdata(pdev);
 	int i;
 
+	scp_unmap_memory_region(scp);
 	for (i = 0; i < SCP_IPI_MAX; i++)
 		mutex_destroy(&scp->ipi_desc[i].lock);
 	mutex_destroy(&scp->send_lock);
-- 
2.18.0


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH v1 07/15] remoteproc: mediatek: Add SCP core 1 reserved memory support

[Tinghan Shen]

Reuse the SCP core 0 reserved memory API on SCP core 1.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_common.h   | 2 ++
 drivers/remoteproc/mtk_scp.c      | 6 ++++--
 drivers/remoteproc/mtk_scp_dual.c | 5 +++++
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index 2e46be605687..da3ea2243678 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -168,4 +168,6 @@ int scp_stop(struct rproc *rproc);
 int scp_load(struct rproc *rproc, const struct firmware *fw);
 void *scp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem);
 int scp_parse_fw(struct rproc *rproc, const struct firmware *fw);
+int scp_map_memory_region(struct mtk_scp *scp);
+void scp_unmap_memory_region(struct mtk_scp *scp);
 #endif
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index 7b9d12ec2d4f..75d161da0f59 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -747,7 +747,7 @@ void *scp_mapping_dm_addr(struct mtk_scp *scp, u32 mem_addr)
 }
 EXPORT_SYMBOL_GPL(scp_mapping_dm_addr);
 
-static int scp_map_memory_region(struct mtk_scp *scp)
+int scp_map_memory_region(struct mtk_scp *scp)
 {
 	int ret;
 
@@ -773,8 +773,9 @@ static int scp_map_memory_region(struct mtk_scp *scp)
 
 	return 0;
 }
+EXPORT_SYMBOL_GPL(scp_map_memory_region);
 
-static void scp_unmap_memory_region(struct mtk_scp *scp)
+void scp_unmap_memory_region(struct mtk_scp *scp)
 {
 	if (scp->dram_size == 0)
 		return;
@@ -783,6 +784,7 @@ static void scp_unmap_memory_region(struct mtk_scp *scp)
 			  scp->dma_addr);
 	of_reserved_mem_device_release(scp->dev);
 }
+EXPORT_SYMBOL_GPL(scp_unmap_memory_region);
 
 static int scp_register_ipi(struct platform_device *pdev, u32 id,
 			    ipi_handler_t handler, void *priv)
diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index e4ada5696bd7..0f932d26f864 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -60,6 +60,10 @@ static int scp_dual_probe(struct platform_device *pdev)
 		return dev_err_probe(dev, PTR_ERR(scp->reg_base),
 				     "Failed to parse and map cfg memory\n");
 
+	ret = scp_map_memory_region(scp);
+	if (ret)
+		return ret;
+
 	mutex_init(&scp->send_lock);
 	for (i = 0; i < SCP_IPI_MAX; i++)
 		mutex_init(&scp->ipi_desc[i].lock);
@@ -75,6 +79,7 @@ static int scp_dual_remove(struct platform_device *pdev)
 	struct mtk_scp *scp = platform_get_drvdata(pdev);
 	int i;
 
+	scp_unmap_memory_region(scp);
 	for (i = 0; i < SCP_IPI_MAX; i++)
 		mutex_destroy(&scp->ipi_desc[i].lock);
 	mutex_destroy(&scp->send_lock);
-- 
2.18.0


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

[PATCH v1 08/15] remoteproc: mediatek: Add SCP core 1 interrupt support

[Tinghan Shen]

Reuse the interrupt handling API of SCP core 0 on SCP core 1.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_common.h   |  1 +
 drivers/remoteproc/mtk_scp.c      |  3 ++-
 drivers/remoteproc/mtk_scp_dual.c | 17 +++++++++++++++++
 3 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index da3ea2243678..04f7ee590f96 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -170,4 +170,5 @@ void *scp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem);
 int scp_parse_fw(struct rproc *rproc, const struct firmware *fw);
 int scp_map_memory_region(struct mtk_scp *scp);
 void scp_unmap_memory_region(struct mtk_scp *scp);
+irqreturn_t scp_irq_handler(int irq, void *priv);
 #endif
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index 75d161da0f59..c67883c28a43 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -237,7 +237,7 @@ static void mt8195_scp_irq_handler(struct mtk_scp *scp)
 	}
 }
 
-static irqreturn_t scp_irq_handler(int irq, void *priv)
+irqreturn_t scp_irq_handler(int irq, void *priv)
 {
 	struct mtk_scp *scp = priv;
 	int ret;
@@ -254,6 +254,7 @@ static irqreturn_t scp_irq_handler(int irq, void *priv)
 
 	return IRQ_HANDLED;
 }
+EXPORT_SYMBOL_GPL(scp_irq_handler);
 
 static int scp_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
 {
diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index 0f932d26f864..7bed39722bd5 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -71,7 +71,24 @@ static int scp_dual_probe(struct platform_device *pdev)
 	init_waitqueue_head(&scp->run.wq);
 	init_waitqueue_head(&scp->ack_wq);
 
+	ret = devm_request_threaded_irq(dev, platform_get_irq(pdev, 0), NULL,
+					scp_irq_handler, IRQF_ONESHOT,
+					pdev->name, scp);
+
+	if (ret) {
+		dev_err(dev, "failed to request irq\n");
+		goto release_dev_mem;
+	}
+
 	return 0;
+
+release_dev_mem:
+	scp_unmap_memory_region(scp);
+	for (i = 0; i < SCP_IPI_MAX; i++)
+		mutex_destroy(&scp->ipi_desc[i].lock);
+	mutex_destroy(&scp->send_lock);
+
+	return ret;
 }
 
 static int scp_dual_remove(struct platform_device *pdev)
-- 
2.18.0

[PATCH v1 08/15] remoteproc: mediatek: Add SCP core 1 interrupt support

[Tinghan Shen]

Reuse the interrupt handling API of SCP core 0 on SCP core 1.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_common.h   |  1 +
 drivers/remoteproc/mtk_scp.c      |  3 ++-
 drivers/remoteproc/mtk_scp_dual.c | 17 +++++++++++++++++
 3 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index da3ea2243678..04f7ee590f96 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -170,4 +170,5 @@ void *scp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem);
 int scp_parse_fw(struct rproc *rproc, const struct firmware *fw);
 int scp_map_memory_region(struct mtk_scp *scp);
 void scp_unmap_memory_region(struct mtk_scp *scp);
+irqreturn_t scp_irq_handler(int irq, void *priv);
 #endif
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index 75d161da0f59..c67883c28a43 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -237,7 +237,7 @@ static void mt8195_scp_irq_handler(struct mtk_scp *scp)
 	}
 }
 
-static irqreturn_t scp_irq_handler(int irq, void *priv)
+irqreturn_t scp_irq_handler(int irq, void *priv)
 {
 	struct mtk_scp *scp = priv;
 	int ret;
@@ -254,6 +254,7 @@ static irqreturn_t scp_irq_handler(int irq, void *priv)
 
 	return IRQ_HANDLED;
 }
+EXPORT_SYMBOL_GPL(scp_irq_handler);
 
 static int scp_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
 {
diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index 0f932d26f864..7bed39722bd5 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -71,7 +71,24 @@ static int scp_dual_probe(struct platform_device *pdev)
 	init_waitqueue_head(&scp->run.wq);
 	init_waitqueue_head(&scp->ack_wq);
 
+	ret = devm_request_threaded_irq(dev, platform_get_irq(pdev, 0), NULL,
+					scp_irq_handler, IRQF_ONESHOT,
+					pdev->name, scp);
+
+	if (ret) {
+		dev_err(dev, "failed to request irq\n");
+		goto release_dev_mem;
+	}
+
 	return 0;
+
+release_dev_mem:
+	scp_unmap_memory_region(scp);
+	for (i = 0; i < SCP_IPI_MAX; i++)
+		mutex_destroy(&scp->ipi_desc[i].lock);
+	mutex_destroy(&scp->send_lock);
+
+	return ret;
 }
 
 static int scp_dual_remove(struct platform_device *pdev)
-- 
2.18.0


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH v1 08/15] remoteproc: mediatek: Add SCP core 1 interrupt support

[Tinghan Shen]

Reuse the interrupt handling API of SCP core 0 on SCP core 1.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_common.h   |  1 +
 drivers/remoteproc/mtk_scp.c      |  3 ++-
 drivers/remoteproc/mtk_scp_dual.c | 17 +++++++++++++++++
 3 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index da3ea2243678..04f7ee590f96 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -170,4 +170,5 @@ void *scp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem);
 int scp_parse_fw(struct rproc *rproc, const struct firmware *fw);
 int scp_map_memory_region(struct mtk_scp *scp);
 void scp_unmap_memory_region(struct mtk_scp *scp);
+irqreturn_t scp_irq_handler(int irq, void *priv);
 #endif
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index 75d161da0f59..c67883c28a43 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -237,7 +237,7 @@ static void mt8195_scp_irq_handler(struct mtk_scp *scp)
 	}
 }
 
-static irqreturn_t scp_irq_handler(int irq, void *priv)
+irqreturn_t scp_irq_handler(int irq, void *priv)
 {
 	struct mtk_scp *scp = priv;
 	int ret;
@@ -254,6 +254,7 @@ static irqreturn_t scp_irq_handler(int irq, void *priv)
 
 	return IRQ_HANDLED;
 }
+EXPORT_SYMBOL_GPL(scp_irq_handler);
 
 static int scp_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
 {
diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index 0f932d26f864..7bed39722bd5 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -71,7 +71,24 @@ static int scp_dual_probe(struct platform_device *pdev)
 	init_waitqueue_head(&scp->run.wq);
 	init_waitqueue_head(&scp->ack_wq);
 
+	ret = devm_request_threaded_irq(dev, platform_get_irq(pdev, 0), NULL,
+					scp_irq_handler, IRQF_ONESHOT,
+					pdev->name, scp);
+
+	if (ret) {
+		dev_err(dev, "failed to request irq\n");
+		goto release_dev_mem;
+	}
+
 	return 0;
+
+release_dev_mem:
+	scp_unmap_memory_region(scp);
+	for (i = 0; i < SCP_IPI_MAX; i++)
+		mutex_destroy(&scp->ipi_desc[i].lock);
+	mutex_destroy(&scp->send_lock);
+
+	return ret;
 }
 
 static int scp_dual_remove(struct platform_device *pdev)
-- 
2.18.0


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

[PATCH v1 09/15] remoteproc: mediatek: Register SCP core 1 initialization ipi

[Tinghan Shen]

The SCP core 1 doesn't have vdec/venc functions like SCP core 0.
Remove usage of venc/vdec parameters.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_scp_dual.c | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index 7bed39722bd5..d4cc15e22640 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -20,6 +20,16 @@ static const struct rproc_ops scp_ops = {
 	.parse_fw	= scp_parse_fw,
 };
 
+static void scp_init_ipi_handler(void *data, unsigned int len, void *priv)
+{
+	struct mtk_scp *scp = (struct mtk_scp *)priv;
+	struct scp_run *run = (struct scp_run *)data;
+
+	scp->run.signaled = run->signaled;
+	strscpy(scp->run.fw_ver, run->fw_ver, SCP_FW_VER_LEN);
+	wake_up_interruptible(&scp->run.wq);
+}
+
 static int scp_dual_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -68,6 +78,13 @@ static int scp_dual_probe(struct platform_device *pdev)
 	for (i = 0; i < SCP_IPI_MAX; i++)
 		mutex_init(&scp->ipi_desc[i].lock);
 
+	/* register SCP initialization IPI */
+	ret = scp_ipi_register(scp, SCP_IPI_INIT, scp_init_ipi_handler, scp);
+	if (ret) {
+		dev_err(dev, "Failed to register IPI_SCP_INIT\n");
+		goto release_dev_mem;
+	}
+
 	init_waitqueue_head(&scp->run.wq);
 	init_waitqueue_head(&scp->ack_wq);
 
@@ -77,11 +94,13 @@ static int scp_dual_probe(struct platform_device *pdev)
 
 	if (ret) {
 		dev_err(dev, "failed to request irq\n");
-		goto release_dev_mem;
+		goto remove_ipi;
 	}
 
 	return 0;
 
+remove_ipi:
+	scp_ipi_unregister(scp, SCP_IPI_INIT);
 release_dev_mem:
 	scp_unmap_memory_region(scp);
 	for (i = 0; i < SCP_IPI_MAX; i++)
@@ -96,6 +115,7 @@ static int scp_dual_remove(struct platform_device *pdev)
 	struct mtk_scp *scp = platform_get_drvdata(pdev);
 	int i;
 
+	scp_ipi_unregister(scp, SCP_IPI_INIT);
 	scp_unmap_memory_region(scp);
 	for (i = 0; i < SCP_IPI_MAX; i++)
 		mutex_destroy(&scp->ipi_desc[i].lock);
-- 
2.18.0

[PATCH v1 09/15] remoteproc: mediatek: Register SCP core 1 initialization ipi

[Tinghan Shen]

The SCP core 1 doesn't have vdec/venc functions like SCP core 0.
Remove usage of venc/vdec parameters.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_scp_dual.c | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index 7bed39722bd5..d4cc15e22640 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -20,6 +20,16 @@ static const struct rproc_ops scp_ops = {
 	.parse_fw	= scp_parse_fw,
 };
 
+static void scp_init_ipi_handler(void *data, unsigned int len, void *priv)
+{
+	struct mtk_scp *scp = (struct mtk_scp *)priv;
+	struct scp_run *run = (struct scp_run *)data;
+
+	scp->run.signaled = run->signaled;
+	strscpy(scp->run.fw_ver, run->fw_ver, SCP_FW_VER_LEN);
+	wake_up_interruptible(&scp->run.wq);
+}
+
 static int scp_dual_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -68,6 +78,13 @@ static int scp_dual_probe(struct platform_device *pdev)
 	for (i = 0; i < SCP_IPI_MAX; i++)
 		mutex_init(&scp->ipi_desc[i].lock);
 
+	/* register SCP initialization IPI */
+	ret = scp_ipi_register(scp, SCP_IPI_INIT, scp_init_ipi_handler, scp);
+	if (ret) {
+		dev_err(dev, "Failed to register IPI_SCP_INIT\n");
+		goto release_dev_mem;
+	}
+
 	init_waitqueue_head(&scp->run.wq);
 	init_waitqueue_head(&scp->ack_wq);
 
@@ -77,11 +94,13 @@ static int scp_dual_probe(struct platform_device *pdev)
 
 	if (ret) {
 		dev_err(dev, "failed to request irq\n");
-		goto release_dev_mem;
+		goto remove_ipi;
 	}
 
 	return 0;
 
+remove_ipi:
+	scp_ipi_unregister(scp, SCP_IPI_INIT);
 release_dev_mem:
 	scp_unmap_memory_region(scp);
 	for (i = 0; i < SCP_IPI_MAX; i++)
@@ -96,6 +115,7 @@ static int scp_dual_remove(struct platform_device *pdev)
 	struct mtk_scp *scp = platform_get_drvdata(pdev);
 	int i;
 
+	scp_ipi_unregister(scp, SCP_IPI_INIT);
 	scp_unmap_memory_region(scp);
 	for (i = 0; i < SCP_IPI_MAX; i++)
 		mutex_destroy(&scp->ipi_desc[i].lock);
-- 
2.18.0


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH v1 09/15] remoteproc: mediatek: Register SCP core 1 initialization ipi

[Tinghan Shen]

The SCP core 1 doesn't have vdec/venc functions like SCP core 0.
Remove usage of venc/vdec parameters.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_scp_dual.c | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index 7bed39722bd5..d4cc15e22640 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -20,6 +20,16 @@ static const struct rproc_ops scp_ops = {
 	.parse_fw	= scp_parse_fw,
 };
 
+static void scp_init_ipi_handler(void *data, unsigned int len, void *priv)
+{
+	struct mtk_scp *scp = (struct mtk_scp *)priv;
+	struct scp_run *run = (struct scp_run *)data;
+
+	scp->run.signaled = run->signaled;
+	strscpy(scp->run.fw_ver, run->fw_ver, SCP_FW_VER_LEN);
+	wake_up_interruptible(&scp->run.wq);
+}
+
 static int scp_dual_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -68,6 +78,13 @@ static int scp_dual_probe(struct platform_device *pdev)
 	for (i = 0; i < SCP_IPI_MAX; i++)
 		mutex_init(&scp->ipi_desc[i].lock);
 
+	/* register SCP initialization IPI */
+	ret = scp_ipi_register(scp, SCP_IPI_INIT, scp_init_ipi_handler, scp);
+	if (ret) {
+		dev_err(dev, "Failed to register IPI_SCP_INIT\n");
+		goto release_dev_mem;
+	}
+
 	init_waitqueue_head(&scp->run.wq);
 	init_waitqueue_head(&scp->ack_wq);
 
@@ -77,11 +94,13 @@ static int scp_dual_probe(struct platform_device *pdev)
 
 	if (ret) {
 		dev_err(dev, "failed to request irq\n");
-		goto release_dev_mem;
+		goto remove_ipi;
 	}
 
 	return 0;
 
+remove_ipi:
+	scp_ipi_unregister(scp, SCP_IPI_INIT);
 release_dev_mem:
 	scp_unmap_memory_region(scp);
 	for (i = 0; i < SCP_IPI_MAX; i++)
@@ -96,6 +115,7 @@ static int scp_dual_remove(struct platform_device *pdev)
 	struct mtk_scp *scp = platform_get_drvdata(pdev);
 	int i;
 
+	scp_ipi_unregister(scp, SCP_IPI_INIT);
 	scp_unmap_memory_region(scp);
 	for (i = 0; i < SCP_IPI_MAX; i++)
 		mutex_destroy(&scp->ipi_desc[i].lock);
-- 
2.18.0


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

[PATCH v1 10/15] remoteproc: mediatek: Add chip dependent operations for SCP core 1

[Tinghan Shen]

The SCP rproc operations has chip dependent callbacks. Implement a
version of these callbacks for MT8195 SCP core 1.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_common.h   |   1 +
 drivers/remoteproc/mtk_scp.c      |   3 +-
 drivers/remoteproc/mtk_scp_dual.c | 121 +++++++++++++++++++++++++++++-
 3 files changed, 123 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index 04f7ee590f96..7b363411ec99 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -171,4 +171,5 @@ int scp_parse_fw(struct rproc *rproc, const struct firmware *fw);
 int scp_map_memory_region(struct mtk_scp *scp);
 void scp_unmap_memory_region(struct mtk_scp *scp);
 irqreturn_t scp_irq_handler(int irq, void *priv);
+void scp_ipi_handler(struct mtk_scp *scp);
 #endif
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index c67883c28a43..55bc4e9d1a6f 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -84,7 +84,7 @@ static void scp_init_ipi_handler(void *data, unsigned int len, void *priv)
 	wake_up_interruptible(&scp->run.wq);
 }
 
-static void scp_ipi_handler(struct mtk_scp *scp)
+void scp_ipi_handler(struct mtk_scp *scp)
 {
 	struct mtk_share_obj __iomem *rcv_obj = scp->recv_buf;
 	struct scp_ipi_desc *ipi_desc = scp->ipi_desc;
@@ -118,6 +118,7 @@ static void scp_ipi_handler(struct mtk_scp *scp)
 	scp->ipi_id_ack[id] = true;
 	wake_up(&scp->ack_wq);
 }
+EXPORT_SYMBOL_GPL(scp_ipi_handler);
 
 static int scp_elf_read_ipi_buf_addr(struct mtk_scp *scp,
 				     const struct firmware *fw,
diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index d4cc15e22640..16cf9d2628c8 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -12,6 +12,124 @@
 #include "mtk_common.h"
 #include "remoteproc_internal.h"
 
+static void mt8195_power_on_sram(void __iomem *addr)
+{
+	int i;
+
+	for (i = 31; i >= 0; i--)
+		writel(GENMASK(i, 0), addr);
+	writel(0, addr);
+}
+
+static void mt8195_power_off_sram(void __iomem *addr)
+{
+	int i;
+
+	writel(0, addr);
+	for (i = 0; i < 32; i++)
+		writel(GENMASK(i, 0), addr);
+}
+
+static int mt8195_scp_dual_before_load(struct mtk_scp *scp)
+{
+	u32 sec_ctrl;
+
+	mt8195_power_on_sram(scp->reg_base + MT8195_CPU1_SRAM_PD);
+
+	/* hold SCP in reset while loading FW. */
+	scp->data->scp_reset_assert(scp);
+
+	/* enable MPU for all memory regions */
+	writel(0xff, scp->reg_base + MT8195_CORE1_MEM_ATT_PREDEF);
+
+	return 0;
+}
+
+static void mt8195_scp_dual_irq_handler(struct mtk_scp *scp)
+{
+	u32 scp_to_host;
+
+	scp_to_host = readl(scp->reg_base + MT8195_SSHUB2APMCU_IPC_SET);
+
+	if (scp_to_host & MT8192_SCP_IPC_INT_BIT) {
+		scp_ipi_handler(scp);
+
+		/*
+		 * SCP won't send another interrupt until we clear
+		 * MT8195_SSHUB2APMCU_IPC_CLR.
+		 */
+		writel(MT8192_SCP_IPC_INT_BIT,
+		       scp->reg_base + MT8195_SSHUB2APMCU_IPC_CLR);
+	}
+}
+
+static void mt8195_scp_dual_reset_assert(struct mtk_scp *scp)
+{
+	writel(1, scp->reg_base + MT8195_CORE1_SW_RSTN_SET);
+}
+
+static void mt8195_scp_dual_reset_deassert(struct mtk_scp *scp)
+{
+	writel(1, scp->reg_base + MT8195_CORE1_SW_RSTN_CLR);
+}
+
+static void *mt8195_scp_dual_da_to_va(struct mtk_scp *scp, u64 da, size_t len)
+{
+	int offset;
+
+	if (da >= scp->sram_phys &&
+	    (da + len) <= scp->sram_phys + scp->sram_size) {
+		offset = da - scp->sram_phys;
+		return (void __force *)scp->sram_base + offset;
+	}
+
+	/* optional memory region */
+	if (scp->l1tcm_size &&
+	    da >= scp->l1tcm_phys &&
+	    (da + len) <= scp->l1tcm_phys + scp->l1tcm_size) {
+		offset = da - scp->l1tcm_phys;
+		return (void __force *)scp->l1tcm_base + offset;
+	}
+
+	/* optional memory region */
+	if (scp->dram_size &&
+	    da >= scp->dma_addr &&
+	    (da + len) <= scp->dma_addr + scp->dram_size) {
+		offset = da - scp->dma_addr;
+		return scp->cpu_addr + offset;
+	}
+
+	return NULL;
+}
+
+static void mt8195_scp_dual_stop(struct mtk_scp *scp)
+{
+	/* Power off CPU SRAM */
+	mt8195_power_off_sram(scp->reg_base + MT8195_CPU1_SRAM_PD);
+
+	/* Disable SCP watchdog */
+	writel(0, scp->reg_base + MT8195_CORE1_WDT_CFG);
+}
+
+static int mt8195_scp_dual_clk_get(struct mtk_scp *scp)
+{
+	scp->clk = NULL;
+
+	return 0;
+}
+
+static const struct mtk_scp_of_data mt8195_scp_dual_of_data = {
+	.scp_clk_get = mt8195_scp_dual_clk_get,
+	.scp_before_load = mt8195_scp_dual_before_load,
+	.scp_irq_handler = mt8195_scp_dual_irq_handler,
+	.scp_reset_assert = mt8195_scp_dual_reset_assert,
+	.scp_reset_deassert = mt8195_scp_dual_reset_deassert,
+	.scp_stop = mt8195_scp_dual_stop,
+	.scp_da_to_va = mt8195_scp_dual_da_to_va,
+	.host_to_scp_reg = MT8192_GIPC_IN_SET,
+	.host_to_scp_int_bit = MT8195_HOST_IPC_INT_BIT,
+};
+
 static const struct rproc_ops scp_ops = {
 	.start		= scp_start,
 	.stop		= scp_stop,
@@ -53,6 +171,7 @@ static int scp_dual_probe(struct platform_device *pdev)
 	scp = (struct mtk_scp *)rproc->priv;
 	scp->rproc = rproc;
 	scp->dev = dev;
+	scp->data = of_device_get_match_data(dev);
 	platform_set_drvdata(pdev, scp);
 
 	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sram");
@@ -125,7 +244,7 @@ static int scp_dual_remove(struct platform_device *pdev)
 }
 
 static const struct of_device_id mtk_scp_dual_of_match[] = {
-	{ .compatible = "mediatek,mt8195-scp-dual" },
+	{ .compatible = "mediatek,mt8195-scp-dual", .data = &mt8195_scp_dual_of_data },
 	{},
 };
 MODULE_DEVICE_TABLE(of, mtk_scp_dual_of_match);
-- 
2.18.0

[PATCH v1 10/15] remoteproc: mediatek: Add chip dependent operations for SCP core 1

[Tinghan Shen]

The SCP rproc operations has chip dependent callbacks. Implement a
version of these callbacks for MT8195 SCP core 1.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_common.h   |   1 +
 drivers/remoteproc/mtk_scp.c      |   3 +-
 drivers/remoteproc/mtk_scp_dual.c | 121 +++++++++++++++++++++++++++++-
 3 files changed, 123 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index 04f7ee590f96..7b363411ec99 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -171,4 +171,5 @@ int scp_parse_fw(struct rproc *rproc, const struct firmware *fw);
 int scp_map_memory_region(struct mtk_scp *scp);
 void scp_unmap_memory_region(struct mtk_scp *scp);
 irqreturn_t scp_irq_handler(int irq, void *priv);
+void scp_ipi_handler(struct mtk_scp *scp);
 #endif
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index c67883c28a43..55bc4e9d1a6f 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -84,7 +84,7 @@ static void scp_init_ipi_handler(void *data, unsigned int len, void *priv)
 	wake_up_interruptible(&scp->run.wq);
 }
 
-static void scp_ipi_handler(struct mtk_scp *scp)
+void scp_ipi_handler(struct mtk_scp *scp)
 {
 	struct mtk_share_obj __iomem *rcv_obj = scp->recv_buf;
 	struct scp_ipi_desc *ipi_desc = scp->ipi_desc;
@@ -118,6 +118,7 @@ static void scp_ipi_handler(struct mtk_scp *scp)
 	scp->ipi_id_ack[id] = true;
 	wake_up(&scp->ack_wq);
 }
+EXPORT_SYMBOL_GPL(scp_ipi_handler);
 
 static int scp_elf_read_ipi_buf_addr(struct mtk_scp *scp,
 				     const struct firmware *fw,
diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index d4cc15e22640..16cf9d2628c8 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -12,6 +12,124 @@
 #include "mtk_common.h"
 #include "remoteproc_internal.h"
 
+static void mt8195_power_on_sram(void __iomem *addr)
+{
+	int i;
+
+	for (i = 31; i >= 0; i--)
+		writel(GENMASK(i, 0), addr);
+	writel(0, addr);
+}
+
+static void mt8195_power_off_sram(void __iomem *addr)
+{
+	int i;
+
+	writel(0, addr);
+	for (i = 0; i < 32; i++)
+		writel(GENMASK(i, 0), addr);
+}
+
+static int mt8195_scp_dual_before_load(struct mtk_scp *scp)
+{
+	u32 sec_ctrl;
+
+	mt8195_power_on_sram(scp->reg_base + MT8195_CPU1_SRAM_PD);
+
+	/* hold SCP in reset while loading FW. */
+	scp->data->scp_reset_assert(scp);
+
+	/* enable MPU for all memory regions */
+	writel(0xff, scp->reg_base + MT8195_CORE1_MEM_ATT_PREDEF);
+
+	return 0;
+}
+
+static void mt8195_scp_dual_irq_handler(struct mtk_scp *scp)
+{
+	u32 scp_to_host;
+
+	scp_to_host = readl(scp->reg_base + MT8195_SSHUB2APMCU_IPC_SET);
+
+	if (scp_to_host & MT8192_SCP_IPC_INT_BIT) {
+		scp_ipi_handler(scp);
+
+		/*
+		 * SCP won't send another interrupt until we clear
+		 * MT8195_SSHUB2APMCU_IPC_CLR.
+		 */
+		writel(MT8192_SCP_IPC_INT_BIT,
+		       scp->reg_base + MT8195_SSHUB2APMCU_IPC_CLR);
+	}
+}
+
+static void mt8195_scp_dual_reset_assert(struct mtk_scp *scp)
+{
+	writel(1, scp->reg_base + MT8195_CORE1_SW_RSTN_SET);
+}
+
+static void mt8195_scp_dual_reset_deassert(struct mtk_scp *scp)
+{
+	writel(1, scp->reg_base + MT8195_CORE1_SW_RSTN_CLR);
+}
+
+static void *mt8195_scp_dual_da_to_va(struct mtk_scp *scp, u64 da, size_t len)
+{
+	int offset;
+
+	if (da >= scp->sram_phys &&
+	    (da + len) <= scp->sram_phys + scp->sram_size) {
+		offset = da - scp->sram_phys;
+		return (void __force *)scp->sram_base + offset;
+	}
+
+	/* optional memory region */
+	if (scp->l1tcm_size &&
+	    da >= scp->l1tcm_phys &&
+	    (da + len) <= scp->l1tcm_phys + scp->l1tcm_size) {
+		offset = da - scp->l1tcm_phys;
+		return (void __force *)scp->l1tcm_base + offset;
+	}
+
+	/* optional memory region */
+	if (scp->dram_size &&
+	    da >= scp->dma_addr &&
+	    (da + len) <= scp->dma_addr + scp->dram_size) {
+		offset = da - scp->dma_addr;
+		return scp->cpu_addr + offset;
+	}
+
+	return NULL;
+}
+
+static void mt8195_scp_dual_stop(struct mtk_scp *scp)
+{
+	/* Power off CPU SRAM */
+	mt8195_power_off_sram(scp->reg_base + MT8195_CPU1_SRAM_PD);
+
+	/* Disable SCP watchdog */
+	writel(0, scp->reg_base + MT8195_CORE1_WDT_CFG);
+}
+
+static int mt8195_scp_dual_clk_get(struct mtk_scp *scp)
+{
+	scp->clk = NULL;
+
+	return 0;
+}
+
+static const struct mtk_scp_of_data mt8195_scp_dual_of_data = {
+	.scp_clk_get = mt8195_scp_dual_clk_get,
+	.scp_before_load = mt8195_scp_dual_before_load,
+	.scp_irq_handler = mt8195_scp_dual_irq_handler,
+	.scp_reset_assert = mt8195_scp_dual_reset_assert,
+	.scp_reset_deassert = mt8195_scp_dual_reset_deassert,
+	.scp_stop = mt8195_scp_dual_stop,
+	.scp_da_to_va = mt8195_scp_dual_da_to_va,
+	.host_to_scp_reg = MT8192_GIPC_IN_SET,
+	.host_to_scp_int_bit = MT8195_HOST_IPC_INT_BIT,
+};
+
 static const struct rproc_ops scp_ops = {
 	.start		= scp_start,
 	.stop		= scp_stop,
@@ -53,6 +171,7 @@ static int scp_dual_probe(struct platform_device *pdev)
 	scp = (struct mtk_scp *)rproc->priv;
 	scp->rproc = rproc;
 	scp->dev = dev;
+	scp->data = of_device_get_match_data(dev);
 	platform_set_drvdata(pdev, scp);
 
 	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sram");
@@ -125,7 +244,7 @@ static int scp_dual_remove(struct platform_device *pdev)
 }
 
 static const struct of_device_id mtk_scp_dual_of_match[] = {
-	{ .compatible = "mediatek,mt8195-scp-dual" },
+	{ .compatible = "mediatek,mt8195-scp-dual", .data = &mt8195_scp_dual_of_data },
 	{},
 };
 MODULE_DEVICE_TABLE(of, mtk_scp_dual_of_match);
-- 
2.18.0


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH v1 10/15] remoteproc: mediatek: Add chip dependent operations for SCP core 1

[Tinghan Shen]

The SCP rproc operations has chip dependent callbacks. Implement a
version of these callbacks for MT8195 SCP core 1.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_common.h   |   1 +
 drivers/remoteproc/mtk_scp.c      |   3 +-
 drivers/remoteproc/mtk_scp_dual.c | 121 +++++++++++++++++++++++++++++-
 3 files changed, 123 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index 04f7ee590f96..7b363411ec99 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -171,4 +171,5 @@ int scp_parse_fw(struct rproc *rproc, const struct firmware *fw);
 int scp_map_memory_region(struct mtk_scp *scp);
 void scp_unmap_memory_region(struct mtk_scp *scp);
 irqreturn_t scp_irq_handler(int irq, void *priv);
+void scp_ipi_handler(struct mtk_scp *scp);
 #endif
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index c67883c28a43..55bc4e9d1a6f 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -84,7 +84,7 @@ static void scp_init_ipi_handler(void *data, unsigned int len, void *priv)
 	wake_up_interruptible(&scp->run.wq);
 }
 
-static void scp_ipi_handler(struct mtk_scp *scp)
+void scp_ipi_handler(struct mtk_scp *scp)
 {
 	struct mtk_share_obj __iomem *rcv_obj = scp->recv_buf;
 	struct scp_ipi_desc *ipi_desc = scp->ipi_desc;
@@ -118,6 +118,7 @@ static void scp_ipi_handler(struct mtk_scp *scp)
 	scp->ipi_id_ack[id] = true;
 	wake_up(&scp->ack_wq);
 }
+EXPORT_SYMBOL_GPL(scp_ipi_handler);
 
 static int scp_elf_read_ipi_buf_addr(struct mtk_scp *scp,
 				     const struct firmware *fw,
diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index d4cc15e22640..16cf9d2628c8 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -12,6 +12,124 @@
 #include "mtk_common.h"
 #include "remoteproc_internal.h"
 
+static void mt8195_power_on_sram(void __iomem *addr)
+{
+	int i;
+
+	for (i = 31; i >= 0; i--)
+		writel(GENMASK(i, 0), addr);
+	writel(0, addr);
+}
+
+static void mt8195_power_off_sram(void __iomem *addr)
+{
+	int i;
+
+	writel(0, addr);
+	for (i = 0; i < 32; i++)
+		writel(GENMASK(i, 0), addr);
+}
+
+static int mt8195_scp_dual_before_load(struct mtk_scp *scp)
+{
+	u32 sec_ctrl;
+
+	mt8195_power_on_sram(scp->reg_base + MT8195_CPU1_SRAM_PD);
+
+	/* hold SCP in reset while loading FW. */
+	scp->data->scp_reset_assert(scp);
+
+	/* enable MPU for all memory regions */
+	writel(0xff, scp->reg_base + MT8195_CORE1_MEM_ATT_PREDEF);
+
+	return 0;
+}
+
+static void mt8195_scp_dual_irq_handler(struct mtk_scp *scp)
+{
+	u32 scp_to_host;
+
+	scp_to_host = readl(scp->reg_base + MT8195_SSHUB2APMCU_IPC_SET);
+
+	if (scp_to_host & MT8192_SCP_IPC_INT_BIT) {
+		scp_ipi_handler(scp);
+
+		/*
+		 * SCP won't send another interrupt until we clear
+		 * MT8195_SSHUB2APMCU_IPC_CLR.
+		 */
+		writel(MT8192_SCP_IPC_INT_BIT,
+		       scp->reg_base + MT8195_SSHUB2APMCU_IPC_CLR);
+	}
+}
+
+static void mt8195_scp_dual_reset_assert(struct mtk_scp *scp)
+{
+	writel(1, scp->reg_base + MT8195_CORE1_SW_RSTN_SET);
+}
+
+static void mt8195_scp_dual_reset_deassert(struct mtk_scp *scp)
+{
+	writel(1, scp->reg_base + MT8195_CORE1_SW_RSTN_CLR);
+}
+
+static void *mt8195_scp_dual_da_to_va(struct mtk_scp *scp, u64 da, size_t len)
+{
+	int offset;
+
+	if (da >= scp->sram_phys &&
+	    (da + len) <= scp->sram_phys + scp->sram_size) {
+		offset = da - scp->sram_phys;
+		return (void __force *)scp->sram_base + offset;
+	}
+
+	/* optional memory region */
+	if (scp->l1tcm_size &&
+	    da >= scp->l1tcm_phys &&
+	    (da + len) <= scp->l1tcm_phys + scp->l1tcm_size) {
+		offset = da - scp->l1tcm_phys;
+		return (void __force *)scp->l1tcm_base + offset;
+	}
+
+	/* optional memory region */
+	if (scp->dram_size &&
+	    da >= scp->dma_addr &&
+	    (da + len) <= scp->dma_addr + scp->dram_size) {
+		offset = da - scp->dma_addr;
+		return scp->cpu_addr + offset;
+	}
+
+	return NULL;
+}
+
+static void mt8195_scp_dual_stop(struct mtk_scp *scp)
+{
+	/* Power off CPU SRAM */
+	mt8195_power_off_sram(scp->reg_base + MT8195_CPU1_SRAM_PD);
+
+	/* Disable SCP watchdog */
+	writel(0, scp->reg_base + MT8195_CORE1_WDT_CFG);
+}
+
+static int mt8195_scp_dual_clk_get(struct mtk_scp *scp)
+{
+	scp->clk = NULL;
+
+	return 0;
+}
+
+static const struct mtk_scp_of_data mt8195_scp_dual_of_data = {
+	.scp_clk_get = mt8195_scp_dual_clk_get,
+	.scp_before_load = mt8195_scp_dual_before_load,
+	.scp_irq_handler = mt8195_scp_dual_irq_handler,
+	.scp_reset_assert = mt8195_scp_dual_reset_assert,
+	.scp_reset_deassert = mt8195_scp_dual_reset_deassert,
+	.scp_stop = mt8195_scp_dual_stop,
+	.scp_da_to_va = mt8195_scp_dual_da_to_va,
+	.host_to_scp_reg = MT8192_GIPC_IN_SET,
+	.host_to_scp_int_bit = MT8195_HOST_IPC_INT_BIT,
+};
+
 static const struct rproc_ops scp_ops = {
 	.start		= scp_start,
 	.stop		= scp_stop,
@@ -53,6 +171,7 @@ static int scp_dual_probe(struct platform_device *pdev)
 	scp = (struct mtk_scp *)rproc->priv;
 	scp->rproc = rproc;
 	scp->dev = dev;
+	scp->data = of_device_get_match_data(dev);
 	platform_set_drvdata(pdev, scp);
 
 	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sram");
@@ -125,7 +244,7 @@ static int scp_dual_remove(struct platform_device *pdev)
 }
 
 static const struct of_device_id mtk_scp_dual_of_match[] = {
-	{ .compatible = "mediatek,mt8195-scp-dual" },
+	{ .compatible = "mediatek,mt8195-scp-dual", .data = &mt8195_scp_dual_of_data },
 	{},
 };
 MODULE_DEVICE_TABLE(of, mtk_scp_dual_of_match);
-- 
2.18.0


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

[PATCH v1 11/15] remoteproc: mediatek: Add SCP core 1 SRAM offset

[Tinghan Shen]

Because SCP core 0 and core 1 both boot from address 0 and have the same
viewpoint of memory, HW has a set of registers, "SRAM offset", to add
offset to accessed address for SCP core 1 to solve this problem.

The "SRAM offset" configuration is composed by specifying a range and an
offset. The value of range is from the viewpoint of SCP core 1.
When SCP core 1 accessing addresses in the configured range, SCP bus
adds an offset to shift the destination on SCP SRAM. This shift is
transparent to the software running on SCP core 1.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_scp_dual.c | 42 +++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index 16cf9d2628c8..4e8d7f5cdad6 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -33,6 +33,27 @@ static void mt8195_power_off_sram(void __iomem *addr)
 static int mt8195_scp_dual_before_load(struct mtk_scp *scp)
 {
 	u32 sec_ctrl;
+	struct device *dev = scp->dev;
+	struct device_node *main_np;
+	struct platform_device *main_pdev;
+	struct mtk_scp *scp_core0;
+
+	/* Get sram start address from SCP core 0 */
+	main_np = of_parse_phandle(dev->of_node, "mediatek,scp-core", 1);
+	if (!main_np) {
+		dev_warn(dev, "Invalid SCP main core phandle\n");
+		return -EINVAL;
+	}
+
+	main_pdev = of_find_device_by_node(main_np);
+	of_node_put(main_np);
+
+	if (!main_pdev) {
+		dev_err(dev, "Cannot find SCP core 0 device\n");
+		return -ENODEV;
+	}
+	scp_core0 = platform_get_drvdata(main_pdev);
+	put_device(&main_pdev->dev);
 
 	mt8195_power_on_sram(scp->reg_base + MT8195_CPU1_SRAM_PD);
 
@@ -42,6 +63,27 @@ static int mt8195_scp_dual_before_load(struct mtk_scp *scp)
 	/* enable MPU for all memory regions */
 	writel(0xff, scp->reg_base + MT8195_CORE1_MEM_ATT_PREDEF);
 
+	/* The value of SRAM offset range is from the viewpoint of SCP core 1.
+	 * This configuration adds an offset on SCP bus when SCP core 1 accesses SCP SRAM
+	 * to solve the SCP core 0 and core 1 both fetch the 1st instruction from the same
+	 * SRAM address.
+	 *
+	 * Because SCP core 0 and core 1 both boot from address 0, this must be configured
+	 * before boot SCP core 1.
+	 *
+	 * Configure the range of SRAM addresses will be added offset.
+	 */
+	writel(0, scp->reg_base + MT8195_L2TCM_OFFSET_RANGE_0_LOW);
+	writel(scp->sram_size, scp->reg_base + MT8195_L2TCM_OFFSET_RANGE_0_HIGH);
+
+	/* configure the offset value */
+	writel(scp->sram_phys - scp_core0->sram_phys, scp->reg_base + MT8195_L2TCM_OFFSET);
+
+	/* enable adding sram offset when fetching instruction and data */
+	sec_ctrl = readl(scp->reg_base + MT8195_SEC_CTRL);
+	sec_ctrl |= MT8195_CORE_OFFSET_ENABLE_I | MT8195_CORE_OFFSET_ENABLE_D;
+	writel(sec_ctrl, scp->reg_base + MT8195_SEC_CTRL);
+
 	return 0;
 }
 
-- 
2.18.0

[PATCH v1 11/15] remoteproc: mediatek: Add SCP core 1 SRAM offset

[Tinghan Shen]

Because SCP core 0 and core 1 both boot from address 0 and have the same
viewpoint of memory, HW has a set of registers, "SRAM offset", to add
offset to accessed address for SCP core 1 to solve this problem.

The "SRAM offset" configuration is composed by specifying a range and an
offset. The value of range is from the viewpoint of SCP core 1.
When SCP core 1 accessing addresses in the configured range, SCP bus
adds an offset to shift the destination on SCP SRAM. This shift is
transparent to the software running on SCP core 1.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_scp_dual.c | 42 +++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index 16cf9d2628c8..4e8d7f5cdad6 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -33,6 +33,27 @@ static void mt8195_power_off_sram(void __iomem *addr)
 static int mt8195_scp_dual_before_load(struct mtk_scp *scp)
 {
 	u32 sec_ctrl;
+	struct device *dev = scp->dev;
+	struct device_node *main_np;
+	struct platform_device *main_pdev;
+	struct mtk_scp *scp_core0;
+
+	/* Get sram start address from SCP core 0 */
+	main_np = of_parse_phandle(dev->of_node, "mediatek,scp-core", 1);
+	if (!main_np) {
+		dev_warn(dev, "Invalid SCP main core phandle\n");
+		return -EINVAL;
+	}
+
+	main_pdev = of_find_device_by_node(main_np);
+	of_node_put(main_np);
+
+	if (!main_pdev) {
+		dev_err(dev, "Cannot find SCP core 0 device\n");
+		return -ENODEV;
+	}
+	scp_core0 = platform_get_drvdata(main_pdev);
+	put_device(&main_pdev->dev);
 
 	mt8195_power_on_sram(scp->reg_base + MT8195_CPU1_SRAM_PD);
 
@@ -42,6 +63,27 @@ static int mt8195_scp_dual_before_load(struct mtk_scp *scp)
 	/* enable MPU for all memory regions */
 	writel(0xff, scp->reg_base + MT8195_CORE1_MEM_ATT_PREDEF);
 
+	/* The value of SRAM offset range is from the viewpoint of SCP core 1.
+	 * This configuration adds an offset on SCP bus when SCP core 1 accesses SCP SRAM
+	 * to solve the SCP core 0 and core 1 both fetch the 1st instruction from the same
+	 * SRAM address.
+	 *
+	 * Because SCP core 0 and core 1 both boot from address 0, this must be configured
+	 * before boot SCP core 1.
+	 *
+	 * Configure the range of SRAM addresses will be added offset.
+	 */
+	writel(0, scp->reg_base + MT8195_L2TCM_OFFSET_RANGE_0_LOW);
+	writel(scp->sram_size, scp->reg_base + MT8195_L2TCM_OFFSET_RANGE_0_HIGH);
+
+	/* configure the offset value */
+	writel(scp->sram_phys - scp_core0->sram_phys, scp->reg_base + MT8195_L2TCM_OFFSET);
+
+	/* enable adding sram offset when fetching instruction and data */
+	sec_ctrl = readl(scp->reg_base + MT8195_SEC_CTRL);
+	sec_ctrl |= MT8195_CORE_OFFSET_ENABLE_I | MT8195_CORE_OFFSET_ENABLE_D;
+	writel(sec_ctrl, scp->reg_base + MT8195_SEC_CTRL);
+
 	return 0;
 }
 
-- 
2.18.0


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH v1 11/15] remoteproc: mediatek: Add SCP core 1 SRAM offset

[Tinghan Shen]

Because SCP core 0 and core 1 both boot from address 0 and have the same
viewpoint of memory, HW has a set of registers, "SRAM offset", to add
offset to accessed address for SCP core 1 to solve this problem.

The "SRAM offset" configuration is composed by specifying a range and an
offset. The value of range is from the viewpoint of SCP core 1.
When SCP core 1 accessing addresses in the configured range, SCP bus
adds an offset to shift the destination on SCP SRAM. This shift is
transparent to the software running on SCP core 1.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_scp_dual.c | 42 +++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index 16cf9d2628c8..4e8d7f5cdad6 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -33,6 +33,27 @@ static void mt8195_power_off_sram(void __iomem *addr)
 static int mt8195_scp_dual_before_load(struct mtk_scp *scp)
 {
 	u32 sec_ctrl;
+	struct device *dev = scp->dev;
+	struct device_node *main_np;
+	struct platform_device *main_pdev;
+	struct mtk_scp *scp_core0;
+
+	/* Get sram start address from SCP core 0 */
+	main_np = of_parse_phandle(dev->of_node, "mediatek,scp-core", 1);
+	if (!main_np) {
+		dev_warn(dev, "Invalid SCP main core phandle\n");
+		return -EINVAL;
+	}
+
+	main_pdev = of_find_device_by_node(main_np);
+	of_node_put(main_np);
+
+	if (!main_pdev) {
+		dev_err(dev, "Cannot find SCP core 0 device\n");
+		return -ENODEV;
+	}
+	scp_core0 = platform_get_drvdata(main_pdev);
+	put_device(&main_pdev->dev);
 
 	mt8195_power_on_sram(scp->reg_base + MT8195_CPU1_SRAM_PD);
 
@@ -42,6 +63,27 @@ static int mt8195_scp_dual_before_load(struct mtk_scp *scp)
 	/* enable MPU for all memory regions */
 	writel(0xff, scp->reg_base + MT8195_CORE1_MEM_ATT_PREDEF);
 
+	/* The value of SRAM offset range is from the viewpoint of SCP core 1.
+	 * This configuration adds an offset on SCP bus when SCP core 1 accesses SCP SRAM
+	 * to solve the SCP core 0 and core 1 both fetch the 1st instruction from the same
+	 * SRAM address.
+	 *
+	 * Because SCP core 0 and core 1 both boot from address 0, this must be configured
+	 * before boot SCP core 1.
+	 *
+	 * Configure the range of SRAM addresses will be added offset.
+	 */
+	writel(0, scp->reg_base + MT8195_L2TCM_OFFSET_RANGE_0_LOW);
+	writel(scp->sram_size, scp->reg_base + MT8195_L2TCM_OFFSET_RANGE_0_HIGH);
+
+	/* configure the offset value */
+	writel(scp->sram_phys - scp_core0->sram_phys, scp->reg_base + MT8195_L2TCM_OFFSET);
+
+	/* enable adding sram offset when fetching instruction and data */
+	sec_ctrl = readl(scp->reg_base + MT8195_SEC_CTRL);
+	sec_ctrl |= MT8195_CORE_OFFSET_ENABLE_I | MT8195_CORE_OFFSET_ENABLE_D;
+	writel(sec_ctrl, scp->reg_base + MT8195_SEC_CTRL);
+
 	return 0;
 }
 
-- 
2.18.0


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

[PATCH v1 12/15] remoteproc: mediatek: Add SCP core 1 as a rproc subdevice

[Tinghan Shen]

Because the clock and SRAM power is controlled by SCP core 0, SCP core 1
has to be boot after SCP core 0. We use the rproc subdev to achieve this
purpose.

The watchdog timeout handler of SCP core 1 is added as part of the rproc
subdevice. This allows SCP core 0 to handle watchdog timeout coming from
SCP core 1.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/Makefile         |   2 +-
 drivers/remoteproc/mtk_common.h     |  12 +++
 drivers/remoteproc/mtk_scp.c        |  32 +++++++
 drivers/remoteproc/mtk_scp_dual.c   |   8 ++
 drivers/remoteproc/mtk_scp_subdev.c | 130 ++++++++++++++++++++++++++++
 5 files changed, 183 insertions(+), 1 deletion(-)
 create mode 100644 drivers/remoteproc/mtk_scp_subdev.c

diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 84cb687d28da..97f729f7c4ae 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -15,7 +15,7 @@ obj-$(CONFIG_IMX_REMOTEPROC)		+= imx_rproc.o
 obj-$(CONFIG_IMX_DSP_REMOTEPROC)	+= imx_dsp_rproc.o
 obj-$(CONFIG_INGENIC_VPU_RPROC)		+= ingenic_rproc.o
 obj-$(CONFIG_MTK_SCP)			+= mtk_scp.o mtk_scp_ipi.o
-obj-$(CONFIG_MTK_SCP_DUALCORE)		+= mtk_scp_dual.o
+obj-$(CONFIG_MTK_SCP_DUALCORE)		+= mtk_scp_dual.o mtk_scp_subdev.o
 obj-$(CONFIG_OMAP_REMOTEPROC)		+= omap_remoteproc.o
 obj-$(CONFIG_WKUP_M3_RPROC)		+= wkup_m3_rproc.o
 obj-$(CONFIG_DA8XX_REMOTEPROC)		+= da8xx_remoteproc.o
diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index 7b363411ec99..a5c26e56277d 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -99,6 +99,14 @@ struct scp_ipi_desc {
 	void *priv;
 };
 
+struct scp_subdev_core {
+	struct rproc_subdev subdev;
+	struct mtk_scp *main_scp;
+	void (*scp_dual_wdt_timeout)(struct mtk_scp *scp, u32 scp_to_host);
+};
+
+#define to_subdev_core(d) container_of(d, struct scp_subdev_core, subdev)
+
 struct mtk_scp;
 
 struct mtk_scp_of_data {
@@ -144,6 +152,7 @@ struct mtk_scp {
 	size_t dram_size;
 
 	struct rproc_subdev *rpmsg_subdev;
+	struct rproc_subdev *dual_subdev;
 };
 
 /**
@@ -172,4 +181,7 @@ int scp_map_memory_region(struct mtk_scp *scp);
 void scp_unmap_memory_region(struct mtk_scp *scp);
 irqreturn_t scp_irq_handler(int irq, void *priv);
 void scp_ipi_handler(struct mtk_scp *scp);
+
+struct rproc_subdev *scp_dual_create_subdev(struct mtk_scp *scp);
+void scp_dual_destroy_subdev(struct rproc_subdev *subdev);
 #endif
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index 55bc4e9d1a6f..c7bf0a44ba0d 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -231,6 +231,13 @@ static void mt8195_scp_irq_handler(struct mtk_scp *scp)
 	} else {
 		if (readl(scp->reg_base + MT8195_SYS_STATUS) & MT8195_CORE1_WDT) {
 			writel(1, scp->reg_base + MT8195_CORE1_WDT_IRQ);
+
+			if (scp->dual_subdev) {
+				struct scp_subdev_core *subdev_core;
+
+				subdev_core = to_subdev_core(scp->dual_subdev);
+				subdev_core->scp_dual_wdt_timeout(scp, scp_to_host);
+			}
 		} else {
 			writel(1, scp->reg_base + MT8192_CORE0_WDT_IRQ);
 			scp_wdt_handler(scp, scp_to_host);
@@ -836,6 +843,27 @@ static void scp_remove_rpmsg_subdev(struct mtk_scp *scp)
 	}
 }
 
+static void scp_add_dual_subdev(struct mtk_scp *scp)
+{
+#if IS_ENABLED(CONFIG_MTK_SCP_DUALCORE)
+	scp->dual_subdev = scp_dual_create_subdev(scp);
+
+	if (scp->dual_subdev)
+		rproc_add_subdev(scp->rproc, scp->dual_subdev);
+#endif
+}
+
+static void scp_remove_dual_subdev(struct mtk_scp *scp)
+{
+#if IS_ENABLED(CONFIG_MTK_SCP_DUALCORE)
+	if (scp->dual_subdev) {
+		rproc_remove_subdev(scp->rproc, scp->dual_subdev);
+		scp_dual_destroy_subdev(scp->dual_subdev);
+		scp->dual_subdev = NULL;
+	}
+#endif
+}
+
 static int scp_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -911,6 +939,8 @@ static int scp_probe(struct platform_device *pdev)
 
 	scp_add_rpmsg_subdev(scp);
 
+	scp_add_dual_subdev(scp);
+
 	ret = devm_request_threaded_irq(dev, platform_get_irq(pdev, 0), NULL,
 					scp_irq_handler, IRQF_ONESHOT,
 					pdev->name, scp);
@@ -927,6 +957,7 @@ static int scp_probe(struct platform_device *pdev)
 	return 0;
 
 remove_subdev:
+	scp_remove_dual_subdev(scp);
 	scp_remove_rpmsg_subdev(scp);
 	scp_ipi_unregister(scp, SCP_IPI_INIT);
 release_dev_mem:
@@ -944,6 +975,7 @@ static int scp_remove(struct platform_device *pdev)
 	int i;
 
 	rproc_del(scp->rproc);
+	scp_remove_dual_subdev(scp);
 	scp_remove_rpmsg_subdev(scp);
 	scp_ipi_unregister(scp, SCP_IPI_INIT);
 	scp_unmap_memory_region(scp);
diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index 4e8d7f5cdad6..90c49716dd39 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -258,6 +258,14 @@ static int scp_dual_probe(struct platform_device *pdev)
 		goto remove_ipi;
 	}
 
+	/* disable auto boot before register rproc.
+	 * it's booted as a subdevice of scp core 0.
+	 */
+	rproc->auto_boot = false;
+	ret = devm_rproc_add(dev, rproc);
+	if (ret)
+		goto remove_ipi;
+
 	return 0;
 
 remove_ipi:
diff --git a/drivers/remoteproc/mtk_scp_subdev.c b/drivers/remoteproc/mtk_scp_subdev.c
new file mode 100644
index 000000000000..197fb207c756
--- /dev/null
+++ b/drivers/remoteproc/mtk_scp_subdev.c
@@ -0,0 +1,130 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2022 MediaTek Inc.
+
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+
+#include "mtk_common.h"
+
+#define SCP_MAIN_CORE 0
+#define SCP_DTS_CORE_ID 0
+#define SCP_DTS_CORE_REF 1
+
+static struct mtk_scp *scp_dual_get(struct mtk_scp *scp)
+{
+	struct device *dev = scp->dev;
+	struct device_node *np;
+	struct platform_device *dual_pdev;
+
+	np = of_parse_phandle(dev->of_node, "mediatek,scp-core", SCP_DTS_CORE_REF);
+	dual_pdev = of_find_device_by_node(np);
+	of_node_put(np);
+
+	if (!dual_pdev) {
+		dev_err(dev, "No scp-dual pdev\n");
+		return NULL;
+	}
+
+	return platform_get_drvdata(dual_pdev);
+}
+
+static void scp_dual_put(struct mtk_scp *scp)
+{
+	put_device(scp->dev);
+}
+
+static int scp_dual_rproc_start(struct rproc_subdev *subdev)
+{
+	struct scp_subdev_core *subdev_core = to_subdev_core(subdev);
+	struct mtk_scp *scp_dual;
+
+	scp_dual = scp_dual_get(subdev_core->main_scp);
+	if (!scp_dual)
+		return -ENODEV;
+
+	rproc_boot(scp_dual->rproc);
+	scp_dual_put(scp_dual);
+
+	return 0;
+}
+
+static void scp_dual_rproc_stop(struct rproc_subdev *subdev, bool crashed)
+{
+	struct scp_subdev_core *subdev_core = to_subdev_core(subdev);
+	struct mtk_scp *scp_dual;
+
+	scp_dual = scp_dual_get(subdev_core->main_scp);
+	if (!scp_dual)
+		return;
+
+	rproc_shutdown(scp_dual->rproc);
+	scp_dual_put(scp_dual);
+}
+
+static void scp_dual_wdt_handler(struct mtk_scp *scp, u32 scp_to_host)
+{
+	struct mtk_scp *scp_dual;
+
+	scp_dual = scp_dual_get(scp);
+	if (!scp_dual)
+		return;
+
+	dev_err(scp_dual->dev, "SCP watchdog timeout! 0x%x\n", scp_to_host);
+	rproc_report_crash(scp_dual->rproc, RPROC_WATCHDOG);
+	scp_dual_put(scp_dual);
+}
+
+struct rproc_subdev *scp_dual_create_subdev(struct mtk_scp *scp)
+{
+	struct device *dev = scp->dev;
+	struct scp_subdev_core *subdev_core;
+	struct device_node *np;
+	int ret, core_id;
+
+	ret = of_property_read_u32_index(dev->of_node, "mediatek,scp-core", SCP_DTS_CORE_ID,
+					 &core_id);
+	if (ret < 0) {
+		dev_warn(dev, "No SCP core id\n");
+		return NULL;
+	}
+
+	if (core_id != SCP_MAIN_CORE) {
+		dev_dbg(dev, "SCP core id %d\n", core_id);
+		return NULL;
+	}
+
+	np = of_parse_phandle(dev->of_node, "mediatek,scp-core", SCP_DTS_CORE_REF);
+	if (!np) {
+		dev_err(dev, "Invalid mediatek,scp-core phandle\n");
+		return NULL;
+	}
+	of_node_put(np);
+
+	subdev_core = devm_kzalloc(dev, sizeof(*subdev_core), GFP_KERNEL);
+	if (!subdev_core)
+		return NULL;
+
+	subdev_core->main_scp = scp;
+	subdev_core->scp_dual_wdt_timeout = scp_dual_wdt_handler;
+	subdev_core->subdev.start = scp_dual_rproc_start;
+	subdev_core->subdev.stop = scp_dual_rproc_stop;
+
+	return &subdev_core->subdev;
+}
+EXPORT_SYMBOL_GPL(scp_dual_create_subdev);
+
+void scp_dual_destroy_subdev(struct rproc_subdev *subdev)
+{
+	struct scp_subdev_core *subdev_core = to_subdev_core(subdev);
+
+	devm_kfree(subdev_core->main_scp->dev, subdev_core);
+}
+EXPORT_SYMBOL_GPL(scp_dual_destroy_subdev);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("MediaTek scp dual core subdev interface");
-- 
2.18.0

[PATCH v1 12/15] remoteproc: mediatek: Add SCP core 1 as a rproc subdevice

[Tinghan Shen]

Because the clock and SRAM power is controlled by SCP core 0, SCP core 1
has to be boot after SCP core 0. We use the rproc subdev to achieve this
purpose.

The watchdog timeout handler of SCP core 1 is added as part of the rproc
subdevice. This allows SCP core 0 to handle watchdog timeout coming from
SCP core 1.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/Makefile         |   2 +-
 drivers/remoteproc/mtk_common.h     |  12 +++
 drivers/remoteproc/mtk_scp.c        |  32 +++++++
 drivers/remoteproc/mtk_scp_dual.c   |   8 ++
 drivers/remoteproc/mtk_scp_subdev.c | 130 ++++++++++++++++++++++++++++
 5 files changed, 183 insertions(+), 1 deletion(-)
 create mode 100644 drivers/remoteproc/mtk_scp_subdev.c

diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 84cb687d28da..97f729f7c4ae 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -15,7 +15,7 @@ obj-$(CONFIG_IMX_REMOTEPROC)		+= imx_rproc.o
 obj-$(CONFIG_IMX_DSP_REMOTEPROC)	+= imx_dsp_rproc.o
 obj-$(CONFIG_INGENIC_VPU_RPROC)		+= ingenic_rproc.o
 obj-$(CONFIG_MTK_SCP)			+= mtk_scp.o mtk_scp_ipi.o
-obj-$(CONFIG_MTK_SCP_DUALCORE)		+= mtk_scp_dual.o
+obj-$(CONFIG_MTK_SCP_DUALCORE)		+= mtk_scp_dual.o mtk_scp_subdev.o
 obj-$(CONFIG_OMAP_REMOTEPROC)		+= omap_remoteproc.o
 obj-$(CONFIG_WKUP_M3_RPROC)		+= wkup_m3_rproc.o
 obj-$(CONFIG_DA8XX_REMOTEPROC)		+= da8xx_remoteproc.o
diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index 7b363411ec99..a5c26e56277d 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -99,6 +99,14 @@ struct scp_ipi_desc {
 	void *priv;
 };
 
+struct scp_subdev_core {
+	struct rproc_subdev subdev;
+	struct mtk_scp *main_scp;
+	void (*scp_dual_wdt_timeout)(struct mtk_scp *scp, u32 scp_to_host);
+};
+
+#define to_subdev_core(d) container_of(d, struct scp_subdev_core, subdev)
+
 struct mtk_scp;
 
 struct mtk_scp_of_data {
@@ -144,6 +152,7 @@ struct mtk_scp {
 	size_t dram_size;
 
 	struct rproc_subdev *rpmsg_subdev;
+	struct rproc_subdev *dual_subdev;
 };
 
 /**
@@ -172,4 +181,7 @@ int scp_map_memory_region(struct mtk_scp *scp);
 void scp_unmap_memory_region(struct mtk_scp *scp);
 irqreturn_t scp_irq_handler(int irq, void *priv);
 void scp_ipi_handler(struct mtk_scp *scp);
+
+struct rproc_subdev *scp_dual_create_subdev(struct mtk_scp *scp);
+void scp_dual_destroy_subdev(struct rproc_subdev *subdev);
 #endif
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index 55bc4e9d1a6f..c7bf0a44ba0d 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -231,6 +231,13 @@ static void mt8195_scp_irq_handler(struct mtk_scp *scp)
 	} else {
 		if (readl(scp->reg_base + MT8195_SYS_STATUS) & MT8195_CORE1_WDT) {
 			writel(1, scp->reg_base + MT8195_CORE1_WDT_IRQ);
+
+			if (scp->dual_subdev) {
+				struct scp_subdev_core *subdev_core;
+
+				subdev_core = to_subdev_core(scp->dual_subdev);
+				subdev_core->scp_dual_wdt_timeout(scp, scp_to_host);
+			}
 		} else {
 			writel(1, scp->reg_base + MT8192_CORE0_WDT_IRQ);
 			scp_wdt_handler(scp, scp_to_host);
@@ -836,6 +843,27 @@ static void scp_remove_rpmsg_subdev(struct mtk_scp *scp)
 	}
 }
 
+static void scp_add_dual_subdev(struct mtk_scp *scp)
+{
+#if IS_ENABLED(CONFIG_MTK_SCP_DUALCORE)
+	scp->dual_subdev = scp_dual_create_subdev(scp);
+
+	if (scp->dual_subdev)
+		rproc_add_subdev(scp->rproc, scp->dual_subdev);
+#endif
+}
+
+static void scp_remove_dual_subdev(struct mtk_scp *scp)
+{
+#if IS_ENABLED(CONFIG_MTK_SCP_DUALCORE)
+	if (scp->dual_subdev) {
+		rproc_remove_subdev(scp->rproc, scp->dual_subdev);
+		scp_dual_destroy_subdev(scp->dual_subdev);
+		scp->dual_subdev = NULL;
+	}
+#endif
+}
+
 static int scp_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -911,6 +939,8 @@ static int scp_probe(struct platform_device *pdev)
 
 	scp_add_rpmsg_subdev(scp);
 
+	scp_add_dual_subdev(scp);
+
 	ret = devm_request_threaded_irq(dev, platform_get_irq(pdev, 0), NULL,
 					scp_irq_handler, IRQF_ONESHOT,
 					pdev->name, scp);
@@ -927,6 +957,7 @@ static int scp_probe(struct platform_device *pdev)
 	return 0;
 
 remove_subdev:
+	scp_remove_dual_subdev(scp);
 	scp_remove_rpmsg_subdev(scp);
 	scp_ipi_unregister(scp, SCP_IPI_INIT);
 release_dev_mem:
@@ -944,6 +975,7 @@ static int scp_remove(struct platform_device *pdev)
 	int i;
 
 	rproc_del(scp->rproc);
+	scp_remove_dual_subdev(scp);
 	scp_remove_rpmsg_subdev(scp);
 	scp_ipi_unregister(scp, SCP_IPI_INIT);
 	scp_unmap_memory_region(scp);
diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index 4e8d7f5cdad6..90c49716dd39 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -258,6 +258,14 @@ static int scp_dual_probe(struct platform_device *pdev)
 		goto remove_ipi;
 	}
 
+	/* disable auto boot before register rproc.
+	 * it's booted as a subdevice of scp core 0.
+	 */
+	rproc->auto_boot = false;
+	ret = devm_rproc_add(dev, rproc);
+	if (ret)
+		goto remove_ipi;
+
 	return 0;
 
 remove_ipi:
diff --git a/drivers/remoteproc/mtk_scp_subdev.c b/drivers/remoteproc/mtk_scp_subdev.c
new file mode 100644
index 000000000000..197fb207c756
--- /dev/null
+++ b/drivers/remoteproc/mtk_scp_subdev.c
@@ -0,0 +1,130 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2022 MediaTek Inc.
+
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+
+#include "mtk_common.h"
+
+#define SCP_MAIN_CORE 0
+#define SCP_DTS_CORE_ID 0
+#define SCP_DTS_CORE_REF 1
+
+static struct mtk_scp *scp_dual_get(struct mtk_scp *scp)
+{
+	struct device *dev = scp->dev;
+	struct device_node *np;
+	struct platform_device *dual_pdev;
+
+	np = of_parse_phandle(dev->of_node, "mediatek,scp-core", SCP_DTS_CORE_REF);
+	dual_pdev = of_find_device_by_node(np);
+	of_node_put(np);
+
+	if (!dual_pdev) {
+		dev_err(dev, "No scp-dual pdev\n");
+		return NULL;
+	}
+
+	return platform_get_drvdata(dual_pdev);
+}
+
+static void scp_dual_put(struct mtk_scp *scp)
+{
+	put_device(scp->dev);
+}
+
+static int scp_dual_rproc_start(struct rproc_subdev *subdev)
+{
+	struct scp_subdev_core *subdev_core = to_subdev_core(subdev);
+	struct mtk_scp *scp_dual;
+
+	scp_dual = scp_dual_get(subdev_core->main_scp);
+	if (!scp_dual)
+		return -ENODEV;
+
+	rproc_boot(scp_dual->rproc);
+	scp_dual_put(scp_dual);
+
+	return 0;
+}
+
+static void scp_dual_rproc_stop(struct rproc_subdev *subdev, bool crashed)
+{
+	struct scp_subdev_core *subdev_core = to_subdev_core(subdev);
+	struct mtk_scp *scp_dual;
+
+	scp_dual = scp_dual_get(subdev_core->main_scp);
+	if (!scp_dual)
+		return;
+
+	rproc_shutdown(scp_dual->rproc);
+	scp_dual_put(scp_dual);
+}
+
+static void scp_dual_wdt_handler(struct mtk_scp *scp, u32 scp_to_host)
+{
+	struct mtk_scp *scp_dual;
+
+	scp_dual = scp_dual_get(scp);
+	if (!scp_dual)
+		return;
+
+	dev_err(scp_dual->dev, "SCP watchdog timeout! 0x%x\n", scp_to_host);
+	rproc_report_crash(scp_dual->rproc, RPROC_WATCHDOG);
+	scp_dual_put(scp_dual);
+}
+
+struct rproc_subdev *scp_dual_create_subdev(struct mtk_scp *scp)
+{
+	struct device *dev = scp->dev;
+	struct scp_subdev_core *subdev_core;
+	struct device_node *np;
+	int ret, core_id;
+
+	ret = of_property_read_u32_index(dev->of_node, "mediatek,scp-core", SCP_DTS_CORE_ID,
+					 &core_id);
+	if (ret < 0) {
+		dev_warn(dev, "No SCP core id\n");
+		return NULL;
+	}
+
+	if (core_id != SCP_MAIN_CORE) {
+		dev_dbg(dev, "SCP core id %d\n", core_id);
+		return NULL;
+	}
+
+	np = of_parse_phandle(dev->of_node, "mediatek,scp-core", SCP_DTS_CORE_REF);
+	if (!np) {
+		dev_err(dev, "Invalid mediatek,scp-core phandle\n");
+		return NULL;
+	}
+	of_node_put(np);
+
+	subdev_core = devm_kzalloc(dev, sizeof(*subdev_core), GFP_KERNEL);
+	if (!subdev_core)
+		return NULL;
+
+	subdev_core->main_scp = scp;
+	subdev_core->scp_dual_wdt_timeout = scp_dual_wdt_handler;
+	subdev_core->subdev.start = scp_dual_rproc_start;
+	subdev_core->subdev.stop = scp_dual_rproc_stop;
+
+	return &subdev_core->subdev;
+}
+EXPORT_SYMBOL_GPL(scp_dual_create_subdev);
+
+void scp_dual_destroy_subdev(struct rproc_subdev *subdev)
+{
+	struct scp_subdev_core *subdev_core = to_subdev_core(subdev);
+
+	devm_kfree(subdev_core->main_scp->dev, subdev_core);
+}
+EXPORT_SYMBOL_GPL(scp_dual_destroy_subdev);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("MediaTek scp dual core subdev interface");
-- 
2.18.0


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH v1 12/15] remoteproc: mediatek: Add SCP core 1 as a rproc subdevice

[Tinghan Shen]

Because the clock and SRAM power is controlled by SCP core 0, SCP core 1
has to be boot after SCP core 0. We use the rproc subdev to achieve this
purpose.

The watchdog timeout handler of SCP core 1 is added as part of the rproc
subdevice. This allows SCP core 0 to handle watchdog timeout coming from
SCP core 1.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/Makefile         |   2 +-
 drivers/remoteproc/mtk_common.h     |  12 +++
 drivers/remoteproc/mtk_scp.c        |  32 +++++++
 drivers/remoteproc/mtk_scp_dual.c   |   8 ++
 drivers/remoteproc/mtk_scp_subdev.c | 130 ++++++++++++++++++++++++++++
 5 files changed, 183 insertions(+), 1 deletion(-)
 create mode 100644 drivers/remoteproc/mtk_scp_subdev.c

diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 84cb687d28da..97f729f7c4ae 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -15,7 +15,7 @@ obj-$(CONFIG_IMX_REMOTEPROC)		+= imx_rproc.o
 obj-$(CONFIG_IMX_DSP_REMOTEPROC)	+= imx_dsp_rproc.o
 obj-$(CONFIG_INGENIC_VPU_RPROC)		+= ingenic_rproc.o
 obj-$(CONFIG_MTK_SCP)			+= mtk_scp.o mtk_scp_ipi.o
-obj-$(CONFIG_MTK_SCP_DUALCORE)		+= mtk_scp_dual.o
+obj-$(CONFIG_MTK_SCP_DUALCORE)		+= mtk_scp_dual.o mtk_scp_subdev.o
 obj-$(CONFIG_OMAP_REMOTEPROC)		+= omap_remoteproc.o
 obj-$(CONFIG_WKUP_M3_RPROC)		+= wkup_m3_rproc.o
 obj-$(CONFIG_DA8XX_REMOTEPROC)		+= da8xx_remoteproc.o
diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index 7b363411ec99..a5c26e56277d 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -99,6 +99,14 @@ struct scp_ipi_desc {
 	void *priv;
 };
 
+struct scp_subdev_core {
+	struct rproc_subdev subdev;
+	struct mtk_scp *main_scp;
+	void (*scp_dual_wdt_timeout)(struct mtk_scp *scp, u32 scp_to_host);
+};
+
+#define to_subdev_core(d) container_of(d, struct scp_subdev_core, subdev)
+
 struct mtk_scp;
 
 struct mtk_scp_of_data {
@@ -144,6 +152,7 @@ struct mtk_scp {
 	size_t dram_size;
 
 	struct rproc_subdev *rpmsg_subdev;
+	struct rproc_subdev *dual_subdev;
 };
 
 /**
@@ -172,4 +181,7 @@ int scp_map_memory_region(struct mtk_scp *scp);
 void scp_unmap_memory_region(struct mtk_scp *scp);
 irqreturn_t scp_irq_handler(int irq, void *priv);
 void scp_ipi_handler(struct mtk_scp *scp);
+
+struct rproc_subdev *scp_dual_create_subdev(struct mtk_scp *scp);
+void scp_dual_destroy_subdev(struct rproc_subdev *subdev);
 #endif
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index 55bc4e9d1a6f..c7bf0a44ba0d 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -231,6 +231,13 @@ static void mt8195_scp_irq_handler(struct mtk_scp *scp)
 	} else {
 		if (readl(scp->reg_base + MT8195_SYS_STATUS) & MT8195_CORE1_WDT) {
 			writel(1, scp->reg_base + MT8195_CORE1_WDT_IRQ);
+
+			if (scp->dual_subdev) {
+				struct scp_subdev_core *subdev_core;
+
+				subdev_core = to_subdev_core(scp->dual_subdev);
+				subdev_core->scp_dual_wdt_timeout(scp, scp_to_host);
+			}
 		} else {
 			writel(1, scp->reg_base + MT8192_CORE0_WDT_IRQ);
 			scp_wdt_handler(scp, scp_to_host);
@@ -836,6 +843,27 @@ static void scp_remove_rpmsg_subdev(struct mtk_scp *scp)
 	}
 }
 
+static void scp_add_dual_subdev(struct mtk_scp *scp)
+{
+#if IS_ENABLED(CONFIG_MTK_SCP_DUALCORE)
+	scp->dual_subdev = scp_dual_create_subdev(scp);
+
+	if (scp->dual_subdev)
+		rproc_add_subdev(scp->rproc, scp->dual_subdev);
+#endif
+}
+
+static void scp_remove_dual_subdev(struct mtk_scp *scp)
+{
+#if IS_ENABLED(CONFIG_MTK_SCP_DUALCORE)
+	if (scp->dual_subdev) {
+		rproc_remove_subdev(scp->rproc, scp->dual_subdev);
+		scp_dual_destroy_subdev(scp->dual_subdev);
+		scp->dual_subdev = NULL;
+	}
+#endif
+}
+
 static int scp_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -911,6 +939,8 @@ static int scp_probe(struct platform_device *pdev)
 
 	scp_add_rpmsg_subdev(scp);
 
+	scp_add_dual_subdev(scp);
+
 	ret = devm_request_threaded_irq(dev, platform_get_irq(pdev, 0), NULL,
 					scp_irq_handler, IRQF_ONESHOT,
 					pdev->name, scp);
@@ -927,6 +957,7 @@ static int scp_probe(struct platform_device *pdev)
 	return 0;
 
 remove_subdev:
+	scp_remove_dual_subdev(scp);
 	scp_remove_rpmsg_subdev(scp);
 	scp_ipi_unregister(scp, SCP_IPI_INIT);
 release_dev_mem:
@@ -944,6 +975,7 @@ static int scp_remove(struct platform_device *pdev)
 	int i;
 
 	rproc_del(scp->rproc);
+	scp_remove_dual_subdev(scp);
 	scp_remove_rpmsg_subdev(scp);
 	scp_ipi_unregister(scp, SCP_IPI_INIT);
 	scp_unmap_memory_region(scp);
diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index 4e8d7f5cdad6..90c49716dd39 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -258,6 +258,14 @@ static int scp_dual_probe(struct platform_device *pdev)
 		goto remove_ipi;
 	}
 
+	/* disable auto boot before register rproc.
+	 * it's booted as a subdevice of scp core 0.
+	 */
+	rproc->auto_boot = false;
+	ret = devm_rproc_add(dev, rproc);
+	if (ret)
+		goto remove_ipi;
+
 	return 0;
 
 remove_ipi:
diff --git a/drivers/remoteproc/mtk_scp_subdev.c b/drivers/remoteproc/mtk_scp_subdev.c
new file mode 100644
index 000000000000..197fb207c756
--- /dev/null
+++ b/drivers/remoteproc/mtk_scp_subdev.c
@@ -0,0 +1,130 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2022 MediaTek Inc.
+
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+
+#include "mtk_common.h"
+
+#define SCP_MAIN_CORE 0
+#define SCP_DTS_CORE_ID 0
+#define SCP_DTS_CORE_REF 1
+
+static struct mtk_scp *scp_dual_get(struct mtk_scp *scp)
+{
+	struct device *dev = scp->dev;
+	struct device_node *np;
+	struct platform_device *dual_pdev;
+
+	np = of_parse_phandle(dev->of_node, "mediatek,scp-core", SCP_DTS_CORE_REF);
+	dual_pdev = of_find_device_by_node(np);
+	of_node_put(np);
+
+	if (!dual_pdev) {
+		dev_err(dev, "No scp-dual pdev\n");
+		return NULL;
+	}
+
+	return platform_get_drvdata(dual_pdev);
+}
+
+static void scp_dual_put(struct mtk_scp *scp)
+{
+	put_device(scp->dev);
+}
+
+static int scp_dual_rproc_start(struct rproc_subdev *subdev)
+{
+	struct scp_subdev_core *subdev_core = to_subdev_core(subdev);
+	struct mtk_scp *scp_dual;
+
+	scp_dual = scp_dual_get(subdev_core->main_scp);
+	if (!scp_dual)
+		return -ENODEV;
+
+	rproc_boot(scp_dual->rproc);
+	scp_dual_put(scp_dual);
+
+	return 0;
+}
+
+static void scp_dual_rproc_stop(struct rproc_subdev *subdev, bool crashed)
+{
+	struct scp_subdev_core *subdev_core = to_subdev_core(subdev);
+	struct mtk_scp *scp_dual;
+
+	scp_dual = scp_dual_get(subdev_core->main_scp);
+	if (!scp_dual)
+		return;
+
+	rproc_shutdown(scp_dual->rproc);
+	scp_dual_put(scp_dual);
+}
+
+static void scp_dual_wdt_handler(struct mtk_scp *scp, u32 scp_to_host)
+{
+	struct mtk_scp *scp_dual;
+
+	scp_dual = scp_dual_get(scp);
+	if (!scp_dual)
+		return;
+
+	dev_err(scp_dual->dev, "SCP watchdog timeout! 0x%x\n", scp_to_host);
+	rproc_report_crash(scp_dual->rproc, RPROC_WATCHDOG);
+	scp_dual_put(scp_dual);
+}
+
+struct rproc_subdev *scp_dual_create_subdev(struct mtk_scp *scp)
+{
+	struct device *dev = scp->dev;
+	struct scp_subdev_core *subdev_core;
+	struct device_node *np;
+	int ret, core_id;
+
+	ret = of_property_read_u32_index(dev->of_node, "mediatek,scp-core", SCP_DTS_CORE_ID,
+					 &core_id);
+	if (ret < 0) {
+		dev_warn(dev, "No SCP core id\n");
+		return NULL;
+	}
+
+	if (core_id != SCP_MAIN_CORE) {
+		dev_dbg(dev, "SCP core id %d\n", core_id);
+		return NULL;
+	}
+
+	np = of_parse_phandle(dev->of_node, "mediatek,scp-core", SCP_DTS_CORE_REF);
+	if (!np) {
+		dev_err(dev, "Invalid mediatek,scp-core phandle\n");
+		return NULL;
+	}
+	of_node_put(np);
+
+	subdev_core = devm_kzalloc(dev, sizeof(*subdev_core), GFP_KERNEL);
+	if (!subdev_core)
+		return NULL;
+
+	subdev_core->main_scp = scp;
+	subdev_core->scp_dual_wdt_timeout = scp_dual_wdt_handler;
+	subdev_core->subdev.start = scp_dual_rproc_start;
+	subdev_core->subdev.stop = scp_dual_rproc_stop;
+
+	return &subdev_core->subdev;
+}
+EXPORT_SYMBOL_GPL(scp_dual_create_subdev);
+
+void scp_dual_destroy_subdev(struct rproc_subdev *subdev)
+{
+	struct scp_subdev_core *subdev_core = to_subdev_core(subdev);
+
+	devm_kfree(subdev_core->main_scp->dev, subdev_core);
+}
+EXPORT_SYMBOL_GPL(scp_dual_destroy_subdev);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("MediaTek scp dual core subdev interface");
-- 
2.18.0


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

[PATCH v1 13/15] remoteproc: mediatek: Wait SCP core 1 probe done

[Tinghan Shen]

SCP core 1 driver probing must finish before start loading SCP core 1
image. Add a simple flag checking mechanism when preparing SCP core 1
subdevice.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_common.h     |  1 +
 drivers/remoteproc/mtk_scp_dual.c   |  2 ++
 drivers/remoteproc/mtk_scp_subdev.c | 35 ++++++++++++++++++++++++++++-
 3 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index a5c26e56277d..464d013ed6b2 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -153,6 +153,7 @@ struct mtk_scp {
 
 	struct rproc_subdev *rpmsg_subdev;
 	struct rproc_subdev *dual_subdev;
+	int dual_probe_done;
 };
 
 /**
diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index 90c49716dd39..ab62ab54175c 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -266,6 +266,8 @@ static int scp_dual_probe(struct platform_device *pdev)
 	if (ret)
 		goto remove_ipi;
 
+	scp->dual_probe_done = 1;
+
 	return 0;
 
 remove_ipi:
diff --git a/drivers/remoteproc/mtk_scp_subdev.c b/drivers/remoteproc/mtk_scp_subdev.c
index 197fb207c756..71dc6fcad61a 100644
--- a/drivers/remoteproc/mtk_scp_subdev.c
+++ b/drivers/remoteproc/mtk_scp_subdev.c
@@ -20,6 +20,7 @@ static struct mtk_scp *scp_dual_get(struct mtk_scp *scp)
 	struct device *dev = scp->dev;
 	struct device_node *np;
 	struct platform_device *dual_pdev;
+	struct mtk_scp *scp_dual;
 
 	np = of_parse_phandle(dev->of_node, "mediatek,scp-core", SCP_DTS_CORE_REF);
 	dual_pdev = of_find_device_by_node(np);
@@ -30,7 +31,11 @@ static struct mtk_scp *scp_dual_get(struct mtk_scp *scp)
 		return NULL;
 	}
 
-	return platform_get_drvdata(dual_pdev);
+	scp_dual = platform_get_drvdata(dual_pdev);
+	if (!scp_dual)
+		put_device(&dual_pdev->dev);
+
+	return scp_dual;
 }
 
 static void scp_dual_put(struct mtk_scp *scp)
@@ -38,6 +43,33 @@ static void scp_dual_put(struct mtk_scp *scp)
 	put_device(scp->dev);
 }
 
+static int scp_dual_rproc_prepare(struct rproc_subdev *subdev)
+{
+	struct scp_subdev_core *subdev_core = to_subdev_core(subdev);
+	struct mtk_scp *scp = subdev_core->main_scp;
+	unsigned long timeout;
+
+	timeout = jiffies + msecs_to_jiffies(100);
+	while (1) {
+		struct mtk_scp *scp_dual = scp_dual_get(scp);
+
+		if (scp_dual && scp_dual->dual_probe_done) {
+			scp_dual_put(scp_dual);
+			break;
+		}
+
+		if (scp_dual && !scp_dual->dual_probe_done)
+			scp_dual_put(scp_dual);
+
+		if (time_after(jiffies, timeout)) {
+			dev_err(scp->dev, "scp-dual probe timeout\n");
+			return -ETIMEDOUT;
+		}
+	}
+
+	return 0;
+}
+
 static int scp_dual_rproc_start(struct rproc_subdev *subdev)
 {
 	struct scp_subdev_core *subdev_core = to_subdev_core(subdev);
@@ -111,6 +143,7 @@ struct rproc_subdev *scp_dual_create_subdev(struct mtk_scp *scp)
 
 	subdev_core->main_scp = scp;
 	subdev_core->scp_dual_wdt_timeout = scp_dual_wdt_handler;
+	subdev_core->subdev.prepare = scp_dual_rproc_prepare;
 	subdev_core->subdev.start = scp_dual_rproc_start;
 	subdev_core->subdev.stop = scp_dual_rproc_stop;
 
-- 
2.18.0

[PATCH v1 13/15] remoteproc: mediatek: Wait SCP core 1 probe done

[Tinghan Shen]

SCP core 1 driver probing must finish before start loading SCP core 1
image. Add a simple flag checking mechanism when preparing SCP core 1
subdevice.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_common.h     |  1 +
 drivers/remoteproc/mtk_scp_dual.c   |  2 ++
 drivers/remoteproc/mtk_scp_subdev.c | 35 ++++++++++++++++++++++++++++-
 3 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index a5c26e56277d..464d013ed6b2 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -153,6 +153,7 @@ struct mtk_scp {
 
 	struct rproc_subdev *rpmsg_subdev;
 	struct rproc_subdev *dual_subdev;
+	int dual_probe_done;
 };
 
 /**
diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index 90c49716dd39..ab62ab54175c 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -266,6 +266,8 @@ static int scp_dual_probe(struct platform_device *pdev)
 	if (ret)
 		goto remove_ipi;
 
+	scp->dual_probe_done = 1;
+
 	return 0;
 
 remove_ipi:
diff --git a/drivers/remoteproc/mtk_scp_subdev.c b/drivers/remoteproc/mtk_scp_subdev.c
index 197fb207c756..71dc6fcad61a 100644
--- a/drivers/remoteproc/mtk_scp_subdev.c
+++ b/drivers/remoteproc/mtk_scp_subdev.c
@@ -20,6 +20,7 @@ static struct mtk_scp *scp_dual_get(struct mtk_scp *scp)
 	struct device *dev = scp->dev;
 	struct device_node *np;
 	struct platform_device *dual_pdev;
+	struct mtk_scp *scp_dual;
 
 	np = of_parse_phandle(dev->of_node, "mediatek,scp-core", SCP_DTS_CORE_REF);
 	dual_pdev = of_find_device_by_node(np);
@@ -30,7 +31,11 @@ static struct mtk_scp *scp_dual_get(struct mtk_scp *scp)
 		return NULL;
 	}
 
-	return platform_get_drvdata(dual_pdev);
+	scp_dual = platform_get_drvdata(dual_pdev);
+	if (!scp_dual)
+		put_device(&dual_pdev->dev);
+
+	return scp_dual;
 }
 
 static void scp_dual_put(struct mtk_scp *scp)
@@ -38,6 +43,33 @@ static void scp_dual_put(struct mtk_scp *scp)
 	put_device(scp->dev);
 }
 
+static int scp_dual_rproc_prepare(struct rproc_subdev *subdev)
+{
+	struct scp_subdev_core *subdev_core = to_subdev_core(subdev);
+	struct mtk_scp *scp = subdev_core->main_scp;
+	unsigned long timeout;
+
+	timeout = jiffies + msecs_to_jiffies(100);
+	while (1) {
+		struct mtk_scp *scp_dual = scp_dual_get(scp);
+
+		if (scp_dual && scp_dual->dual_probe_done) {
+			scp_dual_put(scp_dual);
+			break;
+		}
+
+		if (scp_dual && !scp_dual->dual_probe_done)
+			scp_dual_put(scp_dual);
+
+		if (time_after(jiffies, timeout)) {
+			dev_err(scp->dev, "scp-dual probe timeout\n");
+			return -ETIMEDOUT;
+		}
+	}
+
+	return 0;
+}
+
 static int scp_dual_rproc_start(struct rproc_subdev *subdev)
 {
 	struct scp_subdev_core *subdev_core = to_subdev_core(subdev);
@@ -111,6 +143,7 @@ struct rproc_subdev *scp_dual_create_subdev(struct mtk_scp *scp)
 
 	subdev_core->main_scp = scp;
 	subdev_core->scp_dual_wdt_timeout = scp_dual_wdt_handler;
+	subdev_core->subdev.prepare = scp_dual_rproc_prepare;
 	subdev_core->subdev.start = scp_dual_rproc_start;
 	subdev_core->subdev.stop = scp_dual_rproc_stop;
 
-- 
2.18.0


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH v1 13/15] remoteproc: mediatek: Wait SCP core 1 probe done

[Tinghan Shen]

SCP core 1 driver probing must finish before start loading SCP core 1
image. Add a simple flag checking mechanism when preparing SCP core 1
subdevice.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_common.h     |  1 +
 drivers/remoteproc/mtk_scp_dual.c   |  2 ++
 drivers/remoteproc/mtk_scp_subdev.c | 35 ++++++++++++++++++++++++++++-
 3 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index a5c26e56277d..464d013ed6b2 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -153,6 +153,7 @@ struct mtk_scp {
 
 	struct rproc_subdev *rpmsg_subdev;
 	struct rproc_subdev *dual_subdev;
+	int dual_probe_done;
 };
 
 /**
diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index 90c49716dd39..ab62ab54175c 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -266,6 +266,8 @@ static int scp_dual_probe(struct platform_device *pdev)
 	if (ret)
 		goto remove_ipi;
 
+	scp->dual_probe_done = 1;
+
 	return 0;
 
 remove_ipi:
diff --git a/drivers/remoteproc/mtk_scp_subdev.c b/drivers/remoteproc/mtk_scp_subdev.c
index 197fb207c756..71dc6fcad61a 100644
--- a/drivers/remoteproc/mtk_scp_subdev.c
+++ b/drivers/remoteproc/mtk_scp_subdev.c
@@ -20,6 +20,7 @@ static struct mtk_scp *scp_dual_get(struct mtk_scp *scp)
 	struct device *dev = scp->dev;
 	struct device_node *np;
 	struct platform_device *dual_pdev;
+	struct mtk_scp *scp_dual;
 
 	np = of_parse_phandle(dev->of_node, "mediatek,scp-core", SCP_DTS_CORE_REF);
 	dual_pdev = of_find_device_by_node(np);
@@ -30,7 +31,11 @@ static struct mtk_scp *scp_dual_get(struct mtk_scp *scp)
 		return NULL;
 	}
 
-	return platform_get_drvdata(dual_pdev);
+	scp_dual = platform_get_drvdata(dual_pdev);
+	if (!scp_dual)
+		put_device(&dual_pdev->dev);
+
+	return scp_dual;
 }
 
 static void scp_dual_put(struct mtk_scp *scp)
@@ -38,6 +43,33 @@ static void scp_dual_put(struct mtk_scp *scp)
 	put_device(scp->dev);
 }
 
+static int scp_dual_rproc_prepare(struct rproc_subdev *subdev)
+{
+	struct scp_subdev_core *subdev_core = to_subdev_core(subdev);
+	struct mtk_scp *scp = subdev_core->main_scp;
+	unsigned long timeout;
+
+	timeout = jiffies + msecs_to_jiffies(100);
+	while (1) {
+		struct mtk_scp *scp_dual = scp_dual_get(scp);
+
+		if (scp_dual && scp_dual->dual_probe_done) {
+			scp_dual_put(scp_dual);
+			break;
+		}
+
+		if (scp_dual && !scp_dual->dual_probe_done)
+			scp_dual_put(scp_dual);
+
+		if (time_after(jiffies, timeout)) {
+			dev_err(scp->dev, "scp-dual probe timeout\n");
+			return -ETIMEDOUT;
+		}
+	}
+
+	return 0;
+}
+
 static int scp_dual_rproc_start(struct rproc_subdev *subdev)
 {
 	struct scp_subdev_core *subdev_core = to_subdev_core(subdev);
@@ -111,6 +143,7 @@ struct rproc_subdev *scp_dual_create_subdev(struct mtk_scp *scp)
 
 	subdev_core->main_scp = scp;
 	subdev_core->scp_dual_wdt_timeout = scp_dual_wdt_handler;
+	subdev_core->subdev.prepare = scp_dual_rproc_prepare;
 	subdev_core->subdev.start = scp_dual_rproc_start;
 	subdev_core->subdev.stop = scp_dual_rproc_stop;
 
-- 
2.18.0


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

[PATCH v1 14/15] remoteproc: mediatek: Support rpmsg for SCP core 1

[Tinghan Shen]

Reuse the rpmsg subdevice flow of SCP core 0 on SCP core 1.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_common.h   | 3 +++
 drivers/remoteproc/mtk_scp.c      | 6 ++++--
 drivers/remoteproc/mtk_scp_dual.c | 4 ++++
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index 464d013ed6b2..89e2bec0a087 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -185,4 +185,7 @@ void scp_ipi_handler(struct mtk_scp *scp);
 
 struct rproc_subdev *scp_dual_create_subdev(struct mtk_scp *scp);
 void scp_dual_destroy_subdev(struct rproc_subdev *subdev);
+
+void scp_add_rpmsg_subdev(struct mtk_scp *scp);
+void scp_remove_rpmsg_subdev(struct mtk_scp *scp);
 #endif
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index c7bf0a44ba0d..fbeaa81e914d 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -825,7 +825,7 @@ static struct mtk_rpmsg_info mtk_scp_rpmsg_info = {
 	.ns_ipi_id = SCP_IPI_NS_SERVICE,
 };
 
-static void scp_add_rpmsg_subdev(struct mtk_scp *scp)
+void scp_add_rpmsg_subdev(struct mtk_scp *scp)
 {
 	scp->rpmsg_subdev =
 		mtk_rpmsg_create_rproc_subdev(to_platform_device(scp->dev),
@@ -833,8 +833,9 @@ static void scp_add_rpmsg_subdev(struct mtk_scp *scp)
 	if (scp->rpmsg_subdev)
 		rproc_add_subdev(scp->rproc, scp->rpmsg_subdev);
 }
+EXPORT_SYMBOL_GPL(scp_add_rpmsg_subdev);
 
-static void scp_remove_rpmsg_subdev(struct mtk_scp *scp)
+void scp_remove_rpmsg_subdev(struct mtk_scp *scp)
 {
 	if (scp->rpmsg_subdev) {
 		rproc_remove_subdev(scp->rproc, scp->rpmsg_subdev);
@@ -842,6 +843,7 @@ static void scp_remove_rpmsg_subdev(struct mtk_scp *scp)
 		scp->rpmsg_subdev = NULL;
 	}
 }
+EXPORT_SYMBOL_GPL(scp_remove_rpmsg_subdev);
 
 static void scp_add_dual_subdev(struct mtk_scp *scp)
 {
diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index ab62ab54175c..caa57516e083 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -249,6 +249,8 @@ static int scp_dual_probe(struct platform_device *pdev)
 	init_waitqueue_head(&scp->run.wq);
 	init_waitqueue_head(&scp->ack_wq);
 
+	scp_add_rpmsg_subdev(scp);
+
 	ret = devm_request_threaded_irq(dev, platform_get_irq(pdev, 0), NULL,
 					scp_irq_handler, IRQF_ONESHOT,
 					pdev->name, scp);
@@ -271,6 +273,7 @@ static int scp_dual_probe(struct platform_device *pdev)
 	return 0;
 
 remove_ipi:
+	scp_remove_rpmsg_subdev(scp);
 	scp_ipi_unregister(scp, SCP_IPI_INIT);
 release_dev_mem:
 	scp_unmap_memory_region(scp);
@@ -286,6 +289,7 @@ static int scp_dual_remove(struct platform_device *pdev)
 	struct mtk_scp *scp = platform_get_drvdata(pdev);
 	int i;
 
+	scp_remove_rpmsg_subdev(scp);
 	scp_ipi_unregister(scp, SCP_IPI_INIT);
 	scp_unmap_memory_region(scp);
 	for (i = 0; i < SCP_IPI_MAX; i++)
-- 
2.18.0

[PATCH v1 14/15] remoteproc: mediatek: Support rpmsg for SCP core 1

[Tinghan Shen]

Reuse the rpmsg subdevice flow of SCP core 0 on SCP core 1.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_common.h   | 3 +++
 drivers/remoteproc/mtk_scp.c      | 6 ++++--
 drivers/remoteproc/mtk_scp_dual.c | 4 ++++
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index 464d013ed6b2..89e2bec0a087 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -185,4 +185,7 @@ void scp_ipi_handler(struct mtk_scp *scp);
 
 struct rproc_subdev *scp_dual_create_subdev(struct mtk_scp *scp);
 void scp_dual_destroy_subdev(struct rproc_subdev *subdev);
+
+void scp_add_rpmsg_subdev(struct mtk_scp *scp);
+void scp_remove_rpmsg_subdev(struct mtk_scp *scp);
 #endif
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index c7bf0a44ba0d..fbeaa81e914d 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -825,7 +825,7 @@ static struct mtk_rpmsg_info mtk_scp_rpmsg_info = {
 	.ns_ipi_id = SCP_IPI_NS_SERVICE,
 };
 
-static void scp_add_rpmsg_subdev(struct mtk_scp *scp)
+void scp_add_rpmsg_subdev(struct mtk_scp *scp)
 {
 	scp->rpmsg_subdev =
 		mtk_rpmsg_create_rproc_subdev(to_platform_device(scp->dev),
@@ -833,8 +833,9 @@ static void scp_add_rpmsg_subdev(struct mtk_scp *scp)
 	if (scp->rpmsg_subdev)
 		rproc_add_subdev(scp->rproc, scp->rpmsg_subdev);
 }
+EXPORT_SYMBOL_GPL(scp_add_rpmsg_subdev);
 
-static void scp_remove_rpmsg_subdev(struct mtk_scp *scp)
+void scp_remove_rpmsg_subdev(struct mtk_scp *scp)
 {
 	if (scp->rpmsg_subdev) {
 		rproc_remove_subdev(scp->rproc, scp->rpmsg_subdev);
@@ -842,6 +843,7 @@ static void scp_remove_rpmsg_subdev(struct mtk_scp *scp)
 		scp->rpmsg_subdev = NULL;
 	}
 }
+EXPORT_SYMBOL_GPL(scp_remove_rpmsg_subdev);
 
 static void scp_add_dual_subdev(struct mtk_scp *scp)
 {
diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index ab62ab54175c..caa57516e083 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -249,6 +249,8 @@ static int scp_dual_probe(struct platform_device *pdev)
 	init_waitqueue_head(&scp->run.wq);
 	init_waitqueue_head(&scp->ack_wq);
 
+	scp_add_rpmsg_subdev(scp);
+
 	ret = devm_request_threaded_irq(dev, platform_get_irq(pdev, 0), NULL,
 					scp_irq_handler, IRQF_ONESHOT,
 					pdev->name, scp);
@@ -271,6 +273,7 @@ static int scp_dual_probe(struct platform_device *pdev)
 	return 0;
 
 remove_ipi:
+	scp_remove_rpmsg_subdev(scp);
 	scp_ipi_unregister(scp, SCP_IPI_INIT);
 release_dev_mem:
 	scp_unmap_memory_region(scp);
@@ -286,6 +289,7 @@ static int scp_dual_remove(struct platform_device *pdev)
 	struct mtk_scp *scp = platform_get_drvdata(pdev);
 	int i;
 
+	scp_remove_rpmsg_subdev(scp);
 	scp_ipi_unregister(scp, SCP_IPI_INIT);
 	scp_unmap_memory_region(scp);
 	for (i = 0; i < SCP_IPI_MAX; i++)
-- 
2.18.0


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH v1 14/15] remoteproc: mediatek: Support rpmsg for SCP core 1

[Tinghan Shen]

Reuse the rpmsg subdevice flow of SCP core 0 on SCP core 1.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/remoteproc/mtk_common.h   | 3 +++
 drivers/remoteproc/mtk_scp.c      | 6 ++++--
 drivers/remoteproc/mtk_scp_dual.c | 4 ++++
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index 464d013ed6b2..89e2bec0a087 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -185,4 +185,7 @@ void scp_ipi_handler(struct mtk_scp *scp);
 
 struct rproc_subdev *scp_dual_create_subdev(struct mtk_scp *scp);
 void scp_dual_destroy_subdev(struct rproc_subdev *subdev);
+
+void scp_add_rpmsg_subdev(struct mtk_scp *scp);
+void scp_remove_rpmsg_subdev(struct mtk_scp *scp);
 #endif
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index c7bf0a44ba0d..fbeaa81e914d 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -825,7 +825,7 @@ static struct mtk_rpmsg_info mtk_scp_rpmsg_info = {
 	.ns_ipi_id = SCP_IPI_NS_SERVICE,
 };
 
-static void scp_add_rpmsg_subdev(struct mtk_scp *scp)
+void scp_add_rpmsg_subdev(struct mtk_scp *scp)
 {
 	scp->rpmsg_subdev =
 		mtk_rpmsg_create_rproc_subdev(to_platform_device(scp->dev),
@@ -833,8 +833,9 @@ static void scp_add_rpmsg_subdev(struct mtk_scp *scp)
 	if (scp->rpmsg_subdev)
 		rproc_add_subdev(scp->rproc, scp->rpmsg_subdev);
 }
+EXPORT_SYMBOL_GPL(scp_add_rpmsg_subdev);
 
-static void scp_remove_rpmsg_subdev(struct mtk_scp *scp)
+void scp_remove_rpmsg_subdev(struct mtk_scp *scp)
 {
 	if (scp->rpmsg_subdev) {
 		rproc_remove_subdev(scp->rproc, scp->rpmsg_subdev);
@@ -842,6 +843,7 @@ static void scp_remove_rpmsg_subdev(struct mtk_scp *scp)
 		scp->rpmsg_subdev = NULL;
 	}
 }
+EXPORT_SYMBOL_GPL(scp_remove_rpmsg_subdev);
 
 static void scp_add_dual_subdev(struct mtk_scp *scp)
 {
diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
index ab62ab54175c..caa57516e083 100644
--- a/drivers/remoteproc/mtk_scp_dual.c
+++ b/drivers/remoteproc/mtk_scp_dual.c
@@ -249,6 +249,8 @@ static int scp_dual_probe(struct platform_device *pdev)
 	init_waitqueue_head(&scp->run.wq);
 	init_waitqueue_head(&scp->ack_wq);
 
+	scp_add_rpmsg_subdev(scp);
+
 	ret = devm_request_threaded_irq(dev, platform_get_irq(pdev, 0), NULL,
 					scp_irq_handler, IRQF_ONESHOT,
 					pdev->name, scp);
@@ -271,6 +273,7 @@ static int scp_dual_probe(struct platform_device *pdev)
 	return 0;
 
 remove_ipi:
+	scp_remove_rpmsg_subdev(scp);
 	scp_ipi_unregister(scp, SCP_IPI_INIT);
 release_dev_mem:
 	scp_unmap_memory_region(scp);
@@ -286,6 +289,7 @@ static int scp_dual_remove(struct platform_device *pdev)
 	struct mtk_scp *scp = platform_get_drvdata(pdev);
 	int i;
 
+	scp_remove_rpmsg_subdev(scp);
 	scp_ipi_unregister(scp, SCP_IPI_INIT);
 	scp_unmap_memory_region(scp);
 	for (i = 0; i < SCP_IPI_MAX; i++)
-- 
2.18.0


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

[PATCH v1 15/15] mfd: cros_ec: Add SCP core 1 as a new CrOS EC MCU

[Tinghan Shen]

MT8195 System Companion Processors(SCP) is a dual-core RISC-V MCU.
Add a new cros feature id to represent the SCP 2nd core.

The 1st core is referred to as 'core 0', and the 2nd core is referred
to as 'core 1'.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/mfd/cros_ec_dev.c                      | 5 +++++
 include/linux/platform_data/cros_ec_commands.h | 2 ++
 include/linux/platform_data/cros_ec_proto.h    | 1 +
 3 files changed, 8 insertions(+)

diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
index 596731caf407..07cc31d92edc 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -64,6 +64,11 @@ static const struct cros_feature_to_name cros_mcu_devices[] = {
 		.name	= CROS_EC_DEV_SCP_NAME,
 		.desc	= "System Control Processor",
 	},
+	{
+		.id	= EC_FEATURE_SCP_C1,
+		.name	= CROS_EC_DEV_SCP_C1_NAME,
+		.desc	= "System Control Processor 2nd Core",
+	},
 	{
 		.id	= EC_FEATURE_TOUCHPAD,
 		.name	= CROS_EC_DEV_TP_NAME,
diff --git a/include/linux/platform_data/cros_ec_commands.h b/include/linux/platform_data/cros_ec_commands.h
index 8cfa8cfca77e..9fbf1c5eb8d3 100644
--- a/include/linux/platform_data/cros_ec_commands.h
+++ b/include/linux/platform_data/cros_ec_commands.h
@@ -1300,6 +1300,8 @@ enum ec_feature_code {
 	 * mux.
 	 */
 	EC_FEATURE_TYPEC_MUX_REQUIRE_AP_ACK = 43,
+	/* The MCU is a System Companion Processor (SCP) 2nd Core. */
+	EC_FEATURE_SCP_C1 = 45,
 };
 
 #define EC_FEATURE_MASK_0(event_code) BIT(event_code % 32)
diff --git a/include/linux/platform_data/cros_ec_proto.h b/include/linux/platform_data/cros_ec_proto.h
index 138fd912c808..da06dc7cf1cb 100644
--- a/include/linux/platform_data/cros_ec_proto.h
+++ b/include/linux/platform_data/cros_ec_proto.h
@@ -19,6 +19,7 @@
 #define CROS_EC_DEV_ISH_NAME	"cros_ish"
 #define CROS_EC_DEV_PD_NAME	"cros_pd"
 #define CROS_EC_DEV_SCP_NAME	"cros_scp"
+#define CROS_EC_DEV_SCP_C1_NAME	"cros_scp_c1"
 #define CROS_EC_DEV_TP_NAME	"cros_tp"
 
 /*
-- 
2.18.0

[PATCH v1 15/15] mfd: cros_ec: Add SCP core 1 as a new CrOS EC MCU

[Tinghan Shen]

MT8195 System Companion Processors(SCP) is a dual-core RISC-V MCU.
Add a new cros feature id to represent the SCP 2nd core.

The 1st core is referred to as 'core 0', and the 2nd core is referred
to as 'core 1'.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/mfd/cros_ec_dev.c                      | 5 +++++
 include/linux/platform_data/cros_ec_commands.h | 2 ++
 include/linux/platform_data/cros_ec_proto.h    | 1 +
 3 files changed, 8 insertions(+)

diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
index 596731caf407..07cc31d92edc 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -64,6 +64,11 @@ static const struct cros_feature_to_name cros_mcu_devices[] = {
 		.name	= CROS_EC_DEV_SCP_NAME,
 		.desc	= "System Control Processor",
 	},
+	{
+		.id	= EC_FEATURE_SCP_C1,
+		.name	= CROS_EC_DEV_SCP_C1_NAME,
+		.desc	= "System Control Processor 2nd Core",
+	},
 	{
 		.id	= EC_FEATURE_TOUCHPAD,
 		.name	= CROS_EC_DEV_TP_NAME,
diff --git a/include/linux/platform_data/cros_ec_commands.h b/include/linux/platform_data/cros_ec_commands.h
index 8cfa8cfca77e..9fbf1c5eb8d3 100644
--- a/include/linux/platform_data/cros_ec_commands.h
+++ b/include/linux/platform_data/cros_ec_commands.h
@@ -1300,6 +1300,8 @@ enum ec_feature_code {
 	 * mux.
 	 */
 	EC_FEATURE_TYPEC_MUX_REQUIRE_AP_ACK = 43,
+	/* The MCU is a System Companion Processor (SCP) 2nd Core. */
+	EC_FEATURE_SCP_C1 = 45,
 };
 
 #define EC_FEATURE_MASK_0(event_code) BIT(event_code % 32)
diff --git a/include/linux/platform_data/cros_ec_proto.h b/include/linux/platform_data/cros_ec_proto.h
index 138fd912c808..da06dc7cf1cb 100644
--- a/include/linux/platform_data/cros_ec_proto.h
+++ b/include/linux/platform_data/cros_ec_proto.h
@@ -19,6 +19,7 @@
 #define CROS_EC_DEV_ISH_NAME	"cros_ish"
 #define CROS_EC_DEV_PD_NAME	"cros_pd"
 #define CROS_EC_DEV_SCP_NAME	"cros_scp"
+#define CROS_EC_DEV_SCP_C1_NAME	"cros_scp_c1"
 #define CROS_EC_DEV_TP_NAME	"cros_tp"
 
 /*
-- 
2.18.0


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH v1 15/15] mfd: cros_ec: Add SCP core 1 as a new CrOS EC MCU

[Tinghan Shen]

MT8195 System Companion Processors(SCP) is a dual-core RISC-V MCU.
Add a new cros feature id to represent the SCP 2nd core.

The 1st core is referred to as 'core 0', and the 2nd core is referred
to as 'core 1'.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
---
 drivers/mfd/cros_ec_dev.c                      | 5 +++++
 include/linux/platform_data/cros_ec_commands.h | 2 ++
 include/linux/platform_data/cros_ec_proto.h    | 1 +
 3 files changed, 8 insertions(+)

diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
index 596731caf407..07cc31d92edc 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -64,6 +64,11 @@ static const struct cros_feature_to_name cros_mcu_devices[] = {
 		.name	= CROS_EC_DEV_SCP_NAME,
 		.desc	= "System Control Processor",
 	},
+	{
+		.id	= EC_FEATURE_SCP_C1,
+		.name	= CROS_EC_DEV_SCP_C1_NAME,
+		.desc	= "System Control Processor 2nd Core",
+	},
 	{
 		.id	= EC_FEATURE_TOUCHPAD,
 		.name	= CROS_EC_DEV_TP_NAME,
diff --git a/include/linux/platform_data/cros_ec_commands.h b/include/linux/platform_data/cros_ec_commands.h
index 8cfa8cfca77e..9fbf1c5eb8d3 100644
--- a/include/linux/platform_data/cros_ec_commands.h
+++ b/include/linux/platform_data/cros_ec_commands.h
@@ -1300,6 +1300,8 @@ enum ec_feature_code {
 	 * mux.
 	 */
 	EC_FEATURE_TYPEC_MUX_REQUIRE_AP_ACK = 43,
+	/* The MCU is a System Companion Processor (SCP) 2nd Core. */
+	EC_FEATURE_SCP_C1 = 45,
 };
 
 #define EC_FEATURE_MASK_0(event_code) BIT(event_code % 32)
diff --git a/include/linux/platform_data/cros_ec_proto.h b/include/linux/platform_data/cros_ec_proto.h
index 138fd912c808..da06dc7cf1cb 100644
--- a/include/linux/platform_data/cros_ec_proto.h
+++ b/include/linux/platform_data/cros_ec_proto.h
@@ -19,6 +19,7 @@
 #define CROS_EC_DEV_ISH_NAME	"cros_ish"
 #define CROS_EC_DEV_PD_NAME	"cros_pd"
 #define CROS_EC_DEV_SCP_NAME	"cros_scp"
+#define CROS_EC_DEV_SCP_C1_NAME	"cros_scp_c1"
 #define CROS_EC_DEV_TP_NAME	"cros_tp"
 
 /*
-- 
2.18.0


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

Re: [PATCH v1 00/15] Add support for MT8195 SCP 2nd core

[Krzysztof Kozlowski]

On 01/06/2022 13:21, Tinghan Shen wrote:
> The MT8195 System Companion Processor(SCP) is a dual-core RISC-V MCU.
> Current mediatek remoteproc driver only supports bring-up single core 
> SCP or the 1st core of a dual-core SCP. This series support to bring-up 
      ^^ this or is confusing a bit.

Does this mean that MT8195 has three RISC-V MCUs?

> the 2nd core of a dual-core SCP.



Best regards,
Krzysztof

Re: [PATCH v1 00/15] Add support for MT8195 SCP 2nd core

[Krzysztof Kozlowski]

On 01/06/2022 13:21, Tinghan Shen wrote:
> The MT8195 System Companion Processor(SCP) is a dual-core RISC-V MCU.
> Current mediatek remoteproc driver only supports bring-up single core 
> SCP or the 1st core of a dual-core SCP. This series support to bring-up 
      ^^ this or is confusing a bit.

Does this mean that MT8195 has three RISC-V MCUs?

> the 2nd core of a dual-core SCP.



Best regards,
Krzysztof

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH v1 00/15] Add support for MT8195 SCP 2nd core

[Krzysztof Kozlowski]

On 01/06/2022 13:21, Tinghan Shen wrote:
> The MT8195 System Companion Processor(SCP) is a dual-core RISC-V MCU.
> Current mediatek remoteproc driver only supports bring-up single core 
> SCP or the 1st core of a dual-core SCP. This series support to bring-up 
      ^^ this or is confusing a bit.

Does this mean that MT8195 has three RISC-V MCUs?

> the 2nd core of a dual-core SCP.



Best regards,
Krzysztof

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

Re: [PATCH v1 01/15] dt-binding: remoteproc: mediatek: Support dual-core SCP

[Krzysztof Kozlowski]

On 01/06/2022 13:21, Tinghan Shen wrote:
> The SCP co-processor is a dual-core RISC-V MCU on MT8195.
> 
> Add a new property to identify each core and helps to find drivers
> through device tree API to cooperate with each other, e.g. boot flow and
> watchdog timeout flow.
> 
> Add a new compatile for the driver of SCP 2nd core.
> 
> Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
> ---
>  .../devicetree/bindings/remoteproc/mtk,scp.yaml      | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> index eec3b9c4c713..b181786d9575 100644
> --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> @@ -20,6 +20,7 @@ properties:
>        - mediatek,mt8186-scp
>        - mediatek,mt8192-scp
>        - mediatek,mt8195-scp
> +      - mediatek,mt8195-scp-dual
>  
>    reg:
>      description:
> @@ -57,6 +58,16 @@ properties:
>    memory-region:
>      maxItems: 1
>  
> +  mediatek,scp-core:
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +    description:
> +      The property value is a list with 2 items, a core id and a phandle

uint32, not phandle.

> +      to the sibling SCP node. 

Skip this. First part is obvious from the schema, second part should be
described via items.

The core id represents the id of the dts node contains
> +      this property. The valid values of core id are 0 and 1 for dual-core SCP.
> +      The phandle of sibling SCP node is used to find the register settings,
> +      trigger core dependent callback, and invoke rproc API.

Entire description did not help me to understand what's this. So far it
looks like it is not a hardware property but some programming help, so
it does not look like properly described in bindings.

> +    maxItems: 1

In description you said - two items.

You need allOf:if:then disallowing this property for other variants.

> +
>  required:
>    - compatible
>    - reg
> @@ -115,6 +126,7 @@ examples:
>          reg-names = "sram", "cfg", "l1tcm";
>          clocks = <&infracfg CLK_INFRA_SCPSYS>;
>          clock-names = "main";
> +        mediatek,scp-core = <0 &scp_dual>;

This looks like phandle, so wrong type.
>  
>          cros_ec {
>              mediatek,rpmsg-name = "cros-ec-rpmsg";


Best regards,
Krzysztof

Re: [PATCH v1 01/15] dt-binding: remoteproc: mediatek: Support dual-core SCP

[Krzysztof Kozlowski]

On 01/06/2022 13:21, Tinghan Shen wrote:
> The SCP co-processor is a dual-core RISC-V MCU on MT8195.
> 
> Add a new property to identify each core and helps to find drivers
> through device tree API to cooperate with each other, e.g. boot flow and
> watchdog timeout flow.
> 
> Add a new compatile for the driver of SCP 2nd core.
> 
> Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
> ---
>  .../devicetree/bindings/remoteproc/mtk,scp.yaml      | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> index eec3b9c4c713..b181786d9575 100644
> --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> @@ -20,6 +20,7 @@ properties:
>        - mediatek,mt8186-scp
>        - mediatek,mt8192-scp
>        - mediatek,mt8195-scp
> +      - mediatek,mt8195-scp-dual
>  
>    reg:
>      description:
> @@ -57,6 +58,16 @@ properties:
>    memory-region:
>      maxItems: 1
>  
> +  mediatek,scp-core:
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +    description:
> +      The property value is a list with 2 items, a core id and a phandle

uint32, not phandle.

> +      to the sibling SCP node. 

Skip this. First part is obvious from the schema, second part should be
described via items.

The core id represents the id of the dts node contains
> +      this property. The valid values of core id are 0 and 1 for dual-core SCP.
> +      The phandle of sibling SCP node is used to find the register settings,
> +      trigger core dependent callback, and invoke rproc API.

Entire description did not help me to understand what's this. So far it
looks like it is not a hardware property but some programming help, so
it does not look like properly described in bindings.

> +    maxItems: 1

In description you said - two items.

You need allOf:if:then disallowing this property for other variants.

> +
>  required:
>    - compatible
>    - reg
> @@ -115,6 +126,7 @@ examples:
>          reg-names = "sram", "cfg", "l1tcm";
>          clocks = <&infracfg CLK_INFRA_SCPSYS>;
>          clock-names = "main";
> +        mediatek,scp-core = <0 &scp_dual>;

This looks like phandle, so wrong type.
>  
>          cros_ec {
>              mediatek,rpmsg-name = "cros-ec-rpmsg";


Best regards,
Krzysztof

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH v1 01/15] dt-binding: remoteproc: mediatek: Support dual-core SCP

[Krzysztof Kozlowski]

On 01/06/2022 13:21, Tinghan Shen wrote:
> The SCP co-processor is a dual-core RISC-V MCU on MT8195.
> 
> Add a new property to identify each core and helps to find drivers
> through device tree API to cooperate with each other, e.g. boot flow and
> watchdog timeout flow.
> 
> Add a new compatile for the driver of SCP 2nd core.
> 
> Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
> ---
>  .../devicetree/bindings/remoteproc/mtk,scp.yaml      | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> index eec3b9c4c713..b181786d9575 100644
> --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> @@ -20,6 +20,7 @@ properties:
>        - mediatek,mt8186-scp
>        - mediatek,mt8192-scp
>        - mediatek,mt8195-scp
> +      - mediatek,mt8195-scp-dual
>  
>    reg:
>      description:
> @@ -57,6 +58,16 @@ properties:
>    memory-region:
>      maxItems: 1
>  
> +  mediatek,scp-core:
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +    description:
> +      The property value is a list with 2 items, a core id and a phandle

uint32, not phandle.

> +      to the sibling SCP node. 

Skip this. First part is obvious from the schema, second part should be
described via items.

The core id represents the id of the dts node contains
> +      this property. The valid values of core id are 0 and 1 for dual-core SCP.
> +      The phandle of sibling SCP node is used to find the register settings,
> +      trigger core dependent callback, and invoke rproc API.

Entire description did not help me to understand what's this. So far it
looks like it is not a hardware property but some programming help, so
it does not look like properly described in bindings.

> +    maxItems: 1

In description you said - two items.

You need allOf:if:then disallowing this property for other variants.

> +
>  required:
>    - compatible
>    - reg
> @@ -115,6 +126,7 @@ examples:
>          reg-names = "sram", "cfg", "l1tcm";
>          clocks = <&infracfg CLK_INFRA_SCPSYS>;
>          clock-names = "main";
> +        mediatek,scp-core = <0 &scp_dual>;

This looks like phandle, so wrong type.
>  
>          cros_ec {
>              mediatek,rpmsg-name = "cros-ec-rpmsg";


Best regards,
Krzysztof

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

Re: [PATCH v1 00/15] Add support for MT8195 SCP 2nd core

[Tinghan Shen]

Hi Krzysztof,
 
On Wed, 2022-06-01 at 13:46 +0200, Krzysztof Kozlowski wrote:
> On 01/06/2022 13:21, Tinghan Shen wrote:
> > The MT8195 System Companion Processor(SCP) is a dual-core RISC-V MCU.
> > Current mediatek remoteproc driver only supports bring-up single core 
> > SCP or the 1st core of a dual-core SCP. This series support to bring-up 
> 
>       ^^ this or is confusing a bit.
> 
> Does this mean that MT8195 has three RISC-V MCUs?

My intention is to express that current SCP driver supports bring-up,
1. the single core SCP, e.g. MT8183
2. the 1st core of dual-core SCP, e.g. MT8195


Perhaps rewriting as follows is preferable?

"The mediatek remoteproc driver currently only allows bringing up a single 
core SCP. It only supports bringing up the 1st core in SoCs with a dual-core SCP."
> 
> > the 2nd core of a dual-core SCP.
> 
> 
> 
> Best regards,
> Krzysztof

Re: [PATCH v1 00/15] Add support for MT8195 SCP 2nd core

[Tinghan Shen]

Hi Krzysztof,
 
On Wed, 2022-06-01 at 13:46 +0200, Krzysztof Kozlowski wrote:
> On 01/06/2022 13:21, Tinghan Shen wrote:
> > The MT8195 System Companion Processor(SCP) is a dual-core RISC-V MCU.
> > Current mediatek remoteproc driver only supports bring-up single core 
> > SCP or the 1st core of a dual-core SCP. This series support to bring-up 
> 
>       ^^ this or is confusing a bit.
> 
> Does this mean that MT8195 has three RISC-V MCUs?

My intention is to express that current SCP driver supports bring-up,
1. the single core SCP, e.g. MT8183
2. the 1st core of dual-core SCP, e.g. MT8195


Perhaps rewriting as follows is preferable?

"The mediatek remoteproc driver currently only allows bringing up a single 
core SCP. It only supports bringing up the 1st core in SoCs with a dual-core SCP."
> 
> > the 2nd core of a dual-core SCP.
> 
> 
> 
> Best regards,
> Krzysztof


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH v1 00/15] Add support for MT8195 SCP 2nd core

[Tinghan Shen]

Hi Krzysztof,
 
On Wed, 2022-06-01 at 13:46 +0200, Krzysztof Kozlowski wrote:
> On 01/06/2022 13:21, Tinghan Shen wrote:
> > The MT8195 System Companion Processor(SCP) is a dual-core RISC-V MCU.
> > Current mediatek remoteproc driver only supports bring-up single core 
> > SCP or the 1st core of a dual-core SCP. This series support to bring-up 
> 
>       ^^ this or is confusing a bit.
> 
> Does this mean that MT8195 has three RISC-V MCUs?

My intention is to express that current SCP driver supports bring-up,
1. the single core SCP, e.g. MT8183
2. the 1st core of dual-core SCP, e.g. MT8195


Perhaps rewriting as follows is preferable?

"The mediatek remoteproc driver currently only allows bringing up a single 
core SCP. It only supports bringing up the 1st core in SoCs with a dual-core SCP."
> 
> > the 2nd core of a dual-core SCP.
> 
> 
> 
> Best regards,
> Krzysztof


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

Re: [PATCH v1 01/15] dt-binding: remoteproc: mediatek: Support dual-core SCP

[Tinghan Shen]

Hi Krzysztof,

On Wed, 2022-06-01 at 13:50 +0200, Krzysztof Kozlowski wrote:
> On 01/06/2022 13:21, Tinghan Shen wrote:
> > The SCP co-processor is a dual-core RISC-V MCU on MT8195.
> > 
> > Add a new property to identify each core and helps to find drivers
> > through device tree API to cooperate with each other, e.g. boot flow and
> > watchdog timeout flow.
> > 
> > Add a new compatile for the driver of SCP 2nd core.
> > 
> > Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
> > ---
> >  .../devicetree/bindings/remoteproc/mtk,scp.yaml      | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > index eec3b9c4c713..b181786d9575 100644
> > --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > @@ -20,6 +20,7 @@ properties:
> >        - mediatek,mt8186-scp
> >        - mediatek,mt8192-scp
> >        - mediatek,mt8195-scp
> > +      - mediatek,mt8195-scp-dual
> >  
> >    reg:
> >      description:
> > @@ -57,6 +58,16 @@ properties:
> >    memory-region:
> >      maxItems: 1
> >  
> > +  mediatek,scp-core:
> > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > +    description:
> > +      The property value is a list with 2 items, a core id and a phandle
> 
> uint32, not phandle.
> 
> > +      to the sibling SCP node. 
> 
> Skip this. First part is obvious from the schema, second part should be
> described via items.
> 
> The core id represents the id of the dts node contains
> > +      this property. The valid values of core id are 0 and 1 for dual-core SCP.
> > +      The phandle of sibling SCP node is used to find the register settings,
> > +      trigger core dependent callback, and invoke rproc API.
> 
> Entire description did not help me to understand what's this. So far it
> looks like it is not a hardware property but some programming help, so
> it does not look like properly described in bindings.
> 
> > +    maxItems: 1
> 
> In description you said - two items.
> 
> You need allOf:if:then disallowing this property for other variants.
> 
> > +
> >  required:
> >    - compatible
> >    - reg
> > @@ -115,6 +126,7 @@ examples:
> >          reg-names = "sram", "cfg", "l1tcm";
> >          clocks = <&infracfg CLK_INFRA_SCPSYS>;
> >          clock-names = "main";
> > +        mediatek,scp-core = <0 &scp_dual>;
> 
> This looks like phandle, so wrong type.
> >  
> >          cros_ec {
> >              mediatek,rpmsg-name = "cros-ec-rpmsg";
> 

Thanks for your feedback.
After looking for a comparable uses case, I find out a different approach.

  mediatek,scp-core:
    $ref: "/schemas/types.yaml#/definitions/phandle-array"
    description:
      Enable the dual-core support in scp driver.
    items:
      - items:
          - description: Assign a core id for current scp node.
            enum: [0, 1]
          - description:
              Phandle of another SCP node. This helps to find
              the scp driver of another core to trigger core
              dependent callback, invoke rproc subdevice API, etc.

> 
> Best regards,
> Krzysztof

Re: [PATCH v1 01/15] dt-binding: remoteproc: mediatek: Support dual-core SCP

[Tinghan Shen]

Hi Krzysztof,

On Wed, 2022-06-01 at 13:50 +0200, Krzysztof Kozlowski wrote:
> On 01/06/2022 13:21, Tinghan Shen wrote:
> > The SCP co-processor is a dual-core RISC-V MCU on MT8195.
> > 
> > Add a new property to identify each core and helps to find drivers
> > through device tree API to cooperate with each other, e.g. boot flow and
> > watchdog timeout flow.
> > 
> > Add a new compatile for the driver of SCP 2nd core.
> > 
> > Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
> > ---
> >  .../devicetree/bindings/remoteproc/mtk,scp.yaml      | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > index eec3b9c4c713..b181786d9575 100644
> > --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > @@ -20,6 +20,7 @@ properties:
> >        - mediatek,mt8186-scp
> >        - mediatek,mt8192-scp
> >        - mediatek,mt8195-scp
> > +      - mediatek,mt8195-scp-dual
> >  
> >    reg:
> >      description:
> > @@ -57,6 +58,16 @@ properties:
> >    memory-region:
> >      maxItems: 1
> >  
> > +  mediatek,scp-core:
> > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > +    description:
> > +      The property value is a list with 2 items, a core id and a phandle
> 
> uint32, not phandle.
> 
> > +      to the sibling SCP node. 
> 
> Skip this. First part is obvious from the schema, second part should be
> described via items.
> 
> The core id represents the id of the dts node contains
> > +      this property. The valid values of core id are 0 and 1 for dual-core SCP.
> > +      The phandle of sibling SCP node is used to find the register settings,
> > +      trigger core dependent callback, and invoke rproc API.
> 
> Entire description did not help me to understand what's this. So far it
> looks like it is not a hardware property but some programming help, so
> it does not look like properly described in bindings.
> 
> > +    maxItems: 1
> 
> In description you said - two items.
> 
> You need allOf:if:then disallowing this property for other variants.
> 
> > +
> >  required:
> >    - compatible
> >    - reg
> > @@ -115,6 +126,7 @@ examples:
> >          reg-names = "sram", "cfg", "l1tcm";
> >          clocks = <&infracfg CLK_INFRA_SCPSYS>;
> >          clock-names = "main";
> > +        mediatek,scp-core = <0 &scp_dual>;
> 
> This looks like phandle, so wrong type.
> >  
> >          cros_ec {
> >              mediatek,rpmsg-name = "cros-ec-rpmsg";
> 

Thanks for your feedback.
After looking for a comparable uses case, I find out a different approach.

  mediatek,scp-core:
    $ref: "/schemas/types.yaml#/definitions/phandle-array"
    description:
      Enable the dual-core support in scp driver.
    items:
      - items:
          - description: Assign a core id for current scp node.
            enum: [0, 1]
          - description:
              Phandle of another SCP node. This helps to find
              the scp driver of another core to trigger core
              dependent callback, invoke rproc subdevice API, etc.

> 
> Best regards,
> Krzysztof


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH v1 01/15] dt-binding: remoteproc: mediatek: Support dual-core SCP

[Tinghan Shen]

Hi Krzysztof,

On Wed, 2022-06-01 at 13:50 +0200, Krzysztof Kozlowski wrote:
> On 01/06/2022 13:21, Tinghan Shen wrote:
> > The SCP co-processor is a dual-core RISC-V MCU on MT8195.
> > 
> > Add a new property to identify each core and helps to find drivers
> > through device tree API to cooperate with each other, e.g. boot flow and
> > watchdog timeout flow.
> > 
> > Add a new compatile for the driver of SCP 2nd core.
> > 
> > Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
> > ---
> >  .../devicetree/bindings/remoteproc/mtk,scp.yaml      | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > index eec3b9c4c713..b181786d9575 100644
> > --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > @@ -20,6 +20,7 @@ properties:
> >        - mediatek,mt8186-scp
> >        - mediatek,mt8192-scp
> >        - mediatek,mt8195-scp
> > +      - mediatek,mt8195-scp-dual
> >  
> >    reg:
> >      description:
> > @@ -57,6 +58,16 @@ properties:
> >    memory-region:
> >      maxItems: 1
> >  
> > +  mediatek,scp-core:
> > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > +    description:
> > +      The property value is a list with 2 items, a core id and a phandle
> 
> uint32, not phandle.
> 
> > +      to the sibling SCP node. 
> 
> Skip this. First part is obvious from the schema, second part should be
> described via items.
> 
> The core id represents the id of the dts node contains
> > +      this property. The valid values of core id are 0 and 1 for dual-core SCP.
> > +      The phandle of sibling SCP node is used to find the register settings,
> > +      trigger core dependent callback, and invoke rproc API.
> 
> Entire description did not help me to understand what's this. So far it
> looks like it is not a hardware property but some programming help, so
> it does not look like properly described in bindings.
> 
> > +    maxItems: 1
> 
> In description you said - two items.
> 
> You need allOf:if:then disallowing this property for other variants.
> 
> > +
> >  required:
> >    - compatible
> >    - reg
> > @@ -115,6 +126,7 @@ examples:
> >          reg-names = "sram", "cfg", "l1tcm";
> >          clocks = <&infracfg CLK_INFRA_SCPSYS>;
> >          clock-names = "main";
> > +        mediatek,scp-core = <0 &scp_dual>;
> 
> This looks like phandle, so wrong type.
> >  
> >          cros_ec {
> >              mediatek,rpmsg-name = "cros-ec-rpmsg";
> 

Thanks for your feedback.
After looking for a comparable uses case, I find out a different approach.

  mediatek,scp-core:
    $ref: "/schemas/types.yaml#/definitions/phandle-array"
    description:
      Enable the dual-core support in scp driver.
    items:
      - items:
          - description: Assign a core id for current scp node.
            enum: [0, 1]
          - description:
              Phandle of another SCP node. This helps to find
              the scp driver of another core to trigger core
              dependent callback, invoke rproc subdevice API, etc.

> 
> Best regards,
> Krzysztof


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

Re: [PATCH v1 01/15] dt-binding: remoteproc: mediatek: Support dual-core SCP

[Krzysztof Kozlowski]

On 02/06/2022 07:21, Tinghan Shen wrote:
> Hi Krzysztof,
> 
> On Wed, 2022-06-01 at 13:50 +0200, Krzysztof Kozlowski wrote:
>> On 01/06/2022 13:21, Tinghan Shen wrote:
>>> The SCP co-processor is a dual-core RISC-V MCU on MT8195.
>>>
>>> Add a new property to identify each core and helps to find drivers
>>> through device tree API to cooperate with each other, e.g. boot flow and
>>> watchdog timeout flow.
>>>
>>> Add a new compatile for the driver of SCP 2nd core.
>>>
>>> Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
>>> ---
>>>  .../devicetree/bindings/remoteproc/mtk,scp.yaml      | 12 ++++++++++++
>>>  1 file changed, 12 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
>>> b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
>>> index eec3b9c4c713..b181786d9575 100644
>>> --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
>>> +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
>>> @@ -20,6 +20,7 @@ properties:
>>>        - mediatek,mt8186-scp
>>>        - mediatek,mt8192-scp
>>>        - mediatek,mt8195-scp
>>> +      - mediatek,mt8195-scp-dual
>>>  
>>>    reg:
>>>      description:
>>> @@ -57,6 +58,16 @@ properties:
>>>    memory-region:
>>>      maxItems: 1
>>>  
>>> +  mediatek,scp-core:
>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>> +    description:
>>> +      The property value is a list with 2 items, a core id and a phandle
>>
>> uint32, not phandle.
>>
>>> +      to the sibling SCP node. 
>>
>> Skip this. First part is obvious from the schema, second part should be
>> described via items.
>>
>> The core id represents the id of the dts node contains
>>> +      this property. The valid values of core id are 0 and 1 for dual-core SCP.
>>> +      The phandle of sibling SCP node is used to find the register settings,
>>> +      trigger core dependent callback, and invoke rproc API.
>>
>> Entire description did not help me to understand what's this. So far it
>> looks like it is not a hardware property but some programming help, so
>> it does not look like properly described in bindings.
>>
>>> +    maxItems: 1
>>
>> In description you said - two items.
>>
>> You need allOf:if:then disallowing this property for other variants.
>>
>>> +
>>>  required:
>>>    - compatible
>>>    - reg
>>> @@ -115,6 +126,7 @@ examples:
>>>          reg-names = "sram", "cfg", "l1tcm";
>>>          clocks = <&infracfg CLK_INFRA_SCPSYS>;
>>>          clock-names = "main";
>>> +        mediatek,scp-core = <0 &scp_dual>;
>>
>> This looks like phandle, so wrong type.
>>>  
>>>          cros_ec {
>>>              mediatek,rpmsg-name = "cros-ec-rpmsg";
>>
> 
> Thanks for your feedback.
> After looking for a comparable uses case, I find out a different approach.
> 
>   mediatek,scp-core:
>     $ref: "/schemas/types.yaml#/definitions/phandle-array"
>     description:
>       Enable the dual-core support in scp driver.

You describe desired functional behavior, not the hardware. What is the
property about? If you just want to indicate this is two-core processor,
then it could be:
	mediatek,cores = <2>; /* number of cores */


However it seems you want to achieve here something different and as I
raised last time - it does not look like DT property.

Or maybe this is for first core and you want to indicate the sibling?
Something like that was mentioned in previous description.


>     items:
>       - items:
>           - description: Assign a core id for current scp node.
>             enum: [0, 1]
>           - description:
>               Phandle of another SCP node. This helps to find
>               the scp driver of another core to trigger core
>               dependent callback, invoke rproc subdevice API, etc.

Items should be rather reversed, as [0,1] being the argument to phandle
for a provider (see examples with syscon)...

Best regards,
Krzysztof

Re: [PATCH v1 01/15] dt-binding: remoteproc: mediatek: Support dual-core SCP

[Krzysztof Kozlowski]

On 02/06/2022 07:21, Tinghan Shen wrote:
> Hi Krzysztof,
> 
> On Wed, 2022-06-01 at 13:50 +0200, Krzysztof Kozlowski wrote:
>> On 01/06/2022 13:21, Tinghan Shen wrote:
>>> The SCP co-processor is a dual-core RISC-V MCU on MT8195.
>>>
>>> Add a new property to identify each core and helps to find drivers
>>> through device tree API to cooperate with each other, e.g. boot flow and
>>> watchdog timeout flow.
>>>
>>> Add a new compatile for the driver of SCP 2nd core.
>>>
>>> Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
>>> ---
>>>  .../devicetree/bindings/remoteproc/mtk,scp.yaml      | 12 ++++++++++++
>>>  1 file changed, 12 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
>>> b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
>>> index eec3b9c4c713..b181786d9575 100644
>>> --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
>>> +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
>>> @@ -20,6 +20,7 @@ properties:
>>>        - mediatek,mt8186-scp
>>>        - mediatek,mt8192-scp
>>>        - mediatek,mt8195-scp
>>> +      - mediatek,mt8195-scp-dual
>>>  
>>>    reg:
>>>      description:
>>> @@ -57,6 +58,16 @@ properties:
>>>    memory-region:
>>>      maxItems: 1
>>>  
>>> +  mediatek,scp-core:
>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>> +    description:
>>> +      The property value is a list with 2 items, a core id and a phandle
>>
>> uint32, not phandle.
>>
>>> +      to the sibling SCP node. 
>>
>> Skip this. First part is obvious from the schema, second part should be
>> described via items.
>>
>> The core id represents the id of the dts node contains
>>> +      this property. The valid values of core id are 0 and 1 for dual-core SCP.
>>> +      The phandle of sibling SCP node is used to find the register settings,
>>> +      trigger core dependent callback, and invoke rproc API.
>>
>> Entire description did not help me to understand what's this. So far it
>> looks like it is not a hardware property but some programming help, so
>> it does not look like properly described in bindings.
>>
>>> +    maxItems: 1
>>
>> In description you said - two items.
>>
>> You need allOf:if:then disallowing this property for other variants.
>>
>>> +
>>>  required:
>>>    - compatible
>>>    - reg
>>> @@ -115,6 +126,7 @@ examples:
>>>          reg-names = "sram", "cfg", "l1tcm";
>>>          clocks = <&infracfg CLK_INFRA_SCPSYS>;
>>>          clock-names = "main";
>>> +        mediatek,scp-core = <0 &scp_dual>;
>>
>> This looks like phandle, so wrong type.
>>>  
>>>          cros_ec {
>>>              mediatek,rpmsg-name = "cros-ec-rpmsg";
>>
> 
> Thanks for your feedback.
> After looking for a comparable uses case, I find out a different approach.
> 
>   mediatek,scp-core:
>     $ref: "/schemas/types.yaml#/definitions/phandle-array"
>     description:
>       Enable the dual-core support in scp driver.

You describe desired functional behavior, not the hardware. What is the
property about? If you just want to indicate this is two-core processor,
then it could be:
	mediatek,cores = <2>; /* number of cores */


However it seems you want to achieve here something different and as I
raised last time - it does not look like DT property.

Or maybe this is for first core and you want to indicate the sibling?
Something like that was mentioned in previous description.


>     items:
>       - items:
>           - description: Assign a core id for current scp node.
>             enum: [0, 1]
>           - description:
>               Phandle of another SCP node. This helps to find
>               the scp driver of another core to trigger core
>               dependent callback, invoke rproc subdevice API, etc.

Items should be rather reversed, as [0,1] being the argument to phandle
for a provider (see examples with syscon)...

Best regards,
Krzysztof

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH v1 01/15] dt-binding: remoteproc: mediatek: Support dual-core SCP

[Krzysztof Kozlowski]

On 02/06/2022 07:21, Tinghan Shen wrote:
> Hi Krzysztof,
> 
> On Wed, 2022-06-01 at 13:50 +0200, Krzysztof Kozlowski wrote:
>> On 01/06/2022 13:21, Tinghan Shen wrote:
>>> The SCP co-processor is a dual-core RISC-V MCU on MT8195.
>>>
>>> Add a new property to identify each core and helps to find drivers
>>> through device tree API to cooperate with each other, e.g. boot flow and
>>> watchdog timeout flow.
>>>
>>> Add a new compatile for the driver of SCP 2nd core.
>>>
>>> Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
>>> ---
>>>  .../devicetree/bindings/remoteproc/mtk,scp.yaml      | 12 ++++++++++++
>>>  1 file changed, 12 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
>>> b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
>>> index eec3b9c4c713..b181786d9575 100644
>>> --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
>>> +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
>>> @@ -20,6 +20,7 @@ properties:
>>>        - mediatek,mt8186-scp
>>>        - mediatek,mt8192-scp
>>>        - mediatek,mt8195-scp
>>> +      - mediatek,mt8195-scp-dual
>>>  
>>>    reg:
>>>      description:
>>> @@ -57,6 +58,16 @@ properties:
>>>    memory-region:
>>>      maxItems: 1
>>>  
>>> +  mediatek,scp-core:
>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>> +    description:
>>> +      The property value is a list with 2 items, a core id and a phandle
>>
>> uint32, not phandle.
>>
>>> +      to the sibling SCP node. 
>>
>> Skip this. First part is obvious from the schema, second part should be
>> described via items.
>>
>> The core id represents the id of the dts node contains
>>> +      this property. The valid values of core id are 0 and 1 for dual-core SCP.
>>> +      The phandle of sibling SCP node is used to find the register settings,
>>> +      trigger core dependent callback, and invoke rproc API.
>>
>> Entire description did not help me to understand what's this. So far it
>> looks like it is not a hardware property but some programming help, so
>> it does not look like properly described in bindings.
>>
>>> +    maxItems: 1
>>
>> In description you said - two items.
>>
>> You need allOf:if:then disallowing this property for other variants.
>>
>>> +
>>>  required:
>>>    - compatible
>>>    - reg
>>> @@ -115,6 +126,7 @@ examples:
>>>          reg-names = "sram", "cfg", "l1tcm";
>>>          clocks = <&infracfg CLK_INFRA_SCPSYS>;
>>>          clock-names = "main";
>>> +        mediatek,scp-core = <0 &scp_dual>;
>>
>> This looks like phandle, so wrong type.
>>>  
>>>          cros_ec {
>>>              mediatek,rpmsg-name = "cros-ec-rpmsg";
>>
> 
> Thanks for your feedback.
> After looking for a comparable uses case, I find out a different approach.
> 
>   mediatek,scp-core:
>     $ref: "/schemas/types.yaml#/definitions/phandle-array"
>     description:
>       Enable the dual-core support in scp driver.

You describe desired functional behavior, not the hardware. What is the
property about? If you just want to indicate this is two-core processor,
then it could be:
	mediatek,cores = <2>; /* number of cores */


However it seems you want to achieve here something different and as I
raised last time - it does not look like DT property.

Or maybe this is for first core and you want to indicate the sibling?
Something like that was mentioned in previous description.


>     items:
>       - items:
>           - description: Assign a core id for current scp node.
>             enum: [0, 1]
>           - description:
>               Phandle of another SCP node. This helps to find
>               the scp driver of another core to trigger core
>               dependent callback, invoke rproc subdevice API, etc.

Items should be rather reversed, as [0,1] being the argument to phandle
for a provider (see examples with syscon)...

Best regards,
Krzysztof

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

Re: [PATCH v1 00/15] Add support for MT8195 SCP 2nd core

[Krzysztof Kozlowski]

On 02/06/2022 05:52, Tinghan Shen wrote:
> Hi Krzysztof,
>  
> On Wed, 2022-06-01 at 13:46 +0200, Krzysztof Kozlowski wrote:
>> On 01/06/2022 13:21, Tinghan Shen wrote:
>>> The MT8195 System Companion Processor(SCP) is a dual-core RISC-V MCU.
>>> Current mediatek remoteproc driver only supports bring-up single core 
>>> SCP or the 1st core of a dual-core SCP. This series support to bring-up 
>>
>>       ^^ this or is confusing a bit.
>>
>> Does this mean that MT8195 has three RISC-V MCUs?
> 
> My intention is to express that current SCP driver supports bring-up,
> 1. the single core SCP, e.g. MT8183
> 2. the 1st core of dual-core SCP, e.g. MT8195
> 
> 
> Perhaps rewriting as follows is preferable?
> 
> "The mediatek remoteproc driver currently only allows bringing up a single 
> core SCP. It only supports bringing up the 1st core in SoCs with a dual-core SCP."
>>

Yes, that sounds better. Or mention that single core case is for MT8183,
because that part got me confused.


Best regards,
Krzysztof

Re: [PATCH v1 00/15] Add support for MT8195 SCP 2nd core

[Krzysztof Kozlowski]

On 02/06/2022 05:52, Tinghan Shen wrote:
> Hi Krzysztof,
>  
> On Wed, 2022-06-01 at 13:46 +0200, Krzysztof Kozlowski wrote:
>> On 01/06/2022 13:21, Tinghan Shen wrote:
>>> The MT8195 System Companion Processor(SCP) is a dual-core RISC-V MCU.
>>> Current mediatek remoteproc driver only supports bring-up single core 
>>> SCP or the 1st core of a dual-core SCP. This series support to bring-up 
>>
>>       ^^ this or is confusing a bit.
>>
>> Does this mean that MT8195 has three RISC-V MCUs?
> 
> My intention is to express that current SCP driver supports bring-up,
> 1. the single core SCP, e.g. MT8183
> 2. the 1st core of dual-core SCP, e.g. MT8195
> 
> 
> Perhaps rewriting as follows is preferable?
> 
> "The mediatek remoteproc driver currently only allows bringing up a single 
> core SCP. It only supports bringing up the 1st core in SoCs with a dual-core SCP."
>>

Yes, that sounds better. Or mention that single core case is for MT8183,
because that part got me confused.


Best regards,
Krzysztof

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH v1 00/15] Add support for MT8195 SCP 2nd core

[Krzysztof Kozlowski]

On 02/06/2022 05:52, Tinghan Shen wrote:
> Hi Krzysztof,
>  
> On Wed, 2022-06-01 at 13:46 +0200, Krzysztof Kozlowski wrote:
>> On 01/06/2022 13:21, Tinghan Shen wrote:
>>> The MT8195 System Companion Processor(SCP) is a dual-core RISC-V MCU.
>>> Current mediatek remoteproc driver only supports bring-up single core 
>>> SCP or the 1st core of a dual-core SCP. This series support to bring-up 
>>
>>       ^^ this or is confusing a bit.
>>
>> Does this mean that MT8195 has three RISC-V MCUs?
> 
> My intention is to express that current SCP driver supports bring-up,
> 1. the single core SCP, e.g. MT8183
> 2. the 1st core of dual-core SCP, e.g. MT8195
> 
> 
> Perhaps rewriting as follows is preferable?
> 
> "The mediatek remoteproc driver currently only allows bringing up a single 
> core SCP. It only supports bringing up the 1st core in SoCs with a dual-core SCP."
>>

Yes, that sounds better. Or mention that single core case is for MT8183,
because that part got me confused.


Best regards,
Krzysztof

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

Re: [PATCH v1 01/15] dt-binding: remoteproc: mediatek: Support dual-core SCP

[Tinghan Shen]

Hi Krzysztof,

On Thu, 2022-06-02 at 08:55 +0200, Krzysztof Kozlowski wrote:
> On 02/06/2022 07:21, Tinghan Shen wrote:
> > Hi Krzysztof,
> > 
> > On Wed, 2022-06-01 at 13:50 +0200, Krzysztof Kozlowski wrote:
> > > On 01/06/2022 13:21, Tinghan Shen wrote:
> > > > The SCP co-processor is a dual-core RISC-V MCU on MT8195.
> > > > 
> > > > Add a new property to identify each core and helps to find drivers
> > > > through device tree API to cooperate with each other, e.g. boot flow and
> > > > watchdog timeout flow.
> > > > 
> > > > Add a new compatile for the driver of SCP 2nd core.
> > > > 
> > > > Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
> > > > ---
> > > >  .../devicetree/bindings/remoteproc/mtk,scp.yaml      | 12 ++++++++++++
> > > >  1 file changed, 12 insertions(+)
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > > > b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > > > index eec3b9c4c713..b181786d9575 100644
> > > > --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > > > +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > > > @@ -20,6 +20,7 @@ properties:
> > > >        - mediatek,mt8186-scp
> > > >        - mediatek,mt8192-scp
> > > >        - mediatek,mt8195-scp
> > > > +      - mediatek,mt8195-scp-dual
> > > >  
> > > >    reg:
> > > >      description:
> > > > @@ -57,6 +58,16 @@ properties:
> > > >    memory-region:
> > > >      maxItems: 1
> > > >  
> > > > +  mediatek,scp-core:
> > > > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > > > +    description:
> > > > +      The property value is a list with 2 items, a core id and a phandle
> > > 
> > > uint32, not phandle.
> > > 
> > > > +      to the sibling SCP node. 
> > > 
> > > Skip this. First part is obvious from the schema, second part should be
> > > described via items.
> > > 
> > > The core id represents the id of the dts node contains
> > > > +      this property. The valid values of core id are 0 and 1 for dual-core SCP.
> > > > +      The phandle of sibling SCP node is used to find the register settings,
> > > > +      trigger core dependent callback, and invoke rproc API.
> > > 
> > > Entire description did not help me to understand what's this. So far it
> > > looks like it is not a hardware property but some programming help, so
> > > it does not look like properly described in bindings.
> > > 
> > > > +    maxItems: 1
> > > 
> > > In description you said - two items.
> > > 
> > > You need allOf:if:then disallowing this property for other variants.
> > > 
> > > > +
> > > >  required:
> > > >    - compatible
> > > >    - reg
> > > > @@ -115,6 +126,7 @@ examples:
> > > >          reg-names = "sram", "cfg", "l1tcm";
> > > >          clocks = <&infracfg CLK_INFRA_SCPSYS>;
> > > >          clock-names = "main";
> > > > +        mediatek,scp-core = <0 &scp_dual>;
> > > 
> > > This looks like phandle, so wrong type.
> > > >  
> > > >          cros_ec {
> > > >              mediatek,rpmsg-name = "cros-ec-rpmsg";
> > 
> > Thanks for your feedback.
> > After looking for a comparable uses case, I find out a different approach.
> > 
> >   mediatek,scp-core:
> >     $ref: "/schemas/types.yaml#/definitions/phandle-array"
> >     description:
> >       Enable the dual-core support in scp driver.
> 
> You describe desired functional behavior, not the hardware. What is the
> property about? If you just want to indicate this is two-core processor,
> then it could be:
> 	mediatek,cores = <2>; /* number of cores */
> 
> 
> However it seems you want to achieve here something different and as I
> raised last time - it does not look like DT property.
> 
> Or maybe this is for first core and you want to indicate the sibling?
> Something like that was mentioned in previous description.

This property is mainly added for scp 1st core driver 
and scp 2nd core driver to find each other via DT API.

After reconsidering the use of core id in the scp driver, it 
is not necessary in the control flow. I'll remove the core id 
at next version.

How about change the description as following,

  This property enables the dual-core support in scp driver.
  By providing the phandle of SCP 2nd core node, the 1st SCP node
  can control the SCP 2nd core as the subdevice of remoteproc framework.


Thanks,
Tinghan

> 
> 
> >     items:
> >       - items:
> >           - description: Assign a core id for current scp node.
> >             enum: [0, 1]
> >           - description:
> >               Phandle of another SCP node. This helps to find
> >               the scp driver of another core to trigger core
> >               dependent callback, invoke rproc subdevice API, etc.
> 
> Items should be rather reversed, as [0,1] being the argument to phandle
> for a provider (see examples with syscon)...
> 
> Best regards,
> Krzysztof

Re: [PATCH v1 01/15] dt-binding: remoteproc: mediatek: Support dual-core SCP

[Tinghan Shen]

Hi Krzysztof,

On Thu, 2022-06-02 at 08:55 +0200, Krzysztof Kozlowski wrote:
> On 02/06/2022 07:21, Tinghan Shen wrote:
> > Hi Krzysztof,
> > 
> > On Wed, 2022-06-01 at 13:50 +0200, Krzysztof Kozlowski wrote:
> > > On 01/06/2022 13:21, Tinghan Shen wrote:
> > > > The SCP co-processor is a dual-core RISC-V MCU on MT8195.
> > > > 
> > > > Add a new property to identify each core and helps to find drivers
> > > > through device tree API to cooperate with each other, e.g. boot flow and
> > > > watchdog timeout flow.
> > > > 
> > > > Add a new compatile for the driver of SCP 2nd core.
> > > > 
> > > > Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
> > > > ---
> > > >  .../devicetree/bindings/remoteproc/mtk,scp.yaml      | 12 ++++++++++++
> > > >  1 file changed, 12 insertions(+)
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > > > b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > > > index eec3b9c4c713..b181786d9575 100644
> > > > --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > > > +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > > > @@ -20,6 +20,7 @@ properties:
> > > >        - mediatek,mt8186-scp
> > > >        - mediatek,mt8192-scp
> > > >        - mediatek,mt8195-scp
> > > > +      - mediatek,mt8195-scp-dual
> > > >  
> > > >    reg:
> > > >      description:
> > > > @@ -57,6 +58,16 @@ properties:
> > > >    memory-region:
> > > >      maxItems: 1
> > > >  
> > > > +  mediatek,scp-core:
> > > > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > > > +    description:
> > > > +      The property value is a list with 2 items, a core id and a phandle
> > > 
> > > uint32, not phandle.
> > > 
> > > > +      to the sibling SCP node. 
> > > 
> > > Skip this. First part is obvious from the schema, second part should be
> > > described via items.
> > > 
> > > The core id represents the id of the dts node contains
> > > > +      this property. The valid values of core id are 0 and 1 for dual-core SCP.
> > > > +      The phandle of sibling SCP node is used to find the register settings,
> > > > +      trigger core dependent callback, and invoke rproc API.
> > > 
> > > Entire description did not help me to understand what's this. So far it
> > > looks like it is not a hardware property but some programming help, so
> > > it does not look like properly described in bindings.
> > > 
> > > > +    maxItems: 1
> > > 
> > > In description you said - two items.
> > > 
> > > You need allOf:if:then disallowing this property for other variants.
> > > 
> > > > +
> > > >  required:
> > > >    - compatible
> > > >    - reg
> > > > @@ -115,6 +126,7 @@ examples:
> > > >          reg-names = "sram", "cfg", "l1tcm";
> > > >          clocks = <&infracfg CLK_INFRA_SCPSYS>;
> > > >          clock-names = "main";
> > > > +        mediatek,scp-core = <0 &scp_dual>;
> > > 
> > > This looks like phandle, so wrong type.
> > > >  
> > > >          cros_ec {
> > > >              mediatek,rpmsg-name = "cros-ec-rpmsg";
> > 
> > Thanks for your feedback.
> > After looking for a comparable uses case, I find out a different approach.
> > 
> >   mediatek,scp-core:
> >     $ref: "/schemas/types.yaml#/definitions/phandle-array"
> >     description:
> >       Enable the dual-core support in scp driver.
> 
> You describe desired functional behavior, not the hardware. What is the
> property about? If you just want to indicate this is two-core processor,
> then it could be:
> 	mediatek,cores = <2>; /* number of cores */
> 
> 
> However it seems you want to achieve here something different and as I
> raised last time - it does not look like DT property.
> 
> Or maybe this is for first core and you want to indicate the sibling?
> Something like that was mentioned in previous description.

This property is mainly added for scp 1st core driver 
and scp 2nd core driver to find each other via DT API.

After reconsidering the use of core id in the scp driver, it 
is not necessary in the control flow. I'll remove the core id 
at next version.

How about change the description as following,

  This property enables the dual-core support in scp driver.
  By providing the phandle of SCP 2nd core node, the 1st SCP node
  can control the SCP 2nd core as the subdevice of remoteproc framework.


Thanks,
Tinghan

> 
> 
> >     items:
> >       - items:
> >           - description: Assign a core id for current scp node.
> >             enum: [0, 1]
> >           - description:
> >               Phandle of another SCP node. This helps to find
> >               the scp driver of another core to trigger core
> >               dependent callback, invoke rproc subdevice API, etc.
> 
> Items should be rather reversed, as [0,1] being the argument to phandle
> for a provider (see examples with syscon)...
> 
> Best regards,
> Krzysztof


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH v1 01/15] dt-binding: remoteproc: mediatek: Support dual-core SCP

[Tinghan Shen]

Hi Krzysztof,

On Thu, 2022-06-02 at 08:55 +0200, Krzysztof Kozlowski wrote:
> On 02/06/2022 07:21, Tinghan Shen wrote:
> > Hi Krzysztof,
> > 
> > On Wed, 2022-06-01 at 13:50 +0200, Krzysztof Kozlowski wrote:
> > > On 01/06/2022 13:21, Tinghan Shen wrote:
> > > > The SCP co-processor is a dual-core RISC-V MCU on MT8195.
> > > > 
> > > > Add a new property to identify each core and helps to find drivers
> > > > through device tree API to cooperate with each other, e.g. boot flow and
> > > > watchdog timeout flow.
> > > > 
> > > > Add a new compatile for the driver of SCP 2nd core.
> > > > 
> > > > Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
> > > > ---
> > > >  .../devicetree/bindings/remoteproc/mtk,scp.yaml      | 12 ++++++++++++
> > > >  1 file changed, 12 insertions(+)
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > > > b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > > > index eec3b9c4c713..b181786d9575 100644
> > > > --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > > > +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > > > @@ -20,6 +20,7 @@ properties:
> > > >        - mediatek,mt8186-scp
> > > >        - mediatek,mt8192-scp
> > > >        - mediatek,mt8195-scp
> > > > +      - mediatek,mt8195-scp-dual
> > > >  
> > > >    reg:
> > > >      description:
> > > > @@ -57,6 +58,16 @@ properties:
> > > >    memory-region:
> > > >      maxItems: 1
> > > >  
> > > > +  mediatek,scp-core:
> > > > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > > > +    description:
> > > > +      The property value is a list with 2 items, a core id and a phandle
> > > 
> > > uint32, not phandle.
> > > 
> > > > +      to the sibling SCP node. 
> > > 
> > > Skip this. First part is obvious from the schema, second part should be
> > > described via items.
> > > 
> > > The core id represents the id of the dts node contains
> > > > +      this property. The valid values of core id are 0 and 1 for dual-core SCP.
> > > > +      The phandle of sibling SCP node is used to find the register settings,
> > > > +      trigger core dependent callback, and invoke rproc API.
> > > 
> > > Entire description did not help me to understand what's this. So far it
> > > looks like it is not a hardware property but some programming help, so
> > > it does not look like properly described in bindings.
> > > 
> > > > +    maxItems: 1
> > > 
> > > In description you said - two items.
> > > 
> > > You need allOf:if:then disallowing this property for other variants.
> > > 
> > > > +
> > > >  required:
> > > >    - compatible
> > > >    - reg
> > > > @@ -115,6 +126,7 @@ examples:
> > > >          reg-names = "sram", "cfg", "l1tcm";
> > > >          clocks = <&infracfg CLK_INFRA_SCPSYS>;
> > > >          clock-names = "main";
> > > > +        mediatek,scp-core = <0 &scp_dual>;
> > > 
> > > This looks like phandle, so wrong type.
> > > >  
> > > >          cros_ec {
> > > >              mediatek,rpmsg-name = "cros-ec-rpmsg";
> > 
> > Thanks for your feedback.
> > After looking for a comparable uses case, I find out a different approach.
> > 
> >   mediatek,scp-core:
> >     $ref: "/schemas/types.yaml#/definitions/phandle-array"
> >     description:
> >       Enable the dual-core support in scp driver.
> 
> You describe desired functional behavior, not the hardware. What is the
> property about? If you just want to indicate this is two-core processor,
> then it could be:
> 	mediatek,cores = <2>; /* number of cores */
> 
> 
> However it seems you want to achieve here something different and as I
> raised last time - it does not look like DT property.
> 
> Or maybe this is for first core and you want to indicate the sibling?
> Something like that was mentioned in previous description.

This property is mainly added for scp 1st core driver 
and scp 2nd core driver to find each other via DT API.

After reconsidering the use of core id in the scp driver, it 
is not necessary in the control flow. I'll remove the core id 
at next version.

How about change the description as following,

  This property enables the dual-core support in scp driver.
  By providing the phandle of SCP 2nd core node, the 1st SCP node
  can control the SCP 2nd core as the subdevice of remoteproc framework.


Thanks,
Tinghan

> 
> 
> >     items:
> >       - items:
> >           - description: Assign a core id for current scp node.
> >             enum: [0, 1]
> >           - description:
> >               Phandle of another SCP node. This helps to find
> >               the scp driver of another core to trigger core
> >               dependent callback, invoke rproc subdevice API, etc.
> 
> Items should be rather reversed, as [0,1] being the argument to phandle
> for a provider (see examples with syscon)...
> 
> Best regards,
> Krzysztof


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

Re: [PATCH v1 01/15] dt-binding: remoteproc: mediatek: Support dual-core SCP

[Krzysztof Kozlowski]

On 02/06/2022 10:58, Tinghan Shen wrote:
> Hi Krzysztof,
> 
> On Thu, 2022-06-02 at 08:55 +0200, Krzysztof Kozlowski wrote:
>> On 02/06/2022 07:21, Tinghan Shen wrote:
>>> Hi Krzysztof,
>>>
>>> On Wed, 2022-06-01 at 13:50 +0200, Krzysztof Kozlowski wrote:
>>>> On 01/06/2022 13:21, Tinghan Shen wrote:
>>>>> The SCP co-processor is a dual-core RISC-V MCU on MT8195.
>>>>>
>>>>> Add a new property to identify each core and helps to find drivers
>>>>> through device tree API to cooperate with each other, e.g. boot flow and
>>>>> watchdog timeout flow.
>>>>>
>>>>> Add a new compatile for the driver of SCP 2nd core.
>>>>>
>>>>> Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
>>>>> ---
>>>>>  .../devicetree/bindings/remoteproc/mtk,scp.yaml      | 12 ++++++++++++
>>>>>  1 file changed, 12 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
>>>>> b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
>>>>> index eec3b9c4c713..b181786d9575 100644
>>>>> --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
>>>>> +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
>>>>> @@ -20,6 +20,7 @@ properties:
>>>>>        - mediatek,mt8186-scp
>>>>>        - mediatek,mt8192-scp
>>>>>        - mediatek,mt8195-scp
>>>>> +      - mediatek,mt8195-scp-dual
>>>>>  
>>>>>    reg:
>>>>>      description:
>>>>> @@ -57,6 +58,16 @@ properties:
>>>>>    memory-region:
>>>>>      maxItems: 1
>>>>>  
>>>>> +  mediatek,scp-core:
>>>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>>>> +    description:
>>>>> +      The property value is a list with 2 items, a core id and a phandle
>>>>
>>>> uint32, not phandle.
>>>>
>>>>> +      to the sibling SCP node. 
>>>>
>>>> Skip this. First part is obvious from the schema, second part should be
>>>> described via items.
>>>>
>>>> The core id represents the id of the dts node contains
>>>>> +      this property. The valid values of core id are 0 and 1 for dual-core SCP.
>>>>> +      The phandle of sibling SCP node is used to find the register settings,
>>>>> +      trigger core dependent callback, and invoke rproc API.
>>>>
>>>> Entire description did not help me to understand what's this. So far it
>>>> looks like it is not a hardware property but some programming help, so
>>>> it does not look like properly described in bindings.
>>>>
>>>>> +    maxItems: 1
>>>>
>>>> In description you said - two items.
>>>>
>>>> You need allOf:if:then disallowing this property for other variants.
>>>>
>>>>> +
>>>>>  required:
>>>>>    - compatible
>>>>>    - reg
>>>>> @@ -115,6 +126,7 @@ examples:
>>>>>          reg-names = "sram", "cfg", "l1tcm";
>>>>>          clocks = <&infracfg CLK_INFRA_SCPSYS>;
>>>>>          clock-names = "main";
>>>>> +        mediatek,scp-core = <0 &scp_dual>;
>>>>
>>>> This looks like phandle, so wrong type.
>>>>>  
>>>>>          cros_ec {
>>>>>              mediatek,rpmsg-name = "cros-ec-rpmsg";
>>>
>>> Thanks for your feedback.
>>> After looking for a comparable uses case, I find out a different approach.
>>>
>>>   mediatek,scp-core:
>>>     $ref: "/schemas/types.yaml#/definitions/phandle-array"
>>>     description:
>>>       Enable the dual-core support in scp driver.
>>
>> You describe desired functional behavior, not the hardware. What is the
>> property about? If you just want to indicate this is two-core processor,
>> then it could be:
>> 	mediatek,cores = <2>; /* number of cores */
>>
>>
>> However it seems you want to achieve here something different and as I
>> raised last time - it does not look like DT property.
>>
>> Or maybe this is for first core and you want to indicate the sibling?
>> Something like that was mentioned in previous description.
> 
> This property is mainly added for scp 1st core driver 
> and scp 2nd core driver to find each other via DT API.
> 
> After reconsidering the use of core id in the scp driver, it 
> is not necessary in the control flow. I'll remove the core id 
> at next version.
> 
> How about change the description as following,
> 
>   This property enables the dual-core support in scp driver.
>   By providing the phandle of SCP 2nd core node, the 1st SCP node
>   can control the SCP 2nd core as the subdevice of remoteproc framework.

Please, read it again:

>> You describe desired functional behavior, not the hardware.

Again, you describe Linux implementation (scp driver, remoteproc
framework). You need to describe the hardware, not Linux drivers.

Maybe the hardware property is that one core has its sibling and you
provide here that sibling?


Best regards,
Krzysztof

Re: [PATCH v1 01/15] dt-binding: remoteproc: mediatek: Support dual-core SCP

[Krzysztof Kozlowski]

On 02/06/2022 10:58, Tinghan Shen wrote:
> Hi Krzysztof,
> 
> On Thu, 2022-06-02 at 08:55 +0200, Krzysztof Kozlowski wrote:
>> On 02/06/2022 07:21, Tinghan Shen wrote:
>>> Hi Krzysztof,
>>>
>>> On Wed, 2022-06-01 at 13:50 +0200, Krzysztof Kozlowski wrote:
>>>> On 01/06/2022 13:21, Tinghan Shen wrote:
>>>>> The SCP co-processor is a dual-core RISC-V MCU on MT8195.
>>>>>
>>>>> Add a new property to identify each core and helps to find drivers
>>>>> through device tree API to cooperate with each other, e.g. boot flow and
>>>>> watchdog timeout flow.
>>>>>
>>>>> Add a new compatile for the driver of SCP 2nd core.
>>>>>
>>>>> Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
>>>>> ---
>>>>>  .../devicetree/bindings/remoteproc/mtk,scp.yaml      | 12 ++++++++++++
>>>>>  1 file changed, 12 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
>>>>> b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
>>>>> index eec3b9c4c713..b181786d9575 100644
>>>>> --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
>>>>> +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
>>>>> @@ -20,6 +20,7 @@ properties:
>>>>>        - mediatek,mt8186-scp
>>>>>        - mediatek,mt8192-scp
>>>>>        - mediatek,mt8195-scp
>>>>> +      - mediatek,mt8195-scp-dual
>>>>>  
>>>>>    reg:
>>>>>      description:
>>>>> @@ -57,6 +58,16 @@ properties:
>>>>>    memory-region:
>>>>>      maxItems: 1
>>>>>  
>>>>> +  mediatek,scp-core:
>>>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>>>> +    description:
>>>>> +      The property value is a list with 2 items, a core id and a phandle
>>>>
>>>> uint32, not phandle.
>>>>
>>>>> +      to the sibling SCP node. 
>>>>
>>>> Skip this. First part is obvious from the schema, second part should be
>>>> described via items.
>>>>
>>>> The core id represents the id of the dts node contains
>>>>> +      this property. The valid values of core id are 0 and 1 for dual-core SCP.
>>>>> +      The phandle of sibling SCP node is used to find the register settings,
>>>>> +      trigger core dependent callback, and invoke rproc API.
>>>>
>>>> Entire description did not help me to understand what's this. So far it
>>>> looks like it is not a hardware property but some programming help, so
>>>> it does not look like properly described in bindings.
>>>>
>>>>> +    maxItems: 1
>>>>
>>>> In description you said - two items.
>>>>
>>>> You need allOf:if:then disallowing this property for other variants.
>>>>
>>>>> +
>>>>>  required:
>>>>>    - compatible
>>>>>    - reg
>>>>> @@ -115,6 +126,7 @@ examples:
>>>>>          reg-names = "sram", "cfg", "l1tcm";
>>>>>          clocks = <&infracfg CLK_INFRA_SCPSYS>;
>>>>>          clock-names = "main";
>>>>> +        mediatek,scp-core = <0 &scp_dual>;
>>>>
>>>> This looks like phandle, so wrong type.
>>>>>  
>>>>>          cros_ec {
>>>>>              mediatek,rpmsg-name = "cros-ec-rpmsg";
>>>
>>> Thanks for your feedback.
>>> After looking for a comparable uses case, I find out a different approach.
>>>
>>>   mediatek,scp-core:
>>>     $ref: "/schemas/types.yaml#/definitions/phandle-array"
>>>     description:
>>>       Enable the dual-core support in scp driver.
>>
>> You describe desired functional behavior, not the hardware. What is the
>> property about? If you just want to indicate this is two-core processor,
>> then it could be:
>> 	mediatek,cores = <2>; /* number of cores */
>>
>>
>> However it seems you want to achieve here something different and as I
>> raised last time - it does not look like DT property.
>>
>> Or maybe this is for first core and you want to indicate the sibling?
>> Something like that was mentioned in previous description.
> 
> This property is mainly added for scp 1st core driver 
> and scp 2nd core driver to find each other via DT API.
> 
> After reconsidering the use of core id in the scp driver, it 
> is not necessary in the control flow. I'll remove the core id 
> at next version.
> 
> How about change the description as following,
> 
>   This property enables the dual-core support in scp driver.
>   By providing the phandle of SCP 2nd core node, the 1st SCP node
>   can control the SCP 2nd core as the subdevice of remoteproc framework.

Please, read it again:

>> You describe desired functional behavior, not the hardware.

Again, you describe Linux implementation (scp driver, remoteproc
framework). You need to describe the hardware, not Linux drivers.

Maybe the hardware property is that one core has its sibling and you
provide here that sibling?


Best regards,
Krzysztof

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH v1 01/15] dt-binding: remoteproc: mediatek: Support dual-core SCP

[Krzysztof Kozlowski]

On 02/06/2022 10:58, Tinghan Shen wrote:
> Hi Krzysztof,
> 
> On Thu, 2022-06-02 at 08:55 +0200, Krzysztof Kozlowski wrote:
>> On 02/06/2022 07:21, Tinghan Shen wrote:
>>> Hi Krzysztof,
>>>
>>> On Wed, 2022-06-01 at 13:50 +0200, Krzysztof Kozlowski wrote:
>>>> On 01/06/2022 13:21, Tinghan Shen wrote:
>>>>> The SCP co-processor is a dual-core RISC-V MCU on MT8195.
>>>>>
>>>>> Add a new property to identify each core and helps to find drivers
>>>>> through device tree API to cooperate with each other, e.g. boot flow and
>>>>> watchdog timeout flow.
>>>>>
>>>>> Add a new compatile for the driver of SCP 2nd core.
>>>>>
>>>>> Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
>>>>> ---
>>>>>  .../devicetree/bindings/remoteproc/mtk,scp.yaml      | 12 ++++++++++++
>>>>>  1 file changed, 12 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
>>>>> b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
>>>>> index eec3b9c4c713..b181786d9575 100644
>>>>> --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
>>>>> +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
>>>>> @@ -20,6 +20,7 @@ properties:
>>>>>        - mediatek,mt8186-scp
>>>>>        - mediatek,mt8192-scp
>>>>>        - mediatek,mt8195-scp
>>>>> +      - mediatek,mt8195-scp-dual
>>>>>  
>>>>>    reg:
>>>>>      description:
>>>>> @@ -57,6 +58,16 @@ properties:
>>>>>    memory-region:
>>>>>      maxItems: 1
>>>>>  
>>>>> +  mediatek,scp-core:
>>>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>>>> +    description:
>>>>> +      The property value is a list with 2 items, a core id and a phandle
>>>>
>>>> uint32, not phandle.
>>>>
>>>>> +      to the sibling SCP node. 
>>>>
>>>> Skip this. First part is obvious from the schema, second part should be
>>>> described via items.
>>>>
>>>> The core id represents the id of the dts node contains
>>>>> +      this property. The valid values of core id are 0 and 1 for dual-core SCP.
>>>>> +      The phandle of sibling SCP node is used to find the register settings,
>>>>> +      trigger core dependent callback, and invoke rproc API.
>>>>
>>>> Entire description did not help me to understand what's this. So far it
>>>> looks like it is not a hardware property but some programming help, so
>>>> it does not look like properly described in bindings.
>>>>
>>>>> +    maxItems: 1
>>>>
>>>> In description you said - two items.
>>>>
>>>> You need allOf:if:then disallowing this property for other variants.
>>>>
>>>>> +
>>>>>  required:
>>>>>    - compatible
>>>>>    - reg
>>>>> @@ -115,6 +126,7 @@ examples:
>>>>>          reg-names = "sram", "cfg", "l1tcm";
>>>>>          clocks = <&infracfg CLK_INFRA_SCPSYS>;
>>>>>          clock-names = "main";
>>>>> +        mediatek,scp-core = <0 &scp_dual>;
>>>>
>>>> This looks like phandle, so wrong type.
>>>>>  
>>>>>          cros_ec {
>>>>>              mediatek,rpmsg-name = "cros-ec-rpmsg";
>>>
>>> Thanks for your feedback.
>>> After looking for a comparable uses case, I find out a different approach.
>>>
>>>   mediatek,scp-core:
>>>     $ref: "/schemas/types.yaml#/definitions/phandle-array"
>>>     description:
>>>       Enable the dual-core support in scp driver.
>>
>> You describe desired functional behavior, not the hardware. What is the
>> property about? If you just want to indicate this is two-core processor,
>> then it could be:
>> 	mediatek,cores = <2>; /* number of cores */
>>
>>
>> However it seems you want to achieve here something different and as I
>> raised last time - it does not look like DT property.
>>
>> Or maybe this is for first core and you want to indicate the sibling?
>> Something like that was mentioned in previous description.
> 
> This property is mainly added for scp 1st core driver 
> and scp 2nd core driver to find each other via DT API.
> 
> After reconsidering the use of core id in the scp driver, it 
> is not necessary in the control flow. I'll remove the core id 
> at next version.
> 
> How about change the description as following,
> 
>   This property enables the dual-core support in scp driver.
>   By providing the phandle of SCP 2nd core node, the 1st SCP node
>   can control the SCP 2nd core as the subdevice of remoteproc framework.

Please, read it again:

>> You describe desired functional behavior, not the hardware.

Again, you describe Linux implementation (scp driver, remoteproc
framework). You need to describe the hardware, not Linux drivers.

Maybe the hardware property is that one core has its sibling and you
provide here that sibling?


Best regards,
Krzysztof

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

Re: [PATCH v1 01/15] dt-binding: remoteproc: mediatek: Support dual-core SCP

[Tinghan Shen]

Hi Krzysztof,

On Thu, 2022-06-02 at 12:37 +0200, Krzysztof Kozlowski wrote:
> On 02/06/2022 10:58, Tinghan Shen wrote:
> > Hi Krzysztof,
> > 
> > On Thu, 2022-06-02 at 08:55 +0200, Krzysztof Kozlowski wrote:
> > > On 02/06/2022 07:21, Tinghan Shen wrote:
> > > > Hi Krzysztof,
> > > > 
> > > > On Wed, 2022-06-01 at 13:50 +0200, Krzysztof Kozlowski wrote:
> > > > > On 01/06/2022 13:21, Tinghan Shen wrote:
> > > > > > The SCP co-processor is a dual-core RISC-V MCU on MT8195.
> > > > > > 
> > > > > > Add a new property to identify each core and helps to find drivers
> > > > > > through device tree API to cooperate with each other, e.g. boot flow and
> > > > > > watchdog timeout flow.
> > > > > > 
> > > > > > Add a new compatile for the driver of SCP 2nd core.
> > > > > > 
> > > > > > Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
> > > > > > ---
> > > > > >  .../devicetree/bindings/remoteproc/mtk,scp.yaml      | 12 ++++++++++++
> > > > > >  1 file changed, 12 insertions(+)
> > > > > > 
> > > > > > diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > > > > > b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > > > > > index eec3b9c4c713..b181786d9575 100644
> > > > > > --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > > > > > +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > > > > > @@ -20,6 +20,7 @@ properties:
> > > > > >        - mediatek,mt8186-scp
> > > > > >        - mediatek,mt8192-scp
> > > > > >        - mediatek,mt8195-scp
> > > > > > +      - mediatek,mt8195-scp-dual
> > > > > >  
> > > > > >    reg:
> > > > > >      description:
> > > > > > @@ -57,6 +58,16 @@ properties:
> > > > > >    memory-region:
> > > > > >      maxItems: 1
> > > > > >  
> > > > > > +  mediatek,scp-core:
> > > > > > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > > > > > +    description:
> > > > > > +      The property value is a list with 2 items, a core id and a phandle
> > > > > 
> > > > > uint32, not phandle.
> > > > > 
> > > > > > +      to the sibling SCP node. 
> > > > > 
> > > > > Skip this. First part is obvious from the schema, second part should be
> > > > > described via items.
> > > > > 
> > > > > The core id represents the id of the dts node contains
> > > > > > +      this property. The valid values of core id are 0 and 1 for dual-core SCP.
> > > > > > +      The phandle of sibling SCP node is used to find the register settings,
> > > > > > +      trigger core dependent callback, and invoke rproc API.
> > > > > 
> > > > > Entire description did not help me to understand what's this. So far it
> > > > > looks like it is not a hardware property but some programming help, so
> > > > > it does not look like properly described in bindings.
> > > > > 
> > > > > > +    maxItems: 1
> > > > > 
> > > > > In description you said - two items.
> > > > > 
> > > > > You need allOf:if:then disallowing this property for other variants.
> > > > > 
> > > > > > +
> > > > > >  required:
> > > > > >    - compatible
> > > > > >    - reg
> > > > > > @@ -115,6 +126,7 @@ examples:
> > > > > >          reg-names = "sram", "cfg", "l1tcm";
> > > > > >          clocks = <&infracfg CLK_INFRA_SCPSYS>;
> > > > > >          clock-names = "main";
> > > > > > +        mediatek,scp-core = <0 &scp_dual>;
> > > > > 
> > > > > This looks like phandle, so wrong type.
> > > > > >  
> > > > > >          cros_ec {
> > > > > >              mediatek,rpmsg-name = "cros-ec-rpmsg";
> > > > 
> > > > Thanks for your feedback.
> > > > After looking for a comparable uses case, I find out a different approach.
> > > > 
> > > >   mediatek,scp-core:
> > > >     $ref: "/schemas/types.yaml#/definitions/phandle-array"
> > > >     description:
> > > >       Enable the dual-core support in scp driver.
> > > 
> > > You describe desired functional behavior, not the hardware. What is the
> > > property about? If you just want to indicate this is two-core processor,
> > > then it could be:
> > > 	mediatek,cores = <2>; /* number of cores */
> > > 
> > > 
> > > However it seems you want to achieve here something different and as I
> > > raised last time - it does not look like DT property.
> > > 
> > > Or maybe this is for first core and you want to indicate the sibling?
> > > Something like that was mentioned in previous description.
> > 
> > This property is mainly added for scp 1st core driver 
> > and scp 2nd core driver to find each other via DT API.
> > 
> > After reconsidering the use of core id in the scp driver, it 
> > is not necessary in the control flow. I'll remove the core id 
> > at next version.
> > 
> > How about change the description as following,
> > 
> >   This property enables the dual-core support in scp driver.
> >   By providing the phandle of SCP 2nd core node, the 1st SCP node
> >   can control the SCP 2nd core as the subdevice of remoteproc framework.
> 
> Please, read it again:
> 
> > > You describe desired functional behavior, not the hardware.
> 
> Again, you describe Linux implementation (scp driver, remoteproc
> framework). You need to describe the hardware, not Linux drivers.
> 
> Maybe the hardware property is that one core has its sibling and you
> provide here that sibling?

Yes, exactly. I'm sorry for misreading your argument.

How about this one,
   
  Reference to the sibling SCP core. This is required when 
  dual-core SCP support is enabled.

Thanks,
TingHan

Re: [PATCH v1 01/15] dt-binding: remoteproc: mediatek: Support dual-core SCP

[Tinghan Shen]

Hi Krzysztof,

On Thu, 2022-06-02 at 12:37 +0200, Krzysztof Kozlowski wrote:
> On 02/06/2022 10:58, Tinghan Shen wrote:
> > Hi Krzysztof,
> > 
> > On Thu, 2022-06-02 at 08:55 +0200, Krzysztof Kozlowski wrote:
> > > On 02/06/2022 07:21, Tinghan Shen wrote:
> > > > Hi Krzysztof,
> > > > 
> > > > On Wed, 2022-06-01 at 13:50 +0200, Krzysztof Kozlowski wrote:
> > > > > On 01/06/2022 13:21, Tinghan Shen wrote:
> > > > > > The SCP co-processor is a dual-core RISC-V MCU on MT8195.
> > > > > > 
> > > > > > Add a new property to identify each core and helps to find drivers
> > > > > > through device tree API to cooperate with each other, e.g. boot flow and
> > > > > > watchdog timeout flow.
> > > > > > 
> > > > > > Add a new compatile for the driver of SCP 2nd core.
> > > > > > 
> > > > > > Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
> > > > > > ---
> > > > > >  .../devicetree/bindings/remoteproc/mtk,scp.yaml      | 12 ++++++++++++
> > > > > >  1 file changed, 12 insertions(+)
> > > > > > 
> > > > > > diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > > > > > b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > > > > > index eec3b9c4c713..b181786d9575 100644
> > > > > > --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > > > > > +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > > > > > @@ -20,6 +20,7 @@ properties:
> > > > > >        - mediatek,mt8186-scp
> > > > > >        - mediatek,mt8192-scp
> > > > > >        - mediatek,mt8195-scp
> > > > > > +      - mediatek,mt8195-scp-dual
> > > > > >  
> > > > > >    reg:
> > > > > >      description:
> > > > > > @@ -57,6 +58,16 @@ properties:
> > > > > >    memory-region:
> > > > > >      maxItems: 1
> > > > > >  
> > > > > > +  mediatek,scp-core:
> > > > > > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > > > > > +    description:
> > > > > > +      The property value is a list with 2 items, a core id and a phandle
> > > > > 
> > > > > uint32, not phandle.
> > > > > 
> > > > > > +      to the sibling SCP node. 
> > > > > 
> > > > > Skip this. First part is obvious from the schema, second part should be
> > > > > described via items.
> > > > > 
> > > > > The core id represents the id of the dts node contains
> > > > > > +      this property. The valid values of core id are 0 and 1 for dual-core SCP.
> > > > > > +      The phandle of sibling SCP node is used to find the register settings,
> > > > > > +      trigger core dependent callback, and invoke rproc API.
> > > > > 
> > > > > Entire description did not help me to understand what's this. So far it
> > > > > looks like it is not a hardware property but some programming help, so
> > > > > it does not look like properly described in bindings.
> > > > > 
> > > > > > +    maxItems: 1
> > > > > 
> > > > > In description you said - two items.
> > > > > 
> > > > > You need allOf:if:then disallowing this property for other variants.
> > > > > 
> > > > > > +
> > > > > >  required:
> > > > > >    - compatible
> > > > > >    - reg
> > > > > > @@ -115,6 +126,7 @@ examples:
> > > > > >          reg-names = "sram", "cfg", "l1tcm";
> > > > > >          clocks = <&infracfg CLK_INFRA_SCPSYS>;
> > > > > >          clock-names = "main";
> > > > > > +        mediatek,scp-core = <0 &scp_dual>;
> > > > > 
> > > > > This looks like phandle, so wrong type.
> > > > > >  
> > > > > >          cros_ec {
> > > > > >              mediatek,rpmsg-name = "cros-ec-rpmsg";
> > > > 
> > > > Thanks for your feedback.
> > > > After looking for a comparable uses case, I find out a different approach.
> > > > 
> > > >   mediatek,scp-core:
> > > >     $ref: "/schemas/types.yaml#/definitions/phandle-array"
> > > >     description:
> > > >       Enable the dual-core support in scp driver.
> > > 
> > > You describe desired functional behavior, not the hardware. What is the
> > > property about? If you just want to indicate this is two-core processor,
> > > then it could be:
> > > 	mediatek,cores = <2>; /* number of cores */
> > > 
> > > 
> > > However it seems you want to achieve here something different and as I
> > > raised last time - it does not look like DT property.
> > > 
> > > Or maybe this is for first core and you want to indicate the sibling?
> > > Something like that was mentioned in previous description.
> > 
> > This property is mainly added for scp 1st core driver 
> > and scp 2nd core driver to find each other via DT API.
> > 
> > After reconsidering the use of core id in the scp driver, it 
> > is not necessary in the control flow. I'll remove the core id 
> > at next version.
> > 
> > How about change the description as following,
> > 
> >   This property enables the dual-core support in scp driver.
> >   By providing the phandle of SCP 2nd core node, the 1st SCP node
> >   can control the SCP 2nd core as the subdevice of remoteproc framework.
> 
> Please, read it again:
> 
> > > You describe desired functional behavior, not the hardware.
> 
> Again, you describe Linux implementation (scp driver, remoteproc
> framework). You need to describe the hardware, not Linux drivers.
> 
> Maybe the hardware property is that one core has its sibling and you
> provide here that sibling?

Yes, exactly. I'm sorry for misreading your argument.

How about this one,
   
  Reference to the sibling SCP core. This is required when 
  dual-core SCP support is enabled.

Thanks,
TingHan






_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH v1 01/15] dt-binding: remoteproc: mediatek: Support dual-core SCP

[Tinghan Shen]

Hi Krzysztof,

On Thu, 2022-06-02 at 12:37 +0200, Krzysztof Kozlowski wrote:
> On 02/06/2022 10:58, Tinghan Shen wrote:
> > Hi Krzysztof,
> > 
> > On Thu, 2022-06-02 at 08:55 +0200, Krzysztof Kozlowski wrote:
> > > On 02/06/2022 07:21, Tinghan Shen wrote:
> > > > Hi Krzysztof,
> > > > 
> > > > On Wed, 2022-06-01 at 13:50 +0200, Krzysztof Kozlowski wrote:
> > > > > On 01/06/2022 13:21, Tinghan Shen wrote:
> > > > > > The SCP co-processor is a dual-core RISC-V MCU on MT8195.
> > > > > > 
> > > > > > Add a new property to identify each core and helps to find drivers
> > > > > > through device tree API to cooperate with each other, e.g. boot flow and
> > > > > > watchdog timeout flow.
> > > > > > 
> > > > > > Add a new compatile for the driver of SCP 2nd core.
> > > > > > 
> > > > > > Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
> > > > > > ---
> > > > > >  .../devicetree/bindings/remoteproc/mtk,scp.yaml      | 12 ++++++++++++
> > > > > >  1 file changed, 12 insertions(+)
> > > > > > 
> > > > > > diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > > > > > b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > > > > > index eec3b9c4c713..b181786d9575 100644
> > > > > > --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > > > > > +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > > > > > @@ -20,6 +20,7 @@ properties:
> > > > > >        - mediatek,mt8186-scp
> > > > > >        - mediatek,mt8192-scp
> > > > > >        - mediatek,mt8195-scp
> > > > > > +      - mediatek,mt8195-scp-dual
> > > > > >  
> > > > > >    reg:
> > > > > >      description:
> > > > > > @@ -57,6 +58,16 @@ properties:
> > > > > >    memory-region:
> > > > > >      maxItems: 1
> > > > > >  
> > > > > > +  mediatek,scp-core:
> > > > > > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > > > > > +    description:
> > > > > > +      The property value is a list with 2 items, a core id and a phandle
> > > > > 
> > > > > uint32, not phandle.
> > > > > 
> > > > > > +      to the sibling SCP node. 
> > > > > 
> > > > > Skip this. First part is obvious from the schema, second part should be
> > > > > described via items.
> > > > > 
> > > > > The core id represents the id of the dts node contains
> > > > > > +      this property. The valid values of core id are 0 and 1 for dual-core SCP.
> > > > > > +      The phandle of sibling SCP node is used to find the register settings,
> > > > > > +      trigger core dependent callback, and invoke rproc API.
> > > > > 
> > > > > Entire description did not help me to understand what's this. So far it
> > > > > looks like it is not a hardware property but some programming help, so
> > > > > it does not look like properly described in bindings.
> > > > > 
> > > > > > +    maxItems: 1
> > > > > 
> > > > > In description you said - two items.
> > > > > 
> > > > > You need allOf:if:then disallowing this property for other variants.
> > > > > 
> > > > > > +
> > > > > >  required:
> > > > > >    - compatible
> > > > > >    - reg
> > > > > > @@ -115,6 +126,7 @@ examples:
> > > > > >          reg-names = "sram", "cfg", "l1tcm";
> > > > > >          clocks = <&infracfg CLK_INFRA_SCPSYS>;
> > > > > >          clock-names = "main";
> > > > > > +        mediatek,scp-core = <0 &scp_dual>;
> > > > > 
> > > > > This looks like phandle, so wrong type.
> > > > > >  
> > > > > >          cros_ec {
> > > > > >              mediatek,rpmsg-name = "cros-ec-rpmsg";
> > > > 
> > > > Thanks for your feedback.
> > > > After looking for a comparable uses case, I find out a different approach.
> > > > 
> > > >   mediatek,scp-core:
> > > >     $ref: "/schemas/types.yaml#/definitions/phandle-array"
> > > >     description:
> > > >       Enable the dual-core support in scp driver.
> > > 
> > > You describe desired functional behavior, not the hardware. What is the
> > > property about? If you just want to indicate this is two-core processor,
> > > then it could be:
> > > 	mediatek,cores = <2>; /* number of cores */
> > > 
> > > 
> > > However it seems you want to achieve here something different and as I
> > > raised last time - it does not look like DT property.
> > > 
> > > Or maybe this is for first core and you want to indicate the sibling?
> > > Something like that was mentioned in previous description.
> > 
> > This property is mainly added for scp 1st core driver 
> > and scp 2nd core driver to find each other via DT API.
> > 
> > After reconsidering the use of core id in the scp driver, it 
> > is not necessary in the control flow. I'll remove the core id 
> > at next version.
> > 
> > How about change the description as following,
> > 
> >   This property enables the dual-core support in scp driver.
> >   By providing the phandle of SCP 2nd core node, the 1st SCP node
> >   can control the SCP 2nd core as the subdevice of remoteproc framework.
> 
> Please, read it again:
> 
> > > You describe desired functional behavior, not the hardware.
> 
> Again, you describe Linux implementation (scp driver, remoteproc
> framework). You need to describe the hardware, not Linux drivers.
> 
> Maybe the hardware property is that one core has its sibling and you
> provide here that sibling?

Yes, exactly. I'm sorry for misreading your argument.

How about this one,
   
  Reference to the sibling SCP core. This is required when 
  dual-core SCP support is enabled.

Thanks,
TingHan






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

Re: [PATCH v1 01/15] dt-binding: remoteproc: mediatek: Support dual-core SCP

[Krzysztof Kozlowski]

On 02/06/2022 13:29, Tinghan Shen wrote:
>> Maybe the hardware property is that one core has its sibling and you
>> provide here that sibling?
> 
> Yes, exactly. I'm sorry for misreading your argument.
> 
> How about this one,
>    
>   Reference to the sibling SCP core. This is required when 
>   dual-core SCP support is enabled.

Yes, sounds good. Thank you.


Best regards,
Krzysztof

Re: [PATCH v1 01/15] dt-binding: remoteproc: mediatek: Support dual-core SCP

[Krzysztof Kozlowski]

On 02/06/2022 13:29, Tinghan Shen wrote:
>> Maybe the hardware property is that one core has its sibling and you
>> provide here that sibling?
> 
> Yes, exactly. I'm sorry for misreading your argument.
> 
> How about this one,
>    
>   Reference to the sibling SCP core. This is required when 
>   dual-core SCP support is enabled.

Yes, sounds good. Thank you.


Best regards,
Krzysztof

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH v1 01/15] dt-binding: remoteproc: mediatek: Support dual-core SCP

[Krzysztof Kozlowski]

On 02/06/2022 13:29, Tinghan Shen wrote:
>> Maybe the hardware property is that one core has its sibling and you
>> provide here that sibling?
> 
> Yes, exactly. I'm sorry for misreading your argument.
> 
> How about this one,
>    
>   Reference to the sibling SCP core. This is required when 
>   dual-core SCP support is enabled.

Yes, sounds good. Thank you.


Best regards,
Krzysztof

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

Re: [PATCH v1 05/15] remoteproc: mediatek: Add SCP core 1 driver for dual-core scp

[AngeloGioacchino Del Regno]

Il 01/06/22 13:21, Tinghan Shen ha scritto:
> MT8195 SCP is a dual-core processor. The mtk_scp.c driver only controls
> SCP core 0. This patch adds a basic driver to control the another core.
> 
> Core 1 and core 0 of the SCP are housed in the same subsys.They see
> registers and memory in the same way.
> 
> Core 1 of the SCP features its own set of core configuration registers,
> interrupt controller, timers, and DMAs. The rest of the peripherals
> in this subsystem are shared by core 0 and core 1.
> 
> As for memory, core 1 has its own cache memory, and the SCP SRAM is shared
> by core 0 and core 1.
> 

Hello Tinghan,

checking all the patches that are introducing support for the secondary SCP core,
it's clear that you're practically reusing *most of* mtk_scp in mtk_scp_dual.

I don't think that adding a new configuration option for MTK_SCP_DUALCORE (nor a
new file just for that) is a good idea... the code is "short enough" so you should
really just add support for multi-core SCP in mtk_scp.c instead.

After doing so, I have a hunch that we'll be able to reduce the size of this
implementation even more, as I see literally too much common code :-)

Cheers,
Angelo


> Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
> ---
>   drivers/remoteproc/Makefile       |  1 +
>   drivers/remoteproc/mtk_scp_dual.c | 97 +++++++++++++++++++++++++++++++
>   2 files changed, 98 insertions(+)
>   create mode 100644 drivers/remoteproc/mtk_scp_dual.c
> 
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 5478c7cb9e07..84cb687d28da 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -15,6 +15,7 @@ obj-$(CONFIG_IMX_REMOTEPROC)		+= imx_rproc.o
>   obj-$(CONFIG_IMX_DSP_REMOTEPROC)	+= imx_dsp_rproc.o
>   obj-$(CONFIG_INGENIC_VPU_RPROC)		+= ingenic_rproc.o
>   obj-$(CONFIG_MTK_SCP)			+= mtk_scp.o mtk_scp_ipi.o
> +obj-$(CONFIG_MTK_SCP_DUALCORE)		+= mtk_scp_dual.o
>   obj-$(CONFIG_OMAP_REMOTEPROC)		+= omap_remoteproc.o
>   obj-$(CONFIG_WKUP_M3_RPROC)		+= wkup_m3_rproc.o
>   obj-$(CONFIG_DA8XX_REMOTEPROC)		+= da8xx_remoteproc.o
> diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
> new file mode 100644
> index 000000000000..7bc08d26f208
> --- /dev/null
> +++ b/drivers/remoteproc/mtk_scp_dual.c
> @@ -0,0 +1,97 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (c) 2022 MediaTek Inc.
> +
> +#include <linux/err.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +
> +#include "mtk_common.h"
> +#include "remoteproc_internal.h"
> +
> +static const struct rproc_ops scp_ops;
> +
> +static int scp_dual_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct device_node *np = dev->of_node;
> +	struct mtk_scp *scp;
> +	struct rproc *rproc;
> +	const char *fw_name = "scp-dual.img";
> +	int ret, i;
> +	struct resource *res;
> +
> +	ret = rproc_of_parse_firmware(dev, 0, &fw_name);
> +	if (ret < 0 && ret != -EINVAL)
> +		return ret;
> +
> +	rproc = devm_rproc_alloc(dev, np->name, &scp_ops, fw_name, sizeof(*scp));
> +	if (!rproc) {
> +		dev_err(dev, "unable to allocate remoteproc\n");
> +		return -ENOMEM;
> +	}
> +
> +	scp = (struct mtk_scp *)rproc->priv;
> +	scp->rproc = rproc;
> +	scp->dev = dev;
> +	platform_set_drvdata(pdev, scp);
> +
> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sram");
> +	scp->sram_base = devm_ioremap(dev, res->start, resource_size(res));
> +	if (IS_ERR(scp->sram_base))
> +		return dev_err_probe(dev, PTR_ERR(scp->sram_base),
> +				     "Failed to parse and map sram memory\n");
> +
> +	scp->sram_size = resource_size(res);
> +	scp->sram_phys = res->start;
> +
> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cfg");
> +	scp->reg_base = devm_ioremap(dev, res->start, resource_size(res));
> +	if (IS_ERR(scp->reg_base))
> +		return dev_err_probe(dev, PTR_ERR(scp->reg_base),
> +				     "Failed to parse and map cfg memory\n");
> +
> +	mutex_init(&scp->send_lock);
> +	for (i = 0; i < SCP_IPI_MAX; i++)
> +		mutex_init(&scp->ipi_desc[i].lock);
> +
> +	init_waitqueue_head(&scp->run.wq);
> +	init_waitqueue_head(&scp->ack_wq);
> +
> +	return 0;
> +}
> +
> +static int scp_dual_remove(struct platform_device *pdev)
> +{
> +	struct mtk_scp *scp = platform_get_drvdata(pdev);
> +	int i;
> +
> +	for (i = 0; i < SCP_IPI_MAX; i++)
> +		mutex_destroy(&scp->ipi_desc[i].lock);
> +	mutex_destroy(&scp->send_lock);
> +
> +	return 0;
> +}
> +
> +static const struct of_device_id mtk_scp_dual_of_match[] = {
> +	{ .compatible = "mediatek,mt8195-scp-dual" },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, mtk_scp_dual_of_match);
> +
> +static struct platform_driver mtk_scp_dual_driver = {
> +	.probe = scp_dual_probe,
> +	.remove = scp_dual_remove,
> +	.driver = {
> +		.name = "mtk-scp-dual",
> +		.of_match_table = mtk_scp_dual_of_match,
> +	},
> +};
> +
> +module_platform_driver(mtk_scp_dual_driver);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("MediaTek SCP dualcore control driver");

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH v1 05/15] remoteproc: mediatek: Add SCP core 1 driver for dual-core scp

[AngeloGioacchino Del Regno]

Il 01/06/22 13:21, Tinghan Shen ha scritto:
> MT8195 SCP is a dual-core processor. The mtk_scp.c driver only controls
> SCP core 0. This patch adds a basic driver to control the another core.
> 
> Core 1 and core 0 of the SCP are housed in the same subsys.They see
> registers and memory in the same way.
> 
> Core 1 of the SCP features its own set of core configuration registers,
> interrupt controller, timers, and DMAs. The rest of the peripherals
> in this subsystem are shared by core 0 and core 1.
> 
> As for memory, core 1 has its own cache memory, and the SCP SRAM is shared
> by core 0 and core 1.
> 

Hello Tinghan,

checking all the patches that are introducing support for the secondary SCP core,
it's clear that you're practically reusing *most of* mtk_scp in mtk_scp_dual.

I don't think that adding a new configuration option for MTK_SCP_DUALCORE (nor a
new file just for that) is a good idea... the code is "short enough" so you should
really just add support for multi-core SCP in mtk_scp.c instead.

After doing so, I have a hunch that we'll be able to reduce the size of this
implementation even more, as I see literally too much common code :-)

Cheers,
Angelo


> Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
> ---
>   drivers/remoteproc/Makefile       |  1 +
>   drivers/remoteproc/mtk_scp_dual.c | 97 +++++++++++++++++++++++++++++++
>   2 files changed, 98 insertions(+)
>   create mode 100644 drivers/remoteproc/mtk_scp_dual.c
> 
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 5478c7cb9e07..84cb687d28da 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -15,6 +15,7 @@ obj-$(CONFIG_IMX_REMOTEPROC)		+= imx_rproc.o
>   obj-$(CONFIG_IMX_DSP_REMOTEPROC)	+= imx_dsp_rproc.o
>   obj-$(CONFIG_INGENIC_VPU_RPROC)		+= ingenic_rproc.o
>   obj-$(CONFIG_MTK_SCP)			+= mtk_scp.o mtk_scp_ipi.o
> +obj-$(CONFIG_MTK_SCP_DUALCORE)		+= mtk_scp_dual.o
>   obj-$(CONFIG_OMAP_REMOTEPROC)		+= omap_remoteproc.o
>   obj-$(CONFIG_WKUP_M3_RPROC)		+= wkup_m3_rproc.o
>   obj-$(CONFIG_DA8XX_REMOTEPROC)		+= da8xx_remoteproc.o
> diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
> new file mode 100644
> index 000000000000..7bc08d26f208
> --- /dev/null
> +++ b/drivers/remoteproc/mtk_scp_dual.c
> @@ -0,0 +1,97 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (c) 2022 MediaTek Inc.
> +
> +#include <linux/err.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +
> +#include "mtk_common.h"
> +#include "remoteproc_internal.h"
> +
> +static const struct rproc_ops scp_ops;
> +
> +static int scp_dual_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct device_node *np = dev->of_node;
> +	struct mtk_scp *scp;
> +	struct rproc *rproc;
> +	const char *fw_name = "scp-dual.img";
> +	int ret, i;
> +	struct resource *res;
> +
> +	ret = rproc_of_parse_firmware(dev, 0, &fw_name);
> +	if (ret < 0 && ret != -EINVAL)
> +		return ret;
> +
> +	rproc = devm_rproc_alloc(dev, np->name, &scp_ops, fw_name, sizeof(*scp));
> +	if (!rproc) {
> +		dev_err(dev, "unable to allocate remoteproc\n");
> +		return -ENOMEM;
> +	}
> +
> +	scp = (struct mtk_scp *)rproc->priv;
> +	scp->rproc = rproc;
> +	scp->dev = dev;
> +	platform_set_drvdata(pdev, scp);
> +
> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sram");
> +	scp->sram_base = devm_ioremap(dev, res->start, resource_size(res));
> +	if (IS_ERR(scp->sram_base))
> +		return dev_err_probe(dev, PTR_ERR(scp->sram_base),
> +				     "Failed to parse and map sram memory\n");
> +
> +	scp->sram_size = resource_size(res);
> +	scp->sram_phys = res->start;
> +
> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cfg");
> +	scp->reg_base = devm_ioremap(dev, res->start, resource_size(res));
> +	if (IS_ERR(scp->reg_base))
> +		return dev_err_probe(dev, PTR_ERR(scp->reg_base),
> +				     "Failed to parse and map cfg memory\n");
> +
> +	mutex_init(&scp->send_lock);
> +	for (i = 0; i < SCP_IPI_MAX; i++)
> +		mutex_init(&scp->ipi_desc[i].lock);
> +
> +	init_waitqueue_head(&scp->run.wq);
> +	init_waitqueue_head(&scp->ack_wq);
> +
> +	return 0;
> +}
> +
> +static int scp_dual_remove(struct platform_device *pdev)
> +{
> +	struct mtk_scp *scp = platform_get_drvdata(pdev);
> +	int i;
> +
> +	for (i = 0; i < SCP_IPI_MAX; i++)
> +		mutex_destroy(&scp->ipi_desc[i].lock);
> +	mutex_destroy(&scp->send_lock);
> +
> +	return 0;
> +}
> +
> +static const struct of_device_id mtk_scp_dual_of_match[] = {
> +	{ .compatible = "mediatek,mt8195-scp-dual" },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, mtk_scp_dual_of_match);
> +
> +static struct platform_driver mtk_scp_dual_driver = {
> +	.probe = scp_dual_probe,
> +	.remove = scp_dual_remove,
> +	.driver = {
> +		.name = "mtk-scp-dual",
> +		.of_match_table = mtk_scp_dual_of_match,
> +	},
> +};
> +
> +module_platform_driver(mtk_scp_dual_driver);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("MediaTek SCP dualcore control driver");

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

Re: [PATCH v1 05/15] remoteproc: mediatek: Add SCP core 1 driver for dual-core scp

[AngeloGioacchino Del Regno]

Il 01/06/22 13:21, Tinghan Shen ha scritto:
> MT8195 SCP is a dual-core processor. The mtk_scp.c driver only controls
> SCP core 0. This patch adds a basic driver to control the another core.
> 
> Core 1 and core 0 of the SCP are housed in the same subsys.They see
> registers and memory in the same way.
> 
> Core 1 of the SCP features its own set of core configuration registers,
> interrupt controller, timers, and DMAs. The rest of the peripherals
> in this subsystem are shared by core 0 and core 1.
> 
> As for memory, core 1 has its own cache memory, and the SCP SRAM is shared
> by core 0 and core 1.
> 

Hello Tinghan,

checking all the patches that are introducing support for the secondary SCP core,
it's clear that you're practically reusing *most of* mtk_scp in mtk_scp_dual.

I don't think that adding a new configuration option for MTK_SCP_DUALCORE (nor a
new file just for that) is a good idea... the code is "short enough" so you should
really just add support for multi-core SCP in mtk_scp.c instead.

After doing so, I have a hunch that we'll be able to reduce the size of this
implementation even more, as I see literally too much common code :-)

Cheers,
Angelo


> Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
> ---
>   drivers/remoteproc/Makefile       |  1 +
>   drivers/remoteproc/mtk_scp_dual.c | 97 +++++++++++++++++++++++++++++++
>   2 files changed, 98 insertions(+)
>   create mode 100644 drivers/remoteproc/mtk_scp_dual.c
> 
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 5478c7cb9e07..84cb687d28da 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -15,6 +15,7 @@ obj-$(CONFIG_IMX_REMOTEPROC)		+= imx_rproc.o
>   obj-$(CONFIG_IMX_DSP_REMOTEPROC)	+= imx_dsp_rproc.o
>   obj-$(CONFIG_INGENIC_VPU_RPROC)		+= ingenic_rproc.o
>   obj-$(CONFIG_MTK_SCP)			+= mtk_scp.o mtk_scp_ipi.o
> +obj-$(CONFIG_MTK_SCP_DUALCORE)		+= mtk_scp_dual.o
>   obj-$(CONFIG_OMAP_REMOTEPROC)		+= omap_remoteproc.o
>   obj-$(CONFIG_WKUP_M3_RPROC)		+= wkup_m3_rproc.o
>   obj-$(CONFIG_DA8XX_REMOTEPROC)		+= da8xx_remoteproc.o
> diff --git a/drivers/remoteproc/mtk_scp_dual.c b/drivers/remoteproc/mtk_scp_dual.c
> new file mode 100644
> index 000000000000..7bc08d26f208
> --- /dev/null
> +++ b/drivers/remoteproc/mtk_scp_dual.c
> @@ -0,0 +1,97 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (c) 2022 MediaTek Inc.
> +
> +#include <linux/err.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +
> +#include "mtk_common.h"
> +#include "remoteproc_internal.h"
> +
> +static const struct rproc_ops scp_ops;
> +
> +static int scp_dual_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct device_node *np = dev->of_node;
> +	struct mtk_scp *scp;
> +	struct rproc *rproc;
> +	const char *fw_name = "scp-dual.img";
> +	int ret, i;
> +	struct resource *res;
> +
> +	ret = rproc_of_parse_firmware(dev, 0, &fw_name);
> +	if (ret < 0 && ret != -EINVAL)
> +		return ret;
> +
> +	rproc = devm_rproc_alloc(dev, np->name, &scp_ops, fw_name, sizeof(*scp));
> +	if (!rproc) {
> +		dev_err(dev, "unable to allocate remoteproc\n");
> +		return -ENOMEM;
> +	}
> +
> +	scp = (struct mtk_scp *)rproc->priv;
> +	scp->rproc = rproc;
> +	scp->dev = dev;
> +	platform_set_drvdata(pdev, scp);
> +
> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sram");
> +	scp->sram_base = devm_ioremap(dev, res->start, resource_size(res));
> +	if (IS_ERR(scp->sram_base))
> +		return dev_err_probe(dev, PTR_ERR(scp->sram_base),
> +				     "Failed to parse and map sram memory\n");
> +
> +	scp->sram_size = resource_size(res);
> +	scp->sram_phys = res->start;
> +
> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cfg");
> +	scp->reg_base = devm_ioremap(dev, res->start, resource_size(res));
> +	if (IS_ERR(scp->reg_base))
> +		return dev_err_probe(dev, PTR_ERR(scp->reg_base),
> +				     "Failed to parse and map cfg memory\n");
> +
> +	mutex_init(&scp->send_lock);
> +	for (i = 0; i < SCP_IPI_MAX; i++)
> +		mutex_init(&scp->ipi_desc[i].lock);
> +
> +	init_waitqueue_head(&scp->run.wq);
> +	init_waitqueue_head(&scp->ack_wq);
> +
> +	return 0;
> +}
> +
> +static int scp_dual_remove(struct platform_device *pdev)
> +{
> +	struct mtk_scp *scp = platform_get_drvdata(pdev);
> +	int i;
> +
> +	for (i = 0; i < SCP_IPI_MAX; i++)
> +		mutex_destroy(&scp->ipi_desc[i].lock);
> +	mutex_destroy(&scp->send_lock);
> +
> +	return 0;
> +}
> +
> +static const struct of_device_id mtk_scp_dual_of_match[] = {
> +	{ .compatible = "mediatek,mt8195-scp-dual" },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, mtk_scp_dual_of_match);
> +
> +static struct platform_driver mtk_scp_dual_driver = {
> +	.probe = scp_dual_probe,
> +	.remove = scp_dual_remove,
> +	.driver = {
> +		.name = "mtk-scp-dual",
> +		.of_match_table = mtk_scp_dual_of_match,
> +	},
> +};
> +
> +module_platform_driver(mtk_scp_dual_driver);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("MediaTek SCP dualcore control driver");

Re: [PATCH v1 05/15] remoteproc: mediatek: Add SCP core 1 driver for dual-core scp

[Tinghan Shen]

On Mon, 2022-06-06 at 11:15 +0200, AngeloGioacchino Del Regno wrote:
> Il 01/06/22 13:21, Tinghan Shen ha scritto:
> > MT8195 SCP is a dual-core processor. The mtk_scp.c driver only controls
> > SCP core 0. This patch adds a basic driver to control the another core.
> > 
> > Core 1 and core 0 of the SCP are housed in the same subsys.They see
> > registers and memory in the same way.
> > 
> > Core 1 of the SCP features its own set of core configuration registers,
> > interrupt controller, timers, and DMAs. The rest of the peripherals
> > in this subsystem are shared by core 0 and core 1.
> > 
> > As for memory, core 1 has its own cache memory, and the SCP SRAM is shared
> > by core 0 and core 1.
> > 
> 
> Hello Tinghan,
> 
> checking all the patches that are introducing support for the secondary SCP core,
> it's clear that you're practically reusing *most of* mtk_scp in mtk_scp_dual.
> 
> I don't think that adding a new configuration option for MTK_SCP_DUALCORE (nor a
> new file just for that) is a good idea... the code is "short enough" so you should
> really just add support for multi-core SCP in mtk_scp.c instead.
> 
> After doing so, I have a hunch that we'll be able to reduce the size of this
> implementation even more, as I see literally too much common code :-)
> 

Hi Angelo,

Thanks for your review.

This series has 2 new files, mtk_scp_dual.c and mtk_scp_subdev.c.
Is your advice to merge both files into mtk_scp.c, 
or to merely merge mtk_scp_dual.c to mtk_scp.c?

Thanks,
TingHan

Re: [PATCH v1 05/15] remoteproc: mediatek: Add SCP core 1 driver for dual-core scp

[Tinghan Shen]

On Mon, 2022-06-06 at 11:15 +0200, AngeloGioacchino Del Regno wrote:
> Il 01/06/22 13:21, Tinghan Shen ha scritto:
> > MT8195 SCP is a dual-core processor. The mtk_scp.c driver only controls
> > SCP core 0. This patch adds a basic driver to control the another core.
> > 
> > Core 1 and core 0 of the SCP are housed in the same subsys.They see
> > registers and memory in the same way.
> > 
> > Core 1 of the SCP features its own set of core configuration registers,
> > interrupt controller, timers, and DMAs. The rest of the peripherals
> > in this subsystem are shared by core 0 and core 1.
> > 
> > As for memory, core 1 has its own cache memory, and the SCP SRAM is shared
> > by core 0 and core 1.
> > 
> 
> Hello Tinghan,
> 
> checking all the patches that are introducing support for the secondary SCP core,
> it's clear that you're practically reusing *most of* mtk_scp in mtk_scp_dual.
> 
> I don't think that adding a new configuration option for MTK_SCP_DUALCORE (nor a
> new file just for that) is a good idea... the code is "short enough" so you should
> really just add support for multi-core SCP in mtk_scp.c instead.
> 
> After doing so, I have a hunch that we'll be able to reduce the size of this
> implementation even more, as I see literally too much common code :-)
> 

Hi Angelo,

Thanks for your review.

This series has 2 new files, mtk_scp_dual.c and mtk_scp_subdev.c.
Is your advice to merge both files into mtk_scp.c, 
or to merely merge mtk_scp_dual.c to mtk_scp.c?

Thanks,
TingHan




_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH v1 05/15] remoteproc: mediatek: Add SCP core 1 driver for dual-core scp

[Tinghan Shen]

On Mon, 2022-06-06 at 11:15 +0200, AngeloGioacchino Del Regno wrote:
> Il 01/06/22 13:21, Tinghan Shen ha scritto:
> > MT8195 SCP is a dual-core processor. The mtk_scp.c driver only controls
> > SCP core 0. This patch adds a basic driver to control the another core.
> > 
> > Core 1 and core 0 of the SCP are housed in the same subsys.They see
> > registers and memory in the same way.
> > 
> > Core 1 of the SCP features its own set of core configuration registers,
> > interrupt controller, timers, and DMAs. The rest of the peripherals
> > in this subsystem are shared by core 0 and core 1.
> > 
> > As for memory, core 1 has its own cache memory, and the SCP SRAM is shared
> > by core 0 and core 1.
> > 
> 
> Hello Tinghan,
> 
> checking all the patches that are introducing support for the secondary SCP core,
> it's clear that you're practically reusing *most of* mtk_scp in mtk_scp_dual.
> 
> I don't think that adding a new configuration option for MTK_SCP_DUALCORE (nor a
> new file just for that) is a good idea... the code is "short enough" so you should
> really just add support for multi-core SCP in mtk_scp.c instead.
> 
> After doing so, I have a hunch that we'll be able to reduce the size of this
> implementation even more, as I see literally too much common code :-)
> 

Hi Angelo,

Thanks for your review.

This series has 2 new files, mtk_scp_dual.c and mtk_scp_subdev.c.
Is your advice to merge both files into mtk_scp.c, 
or to merely merge mtk_scp_dual.c to mtk_scp.c?

Thanks,
TingHan




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

Re: [PATCH v1 05/15] remoteproc: mediatek: Add SCP core 1 driver for dual-core scp

[AngeloGioacchino Del Regno]

Il 06/06/22 11:52, Tinghan Shen ha scritto:
> On Mon, 2022-06-06 at 11:15 +0200, AngeloGioacchino Del Regno wrote:
>> Il 01/06/22 13:21, Tinghan Shen ha scritto:
>>> MT8195 SCP is a dual-core processor. The mtk_scp.c driver only controls
>>> SCP core 0. This patch adds a basic driver to control the another core.
>>>
>>> Core 1 and core 0 of the SCP are housed in the same subsys.They see
>>> registers and memory in the same way.
>>>
>>> Core 1 of the SCP features its own set of core configuration registers,
>>> interrupt controller, timers, and DMAs. The rest of the peripherals
>>> in this subsystem are shared by core 0 and core 1.
>>>
>>> As for memory, core 1 has its own cache memory, and the SCP SRAM is shared
>>> by core 0 and core 1.
>>>
>>
>> Hello Tinghan,
>>
>> checking all the patches that are introducing support for the secondary SCP core,
>> it's clear that you're practically reusing *most of* mtk_scp in mtk_scp_dual.
>>
>> I don't think that adding a new configuration option for MTK_SCP_DUALCORE (nor a
>> new file just for that) is a good idea... the code is "short enough" so you should
>> really just add support for multi-core SCP in mtk_scp.c instead.
>>
>> After doing so, I have a hunch that we'll be able to reduce the size of this
>> implementation even more, as I see literally too much common code :-)
>>
> 
> Hi Angelo,
> 
> Thanks for your review.
> 
> This series has 2 new files, mtk_scp_dual.c and mtk_scp_subdev.c.
> Is your advice to merge both files into mtk_scp.c,
> or to merely merge mtk_scp_dual.c to mtk_scp.c?
> 
> Thanks,
> TingHan
> 
> 
> 

I suggest to merge both into mtk_scp.c and commonize/generalize functions inside
of there as much as possible... including the removal of #if IS_ENABLED(...)
macro usages, as you can simply check that during runtime by setting a bool
variable to true when it's dual-core.

Let's do this first step.
I'll give you a more exhaustive review on v2, when this main step is done.

Cheers,
Angelo

Re: [PATCH v1 05/15] remoteproc: mediatek: Add SCP core 1 driver for dual-core scp

[AngeloGioacchino Del Regno]

Il 06/06/22 11:52, Tinghan Shen ha scritto:
> On Mon, 2022-06-06 at 11:15 +0200, AngeloGioacchino Del Regno wrote:
>> Il 01/06/22 13:21, Tinghan Shen ha scritto:
>>> MT8195 SCP is a dual-core processor. The mtk_scp.c driver only controls
>>> SCP core 0. This patch adds a basic driver to control the another core.
>>>
>>> Core 1 and core 0 of the SCP are housed in the same subsys.They see
>>> registers and memory in the same way.
>>>
>>> Core 1 of the SCP features its own set of core configuration registers,
>>> interrupt controller, timers, and DMAs. The rest of the peripherals
>>> in this subsystem are shared by core 0 and core 1.
>>>
>>> As for memory, core 1 has its own cache memory, and the SCP SRAM is shared
>>> by core 0 and core 1.
>>>
>>
>> Hello Tinghan,
>>
>> checking all the patches that are introducing support for the secondary SCP core,
>> it's clear that you're practically reusing *most of* mtk_scp in mtk_scp_dual.
>>
>> I don't think that adding a new configuration option for MTK_SCP_DUALCORE (nor a
>> new file just for that) is a good idea... the code is "short enough" so you should
>> really just add support for multi-core SCP in mtk_scp.c instead.
>>
>> After doing so, I have a hunch that we'll be able to reduce the size of this
>> implementation even more, as I see literally too much common code :-)
>>
> 
> Hi Angelo,
> 
> Thanks for your review.
> 
> This series has 2 new files, mtk_scp_dual.c and mtk_scp_subdev.c.
> Is your advice to merge both files into mtk_scp.c,
> or to merely merge mtk_scp_dual.c to mtk_scp.c?
> 
> Thanks,
> TingHan
> 
> 
> 

I suggest to merge both into mtk_scp.c and commonize/generalize functions inside
of there as much as possible... including the removal of #if IS_ENABLED(...)
macro usages, as you can simply check that during runtime by setting a bool
variable to true when it's dual-core.

Let's do this first step.
I'll give you a more exhaustive review on v2, when this main step is done.

Cheers,
Angelo

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH v1 05/15] remoteproc: mediatek: Add SCP core 1 driver for dual-core scp

[AngeloGioacchino Del Regno]

Il 06/06/22 11:52, Tinghan Shen ha scritto:
> On Mon, 2022-06-06 at 11:15 +0200, AngeloGioacchino Del Regno wrote:
>> Il 01/06/22 13:21, Tinghan Shen ha scritto:
>>> MT8195 SCP is a dual-core processor. The mtk_scp.c driver only controls
>>> SCP core 0. This patch adds a basic driver to control the another core.
>>>
>>> Core 1 and core 0 of the SCP are housed in the same subsys.They see
>>> registers and memory in the same way.
>>>
>>> Core 1 of the SCP features its own set of core configuration registers,
>>> interrupt controller, timers, and DMAs. The rest of the peripherals
>>> in this subsystem are shared by core 0 and core 1.
>>>
>>> As for memory, core 1 has its own cache memory, and the SCP SRAM is shared
>>> by core 0 and core 1.
>>>
>>
>> Hello Tinghan,
>>
>> checking all the patches that are introducing support for the secondary SCP core,
>> it's clear that you're practically reusing *most of* mtk_scp in mtk_scp_dual.
>>
>> I don't think that adding a new configuration option for MTK_SCP_DUALCORE (nor a
>> new file just for that) is a good idea... the code is "short enough" so you should
>> really just add support for multi-core SCP in mtk_scp.c instead.
>>
>> After doing so, I have a hunch that we'll be able to reduce the size of this
>> implementation even more, as I see literally too much common code :-)
>>
> 
> Hi Angelo,
> 
> Thanks for your review.
> 
> This series has 2 new files, mtk_scp_dual.c and mtk_scp_subdev.c.
> Is your advice to merge both files into mtk_scp.c,
> or to merely merge mtk_scp_dual.c to mtk_scp.c?
> 
> Thanks,
> TingHan
> 
> 
> 

I suggest to merge both into mtk_scp.c and commonize/generalize functions inside
of there as much as possible... including the removal of #if IS_ENABLED(...)
macro usages, as you can simply check that during runtime by setting a bool
variable to true when it's dual-core.

Let's do this first step.
I'll give you a more exhaustive review on v2, when this main step is done.

Cheers,
Angelo

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

Re: [PATCH v1 05/15] remoteproc: mediatek: Add SCP core 1 driver for dual-core scp

[Tinghan Shen]

On Mon, 2022-06-06 at 12:08 +0200, AngeloGioacchino Del Regno wrote:
> Il 06/06/22 11:52, Tinghan Shen ha scritto:
> > On Mon, 2022-06-06 at 11:15 +0200, AngeloGioacchino Del Regno wrote:
> > > Il 01/06/22 13:21, Tinghan Shen ha scritto:
> > > > MT8195 SCP is a dual-core processor. The mtk_scp.c driver only controls
> > > > SCP core 0. This patch adds a basic driver to control the another core.
> > > > 
> > > > Core 1 and core 0 of the SCP are housed in the same subsys.They see
> > > > registers and memory in the same way.
> > > > 
> > > > Core 1 of the SCP features its own set of core configuration registers,
> > > > interrupt controller, timers, and DMAs. The rest of the peripherals
> > > > in this subsystem are shared by core 0 and core 1.
> > > > 
> > > > As for memory, core 1 has its own cache memory, and the SCP SRAM is shared
> > > > by core 0 and core 1.
> > > > 
> > > 
> > > Hello Tinghan,
> > > 
> > > checking all the patches that are introducing support for the secondary SCP core,
> > > it's clear that you're practically reusing *most of* mtk_scp in mtk_scp_dual.
> > > 
> > > I don't think that adding a new configuration option for MTK_SCP_DUALCORE (nor a
> > > new file just for that) is a good idea... the code is "short enough" so you should
> > > really just add support for multi-core SCP in mtk_scp.c instead.
> > > 
> > > After doing so, I have a hunch that we'll be able to reduce the size of this
> > > implementation even more, as I see literally too much common code :-)
> > > 
> > 
> > Hi Angelo,
> > 
> > Thanks for your review.
> > 
> > This series has 2 new files, mtk_scp_dual.c and mtk_scp_subdev.c.
> > Is your advice to merge both files into mtk_scp.c,
> > or to merely merge mtk_scp_dual.c to mtk_scp.c?
> > 
> > Thanks,
> > TingHan
> > 
> > 
> > 
> 
> I suggest to merge both into mtk_scp.c and commonize/generalize functions inside
> of there as much as possible... including the removal of #if IS_ENABLED(...)
> macro usages, as you can simply check that during runtime by setting a bool
> variable to true when it's dual-core.
> 
> Let's do this first step.
> I'll give you a more exhaustive review on v2, when this main step is done.
> 
> Cheers,
> Angelo

Hi Angelo,

Ok, I'll merge these files and send next version.


Thanks,
TingHan

Re: [PATCH v1 05/15] remoteproc: mediatek: Add SCP core 1 driver for dual-core scp

[Tinghan Shen]

On Mon, 2022-06-06 at 12:08 +0200, AngeloGioacchino Del Regno wrote:
> Il 06/06/22 11:52, Tinghan Shen ha scritto:
> > On Mon, 2022-06-06 at 11:15 +0200, AngeloGioacchino Del Regno wrote:
> > > Il 01/06/22 13:21, Tinghan Shen ha scritto:
> > > > MT8195 SCP is a dual-core processor. The mtk_scp.c driver only controls
> > > > SCP core 0. This patch adds a basic driver to control the another core.
> > > > 
> > > > Core 1 and core 0 of the SCP are housed in the same subsys.They see
> > > > registers and memory in the same way.
> > > > 
> > > > Core 1 of the SCP features its own set of core configuration registers,
> > > > interrupt controller, timers, and DMAs. The rest of the peripherals
> > > > in this subsystem are shared by core 0 and core 1.
> > > > 
> > > > As for memory, core 1 has its own cache memory, and the SCP SRAM is shared
> > > > by core 0 and core 1.
> > > > 
> > > 
> > > Hello Tinghan,
> > > 
> > > checking all the patches that are introducing support for the secondary SCP core,
> > > it's clear that you're practically reusing *most of* mtk_scp in mtk_scp_dual.
> > > 
> > > I don't think that adding a new configuration option for MTK_SCP_DUALCORE (nor a
> > > new file just for that) is a good idea... the code is "short enough" so you should
> > > really just add support for multi-core SCP in mtk_scp.c instead.
> > > 
> > > After doing so, I have a hunch that we'll be able to reduce the size of this
> > > implementation even more, as I see literally too much common code :-)
> > > 
> > 
> > Hi Angelo,
> > 
> > Thanks for your review.
> > 
> > This series has 2 new files, mtk_scp_dual.c and mtk_scp_subdev.c.
> > Is your advice to merge both files into mtk_scp.c,
> > or to merely merge mtk_scp_dual.c to mtk_scp.c?
> > 
> > Thanks,
> > TingHan
> > 
> > 
> > 
> 
> I suggest to merge both into mtk_scp.c and commonize/generalize functions inside
> of there as much as possible... including the removal of #if IS_ENABLED(...)
> macro usages, as you can simply check that during runtime by setting a bool
> variable to true when it's dual-core.
> 
> Let's do this first step.
> I'll give you a more exhaustive review on v2, when this main step is done.
> 
> Cheers,
> Angelo

Hi Angelo,

Ok, I'll merge these files and send next version.


Thanks,
TingHan



_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH v1 05/15] remoteproc: mediatek: Add SCP core 1 driver for dual-core scp

[Tinghan Shen]

On Mon, 2022-06-06 at 12:08 +0200, AngeloGioacchino Del Regno wrote:
> Il 06/06/22 11:52, Tinghan Shen ha scritto:
> > On Mon, 2022-06-06 at 11:15 +0200, AngeloGioacchino Del Regno wrote:
> > > Il 01/06/22 13:21, Tinghan Shen ha scritto:
> > > > MT8195 SCP is a dual-core processor. The mtk_scp.c driver only controls
> > > > SCP core 0. This patch adds a basic driver to control the another core.
> > > > 
> > > > Core 1 and core 0 of the SCP are housed in the same subsys.They see
> > > > registers and memory in the same way.
> > > > 
> > > > Core 1 of the SCP features its own set of core configuration registers,
> > > > interrupt controller, timers, and DMAs. The rest of the peripherals
> > > > in this subsystem are shared by core 0 and core 1.
> > > > 
> > > > As for memory, core 1 has its own cache memory, and the SCP SRAM is shared
> > > > by core 0 and core 1.
> > > > 
> > > 
> > > Hello Tinghan,
> > > 
> > > checking all the patches that are introducing support for the secondary SCP core,
> > > it's clear that you're practically reusing *most of* mtk_scp in mtk_scp_dual.
> > > 
> > > I don't think that adding a new configuration option for MTK_SCP_DUALCORE (nor a
> > > new file just for that) is a good idea... the code is "short enough" so you should
> > > really just add support for multi-core SCP in mtk_scp.c instead.
> > > 
> > > After doing so, I have a hunch that we'll be able to reduce the size of this
> > > implementation even more, as I see literally too much common code :-)
> > > 
> > 
> > Hi Angelo,
> > 
> > Thanks for your review.
> > 
> > This series has 2 new files, mtk_scp_dual.c and mtk_scp_subdev.c.
> > Is your advice to merge both files into mtk_scp.c,
> > or to merely merge mtk_scp_dual.c to mtk_scp.c?
> > 
> > Thanks,
> > TingHan
> > 
> > 
> > 
> 
> I suggest to merge both into mtk_scp.c and commonize/generalize functions inside
> of there as much as possible... including the removal of #if IS_ENABLED(...)
> macro usages, as you can simply check that during runtime by setting a bool
> variable to true when it's dual-core.
> 
> Let's do this first step.
> I'll give you a more exhaustive review on v2, when this main step is done.
> 
> Cheers,
> Angelo

Hi Angelo,

Ok, I'll merge these files and send next version.


Thanks,
TingHan



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

Re: [PATCH v1 15/15] mfd: cros_ec: Add SCP core 1 as a new CrOS EC MCU

[Lee Jones]

On Wed, 01 Jun 2022, Tinghan Shen wrote:

> MT8195 System Companion Processors(SCP) is a dual-core RISC-V MCU.
> Add a new cros feature id to represent the SCP 2nd core.
> 
> The 1st core is referred to as 'core 0', and the 2nd core is referred
> to as 'core 1'.
> 
> Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
> ---
>  drivers/mfd/cros_ec_dev.c                      | 5 +++++
>  include/linux/platform_data/cros_ec_commands.h | 2 ++
>  include/linux/platform_data/cros_ec_proto.h    | 1 +
>  3 files changed, 8 insertions(+)

Applied, thanks.

-- 
Lee Jones [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v1 15/15] mfd: cros_ec: Add SCP core 1 as a new CrOS EC MCU

[Lee Jones]

On Wed, 01 Jun 2022, Tinghan Shen wrote:

> MT8195 System Companion Processors(SCP) is a dual-core RISC-V MCU.
> Add a new cros feature id to represent the SCP 2nd core.
> 
> The 1st core is referred to as 'core 0', and the 2nd core is referred
> to as 'core 1'.
> 
> Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
> ---
>  drivers/mfd/cros_ec_dev.c                      | 5 +++++
>  include/linux/platform_data/cros_ec_commands.h | 2 ++
>  include/linux/platform_data/cros_ec_proto.h    | 1 +
>  3 files changed, 8 insertions(+)

Applied, thanks.

-- 
Lee Jones [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

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