| Message ID | 1568626884-5189-3-git-send-email-peng.fan@nxp.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | mailbox: arm: introduce smc triggered mailbox | expand |
On Mon, 16 Sep 2019 09:44:41 +0000 Peng Fan <peng.fan@nxp.com> wrote: Hi, looks quite good now, some smaller comments below. I think the only thing left is the "function ID passed by the client" topic. Have you tried using this interface using hvc, for instance in KVM or Xen? For instance to provide access to a clock for a passed-through platform device? Another use case that pops up from time to time is GPIO for guests. This sounds like a use case for using the register interface, also we could use the hvc return value. > 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/ > > Cc: 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 | 167 ++++++++++++++++++++++++++++++++++++++ > 3 files changed, 176 insertions(+) > create mode 100644 drivers/mailbox/arm-smc-mailbox.c > > 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..c84aef39c8d9 > --- /dev/null > +++ b/drivers/mailbox/arm-smc-mailbox.c > @@ -0,0 +1,167 @@ > +// 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/interrupt.h> > +#include <linux/mailbox_controller.h> > +#include <linux/module.h> > +#include <linux/platform_device.h> > + > +struct arm_smc_chan_data { > + unsigned int function_id; > +}; > + > +struct arm_smccc_mbox_cmd { > + unsigned int function_id; > + union { > + unsigned int args_smccc32[6]; > + unsigned long args_smccc64[6]; Shouldn't this be u32 and u64 here, as the data type has this explicit length in the SMCCC? > + }; > +}; If this is the data structure that this mailbox controller uses, I would expect this to be documented somewhere, or even exported. And again, I don't like the idea of having the function ID in here. > + > +typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long, > + unsigned long, unsigned long, > + unsigned long, unsigned long, > + unsigned long); > +static 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; > + u32 function_id; > + > + function_id = chan_data->function_id; > + if (!function_id) > + function_id = cmd->function_id; > + > + if (function_id & BIT(30)) { if (ARM_SMCCC_IS_64(function_id)) { > + ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc64[0], > + cmd->args_smccc64[1], > + cmd->args_smccc64[2], > + cmd->args_smccc64[3], > + cmd->args_smccc64[4], > + cmd->args_smccc64[5]); > + } else { > + ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc32[0], > + cmd->args_smccc32[1], > + cmd->args_smccc32[2], > + cmd->args_smccc32[3], > + cmd->args_smccc32[4], > + cmd->args_smccc32[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 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; > + u32 function_id = 0; > + > + if (of_device_is_compatible(dev->of_node, "arm,smc-mbox")) > + invoke_smc_mbox_fn = __invoke_fn_smc; > + else > + invoke_smc_mbox_fn = __invoke_fn_hvc; > + > + mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL); > + if (!mbox) > + return -ENOMEM; > + > + 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; > + > + of_property_read_u32(dev->of_node, "arm,func-id", &function_id); > + chan_data->function_id = function_id; > + > + mbox->chans->con_priv = chan_data; > + > + mbox->txdone_poll = false; > + mbox->txdone_irq = false; Don't we need to provide something to confirm reception to the client? In our case we can set this as soon as the smc/hvc returns. Cheers, Andre. > + 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");
Hi Andre, > Subject: Re: [PATCH V6 2/2] mailbox: introduce ARM SMC based mailbox > > On Mon, 16 Sep 2019 09:44:41 +0000 > Peng Fan <peng.fan@nxp.com> wrote: > > Hi, > > looks quite good now, some smaller comments below. > I think the only thing left is the "function ID passed by the client" topic. > > Have you tried using this interface using hvc, for instance in KVM or Xen? For No. I do not have that implementation in hypervisor. > instance to provide access to a clock for a passed-through platform device? > Another use case that pops up from time to time is GPIO for guests. This > sounds like a use case for using the register interface, also we could use the > hvc return value. > > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore > > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2F&data=02%7C01%7 > Cpeng.fa > > > n%40nxp.com%7C58a1ed4078264d14958f08d73b95ed7e%7C686ea1d3bc2b > 4c6fa92cd > > > 99c5c301635%7C0%7C1%7C637043387484474825&sdata=Cp1zlhlpQbg > BsWu9ZDV > > RKkXmd6kvUR%2BtPO7EPR7YLpA%3D&reserved=0 > > > > Cc: 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 | 167 > > ++++++++++++++++++++++++++++++++++++++ > > 3 files changed, 176 insertions(+) > > create mode 100644 drivers/mailbox/arm-smc-mailbox.c > > > > 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..c84aef39c8d9 > > --- /dev/null > > +++ b/drivers/mailbox/arm-smc-mailbox.c > > @@ -0,0 +1,167 @@ > > +// 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/interrupt.h> > > +#include <linux/mailbox_controller.h> #include <linux/module.h> > > +#include <linux/platform_device.h> > > + > > +struct arm_smc_chan_data { > > + unsigned int function_id; > > +}; > > + > > +struct arm_smccc_mbox_cmd { > > + unsigned int function_id; > > + union { > > + unsigned int args_smccc32[6]; > > + unsigned long args_smccc64[6]; > > Shouldn't this be u32 and u64 here, as the data type has this explicit length in > the SMCCC? ok > > > + }; > > +}; > > If this is the data structure that this mailbox controller uses, I would expect > this to be documented somewhere, or even exported. Export this structure in include/linux/mailbox/smc-mailbox.h? > > And again, I don't like the idea of having the function ID in here. You mean function_id in arm_smccc_mbox_cmd is not good? > > > + > > +typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long, > > + unsigned long, unsigned long, > > + unsigned long, unsigned long, > > + unsigned long); > > +static 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; > > + u32 function_id; > > + > > + function_id = chan_data->function_id; > > + if (!function_id) > > + function_id = cmd->function_id; > > + > > + if (function_id & BIT(30)) { > > if (ARM_SMCCC_IS_64(function_id)) { ok > > > + ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc64[0], > > + cmd->args_smccc64[1], > > + cmd->args_smccc64[2], > > + cmd->args_smccc64[3], > > + cmd->args_smccc64[4], > > + cmd->args_smccc64[5]); > > + } else { > > + ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc32[0], > > + cmd->args_smccc32[1], > > + cmd->args_smccc32[2], > > + cmd->args_smccc32[3], > > + cmd->args_smccc32[4], > > + cmd->args_smccc32[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 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; > > + u32 function_id = 0; > > + > > + if (of_device_is_compatible(dev->of_node, "arm,smc-mbox")) > > + invoke_smc_mbox_fn = __invoke_fn_smc; > > + else > > + invoke_smc_mbox_fn = __invoke_fn_hvc; > > + > > + mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL); > > + if (!mbox) > > + return -ENOMEM; > > + > > + 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; > > + > > + of_property_read_u32(dev->of_node, "arm,func-id", &function_id); > > + chan_data->function_id = function_id; > > + > > + mbox->chans->con_priv = chan_data; > > + > > + mbox->txdone_poll = false; > > + mbox->txdone_irq = false; > > Don't we need to provide something to confirm reception to the client? In our > case we can set this as soon as the smc/hvc returns. As smc/hvc returns, it means the transfer is over and receive is done. Thanks, Peng. > > Cheers, > Andre. > > > + 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");
On Wed, 18 Sep 2019 09:09:25 +0000 Peng Fan <peng.fan@nxp.com> wrote: Hi, > > Subject: Re: [PATCH V6 2/2] mailbox: introduce ARM SMC based mailbox > > > > On Mon, 16 Sep 2019 09:44:41 +0000 > > Peng Fan <peng.fan@nxp.com> wrote: > > > > Hi, > > > > looks quite good now, some smaller comments below. > > I think the only thing left is the "function ID passed by the client" topic. > > > > Have you tried using this interface using hvc, for instance in KVM or Xen? For > > No. I do not have that implementation in hypervisor. OK, I was thinking about this, because this comes up from to time in Xen, for instance. It would allow to pass exactly one "virtual" clock to a guest (using SCMI), which Xen could pass on to Dom0, which would translate this to an the actual clock. I was just worried that having just *one* example implementation might be too little to have a proper generic interface. I started to update my Allwinner ATF mailbox implementation (which was using SCPI), I will let you know when I managed to eventually test this. > > instance to provide access to a clock for a passed-through platform device? > > Another use case that pops up from time to time is GPIO for guests. This > > sounds like a use case for using the register interface, also we could use the > > hvc return value. > > > > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore > > > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2F&data=02%7C01%7 > > Cpeng.fa > > > > > n%40nxp.com%7C58a1ed4078264d14958f08d73b95ed7e%7C686ea1d3bc2b > > 4c6fa92cd > > > > > 99c5c301635%7C0%7C1%7C637043387484474825&sdata=Cp1zlhlpQbg > > BsWu9ZDV > > > RKkXmd6kvUR%2BtPO7EPR7YLpA%3D&reserved=0 > > > > > > Cc: 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 | 167 > > > ++++++++++++++++++++++++++++++++++++++ > > > 3 files changed, 176 insertions(+) > > > create mode 100644 drivers/mailbox/arm-smc-mailbox.c > > > > > > 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..c84aef39c8d9 > > > --- /dev/null > > > +++ b/drivers/mailbox/arm-smc-mailbox.c > > > @@ -0,0 +1,167 @@ > > > +// 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/interrupt.h> > > > +#include <linux/mailbox_controller.h> #include <linux/module.h> > > > +#include <linux/platform_device.h> > > > + > > > +struct arm_smc_chan_data { > > > + unsigned int function_id; > > > +}; > > > + > > > +struct arm_smccc_mbox_cmd { > > > + unsigned int function_id; > > > + union { > > > + unsigned int args_smccc32[6]; > > > + unsigned long args_smccc64[6]; > > > > Shouldn't this be u32 and u64 here, as the data type has this explicit length in > > the SMCCC? > > ok > > > > > > + }; > > > +}; > > > > If this is the data structure that this mailbox controller uses, I would expect > > this to be documented somewhere, or even exported. > > Export this structure in include/linux/mailbox/smc-mailbox.h? For instance, even though I am not sure this is really desired or helpful, since we expect a generic mailbox client (the SCPI or SCMI driver) to deal with that mailbox. But at least the expected format should be documented, which could just be in writing, not necessarily in code. > > And again, I don't like the idea of having the function ID in here. > > You mean function_id in arm_smccc_mbox_cmd is not good? Yes, this should not be something which mailbox clients are able to choose arbitrarily (see my other email). > > > > > + > > > +typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long, > > > + unsigned long, unsigned long, > > > + unsigned long, unsigned long, > > > + unsigned long); > > > +static 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; > > > + u32 function_id; > > > + > > > + function_id = chan_data->function_id; > > > + if (!function_id) > > > + function_id = cmd->function_id; > > > + > > > + if (function_id & BIT(30)) { > > > > if (ARM_SMCCC_IS_64(function_id)) { > > ok > > > > > > + ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc64[0], > > > + cmd->args_smccc64[1], > > > + cmd->args_smccc64[2], > > > + cmd->args_smccc64[3], > > > + cmd->args_smccc64[4], > > > + cmd->args_smccc64[5]); > > > + } else { > > > + ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc32[0], > > > + cmd->args_smccc32[1], > > > + cmd->args_smccc32[2], > > > + cmd->args_smccc32[3], > > > + cmd->args_smccc32[4], > > > + cmd->args_smccc32[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 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; > > > + u32 function_id = 0; > > > + > > > + if (of_device_is_compatible(dev->of_node, "arm,smc-mbox")) > > > + invoke_smc_mbox_fn = __invoke_fn_smc; > > > + else > > > + invoke_smc_mbox_fn = __invoke_fn_hvc; > > > + > > > + mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL); > > > + if (!mbox) > > > + return -ENOMEM; > > > + > > > + 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; > > > + > > > + of_property_read_u32(dev->of_node, "arm,func-id", &function_id); > > > + chan_data->function_id = function_id; > > > + > > > + mbox->chans->con_priv = chan_data; > > > + > > > + mbox->txdone_poll = false; > > > + mbox->txdone_irq = false; > > > > Don't we need to provide something to confirm reception to the client? In our > > case we can set this as soon as the smc/hvc returns. > > As smc/hvc returns, it means the transfer is over and receive is done. I understand that, but was wondering if the Linux mailbox framework knows about that? In my older version I was calling mbox_chan_received_data() after the smc call returned. Also there is mbox_chan_txdone() with which a controller driver can signal TX completion explicitly. Cheers, Andre. > > Cheers, > > Andre. > > > > > + 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"); >
On Wed, Sep 18, 2019 at 5:00 AM Andre Przywara <andre.przywara@arm.com> wrote: > > > > > > > > > + }; > > > > +}; > > > > > > If this is the data structure that this mailbox controller uses, I would expect > > > this to be documented somewhere, or even exported. > > > > Export this structure in include/linux/mailbox/smc-mailbox.h? > > For instance, even though I am not sure this is really desired or helpful, since we expect a generic mailbox client (the SCPI or SCMI driver) to deal with that mailbox. > > But at least the expected format should be documented, which could just be in writing, not necessarily in code. > Yes, the packet format is specified by the controller and defined in some header for clients to include. Other platforms do that already. > > > > + > > > > +typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long, > > > > + unsigned long, unsigned long, > > > > + unsigned long, unsigned long, > > > > + unsigned long); > > > > +static 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; > > > > + u32 function_id; > > > > + > > > > + function_id = chan_data->function_id; > > > > + if (!function_id) > > > > + function_id = cmd->function_id; > > > > + > > > > + if (function_id & BIT(30)) { > > > > > > if (ARM_SMCCC_IS_64(function_id)) { > > > > ok > > > > > > > > > + ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc64[0], > > > > + cmd->args_smccc64[1], > > > > + cmd->args_smccc64[2], > > > > + cmd->args_smccc64[3], > > > > + cmd->args_smccc64[4], > > > > + cmd->args_smccc64[5]); > > > > + } else { > > > > + ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc32[0], > > > > + cmd->args_smccc32[1], > > > > + cmd->args_smccc32[2], > > > > + cmd->args_smccc32[3], > > > > + cmd->args_smccc32[4], > > > > + cmd->args_smccc32[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 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; > > > > + u32 function_id = 0; > > > > + > > > > + if (of_device_is_compatible(dev->of_node, "arm,smc-mbox")) > > > > + invoke_smc_mbox_fn = __invoke_fn_smc; > > > > + else > > > > + invoke_smc_mbox_fn = __invoke_fn_hvc; > > > > + > > > > + mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL); > > > > + if (!mbox) > > > > + return -ENOMEM; > > > > + > > > > + 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; > > > > + > > > > + of_property_read_u32(dev->of_node, "arm,func-id", &function_id); > > > > + chan_data->function_id = function_id; > > > > + > > > > + mbox->chans->con_priv = chan_data; > > > > + > > > > + mbox->txdone_poll = false; > > > > + mbox->txdone_irq = false; > > > > > > Don't we need to provide something to confirm reception to the client? In our > > > case we can set this as soon as the smc/hvc returns. > > > > As smc/hvc returns, it means the transfer is over and receive is done. > > I understand that, but was wondering if the Linux mailbox framework knows about that? In my older version I was calling mbox_chan_received_data() after the smc call returned. > The code already does that at the end of send_data > Also there is mbox_chan_txdone() with which a controller driver can signal TX completion explicitly. > No. Controller can use that only if it has specified txdone_irq, which is not the case here. Thanks
On Wed, 18 Sep 2019 08:31:57 -0500 Jassi Brar <jassisinghbrar@gmail.com> wrote: Hi, > On Wed, Sep 18, 2019 at 5:00 AM Andre Przywara <andre.przywara@arm.com> wrote: > > > > > > > > > > > > > + }; > > > > > +}; > > > > > > > > If this is the data structure that this mailbox controller uses, I would expect > > > > this to be documented somewhere, or even exported. > > > > > > Export this structure in include/linux/mailbox/smc-mailbox.h? > > > > For instance, even though I am not sure this is really desired or helpful, since we expect a generic mailbox client (the SCPI or SCMI driver) to deal with that mailbox. > > > > But at least the expected format should be documented, which could just be in writing, not necessarily in code. > > > Yes, the packet format is specified by the controller and defined in > some header for clients to include. Other platforms do that already. Yeah, I saw some examples as well, but not every driver was following this apparently. I guess since we have a fixed data format we should export the struct then, maybe with a remark that the actual usage of registers is up to the protocol (within the SMCCC limits), so is optional. > > > > > + > > > > > +typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long, > > > > > + unsigned long, unsigned long, > > > > > + unsigned long, unsigned long, > > > > > + unsigned long); > > > > > +static 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; > > > > > + u32 function_id; > > > > > + > > > > > + function_id = chan_data->function_id; > > > > > + if (!function_id) > > > > > + function_id = cmd->function_id; > > > > > + > > > > > + if (function_id & BIT(30)) { > > > > > > > > if (ARM_SMCCC_IS_64(function_id)) { > > > > > > ok > > > > > > > > > > > > + ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc64[0], > > > > > + cmd->args_smccc64[1], > > > > > + cmd->args_smccc64[2], > > > > > + cmd->args_smccc64[3], > > > > > + cmd->args_smccc64[4], > > > > > + cmd->args_smccc64[5]); > > > > > + } else { > > > > > + ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc32[0], > > > > > + cmd->args_smccc32[1], > > > > > + cmd->args_smccc32[2], > > > > > + cmd->args_smccc32[3], > > > > > + cmd->args_smccc32[4], > > > > > + cmd->args_smccc32[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 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; > > > > > + u32 function_id = 0; > > > > > + > > > > > + if (of_device_is_compatible(dev->of_node, "arm,smc-mbox")) > > > > > + invoke_smc_mbox_fn = __invoke_fn_smc; > > > > > + else > > > > > + invoke_smc_mbox_fn = __invoke_fn_hvc; > > > > > + > > > > > + mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL); > > > > > + if (!mbox) > > > > > + return -ENOMEM; > > > > > + > > > > > + 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; > > > > > + > > > > > + of_property_read_u32(dev->of_node, "arm,func-id", &function_id); > > > > > + chan_data->function_id = function_id; > > > > > + > > > > > + mbox->chans->con_priv = chan_data; > > > > > + > > > > > + mbox->txdone_poll = false; > > > > > + mbox->txdone_irq = false; > > > > > > > > Don't we need to provide something to confirm reception to the client? In our > > > > case we can set this as soon as the smc/hvc returns. > > > > > > As smc/hvc returns, it means the transfer is over and receive is done. > > > > I understand that, but was wondering if the Linux mailbox framework knows about that? In my older version I was calling mbox_chan_received_data() after the smc call returned. > > > The code already does that at the end of send_data True, for some reason I totally missed that line, sorry for that. > > Also there is mbox_chan_txdone() with which a controller driver can signal TX completion explicitly. > > > No. Controller can use that only if it has specified txdone_irq, which > is not the case here. I see. So does the framework handle the case where both txdone_poll and txdone_irq are false? Cheers, Andre.
On Wed, Sep 18, 2019 at 8:58 AM Andre Przywara <andre.przywara@arm.com> wrote: > > > > Also there is mbox_chan_txdone() with which a controller driver can signal TX completion explicitly. > > > > > No. Controller can use that only if it has specified txdone_irq, which > > is not the case here. > > I see. So does the framework handle the case where both txdone_poll and txdone_irq are false? > Of course. If there is no IRQ or POLL mechanism for controller to detect tx-done, the only way left is for client driver to know by some 'ack' response (if any). The client should call mbox_client_txdone() Thanks
Hi Jassi, > Subject: Re: [PATCH V6 2/2] mailbox: introduce ARM SMC based mailbox > > On Wed, Sep 18, 2019 at 5:00 AM Andre Przywara > <andre.przywara@arm.com> wrote: > > > > > > > > > > > > > + }; > > > > > +}; > > > > > > > > If this is the data structure that this mailbox controller uses, I > > > > would expect this to be documented somewhere, or even exported. > > > > > > Export this structure in include/linux/mailbox/smc-mailbox.h? > > > > For instance, even though I am not sure this is really desired or helpful, since > we expect a generic mailbox client (the SCPI or SCMI driver) to deal with that > mailbox. > > > > But at least the expected format should be documented, which could just be > in writing, not necessarily in code. > > > Yes, the packet format is specified by the controller and defined in some > header for clients to include. Other platforms do that already. So you prefer add the structure in include/linux/mailbox/smc-mailbox.h? Thanks, Peng. > > > > > > > > + > > > > > +typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long, > > > > > + unsigned long, unsigned long, > > > > > + unsigned long, unsigned long, > > > > > + unsigned long); static > 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; > > > > > + u32 function_id; > > > > > + > > > > > + function_id = chan_data->function_id; if (!function_id) > > > > > + function_id = cmd->function_id; > > > > > + > > > > > + if (function_id & BIT(30)) { > > > > > > > > if (ARM_SMCCC_IS_64(function_id)) { > > > > > > ok > > > > > > > > > > > > + ret = invoke_smc_mbox_fn(function_id, > cmd->args_smccc64[0], > > > > > + cmd->args_smccc64[1], > > > > > + cmd->args_smccc64[2], > > > > > + cmd->args_smccc64[3], > > > > > + cmd->args_smccc64[4], > > > > > + cmd->args_smccc64[5]); } > else > > > > > + { > > > > > + ret = invoke_smc_mbox_fn(function_id, > cmd->args_smccc32[0], > > > > > + cmd->args_smccc32[1], > > > > > + cmd->args_smccc32[2], > > > > > + cmd->args_smccc32[3], > > > > > + cmd->args_smccc32[4], > > > > > + cmd->args_smccc32[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 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; > > > > > + u32 function_id = 0; > > > > > + > > > > > + if (of_device_is_compatible(dev->of_node, "arm,smc-mbox")) > > > > > + invoke_smc_mbox_fn = __invoke_fn_smc; else > > > > > + invoke_smc_mbox_fn = __invoke_fn_hvc; > > > > > + > > > > > + mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL); if > > > > > + (!mbox) > > > > > + return -ENOMEM; > > > > > + > > > > > + mbox->num_chans = 1; > > > > > + mbox->chans = devm_kzalloc(dev, sizeof(*mbox->chans), > > > > > + mbox->GFP_KERNEL); > > > > > + if (!mbox->chans) > > > > > + return -ENOMEM; > > > > > + > > > > > + chan_data = devm_kzalloc(dev, sizeof(*chan_data), GFP_KERNEL); > > > > > + if (!chan_data) > > > > > + return -ENOMEM; > > > > > + > > > > > + of_property_read_u32(dev->of_node, "arm,func-id", > > > > > + &function_id); chan_data->function_id = function_id; > > > > > + > > > > > + mbox->chans->con_priv = chan_data; > > > > > + > > > > > + mbox->txdone_poll = false; > > > > > + mbox->txdone_irq = false; > > > > > > > > Don't we need to provide something to confirm reception to the > > > > client? In our case we can set this as soon as the smc/hvc returns. > > > > > > As smc/hvc returns, it means the transfer is over and receive is done. > > > > I understand that, but was wondering if the Linux mailbox framework knows > about that? In my older version I was calling mbox_chan_received_data() > after the smc call returned. > > > The code already does that at the end of send_data > > > Also there is mbox_chan_txdone() with which a controller driver can signal > TX completion explicitly. > > > No. Controller can use that only if it has specified txdone_irq, which is not the > case here. > > Thanks
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..c84aef39c8d9 --- /dev/null +++ b/drivers/mailbox/arm-smc-mailbox.c @@ -0,0 +1,167 @@ +// 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/interrupt.h> +#include <linux/mailbox_controller.h> +#include <linux/module.h> +#include <linux/platform_device.h> + +struct arm_smc_chan_data { + unsigned int function_id; +}; + +struct arm_smccc_mbox_cmd { + unsigned int function_id; + union { + unsigned int args_smccc32[6]; + unsigned long args_smccc64[6]; + }; +}; + +typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long, + unsigned long, unsigned long, + unsigned long, unsigned long, + unsigned long); +static 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; + u32 function_id; + + function_id = chan_data->function_id; + if (!function_id) + function_id = cmd->function_id; + + if (function_id & BIT(30)) { + ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc64[0], + cmd->args_smccc64[1], + cmd->args_smccc64[2], + cmd->args_smccc64[3], + cmd->args_smccc64[4], + cmd->args_smccc64[5]); + } else { + ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc32[0], + cmd->args_smccc32[1], + cmd->args_smccc32[2], + cmd->args_smccc32[3], + cmd->args_smccc32[4], + cmd->args_smccc32[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 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; + u32 function_id = 0; + + if (of_device_is_compatible(dev->of_node, "arm,smc-mbox")) + invoke_smc_mbox_fn = __invoke_fn_smc; + else + invoke_smc_mbox_fn = __invoke_fn_hvc; + + mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL); + if (!mbox) + return -ENOMEM; + + 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; + + of_property_read_u32(dev->of_node, "arm,func-id", &function_id); + chan_data->function_id = function_id; + + 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");