* [PATCH v11 0/2] mailbox: arm: introduce smc triggered mailbox @ 2019-12-02 10:14 ` Peng Fan 0 siblings, 0 replies; 10+ messages in thread From: Peng Fan @ 2019-12-02 10:14 UTC (permalink / raw) To: robh+dt, mark.rutland, jassisinghbrar, sudeep.holla, andre.przywara, f.fainelli Cc: devicetree, linux-kernel, linux-arm-kernel, dl-linux-imx, Peng Fan From: Peng Fan <peng.fan@nxp.com> V11: - Minor update: Replace arg_smccc64/32 with unsigned long arg_smccc[]; Hope this version is ok for everyone. V10: - Add R-b tag from Andre, Rob and Florian - Two minor fixes - Drop "are passed from consumers" in patch 1/2 per Andre's comments - Drop interrupts.h in patch 2/2 per Andre's comments V9: - Add Florian's R-b tag in patch 1/2 - Mark arm,func-id as a required property per Andre's comments in patch 1/2. - Make invoke_smc_mbox_fn as a private entry in a channal per Florian's comments in pach 2/2 - Include linux/types.h in arm-smccc-mbox.h in patch 2/2 - Drop function_id from arm_smccc_mbox_cmd since func-id is from DT in patch 2/2/. V8: Add missed arm-smccc-mbox.h V7: Typo fix #mbox-cells changed to 0 Add a new header file arm-smccc-mbox.h Use ARM_SMCCC_IS_64 Andre, The function_id is still kept in arm_smccc_mbox_cmd, because arm,func-id property is optional, so clients could pass function_id to mbox driver. V6: Switch to per-channel a mbox controller Drop arm,num-chans, transports, method Add arm,hvc-mbox compatible Fix smc/hvc args, drop client id and use correct type. https://patchwork.kernel.org/cover/11146641/ V5: yaml fix https://patchwork.kernel.org/cover/11117741/ V4: yaml fix for num-chans in patch 1/2. https://patchwork.kernel.org/cover/11116521/ V3: Drop interrupt Introduce transports for mem/reg usage Add chan-id for mem usage Convert to yaml format https://patchwork.kernel.org/cover/11043541/ V2: This is a modified version from Andre Przywara's patch series https://lore.kernel.org/patchwork/cover/812997/. The modification are mostly: Introduce arm,num-chans Introduce arm_smccc_mbox_cmd txdone_poll and txdone_irq are both set to false arm,func-ids are kept, but as an optional property. Rewords SCPI to SCMI, because I am trying SCMI over SMC, not SCPI. Introduce interrupts notification. [1] is a draft implementation of i.MX8MM SCMI ATF implementation that use smc as mailbox, power/clk is included, but only part of clk has been implemented to work with hardware, power domain only supports get name for now. 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 SCMI protocol to signal a request for some action to be taken by the management processor. However some SoCs does not have a dedicated management core to provide those services. In order to service TEE and to avoid linux shutdown power and clock that used by TEE, need let firmware to handle power and clock, the firmware here is ARM Trusted Firmware that could also run SCMI service. The existing SCMI 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 SCMI requests. The actual requests are still communicated using the standard SCMI way of shared memory regions, but a dedicated mailbox hardware IP can be replaced via this new driver. 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. Please note that this driver just provides a generic mailbox mechanism, It could support synchronous TX/RX, or synchronous TX with asynchronous RX. And while providing SCMI 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. [1] https://github.com/MrVan/arm-trusted-firmware/tree/scmi Peng Fan (2): dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox mailbox: introduce ARM SMC based mailbox .../devicetree/bindings/mailbox/arm-smc.yaml | 96 +++++++++++++ drivers/mailbox/Kconfig | 7 + drivers/mailbox/Makefile | 2 + drivers/mailbox/arm-smc-mailbox.c | 156 +++++++++++++++++++++ include/linux/mailbox/arm-smccc-mbox.h | 17 +++ 5 files changed, 278 insertions(+) create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml create mode 100644 drivers/mailbox/arm-smc-mailbox.c create mode 100644 include/linux/mailbox/arm-smccc-mbox.h -- 2.16.4 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v11 0/2] mailbox: arm: introduce smc triggered mailbox @ 2019-12-02 10:14 ` Peng Fan 0 siblings, 0 replies; 10+ messages in thread From: Peng Fan @ 2019-12-02 10:14 UTC (permalink / raw) To: robh+dt, mark.rutland, jassisinghbrar, sudeep.holla, andre.przywara, f.fainelli Cc: devicetree, Peng Fan, linux-kernel, linux-arm-kernel, dl-linux-imx From: Peng Fan <peng.fan@nxp.com> V11: - Minor update: Replace arg_smccc64/32 with unsigned long arg_smccc[]; Hope this version is ok for everyone. V10: - Add R-b tag from Andre, Rob and Florian - Two minor fixes - Drop "are passed from consumers" in patch 1/2 per Andre's comments - Drop interrupts.h in patch 2/2 per Andre's comments V9: - Add Florian's R-b tag in patch 1/2 - Mark arm,func-id as a required property per Andre's comments in patch 1/2. - Make invoke_smc_mbox_fn as a private entry in a channal per Florian's comments in pach 2/2 - Include linux/types.h in arm-smccc-mbox.h in patch 2/2 - Drop function_id from arm_smccc_mbox_cmd since func-id is from DT in patch 2/2/. V8: Add missed arm-smccc-mbox.h V7: Typo fix #mbox-cells changed to 0 Add a new header file arm-smccc-mbox.h Use ARM_SMCCC_IS_64 Andre, The function_id is still kept in arm_smccc_mbox_cmd, because arm,func-id property is optional, so clients could pass function_id to mbox driver. V6: Switch to per-channel a mbox controller Drop arm,num-chans, transports, method Add arm,hvc-mbox compatible Fix smc/hvc args, drop client id and use correct type. https://patchwork.kernel.org/cover/11146641/ V5: yaml fix https://patchwork.kernel.org/cover/11117741/ V4: yaml fix for num-chans in patch 1/2. https://patchwork.kernel.org/cover/11116521/ V3: Drop interrupt Introduce transports for mem/reg usage Add chan-id for mem usage Convert to yaml format https://patchwork.kernel.org/cover/11043541/ V2: This is a modified version from Andre Przywara's patch series https://lore.kernel.org/patchwork/cover/812997/. The modification are mostly: Introduce arm,num-chans Introduce arm_smccc_mbox_cmd txdone_poll and txdone_irq are both set to false arm,func-ids are kept, but as an optional property. Rewords SCPI to SCMI, because I am trying SCMI over SMC, not SCPI. Introduce interrupts notification. [1] is a draft implementation of i.MX8MM SCMI ATF implementation that use smc as mailbox, power/clk is included, but only part of clk has been implemented to work with hardware, power domain only supports get name for now. 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 SCMI protocol to signal a request for some action to be taken by the management processor. However some SoCs does not have a dedicated management core to provide those services. In order to service TEE and to avoid linux shutdown power and clock that used by TEE, need let firmware to handle power and clock, the firmware here is ARM Trusted Firmware that could also run SCMI service. The existing SCMI 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 SCMI requests. The actual requests are still communicated using the standard SCMI way of shared memory regions, but a dedicated mailbox hardware IP can be replaced via this new driver. 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. Please note that this driver just provides a generic mailbox mechanism, It could support synchronous TX/RX, or synchronous TX with asynchronous RX. And while providing SCMI 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. [1] https://github.com/MrVan/arm-trusted-firmware/tree/scmi Peng Fan (2): dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox mailbox: introduce ARM SMC based mailbox .../devicetree/bindings/mailbox/arm-smc.yaml | 96 +++++++++++++ drivers/mailbox/Kconfig | 7 + drivers/mailbox/Makefile | 2 + drivers/mailbox/arm-smc-mailbox.c | 156 +++++++++++++++++++++ include/linux/mailbox/arm-smccc-mbox.h | 17 +++ 5 files changed, 278 insertions(+) create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml create mode 100644 drivers/mailbox/arm-smc-mailbox.c create mode 100644 include/linux/mailbox/arm-smccc-mbox.h -- 2.16.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v11 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox 2019-12-02 10:14 ` Peng Fan @ 2019-12-02 10:14 ` Peng Fan -1 siblings, 0 replies; 10+ messages in thread From: Peng Fan @ 2019-12-02 10:14 UTC (permalink / raw) To: robh+dt, mark.rutland, jassisinghbrar, sudeep.holla, andre.przywara, f.fainelli Cc: devicetree, linux-kernel, linux-arm-kernel, dl-linux-imx, Peng Fan From: Peng Fan <peng.fan@nxp.com> The ARM SMC/HVC 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. Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> --- .../devicetree/bindings/mailbox/arm-smc.yaml | 96 ++++++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml new file mode 100644 index 000000000000..c165946a64e4 --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml @@ -0,0 +1,96 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM SMC Mailbox Interface + +maintainers: + - Peng Fan <peng.fan@nxp.com> + +description: | + This mailbox uses the ARM smc (secure monitor call) or hvc (hypervisor + call) instruction to trigger a mailbox-connected activity in firmware, + executing on the very same core as the caller. The value of r0/w0/x0 + the firmware returns after the smc call is delivered as a received + message to the mailbox framework, so synchronous communication can be + established. The exact meaning of the action the mailbox triggers as + well as the return value is defined by their users and is not subject + to this binding. + + One example use case of this mailbox is the SCMI 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 the described SMC function identifier, the + firmware is expected to trigger some mailbox connected functionality. + The communication follows the ARM SMC calling convention. + Firmware expects an SMC function identifier in r0 or w0. The supported + identifier is listed in the the arm,func-id property as described below. + 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. + + 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. + +properties: + compatible: + oneOf: + - description: + For implementations using ARM SMC instruction. + const: arm,smc-mbox + + - description: + For implementations using ARM HVC instruction. + const: arm,hvc-mbox + + "#mbox-cells": + const: 0 + + arm,func-id: + description: | + An single 32-bit value specifying the function ID used by the mailbox. + The function ID follows the ARM SMC calling convention standard. + $ref: /schemas/types.yaml#/definitions/uint32 + +required: + - compatible + - "#mbox-cells" + - arm,func-id + +examples: + - | + sram@93f000 { + compatible = "mmio-sram"; + reg = <0x0 0x93f000 0x0 0x1000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x93f000 0x1000>; + + cpu_scp_lpri: scp-shmem@0 { + compatible = "arm,scmi-shmem"; + reg = <0x0 0x200>; + }; + }; + + smc_tx_mbox: tx_mbox { + #mbox-cells = <0>; + compatible = "arm,smc-mbox"; + arm,func-id = <0xc20000fe>; + }; + + firmware { + scmi { + compatible = "arm,scmi"; + mboxes = <&smc_tx_mbox>; + mbox-names = "tx"; + shmem = <&cpu_scp_lpri>; + }; + }; + +... -- 2.16.4 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH v11 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox @ 2019-12-02 10:14 ` Peng Fan 0 siblings, 0 replies; 10+ messages in thread From: Peng Fan @ 2019-12-02 10:14 UTC (permalink / raw) To: robh+dt, mark.rutland, jassisinghbrar, sudeep.holla, andre.przywara, f.fainelli Cc: devicetree, Peng Fan, linux-kernel, linux-arm-kernel, dl-linux-imx From: Peng Fan <peng.fan@nxp.com> The ARM SMC/HVC 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. Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> --- .../devicetree/bindings/mailbox/arm-smc.yaml | 96 ++++++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml new file mode 100644 index 000000000000..c165946a64e4 --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml @@ -0,0 +1,96 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM SMC Mailbox Interface + +maintainers: + - Peng Fan <peng.fan@nxp.com> + +description: | + This mailbox uses the ARM smc (secure monitor call) or hvc (hypervisor + call) instruction to trigger a mailbox-connected activity in firmware, + executing on the very same core as the caller. The value of r0/w0/x0 + the firmware returns after the smc call is delivered as a received + message to the mailbox framework, so synchronous communication can be + established. The exact meaning of the action the mailbox triggers as + well as the return value is defined by their users and is not subject + to this binding. + + One example use case of this mailbox is the SCMI 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 the described SMC function identifier, the + firmware is expected to trigger some mailbox connected functionality. + The communication follows the ARM SMC calling convention. + Firmware expects an SMC function identifier in r0 or w0. The supported + identifier is listed in the the arm,func-id property as described below. + 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. + + 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. + +properties: + compatible: + oneOf: + - description: + For implementations using ARM SMC instruction. + const: arm,smc-mbox + + - description: + For implementations using ARM HVC instruction. + const: arm,hvc-mbox + + "#mbox-cells": + const: 0 + + arm,func-id: + description: | + An single 32-bit value specifying the function ID used by the mailbox. + The function ID follows the ARM SMC calling convention standard. + $ref: /schemas/types.yaml#/definitions/uint32 + +required: + - compatible + - "#mbox-cells" + - arm,func-id + +examples: + - | + sram@93f000 { + compatible = "mmio-sram"; + reg = <0x0 0x93f000 0x0 0x1000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x93f000 0x1000>; + + cpu_scp_lpri: scp-shmem@0 { + compatible = "arm,scmi-shmem"; + reg = <0x0 0x200>; + }; + }; + + smc_tx_mbox: tx_mbox { + #mbox-cells = <0>; + compatible = "arm,smc-mbox"; + arm,func-id = <0xc20000fe>; + }; + + firmware { + scmi { + compatible = "arm,scmi"; + mboxes = <&smc_tx_mbox>; + mbox-names = "tx"; + shmem = <&cpu_scp_lpri>; + }; + }; + +... -- 2.16.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH v11 2/2] mailbox: introduce ARM SMC based mailbox 2019-12-02 10:14 ` Peng Fan @ 2019-12-02 10:14 ` Peng Fan -1 siblings, 0 replies; 10+ messages in thread From: Peng Fan @ 2019-12-02 10:14 UTC (permalink / raw) To: robh+dt, mark.rutland, jassisinghbrar, sudeep.holla, andre.przywara, f.fainelli Cc: devicetree, linux-kernel, linux-arm-kernel, dl-linux-imx, Peng Fan From: Peng Fan <peng.fan@nxp.com> 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. Modified from Andre Przywara's v2 patch https://lore.kernel.org/patchwork/patch/812999/ Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> --- drivers/mailbox/Kconfig | 7 ++ drivers/mailbox/Makefile | 2 + drivers/mailbox/arm-smc-mailbox.c | 156 +++++++++++++++++++++++++++++++++ include/linux/mailbox/arm-smccc-mbox.h | 17 ++++ 4 files changed, 182 insertions(+) create mode 100644 drivers/mailbox/arm-smc-mailbox.c create mode 100644 include/linux/mailbox/arm-smccc-mbox.h diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index ab4eb750bbdd..7707ee26251a 100644 --- a/drivers/mailbox/Kconfig +++ b/drivers/mailbox/Kconfig @@ -16,6 +16,13 @@ config ARM_MHU The controller has 3 mailbox channels, the last of which can be used in Secure mode only. +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. + config IMX_MBOX tristate "i.MX Mailbox" depends on ARCH_MXC || COMPILE_TEST diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index c22fad6f696b..93918a84c91b 100644 --- a/drivers/mailbox/Makefile +++ b/drivers/mailbox/Makefile @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o obj-$(CONFIG_ARM_MHU) += arm_mhu.o +obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o + obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX) += armada-37xx-rwtm-mailbox.o diff --git a/drivers/mailbox/arm-smc-mailbox.c b/drivers/mailbox/arm-smc-mailbox.c new file mode 100644 index 000000000000..223d46fe6513 --- /dev/null +++ b/drivers/mailbox/arm-smc-mailbox.c @@ -0,0 +1,156 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2016,2017 ARM Ltd. + * Copyright 2019 NXP + */ + +#include <linux/arm-smccc.h> +#include <linux/device.h> +#include <linux/kernel.h> +#include <linux/mailbox_controller.h> +#include <linux/mailbox/arm-smccc-mbox.h> +#include <linux/module.h> +#include <linux/platform_device.h> + +typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long, + unsigned long, unsigned long, + unsigned long, unsigned long, + unsigned long); + +struct arm_smc_chan_data { + unsigned int function_id; + smc_mbox_fn *invoke_smc_mbox_fn; +}; + +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_mbox_cmd *cmd = data; + unsigned long ret; + + ret = chan_data->invoke_smc_mbox_fn(chan_data->function_id, + cmd->args_smccc[0], + cmd->args_smccc[1], + cmd->args_smccc[2], + cmd->args_smccc[3], + cmd->args_smccc[4], + cmd->args_smccc[5]); + + mbox_chan_received_data(link, (void *)ret); + + return 0; +} + +static unsigned long __invoke_fn_hvc(unsigned int function_id, + unsigned long arg0, unsigned long arg1, + unsigned long arg2, unsigned long arg3, + unsigned long arg4, unsigned long arg5) +{ + struct arm_smccc_res res; + + arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4, + arg5, 0, &res); + return res.a0; +} + +static unsigned long __invoke_fn_smc(unsigned int function_id, + unsigned long arg0, unsigned long arg1, + unsigned long arg2, unsigned long arg3, + unsigned long arg4, unsigned long arg5) +{ + struct arm_smccc_res res; + + arm_smccc_smc(function_id, arg0, arg1, arg2, arg3, arg4, + arg5, 0, &res); + return res.a0; +} + +static const struct mbox_chan_ops arm_smc_mbox_chan_ops = { + .send_data = arm_smc_send_data, +}; + +static struct mbox_chan * +arm_smc_mbox_of_xlate(struct mbox_controller *mbox, + const struct of_phandle_args *sp) +{ + return mbox->chans; +} + +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; + int ret; + + mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL); + if (!mbox) + return -ENOMEM; + + mbox->of_xlate = arm_smc_mbox_of_xlate; + mbox->num_chans = 1; + mbox->chans = devm_kzalloc(dev, sizeof(*mbox->chans), GFP_KERNEL); + if (!mbox->chans) + return -ENOMEM; + + chan_data = devm_kzalloc(dev, sizeof(*chan_data), GFP_KERNEL); + if (!chan_data) + return -ENOMEM; + + ret = of_property_read_u32(dev->of_node, "arm,func-id", + &chan_data->function_id); + if (ret) + return ret; + + if (of_device_is_compatible(dev->of_node, "arm,smc-mbox")) + chan_data->invoke_smc_mbox_fn = __invoke_fn_smc; + else + chan_data->invoke_smc_mbox_fn = __invoke_fn_hvc; + + + mbox->chans->con_priv = chan_data; + + mbox->txdone_poll = false; + mbox->txdone_irq = false; + mbox->ops = &arm_smc_mbox_chan_ops; + mbox->dev = dev; + + platform_set_drvdata(pdev, mbox); + + ret = devm_mbox_controller_register(dev, mbox); + if (ret) + return ret; + + dev_info(dev, "ARM SMC mailbox enabled.\n"); + + 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", }, + { .compatible = "arm,hvc-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("Peng Fan <peng.fan@nxp.com>"); +MODULE_DESCRIPTION("Generic ARM smc mailbox driver"); +MODULE_LICENSE("GPL v2"); diff --git a/include/linux/mailbox/arm-smccc-mbox.h b/include/linux/mailbox/arm-smccc-mbox.h new file mode 100644 index 000000000000..244e09598c10 --- /dev/null +++ b/include/linux/mailbox/arm-smccc-mbox.h @@ -0,0 +1,17 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#ifndef _LINUX_ARM_SMCCC_MBOX_H_ +#define _LINUX_ARM_SMCCC_MBOX_H_ + +#include <linux/types.h> + +/** + * struct arm_smccc_mbox_cmd - ARM SMCCC message structure + * @args_smccc: actual usage of registers is up to the protocol + * (within the SMCCC limits) + */ +struct arm_smccc_mbox_cmd { + unsigned long args_smccc[6]; +}; + +#endif /* _LINUX_ARM_SMCCC_MBOX_H_ */ -- 2.16.4 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH v11 2/2] mailbox: introduce ARM SMC based mailbox @ 2019-12-02 10:14 ` Peng Fan 0 siblings, 0 replies; 10+ messages in thread From: Peng Fan @ 2019-12-02 10:14 UTC (permalink / raw) To: robh+dt, mark.rutland, jassisinghbrar, sudeep.holla, andre.przywara, f.fainelli Cc: devicetree, Peng Fan, linux-kernel, linux-arm-kernel, dl-linux-imx From: Peng Fan <peng.fan@nxp.com> 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. Modified from Andre Przywara's v2 patch https://lore.kernel.org/patchwork/patch/812999/ Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> --- drivers/mailbox/Kconfig | 7 ++ drivers/mailbox/Makefile | 2 + drivers/mailbox/arm-smc-mailbox.c | 156 +++++++++++++++++++++++++++++++++ include/linux/mailbox/arm-smccc-mbox.h | 17 ++++ 4 files changed, 182 insertions(+) create mode 100644 drivers/mailbox/arm-smc-mailbox.c create mode 100644 include/linux/mailbox/arm-smccc-mbox.h diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index ab4eb750bbdd..7707ee26251a 100644 --- a/drivers/mailbox/Kconfig +++ b/drivers/mailbox/Kconfig @@ -16,6 +16,13 @@ config ARM_MHU The controller has 3 mailbox channels, the last of which can be used in Secure mode only. +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. + config IMX_MBOX tristate "i.MX Mailbox" depends on ARCH_MXC || COMPILE_TEST diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index c22fad6f696b..93918a84c91b 100644 --- a/drivers/mailbox/Makefile +++ b/drivers/mailbox/Makefile @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o obj-$(CONFIG_ARM_MHU) += arm_mhu.o +obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o + obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX) += armada-37xx-rwtm-mailbox.o diff --git a/drivers/mailbox/arm-smc-mailbox.c b/drivers/mailbox/arm-smc-mailbox.c new file mode 100644 index 000000000000..223d46fe6513 --- /dev/null +++ b/drivers/mailbox/arm-smc-mailbox.c @@ -0,0 +1,156 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2016,2017 ARM Ltd. + * Copyright 2019 NXP + */ + +#include <linux/arm-smccc.h> +#include <linux/device.h> +#include <linux/kernel.h> +#include <linux/mailbox_controller.h> +#include <linux/mailbox/arm-smccc-mbox.h> +#include <linux/module.h> +#include <linux/platform_device.h> + +typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long, + unsigned long, unsigned long, + unsigned long, unsigned long, + unsigned long); + +struct arm_smc_chan_data { + unsigned int function_id; + smc_mbox_fn *invoke_smc_mbox_fn; +}; + +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_mbox_cmd *cmd = data; + unsigned long ret; + + ret = chan_data->invoke_smc_mbox_fn(chan_data->function_id, + cmd->args_smccc[0], + cmd->args_smccc[1], + cmd->args_smccc[2], + cmd->args_smccc[3], + cmd->args_smccc[4], + cmd->args_smccc[5]); + + mbox_chan_received_data(link, (void *)ret); + + return 0; +} + +static unsigned long __invoke_fn_hvc(unsigned int function_id, + unsigned long arg0, unsigned long arg1, + unsigned long arg2, unsigned long arg3, + unsigned long arg4, unsigned long arg5) +{ + struct arm_smccc_res res; + + arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4, + arg5, 0, &res); + return res.a0; +} + +static unsigned long __invoke_fn_smc(unsigned int function_id, + unsigned long arg0, unsigned long arg1, + unsigned long arg2, unsigned long arg3, + unsigned long arg4, unsigned long arg5) +{ + struct arm_smccc_res res; + + arm_smccc_smc(function_id, arg0, arg1, arg2, arg3, arg4, + arg5, 0, &res); + return res.a0; +} + +static const struct mbox_chan_ops arm_smc_mbox_chan_ops = { + .send_data = arm_smc_send_data, +}; + +static struct mbox_chan * +arm_smc_mbox_of_xlate(struct mbox_controller *mbox, + const struct of_phandle_args *sp) +{ + return mbox->chans; +} + +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; + int ret; + + mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL); + if (!mbox) + return -ENOMEM; + + mbox->of_xlate = arm_smc_mbox_of_xlate; + mbox->num_chans = 1; + mbox->chans = devm_kzalloc(dev, sizeof(*mbox->chans), GFP_KERNEL); + if (!mbox->chans) + return -ENOMEM; + + chan_data = devm_kzalloc(dev, sizeof(*chan_data), GFP_KERNEL); + if (!chan_data) + return -ENOMEM; + + ret = of_property_read_u32(dev->of_node, "arm,func-id", + &chan_data->function_id); + if (ret) + return ret; + + if (of_device_is_compatible(dev->of_node, "arm,smc-mbox")) + chan_data->invoke_smc_mbox_fn = __invoke_fn_smc; + else + chan_data->invoke_smc_mbox_fn = __invoke_fn_hvc; + + + mbox->chans->con_priv = chan_data; + + mbox->txdone_poll = false; + mbox->txdone_irq = false; + mbox->ops = &arm_smc_mbox_chan_ops; + mbox->dev = dev; + + platform_set_drvdata(pdev, mbox); + + ret = devm_mbox_controller_register(dev, mbox); + if (ret) + return ret; + + dev_info(dev, "ARM SMC mailbox enabled.\n"); + + 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", }, + { .compatible = "arm,hvc-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("Peng Fan <peng.fan@nxp.com>"); +MODULE_DESCRIPTION("Generic ARM smc mailbox driver"); +MODULE_LICENSE("GPL v2"); diff --git a/include/linux/mailbox/arm-smccc-mbox.h b/include/linux/mailbox/arm-smccc-mbox.h new file mode 100644 index 000000000000..244e09598c10 --- /dev/null +++ b/include/linux/mailbox/arm-smccc-mbox.h @@ -0,0 +1,17 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#ifndef _LINUX_ARM_SMCCC_MBOX_H_ +#define _LINUX_ARM_SMCCC_MBOX_H_ + +#include <linux/types.h> + +/** + * struct arm_smccc_mbox_cmd - ARM SMCCC message structure + * @args_smccc: actual usage of registers is up to the protocol + * (within the SMCCC limits) + */ +struct arm_smccc_mbox_cmd { + unsigned long args_smccc[6]; +}; + +#endif /* _LINUX_ARM_SMCCC_MBOX_H_ */ -- 2.16.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH v11 2/2] mailbox: introduce ARM SMC based mailbox 2019-12-02 10:14 ` Peng Fan @ 2019-12-03 11:46 ` Sudeep Holla -1 siblings, 0 replies; 10+ messages in thread From: Sudeep Holla @ 2019-12-03 11:46 UTC (permalink / raw) To: Peng Fan Cc: robh+dt, mark.rutland, jassisinghbrar, andre.przywara, f.fainelli, devicetree, linux-kernel, linux-arm-kernel, dl-linux-imx, Viresh Kumar, Sudeep Holla, Arnd Bergmann (+Viresh,Arnd) On Mon, Dec 02, 2019 at 10:14:43AM +0000, Peng Fan wrote: > From: Peng Fan <peng.fan@nxp.com> > > 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. > I would like to know all the use-cases for this driver ? Is this only for SCMI or will this get used with other protocols on the top. I assume the latter and hence it is preferred to keep this as a mailbox driver. I am not against this approach but the reason I ask is to avoid duplication. Viresh has suggested abstraction of transport from SCMI driver to enable other transports[1]. Couple of transports that I am aware of is this SMC/HVC and the new(still in-concept) SPCI. So I am looking for opinions on that approach. Please feel free to comment here or as part of that patch. -- Regards, Sudeep [1] https://lore.kernel.org/lkml/5c545c2866ba075ddb44907940a1dae1d823b8a1.1575019719.git.viresh.kumar@linaro.org ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v11 2/2] mailbox: introduce ARM SMC based mailbox @ 2019-12-03 11:46 ` Sudeep Holla 0 siblings, 0 replies; 10+ messages in thread From: Sudeep Holla @ 2019-12-03 11:46 UTC (permalink / raw) To: Peng Fan Cc: mark.rutland, devicetree, f.fainelli, Arnd Bergmann, andre.przywara, jassisinghbrar, linux-kernel, Sudeep Holla, robh+dt, dl-linux-imx, Viresh Kumar, linux-arm-kernel (+Viresh,Arnd) On Mon, Dec 02, 2019 at 10:14:43AM +0000, Peng Fan wrote: > From: Peng Fan <peng.fan@nxp.com> > > 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. > I would like to know all the use-cases for this driver ? Is this only for SCMI or will this get used with other protocols on the top. I assume the latter and hence it is preferred to keep this as a mailbox driver. I am not against this approach but the reason I ask is to avoid duplication. Viresh has suggested abstraction of transport from SCMI driver to enable other transports[1]. Couple of transports that I am aware of is this SMC/HVC and the new(still in-concept) SPCI. So I am looking for opinions on that approach. Please feel free to comment here or as part of that patch. -- Regards, Sudeep [1] https://lore.kernel.org/lkml/5c545c2866ba075ddb44907940a1dae1d823b8a1.1575019719.git.viresh.kumar@linaro.org _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [PATCH v11 2/2] mailbox: introduce ARM SMC based mailbox 2019-12-03 11:46 ` Sudeep Holla @ 2019-12-05 3:24 ` Peng Fan -1 siblings, 0 replies; 10+ messages in thread From: Peng Fan @ 2019-12-05 3:24 UTC (permalink / raw) To: Sudeep Holla Cc: robh+dt, mark.rutland, jassisinghbrar, andre.przywara, f.fainelli, devicetree, linux-kernel, linux-arm-kernel, dl-linux-imx, Viresh Kumar, Arnd Bergmann > Subject: Re: [PATCH v11 2/2] mailbox: introduce ARM SMC based mailbox > > (+Viresh,Arnd) > > On Mon, Dec 02, 2019 at 10:14:43AM +0000, Peng Fan wrote: > > From: Peng Fan <peng.fan@nxp.com> > > > > 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. > > > > I would like to know all the use-cases for this driver ? Currently my usecase is SCMI. Is this only for SCMI or > will this get used with other protocols on the top. I assume the latter and > hence it is preferred to keep this as a mailbox driver. > > I am not against this approach but the reason I ask is to avoid duplication. > Viresh has suggested abstraction of transport from SCMI driver to enable > other transports[1]. Couple of transports that I am aware of is this SMC/HVC > and the new(still in-concept) SPCI. > > So I am looking for opinions on that approach. Please feel free to comment > here or as part of that patch. If we want to use SMC as transports, smc mailbox or smc transports(non-mailbox) could be used. Both ok for me, smc transports just need write a new driver under scmi folder. I left the decision to you(scmi maintainer) and Jassi(mailbox maintainer), Just hope the smc/hvc used as transports could be landed in upstream soon. Thanks, Peng. > > -- > Regards, > Sudeep > > [1] > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke > rnel.org%2Flkml%2F5c545c2866ba075ddb44907940a1dae1d823b8a1.15750 > 19719.git.viresh.kumar%40linaro.org&data=02%7C01%7Cpeng.fan%40n > xp.com%7C06edb0c37371419db3cd08d777e66780%7C686ea1d3bc2b4c6fa9 > 2cd99c5c301635%7C0%7C1%7C637109703766574454&sdata=nInLSUu > mwzBvl%2FcmckQkpZbJT4JAtVkzr1TSWkmz6qo%3D&reserved=0 ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [PATCH v11 2/2] mailbox: introduce ARM SMC based mailbox @ 2019-12-05 3:24 ` Peng Fan 0 siblings, 0 replies; 10+ messages in thread From: Peng Fan @ 2019-12-05 3:24 UTC (permalink / raw) To: Sudeep Holla Cc: mark.rutland, devicetree, f.fainelli, Arnd Bergmann, andre.przywara, jassisinghbrar, linux-kernel, robh+dt, dl-linux-imx, Viresh Kumar, linux-arm-kernel > Subject: Re: [PATCH v11 2/2] mailbox: introduce ARM SMC based mailbox > > (+Viresh,Arnd) > > On Mon, Dec 02, 2019 at 10:14:43AM +0000, Peng Fan wrote: > > From: Peng Fan <peng.fan@nxp.com> > > > > 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. > > > > I would like to know all the use-cases for this driver ? Currently my usecase is SCMI. Is this only for SCMI or > will this get used with other protocols on the top. I assume the latter and > hence it is preferred to keep this as a mailbox driver. > > I am not against this approach but the reason I ask is to avoid duplication. > Viresh has suggested abstraction of transport from SCMI driver to enable > other transports[1]. Couple of transports that I am aware of is this SMC/HVC > and the new(still in-concept) SPCI. > > So I am looking for opinions on that approach. Please feel free to comment > here or as part of that patch. If we want to use SMC as transports, smc mailbox or smc transports(non-mailbox) could be used. Both ok for me, smc transports just need write a new driver under scmi folder. I left the decision to you(scmi maintainer) and Jassi(mailbox maintainer), Just hope the smc/hvc used as transports could be landed in upstream soon. Thanks, Peng. > > -- > Regards, > Sudeep > > [1] > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke > rnel.org%2Flkml%2F5c545c2866ba075ddb44907940a1dae1d823b8a1.15750 > 19719.git.viresh.kumar%40linaro.org&data=02%7C01%7Cpeng.fan%40n > xp.com%7C06edb0c37371419db3cd08d777e66780%7C686ea1d3bc2b4c6fa9 > 2cd99c5c301635%7C0%7C1%7C637109703766574454&sdata=nInLSUu > mwzBvl%2FcmckQkpZbJT4JAtVkzr1TSWkmz6qo%3D&reserved=0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2019-12-05 3:25 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-12-02 10:14 [PATCH v11 0/2] mailbox: arm: introduce smc triggered mailbox Peng Fan 2019-12-02 10:14 ` Peng Fan 2019-12-02 10:14 ` [PATCH v11 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox Peng Fan 2019-12-02 10:14 ` Peng Fan 2019-12-02 10:14 ` [PATCH v11 2/2] mailbox: introduce ARM SMC based mailbox Peng Fan 2019-12-02 10:14 ` Peng Fan 2019-12-03 11:46 ` Sudeep Holla 2019-12-03 11:46 ` Sudeep Holla 2019-12-05 3:24 ` Peng Fan 2019-12-05 3:24 ` Peng Fan
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.