[PATCH v2 0/3] mailbox: arm: introduce smc triggered mailbox

[PATCH v2 0/3] mailbox: arm: introduce smc triggered mailbox

[Andre Przywara]

This is a reworked version of my previous post. It addresses Jassi's
comments on the driver and also tries to cover Rob's and Mark's comments
on the binding documentation.
I dropped the more example-like DT changes from v1, as they are actually
not meant to be merged into the Linux tree, but instead are provided as
part of some firmware actually implementing this functionality.

Please let me know what you think.

Cheers,
Andre.

P.S. Leaving for holidays in a few hours, so don't expect timely answers.
-------------------

The traditional Linux mailbox mechanism uses some kind of dedicated hardware
IP to signal a condition to some other processing unit, typically a dedicated
management processor.
This mailbox feature is used for instance by the SCPI protocol to signal a
request for some action to be taken by the management processor.
And while it seems useful to have a dedicated management core to provide
those services offered via the SCPI protocol, a separate and independent
execution unit is not always required, for instance for just setting up
a clock or enabling a device power supply. Those services could be as well
provided by firmware code running on the very same application processor
cores as the OS, using the ARM TrustZone mechanism to protect and abstract
those services. And while the existing SCPI implementation uses a rather
flexible shared memory region to communicate commands and their parameters,
it still requires a mailbox to actually trigger the action.

This patch series provides a Linux mailbox compatible service which uses
smc calls to invoke firmware code, for instance taking care of SCPI requests.
The actual requests are still communicated using the standard SCPI way of
shared memory regions, but a dedicated mailbox hardware IP can be replaced via
this new driver, which not only serves as a trigger for the request, but also
transfers execution to the firmware code in a safe and architected way.

This simple driver uses the architected SMC calling convention to trigger
firmware services, also allows for using "HVC" calls to call into hypervisors
or firmware layers running in the EL2 exception level.

Patch 1 contains the device tree binding documentation, patch 2 introduces
the actual mailbox driver, and patch 3 enables the driver in Kconfig.

Please note that this driver just provides a generic mailbox mechanism,
though this is synchronous and one-way only (triggered by the OS only,
without providing an asynchronous way of triggering request from the
firmware).
And while providing SCPI services was the reason for this exercise, this
driver is in no way bound to this use case, but can be used generically
where the OS wants to signal a mailbox condition to firmware or a
hypervisor.
Also the driver is in no way meant to replace any existing firmware
interface, but actually to complement existing interfaces.

Please have a look and comment whether this sounds like a useful addition
to the kernel.

Cheers,
Andre.

[1] https://github.com/apritzel/arm-trusted-firmware/commits/allwinner-scpi-wip

Andre Przywara (3):
  DT: mailbox: add binding doc for the ARM SMC mailbox
  mailbox: introduce ARM SMC based mailbox
  mailbox: Kconfig: enable ARM SMC mailbox on 64-bit Allwinner SoCs

 .../devicetree/bindings/mailbox/arm-smc.txt        |  76 ++++++++++
 drivers/mailbox/Kconfig                            |   9 ++
 drivers/mailbox/Makefile                           |   2 +
 drivers/mailbox/arm-smc-mailbox.c                  | 155 +++++++++++++++++++++
 4 files changed, 242 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.txt
 create mode 100644 drivers/mailbox/arm-smc-mailbox.c

-- 
2.8.2

[PATCH v2 0/3] mailbox: arm: introduce smc triggered mailbox

[Andre Przywara]

This is a reworked version of my previous post. It addresses Jassi's
comments on the driver and also tries to cover Rob's and Mark's comments
on the binding documentation.
I dropped the more example-like DT changes from v1, as they are actually
not meant to be merged into the Linux tree, but instead are provided as
part of some firmware actually implementing this functionality.

Please let me know what you think.

Cheers,
Andre.

P.S. Leaving for holidays in a few hours, so don't expect timely answers.
-------------------

The traditional Linux mailbox mechanism uses some kind of dedicated hardware
IP to signal a condition to some other processing unit, typically a dedicated
management processor.
This mailbox feature is used for instance by the SCPI protocol to signal a
request for some action to be taken by the management processor.
And while it seems useful to have a dedicated management core to provide
those services offered via the SCPI protocol, a separate and independent
execution unit is not always required, for instance for just setting up
a clock or enabling a device power supply. Those services could be as well
provided by firmware code running on the very same application processor
cores as the OS, using the ARM TrustZone mechanism to protect and abstract
those services. And while the existing SCPI implementation uses a rather
flexible shared memory region to communicate commands and their parameters,
it still requires a mailbox to actually trigger the action.

This patch series provides a Linux mailbox compatible service which uses
smc calls to invoke firmware code, for instance taking care of SCPI requests.
The actual requests are still communicated using the standard SCPI way of
shared memory regions, but a dedicated mailbox hardware IP can be replaced via
this new driver, which not only serves as a trigger for the request, but also
transfers execution to the firmware code in a safe and architected way.

This simple driver uses the architected SMC calling convention to trigger
firmware services, also allows for using "HVC" calls to call into hypervisors
or firmware layers running in the EL2 exception level.

Patch 1 contains the device tree binding documentation, patch 2 introduces
the actual mailbox driver, and patch 3 enables the driver in Kconfig.

Please note that this driver just provides a generic mailbox mechanism,
though this is synchronous and one-way only (triggered by the OS only,
without providing an asynchronous way of triggering request from the
firmware).
And while providing SCPI services was the reason for this exercise, this
driver is in no way bound to this use case, but can be used generically
where the OS wants to signal a mailbox condition to firmware or a
hypervisor.
Also the driver is in no way meant to replace any existing firmware
interface, but actually to complement existing interfaces.

Please have a look and comment whether this sounds like a useful addition
to the kernel.

Cheers,
Andre.

[1] https://github.com/apritzel/arm-trusted-firmware/commits/allwinner-scpi-wip

Andre Przywara (3):
  DT: mailbox: add binding doc for the ARM SMC mailbox
  mailbox: introduce ARM SMC based mailbox
  mailbox: Kconfig: enable ARM SMC mailbox on 64-bit Allwinner SoCs

 .../devicetree/bindings/mailbox/arm-smc.txt        |  76 ++++++++++
 drivers/mailbox/Kconfig                            |   9 ++
 drivers/mailbox/Makefile                           |   2 +
 drivers/mailbox/arm-smc-mailbox.c                  | 155 +++++++++++++++++++++
 4 files changed, 242 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.txt
 create mode 100644 drivers/mailbox/arm-smc-mailbox.c

-- 
2.8.2

[PATCH v2 0/3] mailbox: arm: introduce smc triggered mailbox

[Andre Przywara]

This is a reworked version of my previous post. It addresses Jassi's
comments on the driver and also tries to cover Rob's and Mark's comments
on the binding documentation.
I dropped the more example-like DT changes from v1, as they are actually
not meant to be merged into the Linux tree, but instead are provided as
part of some firmware actually implementing this functionality.

Please let me know what you think.

Cheers,
Andre.

P.S. Leaving for holidays in a few hours, so don't expect timely answers.
-------------------

The traditional Linux mailbox mechanism uses some kind of dedicated hardware
IP to signal a condition to some other processing unit, typically a dedicated
management processor.
This mailbox feature is used for instance by the SCPI protocol to signal a
request for some action to be taken by the management processor.
And while it seems useful to have a dedicated management core to provide
those services offered via the SCPI protocol, a separate and independent
execution unit is not always required, for instance for just setting up
a clock or enabling a device power supply. Those services could be as well
provided by firmware code running on the very same application processor
cores as the OS, using the ARM TrustZone mechanism to protect and abstract
those services. And while the existing SCPI implementation uses a rather
flexible shared memory region to communicate commands and their parameters,
it still requires a mailbox to actually trigger the action.

This patch series provides a Linux mailbox compatible service which uses
smc calls to invoke firmware code, for instance taking care of SCPI requests.
The actual requests are still communicated using the standard SCPI way of
shared memory regions, but a dedicated mailbox hardware IP can be replaced via
this new driver, which not only serves as a trigger for the request, but also
transfers execution to the firmware code in a safe and architected way.

This simple driver uses the architected SMC calling convention to trigger
firmware services, also allows for using "HVC" calls to call into hypervisors
or firmware layers running in the EL2 exception level.

Patch 1 contains the device tree binding documentation, patch 2 introduces
the actual mailbox driver, and patch 3 enables the driver in Kconfig.

Please note that this driver just provides a generic mailbox mechanism,
though this is synchronous and one-way only (triggered by the OS only,
without providing an asynchronous way of triggering request from the
firmware).
And while providing SCPI services was the reason for this exercise, this
driver is in no way bound to this use case, but can be used generically
where the OS wants to signal a mailbox condition to firmware or a
hypervisor.
Also the driver is in no way meant to replace any existing firmware
interface, but actually to complement existing interfaces.

Please have a look and comment whether this sounds like a useful addition
to the kernel.

Cheers,
Andre.

[1] https://github.com/apritzel/arm-trusted-firmware/commits/allwinner-scpi-wip

Andre Przywara (3):
  DT: mailbox: add binding doc for the ARM SMC mailbox
  mailbox: introduce ARM SMC based mailbox
  mailbox: Kconfig: enable ARM SMC mailbox on 64-bit Allwinner SoCs

 .../devicetree/bindings/mailbox/arm-smc.txt        |  76 ++++++++++
 drivers/mailbox/Kconfig                            |   9 ++
 drivers/mailbox/Makefile                           |   2 +
 drivers/mailbox/arm-smc-mailbox.c                  | 155 +++++++++++++++++++++
 4 files changed, 242 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.txt
 create mode 100644 drivers/mailbox/arm-smc-mailbox.c

-- 
2.8.2

[PATCH v2 1/3] DT: mailbox: add binding doc for the ARM SMC mailbox

[Andre Przywara]

The ARM SMC mailbox binding describes a firmware interface to trigger
actions in software layers running in the EL2 or EL3 exception levels.
The term "ARM" here relates to the SMC instruction as part of the ARM
instruction set, not as a standard endorsed by ARM Ltd.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 .../devicetree/bindings/mailbox/arm-smc.txt        | 76 ++++++++++++++++++++++
 1 file changed, 76 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.txt

diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.txt b/Documentation/devicetree/bindings/mailbox/arm-smc.txt
new file mode 100644
index 0000000..d9de57b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm-smc.txt
@@ -0,0 +1,76 @@
+ARM SMC Mailbox Interface
+=========================
+
+This mailbox uses the ARM smc (secure monitor call) instruction to
+trigger a mailbox-connected activity in firmware, executing on the very same
+core as the caller. By nature this operation is synchronous and this
+mailbox provides no way for asynchronous messages to be delivered the other
+way round, from firmware to the OS. However the value of r0/w0/x0 the firmware
+returns after the smc call is delivered as a received message to the
+mailbox framework, so a synchronous communication can be established.
+The exact meaning of both the action the mailbox triggers as well as the
+return value is defined by their users and is not subject to this binding.
+
+One use case of this mailbox is the SCP interface, which uses shared memory
+to transfer commands and parameters, and a mailbox to trigger a function
+call. This allows SoCs without a separate management processor (or
+when such a processor is not available or used) to use this standardized
+interface anyway.
+
+This binding describes no hardware, but establishes a firmware interface.
+Upon receiving an SMC using one of the described SMC function identifiers,
+the firmware is expected to trigger some mailbox connected functionality.
+The communication follows the ARM SMC calling convention[1]:
+Firmware expects an SMC function identifier in r0 or w0 to identify a
+particular mailbox. The supported identifiers are listed in the the
+arm,func-ids properties, as described below.
+Apart from those mandatory SMC function identifier there are no further
+arguments handled by the receiving end.
+The firmware can return one value in the first SMC result register, it
+is expected to be an error value, which shall be propagated to the mailbox
+client.
+The C prototype of the function would be:
+	unsigned long smc_mailbox_call(unsigned long mailbox_identifier);
+The SMC function call is expected to be a fast call and could be from
+any of the defined function ranges.
+
+Any core which supports the SMC or HVC instruction can be used, as long as
+a firmware component running in EL3 or EL2 is handling these calls.
+
+Mailbox Device Node:
+====================
+
+This node is expected to be a child of the /firmware node.
+
+Required properties:
+--------------------
+- compatible:		Shall be "arm,smc-mbox"
+- #mbox-cells		Shall be 1 - the index of the channel needed.
+- arm,func-ids		An array of 32-bit values specifying the function
+			IDs used by each mailbox channel. Those function IDs
+			follow the ARM SMC calling convention standard [1].
+			There is one identifier per channel and the number
+			of supported channels is determined by the length
+			of this array.
+- method:		A string, either:
+			"hvc": if the driver shall use an HVC call, or
+			"smc": if the driver shall use an SMC call.
+
+Example:
+--------
+
+	smc_mbox: mailbox {
+		#mbox-cells = <1>;
+		compatible = "arm,smc-mbox";
+		arm,func-ids = <0x82000001>, <0x82000002>;
+	};
+
+	scpi {
+		compatible = "arm,scpi";
+		mboxes = <&mailbox 0>;
+		shmem = <&cpu_scp_shmem>;
+	};
+
+
+[1]
+http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0028a/index.html
-- 
2.8.2

[PATCH v2 1/3] DT: mailbox: add binding doc for the ARM SMC mailbox

[Andre Przywara]

The ARM SMC mailbox binding describes a firmware interface to trigger
actions in software layers running in the EL2 or EL3 exception levels.
The term "ARM" here relates to the SMC instruction as part of the ARM
instruction set, not as a standard endorsed by ARM Ltd.

Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
---
 .../devicetree/bindings/mailbox/arm-smc.txt        | 76 ++++++++++++++++++++++
 1 file changed, 76 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.txt

diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.txt b/Documentation/devicetree/bindings/mailbox/arm-smc.txt
new file mode 100644
index 0000000..d9de57b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm-smc.txt
@@ -0,0 +1,76 @@
+ARM SMC Mailbox Interface
+=========================
+
+This mailbox uses the ARM smc (secure monitor call) instruction to
+trigger a mailbox-connected activity in firmware, executing on the very same
+core as the caller. By nature this operation is synchronous and this
+mailbox provides no way for asynchronous messages to be delivered the other
+way round, from firmware to the OS. However the value of r0/w0/x0 the firmware
+returns after the smc call is delivered as a received message to the
+mailbox framework, so a synchronous communication can be established.
+The exact meaning of both the action the mailbox triggers as well as the
+return value is defined by their users and is not subject to this binding.
+
+One use case of this mailbox is the SCP interface, which uses shared memory
+to transfer commands and parameters, and a mailbox to trigger a function
+call. This allows SoCs without a separate management processor (or
+when such a processor is not available or used) to use this standardized
+interface anyway.
+
+This binding describes no hardware, but establishes a firmware interface.
+Upon receiving an SMC using one of the described SMC function identifiers,
+the firmware is expected to trigger some mailbox connected functionality.
+The communication follows the ARM SMC calling convention[1]:
+Firmware expects an SMC function identifier in r0 or w0 to identify a
+particular mailbox. The supported identifiers are listed in the the
+arm,func-ids properties, as described below.
+Apart from those mandatory SMC function identifier there are no further
+arguments handled by the receiving end.
+The firmware can return one value in the first SMC result register, it
+is expected to be an error value, which shall be propagated to the mailbox
+client.
+The C prototype of the function would be:
+	unsigned long smc_mailbox_call(unsigned long mailbox_identifier);
+The SMC function call is expected to be a fast call and could be from
+any of the defined function ranges.
+
+Any core which supports the SMC or HVC instruction can be used, as long as
+a firmware component running in EL3 or EL2 is handling these calls.
+
+Mailbox Device Node:
+====================
+
+This node is expected to be a child of the /firmware node.
+
+Required properties:
+--------------------
+- compatible:		Shall be "arm,smc-mbox"
+- #mbox-cells		Shall be 1 - the index of the channel needed.
+- arm,func-ids		An array of 32-bit values specifying the function
+			IDs used by each mailbox channel. Those function IDs
+			follow the ARM SMC calling convention standard [1].
+			There is one identifier per channel and the number
+			of supported channels is determined by the length
+			of this array.
+- method:		A string, either:
+			"hvc": if the driver shall use an HVC call, or
+			"smc": if the driver shall use an SMC call.
+
+Example:
+--------
+
+	smc_mbox: mailbox {
+		#mbox-cells = <1>;
+		compatible = "arm,smc-mbox";
+		arm,func-ids = <0x82000001>, <0x82000002>;
+	};
+
+	scpi {
+		compatible = "arm,scpi";
+		mboxes = <&mailbox 0>;
+		shmem = <&cpu_scp_shmem>;
+	};
+
+
+[1]
+http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0028a/index.html
-- 
2.8.2

[PATCH v2 1/3] DT: mailbox: add binding doc for the ARM SMC mailbox

[Andre Przywara]

The ARM SMC mailbox binding describes a firmware interface to trigger
actions in software layers running in the EL2 or EL3 exception levels.
The term "ARM" here relates to the SMC instruction as part of the ARM
instruction set, not as a standard endorsed by ARM Ltd.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 .../devicetree/bindings/mailbox/arm-smc.txt        | 76 ++++++++++++++++++++++
 1 file changed, 76 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.txt

diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.txt b/Documentation/devicetree/bindings/mailbox/arm-smc.txt
new file mode 100644
index 0000000..d9de57b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm-smc.txt
@@ -0,0 +1,76 @@
+ARM SMC Mailbox Interface
+=========================
+
+This mailbox uses the ARM smc (secure monitor call) instruction to
+trigger a mailbox-connected activity in firmware, executing on the very same
+core as the caller. By nature this operation is synchronous and this
+mailbox provides no way for asynchronous messages to be delivered the other
+way round, from firmware to the OS. However the value of r0/w0/x0 the firmware
+returns after the smc call is delivered as a received message to the
+mailbox framework, so a synchronous communication can be established.
+The exact meaning of both the action the mailbox triggers as well as the
+return value is defined by their users and is not subject to this binding.
+
+One use case of this mailbox is the SCP interface, which uses shared memory
+to transfer commands and parameters, and a mailbox to trigger a function
+call. This allows SoCs without a separate management processor (or
+when such a processor is not available or used) to use this standardized
+interface anyway.
+
+This binding describes no hardware, but establishes a firmware interface.
+Upon receiving an SMC using one of the described SMC function identifiers,
+the firmware is expected to trigger some mailbox connected functionality.
+The communication follows the ARM SMC calling convention[1]:
+Firmware expects an SMC function identifier in r0 or w0 to identify a
+particular mailbox. The supported identifiers are listed in the the
+arm,func-ids properties, as described below.
+Apart from those mandatory SMC function identifier there are no further
+arguments handled by the receiving end.
+The firmware can return one value in the first SMC result register, it
+is expected to be an error value, which shall be propagated to the mailbox
+client.
+The C prototype of the function would be:
+	unsigned long smc_mailbox_call(unsigned long mailbox_identifier);
+The SMC function call is expected to be a fast call and could be from
+any of the defined function ranges.
+
+Any core which supports the SMC or HVC instruction can be used, as long as
+a firmware component running in EL3 or EL2 is handling these calls.
+
+Mailbox Device Node:
+====================
+
+This node is expected to be a child of the /firmware node.
+
+Required properties:
+--------------------
+- compatible:		Shall be "arm,smc-mbox"
+- #mbox-cells		Shall be 1 - the index of the channel needed.
+- arm,func-ids		An array of 32-bit values specifying the function
+			IDs used by each mailbox channel. Those function IDs
+			follow the ARM SMC calling convention standard [1].
+			There is one identifier per channel and the number
+			of supported channels is determined by the length
+			of this array.
+- method:		A string, either:
+			"hvc": if the driver shall use an HVC call, or
+			"smc": if the driver shall use an SMC call.
+
+Example:
+--------
+
+	smc_mbox: mailbox {
+		#mbox-cells = <1>;
+		compatible = "arm,smc-mbox";
+		arm,func-ids = <0x82000001>, <0x82000002>;
+	};
+
+	scpi {
+		compatible = "arm,scpi";
+		mboxes = <&mailbox 0>;
+		shmem = <&cpu_scp_shmem>;
+	};
+
+
+[1]
+http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0028a/index.html
-- 
2.8.2

[PATCH v2 2/3] mailbox: introduce ARM SMC based mailbox

[Andre Przywara]

This mailbox driver implements a mailbox which signals transmitted data
via an ARM smc (secure monitor call) instruction. The mailbox receiver
is implemented in firmware and can synchronously return data when it
returns execution to the non-secure world again.
An asynchronous receive path is not implemented.
This allows the usage of a mailbox to trigger firmware actions on SoCs
which either don't have a separate management processor or on which such
a core is not available. A user of this mailbox could be the SCP
interface.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/mailbox/Kconfig           |   8 ++
 drivers/mailbox/Makefile          |   2 +
 drivers/mailbox/arm-smc-mailbox.c | 155 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 165 insertions(+)
 create mode 100644 drivers/mailbox/arm-smc-mailbox.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index c5731e5..5664b7f 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -170,4 +170,12 @@ config BCM_FLEXRM_MBOX
 	  Mailbox implementation of the Broadcom FlexRM ring manager,
 	  which provides access to various offload engines on Broadcom
 	  SoCs. Say Y here if you want to use the Broadcom FlexRM.
+
+config ARM_SMC_MBOX
+	tristate "Generic ARM smc mailbox"
+	depends on OF && HAVE_ARM_SMCCC
+	help
+	  Generic mailbox driver which uses ARM smc calls to call into
+	  firmware for triggering mailboxes.
+
 endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index d54e412..8ec6869 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -35,3 +35,5 @@ obj-$(CONFIG_BCM_FLEXRM_MBOX)	+= bcm-flexrm-mailbox.o
 obj-$(CONFIG_QCOM_APCS_IPC)	+= qcom-apcs-ipc-mailbox.o
 
 obj-$(CONFIG_TEGRA_HSP_MBOX)	+= tegra-hsp.o
