[PATCH V5 0/5] soc: imx: add scu firmware api support

[PATCH V5 0/5] soc: imx: add scu firmware api support

[Dong Aisheng]

Unlike the former i.MX Architectures, the new generation i.MX8 SoCs
(e.g. MX8QXP and MX8QM) contain a system controller which runs on a
dedicated Cortex-M core to provide power, clock, Pad, and resource
management. Communication between the host processor running
an OS and the system controller happens through a SCU protocol.
This patchset adds the SCU APIs which is implemented based on MU
and will be used by different system components.

It mainly consists of below parts:
1) SCU IPC
   Basic IPC mechanism implemention based on mailbox which is used
   for communication between AP and SCU firmware.
2) SCU IPC Service API

Dong Aisheng (5):
  dt-bindings: arm: fsl: add scu binding doc
  soc: imx: add SC firmware IPC and APIs
  soc: imx: sc: add pm svc support
  soc: imx: sc: add pad svc support
  soc: imx: sc: add misc svc support

 .../devicetree/bindings/arm/freescale/fsl,scu.txt  | 179 ++++++
 drivers/soc/imx/Kconfig                            |   4 +
 drivers/soc/imx/Makefile                           |   1 +
 drivers/soc/imx/sc/Makefile                        |   5 +
 drivers/soc/imx/sc/main/ipc.c                      | 258 +++++++++
 drivers/soc/imx/sc/main/rpc.h                      |  51 ++
 drivers/soc/imx/sc/svc/misc/rpc_clnt.c             | 106 ++++
 drivers/soc/imx/sc/svc/pad/rpc_clnt.c              |  82 +++
 drivers/soc/imx/sc/svc/pm/rpc_clnt.c               | 275 +++++++++
 include/soc/imx/sc/ipc.h                           |  46 ++
 include/soc/imx/sc/sci.h                           |  20 +
 include/soc/imx/sc/svc/misc/api.h                  |  60 ++
 include/soc/imx/sc/svc/pad/api.h                   |  60 ++
 include/soc/imx/sc/svc/pm/api.h                    | 229 ++++++++
 include/soc/imx/sc/types.h                         | 636 +++++++++++++++++++++
 15 files changed, 2012 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
 create mode 100644 drivers/soc/imx/sc/Makefile
 create mode 100644 drivers/soc/imx/sc/main/ipc.c
 create mode 100644 drivers/soc/imx/sc/main/rpc.h
 create mode 100644 drivers/soc/imx/sc/svc/misc/rpc_clnt.c
 create mode 100644 drivers/soc/imx/sc/svc/pad/rpc_clnt.c
 create mode 100644 drivers/soc/imx/sc/svc/pm/rpc_clnt.c
 create mode 100644 include/soc/imx/sc/ipc.h
 create mode 100644 include/soc/imx/sc/sci.h
 create mode 100644 include/soc/imx/sc/svc/misc/api.h
 create mode 100644 include/soc/imx/sc/svc/pad/api.h
 create mode 100644 include/soc/imx/sc/svc/pm/api.h
 create mode 100644 include/soc/imx/sc/types.h

-- 
2.7.4

[PATCH V5 1/5] dt-bindings: arm: fsl: add scu binding doc

[Dong Aisheng]

The System Controller Firmware (SCFW) is a low-level system function
which runs on a dedicated Cortex-M core to provide power, clock, and
resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
(QM, QP), and i.MX8QX (QXP, DX).

Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Jassi Brar <jassisinghbrar@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: devicetree@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-gpio@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
---
v4->v5:
 * scu node should be under firmware node
 * add pd/clk/pinctrl binding as well according to Rob's suggestion
 * switch to new generic MU binding
   Use 8 separate mu channels in one MU instance for SCU communication
v3->v4:
 * fully change to mailbox binding
 * add child node description
v2->v3:
 * update a bit to mailbox binding
v1->v2:
 * remove status
 * changed to mu1
---
 .../devicetree/bindings/arm/freescale/fsl,scu.txt  | 179 +++++++++++++++++++++
 1 file changed, 179 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt

diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
new file mode 100644
index 0000000..2cd7e4a
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -0,0 +1,179 @@
+NXP i.MX System Controller Firmware (SCFW) --------------------------------------------------------------------
+
+The System Controller Firmware (SCFW) is a low-level system function
+which runs on a dedicated Cortex-M core to provide power, clock, and
+resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
+(QM, QP), and i.MX8QX (QXP, DX).
+
+The AP communicates with the SC using a multi-ported MU module found
+in the LSIO subsystem. The current definition of this MU module provides
+5 remote AP connections to the SC to support up to 5 execution environments
+(TZ, HV, standard Linux, etc.). The SC side of this MU module interfaces
+with the LSIO DSC IP bus. The SC firmware will communicate with this MU
+using the MSI bus.
+
+System Controller Device Node:
+============================================================
+
+The scu node with the following properties shall be under the /firmware/ node.
+
+Required properties:
+-------------------
+- compatible:	should be "fsl,imx-scu".
+- mbox-names:	should include "tx0", "tx1", "tx2", "tx3",
+			       "rx0", "rx1", "rx2", "rx3".
+- mboxes:	List of phandle of 4 MU channels for tx and 4 MU channels
+		for rx. All 8 MU channels must be in the same MU instance.
+		Cross instances are not allowed. The MU instance can only
+		be one of LSIO MU0~M4 for imx8qxp and imx8qm. Users need
+		to make sure use the one which is not conflict with other
+		execution environments. e.g. ATF.
+		Note:
+		Channel 0 must be "tx0" or "rx0".
+		Channel 1 must be "tx1" or "rx1".
+		Channel 2 must be "tx2" or "rx2".
+		Channel 3 must be "tx3" or "rx3".
+		e.g.
+		mboxes = <&lsio_mu1 0 0
+			  &lsio_mu1 0 1
+			  &lsio_mu1 0 2
+			  &lsio_mu1 0 3
+			  &lsio_mu1 1 0
+			  &lsio_mu1 1 1
+			  &lsio_mu1 1 2
+			  &lsio_mu1 1 3>;
+		See Documentation/devicetree/bindings/mailbox/fsl,mu.txt
+		for detailed mailbox binding.
+
+i.MX SCU Client Device Node:
+============================================================
+
+Client nodes are maintained as children of the relevant IMX-SCU device node.
+
+Power domain bindings based on SCU Message Protocol
+------------------------------------------------------------
+
+This binding for the SCU power domain providers uses the generic power
+domain binding[2].
+
+Required properties:
+- compatible:		Should be "fsl,scu-pd".
+- #address-cells:	Should be 1.
+- #size-cells:		Should be 0.
+
+Required properties for power domain sub nodes:
+- #power-domain-cells:	Must be 0.
+
+Optional Properties:
+- reg:			Resource ID of this power domain.
+			No exist means uncontrollable by user.
+			See detailed Resource ID list from:
+			include/dt-bindings/power/imx-rsrc.h
+- power-domains:	phandle pointing to the parent power domain.
+
+Clock bindings based on SCU Message Protocol
+------------------------------------------------------------
+
+This binding uses the common clock binding[1].
+
+Required properties:
+- compatible:		Should be "fsl,imx8qxp-clock".
+- #clock-cells:		Should be 1. Contains the Clock ID value.
+
+The clock consumer should specify the desired clock by having the clock
+ID in its "clocks" phandle cell.
+
+See the full list of clock IDs from:
+include/dt-bindings/clock/imx8qxp-clock.h
+
+Pinctrl bindings based on SCU Message Protocol
+------------------------------------------------------------
+
+This binding uses the i.MX common pinctrl binding[3].
+
+Required properties:
+- compatible:		Should be "fsl,imx8qxp-iomuxc".
+
+Required properties for Pinctrl sub nodes:
+- fsl,pins:		Each entry consists of 3 integers which represents
+			the mux and config setting for one pin. The first 2
+			integers <pin_id mux_mode> are specified using a
+			PIN_FUNC_ID macro, which can be found in
+			<dt-bindings/pinctrl/pads-imx8qxp.h>.
+			The last integer CONFIG is the pad setting value like
+			pull-up on this pin.
+
+			Please refer to i.MX8QXP Reference Manual for detailed
+			CONFIG settings.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/power/power_domain.txt
+[3] Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
+
+Example (imx8qxp):
+-------------
+lsio_mu1: mailbox@5d1c0000 {
+	...
+	#mbox-cells = <2>;
+};
+
+firmware {
+	scu {
+		compatible = "fsl,imx-scu";
+		mbox-names = "tx0", "tx1", "tx2", "tx3",
+			     "rx0", "rx1", "rx2", "rx3";
+		mboxes = <&lsio_mu1 0 0
+			  &lsio_mu1 0 1
+			  &lsio_mu1 0 2
+			  &lsio_mu1 0 3
+			  &lsio_mu1 1 0
+			  &lsio_mu1 1 1
+			  &lsio_mu1 1 2
+			  &lsio_mu1 1 3>;
+
+		clk: clk {
+			compatible = "fsl,imx8qxp-clk";
+			#clock-cells = <1>;
+		};
+
+		iomuxc {
+			compatible = "fsl,imx8qxp-iomuxc";
+
+			pinctrl_lpuart0: lpuart0grp {
+				fsl,pins = <
+					SC_P_UART0_RX_ADMA_UART0_RX	0x06000020
+					SC_P_UART0_TX_ADMA_UART0_TX	0x06000020
+				>;
+			};
+			...
+		};
+
+		imx8qx-pm {
+			compatible = "fsl,scu-pd";
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			pd_dma: dma-power-domain {
+				#power-domain-cells = <0>;
+
+				pd_dma_lpuart0: dma-lpuart0@57 {
+					reg = <SC_R_UART_0>;
+					#power-domain-cells = <0>;
+					power-domains = <&pd_dma>;
+				};
+				...
+			};
+			...
+		};
+	};
+};
+
+serial@5a060000 {
+	...
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_lpuart0>;
+	clocks = <&clk IMX8QXP_UART0_CLK>,
+		 <&clk IMX8QXP_UART0_IPG_CLK>;
+	clock-names = "per", "ipg";
+	power-domains = <&pd_dma_lpuart0>;
+};
-- 
2.7.4

[PATCH V5 1/5] dt-bindings: arm: fsl: add scu binding doc

[Dong Aisheng]

The System Controller Firmware (SCFW) is a low-level system function
which runs on a dedicated Cortex-M core to provide power, clock, and
resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
(QM, QP), and i.MX8QX (QXP, DX).

Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Jassi Brar <jassisinghbrar@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: devicetree at vger.kernel.org
Cc: linux-clk at vger.kernel.org
Cc: linux-gpio at vger.kernel.org
Cc: linux-pm at vger.kernel.org
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
---
v4->v5:
 * scu node should be under firmware node
 * add pd/clk/pinctrl binding as well according to Rob's suggestion
 * switch to new generic MU binding
   Use 8 separate mu channels in one MU instance for SCU communication
v3->v4:
 * fully change to mailbox binding
 * add child node description
v2->v3:
 * update a bit to mailbox binding
v1->v2:
 * remove status
 * changed to mu1
---
 .../devicetree/bindings/arm/freescale/fsl,scu.txt  | 179 +++++++++++++++++++++
 1 file changed, 179 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt

diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
new file mode 100644
index 0000000..2cd7e4a
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -0,0 +1,179 @@
+NXP i.MX System Controller Firmware (SCFW) --------------------------------------------------------------------
+
+The System Controller Firmware (SCFW) is a low-level system function
+which runs on a dedicated Cortex-M core to provide power, clock, and
+resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
+(QM, QP), and i.MX8QX (QXP, DX).
+
+The AP communicates with the SC using a multi-ported MU module found
+in the LSIO subsystem. The current definition of this MU module provides
+5 remote AP connections to the SC to support up to 5 execution environments
+(TZ, HV, standard Linux, etc.). The SC side of this MU module interfaces
+with the LSIO DSC IP bus. The SC firmware will communicate with this MU
+using the MSI bus.
+
+System Controller Device Node:
+============================================================
+
+The scu node with the following properties shall be under the /firmware/ node.
+
+Required properties:
+-------------------
+- compatible:	should be "fsl,imx-scu".
+- mbox-names:	should include "tx0", "tx1", "tx2", "tx3",
+			       "rx0", "rx1", "rx2", "rx3".
+- mboxes:	List of phandle of 4 MU channels for tx and 4 MU channels
+		for rx. All 8 MU channels must be in the same MU instance.
+		Cross instances are not allowed. The MU instance can only
+		be one of LSIO MU0~M4 for imx8qxp and imx8qm. Users need
+		to make sure use the one which is not conflict with other
+		execution environments. e.g. ATF.
+		Note:
+		Channel 0 must be "tx0" or "rx0".
+		Channel 1 must be "tx1" or "rx1".
+		Channel 2 must be "tx2" or "rx2".
+		Channel 3 must be "tx3" or "rx3".
+		e.g.
+		mboxes = <&lsio_mu1 0 0
+			  &lsio_mu1 0 1
+			  &lsio_mu1 0 2
+			  &lsio_mu1 0 3
+			  &lsio_mu1 1 0
+			  &lsio_mu1 1 1
+			  &lsio_mu1 1 2
+			  &lsio_mu1 1 3>;
+		See Documentation/devicetree/bindings/mailbox/fsl,mu.txt
+		for detailed mailbox binding.
+
+i.MX SCU Client Device Node:
+============================================================
+
+Client nodes are maintained as children of the relevant IMX-SCU device node.
+
+Power domain bindings based on SCU Message Protocol
+------------------------------------------------------------
+
+This binding for the SCU power domain providers uses the generic power
+domain binding[2].
+
+Required properties:
+- compatible:		Should be "fsl,scu-pd".
+- #address-cells:	Should be 1.
+- #size-cells:		Should be 0.
+
+Required properties for power domain sub nodes:
+- #power-domain-cells:	Must be 0.
+
+Optional Properties:
+- reg:			Resource ID of this power domain.
+			No exist means uncontrollable by user.
+			See detailed Resource ID list from:
+			include/dt-bindings/power/imx-rsrc.h
+- power-domains:	phandle pointing to the parent power domain.
+
+Clock bindings based on SCU Message Protocol
+------------------------------------------------------------
+
+This binding uses the common clock binding[1].
+
+Required properties:
+- compatible:		Should be "fsl,imx8qxp-clock".
+- #clock-cells:		Should be 1. Contains the Clock ID value.
+
+The clock consumer should specify the desired clock by having the clock
+ID in its "clocks" phandle cell.
+
+See the full list of clock IDs from:
+include/dt-bindings/clock/imx8qxp-clock.h
+
+Pinctrl bindings based on SCU Message Protocol
+------------------------------------------------------------
+
+This binding uses the i.MX common pinctrl binding[3].
+
+Required properties:
+- compatible:		Should be "fsl,imx8qxp-iomuxc".
+
+Required properties for Pinctrl sub nodes:
+- fsl,pins:		Each entry consists of 3 integers which represents
+			the mux and config setting for one pin. The first 2
+			integers <pin_id mux_mode> are specified using a
+			PIN_FUNC_ID macro, which can be found in
+			<dt-bindings/pinctrl/pads-imx8qxp.h>.
+			The last integer CONFIG is the pad setting value like
+			pull-up on this pin.
+
+			Please refer to i.MX8QXP Reference Manual for detailed
+			CONFIG settings.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/power/power_domain.txt
+[3] Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
+
+Example (imx8qxp):
+-------------
+lsio_mu1: mailbox at 5d1c0000 {
+	...
+	#mbox-cells = <2>;
+};
+
+firmware {
+	scu {
+		compatible = "fsl,imx-scu";
+		mbox-names = "tx0", "tx1", "tx2", "tx3",
+			     "rx0", "rx1", "rx2", "rx3";
+		mboxes = <&lsio_mu1 0 0
+			  &lsio_mu1 0 1
+			  &lsio_mu1 0 2
+			  &lsio_mu1 0 3
+			  &lsio_mu1 1 0
+			  &lsio_mu1 1 1
+			  &lsio_mu1 1 2
+			  &lsio_mu1 1 3>;
+
+		clk: clk {
+			compatible = "fsl,imx8qxp-clk";
+			#clock-cells = <1>;
+		};
+
+		iomuxc {
+			compatible = "fsl,imx8qxp-iomuxc";
+
+			pinctrl_lpuart0: lpuart0grp {
+				fsl,pins = <
+					SC_P_UART0_RX_ADMA_UART0_RX	0x06000020
+					SC_P_UART0_TX_ADMA_UART0_TX	0x06000020
+				>;
+			};
+			...
+		};
+
+		imx8qx-pm {
+			compatible = "fsl,scu-pd";
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			pd_dma: dma-power-domain {
+				#power-domain-cells = <0>;
+
+				pd_dma_lpuart0: dma-lpuart0 at 57 {
+					reg = <SC_R_UART_0>;
+					#power-domain-cells = <0>;
+					power-domains = <&pd_dma>;
+				};
+				...
+			};
+			...
+		};
+	};
+};
+
+serial at 5a060000 {
+	...
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_lpuart0>;
+	clocks = <&clk IMX8QXP_UART0_CLK>,
+		 <&clk IMX8QXP_UART0_IPG_CLK>;
+	clock-names = "per", "ipg";
+	power-domains = <&pd_dma_lpuart0>;
+};
-- 
2.7.4

[PATCH V5 1/5] dt-bindings: arm: fsl: add scu binding doc

[Dong Aisheng]

The System Controller Firmware (SCFW) is a low-level system function
which runs on a dedicated Cortex-M core to provide power, clock, and
resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
(QM, QP), and i.MX8QX (QXP, DX).

Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Jassi Brar <jassisinghbrar@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: devicetree@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-gpio@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
---
v4->v5:
 * scu node should be under firmware node
 * add pd/clk/pinctrl binding as well according to Rob's suggestion
 * switch to new generic MU binding
   Use 8 separate mu channels in one MU instance for SCU communication
v3->v4:
 * fully change to mailbox binding
 * add child node description
v2->v3:
 * update a bit to mailbox binding
v1->v2:
 * remove status
 * changed to mu1
---
 .../devicetree/bindings/arm/freescale/fsl,scu.txt  | 179 +++++++++++++++++++++
 1 file changed, 179 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt

diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
new file mode 100644
index 0000000..2cd7e4a
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -0,0 +1,179 @@
+NXP i.MX System Controller Firmware (SCFW) --------------------------------------------------------------------
+
+The System Controller Firmware (SCFW) is a low-level system function
+which runs on a dedicated Cortex-M core to provide power, clock, and
+resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
+(QM, QP), and i.MX8QX (QXP, DX).
+
+The AP communicates with the SC using a multi-ported MU module found
+in the LSIO subsystem. The current definition of this MU module provides
+5 remote AP connections to the SC to support up to 5 execution environments
+(TZ, HV, standard Linux, etc.). The SC side of this MU module interfaces
+with the LSIO DSC IP bus. The SC firmware will communicate with this MU
+using the MSI bus.
+
+System Controller Device Node:
+============================================================
+
+The scu node with the following properties shall be under the /firmware/ node.
+
+Required properties:
+-------------------
+- compatible:	should be "fsl,imx-scu".
+- mbox-names:	should include "tx0", "tx1", "tx2", "tx3",
+			       "rx0", "rx1", "rx2", "rx3".
+- mboxes:	List of phandle of 4 MU channels for tx and 4 MU channels
+		for rx. All 8 MU channels must be in the same MU instance.
+		Cross instances are not allowed. The MU instance can only
+		be one of LSIO MU0~M4 for imx8qxp and imx8qm. Users need
+		to make sure use the one which is not conflict with other
+		execution environments. e.g. ATF.
+		Note:
+		Channel 0 must be "tx0" or "rx0".
+		Channel 1 must be "tx1" or "rx1".
+		Channel 2 must be "tx2" or "rx2".
+		Channel 3 must be "tx3" or "rx3".
+		e.g.
+		mboxes = <&lsio_mu1 0 0
+			  &lsio_mu1 0 1
+			  &lsio_mu1 0 2
+			  &lsio_mu1 0 3
+			  &lsio_mu1 1 0
+			  &lsio_mu1 1 1
+			  &lsio_mu1 1 2
+			  &lsio_mu1 1 3>;
+		See Documentation/devicetree/bindings/mailbox/fsl,mu.txt
+		for detailed mailbox binding.
+
+i.MX SCU Client Device Node:
+============================================================
+
+Client nodes are maintained as children of the relevant IMX-SCU device node.
+
+Power domain bindings based on SCU Message Protocol
+------------------------------------------------------------
+
+This binding for the SCU power domain providers uses the generic power
+domain binding[2].
+
+Required properties:
+- compatible:		Should be "fsl,scu-pd".
+- #address-cells:	Should be 1.
+- #size-cells:		Should be 0.
+
+Required properties for power domain sub nodes:
+- #power-domain-cells:	Must be 0.
+
+Optional Properties:
+- reg:			Resource ID of this power domain.
+			No exist means uncontrollable by user.
+			See detailed Resource ID list from:
+			include/dt-bindings/power/imx-rsrc.h
+- power-domains:	phandle pointing to the parent power domain.
+
+Clock bindings based on SCU Message Protocol
+------------------------------------------------------------
+
+This binding uses the common clock binding[1].
+
+Required properties:
+- compatible:		Should be "fsl,imx8qxp-clock".
+- #clock-cells:		Should be 1. Contains the Clock ID value.
+
+The clock consumer should specify the desired clock by having the clock
+ID in its "clocks" phandle cell.
+
+See the full list of clock IDs from:
+include/dt-bindings/clock/imx8qxp-clock.h
+
+Pinctrl bindings based on SCU Message Protocol
+------------------------------------------------------------
+
+This binding uses the i.MX common pinctrl binding[3].
+
+Required properties:
+- compatible:		Should be "fsl,imx8qxp-iomuxc".
+
+Required properties for Pinctrl sub nodes:
+- fsl,pins:		Each entry consists of 3 integers which represents
+			the mux and config setting for one pin. The first 2
+			integers <pin_id mux_mode> are specified using a
+			PIN_FUNC_ID macro, which can be found in
+			<dt-bindings/pinctrl/pads-imx8qxp.h>.
+			The last integer CONFIG is the pad setting value like
+			pull-up on this pin.
+
+			Please refer to i.MX8QXP Reference Manual for detailed
+			CONFIG settings.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/power/power_domain.txt
+[3] Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
+
+Example (imx8qxp):
+-------------
+lsio_mu1: mailbox@5d1c0000 {
+	...
+	#mbox-cells = <2>;
+};
+
+firmware {
+	scu {
+		compatible = "fsl,imx-scu";
+		mbox-names = "tx0", "tx1", "tx2", "tx3",
+			     "rx0", "rx1", "rx2", "rx3";
+		mboxes = <&lsio_mu1 0 0
+			  &lsio_mu1 0 1
+			  &lsio_mu1 0 2
+			  &lsio_mu1 0 3
+			  &lsio_mu1 1 0
+			  &lsio_mu1 1 1
+			  &lsio_mu1 1 2
+			  &lsio_mu1 1 3>;
+
+		clk: clk {
+			compatible = "fsl,imx8qxp-clk";
+			#clock-cells = <1>;
+		};
+
+		iomuxc {
+			compatible = "fsl,imx8qxp-iomuxc";
+
+			pinctrl_lpuart0: lpuart0grp {
+				fsl,pins = <
+					SC_P_UART0_RX_ADMA_UART0_RX	0x06000020
+					SC_P_UART0_TX_ADMA_UART0_TX	0x06000020
+				>;
+			};
+			...
+		};
+
+		imx8qx-pm {
+			compatible = "fsl,scu-pd";
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			pd_dma: dma-power-domain {
+				#power-domain-cells = <0>;
+
+				pd_dma_lpuart0: dma-lpuart0@57 {
+					reg = <SC_R_UART_0>;
+					#power-domain-cells = <0>;
+					power-domains = <&pd_dma>;
+				};
+				...
+			};
+			...
+		};
+	};
+};
+
+serial@5a060000 {
+	...
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_lpuart0>;
+	clocks = <&clk IMX8QXP_UART0_CLK>,
+		 <&clk IMX8QXP_UART0_IPG_CLK>;
+	clock-names = "per", "ipg";
+	power-domains = <&pd_dma_lpuart0>;
+};
-- 
2.7.4

Re: [PATCH V5 1/5] dt-bindings: arm: fsl: add scu binding doc

[Rob Herring]

On Tue, Aug 21, 2018 at 12:08:21AM +0800, Dong Aisheng wrote:
> The System Controller Firmware (SCFW) is a low-level system function
> which runs on a dedicated Cortex-M core to provide power, clock, and
> resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
> (QM, QP), and i.MX8QX (QXP, DX).
> 
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Jassi Brar <jassisinghbrar@gmail.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: devicetree@vger.kernel.org
> Cc: linux-clk@vger.kernel.org
> Cc: linux-gpio@vger.kernel.org
> Cc: linux-pm@vger.kernel.org
> Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> ---
> v4->v5:
>  * scu node should be under firmware node
>  * add pd/clk/pinctrl binding as well according to Rob's suggestion
>  * switch to new generic MU binding
>    Use 8 separate mu channels in one MU instance for SCU communication
> v3->v4:
>  * fully change to mailbox binding
>  * add child node description
> v2->v3:
>  * update a bit to mailbox binding
> v1->v2:
>  * remove status
>  * changed to mu1
> ---
>  .../devicetree/bindings/arm/freescale/fsl,scu.txt  | 179 +++++++++++++++++++++
>  1 file changed, 179 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> new file mode 100644
> index 0000000..2cd7e4a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> @@ -0,0 +1,179 @@
> +NXP i.MX System Controller Firmware (SCFW) --------------------------------------------------------------------

Think you wanted a newline here              ^?

> +
> +The System Controller Firmware (SCFW) is a low-level system function
> +which runs on a dedicated Cortex-M core to provide power, clock, and
> +resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
> +(QM, QP), and i.MX8QX (QXP, DX).
> +
> +The AP communicates with the SC using a multi-ported MU module found
> +in the LSIO subsystem. The current definition of this MU module provides
> +5 remote AP connections to the SC to support up to 5 execution environments
> +(TZ, HV, standard Linux, etc.). The SC side of this MU module interfaces
> +with the LSIO DSC IP bus. The SC firmware will communicate with this MU
> +using the MSI bus.

How are 5 users supported with only 4 channels defined below?

> +
> +System Controller Device Node:
> +============================================================
> +
> +The scu node with the following properties shall be under the /firmware/ node.
> +
> +Required properties:
> +-------------------
> +- compatible:	should be "fsl,imx-scu".
> +- mbox-names:	should include "tx0", "tx1", "tx2", "tx3",
> +			       "rx0", "rx1", "rx2", "rx3".
> +- mboxes:	List of phandle of 4 MU channels for tx and 4 MU channels
> +		for rx. All 8 MU channels must be in the same MU instance.
> +		Cross instances are not allowed. The MU instance can only
> +		be one of LSIO MU0~M4 for imx8qxp and imx8qm. Users need
> +		to make sure use the one which is not conflict with other
> +		execution environments. e.g. ATF.

How is one supposed to know what channels are in use already?

IMO, ATF should remove the channel it uses before passing the DT to the 
next stage. That doesn't help if later stages get a different DT though.

> +		Note:
> +		Channel 0 must be "tx0" or "rx0".
> +		Channel 1 must be "tx1" or "rx1".
> +		Channel 2 must be "tx2" or "rx2".
> +		Channel 3 must be "tx3" or "rx3".
> +		e.g.
> +		mboxes = <&lsio_mu1 0 0
> +			  &lsio_mu1 0 1
> +			  &lsio_mu1 0 2
> +			  &lsio_mu1 0 3
> +			  &lsio_mu1 1 0
> +			  &lsio_mu1 1 1
> +			  &lsio_mu1 1 2
> +			  &lsio_mu1 1 3>;
> +		See Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> +		for detailed mailbox binding.
> +
> +i.MX SCU Client Device Node:
> +============================================================
> +
> +Client nodes are maintained as children of the relevant IMX-SCU device node.
> +
> +Power domain bindings based on SCU Message Protocol
> +------------------------------------------------------------
> +
> +This binding for the SCU power domain providers uses the generic power
> +domain binding[2].
> +
> +Required properties:
> +- compatible:		Should be "fsl,scu-pd".
> +- #address-cells:	Should be 1.
> +- #size-cells:		Should be 0.
> +
> +Required properties for power domain sub nodes:
> +- #power-domain-cells:	Must be 0.
> +
> +Optional Properties:
> +- reg:			Resource ID of this power domain.
> +			No exist means uncontrollable by user.
> +			See detailed Resource ID list from:
> +			include/dt-bindings/power/imx-rsrc.h
> +- power-domains:	phandle pointing to the parent power domain.
> +
> +Clock bindings based on SCU Message Protocol
> +------------------------------------------------------------
> +
> +This binding uses the common clock binding[1].
> +
> +Required properties:
> +- compatible:		Should be "fsl,imx8qxp-clock".
> +- #clock-cells:		Should be 1. Contains the Clock ID value.

There was a recent patch adding input clocks to other i.MX CCM bindings. 
Is that needed here?

> +
> +The clock consumer should specify the desired clock by having the clock
> +ID in its "clocks" phandle cell.
> +
> +See the full list of clock IDs from:
> +include/dt-bindings/clock/imx8qxp-clock.h
> +
> +Pinctrl bindings based on SCU Message Protocol
> +------------------------------------------------------------
> +
> +This binding uses the i.MX common pinctrl binding[3].
> +
> +Required properties:
> +- compatible:		Should be "fsl,imx8qxp-iomuxc".
> +
> +Required properties for Pinctrl sub nodes:
> +- fsl,pins:		Each entry consists of 3 integers which represents
> +			the mux and config setting for one pin. The first 2
> +			integers <pin_id mux_mode> are specified using a
> +			PIN_FUNC_ID macro, which can be found in
> +			<dt-bindings/pinctrl/pads-imx8qxp.h>.
> +			The last integer CONFIG is the pad setting value like
> +			pull-up on this pin.
> +
> +			Please refer to i.MX8QXP Reference Manual for detailed
> +			CONFIG settings.
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +[2] Documentation/devicetree/bindings/power/power_domain.txt
> +[3] Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
> +
> +Example (imx8qxp):
> +-------------
> +lsio_mu1: mailbox@5d1c0000 {
> +	...
> +	#mbox-cells = <2>;
> +};
> +
> +firmware {
> +	scu {
> +		compatible = "fsl,imx-scu";
> +		mbox-names = "tx0", "tx1", "tx2", "tx3",
> +			     "rx0", "rx1", "rx2", "rx3";
> +		mboxes = <&lsio_mu1 0 0
> +			  &lsio_mu1 0 1
> +			  &lsio_mu1 0 2
> +			  &lsio_mu1 0 3
> +			  &lsio_mu1 1 0
> +			  &lsio_mu1 1 1
> +			  &lsio_mu1 1 2
> +			  &lsio_mu1 1 3>;
> +
> +		clk: clk {
> +			compatible = "fsl,imx8qxp-clk";
> +			#clock-cells = <1>;
> +		};
> +
> +		iomuxc {
> +			compatible = "fsl,imx8qxp-iomuxc";
> +
> +			pinctrl_lpuart0: lpuart0grp {
> +				fsl,pins = <
> +					SC_P_UART0_RX_ADMA_UART0_RX	0x06000020
> +					SC_P_UART0_TX_ADMA_UART0_TX	0x06000020
> +				>;
> +			};
> +			...
> +		};
> +
> +		imx8qx-pm {
> +			compatible = "fsl,scu-pd";
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			pd_dma: dma-power-domain {
> +				#power-domain-cells = <0>;
> +
> +				pd_dma_lpuart0: dma-lpuart0@57 {
> +					reg = <SC_R_UART_0>;
> +					#power-domain-cells = <0>;
> +					power-domains = <&pd_dma>;
> +				};
> +				...
> +			};
> +			...
> +		};
> +	};
> +};
> +
> +serial@5a060000 {
> +	...
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_lpuart0>;
> +	clocks = <&clk IMX8QXP_UART0_CLK>,
> +		 <&clk IMX8QXP_UART0_IPG_CLK>;
> +	clock-names = "per", "ipg";
> +	power-domains = <&pd_dma_lpuart0>;
> +};
> -- 
> 2.7.4
> 

[PATCH V5 1/5] dt-bindings: arm: fsl: add scu binding doc

[Rob Herring]

On Tue, Aug 21, 2018 at 12:08:21AM +0800, Dong Aisheng wrote:
> The System Controller Firmware (SCFW) is a low-level system function
> which runs on a dedicated Cortex-M core to provide power, clock, and
> resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
> (QM, QP), and i.MX8QX (QXP, DX).
> 
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Jassi Brar <jassisinghbrar@gmail.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: devicetree at vger.kernel.org
> Cc: linux-clk at vger.kernel.org
> Cc: linux-gpio at vger.kernel.org
> Cc: linux-pm at vger.kernel.org
> Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> ---
> v4->v5:
>  * scu node should be under firmware node
>  * add pd/clk/pinctrl binding as well according to Rob's suggestion
>  * switch to new generic MU binding
>    Use 8 separate mu channels in one MU instance for SCU communication
> v3->v4:
>  * fully change to mailbox binding
>  * add child node description
> v2->v3:
>  * update a bit to mailbox binding
> v1->v2:
>  * remove status
>  * changed to mu1
> ---
>  .../devicetree/bindings/arm/freescale/fsl,scu.txt  | 179 +++++++++++++++++++++
>  1 file changed, 179 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> new file mode 100644
> index 0000000..2cd7e4a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> @@ -0,0 +1,179 @@
> +NXP i.MX System Controller Firmware (SCFW) --------------------------------------------------------------------

Think you wanted a newline here              ^?

> +
> +The System Controller Firmware (SCFW) is a low-level system function
> +which runs on a dedicated Cortex-M core to provide power, clock, and
> +resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
> +(QM, QP), and i.MX8QX (QXP, DX).
> +
> +The AP communicates with the SC using a multi-ported MU module found
> +in the LSIO subsystem. The current definition of this MU module provides
> +5 remote AP connections to the SC to support up to 5 execution environments
> +(TZ, HV, standard Linux, etc.). The SC side of this MU module interfaces
> +with the LSIO DSC IP bus. The SC firmware will communicate with this MU
> +using the MSI bus.

How are 5 users supported with only 4 channels defined below?

> +
> +System Controller Device Node:
> +============================================================
> +
> +The scu node with the following properties shall be under the /firmware/ node.
> +
> +Required properties:
> +-------------------
> +- compatible:	should be "fsl,imx-scu".
> +- mbox-names:	should include "tx0", "tx1", "tx2", "tx3",
> +			       "rx0", "rx1", "rx2", "rx3".
> +- mboxes:	List of phandle of 4 MU channels for tx and 4 MU channels
> +		for rx. All 8 MU channels must be in the same MU instance.
> +		Cross instances are not allowed. The MU instance can only
> +		be one of LSIO MU0~M4 for imx8qxp and imx8qm. Users need
> +		to make sure use the one which is not conflict with other
> +		execution environments. e.g. ATF.

How is one supposed to know what channels are in use already?

IMO, ATF should remove the channel it uses before passing the DT to the 
next stage. That doesn't help if later stages get a different DT though.

