From: Oleksij Rempel <o.rempel@pengutronix.de>
To: "A.s. Dong" <aisheng.dong@nxp.com>,
Shawn Guo <shawnguo@kernel.org>,
Fabio Estevam <fabio.estevam@nxp.com>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>
Cc: "kernel@pengutronix.de" <kernel@pengutronix.de>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
dl-linux-imx <linux-imx@nxp.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>
Subject: Re: [PATCH v2 4/4] mailbox: Add support for i.MX7D messaging unit
Date: Tue, 26 Jun 2018 12:56:04 +0200 [thread overview]
Message-ID: <66bc8ac0-913a-f444-e554-ade4df1306b6@pengutronix.de> (raw)
In-Reply-To: <AM0PR04MB4211BBB72255BDA36C5AFF9880490@AM0PR04MB4211.eurprd04.prod.outlook.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 12193 bytes --]
On 26.06.2018 12:09, A.s. Dong wrote:
>> -----Original Message-----
>> From: Oleksij Rempel [mailto:o.rempel@pengutronix.de]
>> Sent: Friday, June 15, 2018 5:51 PM
>> To: Shawn Guo <shawnguo@kernel.org>; Fabio Estevam
>> <fabio.estevam@nxp.com>; Rob Herring <robh+dt@kernel.org>; Mark
>> Rutland <mark.rutland@arm.com>; A.s. Dong <aisheng.dong@nxp.com>
>> Cc: Oleksij Rempel <o.rempel@pengutronix.de>; kernel@pengutronix.de;
>> linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; linux-
>> clk@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
>> Subject: [PATCH v2 4/4] mailbox: Add support for i.MX7D messaging unit
>>
>> The Mailbox controller is able to send messages (up to 4 32 bit words)
>> between the endpoints.
>>
>> This driver was tested using the mailbox-test driver sending messages
>> between the Cortex-A7 and the Cortex-M4.
>>
>> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
>> ---
>> drivers/mailbox/Kconfig | 6 +
>> drivers/mailbox/Makefile | 2 +
>> drivers/mailbox/imx-mailbox.c | 288
>> ++++++++++++++++++++++++++++++++++
>> 3 files changed, 296 insertions(+)
>> create mode 100644 drivers/mailbox/imx-mailbox.c
>>
>> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index
>> a2bb27446dce..e1d2738a2e4c 100644
>> --- a/drivers/mailbox/Kconfig
>> +++ b/drivers/mailbox/Kconfig
>> @@ -15,6 +15,12 @@ config ARM_MHU
>> The controller has 3 mailbox channels, the last of which can be
>> used in Secure mode only.
>>
>> +config IMX_MBOX
>> + tristate "iMX Mailbox"
>> + depends on SOC_IMX7D || COMPILE_TEST
>> + help
>> + Mailbox implementation for iMX7D Messaging Unit (MU).
>> +
>> config PLATFORM_MHU
>> tristate "Platform MHU Mailbox"
>> depends on OF
>> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index
>> cc23c3a43fcd..ba2fe1b6dd62 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_IMX_MBOX) += imx-mailbox.o
>> +
>> obj-$(CONFIG_PLATFORM_MHU) += platform_mhu.o
>>
>> obj-$(CONFIG_PL320_MBOX) += pl320-ipc.o
>> diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
>> new file mode 100644 index 000000000000..e3f621cb1d30
>> --- /dev/null
>> +++ b/drivers/mailbox/imx-mailbox.c
>> @@ -0,0 +1,288 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (c) 2018 Pengutronix, Oleksij Rempel
>> +<o.rempel@pengutronix.de> */
>> +
>> +#include <linux/clk.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/io.h>
>> +#include <linux/kernel.h>
>> +#include <linux/mailbox_controller.h>
>> +#include <linux/module.h>
>> +#include <linux/of_device.h>
>> +
>> +/* Transmit Register */
>> +#define IMX_MU_xTRn(x) (0x00 + 4 * (x))
>> +/* Receive Register */
>> +#define IMX_MU_xRRn(x) (0x10 + 4 * (x))
>> +/* Status Register */
>> +#define IMX_MU_xSR 0x20
>> +#define IMX_MU_xSR_TEn(x) BIT(20 + (x))
>> +#define IMX_MU_xSR_RFn(x) BIT(24 + (x))
>> +#define IMX_MU_xSR_BRDIP BIT(9)
>> +
>> +/* Control Register */
>> +#define IMX_MU_xCR 0x24
>> +/* Transmit Interrupt Enable */
>> +#define IMX_MU_xCR_TIEn(x) BIT(20 + (x))
>> +/* Receive Interrupt Enable */
>> +#define IMX_MU_xCR_RIEn(x) BIT(24 + (x))
>> +
>> +#define IMX_MU_MAX_CHANS 4u
>> +
>> +struct imx_mu_priv;
>> +
>> +struct imx_mu_cfg {
>> + unsigned int chans;
>> + void (*init_hw)(struct imx_mu_priv *priv); };
>> +
>> +struct imx_mu_con_priv {
>> + int irq;
>> + unsigned int bidx;
>> + unsigned int idx;
>> +};
>> +
>> +struct imx_mu_priv {
>> + struct device *dev;
>> + const struct imx_mu_cfg *dcfg;
>> + void __iomem *base;
>> +
>> + struct mbox_controller mbox;
>> + struct mbox_chan mbox_chans[IMX_MU_MAX_CHANS];
>> +
>> + struct imx_mu_con_priv con_priv[IMX_MU_MAX_CHANS];
>> + struct clk *clk;
>> +};
>> +
>> +static struct imx_mu_priv *to_imx_mu_priv(struct mbox_controller *mbox)
>> +{
>> + return container_of(mbox, struct imx_mu_priv, mbox); }
>> +
>> +static void imx_mu_write(struct imx_mu_priv *priv, u32 val, u32 offs) {
>> + iowrite32(val, priv->base + offs);
>> +}
>> +
>> +static u32 imx_mu_read(struct imx_mu_priv *priv, u32 offs) {
>> + return ioread32(priv->base + offs);
>> +}
>> +
>> +static u32 imx_mu_rmw(struct imx_mu_priv *priv, u32 offs, u32 set, u32
>> +clr) {
>> + u32 val;
>> +
>> + val = imx_mu_read(priv, offs);
>> + val &= ~clr;
>> + val |= set;
>> + imx_mu_write(priv, val, offs);
>> +
>> + return val;
>> +}
>> +
>> +static irqreturn_t imx_mu_isr(int irq, void *p) {
>> + struct mbox_chan *chan = p;
>> + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
>> + struct imx_mu_con_priv *cp = chan->con_priv;
>> +
>> + u32 val, dat;
>> +
>> + val = imx_mu_read(priv, IMX_MU_xSR);
>> + val &= IMX_MU_xSR_TEn(cp->bidx) | IMX_MU_xSR_RFn(cp->bidx);
>> + if (!val)
>> + return IRQ_NONE;
>> +
>> + if (val & IMX_MU_xSR_TEn(cp->bidx)) {
>
> I'm wondering whether this can work properly for multi consumers
> at the same time.
> Because xSR_TEn is 1 by default and four virtual channels actually
> are using the same interrupt. That means channel 1 interrupt may
> cause channel 2 believe it's txdone.
> Have we tested such using?
see imx_mu_send_data()
..... imx_mu_rmw(priv, IMX_MU_xCR, IMX_MU_xSR_TEn(cp->bidx), 0);
>
>> + imx_mu_rmw(priv, IMX_MU_xCR, 0, IMX_MU_xCR_TIEn(cp-
>>> bidx));
and here ^^^
TX status is enabled only for send and disabled as soon at transfer is done.
>> + mbox_chan_txdone(chan, 0);
>> + }
>> +
>> + if (val & IMX_MU_xSR_RFn(cp->bidx)) {
>> + dat = imx_mu_read(priv, IMX_MU_xRRn(cp->idx));
>> + mbox_chan_received_data(chan, (void *)&dat);
>> + }
>> +
>> + return IRQ_HANDLED;
>> +}
>> +
>> +static bool imx_mu_last_tx_done(struct mbox_chan *chan) {
>> + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
>> + struct imx_mu_con_priv *cp = chan->con_priv;
>> + u32 val;
>> +
>> + val = imx_mu_read(priv, IMX_MU_xSR);
>> + /* test if transmit register is empty */
>> + return (!!(val & IMX_MU_xSR_TEn(cp->bidx))); }
>> +
>> +static int imx_mu_send_data(struct mbox_chan *chan, void *data) {
>> + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
>> + struct imx_mu_con_priv *cp = chan->con_priv;
>> + u32 *arg = data;
>> +
>> + if (!imx_mu_last_tx_done(chan))
>> + return -EBUSY;
>> +
>> + imx_mu_write(priv, *arg, IMX_MU_xTRn(cp->idx));
>> + imx_mu_rmw(priv, IMX_MU_xCR, IMX_MU_xSR_TEn(cp->bidx), 0);
>> +
>> + return 0;
>> +}
>
> Since Sascha is requesting to write a generic MU mailbox driver for both
> SCU MU and M4 case, the current way using virtual channels in this patch
> only send one word a time obviously can't fit for SCU MU clients well.
> Do you think if we can refer to TI case to design a generic data transfer
> protocol to allow send multi words which is more close to SCU?
According to your code, you are able to send 1 word message. It means,
your SCU is configured to trigger an interrupt or status update if REG0
was written. The same is true for 2, 3, 4 and 5 word messages.
If the MU configuration would look like you it described, you would be
forced to write always 4 words, even for 1 word message.
> include/linux/soc/ti/ti-msgmgr.h
> struct ti_msgmgr_message {
> size_t len;
> u8 *buf;
> };
>
> Or we try to support both type transfer protocols in this driver?
Sure. ti-msgmgr.c is a good example. You will probably need reduced
variant of it. It is generic enough to make it useful not only for SCU.
> That may introduce much complexities, personally I'm not quite
> like that.
I expect 50-150 lines of extra code.
> Regards
> Dong Aisheng
>
>> +
>> +static int imx_mu_startup(struct mbox_chan *chan) {
>> + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
>> + struct imx_mu_con_priv *cp = chan->con_priv;
>> + int ret;
>> +
>> + ret = request_irq(cp->irq, imx_mu_isr,
>> + IRQF_SHARED, "imx_mu_chan", chan);
>> + if (ret) {
>> + dev_err(chan->mbox->dev,
>> + "Unable to acquire IRQ %d\n", cp->irq);
>> + return ret;
>> + }
>> +
>> + imx_mu_rmw(priv, IMX_MU_xCR, IMX_MU_xCR_RIEn(cp->bidx), 0);
>> +
>> + return 0;
>> +}
>> +
>> +static void imx_mu_shutdown(struct mbox_chan *chan) {
>> + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
>> + struct imx_mu_con_priv *cp = chan->con_priv;
>> +
>> + imx_mu_rmw(priv, IMX_MU_xCR, 0,
>> + IMX_MU_xCR_TIEn(cp->bidx) | IMX_MU_xCR_RIEn(cp-
>>> bidx));
>> +
>> + free_irq(cp->irq, chan);
>> +}
>> +
>> +static const struct mbox_chan_ops imx_mu_ops = {
>> + .send_data = imx_mu_send_data,
>> + .startup = imx_mu_startup,
>> + .shutdown = imx_mu_shutdown,
>> +};
>> +
>> +static int imx_mu_probe(struct platform_device *pdev) {
>> + struct device *dev = &pdev->dev;
>> + struct resource *iomem;
>> + struct imx_mu_priv *priv;
>> + const struct imx_mu_cfg *dcfg;
>> + unsigned int i, chans;
>> + int irq, ret;
>> +
>> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>> + if (!priv)
>> + return -ENOMEM;
>> +
>> + dcfg = of_device_get_match_data(dev);
>> + if (!dcfg)
>> + return -EINVAL;
>> +
>> + priv->dcfg = dcfg;
>> + priv->dev = dev;
>> +
>> + iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + priv->base = devm_ioremap_resource(&pdev->dev, iomem);
>> + if (IS_ERR(priv->base))
>> + return PTR_ERR(priv->base);
>> +
>> + irq = platform_get_irq(pdev, 0);
>> + if (irq <= 0)
>> + return irq < 0 ? irq : -EINVAL;
>> +
>> + priv->clk = devm_clk_get(dev, NULL);
>> + if (IS_ERR(priv->clk)) {
>> + if (PTR_ERR(priv->clk) == -ENOENT) {
>> + priv->clk = NULL;
>> + } else {
>> + dev_err(dev, "Failed to get clock\n");
>> + return PTR_ERR(priv->clk);
>> + }
>> + }
>> +
>> + ret = clk_prepare_enable(priv->clk);
>> + if (ret) {
>> + dev_err(dev, "Failed to enable clock\n");
>> + return ret;
>> + }
>> +
>> + chans = min(dcfg->chans, IMX_MU_MAX_CHANS);
>> + /* Initialize channel identifiers */
>> + for (i = 0; i < chans; i++) {
>> + struct imx_mu_con_priv *cp = &priv->con_priv[i];
>> +
>> + cp->bidx = 3 - i;
>> + cp->idx = i;
>> + cp->irq = irq;
>> + priv->mbox_chans[i].con_priv = cp;
>> + }
>> +
>> + priv->mbox.dev = dev;
>> + priv->mbox.ops = &imx_mu_ops;
>> + priv->mbox.chans = priv->mbox_chans;
>> + priv->mbox.num_chans = chans;
>> + priv->mbox.txdone_irq = true;
>> +
>> + platform_set_drvdata(pdev, priv);
>> +
>> + if (priv->dcfg->init_hw)
>> + priv->dcfg->init_hw(priv);
>> +
>> + return mbox_controller_register(&priv->mbox);
>> +}
>> +
>> +static int imx_mu_remove(struct platform_device *pdev) {
>> + struct imx_mu_priv *priv = platform_get_drvdata(pdev);
>> +
>> + mbox_controller_unregister(&priv->mbox);
>> + clk_disable_unprepare(priv->clk);
>> +
>> + return 0;
>> +}
>> +
>> +
>> +static void imx_mu_init_imx7d_a(struct imx_mu_priv *priv) {
>> + /* Set default config */
>> + imx_mu_write(priv, 0, IMX_MU_xCR);
>> +}
>> +
>> +static const struct imx_mu_cfg imx_mu_cfg_imx7d_a = {
>> + .chans = IMX_MU_MAX_CHANS,
>> + .init_hw = imx_mu_init_imx7d_a,
>> +};
>> +
>> +static const struct imx_mu_cfg imx_mu_cfg_imx7d_b = {
>> + .chans = IMX_MU_MAX_CHANS,
>> +};
>> +
>> +static const struct of_device_id imx_mu_dt_ids[] = {
>> + { .compatible = "fsl,imx7s-mu-a", .data = &imx_mu_cfg_imx7d_a },
>> + { .compatible = "fsl,imx7s-mu-b", .data = &imx_mu_cfg_imx7d_b },
>> + { },
>> +};
>> +MODULE_DEVICE_TABLE(of, imx_mu_dt_ids);
>> +
>> +static struct platform_driver imx_mu_driver = {
>> + .probe = imx_mu_probe,
>> + .remove = imx_mu_remove,
>> + .driver = {
>> + .name = "imx_mu",
>> + .of_match_table = imx_mu_dt_ids,
>> + },
>> +};
>> +module_platform_driver(imx_mu_driver);
>> +
>> +MODULE_AUTHOR("Oleksij Rempel <o.rempel@pengutronix.de>");
>> +MODULE_DESCRIPTION("Message Unit driver for i.MX");
>> MODULE_LICENSE("GPL
>> +v2");
>> --
>> 2.17.1
>
>
>
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2018-06-26 10:56 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-15 9:51 [PATCH v2 0/4] add mailbox support for i.MX7D Oleksij Rempel
2018-06-15 9:51 ` [PATCH v2 1/4] clk: imx7d: add IMX7D_MU_ROOT_CLK Oleksij Rempel
2018-07-09 6:22 ` Stephen Boyd
2018-07-09 6:28 ` Oleksij Rempel
2018-07-09 8:18 ` A.s. Dong
2018-07-09 12:47 ` Fabio Estevam
2018-07-09 16:57 ` Stephen Boyd
2018-06-15 9:51 ` [PATCH v2 2/4] dt-bindings: mailbox: provide imx-mailbox documentation Oleksij Rempel
2018-06-18 8:53 ` Leonard Crestez
2018-06-18 11:51 ` Oleksij Rempel
2018-06-15 9:51 ` [PATCH v2 3/4] ARM: dts: imx7s: add i.MX7 messaging unit support Oleksij Rempel
2018-06-15 9:51 ` [PATCH v2 4/4] mailbox: Add support for i.MX7D messaging unit Oleksij Rempel
2018-06-26 10:09 ` A.s. Dong
2018-06-26 10:56 ` Oleksij Rempel [this message]
2018-06-26 12:07 ` A.s. Dong
2018-07-02 7:35 ` Oleksij Rempel
2018-06-26 13:23 ` Sascha Hauer
2018-06-27 3:18 ` A.s. Dong
2018-07-12 11:28 ` A.s. Dong
2018-07-14 7:02 ` Oleksij Rempel
2018-07-14 8:49 ` A.s. Dong
2018-07-14 9:41 ` Oleksij Rempel
2018-07-14 11:41 ` A.s. Dong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=66bc8ac0-913a-f444-e554-ade4df1306b6@pengutronix.de \
--to=o.rempel@pengutronix.de \
--cc=aisheng.dong@nxp.com \
--cc=devicetree@vger.kernel.org \
--cc=fabio.estevam@nxp.com \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-imx@nxp.com \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=shawnguo@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).