+
+obj-$(CONFIG_ARM_SMC_MBOX)	+= arm-smc-mailbox.o
diff --git a/drivers/mailbox/arm-smc-mailbox.c b/drivers/mailbox/arm-smc-mailbox.c
new file mode 100644
index 0000000..d7b61a7
--- /dev/null
+++ b/drivers/mailbox/arm-smc-mailbox.c
@@ -0,0 +1,155 @@
+/*
+ *  Copyright (C) 2016,2017 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This device provides a mechanism for emulating a mailbox by using
+ * smc calls, allowing a "mailbox" consumer to sit in firmware running
+ * on the same core.
+ */
+
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/mailbox_controller.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/arm-smccc.h>
+
+#define ARM_SMC_MBOX_USE_HVC	BIT(0)
+
+struct arm_smc_chan_data {
+	u32 function_id;
+	u32 flags;
+};
+
+static int arm_smc_send_data(struct mbox_chan *link, void *data)
+{
+	struct arm_smc_chan_data *chan_data = link->con_priv;
+	u32 function_id = chan_data->function_id;
+	struct arm_smccc_res res;
+	u32 msg = *(u32 *)data;
+
+	if (chan_data->flags & ARM_SMC_MBOX_USE_HVC)
+		arm_smccc_hvc(function_id, msg, 0, 0, 0, 0, 0, 0, &res);
+	else
+		arm_smccc_smc(function_id, msg, 0, 0, 0, 0, 0, 0, &res);
+
+	mbox_chan_received_data(link, (void *)res.a0);
+
+	return 0;
+}
+
+/* This mailbox is synchronous, so we are always done. */
+static bool arm_smc_last_tx_done(struct mbox_chan *link)
+{
+	return true;
+}
+
+static const struct mbox_chan_ops arm_smc_mbox_chan_ops = {
+	.send_data	= arm_smc_send_data,
+	.last_tx_done	= arm_smc_last_tx_done
+};
+
+static int arm_smc_mbox_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct mbox_controller *mbox;
+	struct arm_smc_chan_data *chan_data;
+	const char *method;
+	bool use_hvc = false;
+	int ret, i;
+
+	ret = of_property_count_elems_of_size(dev->of_node, "arm,func-ids",
+					      sizeof(u32));
+	if (ret < 0)
+		return ret;
+
+	if (!of_property_read_string(dev->of_node, "method", &method)) {
+		if (!strcmp("hvc", method)) {
+			use_hvc = true;
+		} else if (!strcmp("smc", method)) {
+			use_hvc = false;
+		} else {
+			dev_warn(dev, "invalid \"method\" property: %s\n",
+				 method);
+
+			return -EINVAL;
+		}
+	}
+
+	mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
+	if (!mbox)
+		return -ENOMEM;
+
+	mbox->num_chans = ret;
+	mbox->chans = devm_kcalloc(dev, mbox->num_chans, sizeof(*mbox->chans),
+				   GFP_KERNEL);
+	if (!mbox->chans)
+		return -ENOMEM;
+
+	chan_data = devm_kcalloc(dev, mbox->num_chans, sizeof(*chan_data),
+				 GFP_KERNEL);
+	if (!chan_data)
+		return -ENOMEM;
+
+	for (i = 0; i < mbox->num_chans; i++) {
+		u32 function_id;
+
+		ret = of_property_read_u32_index(dev->of_node,
+						 "arm,func-ids", i,
+						 &function_id);
+		if (ret)
+			return ret;
+
+		chan_data[i].function_id = function_id;
+		if (use_hvc)
+			chan_data[i].flags |= ARM_SMC_MBOX_USE_HVC;
+		mbox->chans[i].con_priv = &chan_data[i];
+	}
+
+	mbox->txdone_poll = true;
+	mbox->txdone_irq = false;
+	mbox->txpoll_period = 1;
+	mbox->ops = &arm_smc_mbox_chan_ops;
+	mbox->dev = dev;
+
+	ret = mbox_controller_register(mbox);
+	if (ret)
+		return ret;
+
+	platform_set_drvdata(pdev, mbox);
+	dev_info(dev, "ARM SMC mailbox enabled with %d chan%s.\n",
+		 mbox->num_chans, mbox->num_chans == 1 ? "" : "s");
+
+	return ret;
+}
+
+static int arm_smc_mbox_remove(struct platform_device *pdev)
+{
+	struct mbox_controller *mbox = platform_get_drvdata(pdev);
+
+	mbox_controller_unregister(mbox);
+	return 0;
+}
+
+static const struct of_device_id arm_smc_mbox_of_match[] = {
+	{ .compatible = "arm,smc-mbox", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, arm_smc_mbox_of_match);
+
+static struct platform_driver arm_smc_mbox_driver = {
+	.driver = {
+		.name = "arm-smc-mbox",
+		.of_match_table = arm_smc_mbox_of_match,
+	},
+	.probe		= arm_smc_mbox_probe,
+	.remove		= arm_smc_mbox_remove,
+};
+module_platform_driver(arm_smc_mbox_driver);
+
+MODULE_AUTHOR("Andre Przywara <andre.przywara@arm.com>");
+MODULE_DESCRIPTION("Generic ARM smc mailbox driver");
+MODULE_LICENSE("GPL v2");
-- 
2.8.2

[PATCH v2 2/3] mailbox: introduce ARM SMC based mailbox

[Andre Przywara]

This mailbox driver implements a mailbox which signals transmitted data
via an ARM smc (secure monitor call) instruction. The mailbox receiver
is implemented in firmware and can synchronously return data when it
returns execution to the non-secure world again.
An asynchronous receive path is not implemented.
This allows the usage of a mailbox to trigger firmware actions on SoCs
which either don't have a separate management processor or on which such
a core is not available. A user of this mailbox could be the SCP
interface.

Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
---
 drivers/mailbox/Kconfig           |   8 ++
 drivers/mailbox/Makefile          |   2 +
 drivers/mailbox/arm-smc-mailbox.c | 155 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 165 insertions(+)
 create mode 100644 drivers/mailbox/arm-smc-mailbox.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index c5731e5..5664b7f 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -170,4 +170,12 @@ config BCM_FLEXRM_MBOX
 	  Mailbox implementation of the Broadcom FlexRM ring manager,
 	  which provides access to various offload engines on Broadcom
 	  SoCs. Say Y here if you want to use the Broadcom FlexRM.
+
+config ARM_SMC_MBOX
+	tristate "Generic ARM smc mailbox"
+	depends on OF && HAVE_ARM_SMCCC
+	help
+	  Generic mailbox driver which uses ARM smc calls to call into
+	  firmware for triggering mailboxes.
+
 endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index d54e412..8ec6869 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -35,3 +35,5 @@ obj-$(CONFIG_BCM_FLEXRM_MBOX)	+= bcm-flexrm-mailbox.o
 obj-$(CONFIG_QCOM_APCS_IPC)	+= qcom-apcs-ipc-mailbox.o
 
 obj-$(CONFIG_TEGRA_HSP_MBOX)	+= tegra-hsp.o
+
+obj-$(CONFIG_ARM_SMC_MBOX)	+= arm-smc-mailbox.o
diff --git a/drivers/mailbox/arm-smc-mailbox.c b/drivers/mailbox/arm-smc-mailbox.c
new file mode 100644
index 0000000..d7b61a7
--- /dev/null
+++ b/drivers/mailbox/arm-smc-mailbox.c
@@ -0,0 +1,155 @@
+/*
+ *  Copyright (C) 2016,2017 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This device provides a mechanism for emulating a mailbox by using
+ * smc calls, allowing a "mailbox" consumer to sit in firmware running
+ * on the same core.
+ */
+
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/mailbox_controller.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/arm-smccc.h>
+
+#define ARM_SMC_MBOX_USE_HVC	BIT(0)
+
+struct arm_smc_chan_data {
+	u32 function_id;
+	u32 flags;
+};
+
+static int arm_smc_send_data(struct mbox_chan *link, void *data)
+{
+	struct arm_smc_chan_data *chan_data = link->con_priv;
+	u32 function_id = chan_data->function_id;
+	struct arm_smccc_res res;
+	u32 msg = *(u32 *)data;
+
+	if (chan_data->flags & ARM_SMC_MBOX_USE_HVC)
+		arm_smccc_hvc(function_id, msg, 0, 0, 0, 0, 0, 0, &res);
+	else
+		arm_smccc_smc(function_id, msg, 0, 0, 0, 0, 0, 0, &res);
+
+	mbox_chan_received_data(link, (void *)res.a0);
+
+	return 0;
+}
+
+/* This mailbox is synchronous, so we are always done. */
+static bool arm_smc_last_tx_done(struct mbox_chan *link)
+{
+	return true;
+}
+
+static const struct mbox_chan_ops arm_smc_mbox_chan_ops = {
+	.send_data	= arm_smc_send_data,
+	.last_tx_done	= arm_smc_last_tx_done
+};
+
+static int arm_smc_mbox_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct mbox_controller *mbox;
+	struct arm_smc_chan_data *chan_data;
+	const char *method;
+	bool use_hvc = false;
+	int ret, i;
+
+	ret = of_property_count_elems_of_size(dev->of_node, "arm,func-ids",
+					      sizeof(u32));
+	if (ret < 0)
+		return ret;
+
+	if (!of_property_read_string(dev->of_node, "method", &method)) {
+		if (!strcmp("hvc", method)) {
+			use_hvc = true;
+		} else if (!strcmp("smc", method)) {
+			use_hvc = false;
+		} else {
+			dev_warn(dev, "invalid \"method\" property: %s\n",
+				 method);
+
+			return -EINVAL;
+		}
+	}
+
+	mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
+	if (!mbox)
+		return -ENOMEM;
+
+	mbox->num_chans = ret;
+	mbox->chans = devm_kcalloc(dev, mbox->num_chans, sizeof(*mbox->chans),
+				   GFP_KERNEL);
+	if (!mbox->chans)
+		return -ENOMEM;
+
+	chan_data = devm_kcalloc(dev, mbox->num_chans, sizeof(*chan_data),
+				 GFP_KERNEL);
+	if (!chan_data)
+		return -ENOMEM;
+
+	for (i = 0; i < mbox->num_chans; i++) {
+		u32 function_id;
+
+		ret = of_property_read_u32_index(dev->of_node,
+						 "arm,func-ids", i,
+						 &function_id);
+		if (ret)
+			return ret;
+
+		chan_data[i].function_id = function_id;
+		if (use_hvc)
+			chan_data[i].flags |= ARM_SMC_MBOX_USE_HVC;
+		mbox->chans[i].con_priv = &chan_data[i];
+	}
+
+	mbox->txdone_poll = true;
+	mbox->txdone_irq = false;
+	mbox->txpoll_period = 1;
+	mbox->ops = &arm_smc_mbox_chan_ops;
+	mbox->dev = dev;
+
+	ret = mbox_controller_register(mbox);
+	if (ret)
+		return ret;
+
+	platform_set_drvdata(pdev, mbox);
+	dev_info(dev, "ARM SMC mailbox enabled with %d chan%s.\n",
+		 mbox->num_chans, mbox->num_chans == 1 ? "" : "s");
+
+	return ret;
+}
+
+static int arm_smc_mbox_remove(struct platform_device *pdev)
+{
+	struct mbox_controller *mbox = platform_get_drvdata(pdev);
+
+	mbox_controller_unregister(mbox);
+	return 0;
+}
+
+static const struct of_device_id arm_smc_mbox_of_match[] = {
+	{ .compatible = "arm,smc-mbox", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, arm_smc_mbox_of_match);
+
+static struct platform_driver arm_smc_mbox_driver = {
+	.driver = {
+		.name = "arm-smc-mbox",
+		.of_match_table = arm_smc_mbox_of_match,
+	},
+	.probe		= arm_smc_mbox_probe,
+	.remove		= arm_smc_mbox_remove,
+};
+module_platform_driver(arm_smc_mbox_driver);
+
+MODULE_AUTHOR("Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>");
+MODULE_DESCRIPTION("Generic ARM smc mailbox driver");
+MODULE_LICENSE("GPL v2");
-- 
2.8.2

[PATCH v2 2/3] mailbox: introduce ARM SMC based mailbox

[Andre Przywara]

This mailbox driver implements a mailbox which signals transmitted data
via an ARM smc (secure monitor call) instruction. The mailbox receiver
is implemented in firmware and can synchronously return data when it
returns execution to the non-secure world again.
An asynchronous receive path is not implemented.
This allows the usage of a mailbox to trigger firmware actions on SoCs
which either don't have a separate management processor or on which such
a core is not available. A user of this mailbox could be the SCP
interface.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/mailbox/Kconfig           |   8 ++
 drivers/mailbox/Makefile          |   2 +
 drivers/mailbox/arm-smc-mailbox.c | 155 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 165 insertions(+)
 create mode 100644 drivers/mailbox/arm-smc-mailbox.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index c5731e5..5664b7f 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -170,4 +170,12 @@ config BCM_FLEXRM_MBOX
 	  Mailbox implementation of the Broadcom FlexRM ring manager,
 	  which provides access to various offload engines on Broadcom
 	  SoCs. Say Y here if you want to use the Broadcom FlexRM.
+
+config ARM_SMC_MBOX
+	tristate "Generic ARM smc mailbox"
+	depends on OF && HAVE_ARM_SMCCC
+	help
+	  Generic mailbox driver which uses ARM smc calls to call into
+	  firmware for triggering mailboxes.
+
 endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index d54e412..8ec6869 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -35,3 +35,5 @@ obj-$(CONFIG_BCM_FLEXRM_MBOX)	+= bcm-flexrm-mailbox.o
 obj-$(CONFIG_QCOM_APCS_IPC)	+= qcom-apcs-ipc-mailbox.o
 
 obj-$(CONFIG_TEGRA_HSP_MBOX)	+= tegra-hsp.o
+
+obj-$(CONFIG_ARM_SMC_MBOX)	+= arm-smc-mailbox.o
diff --git a/drivers/mailbox/arm-smc-mailbox.c b/drivers/mailbox/arm-smc-mailbox.c
new file mode 100644
index 0000000..d7b61a7
--- /dev/null
+++ b/drivers/mailbox/arm-smc-mailbox.c
@@ -0,0 +1,155 @@
+/*
+ *  Copyright (C) 2016,2017 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This device provides a mechanism for emulating a mailbox by using
+ * smc calls, allowing a "mailbox" consumer to sit in firmware running
+ * on the same core.
+ */
+
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/mailbox_controller.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/arm-smccc.h>
+
+#define ARM_SMC_MBOX_USE_HVC	BIT(0)
+
+struct arm_smc_chan_data {
+	u32 function_id;
+	u32 flags;
+};
+
+static int arm_smc_send_data(struct mbox_chan *link, void *data)
+{
+	struct arm_smc_chan_data *chan_data = link->con_priv;
+	u32 function_id = chan_data->function_id;
+	struct arm_smccc_res res;
+	u32 msg = *(u32 *)data;
+
+	if (chan_data->flags & ARM_SMC_MBOX_USE_HVC)
+		arm_smccc_hvc(function_id, msg, 0, 0, 0, 0, 0, 0, &res);
+	else
+		arm_smccc_smc(function_id, msg, 0, 0, 0, 0, 0, 0, &res);
+
+	mbox_chan_received_data(link, (void *)res.a0);
+
+	return 0;
+}
+
+/* This mailbox is synchronous, so we are always done. */
+static bool arm_smc_last_tx_done(struct mbox_chan *link)
+{
+	return true;
+}
+
+static const struct mbox_chan_ops arm_smc_mbox_chan_ops = {
+	.send_data	= arm_smc_send_data,
+	.last_tx_done	= arm_smc_last_tx_done
+};
+
+static int arm_smc_mbox_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct mbox_controller *mbox;
+	struct arm_smc_chan_data *chan_data;
+	const char *method;
+	bool use_hvc = false;
+	int ret, i;
+
+	ret = of_property_count_elems_of_size(dev->of_node, "arm,func-ids",
+					      sizeof(u32));
+	if (ret < 0)
+		return ret;
+
+	if (!of_property_read_string(dev->of_node, "method", &method)) {
+		if (!strcmp("hvc", method)) {
+			use_hvc = true;
+		} else if (!strcmp("smc", method)) {
+			use_hvc = false;
+		} else {
+			dev_warn(dev, "invalid \"method\" property: %s\n",
+				 method);
+
+			return -EINVAL;
+		}
+	}
+
+	mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
+	if (!mbox)
+		return -ENOMEM;
+
+	mbox->num_chans = ret;
+	mbox->chans = devm_kcalloc(dev, mbox->num_chans, sizeof(*mbox->chans),
+				   GFP_KERNEL);
+	if (!mbox->chans)
+		return -ENOMEM;
+
+	chan_data = devm_kcalloc(dev, mbox->num_chans, sizeof(*chan_data),
+				 GFP_KERNEL);
+	if (!chan_data)
+		return -ENOMEM;
+
+	for (i = 0; i < mbox->num_chans; i++) {
+		u32 function_id;
+
+		ret = of_property_read_u32_index(dev->of_node,
+						 "arm,func-ids", i,
+						 &function_id);
+		if (ret)
+			return ret;
+
+		chan_data[i].function_id = function_id;
+		if (use_hvc)
+			chan_data[i].flags |= ARM_SMC_MBOX_USE_HVC;
+		mbox->chans[i].con_priv = &chan_data[i];
+	}
+
+	mbox->txdone_poll = true;
+	mbox->txdone_irq = false;
+	mbox->txpoll_period = 1;
+	mbox->ops = &arm_smc_mbox_chan_ops;
+	mbox->dev = dev;
+
+	ret = mbox_controller_register(mbox);
+	if (ret)
+		return ret;
+
+	platform_set_drvdata(pdev, mbox);
+	dev_info(dev, "ARM SMC mailbox enabled with %d chan%s.\n",
+		 mbox->num_chans, mbox->num_chans == 1 ? "" : "s");
+
+	return ret;
+}
+
+static int arm_smc_mbox_remove(struct platform_device *pdev)
+{
+	struct mbox_controller *mbox = platform_get_drvdata(pdev);
+
+	mbox_controller_unregister(mbox);
+	return 0;
+}
+
+static const struct of_device_id arm_smc_mbox_of_match[] = {
+	{ .compatible = "arm,smc-mbox", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, arm_smc_mbox_of_match);
+
+static struct platform_driver arm_smc_mbox_driver = {
+	.driver = {
+		.name = "arm-smc-mbox",
+		.of_match_table = arm_smc_mbox_of_match,
+	},
+	.probe		= arm_smc_mbox_probe,
+	.remove		= arm_smc_mbox_remove,
+};
+module_platform_driver(arm_smc_mbox_driver);
+
+MODULE_AUTHOR("Andre Przywara <andre.przywara@arm.com>");
+MODULE_DESCRIPTION("Generic ARM smc mailbox driver");
+MODULE_LICENSE("GPL v2");
-- 
2.8.2

[PATCH v2 3/3] mailbox: Kconfig: enable ARM SMC mailbox on 64-bit Allwinner SoCs

[Andre Przywara]

For 64-bit Allwinner SoCs there exist firmware implementations which
provide SCPI controlled handlers for DVFS, sensors and power domains.
To allow usage of this features, enable the required SMC mailbox when
Allwinner SoCs are supported by the kernel.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/mailbox/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 5664b7f..6d6e8bb 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -174,6 +174,7 @@ config BCM_FLEXRM_MBOX
 config ARM_SMC_MBOX
 	tristate "Generic ARM smc mailbox"
 	depends on OF && HAVE_ARM_SMCCC
+	default y if ARM64 && ARCH_SUNXI
 	help
 	  Generic mailbox driver which uses ARM smc calls to call into
 	  firmware for triggering mailboxes.
-- 
2.8.2

[PATCH v2 3/3] mailbox: Kconfig: enable ARM SMC mailbox on 64-bit Allwinner SoCs

[Andre Przywara]

For 64-bit Allwinner SoCs there exist firmware implementations which
provide SCPI controlled handlers for DVFS, sensors and power domains.
To allow usage of this features, enable the required SMC mailbox when
Allwinner SoCs are supported by the kernel.

Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
---
 drivers/mailbox/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 5664b7f..6d6e8bb 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -174,6 +174,7 @@ config BCM_FLEXRM_MBOX
 config ARM_SMC_MBOX
 	tristate "Generic ARM smc mailbox"
 	depends on OF && HAVE_ARM_SMCCC
+	default y if ARM64 && ARCH_SUNXI
 	help
 	  Generic mailbox driver which uses ARM smc calls to call into
 	  firmware for triggering mailboxes.
-- 
2.8.2

[PATCH v2 3/3] mailbox: Kconfig: enable ARM SMC mailbox on 64-bit Allwinner SoCs

[Andre Przywara]

For 64-bit Allwinner SoCs there exist firmware implementations which
provide SCPI controlled handlers for DVFS, sensors and power domains.
To allow usage of this features, enable the required SMC mailbox when
Allwinner SoCs are supported by the kernel.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/mailbox/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 5664b7f..6d6e8bb 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -174,6 +174,7 @@ config BCM_FLEXRM_MBOX
 config ARM_SMC_MBOX
 	tristate "Generic ARM smc mailbox"
 	depends on OF && HAVE_ARM_SMCCC
+	default y if ARM64 && ARCH_SUNXI
 	help
 	  Generic mailbox driver which uses ARM smc calls to call into
 	  firmware for triggering mailboxes.
-- 
2.8.2

Re: [PATCH v2 2/3] mailbox: introduce ARM SMC based mailbox

[Alexey Klimov]

Hi Andre,

On Mon, Jul 24, 2017 at 12:23 AM, Andre Przywara <andre.przywara@arm.com> wrote:
> 
> This mailbox driver implements a mailbox which signals transmitted data
> via an ARM smc (secure monitor call) instruction. The mailbox receiver

As far as I can see, this driver also supports transmission via hvc.
However, almost everywhere here only smc instruction is mentioned.
Is it okay from your point of view?

> is implemented in firmware and can synchronously return data when it
> returns execution to the non-secure world again.
> An asynchronous receive path is not implemented.
> This allows the usage of a mailbox to trigger firmware actions on SoCs
> which either don't have a separate management processor or on which such
> a core is not available. A user of this mailbox could be the SCP
> interface.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  drivers/mailbox/Kconfig           |   8 ++
>  drivers/mailbox/Makefile          |   2 +
>  drivers/mailbox/arm-smc-mailbox.c | 155 ++++++++++++++++++++++++++++++++++++++
>  3 files changed, 165 insertions(+)
>  create mode 100644 drivers/mailbox/arm-smc-mailbox.c
> 
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> index c5731e5..5664b7f 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -170,4 +170,12 @@ config BCM_FLEXRM_MBOX
>           Mailbox implementation of the Broadcom FlexRM ring manager,
>           which provides access to various offload engines on Broadcom
>           SoCs. Say Y here if you want to use the Broadcom FlexRM.
> +
> +config ARM_SMC_MBOX
> +       tristate "Generic ARM smc mailbox"
> +       depends on OF && HAVE_ARM_SMCCC
> +       help
> +         Generic mailbox driver which uses ARM smc calls to call into
> +         firmware for triggering mailboxes.
> +
>  endif
> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> index d54e412..8ec6869 100644
> --- a/drivers/mailbox/Makefile
> +++ b/drivers/mailbox/Makefile
> @@ -35,3 +35,5 @@ obj-$(CONFIG_BCM_FLEXRM_MBOX) += bcm-flexrm-mailbox.o
>  obj-$(CONFIG_QCOM_APCS_IPC)    += qcom-apcs-ipc-mailbox.o
> 
>  obj-$(CONFIG_TEGRA_HSP_MBOX)   += tegra-hsp.o
> +
> +obj-$(CONFIG_ARM_SMC_MBOX)     += arm-smc-mailbox.o
> diff --git a/drivers/mailbox/arm-smc-mailbox.c
> b/drivers/mailbox/arm-smc-mailbox.c
> new file mode 100644
> index 0000000..d7b61a7
> --- /dev/null
> +++ b/drivers/mailbox/arm-smc-mailbox.c
> @@ -0,0 +1,155 @@
> +/*
> + *  Copyright (C) 2016,2017 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This device provides a mechanism for emulating a mailbox by using
> + * smc calls, allowing a "mailbox" consumer to sit in firmware running
> + * on the same core.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/kernel.h>
> +#include <linux/mailbox_controller.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/arm-smccc.h>
> +
> +#define ARM_SMC_MBOX_USE_HVC   BIT(0)
> +
> +struct arm_smc_chan_data {
> +       u32 function_id;
> +       u32 flags;
> +};
> +
> +static int arm_smc_send_data(struct mbox_chan *link, void *data)
> +{
> +       struct arm_smc_chan_data *chan_data = link->con_priv;
> +       u32 function_id = chan_data->function_id;
> +       struct arm_smccc_res res;
> +       u32 msg = *(u32 *)data;
> +
> +       if (chan_data->flags & ARM_SMC_MBOX_USE_HVC)
> +               arm_smccc_hvc(function_id, msg, 0, 0, 0, 0, 0, 0, &res);
> +       else
> +               arm_smccc_smc(function_id, msg, 0, 0, 0, 0, 0, 0, &res);
> +
> +       mbox_chan_received_data(link, (void *)res.a0);
> +
> +       return 0;
> +}
> +
> +/* This mailbox is synchronous, so we are always done. */
> +static bool arm_smc_last_tx_done(struct mbox_chan *link)
> +{
> +       return true;
> +}
> +
> +static const struct mbox_chan_ops arm_smc_mbox_chan_ops = {
> +       .send_data      = arm_smc_send_data,
> +       .last_tx_done   = arm_smc_last_tx_done
> +};

How the usage of timer-based polling tx_done method is justified (since it
always returns 'true')?

At the first glance, will it be more efficient to use TXDONE_BY_ACK here?
For instance, a controller will say:

	mbox->txdone_poll = false;
	mbox->txdone_irq = false;

and a client will say:

	cl->tx_block = true;
	cl->knows_txdone = true,

and the client will tick tx machinery with its mbox_client_txdone() immediately
after sending of message (since 'This mailbox is synchronous'). Otherwise,
why framework and client should wait >=1 ms before sending next message?



> +static int arm_smc_mbox_probe(struct platform_device *pdev)
> +{
> +       struct device *dev = &pdev->dev;
> +       struct mbox_controller *mbox;
> +       struct arm_smc_chan_data *chan_data;
> +       const char *method;
> +       bool use_hvc = false;
> +       int ret, i;
> +
> +       ret = of_property_count_elems_of_size(dev->of_node, "arm,func-ids",
> +                                             sizeof(u32));
> +       if (ret < 0)
> +               return ret;
> +
> +       if (!of_property_read_string(dev->of_node, "method", &method)) {
> +               if (!strcmp("hvc", method)) {
> +                       use_hvc = true;
> +               } else if (!strcmp("smc", method)) {
> +                       use_hvc = false;
> +               } else {
> +                       dev_warn(dev, "invalid \"method\" property: %s\n",
> +                                method);
> +
> +                       return -EINVAL;
> +               }
> +       }
> +
> +       mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
> +       if (!mbox)
> +               return -ENOMEM;
> +
> +       mbox->num_chans = ret;
> +       mbox->chans = devm_kcalloc(dev, mbox->num_chans, sizeof(*mbox->chans),
> +                                  GFP_KERNEL);
> +       if (!mbox->chans)
> +               return -ENOMEM;
> +
> +       chan_data = devm_kcalloc(dev, mbox->num_chans, sizeof(*chan_data),
> +                                GFP_KERNEL);
> +       if (!chan_data)
> +               return -ENOMEM;
> +
> +       for (i = 0; i < mbox->num_chans; i++) {
> +               u32 function_id;
> +
> +               ret = of_property_read_u32_index(dev->of_node,
> +                                                "arm,func-ids", i,
> +                                                &function_id);
> +               if (ret)
> +                       return ret;
> +
> +               chan_data[i].function_id = function_id;
> +               if (use_hvc)
> +                       chan_data[i].flags |= ARM_SMC_MBOX_USE_HVC;
> +               mbox->chans[i].con_priv = &chan_data[i];
> +       }
> +
> +       mbox->txdone_poll = true;
> +       mbox->txdone_irq = false;
> +       mbox->txpoll_period = 1;
> +       mbox->ops = &arm_smc_mbox_chan_ops;
> +       mbox->dev = dev;
> +
> +       ret = mbox_controller_register(mbox);
> +       if (ret)
> +               return ret;
> +
> +       platform_set_drvdata(pdev, mbox);
> +       dev_info(dev, "ARM SMC mailbox enabled with %d chan%s.\n",
> +                mbox->num_chans, mbox->num_chans == 1 ? "" : "s");


Out of curiosity, did you try to use more than one channel with this driver?


[..]

Best regards,
Alexey

[PATCH v2 2/3] mailbox: introduce ARM SMC based mailbox

[Alexey Klimov]

Hi Andre,

On Mon, Jul 24, 2017 at 12:23 AM, Andre Przywara <andre.przywara@arm.com> wrote:
> 
> This mailbox driver implements a mailbox which signals transmitted data
> via an ARM smc (secure monitor call) instruction. The mailbox receiver

As far as I can see, this driver also supports transmission via hvc.
However, almost everywhere here only smc instruction is mentioned.
Is it okay from your point of view?

> is implemented in firmware and can synchronously return data when it
> returns execution to the non-secure world again.
> An asynchronous receive path is not implemented.
> This allows the usage of a mailbox to trigger firmware actions on SoCs
> which either don't have a separate management processor or on which such
> a core is not available. A user of this mailbox could be the SCP
> interface.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  drivers/mailbox/Kconfig           |   8 ++
>  drivers/mailbox/Makefile          |   2 +
>  drivers/mailbox/arm-smc-mailbox.c | 155 ++++++++++++++++++++++++++++++++++++++
>  3 files changed, 165 insertions(+)
>  create mode 100644 drivers/mailbox/arm-smc-mailbox.c
> 
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> index c5731e5..5664b7f 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -170,4 +170,12 @@ config BCM_FLEXRM_MBOX
>           Mailbox implementation of the Broadcom FlexRM ring manager,
>           which provides access to various offload engines on Broadcom
>           SoCs. Say Y here if you want to use the Broadcom FlexRM.
> +
> +config ARM_SMC_MBOX
> +       tristate "Generic ARM smc mailbox"
> +       depends on OF && HAVE_ARM_SMCCC
> +       help
> +         Generic mailbox driver which uses ARM smc calls to call into
> +         firmware for triggering mailboxes.
> +
>  endif
> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> index d54e412..8ec6869 100644
> --- a/drivers/mailbox/Makefile
> +++ b/drivers/mailbox/Makefile
> @@ -35,3 +35,5 @@ obj-$(CONFIG_BCM_FLEXRM_MBOX) += bcm-flexrm-mailbox.o
>  obj-$(CONFIG_QCOM_APCS_IPC)    += qcom-apcs-ipc-mailbox.o
> 
>  obj-$(CONFIG_TEGRA_HSP_MBOX)   += tegra-hsp.o
> +
> +obj-$(CONFIG_ARM_SMC_MBOX)     += arm-smc-mailbox.o
> diff --git a/drivers/mailbox/arm-smc-mailbox.c
> b/drivers/mailbox/arm-smc-mailbox.c
> new file mode 100644
> index 0000000..d7b61a7
> --- /dev/null
> +++ b/drivers/mailbox/arm-smc-mailbox.c
> @@ -0,0 +1,155 @@
> +/*
> + *  Copyright (C) 2016,2017 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This device provides a mechanism for emulating a mailbox by using
> + * smc calls, allowing a "mailbox" consumer to sit in firmware running
> + * on the same core.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/kernel.h>
> +#include <linux/mailbox_controller.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/arm-smccc.h>
> +
> +#define ARM_SMC_MBOX_USE_HVC   BIT(0)
> +
> +struct arm_smc_chan_data {
> +       u32 function_id;
> +       u32 flags;
> +};
> +
> +static int arm_smc_send_data(struct mbox_chan *link, void *data)
> +{
> +       struct arm_smc_chan_data *chan_data = link->con_priv;
> +       u32 function_id = chan_data->function_id;
> +       struct arm_smccc_res res;
> +       u32 msg = *(u32 *)data;
> +
> +       if (chan_data->flags & ARM_SMC_MBOX_USE_HVC)
> +               arm_smccc_hvc(function_id, msg, 0, 0, 0, 0, 0, 0, &res);
> +       else
> +               arm_smccc_smc(function_id, msg, 0, 0, 0, 0, 0, 0, &res);
> +
> +       mbox_chan_received_data(link, (void *)res.a0);
> +
> +       return 0;
> +}
> +
> +/* This mailbox is synchronous, so we are always done. */
> +static bool arm_smc_last_tx_done(struct mbox_chan *link)
> +{
> +       return true;
> +}
> +
> +static const struct mbox_chan_ops arm_smc_mbox_chan_ops = {
> +       .send_data      = arm_smc_send_data,
> +       .last_tx_done   = arm_smc_last_tx_done
> +};

How the usage of timer-based polling tx_done method is justified (since it
always returns 'true')?

At the first glance, will it be more efficient to use TXDONE_BY_ACK here?
For instance, a controller will say:

	mbox->txdone_poll = false;
	mbox->txdone_irq = false;

and a client will say:

	cl->tx_block = true;
	cl->knows_txdone = true,

and the client will tick tx machinery with its mbox_client_txdone() immediately
after sending of message (since 'This mailbox is synchronous'). Otherwise,
why framework and client should wait >=1 ms before sending next message?



> +static int arm_smc_mbox_probe(struct platform_device *pdev)
> +{
> +       struct device *dev = &pdev->dev;
> +       struct mbox_controller *mbox;
> +       struct arm_smc_chan_data *chan_data;
> +       const char *method;
> +       bool use_hvc = false;
> +       int ret, i;
> +
> +       ret = of_property_count_elems_of_size(dev->of_node, "arm,func-ids",
> +                                             sizeof(u32));
> +       if (ret < 0)
> +               return ret;
> +
> +       if (!of_property_read_string(dev->of_node, "method", &method)) {
> +               if (!strcmp("hvc", method)) {
> +                       use_hvc = true;
> +               } else if (!strcmp("smc", method)) {
> +                       use_hvc = false;
> +               } else {
> +                       dev_warn(dev, "invalid \"method\" property: %s\n",
> +                                method);
> +
> +                       return -EINVAL;
> +               }
> +       }
> +
> +       mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
> +       if (!mbox)
> +               return -ENOMEM;
> +
> +       mbox->num_chans = ret;
> +       mbox->chans = devm_kcalloc(dev, mbox->num_chans, sizeof(*mbox->chans),
> +                                  GFP_KERNEL);
> +       if (!mbox->chans)
> +               return -ENOMEM;
> +
> +       chan_data = devm_kcalloc(dev, mbox->num_chans, sizeof(*chan_data),
> +                                GFP_KERNEL);
> +       if (!chan_data)
> +               return -ENOMEM;
> +
> +       for (i = 0; i < mbox->num_chans; i++) {
> +               u32 function_id;
> +
> +               ret = of_property_read_u32_index(dev->of_node,
> +                                                "arm,func-ids", i,
> +                                                &function_id);
> +               if (ret)
> +                       return ret;
> +
> +               chan_data[i].function_id = function_id;
> +               if (use_hvc)
> +                       chan_data[i].flags |= ARM_SMC_MBOX_USE_HVC;
> +               mbox->chans[i].con_priv = &chan_data[i];
> +       }
> +
> +       mbox->txdone_poll = true;
> +       mbox->txdone_irq = false;
> +       mbox->txpoll_period = 1;
> +       mbox->ops = &arm_smc_mbox_chan_ops;
> +       mbox->dev = dev;
> +
> +       ret = mbox_controller_register(mbox);
> +       if (ret)
> +               return ret;
> +
> +       platform_set_drvdata(pdev, mbox);
> +       dev_info(dev, "ARM SMC mailbox enabled with %d chan%s.\n",
> +                mbox->num_chans, mbox->num_chans == 1 ? "" : "s");


Out of curiosity, did you try to use more than one channel with this driver?


[..]

Best regards,
Alexey

Re: [PATCH v2 0/3] mailbox: arm: introduce smc triggered mailbox

[Alexander Graf]

Hi Andre,

On 24.07.17 01:23, Andre Przywara wrote:
> This is a reworked version of my previous post. It addresses Jassi's
> comments on the driver and also tries to cover Rob's and Mark's comments
> on the binding documentation.
> I dropped the more example-like DT changes from v1, as they are actually
> not meant to be merged into the Linux tree, but instead are provided as
> part of some firmware actually implementing this functionality.
> 
> Please let me know what you think.

Could you please quickly explain what it would take to provide SCMI on 
top of this instead of SCPI?

https://lkml.org/lkml/2017/6/7/624

I can certainly see that SCPI is an easier target because it's already 
upstream and widely spread. But wouldn't it make sense to jump on the 
SCMI train while it's taking steam?


Thanks,

Alex

[PATCH v2 0/3] mailbox: arm: introduce smc triggered mailbox

[Alexander Graf]

Hi Andre,

On 24.07.17 01:23, Andre Przywara wrote:
> This is a reworked version of my previous post. It addresses Jassi's
> comments on the driver and also tries to cover Rob's and Mark's comments
> on the binding documentation.
> I dropped the more example-like DT changes from v1, as they are actually
> not meant to be merged into the Linux tree, but instead are provided as
> part of some firmware actually implementing this functionality.
> 
> Please let me know what you think.

Could you please quickly explain what it would take to provide SCMI on 
top of this instead of SCPI?

https://lkml.org/lkml/2017/6/7/624

I can certainly see that SCPI is an easier target because it's already 
upstream and widely spread. But wouldn't it make sense to jump on the 
SCMI train while it's taking steam?


Thanks,

Alex

Re: [PATCH v2 0/3] mailbox: arm: introduce smc triggered mailbox

[Jassi Brar]

On Tue, Aug 1, 2017 at 4:20 PM, Alexander Graf <agraf@suse.de> wrote:
> Hi Andre,
>
> On 24.07.17 01:23, Andre Przywara wrote:
>>
>> This is a reworked version of my previous post. It addresses Jassi's
>> comments on the driver and also tries to cover Rob's and Mark's comments
>> on the binding documentation.
>> I dropped the more example-like DT changes from v1, as they are actually
>> not meant to be merged into the Linux tree, but instead are provided as
>> part of some firmware actually implementing this functionality.
>>
>> Please let me know what you think.
>
>
> Could you please quickly explain what it would take to provide SCMI on top
> of this instead of SCPI?
>
> https://lkml.org/lkml/2017/6/7/624
>
The SCMI (and SCPI) code is broken, that is, unless the firmware/SM is
trained to ignore the random value (pointer to a structure) passed via
R1. Which may be possible to do, but is surely a sign of poor
implementation. And may not be possible if some protocol other than
SCMI runs in parallel.

Andre, your take please?

Thanks.

Re: [PATCH v2 0/3] mailbox: arm: introduce smc triggered mailbox

[Jassi Brar]

On Tue, Aug 1, 2017 at 4:20 PM, Alexander Graf <agraf@suse.de> wrote:
> Hi Andre,
>
> On 24.07.17 01:23, Andre Przywara wrote:
>>
>> This is a reworked version of my previous post. It addresses Jassi's
>> comments on the driver and also tries to cover Rob's and Mark's comments
>> on the binding documentation.
>> I dropped the more example-like DT changes from v1, as they are actually
>> not meant to be merged into the Linux tree, but instead are provided as
>> part of some firmware actually implementing this functionality.
>>
>> Please let me know what you think.
>
>
> Could you please quickly explain what it would take to provide SCMI on top
> of this instead of SCPI?
>
> https://lkml.org/lkml/2017/6/7/624
>
The SCMI (and SCPI) code is broken, that is, unless the firmware/SM is
trained to ignore the random value (pointer to a structure) passed via
R1. Which may be possible to do, but is surely a sign of poor
implementation. And may not be possible if some protocol other than
SCMI runs in parallel.

Andre, your take please?

Thanks.

[PATCH v2 0/3] mailbox: arm: introduce smc triggered mailbox

[Jassi Brar]

On Tue, Aug 1, 2017 at 4:20 PM, Alexander Graf <agraf@suse.de> wrote:
> Hi Andre,
>
> On 24.07.17 01:23, Andre Przywara wrote:
>>
>> This is a reworked version of my previous post. It addresses Jassi's
>> comments on the driver and also tries to cover Rob's and Mark's comments
>> on the binding documentation.
>> I dropped the more example-like DT changes from v1, as they are actually
>> not meant to be merged into the Linux tree, but instead are provided as
>> part of some firmware actually implementing this functionality.
>>
>> Please let me know what you think.
>
>
> Could you please quickly explain what it would take to provide SCMI on top
> of this instead of SCPI?
>
> https://lkml.org/lkml/2017/6/7/624
>
The SCMI (and SCPI) code is broken, that is, unless the firmware/SM is
trained to ignore the random value (pointer to a structure) passed via
R1. Which may be possible to do, but is surely a sign of poor
implementation. And may not be possible if some protocol other than
SCMI runs in parallel.

Andre, your take please?

Thanks.

Re: [PATCH v2 2/3] mailbox: introduce ARM SMC based mailbox

[Jassi Brar]

On Mon, Jul 24, 2017 at 4:53 AM, Andre Przywara <andre.przywara@arm.com> wrote:

> +static int arm_smc_send_data(struct mbox_chan *link, void *data)
> +{
> +       struct arm_smc_chan_data *chan_data = link->con_priv;
> +       u32 function_id = chan_data->function_id;
> +       struct arm_smccc_res res;
> +       u32 msg = *(u32 *)data;
> +
> +       if (chan_data->flags & ARM_SMC_MBOX_USE_HVC)
> +               arm_smccc_hvc(function_id, msg, 0, 0, 0, 0, 0, 0, &res);
> +       else
> +               arm_smccc_smc(function_id, msg, 0, 0, 0, 0, 0, 0, &res);
> +
Sorry, I didn't notice earlier that you cull parameters [R2, R7] to
SMC/HVC call by making them all 0s ...
        arm_smccc_smc(function_id, msg, 0, 0, 0, 0, 0, 0, &res);

I see you have SCMI/SCPI on your mind, however we need to make
controller drivers independent of users.

I think this driver should simply emulate mailbox over the SMC/HVC
calls. That is, respect all parameters.
So maybe we should define a
   struct arm_smccc_mbox_cmd {
         unsigned long a0, a1, a2, a3, a4, a5, a6, a7;
   }

and have
static int arm_smc_send_data(struct mbox_chan *link, void *data)
{
       struct arm_smc_chan_data *chan_data = link->con_priv;
       struct arm_smccc_res res;
       struct arm_smccc_mbox_cmd *cmd = data;
       u32 function_id = cmd->a0;

       ..... and pass cmd.{a1, a2, a3, a4, a5, a6, a7} to the SMC/HVC call.
          ....
}

And BTW, instead of specifying 'func-ids' in DT, we can have
'num-chans' which will tell how many identical channels to populate.
Also because the Function-Identifier seems like belong to the client
driver more than controller.

Cheers!

Re: [PATCH v2 2/3] mailbox: introduce ARM SMC based mailbox

[Jassi Brar]

On Mon, Jul 24, 2017 at 4:53 AM, Andre Przywara <andre.przywara@arm.com> wrote:

> +static int arm_smc_send_data(struct mbox_chan *link, void *data)
> +{
> +       struct arm_smc_chan_data *chan_data = link->con_priv;
> +       u32 function_id = chan_data->function_id;
> +       struct arm_smccc_res res;
> +       u32 msg = *(u32 *)data;
> +
> +       if (chan_data->flags & ARM_SMC_MBOX_USE_HVC)
> +               arm_smccc_hvc(function_id, msg, 0, 0, 0, 0, 0, 0, &res);
> +       else
> +               arm_smccc_smc(function_id, msg, 0, 0, 0, 0, 0, 0, &res);
> +
Sorry, I didn't notice earlier that you cull parameters [R2, R7] to
SMC/HVC call by making them all 0s ...
        arm_smccc_smc(function_id, msg, 0, 0, 0, 0, 0, 0, &res);

I see you have SCMI/SCPI on your mind, however we need to make
controller drivers independent of users.

I think this driver should simply emulate mailbox over the SMC/HVC
calls. That is, respect all parameters.
So maybe we should define a
   struct arm_smccc_mbox_cmd {
         unsigned long a0, a1, a2, a3, a4, a5, a6, a7;
   }

and have
static int arm_smc_send_data(struct mbox_chan *link, void *data)
{
       struct arm_smc_chan_data *chan_data = link->con_priv;
       struct arm_smccc_res res;
       struct arm_smccc_mbox_cmd *cmd = data;
       u32 function_id = cmd->a0;

       ..... and pass cmd.{a1, a2, a3, a4, a5, a6, a7} to the SMC/HVC call.
          ....
}

And BTW, instead of specifying 'func-ids' in DT, we can have
'num-chans' which will tell how many identical channels to populate.
Also because the Function-Identifier seems like belong to the client
driver more than controller.

Cheers!

[PATCH v2 2/3] mailbox: introduce ARM SMC based mailbox

[Jassi Brar]

On Mon, Jul 24, 2017 at 4:53 AM, Andre Przywara <andre.przywara@arm.com> wrote:

> +static int arm_smc_send_data(struct mbox_chan *link, void *data)
> +{
> +       struct arm_smc_chan_data *chan_data = link->con_priv;
> +       u32 function_id = chan_data->function_id;
> +       struct arm_smccc_res res;
> +       u32 msg = *(u32 *)data;
> +
> +       if (chan_data->flags & ARM_SMC_MBOX_USE_HVC)
> +               arm_smccc_hvc(function_id, msg, 0, 0, 0, 0, 0, 0, &res);
> +       else
> +               arm_smccc_smc(function_id, msg, 0, 0, 0, 0, 0, 0, &res);
> +
Sorry, I didn't notice earlier that you cull parameters [R2, R7] to
SMC/HVC call by making them all 0s ...
        arm_smccc_smc(function_id, msg, 0, 0, 0, 0, 0, 0, &res);

I see you have SCMI/SCPI on your mind, however we need to make
controller drivers independent of users.

I think this driver should simply emulate mailbox over the SMC/HVC
calls. That is, respect all parameters.
So maybe we should define a
   struct arm_smccc_mbox_cmd {
         unsigned long a0, a1, a2, a3, a4, a5, a6, a7;
   }

and have
static int arm_smc_send_data(struct mbox_chan *link, void *data)
{
       struct arm_smc_chan_data *chan_data = link->con_priv;
       struct arm_smccc_res res;
       struct arm_smccc_mbox_cmd *cmd = data;
       u32 function_id = cmd->a0;

       ..... and pass cmd.{a1, a2, a3, a4, a5, a6, a7} to the SMC/HVC call.
          ....
}

And BTW, instead of specifying 'func-ids' in DT, we can have
'num-chans' which will tell how many identical channels to populate.
Also because the Function-Identifier seems like belong to the client
driver more than controller.

Cheers!

Re: [PATCH v2 0/3] mailbox: arm: introduce smc triggered mailbox

[Sudeep Holla]

(sorry for SCPI/SCMI discussion in this thread)

On 01/08/17 16:50, Jassi Brar wrote:
> On Tue, Aug 1, 2017 at 4:20 PM, Alexander Graf <agraf@suse.de> wrote:
>> Hi Andre,
>>
>> On 24.07.17 01:23, Andre Przywara wrote:
>>>
>>> This is a reworked version of my previous post. It addresses Jassi's
>>> comments on the driver and also tries to cover Rob's and Mark's comments
>>> on the binding documentation.
>>> I dropped the more example-like DT changes from v1, as they are actually
>>> not meant to be merged into the Linux tree, but instead are provided as
>>> part of some firmware actually implementing this functionality.
>>>
>>> Please let me know what you think.
>>
>>
>> Could you please quickly explain what it would take to provide SCMI on top
>> of this instead of SCPI?
>>
>> https://lkml.org/lkml/2017/6/7/624
>>
> The SCMI (and SCPI) code is broken, that is, unless the firmware/SM is
> trained to ignore the random value (pointer to a structure) passed via
> R1. Which may be possible to do, but is surely a sign of poor
> implementation. And may not be possible if some protocol other than
> SCMI runs in parallel.
> 

Since SCPI and SCMI are based on doorbell designs like ACPI PCC, they
can't send any data as all the data are part of shared memory.

What data needs to be sent from SCPI/SCMI as part of mbox_send_message
in your opinion ? I can't think of any generic way to form this data.

It's not possible to generalize that and SCPI/SCMI's transport is
specifically designed in that way to avoid any kind of dependency
on the mailbox hardware so that the protocol can be generic exactly like
ACPI PCC.

I understand your concern on how existing mailbox controllers work with
it. They can't as they stand today as they expect some specific data
based on the hardware or the protocol they support on it.

One option to deal with this is to have a generic DT based doorbell kind
of controller driver but I am not sure if we can define register level
bindings like ACPI PCC.

Or we teach them to ignore the data if it's not present. I don't like
the idea of adding shim layer for each of the controller as each one
expect different format and more over SCPI/SCMI doesn't even require it
to support SCMI on those mailbox controllers. That may end up with 2x
drivers(one actual driver and and another shim layer for it)

-- 
Regards,
Sudeep

Re: [PATCH v2 0/3] mailbox: arm: introduce smc triggered mailbox

[Sudeep Holla]

(sorry for SCPI/SCMI discussion in this thread)

On 01/08/17 16:50, Jassi Brar wrote:
> On Tue, Aug 1, 2017 at 4:20 PM, Alexander Graf <agraf@suse.de> wrote:
>> Hi Andre,
>>
>> On 24.07.17 01:23, Andre Przywara wrote:
>>>
>>> This is a reworked version of my previous post. It addresses Jassi's
>>> comments on the driver and also tries to cover Rob's and Mark's comments
>>> on the binding documentation.
>>> I dropped the more example-like DT changes from v1, as they are actually
>>> not meant to be merged into the Linux tree, but instead are provided as
>>> part of some firmware actually implementing this functionality.
>>>
>>> Please let me know what you think.
>>
>>
>> Could you please quickly explain what it would take to provide SCMI on top
>> of this instead of SCPI?
>>
>> https://lkml.org/lkml/2017/6/7/624
>>
> The SCMI (and SCPI) code is broken, that is, unless the firmware/SM is
> trained to ignore the random value (pointer to a structure) passed via
> R1. Which may be possible to do, but is surely a sign of poor
> implementation. And may not be possible if some protocol other than
> SCMI runs in parallel.
> 

Since SCPI and SCMI are based on doorbell designs like ACPI PCC, they
can't send any data as all the data are part of shared memory.

What data needs to be sent from SCPI/SCMI as part of mbox_send_message
in your opinion ? I can't think of any generic way to form this data.

It's not possible to generalize that and SCPI/SCMI's transport is
specifically designed in that way to avoid any kind of dependency
on the mailbox hardware so that the protocol can be generic exactly like
ACPI PCC.

I understand your concern on how existing mailbox controllers work with
it. They can't as they stand today as they expect some specific data
based on the hardware or the protocol they support on it.

One option to deal with this is to have a generic DT based doorbell kind
of controller driver but I am not sure if we can define register level
bindings like ACPI PCC.

Or we teach them to ignore the data if it's not present. I don't like
the idea of adding shim layer for each of the controller as each one
expect different format and more over SCPI/SCMI doesn't even require it
to support SCMI on those mailbox controllers. That may end up with 2x
drivers(one actual driver and and another shim layer for it)

-- 
Regards,
Sudeep

[PATCH v2 0/3] mailbox: arm: introduce smc triggered mailbox

[Sudeep Holla]

(sorry for SCPI/SCMI discussion in this thread)

On 01/08/17 16:50, Jassi Brar wrote:
> On Tue, Aug 1, 2017 at 4:20 PM, Alexander Graf <agraf@suse.de> wrote:
>> Hi Andre,
>>
>> On 24.07.17 01:23, Andre Przywara wrote:
>>>
>>> This is a reworked version of my previous post. It addresses Jassi's
>>> comments on the driver and also tries to cover Rob's and Mark's comments
>>> on the binding documentation.
>>> I dropped the more example-like DT changes from v1, as they are actually
>>> not meant to be merged into the Linux tree, but instead are provided as
>>> part of some firmware actually implementing this functionality.
>>>
>>> Please let me know what you think.
>>
>>
>> Could you please quickly explain what it would take to provide SCMI on top
>> of this instead of SCPI?
>>
>> https://lkml.org/lkml/2017/6/7/624
>>
> The SCMI (and SCPI) code is broken, that is, unless the firmware/SM is
> trained to ignore the random value (pointer to a structure) passed via
> R1. Which may be possible to do, but is surely a sign of poor
> implementation. And may not be possible if some protocol other than
> SCMI runs in parallel.
> 

Since SCPI and SCMI are based on doorbell designs like ACPI PCC, they
can't send any data as all the data are part of shared memory.

What data needs to be sent from SCPI/SCMI as part of mbox_send_message
in your opinion ? I can't think of any generic way to form this data.

It's not possible to generalize that and SCPI/SCMI's transport is
specifically designed in that way to avoid any kind of dependency
on the mailbox hardware so that the protocol can be generic exactly like
ACPI PCC.

I understand your concern on how existing mailbox controllers work with
it. They can't as they stand today as they expect some specific data
based on the hardware or the protocol they support on it.

One option to deal with this is to have a generic DT based doorbell kind
of controller driver but I am not sure if we can define register level
bindings like ACPI PCC.

Or we teach them to ignore the data if it's not present. I don't like
the idea of adding shim layer for each of the controller as each one
expect different format and more over SCPI/SCMI doesn't even require it
to support SCMI on those mailbox controllers. That may end up with 2x
drivers(one actual driver and and another shim layer for it)

-- 
Regards,
Sudeep

Re: [PATCH v2 1/3] DT: mailbox: add binding doc for the ARM SMC mailbox

[Rob Herring]

On Mon, Jul 24, 2017 at 12:23:24AM +0100, Andre Przywara wrote:
> The ARM SMC mailbox binding describes a firmware interface to trigger
> actions in software layers running in the EL2 or EL3 exception levels.
> The term "ARM" here relates to the SMC instruction as part of the ARM
> instruction set, not as a standard endorsed by ARM Ltd.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  .../devicetree/bindings/mailbox/arm-smc.txt        | 76 ++++++++++++++++++++++
>  1 file changed, 76 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.txt
> 
> diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.txt b/Documentation/devicetree/bindings/mailbox/arm-smc.txt
> new file mode 100644
> index 0000000..d9de57b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.txt
> @@ -0,0 +1,76 @@
> +ARM SMC Mailbox Interface
> +=========================
> +
> +This mailbox uses the ARM smc (secure monitor call) instruction to
> +trigger a mailbox-connected activity in firmware, executing on the very same
> +core as the caller. By nature this operation is synchronous and this
> +mailbox provides no way for asynchronous messages to be delivered the other
> +way round, from firmware to the OS. However the value of r0/w0/x0 the firmware
> +returns after the smc call is delivered as a received message to the
> +mailbox framework, so a synchronous communication can be established.
> +The exact meaning of both the action the mailbox triggers as well as the
> +return value is defined by their users and is not subject to this binding.
> +
> +One use case of this mailbox is the SCP interface, which uses shared memory
> +to transfer commands and parameters, and a mailbox to trigger a function
> +call. This allows SoCs without a separate management processor (or
> +when such a processor is not available or used) to use this standardized
> +interface anyway.
> +
> +This binding describes no hardware, but establishes a firmware interface.
> +Upon receiving an SMC using one of the described SMC function identifiers,
> +the firmware is expected to trigger some mailbox connected functionality.
> +The communication follows the ARM SMC calling convention[1]:
> +Firmware expects an SMC function identifier in r0 or w0 to identify a
> +particular mailbox. The supported identifiers are listed in the the
> +arm,func-ids properties, as described below.
> +Apart from those mandatory SMC function identifier there are no further
> +arguments handled by the receiving end.
> +The firmware can return one value in the first SMC result register, it
> +is expected to be an error value, which shall be propagated to the mailbox
> +client.
> +The C prototype of the function would be:
> +	unsigned long smc_mailbox_call(unsigned long mailbox_identifier);
> +The SMC function call is expected to be a fast call and could be from
> +any of the defined function ranges.
> +
> +Any core which supports the SMC or HVC instruction can be used, as long as
> +a firmware component running in EL3 or EL2 is handling these calls.
> +
> +Mailbox Device Node:
> +====================
> +
> +This node is expected to be a child of the /firmware node.
> +
> +Required properties:
> +--------------------
> +- compatible:		Shall be "arm,smc-mbox"
> +- #mbox-cells		Shall be 1 - the index of the channel needed.
> +- arm,func-ids		An array of 32-bit values specifying the function
> +			IDs used by each mailbox channel. Those function IDs
> +			follow the ARM SMC calling convention standard [1].
> +			There is one identifier per channel and the number
> +			of supported channels is determined by the length
> +			of this array.

I agree with Jassi's comment on making these a client cell and just 
define the number of channels here. 

> +- method:		A string, either:
> +			"hvc": if the driver shall use an HVC call, or
> +			"smc": if the driver shall use an SMC call.
> +
> +Example:
> +--------
> +
> +	smc_mbox: mailbox {
> +		#mbox-cells = <1>;
> +		compatible = "arm,smc-mbox";
> +		arm,func-ids = <0x82000001>, <0x82000002>;
> +	};
> +
> +	scpi {
> +		compatible = "arm,scpi";
> +		mboxes = <&mailbox 0>;
> +		shmem = <&cpu_scp_shmem>;
> +	};
> +
> +
> +[1]
> +http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0028a/index.html
> -- 
> 2.8.2
> 

Re: [PATCH v2 1/3] DT: mailbox: add binding doc for the ARM SMC mailbox

[Rob Herring]

On Mon, Jul 24, 2017 at 12:23:24AM +0100, Andre Przywara wrote:
> The ARM SMC mailbox binding describes a firmware interface to trigger
> actions in software layers running in the EL2 or EL3 exception levels.
> The term "ARM" here relates to the SMC instruction as part of the ARM
> instruction set, not as a standard endorsed by ARM Ltd.
> 
> Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
> ---
>  .../devicetree/bindings/mailbox/arm-smc.txt        | 76 ++++++++++++++++++++++
>  1 file changed, 76 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.txt
> 
> diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.txt b/Documentation/devicetree/bindings/mailbox/arm-smc.txt
> new file mode 100644
> index 0000000..d9de57b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.txt
> @@ -0,0 +1,76 @@
> +ARM SMC Mailbox Interface
> +=========================
> +
> +This mailbox uses the ARM smc (secure monitor call) instruction to
> +trigger a mailbox-connected activity in firmware, executing on the very same
> +core as the caller. By nature this operation is synchronous and this
> +mailbox provides no way for asynchronous messages to be delivered the other
> +way round, from firmware to the OS. However the value of r0/w0/x0 the firmware
> +returns after the smc call is delivered as a received message to the
> +mailbox framework, so a synchronous communication can be established.
> +The exact meaning of both the action the mailbox triggers as well as the
> +return value is defined by their users and is not subject to this binding.
> +
> +One use case of this mailbox is the SCP interface, which uses shared memory
> +to transfer commands and parameters, and a mailbox to trigger a function
> +call. This allows SoCs without a separate management processor (or
> +when such a processor is not available or used) to use this standardized
> +interface anyway.
> +
> +This binding describes no hardware, but establishes a firmware interface.
> +Upon receiving an SMC using one of the described SMC function identifiers,
> +the firmware is expected to trigger some mailbox connected functionality.
> +The communication follows the ARM SMC calling convention[1]:
> +Firmware expects an SMC function identifier in r0 or w0 to identify a
> +particular mailbox. The supported identifiers are listed in the the
> +arm,func-ids properties, as described below.
> +Apart from those mandatory SMC function identifier there are no further
> +arguments handled by the receiving end.
> +The firmware can return one value in the first SMC result register, it
> +is expected to be an error value, which shall be propagated to the mailbox
> +client.
> +The C prototype of the function would be:
> +	unsigned long smc_mailbox_call(unsigned long mailbox_identifier);
> +The SMC function call is expected to be a fast call and could be from
> +any of the defined function ranges.
> +
> +Any core which supports the SMC or HVC instruction can be used, as long as
> +a firmware component running in EL3 or EL2 is handling these calls.
> +
> +Mailbox Device Node:
> +====================
> +
> +This node is expected to be a child of the /firmware node.
> +
> +Required properties:
> +--------------------
> +- compatible:		Shall be "arm,smc-mbox"
> +- #mbox-cells		Shall be 1 - the index of the channel needed.
> +- arm,func-ids		An array of 32-bit values specifying the function
> +			IDs used by each mailbox channel. Those function IDs
> +			follow the ARM SMC calling convention standard [1].
> +			There is one identifier per channel and the number
> +			of supported channels is determined by the length
> +			of this array.

I agree with Jassi's comment on making these a client cell and just 
define the number of channels here. 

> +- method:		A string, either:
> +			"hvc": if the driver shall use an HVC call, or
> +			"smc": if the driver shall use an SMC call.
> +
> +Example:
> +--------
> +
> +	smc_mbox: mailbox {
> +		#mbox-cells = <1>;
> +		compatible = "arm,smc-mbox";
> +		arm,func-ids = <0x82000001>, <0x82000002>;
> +	};
> +
> +	scpi {
> +		compatible = "arm,scpi";
> +		mboxes = <&mailbox 0>;
> +		shmem = <&cpu_scp_shmem>;
> +	};
> +
> +
> +[1]
> +http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0028a/index.html
> -- 
> 2.8.2
> 

[PATCH v2 1/3] DT: mailbox: add binding doc for the ARM SMC mailbox

[Rob Herring]

On Mon, Jul 24, 2017 at 12:23:24AM +0100, Andre Przywara wrote:
> The ARM SMC mailbox binding describes a firmware interface to trigger
> actions in software layers running in the EL2 or EL3 exception levels.
> The term "ARM" here relates to the SMC instruction as part of the ARM
> instruction set, not as a standard endorsed by ARM Ltd.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  .../devicetree/bindings/mailbox/arm-smc.txt        | 76 ++++++++++++++++++++++
>  1 file changed, 76 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.txt
> 
> diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.txt b/Documentation/devicetree/bindings/mailbox/arm-smc.txt
> new file mode 100644
> index 0000000..d9de57b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.txt
> @@ -0,0 +1,76 @@
> +ARM SMC Mailbox Interface
> +=========================
> +
> +This mailbox uses the ARM smc (secure monitor call) instruction to
> +trigger a mailbox-connected activity in firmware, executing on the very same
> +core as the caller. By nature this operation is synchronous and this
> +mailbox provides no way for asynchronous messages to be delivered the other
> +way round, from firmware to the OS. However the value of r0/w0/x0 the firmware
> +returns after the smc call is delivered as a received message to the
> +mailbox framework, so a synchronous communication can be established.
> +The exact meaning of both the action the mailbox triggers as well as the
> +return value is defined by their users and is not subject to this binding.
> +
> +One use case of this mailbox is the SCP interface, which uses shared memory
> +to transfer commands and parameters, and a mailbox to trigger a function
> +call. This allows SoCs without a separate management processor (or
> +when such a processor is not available or used) to use this standardized
> +interface anyway.
> +
> +This binding describes no hardware, but establishes a firmware interface.
> +Upon receiving an SMC using one of the described SMC function identifiers,
> +the firmware is expected to trigger some mailbox connected functionality.
> +The communication follows the ARM SMC calling convention[1]:
> +Firmware expects an SMC function identifier in r0 or w0 to identify a
> +particular mailbox. The supported identifiers are listed in the the
> +arm,func-ids properties, as described below.
> +Apart from those mandatory SMC function identifier there are no further
> +arguments handled by the receiving end.
> +The firmware can return one value in the first SMC result register, it
> +is expected to be an error value, which shall be propagated to the mailbox
> +client.
> +The C prototype of the function would be:
> +	unsigned long smc_mailbox_call(unsigned long mailbox_identifier);
> +The SMC function call is expected to be a fast call and could be from
> +any of the defined function ranges.
> +
> +Any core which supports the SMC or HVC instruction can be used, as long as
> +a firmware component running in EL3 or EL2 is handling these calls.
> +
> +Mailbox Device Node:
> +====================
> +
> +This node is expected to be a child of the /firmware node.
> +
> +Required properties:
> +--------------------
> +- compatible:		Shall be "arm,smc-mbox"
> +- #mbox-cells		Shall be 1 - the index of the channel needed.
> +- arm,func-ids		An array of 32-bit values specifying the function
> +			IDs used by each mailbox channel. Those function IDs
> +			follow the ARM SMC calling convention standard [1].
> +			There is one identifier per channel and the number
> +			of supported channels is determined by the length
> +			of this array.

I agree with Jassi's comment on making these a client cell and just 
define the number of channels here. 

> +- method:		A string, either:
> +			"hvc": if the driver shall use an HVC call, or
> +			"smc": if the driver shall use an SMC call.
> +
> +Example:
> +--------
> +
> +	smc_mbox: mailbox {
> +		#mbox-cells = <1>;
> +		compatible = "arm,smc-mbox";
> +		arm,func-ids = <0x82000001>, <0x82000002>;
> +	};
> +
> +	scpi {
> +		compatible = "arm,scpi";
> +		mboxes = <&mailbox 0>;
> +		shmem = <&cpu_scp_shmem>;
> +	};
> +
> +
> +[1]
> +http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0028a/index.html
> -- 
> 2.8.2
> 

Re: [PATCH v2 0/3] mailbox: arm: introduce smc triggered mailbox

[Andre Przywara]

Hi,

(sorry for the delay, cleaning up my inbox after holidays)

On 01/08/17 11:50, Alexander Graf wrote:
> Hi Andre,
> 
> On 24.07.17 01:23, Andre Przywara wrote:
>> This is a reworked version of my previous post. It addresses Jassi's
>> comments on the driver and also tries to cover Rob's and Mark's comments
>> on the binding documentation.
>> I dropped the more example-like DT changes from v1, as they are actually
>> not meant to be merged into the Linux tree, but instead are provided as
>> part of some firmware actually implementing this functionality.
>>
>> Please let me know what you think.
> 
> Could you please quickly explain what it would take to provide SCMI on
> top of this instead of SCPI?

On the Linux side basically nothing, that's actually the beauty of this
approach. This driver here is just a Linux mailbox interface provider.
And both SCMI and SCPI rely on one.
So all you would need to do is to provide compliant services on the
firmware side and add the proper nodes to the DT. Whether this is SCMI
or SCPI does not really make much of a difference, apart from the yet
missing upstream Linux support for SCMI, of course.

Cheers,
Andre.

> https://lkml.org/lkml/2017/6/7/624
> 
> I can certainly see that SCPI is an easier target because it's already
> upstream and widely spread. But wouldn't it make sense to jump on the
> SCMI train while it's taking steam?
> 
> 
> Thanks,
> 
> Alex

Re: [PATCH v2 0/3] mailbox: arm: introduce smc triggered mailbox

[Andre Przywara]

Hi,

(sorry for the delay, cleaning up my inbox after holidays)

On 01/08/17 11:50, Alexander Graf wrote:
> Hi Andre,
> 
> On 24.07.17 01:23, Andre Przywara wrote:
>> This is a reworked version of my previous post. It addresses Jassi's
>> comments on the driver and also tries to cover Rob's and Mark's comments
>> on the binding documentation.
>> I dropped the more example-like DT changes from v1, as they are actually
>> not meant to be merged into the Linux tree, but instead are provided as
>> part of some firmware actually implementing this functionality.
>>
>> Please let me know what you think.
> 
> Could you please quickly explain what it would take to provide SCMI on
> top of this instead of SCPI?

On the Linux side basically nothing, that's actually the beauty of this
approach. This driver here is just a Linux mailbox interface provider.
And both SCMI and SCPI rely on one.
So all you would need to do is to provide compliant services on the
firmware side and add the proper nodes to the DT. Whether this is SCMI
or SCPI does not really make much of a difference, apart from the yet
missing upstream Linux support for SCMI, of course.

Cheers,
Andre.

> https://lkml.org/lkml/2017/6/7/624
> 
> I can certainly see that SCPI is an easier target because it's already
> upstream and widely spread. But wouldn't it make sense to jump on the
> SCMI train while it's taking steam?
> 
> 
> Thanks,
> 
> Alex

[PATCH v2 0/3] mailbox: arm: introduce smc triggered mailbox

[Andre Przywara]

Hi,

(sorry for the delay, cleaning up my inbox after holidays)

On 01/08/17 11:50, Alexander Graf wrote:
> Hi Andre,
> 
> On 24.07.17 01:23, Andre Przywara wrote:
>> This is a reworked version of my previous post. It addresses Jassi's
>> comments on the driver and also tries to cover Rob's and Mark's comments
>> on the binding documentation.
>> I dropped the more example-like DT changes from v1, as they are actually
>> not meant to be merged into the Linux tree, but instead are provided as
>> part of some firmware actually implementing this functionality.
>>
>> Please let me know what you think.
> 
> Could you please quickly explain what it would take to provide SCMI on
> top of this instead of SCPI?

On the Linux side basically nothing, that's actually the beauty of this
approach. This driver here is just a Linux mailbox interface provider.
And both SCMI and SCPI rely on one.
So all you would need to do is to provide compliant services on the
firmware side and add the proper nodes to the DT. Whether this is SCMI
or SCPI does not really make much of a difference, apart from the yet
missing upstream Linux support for SCMI, of course.

Cheers,
Andre.

> https://lkml.org/lkml/2017/6/7/624
> 
> I can certainly see that SCPI is an easier target because it's already
> upstream and widely spread. But wouldn't it make sense to jump on the
> SCMI train while it's taking steam?
> 
> 
> Thanks,
> 
> Alex