> +		Note:
> +		Channel 0 must be "tx0" or "rx0".
> +		Channel 1 must be "tx1" or "rx1".
> +		Channel 2 must be "tx2" or "rx2".
> +		Channel 3 must be "tx3" or "rx3".
> +		e.g.
> +		mboxes = <&lsio_mu1 0 0
> +			  &lsio_mu1 0 1
> +			  &lsio_mu1 0 2
> +			  &lsio_mu1 0 3
> +			  &lsio_mu1 1 0
> +			  &lsio_mu1 1 1
> +			  &lsio_mu1 1 2
> +			  &lsio_mu1 1 3>;
> +		See Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> +		for detailed mailbox binding.
> +
> +i.MX SCU Client Device Node:
> +============================================================
> +
> +Client nodes are maintained as children of the relevant IMX-SCU device node.
> +
> +Power domain bindings based on SCU Message Protocol
> +------------------------------------------------------------
> +
> +This binding for the SCU power domain providers uses the generic power
> +domain binding[2].
> +
> +Required properties:
> +- compatible:		Should be "fsl,scu-pd".
> +- #address-cells:	Should be 1.
> +- #size-cells:		Should be 0.
> +
> +Required properties for power domain sub nodes:
> +- #power-domain-cells:	Must be 0.
> +
> +Optional Properties:
> +- reg:			Resource ID of this power domain.
> +			No exist means uncontrollable by user.
> +			See detailed Resource ID list from:
> +			include/dt-bindings/power/imx-rsrc.h
> +- power-domains:	phandle pointing to the parent power domain.
> +
> +Clock bindings based on SCU Message Protocol
> +------------------------------------------------------------
> +
> +This binding uses the common clock binding[1].
> +
> +Required properties:
> +- compatible:		Should be "fsl,imx8qxp-clock".
> +- #clock-cells:		Should be 1. Contains the Clock ID value.

There was a recent patch adding input clocks to other i.MX CCM bindings. 
Is that needed here?

> +
> +The clock consumer should specify the desired clock by having the clock
> +ID in its "clocks" phandle cell.
> +
> +See the full list of clock IDs from:
> +include/dt-bindings/clock/imx8qxp-clock.h
> +
> +Pinctrl bindings based on SCU Message Protocol
> +------------------------------------------------------------
> +
> +This binding uses the i.MX common pinctrl binding[3].
> +
> +Required properties:
> +- compatible:		Should be "fsl,imx8qxp-iomuxc".
> +
> +Required properties for Pinctrl sub nodes:
> +- fsl,pins:		Each entry consists of 3 integers which represents
> +			the mux and config setting for one pin. The first 2
> +			integers <pin_id mux_mode> are specified using a
> +			PIN_FUNC_ID macro, which can be found in
> +			<dt-bindings/pinctrl/pads-imx8qxp.h>.
> +			The last integer CONFIG is the pad setting value like
> +			pull-up on this pin.
> +
> +			Please refer to i.MX8QXP Reference Manual for detailed
> +			CONFIG settings.
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +[2] Documentation/devicetree/bindings/power/power_domain.txt
> +[3] Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
> +
> +Example (imx8qxp):
> +-------------
> +lsio_mu1: mailbox at 5d1c0000 {
> +	...
> +	#mbox-cells = <2>;
> +};
> +
> +firmware {
> +	scu {
> +		compatible = "fsl,imx-scu";
> +		mbox-names = "tx0", "tx1", "tx2", "tx3",
> +			     "rx0", "rx1", "rx2", "rx3";
> +		mboxes = <&lsio_mu1 0 0
> +			  &lsio_mu1 0 1
> +			  &lsio_mu1 0 2
> +			  &lsio_mu1 0 3
> +			  &lsio_mu1 1 0
> +			  &lsio_mu1 1 1
> +			  &lsio_mu1 1 2
> +			  &lsio_mu1 1 3>;
> +
> +		clk: clk {
> +			compatible = "fsl,imx8qxp-clk";
> +			#clock-cells = <1>;
> +		};
> +
> +		iomuxc {
> +			compatible = "fsl,imx8qxp-iomuxc";
> +
> +			pinctrl_lpuart0: lpuart0grp {
> +				fsl,pins = <
> +					SC_P_UART0_RX_ADMA_UART0_RX	0x06000020
> +					SC_P_UART0_TX_ADMA_UART0_TX	0x06000020
> +				>;
> +			};
> +			...
> +		};
> +
> +		imx8qx-pm {
> +			compatible = "fsl,scu-pd";
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			pd_dma: dma-power-domain {
> +				#power-domain-cells = <0>;
> +
> +				pd_dma_lpuart0: dma-lpuart0 at 57 {
> +					reg = <SC_R_UART_0>;
> +					#power-domain-cells = <0>;
> +					power-domains = <&pd_dma>;
> +				};
> +				...
> +			};
> +			...
> +		};
> +	};
> +};
> +
> +serial at 5a060000 {
> +	...
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_lpuart0>;
> +	clocks = <&clk IMX8QXP_UART0_CLK>,
> +		 <&clk IMX8QXP_UART0_IPG_CLK>;
> +	clock-names = "per", "ipg";
> +	power-domains = <&pd_dma_lpuart0>;
> +};
> -- 
> 2.7.4
> 

Re: [PATCH V5 1/5] dt-bindings: arm: fsl: add scu binding doc

[Rob Herring]

On Tue, Aug 21, 2018 at 12:08:21AM +0800, Dong Aisheng wrote:
> The System Controller Firmware (SCFW) is a low-level system function
> which runs on a dedicated Cortex-M core to provide power, clock, and
> resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
> (QM, QP), and i.MX8QX (QXP, DX).
> 
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Jassi Brar <jassisinghbrar@gmail.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: devicetree@vger.kernel.org
> Cc: linux-clk@vger.kernel.org
> Cc: linux-gpio@vger.kernel.org
> Cc: linux-pm@vger.kernel.org
> Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> ---
> v4->v5:
>  * scu node should be under firmware node
>  * add pd/clk/pinctrl binding as well according to Rob's suggestion
>  * switch to new generic MU binding
>    Use 8 separate mu channels in one MU instance for SCU communication
> v3->v4:
>  * fully change to mailbox binding
>  * add child node description
> v2->v3:
>  * update a bit to mailbox binding
> v1->v2:
>  * remove status
>  * changed to mu1
> ---
>  .../devicetree/bindings/arm/freescale/fsl,scu.txt  | 179 +++++++++++++++++++++
>  1 file changed, 179 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> new file mode 100644
> index 0000000..2cd7e4a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> @@ -0,0 +1,179 @@
> +NXP i.MX System Controller Firmware (SCFW) --------------------------------------------------------------------

Think you wanted a newline here              ^?

> +
> +The System Controller Firmware (SCFW) is a low-level system function
> +which runs on a dedicated Cortex-M core to provide power, clock, and
> +resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
> +(QM, QP), and i.MX8QX (QXP, DX).
> +
> +The AP communicates with the SC using a multi-ported MU module found
> +in the LSIO subsystem. The current definition of this MU module provides
> +5 remote AP connections to the SC to support up to 5 execution environments
> +(TZ, HV, standard Linux, etc.). The SC side of this MU module interfaces
> +with the LSIO DSC IP bus. The SC firmware will communicate with this MU
> +using the MSI bus.

How are 5 users supported with only 4 channels defined below?

> +
> +System Controller Device Node:
> +============================================================
> +
> +The scu node with the following properties shall be under the /firmware/ node.
> +
> +Required properties:
> +-------------------
> +- compatible:	should be "fsl,imx-scu".
> +- mbox-names:	should include "tx0", "tx1", "tx2", "tx3",
> +			       "rx0", "rx1", "rx2", "rx3".
> +- mboxes:	List of phandle of 4 MU channels for tx and 4 MU channels
> +		for rx. All 8 MU channels must be in the same MU instance.
> +		Cross instances are not allowed. The MU instance can only
> +		be one of LSIO MU0~M4 for imx8qxp and imx8qm. Users need
> +		to make sure use the one which is not conflict with other
> +		execution environments. e.g. ATF.

How is one supposed to know what channels are in use already?

IMO, ATF should remove the channel it uses before passing the DT to the 
next stage. That doesn't help if later stages get a different DT though.

> +		Note:
> +		Channel 0 must be "tx0" or "rx0".
> +		Channel 1 must be "tx1" or "rx1".
> +		Channel 2 must be "tx2" or "rx2".
> +		Channel 3 must be "tx3" or "rx3".
> +		e.g.
> +		mboxes = <&lsio_mu1 0 0
> +			  &lsio_mu1 0 1
> +			  &lsio_mu1 0 2
> +			  &lsio_mu1 0 3
> +			  &lsio_mu1 1 0
> +			  &lsio_mu1 1 1
> +			  &lsio_mu1 1 2
> +			  &lsio_mu1 1 3>;
> +		See Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> +		for detailed mailbox binding.
> +
> +i.MX SCU Client Device Node:
> +============================================================
> +
> +Client nodes are maintained as children of the relevant IMX-SCU device node.
> +
> +Power domain bindings based on SCU Message Protocol
> +------------------------------------------------------------
> +
> +This binding for the SCU power domain providers uses the generic power
> +domain binding[2].
> +
> +Required properties:
> +- compatible:		Should be "fsl,scu-pd".
> +- #address-cells:	Should be 1.
> +- #size-cells:		Should be 0.
> +
> +Required properties for power domain sub nodes:
> +- #power-domain-cells:	Must be 0.
> +
> +Optional Properties:
> +- reg:			Resource ID of this power domain.
> +			No exist means uncontrollable by user.
> +			See detailed Resource ID list from:
> +			include/dt-bindings/power/imx-rsrc.h
> +- power-domains:	phandle pointing to the parent power domain.
> +
> +Clock bindings based on SCU Message Protocol
> +------------------------------------------------------------
> +
> +This binding uses the common clock binding[1].
> +
> +Required properties:
> +- compatible:		Should be "fsl,imx8qxp-clock".
> +- #clock-cells:		Should be 1. Contains the Clock ID value.

There was a recent patch adding input clocks to other i.MX CCM bindings. 
Is that needed here?

> +
> +The clock consumer should specify the desired clock by having the clock
> +ID in its "clocks" phandle cell.
> +
> +See the full list of clock IDs from:
> +include/dt-bindings/clock/imx8qxp-clock.h
> +
> +Pinctrl bindings based on SCU Message Protocol
> +------------------------------------------------------------
> +
> +This binding uses the i.MX common pinctrl binding[3].
> +
> +Required properties:
> +- compatible:		Should be "fsl,imx8qxp-iomuxc".
> +
> +Required properties for Pinctrl sub nodes:
> +- fsl,pins:		Each entry consists of 3 integers which represents
> +			the mux and config setting for one pin. The first 2
> +			integers <pin_id mux_mode> are specified using a
> +			PIN_FUNC_ID macro, which can be found in
> +			<dt-bindings/pinctrl/pads-imx8qxp.h>.
> +			The last integer CONFIG is the pad setting value like
> +			pull-up on this pin.
> +
> +			Please refer to i.MX8QXP Reference Manual for detailed
> +			CONFIG settings.
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +[2] Documentation/devicetree/bindings/power/power_domain.txt
> +[3] Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
> +
> +Example (imx8qxp):
> +-------------
> +lsio_mu1: mailbox@5d1c0000 {
> +	...
> +	#mbox-cells = <2>;
> +};
> +
> +firmware {
> +	scu {
> +		compatible = "fsl,imx-scu";
> +		mbox-names = "tx0", "tx1", "tx2", "tx3",
> +			     "rx0", "rx1", "rx2", "rx3";
> +		mboxes = <&lsio_mu1 0 0
> +			  &lsio_mu1 0 1
> +			  &lsio_mu1 0 2
> +			  &lsio_mu1 0 3
> +			  &lsio_mu1 1 0
> +			  &lsio_mu1 1 1
> +			  &lsio_mu1 1 2
> +			  &lsio_mu1 1 3>;
> +
> +		clk: clk {
> +			compatible = "fsl,imx8qxp-clk";
> +			#clock-cells = <1>;
> +		};
> +
> +		iomuxc {
> +			compatible = "fsl,imx8qxp-iomuxc";
> +
> +			pinctrl_lpuart0: lpuart0grp {
> +				fsl,pins = <
> +					SC_P_UART0_RX_ADMA_UART0_RX	0x06000020
> +					SC_P_UART0_TX_ADMA_UART0_TX	0x06000020
> +				>;
> +			};
> +			...
> +		};
> +
> +		imx8qx-pm {
> +			compatible = "fsl,scu-pd";
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			pd_dma: dma-power-domain {
> +				#power-domain-cells = <0>;
> +
> +				pd_dma_lpuart0: dma-lpuart0@57 {
> +					reg = <SC_R_UART_0>;
> +					#power-domain-cells = <0>;
> +					power-domains = <&pd_dma>;
> +				};
> +				...
> +			};
> +			...
> +		};
> +	};
> +};
> +
> +serial@5a060000 {
> +	...
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_lpuart0>;
> +	clocks = <&clk IMX8QXP_UART0_CLK>,
> +		 <&clk IMX8QXP_UART0_IPG_CLK>;
> +	clock-names = "per", "ipg";
> +	power-domains = <&pd_dma_lpuart0>;
> +};
> -- 
> 2.7.4
> 

RE: [PATCH V5 1/5] dt-bindings: arm: fsl: add scu binding doc

[A.s. Dong]

Hi Rob,

> -----Original Message-----
> From: Rob Herring <robh@kernel.org>
> Sent: Tuesday, August 21, 2018 2:12 AM
> To: A.s. Dong <aisheng.dong@nxp.com>
> Cc: linux-arm-kernel@lists.infradead.org; dongas86@gmail.com;
> kernel@pengutronix.de; shawnguo@kernel.org; Fabio Estevam
> <fabio.estevam@nxp.com>; dl-linux-imx <linux-imx@nxp.com>; Mark
> Rutland <mark.rutland@arm.com>; Jassi Brar <jassisinghbrar@gmail.com>;
> Linus Walleij <linus.walleij@linaro.org>; Stephen Boyd <sboyd@kernel.org>;
> Rafael J. Wysocki <rjw@rjwysocki.net>; Ulf Hansson
> <ulf.hansson@linaro.org>; devicetree@vger.kernel.org; linux-
> clk@vger.kernel.org; linux-gpio@vger.kernel.org; linux-pm@vger.kernel.org
> Subject: Re: [PATCH V5 1/5] dt-bindings: arm: fsl: add scu binding doc
> 
> On Tue, Aug 21, 2018 at 12:08:21AM +0800, Dong Aisheng wrote:
> > The System Controller Firmware (SCFW) is a low-level system function
> > which runs on a dedicated Cortex-M core to provide power, clock, and
> > resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
> > (QM, QP), and i.MX8QX (QXP, DX).
> >
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: Sascha Hauer <kernel@pengutronix.de>
> > Cc: Jassi Brar <jassisinghbrar@gmail.com>
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Cc: Stephen Boyd <sboyd@kernel.org>
> > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> > Cc: Ulf Hansson <ulf.hansson@linaro.org>
> > Cc: Shawn Guo <shawnguo@kernel.org>
> > Cc: Fabio Estevam <fabio.estevam@nxp.com>
> > Cc: devicetree@vger.kernel.org
> > Cc: linux-clk@vger.kernel.org
> > Cc: linux-gpio@vger.kernel.org
> > Cc: linux-pm@vger.kernel.org
> > Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> > ---
> > v4->v5:
> >  * scu node should be under firmware node
> >  * add pd/clk/pinctrl binding as well according to Rob's suggestion
> >  * switch to new generic MU binding
> >    Use 8 separate mu channels in one MU instance for SCU communication
> > v3->v4:
> >  * fully change to mailbox binding
> >  * add child node description
> > v2->v3:
> >  * update a bit to mailbox binding
> > v1->v2:
> >  * remove status
> >  * changed to mu1
> > ---
> >  .../devicetree/bindings/arm/freescale/fsl,scu.txt  | 179
> > +++++++++++++++++++++
> >  1 file changed, 179 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > new file mode 100644
> > index 0000000..2cd7e4a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > @@ -0,0 +1,179 @@
> > +NXP i.MX System Controller Firmware (SCFW)
> > +--------------------------------------------------------------------
> 
> Think you wanted a newline here              ^?

Yes, of course.
It seems to be introduced by mistake.
Thanks for reminder.

> 
> > +
> > +The System Controller Firmware (SCFW) is a low-level system function
> > +which runs on a dedicated Cortex-M core to provide power, clock, and
> > +resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
> > +(QM, QP), and i.MX8QX (QXP, DX).
> > +
> > +The AP communicates with the SC using a multi-ported MU module found
> > +in the LSIO subsystem. The current definition of this MU module
> > +provides
> > +5 remote AP connections to the SC to support up to 5 execution
> > +environments (TZ, HV, standard Linux, etc.). The SC side of this MU
> > +module interfaces with the LSIO DSC IP bus. The SC firmware will
> > +communicate with this MU using the MSI bus.
> 
> How are 5 users supported with only 4 channels defined below?

There're 5 MU instances designed to be specifically communicate with
SCU Firmware on MX8 hardware.

With the new generic mu binding [1], each MU instance is abstracted
Into 16 virtual MU channels. (4 Tx, 4 Rx, 4 Tx doorbell, 4 Rx doorbell).
(MU has 4 pair of Tx/Rx data register which can be used to send/receive
multi words. With new binding, each data register is abstracted into one
MU channel, totally 8 channels for data transfer).

SCU protocol is already designed to uses all data registers to send/receive
multi words according to MU hardware reference manual. So it must
use all channels in one MU instances with new binding.

On MX8, it can be one of LSIO MU0~M4.
 
[1] https://patchwork.kernel.org/patch/10554565/

> 
> > +
> > +System Controller Device Node:
> >
> +=========================================================
> ===
> > +
> > +The scu node with the following properties shall be under the /firmware/
> node.
> > +
> > +Required properties:
> > +-------------------
> > +- compatible:	should be "fsl,imx-scu".
> > +- mbox-names:	should include "tx0", "tx1", "tx2", "tx3",
> > +			       "rx0", "rx1", "rx2", "rx3".
> > +- mboxes:	List of phandle of 4 MU channels for tx and 4 MU channels
> > +		for rx. All 8 MU channels must be in the same MU instance.
> > +		Cross instances are not allowed. The MU instance can only
> > +		be one of LSIO MU0~M4 for imx8qxp and imx8qm. Users
> need
> > +		to make sure use the one which is not conflict with other
> > +		execution environments. e.g. ATF.
> 
> How is one supposed to know what channels are in use already?
> 

Currently it's simply predefined.
E.g. ATF uses MU0 and u-Boot & Kernel uses MU1.

> IMO, ATF should remove the channel it uses before passing the DT to the
> next stage. 

Sounds like a good idea.
To be more specific, you mean simply marking the MU node status used in ATF
to be "disabled" before passing to the next stage, am I understand correct?

> That doesn't help if later stages get a different DT though.

Doesn't help? Sorry a bit confusing...

> 
> > +		Note:
> > +		Channel 0 must be "tx0" or "rx0".
> > +		Channel 1 must be "tx1" or "rx1".
> > +		Channel 2 must be "tx2" or "rx2".
> > +		Channel 3 must be "tx3" or "rx3".
> > +		e.g.
> > +		mboxes = <&lsio_mu1 0 0
> > +			  &lsio_mu1 0 1
> > +			  &lsio_mu1 0 2
> > +			  &lsio_mu1 0 3
> > +			  &lsio_mu1 1 0
> > +			  &lsio_mu1 1 1
> > +			  &lsio_mu1 1 2
> > +			  &lsio_mu1 1 3>;
> > +		See Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> > +		for detailed mailbox binding.
> > +
> > +i.MX SCU Client Device Node:
> >
> +=========================================================
> ===
> > +
> > +Client nodes are maintained as children of the relevant IMX-SCU device
> node.
> > +
> > +Power domain bindings based on SCU Message Protocol
> > +------------------------------------------------------------
> > +
> > +This binding for the SCU power domain providers uses the generic
> > +power domain binding[2].
> > +
> > +Required properties:
> > +- compatible:		Should be "fsl,scu-pd".
> > +- #address-cells:	Should be 1.
> > +- #size-cells:		Should be 0.
> > +
> > +Required properties for power domain sub nodes:
> > +- #power-domain-cells:	Must be 0.
> > +
> > +Optional Properties:
> > +- reg:			Resource ID of this power domain.
> > +			No exist means uncontrollable by user.
> > +			See detailed Resource ID list from:
> > +			include/dt-bindings/power/imx-rsrc.h
> > +- power-domains:	phandle pointing to the parent power domain.
> > +
> > +Clock bindings based on SCU Message Protocol
> > +------------------------------------------------------------
> > +
> > +This binding uses the common clock binding[1].
> > +
> > +Required properties:
> > +- compatible:		Should be "fsl,imx8qxp-clock".
> > +- #clock-cells:		Should be 1. Contains the Clock ID value.
> 
> There was a recent patch adding input clocks to other i.MX CCM bindings.
> Is that needed here?
> 

Will double check it, thanks for reminder.

Regards
Dong Aisheng

> > +
> > +The clock consumer should specify the desired clock by having the
> > +clock ID in its "clocks" phandle cell.
> > +
> > +See the full list of clock IDs from:
> > +include/dt-bindings/clock/imx8qxp-clock.h
> > +
> > +Pinctrl bindings based on SCU Message Protocol
> > +------------------------------------------------------------
> > +
> > +This binding uses the i.MX common pinctrl binding[3].
> > +
> > +Required properties:
> > +- compatible:		Should be "fsl,imx8qxp-iomuxc".
> > +
> > +Required properties for Pinctrl sub nodes:
> > +- fsl,pins:		Each entry consists of 3 integers which represents
> > +			the mux and config setting for one pin. The first 2
> > +			integers <pin_id mux_mode> are specified using a
> > +			PIN_FUNC_ID macro, which can be found in
> > +			<dt-bindings/pinctrl/pads-imx8qxp.h>.
> > +			The last integer CONFIG is the pad setting value like
> > +			pull-up on this pin.
> > +
> > +			Please refer to i.MX8QXP Reference Manual for
> detailed
> > +			CONFIG settings.
> > +
> > +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> > +[2] Documentation/devicetree/bindings/power/power_domain.txt
> > +[3] Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
> > +
> > +Example (imx8qxp):
> > +-------------
> > +lsio_mu1: mailbox@5d1c0000 {
> > +	...
> > +	#mbox-cells = <2>;
> > +};
> > +
> > +firmware {
> > +	scu {
> > +		compatible = "fsl,imx-scu";
> > +		mbox-names = "tx0", "tx1", "tx2", "tx3",
> > +			     "rx0", "rx1", "rx2", "rx3";
> > +		mboxes = <&lsio_mu1 0 0
> > +			  &lsio_mu1 0 1
> > +			  &lsio_mu1 0 2
> > +			  &lsio_mu1 0 3
> > +			  &lsio_mu1 1 0
> > +			  &lsio_mu1 1 1
> > +			  &lsio_mu1 1 2
> > +			  &lsio_mu1 1 3>;
> > +
> > +		clk: clk {
> > +			compatible = "fsl,imx8qxp-clk";
> > +			#clock-cells = <1>;
> > +		};
> > +
> > +		iomuxc {
> > +			compatible = "fsl,imx8qxp-iomuxc";
> > +
> > +			pinctrl_lpuart0: lpuart0grp {
> > +				fsl,pins = <
> > +					SC_P_UART0_RX_ADMA_UART0_RX
> 	0x06000020
> > +					SC_P_UART0_TX_ADMA_UART0_TX
> 	0x06000020
> > +				>;
> > +			};
> > +			...
> > +		};
> > +
> > +		imx8qx-pm {
> > +			compatible = "fsl,scu-pd";
> > +			#address-cells = <1>;
> > +			#size-cells = <0>;
> > +
> > +			pd_dma: dma-power-domain {
> > +				#power-domain-cells = <0>;
> > +
> > +				pd_dma_lpuart0: dma-lpuart0@57 {
> > +					reg = <SC_R_UART_0>;
> > +					#power-domain-cells = <0>;
> > +					power-domains = <&pd_dma>;
> > +				};
> > +				...
> > +			};
> > +			...
> > +		};
> > +	};
> > +};
> > +
> > +serial@5a060000 {
> > +	...
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_lpuart0>;
> > +	clocks = <&clk IMX8QXP_UART0_CLK>,
> > +		 <&clk IMX8QXP_UART0_IPG_CLK>;
> > +	clock-names = "per", "ipg";
> > +	power-domains = <&pd_dma_lpuart0>;
> > +};
> > --
> > 2.7.4
> >

[PATCH V5 1/5] dt-bindings: arm: fsl: add scu binding doc

[A.s. Dong]

Hi Rob,

> -----Original Message-----
> From: Rob Herring <robh@kernel.org>
> Sent: Tuesday, August 21, 2018 2:12 AM
> To: A.s. Dong <aisheng.dong@nxp.com>
> Cc: linux-arm-kernel at lists.infradead.org; dongas86 at gmail.com;
> kernel at pengutronix.de; shawnguo at kernel.org; Fabio Estevam
> <fabio.estevam@nxp.com>; dl-linux-imx <linux-imx@nxp.com>; Mark
> Rutland <mark.rutland@arm.com>; Jassi Brar <jassisinghbrar@gmail.com>;
> Linus Walleij <linus.walleij@linaro.org>; Stephen Boyd <sboyd@kernel.org>;
> Rafael J. Wysocki <rjw@rjwysocki.net>; Ulf Hansson
> <ulf.hansson@linaro.org>; devicetree at vger.kernel.org; linux-
> clk at vger.kernel.org; linux-gpio at vger.kernel.org; linux-pm at vger.kernel.org
> Subject: Re: [PATCH V5 1/5] dt-bindings: arm: fsl: add scu binding doc
> 
> On Tue, Aug 21, 2018 at 12:08:21AM +0800, Dong Aisheng wrote:
> > The System Controller Firmware (SCFW) is a low-level system function
> > which runs on a dedicated Cortex-M core to provide power, clock, and
> > resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
> > (QM, QP), and i.MX8QX (QXP, DX).
> >
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: Sascha Hauer <kernel@pengutronix.de>
> > Cc: Jassi Brar <jassisinghbrar@gmail.com>
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Cc: Stephen Boyd <sboyd@kernel.org>
> > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> > Cc: Ulf Hansson <ulf.hansson@linaro.org>
> > Cc: Shawn Guo <shawnguo@kernel.org>
> > Cc: Fabio Estevam <fabio.estevam@nxp.com>
> > Cc: devicetree at vger.kernel.org
> > Cc: linux-clk at vger.kernel.org
> > Cc: linux-gpio at vger.kernel.org
> > Cc: linux-pm at vger.kernel.org
> > Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> > ---
> > v4->v5:
> >  * scu node should be under firmware node
> >  * add pd/clk/pinctrl binding as well according to Rob's suggestion
> >  * switch to new generic MU binding
> >    Use 8 separate mu channels in one MU instance for SCU communication
> > v3->v4:
> >  * fully change to mailbox binding
> >  * add child node description
> > v2->v3:
> >  * update a bit to mailbox binding
> > v1->v2:
> >  * remove status
> >  * changed to mu1
> > ---
> >  .../devicetree/bindings/arm/freescale/fsl,scu.txt  | 179
> > +++++++++++++++++++++
> >  1 file changed, 179 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > new file mode 100644
> > index 0000000..2cd7e4a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > @@ -0,0 +1,179 @@
> > +NXP i.MX System Controller Firmware (SCFW)
> > +--------------------------------------------------------------------
> 
> Think you wanted a newline here              ^?

Yes, of course.
It seems to be introduced by mistake.
Thanks for reminder.

> 
> > +
> > +The System Controller Firmware (SCFW) is a low-level system function
> > +which runs on a dedicated Cortex-M core to provide power, clock, and
> > +resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
> > +(QM, QP), and i.MX8QX (QXP, DX).
> > +
> > +The AP communicates with the SC using a multi-ported MU module found
> > +in the LSIO subsystem. The current definition of this MU module
> > +provides
> > +5 remote AP connections to the SC to support up to 5 execution
> > +environments (TZ, HV, standard Linux, etc.). The SC side of this MU
> > +module interfaces with the LSIO DSC IP bus. The SC firmware will
> > +communicate with this MU using the MSI bus.
> 
> How are 5 users supported with only 4 channels defined below?

There're 5 MU instances designed to be specifically communicate with
SCU Firmware on MX8 hardware.

With the new generic mu binding [1], each MU instance is abstracted
Into 16 virtual MU channels. (4 Tx, 4 Rx, 4 Tx doorbell, 4 Rx doorbell).
(MU has 4 pair of Tx/Rx data register which can be used to send/receive
multi words. With new binding, each data register is abstracted into one
MU channel, totally 8 channels for data transfer).

SCU protocol is already designed to uses all data registers to send/receive
multi words according to MU hardware reference manual. So it must
use all channels in one MU instances with new binding.

On MX8, it can be one of LSIO MU0~M4.
 
[1] https://patchwork.kernel.org/patch/10554565/

> 
> > +
> > +System Controller Device Node:
> >
> +=========================================================
> ===
> > +
> > +The scu node with the following properties shall be under the /firmware/
> node.
> > +
> > +Required properties:
> > +-------------------
> > +- compatible:	should be "fsl,imx-scu".
> > +- mbox-names:	should include "tx0", "tx1", "tx2", "tx3",
> > +			       "rx0", "rx1", "rx2", "rx3".
> > +- mboxes:	List of phandle of 4 MU channels for tx and 4 MU channels
> > +		for rx. All 8 MU channels must be in the same MU instance.
> > +		Cross instances are not allowed. The MU instance can only
> > +		be one of LSIO MU0~M4 for imx8qxp and imx8qm. Users
> need
> > +		to make sure use the one which is not conflict with other
> > +		execution environments. e.g. ATF.
> 
> How is one supposed to know what channels are in use already?
> 

Currently it's simply predefined.
E.g. ATF uses MU0 and u-Boot & Kernel uses MU1.

> IMO, ATF should remove the channel it uses before passing the DT to the
> next stage. 

Sounds like a good idea.
To be more specific, you mean simply marking the MU node status used in ATF
to be "disabled" before passing to the next stage, am I understand correct?

> That doesn't help if later stages get a different DT though.

Doesn't help? Sorry a bit confusing...

> 
> > +		Note:
> > +		Channel 0 must be "tx0" or "rx0".
> > +		Channel 1 must be "tx1" or "rx1".
> > +		Channel 2 must be "tx2" or "rx2".
> > +		Channel 3 must be "tx3" or "rx3".
> > +		e.g.
> > +		mboxes = <&lsio_mu1 0 0
> > +			  &lsio_mu1 0 1
> > +			  &lsio_mu1 0 2
> > +			  &lsio_mu1 0 3
> > +			  &lsio_mu1 1 0
> > +			  &lsio_mu1 1 1
> > +			  &lsio_mu1 1 2
> > +			  &lsio_mu1 1 3>;
> > +		See Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> > +		for detailed mailbox binding.
> > +
> > +i.MX SCU Client Device Node:
> >
> +=========================================================
> ===
> > +
> > +Client nodes are maintained as children of the relevant IMX-SCU device
> node.
> > +
> > +Power domain bindings based on SCU Message Protocol
> > +------------------------------------------------------------
> > +
> > +This binding for the SCU power domain providers uses the generic
> > +power domain binding[2].
> > +
> > +Required properties:
> > +- compatible:		Should be "fsl,scu-pd".
> > +- #address-cells:	Should be 1.
> > +- #size-cells:		Should be 0.
> > +
> > +Required properties for power domain sub nodes:
> > +- #power-domain-cells:	Must be 0.
> > +
> > +Optional Properties:
> > +- reg:			Resource ID of this power domain.
> > +			No exist means uncontrollable by user.
> > +			See detailed Resource ID list from:
> > +			include/dt-bindings/power/imx-rsrc.h
> > +- power-domains:	phandle pointing to the parent power domain.
> > +
> > +Clock bindings based on SCU Message Protocol
> > +------------------------------------------------------------
> > +
> > +This binding uses the common clock binding[1].
> > +
> > +Required properties:
> > +- compatible:		Should be "fsl,imx8qxp-clock".
> > +- #clock-cells:		Should be 1. Contains the Clock ID value.
> 
> There was a recent patch adding input clocks to other i.MX CCM bindings.
> Is that needed here?
> 

Will double check it, thanks for reminder.

Regards
Dong Aisheng

> > +
> > +The clock consumer should specify the desired clock by having the
> > +clock ID in its "clocks" phandle cell.
> > +
> > +See the full list of clock IDs from:
> > +include/dt-bindings/clock/imx8qxp-clock.h
> > +
> > +Pinctrl bindings based on SCU Message Protocol
> > +------------------------------------------------------------
> > +
> > +This binding uses the i.MX common pinctrl binding[3].
> > +
> > +Required properties:
> > +- compatible:		Should be "fsl,imx8qxp-iomuxc".
> > +
> > +Required properties for Pinctrl sub nodes:
> > +- fsl,pins:		Each entry consists of 3 integers which represents
> > +			the mux and config setting for one pin. The first 2
> > +			integers <pin_id mux_mode> are specified using a
> > +			PIN_FUNC_ID macro, which can be found in
> > +			<dt-bindings/pinctrl/pads-imx8qxp.h>.
> > +			The last integer CONFIG is the pad setting value like
> > +			pull-up on this pin.
> > +
> > +			Please refer to i.MX8QXP Reference Manual for
> detailed
> > +			CONFIG settings.
> > +
> > +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> > +[2] Documentation/devicetree/bindings/power/power_domain.txt
> > +[3] Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
> > +
> > +Example (imx8qxp):
> > +-------------
> > +lsio_mu1: mailbox at 5d1c0000 {
> > +	...
> > +	#mbox-cells = <2>;
> > +};
> > +
> > +firmware {
> > +	scu {
> > +		compatible = "fsl,imx-scu";
> > +		mbox-names = "tx0", "tx1", "tx2", "tx3",
> > +			     "rx0", "rx1", "rx2", "rx3";
> > +		mboxes = <&lsio_mu1 0 0
> > +			  &lsio_mu1 0 1
> > +			  &lsio_mu1 0 2
> > +			  &lsio_mu1 0 3
> > +			  &lsio_mu1 1 0
> > +			  &lsio_mu1 1 1
> > +			  &lsio_mu1 1 2
> > +			  &lsio_mu1 1 3>;
> > +
> > +		clk: clk {
> > +			compatible = "fsl,imx8qxp-clk";
> > +			#clock-cells = <1>;
> > +		};
> > +
> > +		iomuxc {
> > +			compatible = "fsl,imx8qxp-iomuxc";
> > +
> > +			pinctrl_lpuart0: lpuart0grp {
> > +				fsl,pins = <
> > +					SC_P_UART0_RX_ADMA_UART0_RX
> 	0x06000020
> > +					SC_P_UART0_TX_ADMA_UART0_TX
> 	0x06000020
> > +				>;
> > +			};
> > +			...
> > +		};
> > +
> > +		imx8qx-pm {
> > +			compatible = "fsl,scu-pd";
> > +			#address-cells = <1>;
> > +			#size-cells = <0>;
> > +
> > +			pd_dma: dma-power-domain {
> > +				#power-domain-cells = <0>;
> > +
> > +				pd_dma_lpuart0: dma-lpuart0 at 57 {
> > +					reg = <SC_R_UART_0>;
> > +					#power-domain-cells = <0>;
> > +					power-domains = <&pd_dma>;
> > +				};
> > +				...
> > +			};
> > +			...
> > +		};
> > +	};
> > +};
> > +
> > +serial at 5a060000 {
> > +	...
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_lpuart0>;
> > +	clocks = <&clk IMX8QXP_UART0_CLK>,
> > +		 <&clk IMX8QXP_UART0_IPG_CLK>;
> > +	clock-names = "per", "ipg";
> > +	power-domains = <&pd_dma_lpuart0>;
> > +};
> > --
> > 2.7.4
> >

RE: [PATCH V5 1/5] dt-bindings: arm: fsl: add scu binding doc

[A.s. Dong]

Hi Rob,

> -----Original Message-----
> From: Rob Herring <robh@kernel.org>
> Sent: Tuesday, August 21, 2018 2:12 AM
> To: A.s. Dong <aisheng.dong@nxp.com>
> Cc: linux-arm-kernel@lists.infradead.org; dongas86@gmail.com;
> kernel@pengutronix.de; shawnguo@kernel.org; Fabio Estevam
> <fabio.estevam@nxp.com>; dl-linux-imx <linux-imx@nxp.com>; Mark
> Rutland <mark.rutland@arm.com>; Jassi Brar <jassisinghbrar@gmail.com>;
> Linus Walleij <linus.walleij@linaro.org>; Stephen Boyd <sboyd@kernel.org>=
;
> Rafael J. Wysocki <rjw@rjwysocki.net>; Ulf Hansson
> <ulf.hansson@linaro.org>; devicetree@vger.kernel.org; linux-
> clk@vger.kernel.org; linux-gpio@vger.kernel.org; linux-pm@vger.kernel.org
> Subject: Re: [PATCH V5 1/5] dt-bindings: arm: fsl: add scu binding doc
>=20
> On Tue, Aug 21, 2018 at 12:08:21AM +0800, Dong Aisheng wrote:
> > The System Controller Firmware (SCFW) is a low-level system function
> > which runs on a dedicated Cortex-M core to provide power, clock, and
> > resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
> > (QM, QP), and i.MX8QX (QXP, DX).
> >
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: Sascha Hauer <kernel@pengutronix.de>
> > Cc: Jassi Brar <jassisinghbrar@gmail.com>
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Cc: Stephen Boyd <sboyd@kernel.org>
> > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> > Cc: Ulf Hansson <ulf.hansson@linaro.org>
> > Cc: Shawn Guo <shawnguo@kernel.org>
> > Cc: Fabio Estevam <fabio.estevam@nxp.com>
> > Cc: devicetree@vger.kernel.org
> > Cc: linux-clk@vger.kernel.org
> > Cc: linux-gpio@vger.kernel.org
> > Cc: linux-pm@vger.kernel.org
> > Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> > ---
> > v4->v5:
> >  * scu node should be under firmware node
> >  * add pd/clk/pinctrl binding as well according to Rob's suggestion
> >  * switch to new generic MU binding
> >    Use 8 separate mu channels in one MU instance for SCU communication
> > v3->v4:
> >  * fully change to mailbox binding
> >  * add child node description
> > v2->v3:
> >  * update a bit to mailbox binding
> > v1->v2:
> >  * remove status
> >  * changed to mu1
> > ---
> >  .../devicetree/bindings/arm/freescale/fsl,scu.txt  | 179
> > +++++++++++++++++++++
> >  1 file changed, 179 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > new file mode 100644
> > index 0000000..2cd7e4a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > @@ -0,0 +1,179 @@
> > +NXP i.MX System Controller Firmware (SCFW)
> > +--------------------------------------------------------------------
>=20
> Think you wanted a newline here              ^?

Yes, of course.
It seems to be introduced by mistake.
Thanks for reminder.

>=20
> > +
> > +The System Controller Firmware (SCFW) is a low-level system function
> > +which runs on a dedicated Cortex-M core to provide power, clock, and
> > +resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
> > +(QM, QP), and i.MX8QX (QXP, DX).
> > +
> > +The AP communicates with the SC using a multi-ported MU module found
> > +in the LSIO subsystem. The current definition of this MU module
> > +provides
> > +5 remote AP connections to the SC to support up to 5 execution
> > +environments (TZ, HV, standard Linux, etc.). The SC side of this MU
> > +module interfaces with the LSIO DSC IP bus. The SC firmware will
> > +communicate with this MU using the MSI bus.
>=20
> How are 5 users supported with only 4 channels defined below?

There're 5 MU instances designed to be specifically communicate with
SCU Firmware on MX8 hardware.

With the new generic mu binding [1], each MU instance is abstracted
Into 16 virtual MU channels. (4 Tx, 4 Rx, 4 Tx doorbell, 4 Rx doorbell).
(MU has 4 pair of Tx/Rx data register which can be used to send/receive
multi words. With new binding, each data register is abstracted into one
MU channel, totally 8 channels for data transfer).

SCU protocol is already designed to uses all data registers to send/receive
multi words according to MU hardware reference manual. So it must
use all channels in one MU instances with new binding.

On MX8, it can be one of LSIO MU0~M4.
=20
[1] https://patchwork.kernel.org/patch/10554565/

>=20
> > +
> > +System Controller Device Node:
> >
> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
> =3D=3D=3D
> > +
> > +The scu node with the following properties shall be under the /firmwar=
e/
> node.
> > +
> > +Required properties:
> > +-------------------
> > +- compatible:	should be "fsl,imx-scu".
> > +- mbox-names:	should include "tx0", "tx1", "tx2", "tx3",
> > +			       "rx0", "rx1", "rx2", "rx3".
> > +- mboxes:	List of phandle of 4 MU channels for tx and 4 MU channels
> > +		for rx. All 8 MU channels must be in the same MU instance.
> > +		Cross instances are not allowed. The MU instance can only
> > +		be one of LSIO MU0~M4 for imx8qxp and imx8qm. Users
> need
> > +		to make sure use the one which is not conflict with other
> > +		execution environments. e.g. ATF.
>=20
> How is one supposed to know what channels are in use already?
>=20

Currently it's simply predefined.
E.g. ATF uses MU0 and u-Boot & Kernel uses MU1.

> IMO, ATF should remove the channel it uses before passing the DT to the
> next stage.=20

Sounds like a good idea.
To be more specific, you mean simply marking the MU node status used in ATF
to be "disabled" before passing to the next stage, am I understand correct?

> That doesn't help if later stages get a different DT though.

Doesn't help? Sorry a bit confusing...

>=20
> > +		Note:
> > +		Channel 0 must be "tx0" or "rx0".
> > +		Channel 1 must be "tx1" or "rx1".
> > +		Channel 2 must be "tx2" or "rx2".
> > +		Channel 3 must be "tx3" or "rx3".
> > +		e.g.
> > +		mboxes =3D <&lsio_mu1 0 0
> > +			  &lsio_mu1 0 1
> > +			  &lsio_mu1 0 2
> > +			  &lsio_mu1 0 3
> > +			  &lsio_mu1 1 0
> > +			  &lsio_mu1 1 1
> > +			  &lsio_mu1 1 2
> > +			  &lsio_mu1 1 3>;
> > +		See Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> > +		for detailed mailbox binding.
> > +
> > +i.MX SCU Client Device Node:
> >
> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
> =3D=3D=3D
> > +
> > +Client nodes are maintained as children of the relevant IMX-SCU device
> node.
> > +
> > +Power domain bindings based on SCU Message Protocol
> > +------------------------------------------------------------
> > +
> > +This binding for the SCU power domain providers uses the generic
> > +power domain binding[2].
> > +
> > +Required properties:
> > +- compatible:		Should be "fsl,scu-pd".
> > +- #address-cells:	Should be 1.
> > +- #size-cells:		Should be 0.
> > +
> > +Required properties for power domain sub nodes:
> > +- #power-domain-cells:	Must be 0.
> > +
> > +Optional Properties:
> > +- reg:			Resource ID of this power domain.
> > +			No exist means uncontrollable by user.
> > +			See detailed Resource ID list from:
> > +			include/dt-bindings/power/imx-rsrc.h
> > +- power-domains:	phandle pointing to the parent power domain.
> > +
> > +Clock bindings based on SCU Message Protocol
> > +------------------------------------------------------------
> > +
> > +This binding uses the common clock binding[1].
> > +
> > +Required properties:
> > +- compatible:		Should be "fsl,imx8qxp-clock".
> > +- #clock-cells:		Should be 1. Contains the Clock ID value.
>=20
> There was a recent patch adding input clocks to other i.MX CCM bindings.
> Is that needed here?
>=20

Will double check it, thanks for reminder.

Regards
Dong Aisheng

> > +
> > +The clock consumer should specify the desired clock by having the
> > +clock ID in its "clocks" phandle cell.
> > +
> > +See the full list of clock IDs from:
> > +include/dt-bindings/clock/imx8qxp-clock.h
> > +
> > +Pinctrl bindings based on SCU Message Protocol
> > +------------------------------------------------------------
> > +
> > +This binding uses the i.MX common pinctrl binding[3].
> > +
> > +Required properties:
> > +- compatible:		Should be "fsl,imx8qxp-iomuxc".
> > +
> > +Required properties for Pinctrl sub nodes:
> > +- fsl,pins:		Each entry consists of 3 integers which represents
> > +			the mux and config setting for one pin. The first 2
> > +			integers <pin_id mux_mode> are specified using a
> > +			PIN_FUNC_ID macro, which can be found in
> > +			<dt-bindings/pinctrl/pads-imx8qxp.h>.
> > +			The last integer CONFIG is the pad setting value like
> > +			pull-up on this pin.
> > +
> > +			Please refer to i.MX8QXP Reference Manual for
> detailed
> > +			CONFIG settings.
> > +
> > +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> > +[2] Documentation/devicetree/bindings/power/power_domain.txt
> > +[3] Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
> > +
> > +Example (imx8qxp):
> > +-------------
> > +lsio_mu1: mailbox@5d1c0000 {
> > +	...
> > +	#mbox-cells =3D <2>;
> > +};
> > +
> > +firmware {
> > +	scu {
> > +		compatible =3D "fsl,imx-scu";
> > +		mbox-names =3D "tx0", "tx1", "tx2", "tx3",
> > +			     "rx0", "rx1", "rx2", "rx3";
> > +		mboxes =3D <&lsio_mu1 0 0
> > +			  &lsio_mu1 0 1
> > +			  &lsio_mu1 0 2
> > +			  &lsio_mu1 0 3
> > +			  &lsio_mu1 1 0
> > +			  &lsio_mu1 1 1
> > +			  &lsio_mu1 1 2
> > +			  &lsio_mu1 1 3>;
> > +
> > +		clk: clk {
> > +			compatible =3D "fsl,imx8qxp-clk";
> > +			#clock-cells =3D <1>;
> > +		};
> > +
> > +		iomuxc {
> > +			compatible =3D "fsl,imx8qxp-iomuxc";
> > +
> > +			pinctrl_lpuart0: lpuart0grp {
> > +				fsl,pins =3D <
> > +					SC_P_UART0_RX_ADMA_UART0_RX
> 	0x06000020
> > +					SC_P_UART0_TX_ADMA_UART0_TX
> 	0x06000020
> > +				>;
> > +			};
> > +			...
> > +		};
> > +
> > +		imx8qx-pm {
> > +			compatible =3D "fsl,scu-pd";
> > +			#address-cells =3D <1>;
> > +			#size-cells =3D <0>;
> > +
> > +			pd_dma: dma-power-domain {
> > +				#power-domain-cells =3D <0>;
> > +
> > +				pd_dma_lpuart0: dma-lpuart0@57 {
> > +					reg =3D <SC_R_UART_0>;
> > +					#power-domain-cells =3D <0>;
> > +					power-domains =3D <&pd_dma>;
> > +				};
> > +				...
> > +			};
> > +			...
> > +		};
> > +	};
> > +};
> > +
> > +serial@5a060000 {
> > +	...
> > +	pinctrl-names =3D "default";
> > +	pinctrl-0 =3D <&pinctrl_lpuart0>;
> > +	clocks =3D <&clk IMX8QXP_UART0_CLK>,
> > +		 <&clk IMX8QXP_UART0_IPG_CLK>;
> > +	clock-names =3D "per", "ipg";
> > +	power-domains =3D <&pd_dma_lpuart0>;
> > +};
> > --
> > 2.7.4
> >

RE: [PATCH V5 1/5] dt-bindings: arm: fsl: add scu binding doc

[A.s. Dong]

Hi Rob,

> > > +Clock bindings based on SCU Message Protocol
> > > +------------------------------------------------------------
> > > +
> > > +This binding uses the common clock binding[1].
> > > +
> > > +Required properties:
> > > +- compatible:		Should be "fsl,imx8qxp-clock".
> > > +- #clock-cells:		Should be 1. Contains the Clock ID value.
> >
> > There was a recent patch adding input clocks to other i.MX CCM bindings.
> > Is that needed here?
> >
> 
> Will double check it, thanks for reminder.

It should work for mx8 as well.

I will add them like below:
+- clocks:              List of clock specifiers, must contain an entry for
+                       each required entry in clock-names
+- clock-names:         Should include entries "xtal_32KHz", "xtal_24MHz"

Thanks for the suggestion.

Regards
Dong Aisheng

[PATCH V5 1/5] dt-bindings: arm: fsl: add scu binding doc

[A.s. Dong]

Hi Rob,

> > > +Clock bindings based on SCU Message Protocol
> > > +------------------------------------------------------------
> > > +
> > > +This binding uses the common clock binding[1].
> > > +
> > > +Required properties:
> > > +- compatible:		Should be "fsl,imx8qxp-clock".
> > > +- #clock-cells:		Should be 1. Contains the Clock ID value.
> >
> > There was a recent patch adding input clocks to other i.MX CCM bindings.
> > Is that needed here?
> >
> 
> Will double check it, thanks for reminder.

It should work for mx8 as well.

I will add them like below:
+- clocks:              List of clock specifiers, must contain an entry for
+                       each required entry in clock-names
+- clock-names:         Should include entries "xtal_32KHz", "xtal_24MHz"

Thanks for the suggestion.

Regards
Dong Aisheng

RE: [PATCH V5 1/5] dt-bindings: arm: fsl: add scu binding doc

[A.s. Dong]

Hi Rob,

> > > +Clock bindings based on SCU Message Protocol
> > > +------------------------------------------------------------
> > > +
> > > +This binding uses the common clock binding[1].
> > > +
> > > +Required properties:
> > > +- compatible:		Should be "fsl,imx8qxp-clock".
> > > +- #clock-cells:		Should be 1. Contains the Clock ID value.
> >
> > There was a recent patch adding input clocks to other i.MX CCM bindings=
.
> > Is that needed here?
> >
>=20
> Will double check it, thanks for reminder.

It should work for mx8 as well.

I will add them like below:
+- clocks:              List of clock specifiers, must contain an entry for
+                       each required entry in clock-names
+- clock-names:         Should include entries "xtal_32KHz", "xtal_24MHz"

Thanks for the suggestion.

Regards
Dong Aisheng

Re: [PATCH V5 1/5] dt-bindings: arm: fsl: add scu binding doc

[Jassi Brar]

On Tue, Aug 21, 2018 at 8:30 AM A.s. Dong <aisheng.dong@nxp.com> wrote:
>
> > > +
> > > +The System Controller Firmware (SCFW) is a low-level system function
> > > +which runs on a dedicated Cortex-M core to provide power, clock, and
> > > +resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
> > > +(QM, QP), and i.MX8QX (QXP, DX).
> > > +
> > > +The AP communicates with the SC using a multi-ported MU module found
> > > +in the LSIO subsystem. The current definition of this MU module
> > > +provides
> > > +5 remote AP connections to the SC to support up to 5 execution
> > > +environments (TZ, HV, standard Linux, etc.). The SC side of this MU
> > > +module interfaces with the LSIO DSC IP bus. The SC firmware will
> > > +communicate with this MU using the MSI bus.
> >
> > How are 5 users supported with only 4 channels defined below?
>
> There're 5 MU instances designed to be specifically communicate with
> SCU Firmware on MX8 hardware.
>
This is correct.

> With the new generic mu binding [1], each MU instance is abstracted
> Into 16 virtual MU channels. (4 Tx, 4 Rx, 4 Tx doorbell, 4 Rx doorbell).
> (MU has 4 pair of Tx/Rx data register which can be used to send/receive
> multi words. With new binding, each data register is abstracted into one
> MU channel, totally 8 channels for data transfer).
>
> SCU protocol is already designed to uses all data registers to send/receive
> multi words according to MU hardware reference manual. So it must
> use all channels in one MU instances with new binding.
>
FYI, this is incorrect.
The 16 channels are physical and not virtual. In fact, all this is to
avoid virtual channels.
The physical resources required by new bindings are exactly the same
as by old bindings. Now you use 8 physical channels instead of 1
virtual.

[PATCH V5 1/5] dt-bindings: arm: fsl: add scu binding doc

[Jassi Brar]

On Tue, Aug 21, 2018 at 8:30 AM A.s. Dong <aisheng.dong@nxp.com> wrote:
>
> > > +
> > > +The System Controller Firmware (SCFW) is a low-level system function
> > > +which runs on a dedicated Cortex-M core to provide power, clock, and
> > > +resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
> > > +(QM, QP), and i.MX8QX (QXP, DX).
> > > +
> > > +The AP communicates with the SC using a multi-ported MU module found
> > > +in the LSIO subsystem. The current definition of this MU module
> > > +provides
> > > +5 remote AP connections to the SC to support up to 5 execution
> > > +environments (TZ, HV, standard Linux, etc.). The SC side of this MU
> > > +module interfaces with the LSIO DSC IP bus. The SC firmware will
> > > +communicate with this MU using the MSI bus.
> >
> > How are 5 users supported with only 4 channels defined below?
>
> There're 5 MU instances designed to be specifically communicate with
> SCU Firmware on MX8 hardware.
>
This is correct.

> With the new generic mu binding [1], each MU instance is abstracted
> Into 16 virtual MU channels. (4 Tx, 4 Rx, 4 Tx doorbell, 4 Rx doorbell).
> (MU has 4 pair of Tx/Rx data register which can be used to send/receive
> multi words. With new binding, each data register is abstracted into one
> MU channel, totally 8 channels for data transfer).
>
> SCU protocol is already designed to uses all data registers to send/receive
> multi words according to MU hardware reference manual. So it must
> use all channels in one MU instances with new binding.
>
FYI, this is incorrect.
The 16 channels are physical and not virtual. In fact, all this is to
avoid virtual channels.
The physical resources required by new bindings are exactly the same
as by old bindings. Now you use 8 physical channels instead of 1
virtual.

Re: [PATCH V5 1/5] dt-bindings: arm: fsl: add scu binding doc

[Jassi Brar]

On Tue, Aug 21, 2018 at 8:30 AM A.s. Dong <aisheng.dong@nxp.com> wrote:
>
> > > +
> > > +The System Controller Firmware (SCFW) is a low-level system function
> > > +which runs on a dedicated Cortex-M core to provide power, clock, and
> > > +resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
> > > +(QM, QP), and i.MX8QX (QXP, DX).
> > > +
> > > +The AP communicates with the SC using a multi-ported MU module found
> > > +in the LSIO subsystem. The current definition of this MU module
> > > +provides
> > > +5 remote AP connections to the SC to support up to 5 execution
> > > +environments (TZ, HV, standard Linux, etc.). The SC side of this MU
> > > +module interfaces with the LSIO DSC IP bus. The SC firmware will
> > > +communicate with this MU using the MSI bus.
> >
> > How are 5 users supported with only 4 channels defined below?
>
> There're 5 MU instances designed to be specifically communicate with
> SCU Firmware on MX8 hardware.
>
This is correct.

> With the new generic mu binding [1], each MU instance is abstracted
> Into 16 virtual MU channels. (4 Tx, 4 Rx, 4 Tx doorbell, 4 Rx doorbell).
> (MU has 4 pair of Tx/Rx data register which can be used to send/receive
> multi words. With new binding, each data register is abstracted into one
> MU channel, totally 8 channels for data transfer).
>
> SCU protocol is already designed to uses all data registers to send/receive
> multi words according to MU hardware reference manual. So it must
> use all channels in one MU instances with new binding.
>
FYI, this is incorrect.
The 16 channels are physical and not virtual. In fact, all this is to
avoid virtual channels.
The physical resources required by new bindings are exactly the same
as by old bindings. Now you use 8 physical channels instead of 1
virtual.

RE: [PATCH V5 1/5] dt-bindings: arm: fsl: add scu binding doc

[A.s. Dong]

> -----Original Message-----
> From: Jassi Brar [mailto:jassisinghbrar@gmail.com]
> On Tue, Aug 21, 2018 at 8:30 AM A.s. Dong <aisheng.dong@nxp.com> wrote:
> >
> > > > +
> > > > +The System Controller Firmware (SCFW) is a low-level system
> > > > +function which runs on a dedicated Cortex-M core to provide
> > > > +power, clock, and resource management. It exists on some i.MX8
> > > > +processors. e.g. i.MX8QM (QM, QP), and i.MX8QX (QXP, DX).
> > > > +
> > > > +The AP communicates with the SC using a multi-ported MU module
> > > > +found in the LSIO subsystem. The current definition of this MU
> > > > +module provides
> > > > +5 remote AP connections to the SC to support up to 5 execution
> > > > +environments (TZ, HV, standard Linux, etc.). The SC side of this
> > > > +MU module interfaces with the LSIO DSC IP bus. The SC firmware
> > > > +will communicate with this MU using the MSI bus.
> > >
> > > How are 5 users supported with only 4 channels defined below?
> >
> > There're 5 MU instances designed to be specifically communicate with
> > SCU Firmware on MX8 hardware.
> >
> This is correct.
> 
> > With the new generic mu binding [1], each MU instance is abstracted
> > Into 16 virtual MU channels. (4 Tx, 4 Rx, 4 Tx doorbell, 4 Rx doorbell).
> > (MU has 4 pair of Tx/Rx data register which can be used to
> > send/receive multi words. With new binding, each data register is
> > abstracted into one MU channel, totally 8 channels for data transfer).
> >
> > SCU protocol is already designed to uses all data registers to
> > send/receive multi words according to MU hardware reference manual. So
> > it must use all channels in one MU instances with new binding.
> >
> FYI, this is incorrect.
> The 16 channels are physical and not virtual. In fact, all this is to avoid virtual
> channels.
> The physical resources required by new bindings are exactly the same as by old
> bindings. Now you use 8 physical channels instead of 1 virtual.

Okay, got it.
I'm fine to refer to them all as physical channels.
Thanks

Regards
Dong Aisheng

[PATCH V5 1/5] dt-bindings: arm: fsl: add scu binding doc

[A.s. Dong]

> -----Original Message-----
> From: Jassi Brar [mailto:jassisinghbrar at gmail.com]
> On Tue, Aug 21, 2018 at 8:30 AM A.s. Dong <aisheng.dong@nxp.com> wrote:
> >
> > > > +
> > > > +The System Controller Firmware (SCFW) is a low-level system
> > > > +function which runs on a dedicated Cortex-M core to provide
> > > > +power, clock, and resource management. It exists on some i.MX8
> > > > +processors. e.g. i.MX8QM (QM, QP), and i.MX8QX (QXP, DX).
> > > > +
> > > > +The AP communicates with the SC using a multi-ported MU module
> > > > +found in the LSIO subsystem. The current definition of this MU
> > > > +module provides
> > > > +5 remote AP connections to the SC to support up to 5 execution
> > > > +environments (TZ, HV, standard Linux, etc.). The SC side of this
> > > > +MU module interfaces with the LSIO DSC IP bus. The SC firmware
> > > > +will communicate with this MU using the MSI bus.
> > >
> > > How are 5 users supported with only 4 channels defined below?
> >
> > There're 5 MU instances designed to be specifically communicate with
> > SCU Firmware on MX8 hardware.
> >
> This is correct.
> 
> > With the new generic mu binding [1], each MU instance is abstracted
> > Into 16 virtual MU channels. (4 Tx, 4 Rx, 4 Tx doorbell, 4 Rx doorbell).
> > (MU has 4 pair of Tx/Rx data register which can be used to
> > send/receive multi words. With new binding, each data register is
> > abstracted into one MU channel, totally 8 channels for data transfer).
> >
> > SCU protocol is already designed to uses all data registers to
> > send/receive multi words according to MU hardware reference manual. So
> > it must use all channels in one MU instances with new binding.
> >
> FYI, this is incorrect.
> The 16 channels are physical and not virtual. In fact, all this is to avoid virtual
> channels.
> The physical resources required by new bindings are exactly the same as by old
> bindings. Now you use 8 physical channels instead of 1 virtual.

Okay, got it.
I'm fine to refer to them all as physical channels.
Thanks

Regards
Dong Aisheng

RE: [PATCH V5 1/5] dt-bindings: arm: fsl: add scu binding doc

[A.s. Dong]

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYXNzaSBCcmFyIFttYWlsdG86
amFzc2lzaW5naGJyYXJAZ21haWwuY29tXQ0KPiBPbiBUdWUsIEF1ZyAyMSwgMjAxOCBhdCA4OjMw
IEFNIEEucy4gRG9uZyA8YWlzaGVuZy5kb25nQG54cC5jb20+IHdyb3RlOg0KPiA+DQo+ID4gPiA+
ICsNCj4gPiA+ID4gK1RoZSBTeXN0ZW0gQ29udHJvbGxlciBGaXJtd2FyZSAoU0NGVykgaXMgYSBs
b3ctbGV2ZWwgc3lzdGVtDQo+ID4gPiA+ICtmdW5jdGlvbiB3aGljaCBydW5zIG9uIGEgZGVkaWNh
dGVkIENvcnRleC1NIGNvcmUgdG8gcHJvdmlkZQ0KPiA+ID4gPiArcG93ZXIsIGNsb2NrLCBhbmQg
cmVzb3VyY2UgbWFuYWdlbWVudC4gSXQgZXhpc3RzIG9uIHNvbWUgaS5NWDgNCj4gPiA+ID4gK3By
b2Nlc3NvcnMuIGUuZy4gaS5NWDhRTSAoUU0sIFFQKSwgYW5kIGkuTVg4UVggKFFYUCwgRFgpLg0K
PiA+ID4gPiArDQo+ID4gPiA+ICtUaGUgQVAgY29tbXVuaWNhdGVzIHdpdGggdGhlIFNDIHVzaW5n
IGEgbXVsdGktcG9ydGVkIE1VIG1vZHVsZQ0KPiA+ID4gPiArZm91bmQgaW4gdGhlIExTSU8gc3Vi
c3lzdGVtLiBUaGUgY3VycmVudCBkZWZpbml0aW9uIG9mIHRoaXMgTVUNCj4gPiA+ID4gK21vZHVs
ZSBwcm92aWRlcw0KPiA+ID4gPiArNSByZW1vdGUgQVAgY29ubmVjdGlvbnMgdG8gdGhlIFNDIHRv
IHN1cHBvcnQgdXAgdG8gNSBleGVjdXRpb24NCj4gPiA+ID4gK2Vudmlyb25tZW50cyAoVFosIEhW
LCBzdGFuZGFyZCBMaW51eCwgZXRjLikuIFRoZSBTQyBzaWRlIG9mIHRoaXMNCj4gPiA+ID4gK01V
IG1vZHVsZSBpbnRlcmZhY2VzIHdpdGggdGhlIExTSU8gRFNDIElQIGJ1cy4gVGhlIFNDIGZpcm13
YXJlDQo+ID4gPiA+ICt3aWxsIGNvbW11bmljYXRlIHdpdGggdGhpcyBNVSB1c2luZyB0aGUgTVNJ
IGJ1cy4NCj4gPiA+DQo+ID4gPiBIb3cgYXJlIDUgdXNlcnMgc3VwcG9ydGVkIHdpdGggb25seSA0
IGNoYW5uZWxzIGRlZmluZWQgYmVsb3c/DQo+ID4NCj4gPiBUaGVyZSdyZSA1IE1VIGluc3RhbmNl
cyBkZXNpZ25lZCB0byBiZSBzcGVjaWZpY2FsbHkgY29tbXVuaWNhdGUgd2l0aA0KPiA+IFNDVSBG
aXJtd2FyZSBvbiBNWDggaGFyZHdhcmUuDQo+ID4NCj4gVGhpcyBpcyBjb3JyZWN0Lg0KPiANCj4g
PiBXaXRoIHRoZSBuZXcgZ2VuZXJpYyBtdSBiaW5kaW5nIFsxXSwgZWFjaCBNVSBpbnN0YW5jZSBp
cyBhYnN0cmFjdGVkDQo+ID4gSW50byAxNiB2aXJ0dWFsIE1VIGNoYW5uZWxzLiAoNCBUeCwgNCBS
eCwgNCBUeCBkb29yYmVsbCwgNCBSeCBkb29yYmVsbCkuDQo+ID4gKE1VIGhhcyA0IHBhaXIgb2Yg
VHgvUnggZGF0YSByZWdpc3RlciB3aGljaCBjYW4gYmUgdXNlZCB0bw0KPiA+IHNlbmQvcmVjZWl2
ZSBtdWx0aSB3b3Jkcy4gV2l0aCBuZXcgYmluZGluZywgZWFjaCBkYXRhIHJlZ2lzdGVyIGlzDQo+
ID4gYWJzdHJhY3RlZCBpbnRvIG9uZSBNVSBjaGFubmVsLCB0b3RhbGx5IDggY2hhbm5lbHMgZm9y
IGRhdGEgdHJhbnNmZXIpLg0KPiA+DQo+ID4gU0NVIHByb3RvY29sIGlzIGFscmVhZHkgZGVzaWdu
ZWQgdG8gdXNlcyBhbGwgZGF0YSByZWdpc3RlcnMgdG8NCj4gPiBzZW5kL3JlY2VpdmUgbXVsdGkg
d29yZHMgYWNjb3JkaW5nIHRvIE1VIGhhcmR3YXJlIHJlZmVyZW5jZSBtYW51YWwuIFNvDQo+ID4g
aXQgbXVzdCB1c2UgYWxsIGNoYW5uZWxzIGluIG9uZSBNVSBpbnN0YW5jZXMgd2l0aCBuZXcgYmlu
ZGluZy4NCj4gPg0KPiBGWUksIHRoaXMgaXMgaW5jb3JyZWN0Lg0KPiBUaGUgMTYgY2hhbm5lbHMg
YXJlIHBoeXNpY2FsIGFuZCBub3QgdmlydHVhbC4gSW4gZmFjdCwgYWxsIHRoaXMgaXMgdG8gYXZv
aWQgdmlydHVhbA0KPiBjaGFubmVscy4NCj4gVGhlIHBoeXNpY2FsIHJlc291cmNlcyByZXF1aXJl
ZCBieSBuZXcgYmluZGluZ3MgYXJlIGV4YWN0bHkgdGhlIHNhbWUgYXMgYnkgb2xkDQo+IGJpbmRp
bmdzLiBOb3cgeW91IHVzZSA4IHBoeXNpY2FsIGNoYW5uZWxzIGluc3RlYWQgb2YgMSB2aXJ0dWFs
Lg0KDQpPa2F5LCBnb3QgaXQuDQpJJ20gZmluZSB0byByZWZlciB0byB0aGVtIGFsbCBhcyBwaHlz
aWNhbCBjaGFubmVscy4NClRoYW5rcw0KDQpSZWdhcmRzDQpEb25nIEFpc2hlbmcNCg==

[PATCH V5 2/5] soc: imx: add SC firmware IPC and APIs

[Dong Aisheng]

The System Controller Firmware (SCFW) is a low-level system function
which runs on a dedicated Cortex-M core to provide power, clock, and
resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
(QM, QP), and i.MX8QX (QXP, DX).

This patch adds the SC firmware service APIs used by the system.
It mainly consists of two parts:
1) Implementation of the IPC functions using MUs (client side).
2) SCU firmware services APIs implemented based on RPC calls

Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Jassi Brar <jassisinghbrar@gmail.com>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
---
v4->v5:
 * switch to new generic MU binding.
   Use 8 separate mu channels in one MU instance for SCU communication
 * create struct sc_rpc_msg to separate the msg header and service,
   accordingly the old sc_rpc_msg_s with raw data union is removed.
   This can gain better readability.
 * remove defines like RPC_XXX(MSG)
 * remove unused types
 * headfiles cleanup
 * NOTE:
   With the new approach that uses 8 separate irq driven changes, i still
   did not find a clean way to better support receiving msg over 4 words.
   So the current driver does not support it.
   As in current SCU protocol, there's only a minor of commands need
   receiving msg over 4 words which is still not used by Linux, so it does
   not affect the normal function.
 * Know issue:
   The performance drops a lot after using 8 separate interrupt driven MUs
   to send/receive msgs.
   e.g. Sending a scu message with tx size 2 words and rx size 2 words:
   Former (polling) : < 10us to handle a SCU msg
   Now (irq) : 20~30 us to handle a SCU msg (Caused by interrupt latency)
v3->v4:
 * change to use mailbox
 * separate the IPC part and RPC API for easy review
 * headfiles cleanup
v2->v3:
 * add the ipc read/write error check
v1->v2:
 * change the type of sc_ipc_t from uint32_t to unsigned long.
   This can make it be capable of storing 64 bit pointer in ARMv8 system.
 * Update to use the new MU library implemenation (handle iomem privately)
 * remove unused delcarations e.g. sc_rpc_dispatch and sc_rpc_xlate.
 * remove unneeded pad ctl functions
---
 drivers/soc/imx/Kconfig       |   4 +
 drivers/soc/imx/Makefile      |   1 +
 drivers/soc/imx/sc/Makefile   |   2 +
 drivers/soc/imx/sc/main/ipc.c | 258 +++++++++++++++++
 drivers/soc/imx/sc/main/rpc.h |  51 ++++
 include/soc/imx/sc/ipc.h      |  46 +++
 include/soc/imx/sc/sci.h      |  16 ++
 include/soc/imx/sc/types.h    | 636 ++++++++++++++++++++++++++++++++++++++++++
 8 files changed, 1014 insertions(+)
 create mode 100644 drivers/soc/imx/sc/Makefile
 create mode 100644 drivers/soc/imx/sc/main/ipc.c
 create mode 100644 drivers/soc/imx/sc/main/rpc.h
 create mode 100644 include/soc/imx/sc/ipc.h
 create mode 100644 include/soc/imx/sc/sci.h
 create mode 100644 include/soc/imx/sc/types.h

diff --git a/drivers/soc/imx/Kconfig b/drivers/soc/imx/Kconfig
index a5b86a2..e3084d8 100644
--- a/drivers/soc/imx/Kconfig
+++ b/drivers/soc/imx/Kconfig
@@ -7,4 +7,8 @@ config IMX7_PM_DOMAINS
 	select PM_GENERIC_DOMAINS
 	default y if SOC_IMX7D
 
+config HAVE_IMX_SCU
+	bool
+	depends on IMX_MBOX
+
 endmenu
diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile
index aab41a5c..be79f67 100644
--- a/drivers/soc/imx/Makefile
+++ b/drivers/soc/imx/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
 obj-$(CONFIG_IMX7_PM_DOMAINS) += gpcv2.o
+obj-$(CONFIG_HAVE_IMX_SCU) += sc/
diff --git a/drivers/soc/imx/sc/Makefile b/drivers/soc/imx/sc/Makefile
new file mode 100644
index 0000000..a3db142
--- /dev/null
+++ b/drivers/soc/imx/sc/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-y += main/ipc.o
diff --git a/drivers/soc/imx/sc/main/ipc.c b/drivers/soc/imx/sc/main/ipc.c
new file mode 100644
index 0000000..bc9e866
--- /dev/null
+++ b/drivers/soc/imx/sc/main/ipc.c
@@ -0,0 +1,258 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017~2018 NXP
+ *	Dong Aisheng <aisheng.dong@nxp.com>
+ *
+ * Implementation of the IPC functions using MUs (client side).
+ *
+ */
+
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/kernel.h>
+#include <linux/mailbox_client.h>
+#include <linux/mutex.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+
+#include "rpc.h"
+
+#define SCU_MU_CHAN_NUM		8
+#define MAX_RX_TIMEOUT		(msecs_to_jiffies(30))
+
+struct sc_chan {
+	struct sc_ipc *sc_ipc;
+
+	struct mbox_client cl;
+	struct mbox_chan *ch;
+	int idx;
+};
+
+struct sc_ipc {
+	/* SCU uses 4 Tx and 4 Rx channels */
+	struct sc_chan chans[SCU_MU_CHAN_NUM];
+	struct device *dev;
+	struct mutex lock;
+	struct completion done;
+
+	/* temporarily store the SCU msg */
+	u32 *msg;
+	u8 rx_size;
+	u8 count;
+};
+
+static sc_ipc_t scu_ipc_handle;
+
+/*
+ * Get the default handle used by SCU
+ */
+int sc_ipc_get_handle(sc_ipc_t *ipc)
+{
+	if (!scu_ipc_handle)
+		return -EPROBE_DEFER;
+
+	*ipc = scu_ipc_handle;
+	return 0;
+}
+EXPORT_SYMBOL(sc_ipc_get_handle);
+
+static void sc_rx_callback(struct mbox_client *c, void *msg)
+{
+	struct sc_chan *sc_chan = container_of(c, struct sc_chan, cl);
+	struct sc_ipc *sc_ipc = sc_chan->sc_ipc;
+	struct sc_rpc_msg *hdr;
+	u32 *data = msg;
+
+	if (sc_chan->idx == 0) {
+		hdr = msg;
+		sc_ipc->rx_size = hdr->size;
+		dev_dbg(sc_ipc->dev, "msg rx size %u\n", sc_ipc->rx_size);
+		if (sc_ipc->rx_size > 4)
+			dev_warn(sc_ipc->dev, "RPC does not support receiving over 4 words: %u\n",
+				 sc_ipc->rx_size);
+	}
+
+	sc_ipc->msg[sc_chan->idx] = *data;
+	sc_ipc->count++;
+
+	dev_dbg(sc_ipc->dev, "mu %u msg %u 0x%x\n", sc_chan->idx,
+		sc_ipc->count, *data);
+
+	if ((sc_ipc->rx_size != 0) && (sc_ipc->count == sc_ipc->rx_size))
+		complete(&sc_ipc->done);
+}
+
+int sc_ipc_write(struct sc_ipc *sc_ipc, void *msg)
+{
+	struct sc_rpc_msg *hdr = msg;
+	struct sc_chan *sc_chan;
+	u32 *data = msg;
+	int ret;
+	int i;
+
+	/* Check size */
+	if (hdr->size > SC_RPC_MAX_MSG)
+		return -EINVAL;
+
+	dev_dbg(sc_ipc->dev, "RPC SVC %u FUNC %u SIZE %u\n", hdr->svc,
+		hdr->func, hdr->size);
+
+	for (i = 0; i < hdr->size; i++) {
+		sc_chan = &sc_ipc->chans[i % 4];
+		ret = mbox_send_message(sc_chan->ch, &data[i]);
+		if (ret < 0)
+			return ret;
+	}
+
+	return 0;
+}
+
+/*
+ * RPC command/response
+ */
+int sc_call_rpc(sc_ipc_t ipc, void *msg, bool no_resp)
+{
+	struct sc_ipc *sc_ipc = (struct sc_ipc *)ipc;
+	int ret;
+
+	if (WARN_ON(!sc_ipc || !msg))
+		return -EINVAL;
+
+	mutex_lock(&sc_ipc->lock);
+	reinit_completion(&sc_ipc->done);
+
+	sc_ipc->msg = msg;
+	sc_ipc->count = 0;
+	ret = sc_ipc_write(sc_ipc, msg);
+	if (ret < 0) {
+		dev_err(sc_ipc->dev, "RPC send msg failed: %d\n", ret);
+		goto out;
+	}
+
+	if (!no_resp) {
+		if (!wait_for_completion_timeout(&sc_ipc->done,
+						 MAX_RX_TIMEOUT)) {
+			dev_err(sc_ipc->dev, "RPC send msg timeout\n");
+			return -ETIMEDOUT;
+		}
+		ret = 0;
+	}
+out:
+	mutex_unlock(&sc_ipc->lock);
+
+	dev_dbg(sc_ipc->dev, "RPC SVC done\n");
+
+	return ret;
+}
+
+/*
+ * Open an IPC channel
+ */
+int sc_ipc_open(sc_ipc_t *ipc, struct device *dev)
+{
+	struct sc_ipc *sc_ipc;
+	struct sc_chan *sc_chan;
+	struct mbox_client *cl;
+	char *chan_name;
+	int ret;
+	int i;
+
+	sc_ipc = devm_kzalloc(dev, sizeof(*sc_ipc), GFP_KERNEL);
+	if (!sc_ipc)
+		return -ENOMEM;
+
+	for (i = 0; i < SCU_MU_CHAN_NUM; i++) {
+		if (i < 4)
+			chan_name = kasprintf(GFP_KERNEL, "tx%d", i);
+		else
+			chan_name = kasprintf(GFP_KERNEL, "rx%d", i - 4);
+
+		if (!chan_name)
+			return -ENOMEM;
+
+		sc_chan = &sc_ipc->chans[i];
+		cl = &sc_chan->cl;
+		cl->dev = dev;
+		cl->tx_block = false;
+		cl->knows_txdone = true;
+		cl->rx_callback = sc_rx_callback;
+
+		sc_chan->sc_ipc = sc_ipc;
+		sc_chan->idx = i % 4;
+		sc_chan->ch = mbox_request_channel_byname(cl, chan_name);
+		if (IS_ERR(sc_chan->ch)) {
+			ret = PTR_ERR(sc_chan->ch);
+			if (ret != -EPROBE_DEFER)
+				dev_err(dev, "Failed to get mbox %d\n", ret);
+
+			return ret;
+		}
+
+		dev_dbg(dev, "mbox request chan %s\n", chan_name);
+		/* chan_name is not used anymore by framework */
+		kfree(chan_name);
+	}
+
+	sc_ipc->dev = dev;
+	mutex_init(&sc_ipc->lock);
+	init_completion(&sc_ipc->done);
+
+	*ipc = (sc_ipc_t)sc_ipc;
+
+	return 0;
+}
+EXPORT_SYMBOL(sc_ipc_open);
+
+/*
+ * Close an IPC channel
+ */
+void sc_ipc_close(sc_ipc_t ipc)
+{
+	struct sc_ipc *sc_ipc = (struct sc_ipc *)ipc;
+	struct sc_chan *sc_chan;
+	int i;
+
+	WARN_ON(!sc_ipc);
+
+	/* we do not free the default ipc handle */
+	if (ipc == scu_ipc_handle)
+		return;
+
+	for (i = 0; i < SCU_MU_CHAN_NUM; i++) {
+		sc_chan = &sc_ipc->chans[i];
+		mbox_free_channel(sc_chan->ch);
+	}
+
+	devm_kfree(sc_ipc->dev, sc_ipc);
+}
+EXPORT_SYMBOL(sc_ipc_close);
+
+static int imx_sc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	int ret;
+
+	ret = sc_ipc_open(&scu_ipc_handle, dev);
+	if (ret)
+		return ret;
+
+	pr_info("NXP i.MX SCU Initialized\n");
+
+	return devm_of_platform_populate(dev);
+}
+
+static const struct of_device_id imx_sc_match[] = {
+	{ .compatible = "fsl,imx-scu", },
+	{ /* Sentinel */ }
+};
+
+static struct platform_driver imx_sc_driver = {
+	.driver = {
+		.name = "imx-scu",
+		.of_match_table = imx_sc_match,
+	},
+	.probe = imx_sc_probe,
+};
+builtin_platform_driver(imx_sc_driver);
diff --git a/drivers/soc/imx/sc/main/rpc.h b/drivers/soc/imx/sc/main/rpc.h
new file mode 100644
index 0000000..93e66e5
--- /dev/null
+++ b/drivers/soc/imx/sc/main/rpc.h
@@ -0,0 +1,51 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017~2018 NXP
+ *
+ * Header file for the RPC implementation.
+ */
+
+#ifndef _SC_RPC_H
+#define _SC_RPC_H
+
+#include <soc/imx/sc/types.h>
+#include <soc/imx/sc/ipc.h>
+
+#define SC_RPC_VERSION		1
+
+#define SC_RPC_MAX_MSG		8
+
+enum sc_rpc_svc_e {
+	SC_RPC_SVC_UNKNOWN = 0,
+	SC_RPC_SVC_RETURN = 1,
+	SC_RPC_SVC_PM = 2,
+	SC_RPC_SVC_RM = 3,
+	SC_RPC_SVC_TIMER = 5,
+	SC_RPC_SVC_PAD = 6,
+	SC_RPC_SVC_MISC = 7,
+	SC_RPC_SVC_IRQ = 8,
+	SC_RPC_SVC_ABORT = 9
+};
+
+struct sc_rpc_msg {
+	uint8_t ver;
+	uint8_t size;
+	uint8_t svc;
+	uint8_t func;
+};
+
+/*
+ * This is an internal function to send an RPC message over an IPC
+ * channel. It is called by client-side SCFW API function shims.
+ *
+ * @param[in]     ipc         IPC handle
+ * @param[in,out] msg         handle to a message
+ * @param[in]     no_resp     response flag
+ *
+ * If no_resp is false then this function waits for a response
+ * and returns the result in msg.
+ */
+int sc_call_rpc(sc_ipc_t ipc, void *msg, bool no_resp);
+
+#endif /* _SC_RPC_H */
diff --git a/include/soc/imx/sc/ipc.h b/include/soc/imx/sc/ipc.h
new file mode 100644
index 0000000..cb26935
--- /dev/null
+++ b/include/soc/imx/sc/ipc.h
@@ -0,0 +1,46 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017~2018 NXP
+ *
+ * Header file for the IPC implementation.
+ */
+
+#ifndef _SC_IPC_H
+#define _SC_IPC_H
+
+#include <linux/device.h>
+#include <linux/types.h>
+
+/*
+ * This type is used to declare a handle for an IPC communication
+ * channel. Its meaning is specific to the IPC implementation.
+ */
+typedef unsigned long sc_ipc_t;
+
+/*
+ * This function opens an IPC channel.
+ *
+ * @param [out]	ipc	return pointer for ipc handle
+ * @param [in]	dev	device to open mu channel
+ *
+ * @return Returns an error code (0 = success, failed if < 0)
+ */
+int sc_ipc_open(sc_ipc_t *ipc, struct device *dev);
+
+/*
+ * This function closes an IPC channel.
+ *
+ * @param[in]	ipc	id of channel to close
+ */
+void sc_ipc_close(sc_ipc_t ipc);
+
+/*
+ * This function gets the default ipc handle used by SCU
+ *
+ * @param[out]	ipc	id of channel to close
+ *
+ * @return Returns an error code (0 = success, failed if < 0)
+ */
+int sc_ipc_get_handle(sc_ipc_t *ipc);
+#endif /* _SC_IPC_H */
diff --git a/include/soc/imx/sc/sci.h b/include/soc/imx/sc/sci.h
new file mode 100644
index 0000000..de3892a
--- /dev/null
+++ b/include/soc/imx/sc/sci.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017~2018 NXP
+ *
+ * Header file containing the public System Controller Interface (SCI)
+ * definitions.
+ */
+
+#ifndef _SC_SCI_H
+#define _SC_SCI_H
+
+#include <soc/imx/sc/ipc.h>
+#include <soc/imx/sc/types.h>
+
+#endif /* _SC_SCI_H */
diff --git a/include/soc/imx/sc/types.h b/include/soc/imx/sc/types.h
new file mode 100644
index 0000000..e56265e
--- /dev/null
+++ b/include/soc/imx/sc/types.h
@@ -0,0 +1,636 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017~2018 NXP
+ *
+ * Header file containing types used across multiple service APIs.
+ */
+
+#ifndef _SC_TYPES_H
+#define _SC_TYPES_H
+
+/*
+ * This type is used to indicate error response for most functions.
+ */
+typedef enum sc_err_e {
+	SC_ERR_NONE = 0,	/* Success */
+	SC_ERR_VERSION = 1,	/* Incompatible API version */
+	SC_ERR_CONFIG = 2,	/* Configuration error */
+	SC_ERR_PARM = 3,	/* Bad parameter */
+	SC_ERR_NOACCESS = 4,	/* Permission error (no access) */
+	SC_ERR_LOCKED = 5,	/* Permission error (locked) */
+	SC_ERR_UNAVAILABLE = 6,	/* Unavailable (out of resources) */
+	SC_ERR_NOTFOUND = 7,	/* Not found */
+	SC_ERR_NOPOWER = 8,	/* No power */
+	SC_ERR_IPC = 9,		/* Generic IPC error */
+	SC_ERR_BUSY = 10,	/* Resource is currently busy/active */
+	SC_ERR_FAIL = 11,	/* General I/O failure */
+	SC_ERR_LAST
+} sc_err_t;
+
+/*
+ * This type is used to indicate a resource. Resources include peripherals
+ * and bus masters (but not memory regions). Note items from list should
+ * never be changed or removed (only added to at the end of the list).
+ */
+typedef enum sc_rsrc_e {
+	SC_R_A53 = 0,
+	SC_R_A53_0 = 1,
+	SC_R_A53_1 = 2,
+	SC_R_A53_2 = 3,
+	SC_R_A53_3 = 4,
+	SC_R_A72 = 5,
+	SC_R_A72_0 = 6,
+	SC_R_A72_1 = 7,
+	SC_R_A72_2 = 8,
+	SC_R_A72_3 = 9,
+	SC_R_CCI = 10,
+	SC_R_DB = 11,
+	SC_R_DRC_0 = 12,
+	SC_R_DRC_1 = 13,
+	SC_R_GIC_SMMU = 14,
+	SC_R_IRQSTR_M4_0 = 15,
+	SC_R_IRQSTR_M4_1 = 16,
+	SC_R_SMMU = 17,
+	SC_R_GIC = 18,
+	SC_R_DC_0_BLIT0 = 19,
+	SC_R_DC_0_BLIT1 = 20,
+	SC_R_DC_0_BLIT2 = 21,
+	SC_R_DC_0_BLIT_OUT = 22,
+	SC_R_DC_0_CAPTURE0 = 23,
+	SC_R_DC_0_CAPTURE1 = 24,
+	SC_R_DC_0_WARP = 25,
+	SC_R_DC_0_INTEGRAL0 = 26,
+	SC_R_DC_0_INTEGRAL1 = 27,
+	SC_R_DC_0_VIDEO0 = 28,
+	SC_R_DC_0_VIDEO1 = 29,
+	SC_R_DC_0_FRAC0 = 30,
+	SC_R_DC_0_FRAC1 = 31,
+	SC_R_DC_0 = 32,
+	SC_R_GPU_2_PID0 = 33,
+	SC_R_DC_0_PLL_0 = 34,
+	SC_R_DC_0_PLL_1 = 35,
+	SC_R_DC_1_BLIT0 = 36,
+	SC_R_DC_1_BLIT1 = 37,
+	SC_R_DC_1_BLIT2 = 38,
+	SC_R_DC_1_BLIT_OUT = 39,
+	SC_R_DC_1_CAPTURE0 = 40,
+	SC_R_DC_1_CAPTURE1 = 41,
+	SC_R_DC_1_WARP = 42,
+	SC_R_DC_1_INTEGRAL0 = 43,
+	SC_R_DC_1_INTEGRAL1 = 44,
+	SC_R_DC_1_VIDEO0 = 45,
+	SC_R_DC_1_VIDEO1 = 46,
+	SC_R_DC_1_FRAC0 = 47,
+	SC_R_DC_1_FRAC1 = 48,
+	SC_R_DC_1 = 49,
+	SC_R_GPU_3_PID0 = 50,
+	SC_R_DC_1_PLL_0 = 51,
+	SC_R_DC_1_PLL_1 = 52,
+	SC_R_SPI_0 = 53,
+	SC_R_SPI_1 = 54,
+	SC_R_SPI_2 = 55,
+	SC_R_SPI_3 = 56,
+	SC_R_UART_0 = 57,
+	SC_R_UART_1 = 58,
+	SC_R_UART_2 = 59,
+	SC_R_UART_3 = 60,
+	SC_R_UART_4 = 61,
+	SC_R_EMVSIM_0 = 62,
+	SC_R_EMVSIM_1 = 63,
+	SC_R_DMA_0_CH0 = 64,
+	SC_R_DMA_0_CH1 = 65,
+	SC_R_DMA_0_CH2 = 66,
+	SC_R_DMA_0_CH3 = 67,
+	SC_R_DMA_0_CH4 = 68,
+	SC_R_DMA_0_CH5 = 69,
+	SC_R_DMA_0_CH6 = 70,
+	SC_R_DMA_0_CH7 = 71,
+	SC_R_DMA_0_CH8 = 72,
+	SC_R_DMA_0_CH9 = 73,
+	SC_R_DMA_0_CH10 = 74,
+	SC_R_DMA_0_CH11 = 75,
+	SC_R_DMA_0_CH12 = 76,
+	SC_R_DMA_0_CH13 = 77,
+	SC_R_DMA_0_CH14 = 78,
+	SC_R_DMA_0_CH15 = 79,
+	SC_R_DMA_0_CH16 = 80,
+	SC_R_DMA_0_CH17 = 81,
+	SC_R_DMA_0_CH18 = 82,
+	SC_R_DMA_0_CH19 = 83,
+	SC_R_DMA_0_CH20 = 84,
+	SC_R_DMA_0_CH21 = 85,
+	SC_R_DMA_0_CH22 = 86,
+	SC_R_DMA_0_CH23 = 87,
+	SC_R_DMA_0_CH24 = 88,
+	SC_R_DMA_0_CH25 = 89,
+	SC_R_DMA_0_CH26 = 90,
+	SC_R_DMA_0_CH27 = 91,
+	SC_R_DMA_0_CH28 = 92,
+	SC_R_DMA_0_CH29 = 93,
+	SC_R_DMA_0_CH30 = 94,
+	SC_R_DMA_0_CH31 = 95,
+	SC_R_I2C_0 = 96,
+	SC_R_I2C_1 = 97,
+	SC_R_I2C_2 = 98,
+	SC_R_I2C_3 = 99,
+	SC_R_I2C_4 = 100,
+	SC_R_ADC_0 = 101,
+	SC_R_ADC_1 = 102,
+	SC_R_FTM_0 = 103,
+	SC_R_FTM_1 = 104,
+	SC_R_CAN_0 = 105,
+	SC_R_CAN_1 = 106,
+	SC_R_CAN_2 = 107,
+	SC_R_DMA_1_CH0 = 108,
+	SC_R_DMA_1_CH1 = 109,
+	SC_R_DMA_1_CH2 = 110,
+	SC_R_DMA_1_CH3 = 111,
+	SC_R_DMA_1_CH4 = 112,
+	SC_R_DMA_1_CH5 = 113,
+	SC_R_DMA_1_CH6 = 114,
+	SC_R_DMA_1_CH7 = 115,
+	SC_R_DMA_1_CH8 = 116,
+	SC_R_DMA_1_CH9 = 117,
+	SC_R_DMA_1_CH10 = 118,
+	SC_R_DMA_1_CH11 = 119,
+	SC_R_DMA_1_CH12 = 120,
+	SC_R_DMA_1_CH13 = 121,
+	SC_R_DMA_1_CH14 = 122,
+	SC_R_DMA_1_CH15 = 123,
+	SC_R_DMA_1_CH16 = 124,
+	SC_R_DMA_1_CH17 = 125,
+	SC_R_DMA_1_CH18 = 126,
+	SC_R_DMA_1_CH19 = 127,
+	SC_R_DMA_1_CH20 = 128,
+	SC_R_DMA_1_CH21 = 129,
+	SC_R_DMA_1_CH22 = 130,
+	SC_R_DMA_1_CH23 = 131,
+	SC_R_DMA_1_CH24 = 132,
+	SC_R_DMA_1_CH25 = 133,
+	SC_R_DMA_1_CH26 = 134,
+	SC_R_DMA_1_CH27 = 135,
+	SC_R_DMA_1_CH28 = 136,
+	SC_R_DMA_1_CH29 = 137,
+	SC_R_DMA_1_CH30 = 138,
+	SC_R_DMA_1_CH31 = 139,
+	SC_R_UNUSED1 = 140,
+	SC_R_UNUSED2 = 141,
+	SC_R_UNUSED3 = 142,
+	SC_R_UNUSED4 = 143,
+	SC_R_GPU_0_PID0 = 144,
+	SC_R_GPU_0_PID1 = 145,
+	SC_R_GPU_0_PID2 = 146,
+	SC_R_GPU_0_PID3 = 147,
+	SC_R_GPU_1_PID0 = 148,
+	SC_R_GPU_1_PID1 = 149,
+	SC_R_GPU_1_PID2 = 150,
+	SC_R_GPU_1_PID3 = 151,
+	SC_R_PCIE_A = 152,
+	SC_R_SERDES_0 = 153,
+	SC_R_MATCH_0 = 154,
+	SC_R_MATCH_1 = 155,
+	SC_R_MATCH_2 = 156,
+	SC_R_MATCH_3 = 157,
+	SC_R_MATCH_4 = 158,
+	SC_R_MATCH_5 = 159,
+	SC_R_MATCH_6 = 160,
+	SC_R_MATCH_7 = 161,
+	SC_R_MATCH_8 = 162,
+	SC_R_MATCH_9 = 163,
+	SC_R_MATCH_10 = 164,
+	SC_R_MATCH_11 = 165,
+	SC_R_MATCH_12 = 166,
+	SC_R_MATCH_13 = 167,
+	SC_R_MATCH_14 = 168,
+	SC_R_PCIE_B = 169,
+	SC_R_SATA_0 = 170,
+	SC_R_SERDES_1 = 171,
+	SC_R_HSIO_GPIO = 172,
+	SC_R_MATCH_15 = 173,
+	SC_R_MATCH_16 = 174,
+	SC_R_MATCH_17 = 175,
+	SC_R_MATCH_18 = 176,
+	SC_R_MATCH_19 = 177,
+	SC_R_MATCH_20 = 178,
+	SC_R_MATCH_21 = 179,
+	SC_R_MATCH_22 = 180,
+	SC_R_MATCH_23 = 181,
+	SC_R_MATCH_24 = 182,
+	SC_R_MATCH_25 = 183,
+	SC_R_MATCH_26 = 184,
+	SC_R_MATCH_27 = 185,
+	SC_R_MATCH_28 = 186,
+	SC_R_LCD_0 = 187,
+	SC_R_LCD_0_PWM_0 = 188,
+	SC_R_LCD_0_I2C_0 = 189,
+	SC_R_LCD_0_I2C_1 = 190,
+	SC_R_PWM_0 = 191,
+	SC_R_PWM_1 = 192,
+	SC_R_PWM_2 = 193,
+	SC_R_PWM_3 = 194,
+	SC_R_PWM_4 = 195,
+	SC_R_PWM_5 = 196,
+	SC_R_PWM_6 = 197,
+	SC_R_PWM_7 = 198,
+	SC_R_GPIO_0 = 199,
+	SC_R_GPIO_1 = 200,
+	SC_R_GPIO_2 = 201,
+	SC_R_GPIO_3 = 202,
+	SC_R_GPIO_4 = 203,
+	SC_R_GPIO_5 = 204,
+	SC_R_GPIO_6 = 205,
+	SC_R_GPIO_7 = 206,
+	SC_R_GPT_0 = 207,
+	SC_R_GPT_1 = 208,
+	SC_R_GPT_2 = 209,
+	SC_R_GPT_3 = 210,
+	SC_R_GPT_4 = 211,
+	SC_R_KPP = 212,
+	SC_R_MU_0A = 213,
+	SC_R_MU_1A = 214,
+	SC_R_MU_2A = 215,
+	SC_R_MU_3A = 216,
+	SC_R_MU_4A = 217,
+	SC_R_MU_5A = 218,
+	SC_R_MU_6A = 219,
+	SC_R_MU_7A = 220,
+	SC_R_MU_8A = 221,
+	SC_R_MU_9A = 222,
+	SC_R_MU_10A = 223,
+	SC_R_MU_11A = 224,
+	SC_R_MU_12A = 225,
+	SC_R_MU_13A = 226,
+	SC_R_MU_5B = 227,
+	SC_R_MU_6B = 228,
+	SC_R_MU_7B = 229,
+	SC_R_MU_8B = 230,
+	SC_R_MU_9B = 231,
+	SC_R_MU_10B = 232,
+	SC_R_MU_11B = 233,
+	SC_R_MU_12B = 234,
+	SC_R_MU_13B = 235,
+	SC_R_ROM_0 = 236,
+	SC_R_FSPI_0 = 237,
+	SC_R_FSPI_1 = 238,
+	SC_R_IEE = 239,
+	SC_R_IEE_R0 = 240,
+	SC_R_IEE_R1 = 241,
+	SC_R_IEE_R2 = 242,
+	SC_R_IEE_R3 = 243,
+	SC_R_IEE_R4 = 244,
+	SC_R_IEE_R5 = 245,
+	SC_R_IEE_R6 = 246,
+	SC_R_IEE_R7 = 247,
+	SC_R_SDHC_0 = 248,
+	SC_R_SDHC_1 = 249,
+	SC_R_SDHC_2 = 250,
+	SC_R_ENET_0 = 251,
+	SC_R_ENET_1 = 252,
+	SC_R_MLB_0 = 253,
+	SC_R_DMA_2_CH0 = 254,
+	SC_R_DMA_2_CH1 = 255,
+	SC_R_DMA_2_CH2 = 256,
+	SC_R_DMA_2_CH3 = 257,
+	SC_R_DMA_2_CH4 = 258,
+	SC_R_USB_0 = 259,
+	SC_R_USB_1 = 260,
+	SC_R_USB_0_PHY = 261,
+	SC_R_USB_2 = 262,
+	SC_R_USB_2_PHY = 263,
+	SC_R_DTCP = 264,
+	SC_R_NAND = 265,
+	SC_R_LVDS_0 = 266,
+	SC_R_LVDS_0_PWM_0 = 267,
+	SC_R_LVDS_0_I2C_0 = 268,
+	SC_R_LVDS_0_I2C_1 = 269,
+	SC_R_LVDS_1 = 270,
+	SC_R_LVDS_1_PWM_0 = 271,
+	SC_R_LVDS_1_I2C_0 = 272,
+	SC_R_LVDS_1_I2C_1 = 273,
+	SC_R_LVDS_2 = 274,
+	SC_R_LVDS_2_PWM_0 = 275,
+	SC_R_LVDS_2_I2C_0 = 276,
+	SC_R_LVDS_2_I2C_1 = 277,
+	SC_R_M4_0_PID0 = 278,
+	SC_R_M4_0_PID1 = 279,
+	SC_R_M4_0_PID2 = 280,
+	SC_R_M4_0_PID3 = 281,
+	SC_R_M4_0_PID4 = 282,
+	SC_R_M4_0_RGPIO = 283,
+	SC_R_M4_0_SEMA42 = 284,
+	SC_R_M4_0_TPM = 285,
+	SC_R_M4_0_PIT = 286,
+	SC_R_M4_0_UART = 287,
+	SC_R_M4_0_I2C = 288,
+	SC_R_M4_0_INTMUX = 289,
+	SC_R_M4_0_SIM = 290,
+	SC_R_M4_0_WDOG = 291,
+	SC_R_M4_0_MU_0B = 292,
+	SC_R_M4_0_MU_0A0 = 293,
+	SC_R_M4_0_MU_0A1 = 294,
+	SC_R_M4_0_MU_0A2 = 295,
+	SC_R_M4_0_MU_0A3 = 296,
+	SC_R_M4_0_MU_1A = 297,
+	SC_R_M4_1_PID0 = 298,
+	SC_R_M4_1_PID1 = 299,
+	SC_R_M4_1_PID2 = 300,
+	SC_R_M4_1_PID3 = 301,
+	SC_R_M4_1_PID4 = 302,
+	SC_R_M4_1_RGPIO = 303,
+	SC_R_M4_1_SEMA42 = 304,
+	SC_R_M4_1_TPM = 305,
+	SC_R_M4_1_PIT = 306,
+	SC_R_M4_1_UART = 307,
+	SC_R_M4_1_I2C = 308,
+	SC_R_M4_1_INTMUX = 309,
+	SC_R_M4_1_SIM = 310,
+	SC_R_M4_1_WDOG = 311,
+	SC_R_M4_1_MU_0B = 312,
+	SC_R_M4_1_MU_0A0 = 313,
+	SC_R_M4_1_MU_0A1 = 314,
+	SC_R_M4_1_MU_0A2 = 315,
+	SC_R_M4_1_MU_0A3 = 316,
+	SC_R_M4_1_MU_1A = 317,
+	SC_R_SAI_0 = 318,
+	SC_R_SAI_1 = 319,
+	SC_R_SAI_2 = 320,
+	SC_R_IRQSTR_SCU2 = 321,
+	SC_R_IRQSTR_DSP = 322,
+	SC_R_UNUSED5 = 323,
+	SC_R_UNUSED6 = 324,
+	SC_R_AUDIO_PLL_0 = 325,
+	SC_R_PI_0 = 326,
+	SC_R_PI_0_PWM_0 = 327,
+	SC_R_PI_0_PWM_1 = 328,
+	SC_R_PI_0_I2C_0 = 329,
+	SC_R_PI_0_PLL = 330,
+	SC_R_PI_1 = 331,
+	SC_R_PI_1_PWM_0 = 332,
+	SC_R_PI_1_PWM_1 = 333,
+	SC_R_PI_1_I2C_0 = 334,
+	SC_R_PI_1_PLL = 335,
+	SC_R_SC_PID0 = 336,
+	SC_R_SC_PID1 = 337,
+	SC_R_SC_PID2 = 338,
+	SC_R_SC_PID3 = 339,
+	SC_R_SC_PID4 = 340,
+	SC_R_SC_SEMA42 = 341,
+	SC_R_SC_TPM = 342,
+	SC_R_SC_PIT = 343,
+	SC_R_SC_UART = 344,
+	SC_R_SC_I2C = 345,
+	SC_R_SC_MU_0B = 346,
+	SC_R_SC_MU_0A0 = 347,
+	SC_R_SC_MU_0A1 = 348,
+	SC_R_SC_MU_0A2 = 349,
+	SC_R_SC_MU_0A3 = 350,
+	SC_R_SC_MU_1A = 351,
+	SC_R_SYSCNT_RD = 352,
+	SC_R_SYSCNT_CMP = 353,
+	SC_R_DEBUG = 354,
+	SC_R_SYSTEM = 355,
+	SC_R_SNVS = 356,
+	SC_R_OTP = 357,
+	SC_R_VPU_PID0 = 358,
+	SC_R_VPU_PID1 = 359,
+	SC_R_VPU_PID2 = 360,
+	SC_R_VPU_PID3 = 361,
+	SC_R_VPU_PID4 = 362,
+	SC_R_VPU_PID5 = 363,
+	SC_R_VPU_PID6 = 364,
+	SC_R_VPU_PID7 = 365,
+	SC_R_VPU_UART = 366,
+	SC_R_VPUCORE = 367,
+	SC_R_VPUCORE_0 = 368,
+	SC_R_VPUCORE_1 = 369,
+	SC_R_VPUCORE_2 = 370,
+	SC_R_VPUCORE_3 = 371,
+	SC_R_DMA_4_CH0 = 372,
+	SC_R_DMA_4_CH1 = 373,
+	SC_R_DMA_4_CH2 = 374,
+	SC_R_DMA_4_CH3 = 375,
+	SC_R_DMA_4_CH4 = 376,
+	SC_R_ISI_CH0 = 377,
+	SC_R_ISI_CH1 = 378,
+	SC_R_ISI_CH2 = 379,
+	SC_R_ISI_CH3 = 380,
+	SC_R_ISI_CH4 = 381,
+	SC_R_ISI_CH5 = 382,
+	SC_R_ISI_CH6 = 383,
+	SC_R_ISI_CH7 = 384,
+	SC_R_MJPEG_DEC_S0 = 385,
+	SC_R_MJPEG_DEC_S1 = 386,
+	SC_R_MJPEG_DEC_S2 = 387,
+	SC_R_MJPEG_DEC_S3 = 388,
+	SC_R_MJPEG_ENC_S0 = 389,
+	SC_R_MJPEG_ENC_S1 = 390,
+	SC_R_MJPEG_ENC_S2 = 391,
+	SC_R_MJPEG_ENC_S3 = 392,
+	SC_R_MIPI_0 = 393,
+	SC_R_MIPI_0_PWM_0 = 394,
+	SC_R_MIPI_0_I2C_0 = 395,
+	SC_R_MIPI_0_I2C_1 = 396,
+	SC_R_MIPI_1 = 397,
+	SC_R_MIPI_1_PWM_0 = 398,
+	SC_R_MIPI_1_I2C_0 = 399,
+	SC_R_MIPI_1_I2C_1 = 400,
+	SC_R_CSI_0 = 401,
+	SC_R_CSI_0_PWM_0 = 402,
+	SC_R_CSI_0_I2C_0 = 403,
+	SC_R_CSI_1 = 404,
+	SC_R_CSI_1_PWM_0 = 405,
+	SC_R_CSI_1_I2C_0 = 406,
+	SC_R_HDMI = 407,
+	SC_R_HDMI_I2S = 408,
+	SC_R_HDMI_I2C_0 = 409,
+	SC_R_HDMI_PLL_0 = 410,
+	SC_R_HDMI_RX = 411,
+	SC_R_HDMI_RX_BYPASS = 412,
+	SC_R_HDMI_RX_I2C_0 = 413,
+	SC_R_ASRC_0 = 414,
+	SC_R_ESAI_0 = 415,
+	SC_R_SPDIF_0 = 416,
+	SC_R_SPDIF_1 = 417,
+	SC_R_SAI_3 = 418,
+	SC_R_SAI_4 = 419,
+	SC_R_SAI_5 = 420,
+	SC_R_GPT_5 = 421,
+	SC_R_GPT_6 = 422,
+	SC_R_GPT_7 = 423,
+	SC_R_GPT_8 = 424,
+	SC_R_GPT_9 = 425,
+	SC_R_GPT_10 = 426,
+	SC_R_DMA_2_CH5 = 427,
+	SC_R_DMA_2_CH6 = 428,
+	SC_R_DMA_2_CH7 = 429,
+	SC_R_DMA_2_CH8 = 430,
+	SC_R_DMA_2_CH9 = 431,
+	SC_R_DMA_2_CH10 = 432,
+	SC_R_DMA_2_CH11 = 433,
+	SC_R_DMA_2_CH12 = 434,
+	SC_R_DMA_2_CH13 = 435,
+	SC_R_DMA_2_CH14 = 436,
+	SC_R_DMA_2_CH15 = 437,
+	SC_R_DMA_2_CH16 = 438,
+	SC_R_DMA_2_CH17 = 439,
+	SC_R_DMA_2_CH18 = 440,
+	SC_R_DMA_2_CH19 = 441,
+	SC_R_DMA_2_CH20 = 442,
+	SC_R_DMA_2_CH21 = 443,
+	SC_R_DMA_2_CH22 = 444,
+	SC_R_DMA_2_CH23 = 445,
+	SC_R_DMA_2_CH24 = 446,
+	SC_R_DMA_2_CH25 = 447,
+	SC_R_DMA_2_CH26 = 448,
+	SC_R_DMA_2_CH27 = 449,
+	SC_R_DMA_2_CH28 = 450,
+	SC_R_DMA_2_CH29 = 451,
+	SC_R_DMA_2_CH30 = 452,
+	SC_R_DMA_2_CH31 = 453,
+	SC_R_ASRC_1 = 454,
+	SC_R_ESAI_1 = 455,
+	SC_R_SAI_6 = 456,
+	SC_R_SAI_7 = 457,
+	SC_R_AMIX = 458,
+	SC_R_MQS_0 = 459,
+	SC_R_DMA_3_CH0 = 460,
+	SC_R_DMA_3_CH1 = 461,
+	SC_R_DMA_3_CH2 = 462,
+	SC_R_DMA_3_CH3 = 463,
+	SC_R_DMA_3_CH4 = 464,
+	SC_R_DMA_3_CH5 = 465,
+	SC_R_DMA_3_CH6 = 466,
+	SC_R_DMA_3_CH7 = 467,
+	SC_R_DMA_3_CH8 = 468,
+	SC_R_DMA_3_CH9 = 469,
+	SC_R_DMA_3_CH10 = 470,
+	SC_R_DMA_3_CH11 = 471,
+	SC_R_DMA_3_CH12 = 472,
+	SC_R_DMA_3_CH13 = 473,
+	SC_R_DMA_3_CH14 = 474,
+	SC_R_DMA_3_CH15 = 475,
+	SC_R_DMA_3_CH16 = 476,
+	SC_R_DMA_3_CH17 = 477,
+	SC_R_DMA_3_CH18 = 478,
+	SC_R_DMA_3_CH19 = 479,
+	SC_R_DMA_3_CH20 = 480,
+	SC_R_DMA_3_CH21 = 481,
+	SC_R_DMA_3_CH22 = 482,
+	SC_R_DMA_3_CH23 = 483,
+	SC_R_DMA_3_CH24 = 484,
+	SC_R_DMA_3_CH25 = 485,
+	SC_R_DMA_3_CH26 = 486,
+	SC_R_DMA_3_CH27 = 487,
+	SC_R_DMA_3_CH28 = 488,
+	SC_R_DMA_3_CH29 = 489,
+	SC_R_DMA_3_CH30 = 490,
+	SC_R_DMA_3_CH31 = 491,
+	SC_R_AUDIO_PLL_1 = 492,
+	SC_R_AUDIO_CLK_0 = 493,
+	SC_R_AUDIO_CLK_1 = 494,
+	SC_R_MCLK_OUT_0 = 495,
+	SC_R_MCLK_OUT_1 = 496,
+	SC_R_PMIC_0 = 497,
+	SC_R_PMIC_1 = 498,
+	SC_R_SECO = 499,
+	SC_R_CAAM_JR1 = 500,
+	SC_R_CAAM_JR2 = 501,
+	SC_R_CAAM_JR3 = 502,
+	SC_R_SECO_MU_2 = 503,
+	SC_R_SECO_MU_3 = 504,
+	SC_R_SECO_MU_4 = 505,
+	SC_R_HDMI_RX_PWM_0 = 506,
+	SC_R_A35 = 507,
+	SC_R_A35_0 = 508,
+	SC_R_A35_1 = 509,
+	SC_R_A35_2 = 510,
+	SC_R_A35_3 = 511,
+	SC_R_DSP = 512,
+	SC_R_DSP_RAM = 513,
+	SC_R_CAAM_JR1_OUT = 514,
+	SC_R_CAAM_JR2_OUT = 515,
+	SC_R_CAAM_JR3_OUT = 516,
+	SC_R_VPU_DEC_0 = 517,
+	SC_R_VPU_ENC_0 = 518,
+	SC_R_CAAM_JR0 = 519,
+	SC_R_CAAM_JR0_OUT = 520,
+	SC_R_PMIC_2 = 521,
+	SC_R_DBLOGIC = 522,
+	SC_R_HDMI_PLL_1 = 523,
+	SC_R_BOARD_R0 = 524,
+	SC_R_BOARD_R1 = 525,
+	SC_R_BOARD_R2 = 526,
+	SC_R_BOARD_R3 = 527,
+	SC_R_BOARD_R4 = 528,
+	SC_R_BOARD_R5 = 529,
+	SC_R_BOARD_R6 = 530,
+	SC_R_BOARD_R7 = 531,
+	SC_R_MJPEG_DEC_MP = 532,
+	SC_R_MJPEG_ENC_MP = 533,
+	SC_R_VPU_TS_0 = 534,
+	SC_R_VPU_MU_0 = 535,
+	SC_R_VPU_MU_1 = 536,
+	SC_R_VPU_MU_2 = 537,
+	SC_R_VPU_MU_3 = 538,
+	SC_R_VPU_ENC_1 = 539,
+	SC_R_VPU = 540,
+	SC_R_LAST
+} sc_rsrc_t;
+
+/* NOTE - please add by replacing some of the UNUSED from above! */
+
+/*
+ * This type is used to indicate a control.
+ */
+typedef enum sc_ctrl_e {
+	SC_C_TEMP = 0,
+	SC_C_TEMP_HI = 1,
+	SC_C_TEMP_LOW = 2,
+	SC_C_PXL_LINK_MST1_ADDR = 3,
+	SC_C_PXL_LINK_MST2_ADDR = 4,
+	SC_C_PXL_LINK_MST_ENB = 5,
+	SC_C_PXL_LINK_MST1_ENB = 6,
+	SC_C_PXL_LINK_MST2_ENB = 7,
+	SC_C_PXL_LINK_SLV1_ADDR = 8,
+	SC_C_PXL_LINK_SLV2_ADDR = 9,
+	SC_C_PXL_LINK_MST_VLD = 10,
+	SC_C_PXL_LINK_MST1_VLD = 11,
+	SC_C_PXL_LINK_MST2_VLD = 12,
+	SC_C_SINGLE_MODE = 13,
+	SC_C_ID = 14,
+	SC_C_PXL_CLK_POLARITY = 15,
+	SC_C_LINESTATE = 16,
+	SC_C_PCIE_G_RST = 17,
+	SC_C_PCIE_BUTTON_RST = 18,
+	SC_C_PCIE_PERST = 19,
+	SC_C_PHY_RESET = 20,
+	SC_C_PXL_LINK_RATE_CORRECTION = 21,
+	SC_C_PANIC = 22,
+	SC_C_PRIORITY_GROUP = 23,
+	SC_C_TXCLK = 24,
+	SC_C_CLKDIV = 25,
+	SC_C_DISABLE_50 = 26,
+	SC_C_DISABLE_125 = 27,
+	SC_C_SEL_125 = 28,
+	SC_C_MODE = 29,
+	SC_C_SYNC_CTRL0 = 30,
+	SC_C_KACHUNK_CNT = 31,
+	SC_C_KACHUNK_SEL = 32,
+	SC_C_SYNC_CTRL1 = 33,
+	SC_C_DPI_RESET = 34,
+	SC_C_MIPI_RESET = 35,
+	SC_C_DUAL_MODE = 36,
+	SC_C_VOLTAGE = 37,
+	SC_C_PXL_LINK_SEL = 38,
+	SC_C_OFS_SEL = 39,
+	SC_C_OFS_AUDIO = 40,
+	SC_C_OFS_PERIPH = 41,
+	SC_C_OFS_IRQ = 42,
+	SC_C_RST0 = 43,
+	SC_C_RST1 = 44,
+	SC_C_SEL0 = 45,
+	SC_C_LAST
+} sc_ctrl_t;
+
+#endif /* _SC_TYPES_H */
-- 
2.7.4

[PATCH V5 2/5] soc: imx: add SC firmware IPC and APIs

[Sascha Hauer]

On Tue, Aug 21, 2018 at 12:08:22AM +0800, Dong Aisheng wrote:
> The System Controller Firmware (SCFW) is a low-level system function
> which runs on a dedicated Cortex-M core to provide power, clock, and
> resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
> (QM, QP), and i.MX8QX (QXP, DX).
> 
> This patch adds the SC firmware service APIs used by the system.
> It mainly consists of two parts:
> 1) Implementation of the IPC functions using MUs (client side).
> 2) SCU firmware services APIs implemented based on RPC calls
> 
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Jassi Brar <jassisinghbrar@gmail.com>
> Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> ---
> +int sc_ipc_open(sc_ipc_t *ipc, struct device *dev)
> +{
> +	struct sc_ipc *sc_ipc;
> +	struct sc_chan *sc_chan;
> +	struct mbox_client *cl;
> +	char *chan_name;
> +	int ret;
> +	int i;
> +
> +	sc_ipc = devm_kzalloc(dev, sizeof(*sc_ipc), GFP_KERNEL);
> +	if (!sc_ipc)
> +		return -ENOMEM;
> +
> +	for (i = 0; i < SCU_MU_CHAN_NUM; i++) {
> +		if (i < 4)
> +			chan_name = kasprintf(GFP_KERNEL, "tx%d", i);
> +		else
> +			chan_name = kasprintf(GFP_KERNEL, "rx%d", i - 4);
> +
> +		if (!chan_name)
> +			return -ENOMEM;
> +
> +		sc_chan = &sc_ipc->chans[i];
> +		cl = &sc_chan->cl;
> +		cl->dev = dev;
> +		cl->tx_block = false;
> +		cl->knows_txdone = true;
> +		cl->rx_callback = sc_rx_callback;
> +
> +		sc_chan->sc_ipc = sc_ipc;
> +		sc_chan->idx = i % 4;
> +		sc_chan->ch = mbox_request_channel_byname(cl, chan_name);
> +		if (IS_ERR(sc_chan->ch)) {
> +			ret = PTR_ERR(sc_chan->ch);
> +			if (ret != -EPROBE_DEFER)
> +				dev_err(dev, "Failed to get mbox %d\n", ret);
> +
> +			return ret;
> +		}
> +
> +		dev_dbg(dev, "mbox request chan %s\n", chan_name);
> +		/* chan_name is not used anymore by framework */
> +		kfree(chan_name);
> +	}
> +
> +	sc_ipc->dev = dev;
> +	mutex_init(&sc_ipc->lock);
> +	init_completion(&sc_ipc->done);
> +
> +	*ipc = (sc_ipc_t)sc_ipc;
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(sc_ipc_open);

You export a sc_ipc_open() but it's only ever used once, in your
internal code. Every other user uses sc_ipc_get_handle() which returns
the same global handle for every user. In fact, I think sc_ipc_open()
*can* only be used once, because every other user would get -EBUSY when
requesting the same mailboxes again.

Please drop all this pseudo resource management nonsense. You simply do
no resource management. Face it, there is only one global handle that is
used, don't try to hide it.

I had a look at the FSL Kernel to see where this code comes from and
what the initial intention might be and I almost fell from my chair
laughing.

Every scu consumer does a:

>	sc_ipc_getMuID(&mu_id);

which returs a global mu id

>	sc_ipc_open(&ipcHndl, mu_id);

mu_id is not used in this function (or correctly, used to calculate a
value which is then unused). ipcHndl is filled with the current task
pid. Hell what, how is the current task pid used as an identifier? Ok,
read on.

>	sc_misc_set_control(ipcHndl, ...);

Following the code we end up in sc_ipc_write() / sc_ipc_read() where
this handle, filled with some random value is not even used. So
everything around sc_ipc_getMuID() and sc_ipc_open() is just dead code.
It's just a complicated way to generate an arbitrary number which then
ends up being unused. Even some init code calls sc_ipc_open() and
assigns the result to some global variable mu_ipcHandle.  This variable
is only used to pass it to sc_irq_enable(), but looking at
sc_irq_enable() you see that this parameter is again unused.

If you want to get this upstream I strongly suggest that you free
yourself from the FSL codebase.

> +/*
> + * This type is used to declare a handle for an IPC communication
> + * channel. Its meaning is specific to the IPC implementation.
> + */
> +typedef unsigned long sc_ipc_t;

sc_ipc_t is a typedef to unsigned long. Let's see how it's used:

void sc_ipc_close(sc_ipc_t ipc)
{
	struct sc_ipc *sc_ipc = (struct sc_ipc *)ipc;
	...
}

So sc_ipc_t really is a struct sc_ipc *. Why don't you simply use it as
such? Forget about typdefs. Do not use them. Call this thingy "struct
sc_ipc" and that's it. No need for casting or typedefing.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH V5 2/5] soc: imx: add SC firmware IPC and APIs

[A.s. Dong]

> -----Original Message-----
> From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> Sent: Monday, September 10, 2018 4:41 PM
> To: A.s. Dong <aisheng.dong@nxp.com>
> Cc: linux-arm-kernel at lists.infradead.org; dongas86 at gmail.com; Jassi Brar
> <jassisinghbrar@gmail.com>; dl-linux-imx <linux-imx@nxp.com>;
> kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> shawnguo at kernel.org
> Subject: Re: [PATCH V5 2/5] soc: imx: add SC firmware IPC and APIs
> 
> On Tue, Aug 21, 2018 at 12:08:22AM +0800, Dong Aisheng wrote:
> > The System Controller Firmware (SCFW) is a low-level system function
> > which runs on a dedicated Cortex-M core to provide power, clock, and
> > resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
> > (QM, QP), and i.MX8QX (QXP, DX).
> >
> > This patch adds the SC firmware service APIs used by the system.
> > It mainly consists of two parts:
> > 1) Implementation of the IPC functions using MUs (client side).
> > 2) SCU firmware services APIs implemented based on RPC calls
> >
> > Cc: Shawn Guo <shawnguo@kernel.org>
> > Cc: Sascha Hauer <kernel@pengutronix.de>
> > Cc: Fabio Estevam <fabio.estevam@nxp.com>
> > Cc: Jassi Brar <jassisinghbrar@gmail.com>
> > Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> > ---
> > +int sc_ipc_open(sc_ipc_t *ipc, struct device *dev) {
> > +	struct sc_ipc *sc_ipc;
> > +	struct sc_chan *sc_chan;
> > +	struct mbox_client *cl;
> > +	char *chan_name;
> > +	int ret;
> > +	int i;
> > +
> > +	sc_ipc = devm_kzalloc(dev, sizeof(*sc_ipc), GFP_KERNEL);
> > +	if (!sc_ipc)
> > +		return -ENOMEM;
> > +
> > +	for (i = 0; i < SCU_MU_CHAN_NUM; i++) {
> > +		if (i < 4)
> > +			chan_name = kasprintf(GFP_KERNEL, "tx%d", i);
> > +		else
> > +			chan_name = kasprintf(GFP_KERNEL, "rx%d", i - 4);
> > +
> > +		if (!chan_name)
> > +			return -ENOMEM;
> > +
> > +		sc_chan = &sc_ipc->chans[i];
> > +		cl = &sc_chan->cl;
> > +		cl->dev = dev;
> > +		cl->tx_block = false;
> > +		cl->knows_txdone = true;
> > +		cl->rx_callback = sc_rx_callback;
> > +
> > +		sc_chan->sc_ipc = sc_ipc;
> > +		sc_chan->idx = i % 4;
> > +		sc_chan->ch = mbox_request_channel_byname(cl, chan_name);
> > +		if (IS_ERR(sc_chan->ch)) {
> > +			ret = PTR_ERR(sc_chan->ch);
> > +			if (ret != -EPROBE_DEFER)
> > +				dev_err(dev, "Failed to get mbox %d\n", ret);
> > +
> > +			return ret;
> > +		}
> > +
> > +		dev_dbg(dev, "mbox request chan %s\n", chan_name);
> > +		/* chan_name is not used anymore by framework */
> > +		kfree(chan_name);
> > +	}
> > +
> > +	sc_ipc->dev = dev;
> > +	mutex_init(&sc_ipc->lock);
> > +	init_completion(&sc_ipc->done);
> > +
> > +	*ipc = (sc_ipc_t)sc_ipc;
> > +
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL(sc_ipc_open);
> 
> You export a sc_ipc_open() but it's only ever used once, in your internal code.
> Every other user uses sc_ipc_get_handle() which returns the same global
> handle for every user. In fact, I think sc_ipc_open()
> *can* only be used once, because every other user would get -EBUSY when
> requesting the same mailboxes again.
> 
> Please drop all this pseudo resource management nonsense. You simply do no
> resource management. Face it, there is only one global handle that is used,
> don't try to hide it.
> 

The original purpose of this code is that there're 5 MUs can be used by the system,
that means other users can choose to not use the default SCU MU. So sc_ipc_open()
may not be used only once.
e.g.
SCU MU1 sc_ipc_open()
CLK MU1 sc_ipc_get_handle()
Power Domain MU2 sc_ipc_open()
Pinctrl MU3 sc_ipc_open()
and etc...

>From TI SCI code, it seems it also support multiple SCI phandle although the kernel currently
Only users one. But the idea behind is the same.

> I had a look at the FSL Kernel to see where this code comes from and what the
> initial intention might be and I almost fell from my chair laughing.
> 

I'm really sorry you got a bad impression on the internal code.
We do know those issues and I've already reported them to internal team
a few months ago and I would like to help clean up them later.
For upstream, I actually have already totally rewritten the code, none of them
are used except keep a few function name definition from an abstract view.

> Every scu consumer does a:
> 
> >	sc_ipc_getMuID(&mu_id);
> 
> which returs a global mu id
> 
> >	sc_ipc_open(&ipcHndl, mu_id);
> 
> mu_id is not used in this function (or correctly, used to calculate a value which
> is then unused). ipcHndl is filled with the current task pid. Hell what, how is
> the current task pid used as an identifier? Ok, read on.
> 
> >	sc_misc_set_control(ipcHndl, ...);
> 
> Following the code we end up in sc_ipc_write() / sc_ipc_read() where this
> handle, filled with some random value is not even used. So everything around
> sc_ipc_getMuID() and sc_ipc_open() is just dead code.
> It's just a complicated way to generate an arbitrary number which then ends
> up being unused. Even some init code calls sc_ipc_open() and assigns the result
> to some global variable mu_ipcHandle.  This variable is only used to pass it to
> sc_irq_enable(), but looking at
> sc_irq_enable() you see that this parameter is again unused.
> 
> If you want to get this upstream I strongly suggest that you free yourself from
> the FSL codebase.

Yes, I've already totally rewritten them before upstream.
The above code you pointed out are not in my patches.

> 
> > +/*
> > + * This type is used to declare a handle for an IPC communication
> > + * channel. Its meaning is specific to the IPC implementation.
> > + */
> > +typedef unsigned long sc_ipc_t;
> 
> sc_ipc_t is a typedef to unsigned long. Let's see how it's used:
> 
> void sc_ipc_close(sc_ipc_t ipc)
> {
> 	struct sc_ipc *sc_ipc = (struct sc_ipc *)ipc;
> 	...
> }
> 
> So sc_ipc_t really is a struct sc_ipc *. Why don't you simply use it as such?
> Forget about typdefs. Do not use them. Call this thingy "struct sc_ipc" and
> that's it. No need for casting or typedefing.
> 

Our SCU firmware is OS independent. From SC point of view definition,
sc_ipc_t implementation is OS dependant. OS can interpret them into
the structure they needed. That's the orginal purpose and where the APIs
are prototyped.

But I'm also ok if you think no need to keep it as it's already determined
for Linux OS. Just let me know and I will do it.

Thanks for the review.

Regards
Dong Aisheng

> Sascha
> 
> --
> Pengutronix e.K.                           |
> |
> Industrial Linux Solutions                 |
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> pengutronix.de%2F&amp;data=02%7C01%7Caisheng.dong%40nxp.com%7C3d
> 7053028342490dd3e008d616f91982%7C686ea1d3bc2b4c6fa92cd99c5c3016
> 35%7C0%7C0%7C636721656469432903&amp;sdata=MKpRwuI7HlZNmDcvrV
> OxpkUHqtv1It%2FHKiSK031ITuM%3D&amp;reserved=0  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> |
> Amtsgericht Hildesheim, HRA 2686           | Fax:
> +49-5121-206917-5555 |

[PATCH V5 2/5] soc: imx: add SC firmware IPC and APIs

[Sascha Hauer]

On Mon, Sep 10, 2018 at 09:44:08AM +0000, A.s. Dong wrote:
> > -----Original Message-----
> > From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> > Sent: Monday, September 10, 2018 4:41 PM
> > To: A.s. Dong <aisheng.dong@nxp.com>
> > Cc: linux-arm-kernel at lists.infradead.org; dongas86 at gmail.com; Jassi Brar
> > <jassisinghbrar@gmail.com>; dl-linux-imx <linux-imx@nxp.com>;
> > kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> > shawnguo at kernel.org
> > Subject: Re: [PATCH V5 2/5] soc: imx: add SC firmware IPC and APIs
> > 
> > On Tue, Aug 21, 2018 at 12:08:22AM +0800, Dong Aisheng wrote:
> > > The System Controller Firmware (SCFW) is a low-level system function
> > > which runs on a dedicated Cortex-M core to provide power, clock, and
> > > resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
> > > (QM, QP), and i.MX8QX (QXP, DX).
> > >
> > > This patch adds the SC firmware service APIs used by the system.
> > > It mainly consists of two parts:
> > > 1) Implementation of the IPC functions using MUs (client side).
> > > 2) SCU firmware services APIs implemented based on RPC calls
> > >
> > > Cc: Shawn Guo <shawnguo@kernel.org>
> > > Cc: Sascha Hauer <kernel@pengutronix.de>
> > > Cc: Fabio Estevam <fabio.estevam@nxp.com>
> > > Cc: Jassi Brar <jassisinghbrar@gmail.com>
> > > Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> > > ---
> > > +int sc_ipc_open(sc_ipc_t *ipc, struct device *dev) {
> > > +	struct sc_ipc *sc_ipc;
> > > +	struct sc_chan *sc_chan;
> > > +	struct mbox_client *cl;
> > > +	char *chan_name;
> > > +	int ret;
> > > +	int i;
> > > +
> > > +	sc_ipc = devm_kzalloc(dev, sizeof(*sc_ipc), GFP_KERNEL);
> > > +	if (!sc_ipc)
> > > +		return -ENOMEM;
> > > +
> > > +	for (i = 0; i < SCU_MU_CHAN_NUM; i++) {
> > > +		if (i < 4)
> > > +			chan_name = kasprintf(GFP_KERNEL, "tx%d", i);
> > > +		else
> > > +			chan_name = kasprintf(GFP_KERNEL, "rx%d", i - 4);
> > > +
> > > +		if (!chan_name)
> > > +			return -ENOMEM;
> > > +
> > > +		sc_chan = &sc_ipc->chans[i];
> > > +		cl = &sc_chan->cl;
> > > +		cl->dev = dev;
> > > +		cl->tx_block = false;
> > > +		cl->knows_txdone = true;
> > > +		cl->rx_callback = sc_rx_callback;
> > > +
> > > +		sc_chan->sc_ipc = sc_ipc;
> > > +		sc_chan->idx = i % 4;
> > > +		sc_chan->ch = mbox_request_channel_byname(cl, chan_name);
> > > +		if (IS_ERR(sc_chan->ch)) {
> > > +			ret = PTR_ERR(sc_chan->ch);
> > > +			if (ret != -EPROBE_DEFER)
> > > +				dev_err(dev, "Failed to get mbox %d\n", ret);
> > > +
> > > +			return ret;
> > > +		}
> > > +
> > > +		dev_dbg(dev, "mbox request chan %s\n", chan_name);
> > > +		/* chan_name is not used anymore by framework */
> > > +		kfree(chan_name);
> > > +	}
> > > +
> > > +	sc_ipc->dev = dev;
> > > +	mutex_init(&sc_ipc->lock);
> > > +	init_completion(&sc_ipc->done);
> > > +
> > > +	*ipc = (sc_ipc_t)sc_ipc;
> > > +
> > > +	return 0;
> > > +}
> > > +EXPORT_SYMBOL(sc_ipc_open);
> > 
> > You export a sc_ipc_open() but it's only ever used once, in your internal code.
> > Every other user uses sc_ipc_get_handle() which returns the same global
> > handle for every user. In fact, I think sc_ipc_open()
> > *can* only be used once, because every other user would get -EBUSY when
> > requesting the same mailboxes again.
> > 
> > Please drop all this pseudo resource management nonsense. You simply do no
> > resource management. Face it, there is only one global handle that is used,
> > don't try to hide it.
> > 
> 
> The original purpose of this code is that there're 5 MUs can be used by the system,
> that means other users can choose to not use the default SCU MU. So sc_ipc_open()
> may not be used only once.
> e.g.
> SCU MU1 sc_ipc_open()
> CLK MU1 sc_ipc_get_handle()
> Power Domain MU2 sc_ipc_open()
> Pinctrl MU3 sc_ipc_open()
> and etc...

Your code started by busy polling the MU units until it would send an
answer. The communication is completely synchronous and on the SCU side
we have a single core cortex M4 processor. Why should we use another SCU
channel? I bet the SCU side services the MUs round robin, so changing
the MU won't change much.

> Our SCU firmware is OS independent. From SC point of view definition,
> sc_ipc_t implementation is OS dependant. OS can interpret them into
> the structure they needed. That's the orginal purpose and where the APIs
> are prototyped.

Nobody is interested in the SCU side here. I'd really like to have a
peek, but it's totally irrelevant for the Kernel code.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH V5 2/5] soc: imx: add SC firmware IPC and APIs

[A.s. Dong]

Hi Sascha,

> -----Original Message-----
> From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> Sent: Monday, September 10, 2018 8:12 PM
> To: A.s. Dong <aisheng.dong@nxp.com>
> Cc: linux-arm-kernel at lists.infradead.org; dongas86 at gmail.com; Jassi Brar
> <jassisinghbrar@gmail.com>; dl-linux-imx <linux-imx@nxp.com>;
> kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> shawnguo at kernel.org
> Subject: Re: [PATCH V5 2/5] soc: imx: add SC firmware IPC and APIs
> 
> On Mon, Sep 10, 2018 at 09:44:08AM +0000, A.s. Dong wrote:
> > > -----Original Message-----
> > > From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> > > Sent: Monday, September 10, 2018 4:41 PM
> > > To: A.s. Dong <aisheng.dong@nxp.com>
> > > Cc: linux-arm-kernel at lists.infradead.org; dongas86 at gmail.com; Jassi
> > > Brar <jassisinghbrar@gmail.com>; dl-linux-imx <linux-imx@nxp.com>;
> > > kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> > > shawnguo at kernel.org
> > > Subject: Re: [PATCH V5 2/5] soc: imx: add SC firmware IPC and APIs
> > >
> > > On Tue, Aug 21, 2018 at 12:08:22AM +0800, Dong Aisheng wrote:
> > > > The System Controller Firmware (SCFW) is a low-level system
> > > > function which runs on a dedicated Cortex-M core to provide power,
> > > > clock, and resource management. It exists on some i.MX8
> > > > processors. e.g. i.MX8QM (QM, QP), and i.MX8QX (QXP, DX).
> > > >
> > > > This patch adds the SC firmware service APIs used by the system.
> > > > It mainly consists of two parts:
> > > > 1) Implementation of the IPC functions using MUs (client side).
> > > > 2) SCU firmware services APIs implemented based on RPC calls
> > > >
> > > > Cc: Shawn Guo <shawnguo@kernel.org>
> > > > Cc: Sascha Hauer <kernel@pengutronix.de>
> > > > Cc: Fabio Estevam <fabio.estevam@nxp.com>
> > > > Cc: Jassi Brar <jassisinghbrar@gmail.com>
> > > > Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> > > > ---
> > > > +int sc_ipc_open(sc_ipc_t *ipc, struct device *dev) {
> > > > +	struct sc_ipc *sc_ipc;
> > > > +	struct sc_chan *sc_chan;
> > > > +	struct mbox_client *cl;
> > > > +	char *chan_name;
> > > > +	int ret;
> > > > +	int i;
> > > > +
> > > > +	sc_ipc = devm_kzalloc(dev, sizeof(*sc_ipc), GFP_KERNEL);
> > > > +	if (!sc_ipc)
> > > > +		return -ENOMEM;
> > > > +
> > > > +	for (i = 0; i < SCU_MU_CHAN_NUM; i++) {
> > > > +		if (i < 4)
> > > > +			chan_name = kasprintf(GFP_KERNEL, "tx%d", i);
> > > > +		else
> > > > +			chan_name = kasprintf(GFP_KERNEL, "rx%d", i - 4);
> > > > +
> > > > +		if (!chan_name)
> > > > +			return -ENOMEM;
> > > > +
> > > > +		sc_chan = &sc_ipc->chans[i];
> > > > +		cl = &sc_chan->cl;
> > > > +		cl->dev = dev;
> > > > +		cl->tx_block = false;
> > > > +		cl->knows_txdone = true;
> > > > +		cl->rx_callback = sc_rx_callback;
> > > > +
> > > > +		sc_chan->sc_ipc = sc_ipc;
> > > > +		sc_chan->idx = i % 4;
> > > > +		sc_chan->ch = mbox_request_channel_byname(cl, chan_name);
> > > > +		if (IS_ERR(sc_chan->ch)) {
> > > > +			ret = PTR_ERR(sc_chan->ch);
> > > > +			if (ret != -EPROBE_DEFER)
> > > > +				dev_err(dev, "Failed to get mbox %d\n", ret);
> > > > +
> > > > +			return ret;
> > > > +		}
> > > > +
> > > > +		dev_dbg(dev, "mbox request chan %s\n", chan_name);
> > > > +		/* chan_name is not used anymore by framework */
> > > > +		kfree(chan_name);
> > > > +	}
> > > > +
> > > > +	sc_ipc->dev = dev;
> > > > +	mutex_init(&sc_ipc->lock);
> > > > +	init_completion(&sc_ipc->done);
> > > > +
> > > > +	*ipc = (sc_ipc_t)sc_ipc;
> > > > +
> > > > +	return 0;
> > > > +}
> > > > +EXPORT_SYMBOL(sc_ipc_open);
> > >
> > > You export a sc_ipc_open() but it's only ever used once, in your internal
> code.
> > > Every other user uses sc_ipc_get_handle() which returns the same
> > > global handle for every user. In fact, I think sc_ipc_open()
> > > *can* only be used once, because every other user would get -EBUSY
> > > when requesting the same mailboxes again.
> > >
> > > Please drop all this pseudo resource management nonsense. You simply
> > > do no resource management. Face it, there is only one global handle
> > > that is used, don't try to hide it.
> > >
> >
> > The original purpose of this code is that there're 5 MUs can be used
> > by the system, that means other users can choose to not use the
> > default SCU MU. So sc_ipc_open() may not be used only once.
> > e.g.
> > SCU MU1 sc_ipc_open()
> > CLK MU1 sc_ipc_get_handle()
> > Power Domain MU2 sc_ipc_open()
> > Pinctrl MU3 sc_ipc_open()
> > and etc...
> 
> Your code started by busy polling the MU units until it would send an answer.
> The communication is completely synchronous and on the SCU side we have a
> single core cortex M4 processor. Why should we use another SCU channel? I
> bet the SCU side services the MUs round robin, so changing the MU won't
> change much.

I carefully went through our SCU side code, SCU messages are completely handled
asynchronously by interrupt driven and it does not have to wait for one SCU Message
to be completed handled before being able to handle the next one.

The pseudo-code is like:
Handle_mu_irq()
{
	For (mu = 0; mu < NUM_MU; mu++) {
		If (mu_pending()) {
			Read(mu); // if available
			Handle(mu); //if rx done
			Write(mu);
		}
	}
	...
}

That means Read and Write process for all MUs channels can be processed sequentially
within one IRQ, Don't have to wait one of them to be fully completed first.

For example, the follow could be:
MU IRQ #0 -> Read MU0 word 0-1 -> Read MU1 word 0-2 -> Read MU2 word 0 -> Exit.
MU IRQ #1 -> Read MU0 word 2 -> Read MU1 word 3 -> Handle MU1 -> Write MU1
		 -> Read MU2 word 1 -> Exit.
MU IRQ #2 -> Read MU0 word 3 -> Handle MU0 -> Write MU0 -> Read MU2 word 2
		 -> Handle MU2 -> Write MU2 -> Exit.
(Assume MU0 msg size 4, MU1 msg size 4, MU2 msg size 3)

But if we only support one SCU MU in kernel, then all SCU messages must be handled
one by one. So it seems like using multiple SCU MUs in kernel are still better than
using a single one. Am I understand correct?

Furthermore, If I understand correct, even SCU msg are processed one by one in SCU side.
Using multiple channels in kernel side still can improve the performance a bit in theory
Because it saves the MU lock contention time. Just like the Async request feature supported
By MMC subsystem(saving MMC command prepare time asynchronously). And multiple
MU channels actually are better because they're individual instances than mmc controller.

> 
> > Our SCU firmware is OS independent. From SC point of view definition,
> > sc_ipc_t implementation is OS dependant. OS can interpret them into
> > the structure they needed. That's the orginal purpose and where the
> > APIs are prototyped.
> 
> Nobody is interested in the SCU side here. I'd really like to have a peek, but it's
> totally irrelevant for the Kernel code.
> 

Okay, got your point. I would remove it.
I'd also wish it opensource some day in the future...

Regards
Dong Aisheng

> Sascha
> 
> --
> Pengutronix e.K.                           |
> |
> Industrial Linux Solutions                 |
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> pengutronix.de%2F&amp;data=02%7C01%7Caisheng.dong%40nxp.com%7C07
> e353ec055a48ca0eee08d61716992d%7C686ea1d3bc2b4c6fa92cd99c5c3016
> 35%7C0%7C0%7C636721783169922469&amp;sdata=o2rN%2FE3UtksWsVRC
> 37wgre5bwqlWu51ZQVgDOUDkG2U%3D&amp;reserved=0  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> |
> Amtsgericht Hildesheim, HRA 2686           | Fax:
> +49-5121-206917-5555 |

[PATCH V5 2/5] soc: imx: add SC firmware IPC and APIs

[A.s. Dong]

Hi Sascha,

> -----Original Message-----
> From: A.s. Dong

[...]

> > > > You export a sc_ipc_open() but it's only ever used once, in your
> > > > internal
> > code.
> > > > Every other user uses sc_ipc_get_handle() which returns the same
> > > > global handle for every user. In fact, I think sc_ipc_open()
> > > > *can* only be used once, because every other user would get -EBUSY
> > > > when requesting the same mailboxes again.
> > > >
> > > > Please drop all this pseudo resource management nonsense. You
> > > > simply do no resource management. Face it, there is only one
> > > > global handle that is used, don't try to hide it.
> > > >
> > >
> > > The original purpose of this code is that there're 5 MUs can be used
> > > by the system, that means other users can choose to not use the
> > > default SCU MU. So sc_ipc_open() may not be used only once.
> > > e.g.
> > > SCU MU1 sc_ipc_open()
> > > CLK MU1 sc_ipc_get_handle()
> > > Power Domain MU2 sc_ipc_open()
> > > Pinctrl MU3 sc_ipc_open()
> > > and etc...
> >
> > Your code started by busy polling the MU units until it would send an answer.
> > The communication is completely synchronous and on the SCU side we
> > have a single core cortex M4 processor. Why should we use another SCU
> > channel? I bet the SCU side services the MUs round robin, so changing
> > the MU won't change much.
> 
> I carefully went through our SCU side code, SCU messages are completely
> handled asynchronously by interrupt driven and it does not have to wait for
> one SCU Message to be completed handled before being able to handle the
> next one.
> 
> The pseudo-code is like:
> Handle_mu_irq()
> {
> 	For (mu = 0; mu < NUM_MU; mu++) {
> 		If (mu_pending()) {
> 			Read(mu); // if available
> 			Handle(mu); //if rx done
> 			Write(mu);
> 		}
> 	}
> 	...
> }
> 
> That means Read and Write process for all MUs channels can be processed
> sequentially within one IRQ, Don't have to wait one of them to be fully
> completed first.
> 
> For example, the follow could be:
> MU IRQ #0 -> Read MU0 word 0-1 -> Read MU1 word 0-2 -> Read MU2 word 0
> -> Exit.
> MU IRQ #1 -> Read MU0 word 2 -> Read MU1 word 3 -> Handle MU1 -> Write
> MU1
> 		 -> Read MU2 word 1 -> Exit.
> MU IRQ #2 -> Read MU0 word 3 -> Handle MU0 -> Write MU0 -> Read MU2
> word 2
> 		 -> Handle MU2 -> Write MU2 -> Exit.
> (Assume MU0 msg size 4, MU1 msg size 4, MU2 msg size 3)
> 
> But if we only support one SCU MU in kernel, then all SCU messages must be
> handled one by one. So it seems like using multiple SCU MUs in kernel are still
> better than using a single one. Am I understand correct?
> 
> Furthermore, If I understand correct, even SCU msg are processed one by one
> in SCU side.
> Using multiple channels in kernel side still can improve the performance a bit
> in theory Because it saves the MU lock contention time. Just like the Async
> request feature supported By MMC subsystem(saving MMC command prepare
> time asynchronously). And multiple MU channels actually are better because
> they're individual instances than mmc controller.
> 

Would you mind give some hints about this?
Can you help clarify a bit if you still think we don't need support multi channels
In kernels regardless of the performance issue?
Then I can just drop it and go ahead.

Regards
Dong Aisheng

[PATCH V5 2/5] soc: imx: add SC firmware IPC and APIs

[Sascha Hauer]

On Tue, Sep 11, 2018 at 10:38:52AM +0000, A.s. Dong wrote:
> Hi Sascha,
> 
> > -----Original Message-----
> > From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> > Sent: Monday, September 10, 2018 8:12 PM
> > To: A.s. Dong <aisheng.dong@nxp.com>
> > Cc: linux-arm-kernel at lists.infradead.org; dongas86 at gmail.com; Jassi Brar
> > <jassisinghbrar@gmail.com>; dl-linux-imx <linux-imx@nxp.com>;
> > kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> > shawnguo at kernel.org
> > Subject: Re: [PATCH V5 2/5] soc: imx: add SC firmware IPC and APIs
> > 
> > On Mon, Sep 10, 2018 at 09:44:08AM +0000, A.s. Dong wrote:
> > > > -----Original Message-----
> > > > From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> > > > Sent: Monday, September 10, 2018 4:41 PM
> > > > To: A.s. Dong <aisheng.dong@nxp.com>
> > > > Cc: linux-arm-kernel at lists.infradead.org; dongas86 at gmail.com; Jassi
> > > > Brar <jassisinghbrar@gmail.com>; dl-linux-imx <linux-imx@nxp.com>;
> > > > kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> > > > shawnguo at kernel.org
> > > > Subject: Re: [PATCH V5 2/5] soc: imx: add SC firmware IPC and APIs
> > > >
> > > > On Tue, Aug 21, 2018 at 12:08:22AM +0800, Dong Aisheng wrote:
> > > > > The System Controller Firmware (SCFW) is a low-level system
> > > > > function which runs on a dedicated Cortex-M core to provide power,
> > > > > clock, and resource management. It exists on some i.MX8
> > > > > processors. e.g. i.MX8QM (QM, QP), and i.MX8QX (QXP, DX).
> > > > >
> > > > > This patch adds the SC firmware service APIs used by the system.
> > > > > It mainly consists of two parts:
> > > > > 1) Implementation of the IPC functions using MUs (client side).
> > > > > 2) SCU firmware services APIs implemented based on RPC calls
> > > > >
> > > > > Cc: Shawn Guo <shawnguo@kernel.org>
> > > > > Cc: Sascha Hauer <kernel@pengutronix.de>
> > > > > Cc: Fabio Estevam <fabio.estevam@nxp.com>
> > > > > Cc: Jassi Brar <jassisinghbrar@gmail.com>
> > > > > Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> > > > > ---
> > > > > +int sc_ipc_open(sc_ipc_t *ipc, struct device *dev) {
> > > > > +	struct sc_ipc *sc_ipc;
> > > > > +	struct sc_chan *sc_chan;
> > > > > +	struct mbox_client *cl;
> > > > > +	char *chan_name;
> > > > > +	int ret;
> > > > > +	int i;
> > > > > +
> > > > > +	sc_ipc = devm_kzalloc(dev, sizeof(*sc_ipc), GFP_KERNEL);
> > > > > +	if (!sc_ipc)
> > > > > +		return -ENOMEM;
> > > > > +
> > > > > +	for (i = 0; i < SCU_MU_CHAN_NUM; i++) {
> > > > > +		if (i < 4)
> > > > > +			chan_name = kasprintf(GFP_KERNEL, "tx%d", i);
> > > > > +		else
> > > > > +			chan_name = kasprintf(GFP_KERNEL, "rx%d", i - 4);
> > > > > +
> > > > > +		if (!chan_name)
> > > > > +			return -ENOMEM;
> > > > > +
> > > > > +		sc_chan = &sc_ipc->chans[i];
> > > > > +		cl = &sc_chan->cl;
> > > > > +		cl->dev = dev;
> > > > > +		cl->tx_block = false;
> > > > > +		cl->knows_txdone = true;
> > > > > +		cl->rx_callback = sc_rx_callback;
> > > > > +
> > > > > +		sc_chan->sc_ipc = sc_ipc;
> > > > > +		sc_chan->idx = i % 4;
> > > > > +		sc_chan->ch = mbox_request_channel_byname(cl, chan_name);
> > > > > +		if (IS_ERR(sc_chan->ch)) {
> > > > > +			ret = PTR_ERR(sc_chan->ch);
> > > > > +			if (ret != -EPROBE_DEFER)
> > > > > +				dev_err(dev, "Failed to get mbox %d\n", ret);
> > > > > +
> > > > > +			return ret;
> > > > > +		}
> > > > > +
> > > > > +		dev_dbg(dev, "mbox request chan %s\n", chan_name);
> > > > > +		/* chan_name is not used anymore by framework */
> > > > > +		kfree(chan_name);
> > > > > +	}
> > > > > +
> > > > > +	sc_ipc->dev = dev;
> > > > > +	mutex_init(&sc_ipc->lock);
> > > > > +	init_completion(&sc_ipc->done);
> > > > > +
> > > > > +	*ipc = (sc_ipc_t)sc_ipc;
> > > > > +
> > > > > +	return 0;
> > > > > +}
> > > > > +EXPORT_SYMBOL(sc_ipc_open);
> > > >
> > > > You export a sc_ipc_open() but it's only ever used once, in your internal
> > code.
> > > > Every other user uses sc_ipc_get_handle() which returns the same
> > > > global handle for every user. In fact, I think sc_ipc_open()
> > > > *can* only be used once, because every other user would get -EBUSY
> > > > when requesting the same mailboxes again.
> > > >
> > > > Please drop all this pseudo resource management nonsense. You simply
> > > > do no resource management. Face it, there is only one global handle
> > > > that is used, don't try to hide it.
> > > >
> > >
> > > The original purpose of this code is that there're 5 MUs can be used
> > > by the system, that means other users can choose to not use the
> > > default SCU MU. So sc_ipc_open() may not be used only once.
> > > e.g.
> > > SCU MU1 sc_ipc_open()
> > > CLK MU1 sc_ipc_get_handle()
> > > Power Domain MU2 sc_ipc_open()
> > > Pinctrl MU3 sc_ipc_open()
> > > and etc...
> > 
> > Your code started by busy polling the MU units until it would send an answer.
> > The communication is completely synchronous and on the SCU side we have a
> > single core cortex M4 processor. Why should we use another SCU channel? I
> > bet the SCU side services the MUs round robin, so changing the MU won't
> > change much.
> 
> I carefully went through our SCU side code, SCU messages are completely handled
> asynchronously by interrupt driven and it does not have to wait for one SCU Message
> to be completed handled before being able to handle the next one.
> 
> The pseudo-code is like:
> Handle_mu_irq()
> {
> 	For (mu = 0; mu < NUM_MU; mu++) {
> 		If (mu_pending()) {
> 			Read(mu); // if available
> 			Handle(mu); //if rx done
> 			Write(mu);
> 		}
> 	}
> 	...
> }
> 
> That means Read and Write process for all MUs channels can be processed sequentially
> within one IRQ, Don't have to wait one of them to be fully completed first.
> 
> For example, the follow could be:
> MU IRQ #0 -> Read MU0 word 0-1 -> Read MU1 word 0-2 -> Read MU2 word 0 -> Exit.
> MU IRQ #1 -> Read MU0 word 2 -> Read MU1 word 3 -> Handle MU1 -> Write MU1
> 		 -> Read MU2 word 1 -> Exit.
> MU IRQ #2 -> Read MU0 word 3 -> Handle MU0 -> Write MU0 -> Read MU2 word 2
> 		 -> Handle MU2 -> Write MU2 -> Exit.
> (Assume MU0 msg size 4, MU1 msg size 4, MU2 msg size 3)
> 
> But if we only support one SCU MU in kernel, then all SCU messages must be handled
> one by one. So it seems like using multiple SCU MUs in kernel are still better than
> using a single one. Am I understand correct?

There's still only one CPU core in the SCU. Why should it be faster when
it does two things at the same time?

Honestly, start simple. Drop the stuff you don't need currently and add
it when you actually can argument *why* you need it and that it improves
something. And when we are there we can discuss how we want to do this
and how proper resource management can be done.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH V5 2/5] soc: imx: add SC firmware IPC and APIs

[A.s. Dong]

> -----Original Message-----
> From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> Sent: Tuesday, September 18, 2018 2:23 PM
> To: A.s. Dong <aisheng.dong@nxp.com>
> Cc: linux-arm-kernel at lists.infradead.org; dongas86 at gmail.com; Jassi Brar
> <jassisinghbrar@gmail.com>; dl-linux-imx <linux-imx@nxp.com>;
> kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> shawnguo at kernel.org
> Subject: Re: [PATCH V5 2/5] soc: imx: add SC firmware IPC and APIs
> 
> On Tue, Sep 11, 2018 at 10:38:52AM +0000, A.s. Dong wrote:
> > Hi Sascha,
> >
> > > -----Original Message-----
> > > From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> > > Sent: Monday, September 10, 2018 8:12 PM
> > > To: A.s. Dong <aisheng.dong@nxp.com>
> > > Cc: linux-arm-kernel at lists.infradead.org; dongas86 at gmail.com; Jassi
> > > Brar <jassisinghbrar@gmail.com>; dl-linux-imx <linux-imx@nxp.com>;
> > > kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> > > shawnguo at kernel.org
> > > Subject: Re: [PATCH V5 2/5] soc: imx: add SC firmware IPC and APIs
> > >
> > > On Mon, Sep 10, 2018 at 09:44:08AM +0000, A.s. Dong wrote:
> > > > > -----Original Message-----
> > > > > From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> > > > > Sent: Monday, September 10, 2018 4:41 PM
> > > > > To: A.s. Dong <aisheng.dong@nxp.com>
> > > > > Cc: linux-arm-kernel at lists.infradead.org; dongas86 at gmail.com;
> > > > > Jassi Brar <jassisinghbrar@gmail.com>; dl-linux-imx
> > > > > <linux-imx@nxp.com>; kernel at pengutronix.de; Fabio Estevam
> > > > > <fabio.estevam@nxp.com>; shawnguo at kernel.org
> > > > > Subject: Re: [PATCH V5 2/5] soc: imx: add SC firmware IPC and
> > > > > APIs
> > > > >
> > > > > On Tue, Aug 21, 2018 at 12:08:22AM +0800, Dong Aisheng wrote:
> > > > > > The System Controller Firmware (SCFW) is a low-level system
> > > > > > function which runs on a dedicated Cortex-M core to provide
> > > > > > power, clock, and resource management. It exists on some i.MX8
> > > > > > processors. e.g. i.MX8QM (QM, QP), and i.MX8QX (QXP, DX).
> > > > > >
> > > > > > This patch adds the SC firmware service APIs used by the system.
> > > > > > It mainly consists of two parts:
> > > > > > 1) Implementation of the IPC functions using MUs (client side).
> > > > > > 2) SCU firmware services APIs implemented based on RPC calls
> > > > > >
> > > > > > Cc: Shawn Guo <shawnguo@kernel.org>
> > > > > > Cc: Sascha Hauer <kernel@pengutronix.de>
> > > > > > Cc: Fabio Estevam <fabio.estevam@nxp.com>
> > > > > > Cc: Jassi Brar <jassisinghbrar@gmail.com>
> > > > > > Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> > > > > > ---
> > > > > > +int sc_ipc_open(sc_ipc_t *ipc, struct device *dev) {
> > > > > > +	struct sc_ipc *sc_ipc;
> > > > > > +	struct sc_chan *sc_chan;
> > > > > > +	struct mbox_client *cl;
> > > > > > +	char *chan_name;
> > > > > > +	int ret;
> > > > > > +	int i;
> > > > > > +
> > > > > > +	sc_ipc = devm_kzalloc(dev, sizeof(*sc_ipc), GFP_KERNEL);
> > > > > > +	if (!sc_ipc)
> > > > > > +		return -ENOMEM;
> > > > > > +
> > > > > > +	for (i = 0; i < SCU_MU_CHAN_NUM; i++) {
> > > > > > +		if (i < 4)
> > > > > > +			chan_name = kasprintf(GFP_KERNEL, "tx%d", i);
> > > > > > +		else
> > > > > > +			chan_name = kasprintf(GFP_KERNEL, "rx%d", i - 4);
> > > > > > +
> > > > > > +		if (!chan_name)
> > > > > > +			return -ENOMEM;
> > > > > > +
> > > > > > +		sc_chan = &sc_ipc->chans[i];
> > > > > > +		cl = &sc_chan->cl;
> > > > > > +		cl->dev = dev;
> > > > > > +		cl->tx_block = false;
> > > > > > +		cl->knows_txdone = true;
> > > > > > +		cl->rx_callback = sc_rx_callback;
> > > > > > +
> > > > > > +		sc_chan->sc_ipc = sc_ipc;
> > > > > > +		sc_chan->idx = i % 4;
> > > > > > +		sc_chan->ch = mbox_request_channel_byname(cl,
> chan_name);
> > > > > > +		if (IS_ERR(sc_chan->ch)) {
> > > > > > +			ret = PTR_ERR(sc_chan->ch);
> > > > > > +			if (ret != -EPROBE_DEFER)
> > > > > > +				dev_err(dev, "Failed to get mbox %d\n", ret);
> > > > > > +
> > > > > > +			return ret;
> > > > > > +		}
> > > > > > +
> > > > > > +		dev_dbg(dev, "mbox request chan %s\n", chan_name);
> > > > > > +		/* chan_name is not used anymore by framework */
> > > > > > +		kfree(chan_name);
> > > > > > +	}
> > > > > > +
> > > > > > +	sc_ipc->dev = dev;
> > > > > > +	mutex_init(&sc_ipc->lock);
> > > > > > +	init_completion(&sc_ipc->done);
> > > > > > +
> > > > > > +	*ipc = (sc_ipc_t)sc_ipc;
> > > > > > +
> > > > > > +	return 0;
> > > > > > +}
> > > > > > +EXPORT_SYMBOL(sc_ipc_open);
> > > > >
> > > > > You export a sc_ipc_open() but it's only ever used once, in your
> > > > > internal
> > > code.
> > > > > Every other user uses sc_ipc_get_handle() which returns the same
> > > > > global handle for every user. In fact, I think sc_ipc_open()
> > > > > *can* only be used once, because every other user would get
> > > > > -EBUSY when requesting the same mailboxes again.
> > > > >
> > > > > Please drop all this pseudo resource management nonsense. You
> > > > > simply do no resource management. Face it, there is only one
> > > > > global handle that is used, don't try to hide it.
> > > > >
> > > >
> > > > The original purpose of this code is that there're 5 MUs can be
> > > > used by the system, that means other users can choose to not use
> > > > the default SCU MU. So sc_ipc_open() may not be used only once.
> > > > e.g.
> > > > SCU MU1 sc_ipc_open()
> > > > CLK MU1 sc_ipc_get_handle()
> > > > Power Domain MU2 sc_ipc_open()
> > > > Pinctrl MU3 sc_ipc_open()
> > > > and etc...
> > >
> > > Your code started by busy polling the MU units until it would send an
> answer.
> > > The communication is completely synchronous and on the SCU side we
> > > have a single core cortex M4 processor. Why should we use another
> > > SCU channel? I bet the SCU side services the MUs round robin, so
> > > changing the MU won't change much.
> >
> > I carefully went through our SCU side code, SCU messages are
> > completely handled asynchronously by interrupt driven and it does not
> > have to wait for one SCU Message to be completed handled before being
> able to handle the next one.
> >
> > The pseudo-code is like:
> > Handle_mu_irq()
> > {
> > 	For (mu = 0; mu < NUM_MU; mu++) {
> > 		If (mu_pending()) {
> > 			Read(mu); // if available
> > 			Handle(mu); //if rx done
> > 			Write(mu);
> > 		}
> > 	}
> > 	...
> > }
> >
> > That means Read and Write process for all MUs channels can be
> > processed sequentially within one IRQ, Don't have to wait one of them to be
> fully completed first.
> >
> > For example, the follow could be:
> > MU IRQ #0 -> Read MU0 word 0-1 -> Read MU1 word 0-2 -> Read MU2 word
> 0 -> Exit.
> > MU IRQ #1 -> Read MU0 word 2 -> Read MU1 word 3 -> Handle MU1 -> Write
> MU1
> > 		 -> Read MU2 word 1 -> Exit.
> > MU IRQ #2 -> Read MU0 word 3 -> Handle MU0 -> Write MU0 -> Read MU2
> word 2
> > 		 -> Handle MU2 -> Write MU2 -> Exit.
> > (Assume MU0 msg size 4, MU1 msg size 4, MU2 msg size 3)
> >
> > But if we only support one SCU MU in kernel, then all SCU messages
> > must be handled one by one. So it seems like using multiple SCU MUs in
> > kernel are still better than using a single one. Am I understand correct?
> 
> There's still only one CPU core in the SCU. Why should it be faster when it does
> two things at the same time?
> 

Not at the same time, but got a chance to handle another thing while waiting for the
former thing to be ready. I already described in above process.
When SCU read MU0, MU0 messages may not be fully ready assume it's a four word
message (depends on A core send speed, actually it may be worse than the initial polling
mode after using 8 separate interrupt driven channels)

> Honestly, start simple. Drop the stuff you don't need currently and add it when
> you actually can argument *why* you need it and that it improves something.
> And when we are there we can discuss how we want to do this and how
> proper resource management can be done.
> 

Okay, it's fine with that. Thanks for the suggestion.
I can then provide some tuning data at that point to help the understanding.

Regards
Dong Aisheng

> Sascha
> 
> --
> Pengutronix e.K.                           |
> |
> Industrial Linux Solutions                 |
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> pengutronix.de%2F&amp;data=02%7C01%7Caisheng.dong%40nxp.com%7C0f
> 743e829180493bc76d08d61d2f2473%7C686ea1d3bc2b4c6fa92cd99c5c3016
> 35%7C0%7C0%7C636728485665858207&amp;sdata=VPLDzUInryAFCok%2Bw
> ZOJ%2BQK6ezqRx4U2DPiaUwz3%2Bl0%3D&amp;reserved=0  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> |
> Amtsgericht Hildesheim, HRA 2686           | Fax:
> +49-5121-206917-5555 |

[PATCH V5 3/5] soc: imx: sc: add pm svc support

[Dong Aisheng]

Add SCU PM SVC support which provides clock gate, rate, parent
set support as well as resource power management.

Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
---
 drivers/soc/imx/sc/Makefile          |   1 +
 drivers/soc/imx/sc/svc/pm/rpc_clnt.c | 275 +++++++++++++++++++++++++++++++++++
 include/soc/imx/sc/sci.h             |   2 +
 include/soc/imx/sc/svc/pm/api.h      | 229 +++++++++++++++++++++++++++++
 4 files changed, 507 insertions(+)
 create mode 100644 drivers/soc/imx/sc/svc/pm/rpc_clnt.c
 create mode 100644 include/soc/imx/sc/svc/pm/api.h

diff --git a/drivers/soc/imx/sc/Makefile b/drivers/soc/imx/sc/Makefile
index a3db142..6898815 100644
--- a/drivers/soc/imx/sc/Makefile
+++ b/drivers/soc/imx/sc/Makefile
@@ -1,2 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-y += main/ipc.o
+obj-y += svc/pm/rpc_clnt.o
diff --git a/drivers/soc/imx/sc/svc/pm/rpc_clnt.c b/drivers/soc/imx/sc/svc/pm/rpc_clnt.c
new file mode 100644
index 0000000..32228fa
--- /dev/null
+++ b/drivers/soc/imx/sc/svc/pm/rpc_clnt.c
@@ -0,0 +1,275 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017~2018 NXP
+ *
+ * File containing client-side RPC functions for the PM service. These
+ * function are ported to clients that communicate to the SC.
+ *
+ */
+
+#include <soc/imx/sc/svc/pm/api.h>
+#include "../../main/rpc.h"
+
+/*
+ * This type is used to indicate RPC PM function calls.
+ */
+enum pm_func_e {
+	PM_FUNC_UNKNOWN = 0,
+	PM_FUNC_SET_SYS_POWER_MODE = 19,
+	PM_FUNC_SET_PARTITION_POWER_MODE = 1,
+	PM_FUNC_GET_SYS_POWER_MODE = 2,
+	PM_FUNC_SET_RESOURCE_POWER_MODE = 3,
+	PM_FUNC_GET_RESOURCE_POWER_MODE = 4,
+	PM_FUNC_REQ_LOW_POWER_MODE = 16,
+	PM_FUNC_SET_CPU_RESUME_ADDR = 17,
+	PM_FUNC_REQ_SYS_IF_POWER_MODE = 18,
+	PM_FUNC_SET_CLOCK_RATE = 5,
+	PM_FUNC_GET_CLOCK_RATE = 6,
+	PM_FUNC_CLOCK_ENABLE = 7,
+	PM_FUNC_SET_CLOCK_PARENT = 14,
+	PM_FUNC_GET_CLOCK_PARENT = 15,
+	PM_FUNC_RESET = 13,
+	PM_FUNC_RESET_REASON = 10,
+	PM_FUNC_BOOT = 8,
+	PM_FUNC_REBOOT = 9,
+	PM_FUNC_REBOOT_PARTITION = 12,
+	PM_FUNC_CPU_START = 11,
+};
+
+struct imx_sc_msg_req_set_resource_power_mode {
+	struct sc_rpc_msg hdr;
+	u16 resource;
+	u8 mode;
+} __packed;
+
+struct imx_sc_msg_req_get_resource_power_mode {
+	struct sc_rpc_msg hdr;
+	u16 resource;
+} __packed;
+
+struct imx_sc_msg_resp_get_resource_power_mode {
+	struct sc_rpc_msg hdr;
+	u8 mode;
+} __packed;
+
+struct imx_sc_msg_req_set_clock_rate {
+	struct sc_rpc_msg hdr;
+	u32 rate;
+	u16 resource;
+	u8 clk;
+} __packed;
+
+struct imx_sc_msg_req_get_clock_rate {
+	struct sc_rpc_msg hdr;
+	u16 resource;
+	u8 clk;
+} __packed;
+
+struct imx_sc_msg_resp_get_clock_rate {
+	struct sc_rpc_msg hdr;
+	u32 rate;
+} __packed;
+
+struct imx_sc_msg_req_clock_enable {
+	struct sc_rpc_msg hdr;
+	u16 resource;
+	u8 clk;
+	u8 enable;
+	u8 autog;
+} __packed;
+
+struct imx_sc_msg_req_set_clock_parent {
+	struct sc_rpc_msg hdr;
+	u16 resource;
+	u8 clk;
+	u8 parent;
+} __packed;
+
+struct imx_sc_msg_req_get_clock_parent {
+	struct sc_rpc_msg hdr;
+	u16 resource;
+	u8 clk;
+} __packed;
+
+struct imx_sc_msg_resp_get_clock_parent {
+	struct sc_rpc_msg hdr;
+	u8 parent;
+} __packed;
+
+sc_err_t sc_pm_set_resource_power_mode(sc_ipc_t ipc, sc_rsrc_t resource,
+				       sc_pm_power_mode_t mode)
+{
+	struct imx_sc_msg_req_set_resource_power_mode msg;
+	struct sc_rpc_msg *hdr = &msg.hdr;
+	int ret;
+
+	hdr->ver = SC_RPC_VERSION;
+	hdr->svc = (uint8_t)SC_RPC_SVC_PM;
+	hdr->func = (uint8_t)PM_FUNC_SET_RESOURCE_POWER_MODE;
+	hdr->size = 2;
+
+	msg.resource = resource;
+	msg.mode = mode;
+
+	ret = sc_call_rpc(ipc, (void *)&msg, false);
+	if (ret)
+		return SC_ERR_FAIL;
+
+	return (sc_err_t)hdr->func;
+}
+
+sc_err_t sc_pm_get_resource_power_mode(sc_ipc_t ipc, sc_rsrc_t resource,
+				       sc_pm_power_mode_t *mode)
+{
+	struct imx_sc_msg_req_get_resource_power_mode msg;
+	struct imx_sc_msg_resp_get_resource_power_mode *resp;
+	struct sc_rpc_msg *hdr = &msg.hdr;
+	int ret;
+
+	hdr->ver = SC_RPC_VERSION;
+	hdr->svc = (uint8_t)SC_RPC_SVC_PM;
+	hdr->func = (uint8_t)PM_FUNC_GET_RESOURCE_POWER_MODE;
+	hdr->size = 2;
+
+	msg.resource = resource;
+
+	ret = sc_call_rpc(ipc, (void *)&msg, false);
+	if (ret)
+		return SC_ERR_FAIL;
+
+	resp = (struct imx_sc_msg_resp_get_resource_power_mode *)&msg;
+	if (mode != NULL)
+		*mode = resp->mode;
+
+	return (sc_err_t)resp->hdr.func;
+}
+
+sc_err_t sc_pm_set_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource,
+			      sc_pm_clk_t clk, sc_pm_clock_rate_t *rate)
+{
+	struct imx_sc_msg_req_set_clock_rate msg;
+	struct imx_sc_msg_resp_get_clock_rate *resp;
+	struct sc_rpc_msg *hdr = &msg.hdr;
+	int ret;
+
+	hdr->ver = SC_RPC_VERSION;
+	hdr->svc = (uint8_t)SC_RPC_SVC_PM;
+	hdr->func = (uint8_t)PM_FUNC_SET_CLOCK_RATE;
+	hdr->size = 3;
+
+	msg.rate = *rate;
+	msg.resource = resource;
+	msg.clk = clk;
+
+	ret = sc_call_rpc(ipc, (void *)&msg, false);
+	if (ret)
+		return SC_ERR_FAIL;
+
+	resp = (struct imx_sc_msg_resp_get_clock_rate *)&msg;
+	if (rate != NULL)
+		*rate = resp->rate;
+
+	return (sc_err_t)resp->hdr.func;
+}
+
+sc_err_t sc_pm_get_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource,
+			      sc_pm_clk_t clk, sc_pm_clock_rate_t *rate)
+{
+	struct imx_sc_msg_req_get_clock_rate msg;
+	struct imx_sc_msg_resp_get_clock_rate *resp;
+	struct sc_rpc_msg *hdr = &msg.hdr;
+	int ret;
+
+	hdr->ver = SC_RPC_VERSION;
+	hdr->svc = (uint8_t)SC_RPC_SVC_PM;
+	hdr->func = (uint8_t)PM_FUNC_GET_CLOCK_RATE;
+	hdr->size = 2;
+
+	msg.resource = resource;
+	msg.clk = clk;
+
+	ret = sc_call_rpc(ipc, (void *)&msg, false);
+	if (ret)
+		return SC_ERR_FAIL;
+
+	resp = (struct imx_sc_msg_resp_get_clock_rate *)&msg;
+	if (rate != NULL)
+		*rate = resp->rate;
+
+	return (sc_err_t)resp->hdr.func;
+}
+
+sc_err_t sc_pm_clock_enable(sc_ipc_t ipc, sc_rsrc_t resource,
+			    sc_pm_clk_t clk, bool enable, bool autog)
+{
+	struct imx_sc_msg_req_clock_enable msg;
+	struct sc_rpc_msg *hdr = &msg.hdr;
+	int ret;
+
+	hdr->ver = SC_RPC_VERSION;
+	hdr->svc = (uint8_t)SC_RPC_SVC_PM;
+	hdr->func = (uint8_t)PM_FUNC_CLOCK_ENABLE;
+	hdr->size = 3;
+
+	msg.resource = resource;
+	msg.clk = clk;
+	msg.enable = (uint8_t)enable;
+	msg.autog = (uint8_t)autog;
+
+	ret = sc_call_rpc(ipc, (void *)&msg, false);
+	if (ret)
+		return SC_ERR_FAIL;
+
+	return (sc_err_t)hdr->func;
+}
+
+sc_err_t sc_pm_set_clock_parent(sc_ipc_t ipc, sc_rsrc_t resource,
+				sc_pm_clk_t clk, sc_pm_clk_parent_t parent)
+{
+	struct imx_sc_msg_req_set_clock_parent msg;
+	struct sc_rpc_msg *hdr = &msg.hdr;
+	int ret;
+
+	hdr->ver = SC_RPC_VERSION;
+	hdr->svc = (uint8_t)SC_RPC_SVC_PM;
+	hdr->func = (uint8_t)PM_FUNC_SET_CLOCK_PARENT;
+	hdr->size = 2;
+
+	msg.resource = resource;
+	msg.clk = clk;
+	msg.parent = parent;
+
+	ret = sc_call_rpc(ipc, (void *)&msg, false);
+	if (ret)
+		return SC_ERR_FAIL;
+
+	return (sc_err_t)hdr->func;
+}
+
+sc_err_t sc_pm_get_clock_parent(sc_ipc_t ipc, sc_rsrc_t resource,
+				sc_pm_clk_t clk, sc_pm_clk_parent_t *parent)
+{
+	struct imx_sc_msg_req_get_clock_parent msg;
+	struct imx_sc_msg_resp_get_clock_parent *resp;
+	struct sc_rpc_msg *hdr = &msg.hdr;
+	int ret;
+
+	hdr->ver = SC_RPC_VERSION;
+	hdr->svc = (uint8_t)SC_RPC_SVC_PM;
+	hdr->func = (uint8_t)PM_FUNC_GET_CLOCK_PARENT;
+	hdr->size = 2;
+
+	msg.resource = resource;
+	msg.clk = clk;
+
+	ret = sc_call_rpc(ipc, (void *)&msg, false);
+	if (ret)
+		return SC_ERR_FAIL;
+
+	resp = (struct imx_sc_msg_resp_get_clock_parent *)&msg;
+	if (parent != NULL)
+		*parent = resp->parent;
+
+	return (sc_err_t)resp->hdr.func;
+}
diff --git a/include/soc/imx/sc/sci.h b/include/soc/imx/sc/sci.h
index de3892a..b7248cf 100644
--- a/include/soc/imx/sc/sci.h
+++ b/include/soc/imx/sc/sci.h
@@ -13,4 +13,6 @@
 #include <soc/imx/sc/ipc.h>
 #include <soc/imx/sc/types.h>
 
+#include <soc/imx/sc/svc/pm/api.h>
+
 #endif /* _SC_SCI_H */
diff --git a/include/soc/imx/sc/svc/pm/api.h b/include/soc/imx/sc/svc/pm/api.h
new file mode 100644
index 0000000..2a9e4b9
--- /dev/null
+++ b/include/soc/imx/sc/svc/pm/api.h
@@ -0,0 +1,229 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017~2018 NXP
+ *
+ * Header file containing the public API for the System Controller (SC)
+ * Power Management (PM) function. This includes functions for power state
+ * control, clock control, reset control, and wake-up event control.
+ *
+ * PM_SVC (SVC) Power Management Service
+ *
+ * Module for the Power Management (PM) service.
+ */
+
+#ifndef _SC_PM_API_H
+#define _SC_PM_API_H
+
+#include <soc/imx/sc/ipc.h>
+#include <soc/imx/sc/types.h>
+
+/*
+ * Defines for ALL parameters
+ */
+#define SC_PM_CLK_ALL   UINT8_MAX	/* All clocks */
+
+/*
+ * Defines for sc_pm_power_mode_t
+ */
+#define SC_PM_PW_MODE_OFF	0	/* Power off */
+#define SC_PM_PW_MODE_STBY	1	/* Power in standby */
+#define SC_PM_PW_MODE_LP	2	/* Power in low-power */
+#define SC_PM_PW_MODE_ON	3	/* Power on */
+
+/*
+ * Defines for sc_pm_clk_t
+ */
+#define SC_PM_CLK_SLV_BUS	0	/* Slave bus clock */
+#define SC_PM_CLK_MST_BUS	1	/* Master bus clock */
+#define SC_PM_CLK_PER		2	/* Peripheral clock */
+#define SC_PM_CLK_PHY		3	/* Phy clock */
+#define SC_PM_CLK_MISC		4	/* Misc clock */
+#define SC_PM_CLK_MISC0		0	/* Misc 0 clock */
+#define SC_PM_CLK_MISC1		1	/* Misc 1 clock */
+#define SC_PM_CLK_MISC2		2	/* Misc 2 clock */
+#define SC_PM_CLK_MISC3		3	/* Misc 3 clock */
+#define SC_PM_CLK_MISC4		4	/* Misc 4 clock */
+#define SC_PM_CLK_CPU		2	/* CPU clock */
+#define SC_PM_CLK_PLL		4	/* PLL */
+#define SC_PM_CLK_BYPASS	4	/* Bypass clock */
+
+/*
+ * Defines for sc_pm_clk_parent_t
+ */
+#define SC_PM_PARENT_XTAL	0	/* Parent is XTAL. */
+#define SC_PM_PARENT_PLL0	1	/* Parent is PLL0 */
+#define SC_PM_PARENT_PLL1	2	/* Parent is PLL1 or PLL0/2 */
+#define SC_PM_PARENT_PLL2	3	/* Parent in PLL2 or PLL0/4 */
+#define SC_PM_PARENT_BYPS	4	/* Parent is a bypass clock. */
+
+/*
+ * This type is used to declare a power mode. Note resources only use
+ * SC_PM_PW_MODE_OFF and SC_PM_PW_MODE_ON. The other modes are used only
+ * as system power modes.
+ */
+typedef uint8_t sc_pm_power_mode_t;
+
+/*
+ * This type is used to declare a clock.
+ */
+typedef uint8_t sc_pm_clk_t;
+
+/*
+ * This type is used to declare the clock parent.
+ */
+typedef uint8_t sc_pm_clk_parent_t;
+
+/*
+ * This type is used to declare clock rates.
+ */
+typedef uint32_t sc_pm_clock_rate_t;
+
+/*
+ * Power Functions
+ */
+
+/*
+ * This function sets the power mode of a resource.
+ *
+ * @param [in]	ipc		IPC handle
+ * @param [in]	resource	ID of the resource
+ * @param [in]	mode		power mode to apply
+ *
+ * @return Returns an error code (SC_ERR_NONE = success).
+ *
+ * Return errors:
+ * - SC_ERR_PARM if invalid resource or mode,
+ * - SC_ERR_NOACCESS if caller's partition is not the resource owner
+ *   or parent of the owner
+ *
+ * Resources set to SC_PM_PW_MODE_ON will reflect the
+ * power mode of the partition and will change as that changes.
+ *
+ * Note some resources are still not accessible even when powered up if bus
+ * transactions go through a fabric not powered up. Examples of this are
+ * resources in display and capture subsystems which require the display
+ * controller or the imaging subsytem to be powered up first.
+ */
+sc_err_t sc_pm_set_resource_power_mode(sc_ipc_t ipc, sc_rsrc_t resource,
+				       sc_pm_power_mode_t mode);
+
+/*
+ * This function gets the power mode of a resource.
+ *
+ * @param [in]	ipc		IPC handle
+ * @param [in]	resource	ID of the resource
+ * @param [out]	mode		pointer to return power mode
+ *
+ * @return Returns an error code (SC_ERR_NONE = success).
+ *
+ * Note only SC_PM_PW_MODE_OFF and SC_PM_PW_MODE_ON are valid. The value
+ * returned does not reflect the power mode of the partition..
+ */
+sc_err_t sc_pm_get_resource_power_mode(sc_ipc_t ipc, sc_rsrc_t resource,
+				       sc_pm_power_mode_t *mode);
+
+/*
+ * Clock/PLL Functions
+ */
+
+/*
+ * This function sets the rate of a resource's clock/PLL.
+ *
+ * @param [in]		ipc		IPC handle
+ * @param [in]		resource	ID of the resource
+ * @param [in]		clk		clock/PLL to affect
+ * @param [in,out]	rate		pointer to rate to set,
+ *					return actual rate
+ * @return Returns an error code (SC_ERR_NONE = success).
+ *
+ * Return errors:
+ * - SC_ERR_PARM if invalid resource or clock/PLL,
+ * - SC_ERR_NOACCESS if caller's partition is not the resource owner
+ *   or parent of the owner,
+ * - SC_ERR_UNAVAILABLE if clock/PLL not applicable to this resource,
+ * - SC_ERR_LOCKED if rate locked (usually because shared clock/PLL)
+ */
+sc_err_t sc_pm_set_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource,
+			      sc_pm_clk_t clk, sc_pm_clock_rate_t *rate);
+
+/*
+ * This function gets the rate of a resource's clock/PLL.
+ *
+ * @param [in]	ipc		IPC handle
+ * @param [in]	resource	ID of the resource
+ * @param [in]	clk		clock/PLL to affect
+ * @param [out]	rate		pointer to return rate
+ *
+ * @return Returns an error code (SC_ERR_NONE = success).
+ *
+ * Return errors:
+ * - SC_ERR_PARM if invalid resource or clock/PLL,
+ * - SC_ERR_NOACCESS if caller's partition is not the resource owner
+ *   or parent of the owner,
+ * - SC_ERR_UNAVAILABLE if clock/PLL not applicable to this resource
+ */
+sc_err_t sc_pm_get_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource,
+			      sc_pm_clk_t clk, sc_pm_clock_rate_t *rate);
+
+/*
+ * This function enables/disables a resource's clock.
+ *
+ * @param [in]	ipc		IPC handle
+ * @param [in]	resource	ID of the resource
+ * @param [in]	clk		clock to affect
+ * @param [in]	enable		enable if true; otherwise disabled
+ * @param [in]	autog		HW auto clock gating
+ *
+ * @return Returns an error code (SC_ERR_NONE = success).
+ *
+ * Return errors:
+ * - SC_ERR_PARM if invalid resource or clock,
+ * - SC_ERR_NOACCESS if caller's partition is not the resource owner
+ *   or parent of the owner,
+ * - SC_ERR_UNAVAILABLE if clock not applicable to this resource
+ */
+sc_err_t sc_pm_clock_enable(sc_ipc_t ipc, sc_rsrc_t resource,
+			    sc_pm_clk_t clk, bool enable, bool autog);
+
+/*
+ * This function sets the parent of a resource's clock.
+ * This function should only be called when the clock is disabled.
+ *
+ * @param [in]	ipc		IPC handle
+ * @param [in]	resource	ID of the resource
+ * @param [in]	clk		clock to affect
+ * @param [in]	parent		New parent of the clock.
+ *
+ * @return Returns an error code (SC_ERR_NONE = success).
+ *
+ * Return errors:
+ * - SC_ERR_PARM if invalid resource or clock,
+ * - SC_ERR_NOACCESS if caller's partition is not the resource owner
+ *   or parent of the owner,
+ * - SC_ERR_UNAVAILABLE if clock not applicable to this resource
+ * - SC_ERR_BUSY if clock is currently enabled.
+ */
+sc_err_t sc_pm_set_clock_parent(sc_ipc_t ipc, sc_rsrc_t resource,
+				sc_pm_clk_t clk, sc_pm_clk_parent_t parent);
+
+/*
+ * This function gets the parent of a resource's clock.
+ *
+ * @param [in]	ipc		IPC handle
+ * @param [in]	resource	ID of the resource
+ * @param [in]	clk		clock to affect
+ * @param [out]	parent		pointer to return parent of clock.
+ *
+ * @return Returns an error code (SC_ERR_NONE = success).
+ *
+ * Return errors:
+ * - SC_ERR_PARM if invalid resource or clock,
+ * - SC_ERR_NOACCESS if caller's partition is not the resource owner
+ *   or parent of the owner,
+ * - SC_ERR_UNAVAILABLE if clock not applicable to this resource
+ */
+sc_err_t sc_pm_get_clock_parent(sc_ipc_t ipc, sc_rsrc_t resource,
+				sc_pm_clk_t clk, sc_pm_clk_parent_t *parent);
+
+#endif /* _SC_PM_API_H */
-- 
2.7.4

[PATCH V5 4/5] soc: imx: sc: add pad svc support

[Dong Aisheng]

Add SCU PAD SVC support which provides pad get/set functions.

Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
---
 drivers/soc/imx/sc/Makefile           |  1 +
 drivers/soc/imx/sc/svc/pad/rpc_clnt.c | 82 +++++++++++++++++++++++++++++++++++
 include/soc/imx/sc/sci.h              |  1 +
 include/soc/imx/sc/svc/pad/api.h      | 60 +++++++++++++++++++++++++
 4 files changed, 144 insertions(+)
 create mode 100644 drivers/soc/imx/sc/svc/pad/rpc_clnt.c
 create mode 100644 include/soc/imx/sc/svc/pad/api.h

diff --git a/drivers/soc/imx/sc/Makefile b/drivers/soc/imx/sc/Makefile
index 6898815..3a709b2 100644
--- a/drivers/soc/imx/sc/Makefile
+++ b/drivers/soc/imx/sc/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-y += main/ipc.o
+obj-y += svc/pad/rpc_clnt.o
 obj-y += svc/pm/rpc_clnt.o
diff --git a/drivers/soc/imx/sc/svc/pad/rpc_clnt.c b/drivers/soc/imx/sc/svc/pad/rpc_clnt.c
new file mode 100644
index 0000000..f300aef
--- /dev/null
+++ b/drivers/soc/imx/sc/svc/pad/rpc_clnt.c
@@ -0,0 +1,82 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017~2018 NXP
+ *
+ * File containing client-side RPC functions for the PAD service. These
+ * function are ported to clients that communicate to the SC.
+ *
+ */
+
+#include <soc/imx/sc/svc/pad/api.h>
+#include "../../main/rpc.h"
+
+/*
+ * This type is used to indicate RPC PAD function calls.
+ */
+enum pad_func_e {
+	PAD_FUNC_SET = 15,
+	PAD_FUNC_GET = 16,
+};
+
+struct imx_sc_msg_req_pad_set {
+	struct sc_rpc_msg hdr;
+	u32 val;
+	u16 pad;
+} __packed;
+
+struct imx_sc_msg_req_pad_get {
+	struct sc_rpc_msg hdr;
+	u16 pad;
+} __packed;
+
+struct imx_sc_msg_resp_pad_get {
+	struct sc_rpc_msg hdr;
+	u32 val;
+} __packed;
+
+sc_err_t sc_pad_set(sc_ipc_t ipc, sc_pad_t pad, uint32_t val)
+{
+	struct imx_sc_msg_req_pad_set msg;
+	struct sc_rpc_msg *hdr = &msg.hdr;
+	int ret;
+
+	hdr->ver = SC_RPC_VERSION;
+	hdr->svc = (uint8_t)SC_RPC_SVC_PAD;
+	hdr->func = (uint8_t)PAD_FUNC_SET;
+	hdr->size = 3;
+
+	msg.val = val;
+	msg.pad = pad;
+
+	ret = sc_call_rpc(ipc, (void *)&msg, false);
+	if (ret)
+		return SC_ERR_FAIL;
+
+	return (sc_err_t)hdr->func;
+}
+
+sc_err_t sc_pad_get(sc_ipc_t ipc, sc_pad_t pad, uint32_t *val)
+{
+	struct imx_sc_msg_req_pad_get msg;
+	struct imx_sc_msg_resp_pad_get *resp;
+	struct sc_rpc_msg *hdr = &msg.hdr;
+	int ret;
+
+	hdr->ver = SC_RPC_VERSION;
+	hdr->svc = (uint8_t)SC_RPC_SVC_PAD;
+	hdr->func = (uint8_t)PAD_FUNC_GET;
+	hdr->size = 2;
+
+	msg.pad = pad;
+
+	ret = sc_call_rpc(ipc, (void *)&msg, false);
+	if (ret)
+		return SC_ERR_FAIL;
+
+	resp = (struct imx_sc_msg_resp_pad_get *)&msg;
+	if (val != NULL)
+		*val = resp->val;
+
+	return (sc_err_t)resp->hdr.func;
+}
diff --git a/include/soc/imx/sc/sci.h b/include/soc/imx/sc/sci.h
index b7248cf..2407890 100644
--- a/include/soc/imx/sc/sci.h
+++ b/include/soc/imx/sc/sci.h
@@ -13,6 +13,7 @@
 #include <soc/imx/sc/ipc.h>
 #include <soc/imx/sc/types.h>
 
+#include <soc/imx/sc/svc/pad/api.h>
 #include <soc/imx/sc/svc/pm/api.h>
 
 #endif /* _SC_SCI_H */
diff --git a/include/soc/imx/sc/svc/pad/api.h b/include/soc/imx/sc/svc/pad/api.h
new file mode 100644
index 0000000..d7d80b6
--- /dev/null
+++ b/include/soc/imx/sc/svc/pad/api.h
@@ -0,0 +1,60 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017~2018 NXP
+ *
+ * Header file containing the public API for the System Controller (SC)
+ * Pad Control (PAD) function.
+ *
+ * PAD_SVC (SVC) Pad Service
+ *
+ * Module for the Pad Control (PAD) service.
+ *
+ */
+
+#ifndef _SC_PAD_API_H
+#define _SC_PAD_API_H
+
+#include <soc/imx/sc/ipc.h>
+#include <soc/imx/sc/types.h>
+
+/*
+ * This type is used to indicate a pad. Valid values are SoC specific.
+ *
+ * Refer to the SoC [Pad List](@ref PADS) for valid pad values.
+ */
+typedef uint16_t sc_pad_t;
+
+/*
+ * This function configures the settings for a pad. This setting is SoC
+ * specific.
+ *
+ * @param [in]	ipc	IPC handle
+ * @param [in]	pad	pad to configure
+ * @param [in]	val	value to set
+ *
+ * @return Returns an error code (SC_ERR_NONE = success).
+ *
+ * Return errors:
+ * - SC_PARM if arguments out of range or invalid,
+ * - SC_ERR_NOACCESS if caller's partition is not the pad owner
+ */
+sc_err_t sc_pad_set(sc_ipc_t ipc, sc_pad_t pad, uint32_t val);
+
+/*
+ * This function gets the settings for a pad. This setting is SoC
+ * specific.
+ *
+ * @param [in]	ipc	IPC handle
+ * @param [in]	pad	pad to query
+ * @param [out]	val	pointer to return setting
+ *
+ * @return Returns an error code (SC_ERR_NONE = success).
+ *
+ * Return errors:
+ * - SC_PARM if arguments out of range or invalid,
+ * - SC_ERR_NOACCESS if caller's partition is not the pad owner
+ */
+sc_err_t sc_pad_get(sc_ipc_t ipc, sc_pad_t pad, uint32_t *val);
+
+#endif /* _SC_PAD_API_H */
-- 
2.7.4

[PATCH V5 5/5] soc: imx: sc: add misc svc support

[Dong Aisheng]

Add SCU MISC SVC support which provides misc control get/set functions.

Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
---
 drivers/soc/imx/sc/Makefile            |   1 +
 drivers/soc/imx/sc/svc/misc/rpc_clnt.c | 106 +++++++++++++++++++++++++++++++++
 include/soc/imx/sc/sci.h               |   1 +
 include/soc/imx/sc/svc/misc/api.h      |  60 +++++++++++++++++++
 4 files changed, 168 insertions(+)
 create mode 100644 drivers/soc/imx/sc/svc/misc/rpc_clnt.c
 create mode 100644 include/soc/imx/sc/svc/misc/api.h

diff --git a/drivers/soc/imx/sc/Makefile b/drivers/soc/imx/sc/Makefile
index 3a709b2..6a3159f 100644
--- a/drivers/soc/imx/sc/Makefile
+++ b/drivers/soc/imx/sc/Makefile
@@ -1,4 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-y += main/ipc.o
+obj-y += svc/misc/rpc_clnt.o
 obj-y += svc/pad/rpc_clnt.o
 obj-y += svc/pm/rpc_clnt.o
diff --git a/drivers/soc/imx/sc/svc/misc/rpc_clnt.c b/drivers/soc/imx/sc/svc/misc/rpc_clnt.c
new file mode 100644
index 0000000..810a0ad
--- /dev/null
+++ b/drivers/soc/imx/sc/svc/misc/rpc_clnt.c
@@ -0,0 +1,106 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017~2018 NXP
+ *
+ * File containing client-side RPC functions for the MISC service. These
+ * function are ported to clients that communicate to the SC.
+ *
+ */
+
+#include <soc/imx/sc/svc/misc/api.h>
+#include "../../main/rpc.h"
+
+/*
+ * This type is used to indicate RPC MISC function calls.
+ */
+enum misc_func_e {
+	MISC_FUNC_UNKNOWN = 0,
+	MISC_FUNC_SET_CONTROL = 1,
+	MISC_FUNC_GET_CONTROL = 2,
+	MISC_FUNC_SET_MAX_DMA_GROUP = 4,
+	MISC_FUNC_SET_DMA_GROUP = 5,
+	MISC_FUNC_SECO_IMAGE_LOAD = 8,
+	MISC_FUNC_SECO_AUTHENTICATE = 9,
+	MISC_FUNC_DEBUG_OUT = 10,
+	MISC_FUNC_WAVEFORM_CAPTURE = 6,
+	MISC_FUNC_BUILD_INFO = 15,
+	MISC_FUNC_UNIQUE_ID = 19,
+	MISC_FUNC_SET_ARI = 3,
+	MISC_FUNC_BOOT_STATUS = 7,
+	MISC_FUNC_BOOT_DONE = 14,
+	MISC_FUNC_OTP_FUSE_READ = 11,
+	MISC_FUNC_OTP_FUSE_WRITE = 17,
+	MISC_FUNC_SET_TEMP = 12,
+	MISC_FUNC_GET_TEMP = 13,
+	MISC_FUNC_GET_BOOT_DEV = 16,
+	MISC_FUNC_GET_BUTTON_STATUS = 18,
+};
+
+struct imx_sc_msg_req_misc_set_ctrl {
+	struct sc_rpc_msg hdr;
+	u32 ctrl;
+	u32 val;
+	u16 resource;
+} __packed;
+
+struct imx_sc_msg_req_misc_get_ctrl {
+	struct sc_rpc_msg hdr;
+	u32 ctrl;
+	u16 resource;
+} __packed;
+
+struct imx_sc_msg_resp_misc_get_ctrl {
+	struct sc_rpc_msg hdr;
+	u32 val;
+} __packed;
+
+sc_err_t sc_misc_set_control(sc_ipc_t ipc, sc_rsrc_t resource,
+			     sc_ctrl_t ctrl, uint32_t val)
+{
+	struct imx_sc_msg_req_misc_set_ctrl msg;
+	struct sc_rpc_msg *hdr = &msg.hdr;
+	int ret;
+
+	hdr->ver = SC_RPC_VERSION;
+	hdr->svc = (uint8_t)SC_RPC_SVC_MISC;
+	hdr->func = (uint8_t)MISC_FUNC_SET_CONTROL;
+	hdr->size = 4;
+
+	msg.ctrl = ctrl;
+	msg.val = val;
+	msg.resource = resource;
+
+	ret = sc_call_rpc(ipc, (void *)&msg, false);
+	if (ret)
+		return SC_ERR_FAIL;
+
+	return (sc_err_t)hdr->func;
+}
+
+sc_err_t sc_misc_get_control(sc_ipc_t ipc, sc_rsrc_t resource,
+			     sc_ctrl_t ctrl, uint32_t *val)
+{
+	struct imx_sc_msg_req_misc_get_ctrl msg;
+	struct imx_sc_msg_resp_misc_get_ctrl *resp;
+	struct sc_rpc_msg *hdr = &msg.hdr;
+	int ret;
+
+	hdr->ver = SC_RPC_VERSION;
+	hdr->svc = (uint8_t)SC_RPC_SVC_MISC;
+	hdr->func = (uint8_t)MISC_FUNC_GET_CONTROL;
+	hdr->size = 3;
+
+	msg.ctrl = ctrl;
+	msg.resource = resource;
+
+	ret = sc_call_rpc(ipc, (void *)&msg, false);
+	if (ret)
+		return SC_ERR_FAIL;
+
+	resp = (struct imx_sc_msg_resp_misc_get_ctrl *)&msg;
+	if (val != NULL)
+		*val = resp->val;
+
+	return (sc_err_t)resp->hdr.func;
+}
diff --git a/include/soc/imx/sc/sci.h b/include/soc/imx/sc/sci.h
index 2407890..867b9c5 100644
--- a/include/soc/imx/sc/sci.h
+++ b/include/soc/imx/sc/sci.h
@@ -13,6 +13,7 @@
 #include <soc/imx/sc/ipc.h>
 #include <soc/imx/sc/types.h>
 
+#include <soc/imx/sc/svc/misc/api.h>
 #include <soc/imx/sc/svc/pad/api.h>
 #include <soc/imx/sc/svc/pm/api.h>
 
diff --git a/include/soc/imx/sc/svc/misc/api.h b/include/soc/imx/sc/svc/misc/api.h
new file mode 100644
index 0000000..e217f4c
--- /dev/null
+++ b/include/soc/imx/sc/svc/misc/api.h
@@ -0,0 +1,60 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017~2018 NXP
+ *
+ * Header file containing the public API for the System Controller (SC)
+ * Miscellaneous (MISC) function.
+ *
+ * MISC_SVC (SVC) Miscellaneous Service
+ *
+ * Module for the Miscellaneous (MISC) service.
+ */
+
+#ifndef _SC_MISC_API_H
+#define _SC_MISC_API_H
+
+#include <soc/imx/sc/ipc.h>
+#include <soc/imx/sc/types.h>
+
+/*
+ * Control Functions
+ */
+
+/*
+ * This function sets a miscellaneous control value.
+ *
+ * @param[in]     ipc         IPC handle
+ * @param[in]     resource    resource the control is associated with
+ * @param[in]     ctrl        control to change
+ * @param[in]     val         value to apply to the control
+ *
+ * @return Returns an error code (SC_ERR_NONE = success).
+ *
+ * Return errors:
+ * - SC_PARM if arguments out of range or invalid,
+ * - SC_ERR_NOACCESS if caller's partition is not the resource owner or parent
+ *   of the owner
+ */
+sc_err_t sc_misc_set_control(sc_ipc_t ipc, sc_rsrc_t resource,
+			     sc_ctrl_t ctrl, uint32_t val);
+
+/*
+ * This function gets a miscellaneous control value.
+ *
+ * @param[in]     ipc         IPC handle
+ * @param[in]     resource    resource the control is associated with
+ * @param[in]     ctrl        control to get
+ * @param[out]    val         pointer to return the control value
+ *
+ * @return Returns an error code (SC_ERR_NONE = success).
+ *
+ * Return errors:
+ * - SC_PARM if arguments out of range or invalid,
+ * - SC_ERR_NOACCESS if caller's partition is not the resource owner or parent
+ *   of the owner
+ */
+sc_err_t sc_misc_get_control(sc_ipc_t ipc, sc_rsrc_t resource,
+			     sc_ctrl_t ctrl, uint32_t *val);
+
+#endif /* _SC_MISC_API_H */
-- 
2.7.4

[PATCH V5 0/5] soc: imx: add scu firmware api support

[A.s. Dong]

Hi Jassi & Sascha,

Would you help review this new version patch series?

It's changed to generic MU driver using 8 separately MU channels
according to Jassi's suggestion.
Please help check if this is okay to you.

Regards
Dong Aisheng

> -----Original Message-----
> From: A.s. Dong
> Sent: Tuesday, August 21, 2018 12:08 AM
> To: linux-arm-kernel at lists.infradead.org
> Cc: dongas86 at gmail.com; kernel at pengutronix.de; shawnguo at kernel.org;
> Fabio Estevam <fabio.estevam@nxp.com>; dl-linux-imx <linux-
> imx at nxp.com>; A.s. Dong <aisheng.dong@nxp.com>
> Subject: [PATCH V5 0/5] soc: imx: add scu firmware api support
> 
> Unlike the former i.MX Architectures, the new generation i.MX8 SoCs (e.g.
> MX8QXP and MX8QM) contain a system controller which runs on a dedicated
> Cortex-M core to provide power, clock, Pad, and resource management.
> Communication between the host processor running an OS and the system
> controller happens through a SCU protocol.
> This patchset adds the SCU APIs which is implemented based on MU and will
> be used by different system components.
> 
> It mainly consists of below parts:
> 1) SCU IPC
>    Basic IPC mechanism implemention based on mailbox which is used
>    for communication between AP and SCU firmware.
> 2) SCU IPC Service API
> 
> Dong Aisheng (5):
>   dt-bindings: arm: fsl: add scu binding doc
>   soc: imx: add SC firmware IPC and APIs
>   soc: imx: sc: add pm svc support
>   soc: imx: sc: add pad svc support
>   soc: imx: sc: add misc svc support
> 
>  .../devicetree/bindings/arm/freescale/fsl,scu.txt  | 179 ++++++
>  drivers/soc/imx/Kconfig                            |   4 +
>  drivers/soc/imx/Makefile                           |   1 +
>  drivers/soc/imx/sc/Makefile                        |   5 +
>  drivers/soc/imx/sc/main/ipc.c                      | 258 +++++++++
>  drivers/soc/imx/sc/main/rpc.h                      |  51 ++
>  drivers/soc/imx/sc/svc/misc/rpc_clnt.c             | 106 ++++
>  drivers/soc/imx/sc/svc/pad/rpc_clnt.c              |  82 +++
>  drivers/soc/imx/sc/svc/pm/rpc_clnt.c               | 275 +++++++++
>  include/soc/imx/sc/ipc.h                           |  46 ++
>  include/soc/imx/sc/sci.h                           |  20 +
>  include/soc/imx/sc/svc/misc/api.h                  |  60 ++
>  include/soc/imx/sc/svc/pad/api.h                   |  60 ++
>  include/soc/imx/sc/svc/pm/api.h                    | 229 ++++++++
>  include/soc/imx/sc/types.h                         | 636 +++++++++++++++++++++
>  15 files changed, 2012 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
>  create mode 100644 drivers/soc/imx/sc/Makefile  create mode 100644
> drivers/soc/imx/sc/main/ipc.c  create mode 100644
> drivers/soc/imx/sc/main/rpc.h  create mode 100644
> drivers/soc/imx/sc/svc/misc/rpc_clnt.c
>  create mode 100644 drivers/soc/imx/sc/svc/pad/rpc_clnt.c
>  create mode 100644 drivers/soc/imx/sc/svc/pm/rpc_clnt.c
>  create mode 100644 include/soc/imx/sc/ipc.h  create mode 100644
> include/soc/imx/sc/sci.h  create mode 100644
> include/soc/imx/sc/svc/misc/api.h  create mode 100644
> include/soc/imx/sc/svc/pad/api.h  create mode 100644
> include/soc/imx/sc/svc/pm/api.h  create mode 100644
> include/soc/imx/sc/types.h
> 
> --
> 2.7.4

[PATCH V5 0/5] soc: imx: add scu firmware api support

[A.s. Dong]

Hi Jassi & Sasha,

Do you have some suggestions about this patch series?

Regards
Dong Aisheng

> -----Original Message-----
> From: A.s. Dong
> Sent: Tuesday, August 21, 2018 12:32 AM
> To: Jassi Brar <jassisinghbrar@gmail.com>; Sascha Hauer
> <s.hauer@pengutronix.de>
> Cc: dongas86 at gmail.com; kernel at pengutronix.de; shawnguo at kernel.org;
> Fabio Estevam <fabio.estevam@nxp.com>; dl-linux-imx <linux-imx@nxp.com>;
> linux-arm-kernel at lists.infradead.org
> Subject: RE: [PATCH V5 0/5] soc: imx: add scu firmware api support
> 
> Hi Jassi & Sascha,
> 
> Would you help review this new version patch series?
> 
> It's changed to generic MU driver using 8 separately MU channels according to
> Jassi's suggestion.
> Please help check if this is okay to you.
> 
> Regards
> Dong Aisheng
> 
> > -----Original Message-----
> > From: A.s. Dong
> > Sent: Tuesday, August 21, 2018 12:08 AM
> > To: linux-arm-kernel at lists.infradead.org
> > Cc: dongas86 at gmail.com; kernel at pengutronix.de; shawnguo at kernel.org;
> > Fabio Estevam <fabio.estevam@nxp.com>; dl-linux-imx <linux-
> > imx at nxp.com>; A.s. Dong <aisheng.dong@nxp.com>
> > Subject: [PATCH V5 0/5] soc: imx: add scu firmware api support
> >
> > Unlike the former i.MX Architectures, the new generation i.MX8 SoCs (e.g.
> > MX8QXP and MX8QM) contain a system controller which runs on a
> > dedicated Cortex-M core to provide power, clock, Pad, and resource
> management.
> > Communication between the host processor running an OS and the system
> > controller happens through a SCU protocol.
> > This patchset adds the SCU APIs which is implemented based on MU and
> > will be used by different system components.
> >
> > It mainly consists of below parts:
> > 1) SCU IPC
> >    Basic IPC mechanism implemention based on mailbox which is used
> >    for communication between AP and SCU firmware.
> > 2) SCU IPC Service API
> >
> > Dong Aisheng (5):
> >   dt-bindings: arm: fsl: add scu binding doc
> >   soc: imx: add SC firmware IPC and APIs
> >   soc: imx: sc: add pm svc support
> >   soc: imx: sc: add pad svc support
> >   soc: imx: sc: add misc svc support
> >
> >  .../devicetree/bindings/arm/freescale/fsl,scu.txt  | 179 ++++++
> >  drivers/soc/imx/Kconfig                            |   4 +
> >  drivers/soc/imx/Makefile                           |   1 +
> >  drivers/soc/imx/sc/Makefile                        |   5 +
> >  drivers/soc/imx/sc/main/ipc.c                      | 258 +++++++++
> >  drivers/soc/imx/sc/main/rpc.h                      |  51 ++
> >  drivers/soc/imx/sc/svc/misc/rpc_clnt.c             | 106 ++++
> >  drivers/soc/imx/sc/svc/pad/rpc_clnt.c              |  82 +++
> >  drivers/soc/imx/sc/svc/pm/rpc_clnt.c               | 275 +++++++++
> >  include/soc/imx/sc/ipc.h                           |  46 ++
> >  include/soc/imx/sc/sci.h                           |  20 +
> >  include/soc/imx/sc/svc/misc/api.h                  |  60 ++
> >  include/soc/imx/sc/svc/pad/api.h                   |  60 ++
> >  include/soc/imx/sc/svc/pm/api.h                    | 229 ++++++++
> >  include/soc/imx/sc/types.h                         | 636
> +++++++++++++++++++++
> >  15 files changed, 2012 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> >  create mode 100644 drivers/soc/imx/sc/Makefile  create mode 100644
> > drivers/soc/imx/sc/main/ipc.c  create mode 100644
> > drivers/soc/imx/sc/main/rpc.h  create mode 100644
> > drivers/soc/imx/sc/svc/misc/rpc_clnt.c
> >  create mode 100644 drivers/soc/imx/sc/svc/pad/rpc_clnt.c
> >  create mode 100644 drivers/soc/imx/sc/svc/pm/rpc_clnt.c
> >  create mode 100644 include/soc/imx/sc/ipc.h  create mode 100644
> > include/soc/imx/sc/sci.h  create mode 100644
> > include/soc/imx/sc/svc/misc/api.h  create mode 100644
> > include/soc/imx/sc/svc/pad/api.h  create mode 100644
> > include/soc/imx/sc/svc/pm/api.h  create mode 100644
> > include/soc/imx/sc/types.h
> >
> > --
> > 2.7.4

[PATCH V5 0/5] soc: imx: add scu firmware api support

[Jassi Brar]

On Fri, Aug 24, 2018 at 1:06 PM A.s. Dong <aisheng.dong@nxp.com> wrote:
>
> Hi Jassi & Sasha,
>
> Do you have some suggestions about this patch series?
>
The client uses the mailbox api as expected. And I leave the
implementation upto you. So, I am fine.

[PATCH V5 0/5] soc: imx: add scu firmware api support

[A.s. Dong]

> -----Original Message-----
> From: Jassi Brar [mailto:jassisinghbrar at gmail.com]
> On Fri, Aug 24, 2018 at 1:06 PM A.s. Dong <aisheng.dong@nxp.com> wrote:
> >
> > Hi Jassi & Sasha,
> >
> > Do you have some suggestions about this patch series?
> >
> The client uses the mailbox api as expected. And I leave the implementation
> upto you. So, I am fine.

Thanks

Sascha,
What's your suggestion?

Regards
Dong Aisheng

[PATCH V5 0/5] soc: imx: add scu firmware api support

[Sascha Hauer]

On Fri, Aug 24, 2018 at 07:36:38AM +0000, A.s. Dong wrote:
> Hi Jassi & Sasha,
> 
> Do you have some suggestions about this patch series?

I still think that the users like clk and pinctrl should directly call
sc_call_rpc(), no need for this shim at all.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH V5 0/5] soc: imx: add scu firmware api support

[A.s. Dong]

> -----Original Message-----
> From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> Sent: Monday, August 27, 2018 4:33 PM
> To: A.s. Dong <aisheng.dong@nxp.com>
> Cc: Jassi Brar <jassisinghbrar@gmail.com>; dongas86 at gmail.com;
> kernel at pengutronix.de; shawnguo at kernel.org; Fabio Estevam
> <fabio.estevam@nxp.com>; dl-linux-imx <linux-imx@nxp.com>;
> linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH V5 0/5] soc: imx: add scu firmware api support
> 
> On Fri, Aug 24, 2018 at 07:36:38AM +0000, A.s. Dong wrote:
> > Hi Jassi & Sasha,
> >
> > Do you have some suggestions about this patch series?
> 
> I still think that the users like clk and pinctrl should directly call sc_call_rpc(),
> no need for this shim at all.
> 

Sorry, I'm a bit confuse.
What specific shim do you mean not needed?

Do you mean we don't need all the SCU SVC APIs (clk/pm/pinctrl/misc and etc)
Implemented in this patch series and instead directly implement them in client
driver?
For example:
drivers/soc/imx/sc/svc/pm/rpc_clnt.c
sc_err_t sc_pm_get_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource,
                              sc_pm_clk_t clk, sc_pm_clock_rate_t *rate)
Change to:
drivers/clk/imx/scu/scu_clock.c ?
sc_err_t sc_pm_get_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource,
                              sc_pm_clk_t clk, sc_pm_clock_rate_t *rate)

Regards
Dong Aisheng

> Sascha
> 
> --
> Pengutronix e.K.                           |
> |
> Industrial Linux Solutions                 |
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> pengutronix.de%2F&amp;data=02%7C01%7Caisheng.dong%40nxp.com%7C39
> eeb76a11134dbbf23d08d60bf7b9d1%7C686ea1d3bc2b4c6fa92cd99c5c3016
> 35%7C0%7C0%7C636709555948361895&amp;sdata=qFfNaPeDvy3IN5O4Ou
> UUYg3I6360%2FDX6Bg8YAJB11pg%3D&amp;reserved=0  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> |
> Amtsgericht Hildesheim, HRA 2686           | Fax:
> +49-5121-206917-5555 |

[PATCH V5 0/5] soc: imx: add scu firmware api support

[A.s. Dong]

> From: A.s. Dong
> > From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> > On Fri, Aug 24, 2018 at 07:36:38AM +0000, A.s. Dong wrote:
> > > Hi Jassi & Sasha,
> > >
> > > Do you have some suggestions about this patch series?
> >
> > I still think that the users like clk and pinctrl should directly call
> > sc_call_rpc(), no need for this shim at all.
> >
> 
> Sorry, I'm a bit confuse.
> What specific shim do you mean not needed?
> 
> Do you mean we don't need all the SCU SVC APIs (clk/pm/pinctrl/misc and etc)
> Implemented in this patch series and instead directly implement them in client
> driver?
> For example:
> drivers/soc/imx/sc/svc/pm/rpc_clnt.c
> sc_err_t sc_pm_get_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource,
>                               sc_pm_clk_t clk, sc_pm_clock_rate_t *rate)
> Change to:
> drivers/clk/imx/scu/scu_clock.c ?
> sc_err_t sc_pm_get_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource,
>                               sc_pm_clk_t clk, sc_pm_clock_rate_t *rate)
>

I thought even make client driver to directly to sc_call_rpc(), it may still better to
Make them into a serrate function call like sc_pm_get_clock_rate() but just put
In client driver instead of in the central SCU SVC place.
Not sure the point to do that.
Would you please help clarify a bit more?

Regards
Dong Aisheng

[PATCH V5 0/5] soc: imx: add scu firmware api support

[Sascha Hauer]

On Mon, Aug 27, 2018 at 10:21:37AM +0000, A.s. Dong wrote:
> > From: A.s. Dong
> > > From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> > > On Fri, Aug 24, 2018 at 07:36:38AM +0000, A.s. Dong wrote:
> > > > Hi Jassi & Sasha,
> > > >
> > > > Do you have some suggestions about this patch series?
> > >
> > > I still think that the users like clk and pinctrl should directly call
> > > sc_call_rpc(), no need for this shim at all.
> > >
> > 
> > Sorry, I'm a bit confuse.
> > What specific shim do you mean not needed?
> > 
> > Do you mean we don't need all the SCU SVC APIs (clk/pm/pinctrl/misc and etc)
> > Implemented in this patch series and instead directly implement them in client
> > driver?
> > For example:
> > drivers/soc/imx/sc/svc/pm/rpc_clnt.c
> > sc_err_t sc_pm_get_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource,
> >                               sc_pm_clk_t clk, sc_pm_clock_rate_t *rate)
> > Change to:
> > drivers/clk/imx/scu/scu_clock.c ?
> > sc_err_t sc_pm_get_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource,
> >                               sc_pm_clk_t clk, sc_pm_clock_rate_t *rate)
> >
> 
> I thought even make client driver to directly to sc_call_rpc(), it may still better to
> Make them into a serrate function call like sc_pm_get_clock_rate() but just put
> In client driver instead of in the central SCU SVC place.
> Not sure the point to do that.
> Would you please help clarify a bit more?

I think translating the sc message setup into a function only adds
additional overhead that the reader has to follow. I do not see the
point for doing this.

Also when we do the message sending directly in the clients we do not
end up with a huge bag of all possible message sending function of which
only a fraction is ever going to be used.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH V5 0/5] soc: imx: add scu firmware api support

[A.s. Dong]

> -----Original Message-----
> From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> Sent: Tuesday, August 28, 2018 2:21 PM
> To: A.s. Dong <aisheng.dong@nxp.com>
> Cc: Jassi Brar <jassisinghbrar@gmail.com>; dongas86 at gmail.com;
> kernel at pengutronix.de; shawnguo at kernel.org; Fabio Estevam
> <fabio.estevam@nxp.com>; dl-linux-imx <linux-imx@nxp.com>;
> linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH V5 0/5] soc: imx: add scu firmware api support
> 
> On Mon, Aug 27, 2018 at 10:21:37AM +0000, A.s. Dong wrote:
> > > From: A.s. Dong
> > > > From: Sascha Hauer [mailto:s.hauer at pengutronix.de] On Fri, Aug 24,
> > > > 2018 at 07:36:38AM +0000, A.s. Dong wrote:
> > > > > Hi Jassi & Sasha,
> > > > >
> > > > > Do you have some suggestions about this patch series?
> > > >
> > > > I still think that the users like clk and pinctrl should directly
> > > > call sc_call_rpc(), no need for this shim at all.
> > > >
> > >
> > > Sorry, I'm a bit confuse.
> > > What specific shim do you mean not needed?
> > >
> > > Do you mean we don't need all the SCU SVC APIs (clk/pm/pinctrl/misc
> > > and etc) Implemented in this patch series and instead directly
> > > implement them in client driver?
> > > For example:
> > > drivers/soc/imx/sc/svc/pm/rpc_clnt.c
> > > sc_err_t sc_pm_get_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource,
> > >                               sc_pm_clk_t clk, sc_pm_clock_rate_t
> > > *rate) Change to:
> > > drivers/clk/imx/scu/scu_clock.c ?
> > > sc_err_t sc_pm_get_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource,
> > >                               sc_pm_clk_t clk, sc_pm_clock_rate_t
> > > *rate)
> > >
> >
> > I thought even make client driver to directly to sc_call_rpc(), it may
> > still better to Make them into a serrate function call like
> > sc_pm_get_clock_rate() but just put In client driver instead of in the central
> SCU SVC place.
> > Not sure the point to do that.
> > Would you please help clarify a bit more?
> 
> I think translating the sc message setup into a function only adds additional
> overhead that the reader has to follow. I do not see the point for doing this.
> 

The original point is to separate the SCU service API implementation from the client
drivers. Client drivers don't have to know the internal details of the API implementation,
they just use the service API provided by SCU firmware. API implementation and client
users will be maintained independently.

And this way seems like to be commonly used in current kernel:
See:
drivers/firmware/ti_sci.c
drivers/firmware/arm_scpi.c
drivers/firmware/arm_scmi/clock.c

Should we be the exception?

> Also when we do the message sending directly in the clients we do not end up
> with a huge bag of all possible message sending function of which only a
> fraction is ever going to be used.
> 

Currently I only add the APIs actually used by client driver. All unused APIs
are not added until we have real requirements.
So changing a place seems like would not affect much.

Regards
Dong Aisheng

> Sascha
> 
> --
> Pengutronix e.K.                           |
> |
> Industrial Linux Solutions                 |
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> pengutronix.de%2F&amp;data=02%7C01%7Caisheng.dong%40nxp.com%7C79
> cabf129d764c8d2dec08d60cae7563%7C686ea1d3bc2b4c6fa92cd99c5c30163
> 5%7C0%7C0%7C636710340764331803&amp;sdata=vWXc5oHn6fZN0zBYbMI
> mgsVMzPQMU08wvSt3HNvbGgM%3D&amp;reserved=0  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> |
> Amtsgericht Hildesheim, HRA 2686           | Fax:
> +49-5121-206917-5555 |

[PATCH V5 0/5] soc: imx: add scu firmware api support

[Sascha Hauer]

On Tue, Aug 28, 2018 at 08:53:34AM +0000, A.s. Dong wrote:
> > -----Original Message-----
> > From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> > Sent: Tuesday, August 28, 2018 2:21 PM
> > To: A.s. Dong <aisheng.dong@nxp.com>
> > Cc: Jassi Brar <jassisinghbrar@gmail.com>; dongas86 at gmail.com;
> > kernel at pengutronix.de; shawnguo at kernel.org; Fabio Estevam
> > <fabio.estevam@nxp.com>; dl-linux-imx <linux-imx@nxp.com>;
> > linux-arm-kernel at lists.infradead.org
> > Subject: Re: [PATCH V5 0/5] soc: imx: add scu firmware api support
> > 
> > On Mon, Aug 27, 2018 at 10:21:37AM +0000, A.s. Dong wrote:
> > > > From: A.s. Dong
> > > > > From: Sascha Hauer [mailto:s.hauer at pengutronix.de] On Fri, Aug 24,
> > > > > 2018 at 07:36:38AM +0000, A.s. Dong wrote:
> > > > > > Hi Jassi & Sasha,
> > > > > >
> > > > > > Do you have some suggestions about this patch series?
> > > > >
> > > > > I still think that the users like clk and pinctrl should directly
> > > > > call sc_call_rpc(), no need for this shim at all.
> > > > >
> > > >
> > > > Sorry, I'm a bit confuse.
> > > > What specific shim do you mean not needed?
> > > >
> > > > Do you mean we don't need all the SCU SVC APIs (clk/pm/pinctrl/misc
> > > > and etc) Implemented in this patch series and instead directly
> > > > implement them in client driver?
> > > > For example:
> > > > drivers/soc/imx/sc/svc/pm/rpc_clnt.c
> > > > sc_err_t sc_pm_get_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource,
> > > >                               sc_pm_clk_t clk, sc_pm_clock_rate_t
> > > > *rate) Change to:
> > > > drivers/clk/imx/scu/scu_clock.c ?
> > > > sc_err_t sc_pm_get_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource,
> > > >                               sc_pm_clk_t clk, sc_pm_clock_rate_t
> > > > *rate)
> > > >
> > >
> > > I thought even make client driver to directly to sc_call_rpc(), it may
> > > still better to Make them into a serrate function call like
> > > sc_pm_get_clock_rate() but just put In client driver instead of in the central
> > SCU SVC place.
> > > Not sure the point to do that.
> > > Would you please help clarify a bit more?
> > 
> > I think translating the sc message setup into a function only adds additional
> > overhead that the reader has to follow. I do not see the point for doing this.
> > 
> 
> The original point is to separate the SCU service API implementation from the client
> drivers. Client drivers don't have to know the internal details of the API implementation,
> they just use the service API provided by SCU firmware. API implementation and client
> users will be maintained independently.

I would buy this argument if the 'API implementation' was more than a
shim layer that directly translates between function arguments and a
message struct. With this you effectively can't change the API
implementation without changing the API you provide to the client
drivers.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH V5 0/5] soc: imx: add scu firmware api support

[A.s. Dong]

> -----Original Message-----
> From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> Sent: Wednesday, August 29, 2018 2:54 PM
> To: A.s. Dong <aisheng.dong@nxp.com>
> Cc: Jassi Brar <jassisinghbrar@gmail.com>; dongas86 at gmail.com;
> kernel at pengutronix.de; shawnguo at kernel.org; Fabio Estevam
> <fabio.estevam@nxp.com>; dl-linux-imx <linux-imx@nxp.com>;
> linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH V5 0/5] soc: imx: add scu firmware api support
> 
> On Tue, Aug 28, 2018 at 08:53:34AM +0000, A.s. Dong wrote:
> > > -----Original Message-----
> > > From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> > > Sent: Tuesday, August 28, 2018 2:21 PM
> > > To: A.s. Dong <aisheng.dong@nxp.com>
> > > Cc: Jassi Brar <jassisinghbrar@gmail.com>; dongas86 at gmail.com;
> > > kernel at pengutronix.de; shawnguo at kernel.org; Fabio Estevam
> > > <fabio.estevam@nxp.com>; dl-linux-imx <linux-imx@nxp.com>;
> > > linux-arm-kernel at lists.infradead.org
> > > Subject: Re: [PATCH V5 0/5] soc: imx: add scu firmware api support
> > >
> > > On Mon, Aug 27, 2018 at 10:21:37AM +0000, A.s. Dong wrote:
> > > > > From: A.s. Dong
> > > > > > From: Sascha Hauer [mailto:s.hauer at pengutronix.de] On Fri, Aug
> > > > > > 24,
> > > > > > 2018 at 07:36:38AM +0000, A.s. Dong wrote:
> > > > > > > Hi Jassi & Sasha,
> > > > > > >
> > > > > > > Do you have some suggestions about this patch series?
> > > > > >
> > > > > > I still think that the users like clk and pinctrl should
> > > > > > directly call sc_call_rpc(), no need for this shim at all.
> > > > > >
> > > > >
> > > > > Sorry, I'm a bit confuse.
> > > > > What specific shim do you mean not needed?
> > > > >
> > > > > Do you mean we don't need all the SCU SVC APIs
> > > > > (clk/pm/pinctrl/misc and etc) Implemented in this patch series
> > > > > and instead directly implement them in client driver?
> > > > > For example:
> > > > > drivers/soc/imx/sc/svc/pm/rpc_clnt.c
> > > > > sc_err_t sc_pm_get_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource,
> > > > >                               sc_pm_clk_t clk,
> > > > > sc_pm_clock_rate_t
> > > > > *rate) Change to:
> > > > > drivers/clk/imx/scu/scu_clock.c ?
> > > > > sc_err_t sc_pm_get_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource,
> > > > >                               sc_pm_clk_t clk,
> > > > > sc_pm_clock_rate_t
> > > > > *rate)
> > > > >
> > > >
> > > > I thought even make client driver to directly to sc_call_rpc(), it
> > > > may still better to Make them into a serrate function call like
> > > > sc_pm_get_clock_rate() but just put In client driver instead of in
> > > > the central
> > > SCU SVC place.
> > > > Not sure the point to do that.
> > > > Would you please help clarify a bit more?
> > >
> > > I think translating the sc message setup into a function only adds
> > > additional overhead that the reader has to follow. I do not see the point for
> doing this.
> > >
> >
> > The original point is to separate the SCU service API implementation
> > from the client drivers. Client drivers don't have to know the
> > internal details of the API implementation, they just use the service
> > API provided by SCU firmware. API implementation and client users will be
> maintained independently.
> 
> I would buy this argument if the 'API implementation' was more than a shim
> layer that directly translates between function arguments and a message struct.
> With this you effectively can't change the API implementation without
> changing the API you provide to the client drivers.
> 

In reality, the API implementation could change without changing the API prototype.
The API is defined in a more generic way and less possible to change.
But the internal implementation is allowed to change if the firmware updates.
e.g. protocol params layout and size and etc.

This way give us a clear separation between API internals and client users which
are more like to be maintained independently.
And it may also help if we want to support old firmware due to API internal
implementation changes. (And note that SCU firmware supports many functions,
distribute them into various drivers may cause a bit mess. Some of them may get
troubles on finding a proper place to put.)

So aren't those more valuable comparing to move SCU APIs into client drivers?
And current kernel users (arm scpi/scmi, ti sci) already do like this... why not i.MX?

Sorry if I still not get your point. 
Please help clarify a bit more if I missed something..

Regards
Dong Aisheng

> Sascha
> 
> --
> Pengutronix e.K.                           |
> |
> Industrial Linux Solutions                 |
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> pengutronix.de%2F&amp;data=02%7C01%7Caisheng.dong%40nxp.com%7C97
> 6c8b12abfc4be67f0708d60d7c2c1e%7C686ea1d3bc2b4c6fa92cd99c5c30163
> 5%7C0%7C0%7C636711224308904255&amp;sdata=i2OfGviDpZrpEQVVv51gd
> gu2Cq20aBtRRtzR2wLzr0U%3D&amp;reserved=0  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> |
> Amtsgericht Hildesheim, HRA 2686           | Fax:
> +49-5121-206917-5555 |

[PATCH V5 0/5] soc: imx: add scu firmware api support

[A.s. Dong]

Hi Sascha,

> -----Original Message-----
> From: A.s. Dong
> Sent: Wednesday, August 29, 2018 4:35 PM
> To: Sascha Hauer <s.hauer@pengutronix.de>

[...]

> > > The original point is to separate the SCU service API implementation
> > > from the client drivers. Client drivers don't have to know the
> > > internal details of the API implementation, they just use the
> > > service API provided by SCU firmware. API implementation and client
> > > users will be
> > maintained independently.
> >
> > I would buy this argument if the 'API implementation' was more than a
> > shim layer that directly translates between function arguments and a
> message struct.
> > With this you effectively can't change the API implementation without
> > changing the API you provide to the client drivers.
> >
> 
> In reality, the API implementation could change without changing the API
> prototype.
> The API is defined in a more generic way and less possible to change.
> But the internal implementation is allowed to change if the firmware updates.
> e.g. protocol params layout and size and etc.
> 
> This way give us a clear separation between API internals and client users
> which are more like to be maintained independently.
> And it may also help if we want to support old firmware due to API internal
> implementation changes. (And note that SCU firmware supports many
> functions, distribute them into various drivers may cause a bit mess. Some of
> them may get troubles on finding a proper place to put.)
> 
> So aren't those more valuable comparing to move SCU APIs into client drivers?
> And current kernel users (arm scpi/scmi, ti sci) already do like this... why not
> i.MX?
> 
> Sorry if I still not get your point.
> Please help clarify a bit more if I missed something..

Please let me know if you still believe moving SCU API implementation into
each client driver is a more reasonable way to go, then i will do it as I trust
your professionality.
.
This patch series has been pending for a long time. We need a way out to
speed up the work.

Regards
Dong Aisheng

> 
> Regards
> Dong Aisheng
> 
> > Sascha
> >
> > --
> > Pengutronix e.K.                           |
> > |
> > Industrial Linux Solutions                 |
> >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> >
> pengutronix.de%2F&amp;data=02%7C01%7Caisheng.dong%40nxp.com%7C97
> >
> 6c8b12abfc4be67f0708d60d7c2c1e%7C686ea1d3bc2b4c6fa92cd99c5c30163
> >
> 5%7C0%7C0%7C636711224308904255&amp;sdata=i2OfGviDpZrpEQVVv51gd
> > gu2Cq20aBtRRtzR2wLzr0U%3D&amp;reserved=0  | Peiner Str. 6-8, 31137
> > Hildesheim, Germany | Phone: +49-5121-206917-0
> > |
> > Amtsgericht Hildesheim, HRA 2686           | Fax:
> > +49-5121-206917-5555 |

[PATCH V5 0/5] soc: imx: add scu firmware api support

[Sascha Hauer]

On Mon, Sep 03, 2018 at 08:57:36AM +0000, A.s. Dong wrote:
> Hi Sascha,
> 
> > -----Original Message-----
> > From: A.s. Dong
> > Sent: Wednesday, August 29, 2018 4:35 PM
> > To: Sascha Hauer <s.hauer@pengutronix.de>
> 
> [...]
> 
> > > > The original point is to separate the SCU service API implementation
> > > > from the client drivers. Client drivers don't have to know the
> > > > internal details of the API implementation, they just use the
> > > > service API provided by SCU firmware. API implementation and client
> > > > users will be
> > > maintained independently.
> > >
> > > I would buy this argument if the 'API implementation' was more than a
> > > shim layer that directly translates between function arguments and a
> > message struct.
> > > With this you effectively can't change the API implementation without
> > > changing the API you provide to the client drivers.
> > >
> > 
> > In reality, the API implementation could change without changing the API
> > prototype.
> > The API is defined in a more generic way and less possible to change.
> > But the internal implementation is allowed to change if the firmware updates.
> > e.g. protocol params layout and size and etc.
> > 
> > This way give us a clear separation between API internals and client users
> > which are more like to be maintained independently.
> > And it may also help if we want to support old firmware due to API internal
> > implementation changes. (And note that SCU firmware supports many
> > functions, distribute them into various drivers may cause a bit mess. Some of
> > them may get troubles on finding a proper place to put.)

Examples?

> > 
> > So aren't those more valuable comparing to move SCU APIs into client drivers?
> > And current kernel users (arm scpi/scmi, ti sci) already do like this... why not
> > i.MX?
> > 
> > Sorry if I still not get your point.
> > Please help clarify a bit more if I missed something..
> 
> Please let me know if you still believe moving SCU API implementation into
> each client driver is a more reasonable way to go, then i will do it as I trust
> your professionality.

Yes, I still think that. I still think the 1:1 mapping between messages
and function calls is an unnecessary overhead.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH V5 0/5] soc: imx: add scu firmware api support

[A.s. Dong]

Hi Sasha,

> -----Original Message-----
> From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> Sent: Monday, September 3, 2018 7:45 PM
>
> On Mon, Sep 03, 2018 at 08:57:36AM +0000, A.s. Dong wrote:
> > Hi Sascha,
> >
> > > -----Original Message-----
> > > From: A.s. Dong
> > > Sent: Wednesday, August 29, 2018 4:35 PM
> > > To: Sascha Hauer <s.hauer@pengutronix.de>
> >
> > [...]
> >
> > > > > The original point is to separate the SCU service API
> > > > > implementation from the client drivers. Client drivers don't
> > > > > have to know the internal details of the API implementation,
> > > > > they just use the service API provided by SCU firmware. API
> > > > > implementation and client users will be
> > > > maintained independently.
> > > >
> > > > I would buy this argument if the 'API implementation' was more
> > > > than a shim layer that directly translates between function
> > > > arguments and a
> > > message struct.
> > > > With this you effectively can't change the API implementation
> > > > without changing the API you provide to the client drivers.
> > > >
> > >
> > > In reality, the API implementation could change without changing the
> > > API prototype.
> > > The API is defined in a more generic way and less possible to change.
> > > But the internal implementation is allowed to change if the firmware
> updates.
> > > e.g. protocol params layout and size and etc.
> > >
> > > This way give us a clear separation between API internals and client
> > > users which are more like to be maintained independently.
> > > And it may also help if we want to support old firmware due to API
> > > internal implementation changes. (And note that SCU firmware
> > > supports many functions, distribute them into various drivers may
> > > cause a bit mess. Some of them may get troubles on finding a proper
> > > place to put.)
> 
> Examples?
> 

Take sc_misc_set_control as example which is widely used by various client drivers.
Encoding message in driver may cause many duplicated code. 
Cscope tag: sc_misc_set_control
   #   line  filename / context / line
   1    206  drivers/clk/imx/clk-divider-scu.c <<clk_divider3_scu_set_rate>>
             sci_err = sc_misc_set_control(ccm_ipc_handle, clk->rsrc_id,
   2    372  drivers/clk/imx/clk-gate-scu.c <<clk_gate3_scu_prepare>>
             return sc_misc_set_control(ccm_ipc_handle,
   4    319  drivers/clk/imx/clk-mux-scu.c <<clk_mux_gpr_scu_set_parent>>
             sc_misc_set_control(ccm_ipc_handle,
   5    128  drivers/gpu/drm/imx/hdp/imx-hdp.c <<imx8qm_pixel_link_validate>>
             sciErr = sc_misc_set_control(hdp->ipcHndl, SC_R_DC_0,
  10    432  drivers/gpu/drm/imx/hdp/imx-hdp.c <<imx8qm_dp_pixel_clock_set_rate>>
             sc_misc_set_control(ipc_handle, SC_R_HDMI, SC_C_MODE, 1);
  11    339  drivers/gpu/drm/imx/imx-ldb.c <<dpu_pixel_link_validate>>
             sciErr = sc_misc_set_control(ipcHndl, SC_R_DC_0,
  30    271  drivers/gpu/drm/imx/nwl_dsi-imx.c <<imx8q_dsi_poweron>>
             sci_err = sc_misc_set_control(ipc_handle,
  41   1544  drivers/gpu/imx/dpu/dpu-common.c <<dpu_pixel_link_init>>
             sciErr = sc_misc_set_control(ipcHndl, SC_R_DC_0, SC_C_KACHUNK_CNT, 32);
  58   1612  drivers/gpu/imx/dpu/dpu-common.c <<dpu_pixel_link_init>>
             sciErr = sc_misc_set_control(ipcHndl, SC_R_DC_1, SC_C_SYNC_CTRL1, 0);
  59    147  drivers/gpu/imx/dpu/dpu-framegen.c <<dpu_pixel_link_enable>>
             sciErr = sc_misc_set_control(ipcHndl, SC_R_DC_0,
  65    312  drivers/gpu/imx/imx8_dprc.c <<dprc_dpu_gpr_configure>>
             sciErr = sc_misc_set_control(ipcHndl, dprc->sc_resource,
  67    573  drivers/media/platform/imx8/hdmi/mxc-hdmi-rx.c <<imx8qm_hdmi_phy_reset>>
             sciErr = sc_misc_set_control(hdmi_rx->ipcHndl, SC_R_HDMI_RX, SC_C_PHY_RESET, reset);
  68    139  drivers/media/platform/imx8/mxc-mipi-csi2.c <<mipi_sc_fw_init>>
             sciErr = sc_misc_set_control(ipcHndl, rsrc_id, SC_C_MIPI_RESET, enable);
  69   1261  drivers/mxc/gpu-viv/hal/os/linux/kernel/platform/freescale/gc_hal_kernel_platform_imx.c <<set_power>>
             sc_err_t sciErr = sc_misc_set_control(gpu_ipcHandle, priv->sc_gpu_pid[gpu], SC_C_ID, gpu);
  72    230  drivers/net/ethernet/freescale/fec_fixup.c <<imx8qm_ipg_stop_enable>>
             sc_err = sc_misc_set_control(ipc_handle, rsrc_id, SC_C_IPG_STOP, val);
  73    187  drivers/phy/phy-mixel-mipi-dsi.c <<mixel_mipi_phy_enable>>
             sci_err = sc_misc_set_control(ipc_handle,
  74    794  sound/soc/fsl/fsl_dsp.c <<fsl_dsp_probe>>
             sciErr = sc_misc_set_control(dsp_priv->dsp_ipcHandle, SC_R_DSP,
...

> > >
> > > So aren't those more valuable comparing to move SCU APIs into client
> drivers?
> > > And current kernel users (arm scpi/scmi, ti sci) already do like
> > > this... why not i.MX?
> > >
> > > Sorry if I still not get your point.
> > > Please help clarify a bit more if I missed something..
> >
> > Please let me know if you still believe moving SCU API implementation
> > into each client driver is a more reasonable way to go, then i will do
> > it as I trust your professionality.
> 
> Yes, I still think that. I still think the 1:1 mapping between messages and
> function calls is an unnecessary overhead.
> 

Okay, let's do that way first if you still think it's proper.
BTW, do you have any comment about the MU usage in Patch 2/5 ?
[V5,2/5] soc: imx: add SC firmware IPC and APIs
https://patchwork.kernel.org/patch/10570551/

As this patch may not change much even changing to new approach, except moving
drivers/soc/imx/sc/main/rpc.h under include/soc/imx to allow drivers to touch
the internal details of SCU API implementation. So I guess this version
does not affect review process.

Regards
Dong Aisheng

> Sascha
> 
> 
> --
> Pengutronix e.K.                           |
> |
> Industrial Linux Solutions                 |
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> pengutronix.de%2F&amp;data=02%7C01%7Caisheng.dong%40nxp.com%7Ca0
> 3cf22e3f194f921f2d08d61192a293%7C686ea1d3bc2b4c6fa92cd99c5c30163
> 5%7C0%7C0%7C636715718821871337&amp;sdata=usMYj5iYuKFhqBU2HMHI
> gGL8w0FTMQ632a6HiTotNoc%3D&amp;reserved=0  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> |
> Amtsgericht Hildesheim, HRA 2686           | Fax:
> +49-5121-206917-5555 |

[PATCH V5 0/5] soc: imx: add scu firmware api support

[Sascha Hauer]

On Thu, Sep 06, 2018 at 03:21:39AM +0000, A.s. Dong wrote:
> Hi Sasha,
> 
> > -----Original Message-----
> > From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> > Sent: Monday, September 3, 2018 7:45 PM
> >
> > On Mon, Sep 03, 2018 at 08:57:36AM +0000, A.s. Dong wrote:
> > > Hi Sascha,
> > >
> > > > -----Original Message-----
> > > > From: A.s. Dong
> > > > Sent: Wednesday, August 29, 2018 4:35 PM
> > > > To: Sascha Hauer <s.hauer@pengutronix.de>
> > >
> > > [...]
> > >
> > > > > > The original point is to separate the SCU service API
> > > > > > implementation from the client drivers. Client drivers don't
> > > > > > have to know the internal details of the API implementation,
> > > > > > they just use the service API provided by SCU firmware. API
> > > > > > implementation and client users will be
> > > > > maintained independently.
> > > > >
> > > > > I would buy this argument if the 'API implementation' was more
> > > > > than a shim layer that directly translates between function
> > > > > arguments and a
> > > > message struct.
> > > > > With this you effectively can't change the API implementation
> > > > > without changing the API you provide to the client drivers.
> > > > >
> > > >
> > > > In reality, the API implementation could change without changing the
> > > > API prototype.
> > > > The API is defined in a more generic way and less possible to change.
> > > > But the internal implementation is allowed to change if the firmware
> > updates.
> > > > e.g. protocol params layout and size and etc.
> > > >
> > > > This way give us a clear separation between API internals and client
> > > > users which are more like to be maintained independently.
> > > > And it may also help if we want to support old firmware due to API
> > > > internal implementation changes. (And note that SCU firmware
> > > > supports many functions, distribute them into various drivers may
> > > > cause a bit mess. Some of them may get troubles on finding a proper
> > > > place to put.)
> > 
> > Examples?
> > 
> 
> Take sc_misc_set_control as example which is widely used by various client drivers.
> Encoding message in driver may cause many duplicated code. 
> Cscope tag: sc_misc_set_control
>    #   line  filename / context / line
>    1    206  drivers/clk/imx/clk-divider-scu.c <<clk_divider3_scu_set_rate>>
>              sci_err = sc_misc_set_control(ccm_ipc_handle, clk->rsrc_id,

You can still create a helper function for these calls. I was mainly
aiming for the oneshot usages of several other functions.

> > > >
> > > > So aren't those more valuable comparing to move SCU APIs into client
> > drivers?
> > > > And current kernel users (arm scpi/scmi, ti sci) already do like
> > > > this... why not i.MX?
> > > >
> > > > Sorry if I still not get your point.
> > > > Please help clarify a bit more if I missed something..
> > >
> > > Please let me know if you still believe moving SCU API implementation
> > > into each client driver is a more reasonable way to go, then i will do
> > > it as I trust your professionality.
> > 
> > Yes, I still think that. I still think the 1:1 mapping between messages and
> > function calls is an unnecessary overhead.
> > 
> 
> Okay, let's do that way first if you still think it's proper.
> BTW, do you have any comment about the MU usage in Patch 2/5 ?
> [V5,2/5] soc: imx: add SC firmware IPC and APIs
> https://patchwork.kernel.org/patch/10570551/

The MU usage looks fine from a first glance.

The way you share a global scu handle with your clients still looks
ridiculous though.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH V5 0/5] soc: imx: add scu firmware api support

[A.s. Dong]

> -----Original Message-----
> From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> Sent: Monday, September 10, 2018 3:04 PM
> To: A.s. Dong <aisheng.dong@nxp.com>
> Cc: Jassi Brar <jassisinghbrar@gmail.com>; dongas86 at gmail.com;
> kernel at pengutronix.de; shawnguo at kernel.org; Fabio Estevam
> <fabio.estevam@nxp.com>; dl-linux-imx <linux-imx@nxp.com>;
> linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH V5 0/5] soc: imx: add scu firmware api support
> 
> On Thu, Sep 06, 2018 at 03:21:39AM +0000, A.s. Dong wrote:
> > Hi Sasha,
> >
> > > -----Original Message-----
> > > From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> > > Sent: Monday, September 3, 2018 7:45 PM
> > >
> > > On Mon, Sep 03, 2018 at 08:57:36AM +0000, A.s. Dong wrote:
> > > > Hi Sascha,
> > > >
> > > > > -----Original Message-----
> > > > > From: A.s. Dong
> > > > > Sent: Wednesday, August 29, 2018 4:35 PM
> > > > > To: Sascha Hauer <s.hauer@pengutronix.de>
> > > >
> > > > [...]
> > > >
> > > > > > > The original point is to separate the SCU service API
> > > > > > > implementation from the client drivers. Client drivers don't
> > > > > > > have to know the internal details of the API implementation,
> > > > > > > they just use the service API provided by SCU firmware. API
> > > > > > > implementation and client users will be
> > > > > > maintained independently.
> > > > > >
> > > > > > I would buy this argument if the 'API implementation' was more
> > > > > > than a shim layer that directly translates between function
> > > > > > arguments and a
> > > > > message struct.
> > > > > > With this you effectively can't change the API implementation
> > > > > > without changing the API you provide to the client drivers.
> > > > > >
> > > > >
> > > > > In reality, the API implementation could change without changing
> > > > > the API prototype.
> > > > > The API is defined in a more generic way and less possible to change.
> > > > > But the internal implementation is allowed to change if the
> > > > > firmware
> > > updates.
> > > > > e.g. protocol params layout and size and etc.
> > > > >
> > > > > This way give us a clear separation between API internals and
> > > > > client users which are more like to be maintained independently.
> > > > > And it may also help if we want to support old firmware due to
> > > > > API internal implementation changes. (And note that SCU firmware
> > > > > supports many functions, distribute them into various drivers
> > > > > may cause a bit mess. Some of them may get troubles on finding a
> > > > > proper place to put.)
> > >
> > > Examples?
> > >
> >
> > Take sc_misc_set_control as example which is widely used by various client
> drivers.
> > Encoding message in driver may cause many duplicated code.
> > Cscope tag: sc_misc_set_control
> >    #   line  filename / context / line
> >    1    206  drivers/clk/imx/clk-divider-scu.c
> <<clk_divider3_scu_set_rate>>
> >              sci_err = sc_misc_set_control(ccm_ipc_handle,
> > clk->rsrc_id,
> 
> You can still create a helper function for these calls. I was mainly aiming for the
> oneshot usages of several other functions.
> 

Okay. That seems good to me.
So you mean we can still put the generic SVC APIs (e.g. sc_misc_set/get_control) in
a generic place. e.g. under drivers/soc/imx/sc/svc/ 
But put those oneshot usages APIs into individuals drivers. Right?
We can do that way.

> > > > >
> > > > > So aren't those more valuable comparing to move SCU APIs into
> > > > > client
> > > drivers?
> > > > > And current kernel users (arm scpi/scmi, ti sci) already do like
> > > > > this... why not i.MX?
> > > > >
> > > > > Sorry if I still not get your point.
> > > > > Please help clarify a bit more if I missed something..
> > > >
> > > > Please let me know if you still believe moving SCU API
> > > > implementation into each client driver is a more reasonable way to
> > > > go, then i will do it as I trust your professionality.
> > >
> > > Yes, I still think that. I still think the 1:1 mapping between
> > > messages and function calls is an unnecessary overhead.
> > >
> >
> > Okay, let's do that way first if you still think it's proper.
> > BTW, do you have any comment about the MU usage in Patch 2/5 ?
> > [V5,2/5] soc: imx: add SC firmware IPC and APIs
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
> >
> chwork.kernel.org%2Fpatch%2F10570551%2F&amp;data=02%7C01%7Caishe
> ng.don
> >
> g%40nxp.com%7C195b82e11bc04a2a342a08d616eb906e%7C686ea1d3bc2b
> 4c6fa92cd
> >
> 99c5c301635%7C0%7C0%7C636721598339072295&amp;sdata=dYWNSEOoll
> 1%2BCq2i1
> > 5uBxwelooUbAkNE6S9fnMOzf2I%3D&amp;reserved=0
> 
> The MU usage looks fine from a first glance.
> 
> The way you share a global scu handle with your clients still looks ridiculous
> though.

What's your suggestion?

I checked other references:
ARM SCPI, it also shares a global scpi_ops, no much difference than handler.
struct scpi_ops *get_scpi_ops(void)
{
        return scpi_info ? scpi_info->scpi_ops : NULL;
}               
EXPORT_SYMBOL_GPL(get_scpi_ops);

TI also indirectly shares a global handler, they put it in a global ti_sci_list.
And allocate it dynamically (there's actually only one SCI instance in current kernel)
const struct ti_sci_handle *ti_sci_get_handle(struct device *dev)
{
}

It looks like they have no too much difference from i.MX.
And we have 5 MU instances, the scu handle used by client can be different later.

Regards
Dong Aisheng

> 
> Sascha
> 
> --
> Pengutronix e.K.                           |
> |
> Industrial Linux Solutions                 |
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> pengutronix.de%2F&amp;data=02%7C01%7Caisheng.dong%40nxp.com%7C19
> 5b82e11bc04a2a342a08d616eb906e%7C686ea1d3bc2b4c6fa92cd99c5c3016
> 35%7C0%7C0%7C636721598339072295&amp;sdata=dZKI%2FX4zoUTDTchK8
> 7DEpRzXIFUI1IR8kwUlA3t3HlY%3D&amp;reserved=0  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> |
> Amtsgericht Hildesheim, HRA 2686           | Fax:
> +49-5121-206917-5555 |

[PATCH V5 0/5] soc: imx: add scu firmware api support

[Sascha Hauer]

On Mon, Aug 27, 2018 at 09:59:36AM +0000, A.s. Dong wrote:
> > -----Original Message-----
> > From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> > Sent: Monday, August 27, 2018 4:33 PM
> > To: A.s. Dong <aisheng.dong@nxp.com>
> > Cc: Jassi Brar <jassisinghbrar@gmail.com>; dongas86 at gmail.com;
> > kernel at pengutronix.de; shawnguo at kernel.org; Fabio Estevam
> > <fabio.estevam@nxp.com>; dl-linux-imx <linux-imx@nxp.com>;
> > linux-arm-kernel at lists.infradead.org
> > Subject: Re: [PATCH V5 0/5] soc: imx: add scu firmware api support
> > 
> > On Fri, Aug 24, 2018 at 07:36:38AM +0000, A.s. Dong wrote:
> > > Hi Jassi & Sasha,
> > >
> > > Do you have some suggestions about this patch series?
> > 
> > I still think that the users like clk and pinctrl should directly call sc_call_rpc(),
> > no need for this shim at all.
> > 
> 
> Sorry, I'm a bit confuse.
> What specific shim do you mean not needed?
> 
> Do you mean we don't need all the SCU SVC APIs (clk/pm/pinctrl/misc and etc)
> Implemented in this patch series and instead directly implement them in client
> driver?
> For example:
> drivers/soc/imx/sc/svc/pm/rpc_clnt.c
> sc_err_t sc_pm_get_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource,
>                               sc_pm_clk_t clk, sc_pm_clock_rate_t *rate)
> Change to:
> drivers/clk/imx/scu/scu_clock.c ?
> sc_err_t sc_pm_get_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource,
>                               sc_pm_clk_t clk, sc_pm_clock_rate_t *rate)

That particular function would go into drivers/clk/imx/scu/clk-divider-scu.c
and probably would be no separate function at all but go into
clk_divider_scu_recalc_rate(), but yes, that's the idea.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH V5 0/5] soc: imx: add scu firmware api support

[A.s. Dong]

> -----Original Message-----
> From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> Sent: Tuesday, August 28, 2018 2:15 PM
> To: A.s. Dong <aisheng.dong@nxp.com>
> Cc: Jassi Brar <jassisinghbrar@gmail.com>; dongas86 at gmail.com;
> kernel at pengutronix.de; shawnguo at kernel.org; Fabio Estevam
> <fabio.estevam@nxp.com>; dl-linux-imx <linux-imx@nxp.com>;
> linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH V5 0/5] soc: imx: add scu firmware api support
> 
> On Mon, Aug 27, 2018 at 09:59:36AM +0000, A.s. Dong wrote:
> > > -----Original Message-----
> > > From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> > > Sent: Monday, August 27, 2018 4:33 PM
> > > To: A.s. Dong <aisheng.dong@nxp.com>
> > > Cc: Jassi Brar <jassisinghbrar@gmail.com>; dongas86 at gmail.com;
> > > kernel at pengutronix.de; shawnguo at kernel.org; Fabio Estevam
> > > <fabio.estevam@nxp.com>; dl-linux-imx <linux-imx@nxp.com>;
> > > linux-arm-kernel at lists.infradead.org
> > > Subject: Re: [PATCH V5 0/5] soc: imx: add scu firmware api support
> > >
> > > On Fri, Aug 24, 2018 at 07:36:38AM +0000, A.s. Dong wrote:
> > > > Hi Jassi & Sasha,
> > > >
> > > > Do you have some suggestions about this patch series?
> > >
> > > I still think that the users like clk and pinctrl should directly
> > > call sc_call_rpc(), no need for this shim at all.
> > >
> >
> > Sorry, I'm a bit confuse.
> > What specific shim do you mean not needed?
> >
> > Do you mean we don't need all the SCU SVC APIs (clk/pm/pinctrl/misc
> > and etc) Implemented in this patch series and instead directly
> > implement them in client driver?
> > For example:
> > drivers/soc/imx/sc/svc/pm/rpc_clnt.c
> > sc_err_t sc_pm_get_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource,
> >                               sc_pm_clk_t clk, sc_pm_clock_rate_t
> > *rate) Change to:
> > drivers/clk/imx/scu/scu_clock.c ?
> > sc_err_t sc_pm_get_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource,
> >                               sc_pm_clk_t clk, sc_pm_clock_rate_t
> > *rate)
> 
> That particular function would go into drivers/clk/imx/scu/clk-divider-scu.c
> and probably would be no separate function at all but go into
> clk_divider_scu_recalc_rate(), but yes, that's the idea.
> 

I understanding your point. Just a bit wondering whether it's so worth to do that...
As in my last reply, this is a common way in current kernel and separate well
between the SCU API implementation details and the client users which
somehow can ease our maintain.

Do you think it makes sense?

Regards
Dong Aisheng

> Sascha
> 
> --
> Pengutronix e.K.                           |
> |
> Industrial Linux Solutions                 |
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> pengutronix.de%2F&amp;data=02%7C01%7Caisheng.dong%40nxp.com%7C64
> 6e546c196147b1e76a08d60cad9e8b%7C686ea1d3bc2b4c6fa92cd99c5c3016
> 35%7C0%7C0%7C636710337160102101&amp;sdata=idEapYpZEVA%2FHP3i%
> 2FfYTBKpPJxaGeZ3jY5RzZgfhdLc%3D&amp;reserved=0  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> |
> Amtsgericht Hildesheim, HRA 2686           | Fax:
> +49-5121-206917-5555 |