[{"id":1794762,"web_url":"http://patchwork.ozlabs.org/comment/1794762/","msgid":"<90d25374-cc83-7f75-eb38-766f0cdb9c53@arm.com>","list_archive_url":null,"date":"2017-10-27T10:40:59","subject":"Re: [PATCH v2 2/3] mailbox: Add support for Hi3660 mailbox","submitter":{"id":72256,"url":"http://patchwork.ozlabs.org/api/people/72256/","name":"Julien Thierry","email":"julien.thierry@arm.com"},"content":"Hi Kaihua,\n\nOn 27/10/17 07:15, Kaihua Zhong wrote:\n> Hi3660 mailbox controller is used to send message within multiple\n> processors, MCU, HIFI, etc. It supports 32 mailbox channels and every\n> channel can only be used for single transferring direction. Once the\n> channel is enabled, it needs to specify the destination interrupt and\n> acknowledge interrupt, these two interrupt vectors are used to create\n> the connection between the mailbox and interrupt controllers.\n> \n> The application processor (or from point of view of kernel) is not the\n> only one master which can launch the data transferring, other\n> processors or MCU/DSP also can kick off the data transferring. So this\n> driver implements a locking mechanism to support exclusive accessing.\n> \n> The data transferring supports two modes, one is named as \"automatic\n> acknowledge\" mode so after send message the kernel doesn't need to wait\n> for acknowledge from remote and directly return; there have another mode\n> is to rely on handling interrupt for acknowledge.\n> \n> This commit is for initial version driver, which only supports\n> \"automatic acknowledge\" mode to support CPU clock, which is the only\n> one consumer to use mailbox and has been verified. Later may enhance\n> this driver for interrupt mode (e.g. for supporting HIFI).\n> \n> Cc: John Stultz \n> Cc: Guodong Xu \n> Cc: Haojian Zhuang \n> Cc: Niranjan Yadla \n> Cc: Raj Pawate \n> Signed-off-by: Leo Yan \n> Signed-off-by: Ruyi Wang \n> Signed-off-by: Kaihua Zhong \n> Signed-off-by: Kevin Wang \n> ---\n> drivers/mailbox/Kconfig | 8 +\n> drivers/mailbox/Makefile | 2 +\n> drivers/mailbox/hi3660-mailbox.c | 331 +++++++++++++++++++++++++++++++++++++++\n> 3 files changed, 341 insertions(+)\n> create mode 100644 drivers/mailbox/hi3660-mailbox.c\n> \n> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig\n> index c5731e5..4b5d6e9 100644\n> --- a/drivers/mailbox/Kconfig\n> +++ b/drivers/mailbox/Kconfig\n> @@ -108,6 +108,14 @@ config TI_MESSAGE_MANAGER\n> \t multiple processors within the SoC. Select this driver if your\n> \t platform has support for the hardware block.\n> \n> +config HI3660_MBOX\n> +\ttristate \"Hi3660 Mailbox\"\n> +\tdepends on ARCH_HISI && OF\n> +\thelp\n> +\t An implementation of the hi3660 mailbox. It is used to send message\n> +\t between application processors and other processors/MCU/DSP. Select\n> +\t Y here if you want to use Hi3660 mailbox controller.\n> +\n> config HI6220_MBOX\n> \ttristate \"Hi6220 Mailbox\"\n> \tdepends on ARCH_HISI\n> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile\n> index d54e412..7d1bd51 100644\n> --- a/drivers/mailbox/Makefile\n> +++ b/drivers/mailbox/Makefile\n> @@ -26,6 +26,8 @@ obj-$(CONFIG_TI_MESSAGE_MANAGER) += ti-msgmgr.o\n> \n> obj-$(CONFIG_XGENE_SLIMPRO_MBOX) += mailbox-xgene-slimpro.o\n> \n> +obj-$(CONFIG_HI3660_MBOX)\t+= hi3660-mailbox.o\n> +\n> obj-$(CONFIG_HI6220_MBOX)\t+= hi6220-mailbox.o\n> \n> obj-$(CONFIG_BCM_PDC_MBOX)\t+= bcm-pdc-mailbox.o\n> diff --git a/drivers/mailbox/hi3660-mailbox.c b/drivers/mailbox/hi3660-mailbox.c\n> new file mode 100644\n> index 0000000..67df8f8\n> --- /dev/null\n> +++ b/drivers/mailbox/hi3660-mailbox.c\n> @@ -0,0 +1,331 @@\n> +/*\n> + * Hisilicon's Hi3660 mailbox controller driver\n> + *\n> + * Copyright (c) 2017 Hisilicon Limited.\n> + * Copyright (c) 2017 Linaro Limited.\n> + *\n> + * Author: Leo Yan \n> + *\n> + * This program is free software: you can redistribute it and/or modify\n> + * it under the terms of the GNU General Public License as published by\n> + * the Free Software Foundation, version 2 of the License.\n> + *\n> + * This program is distributed in the hope that it will be useful,\n> + * but WITHOUT ANY WARRANTY; without even the implied warranty of\n> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\n> + * GNU General Public License for more details.\n> + *\n> + */\n> +\n> +#include \n> +#include \n> +#include \n> +#include \n> +#include \n> +#include \n> +#include \n> +#include \n> +#include \n> +#include \n> +#include \n> +\n> +#include \"mailbox.h\"\n> +\n> +#define MBOX_CHAN_MAX\t\t\t32\n> +\n> +#define MBOX_RX\t\t\t\t(0x0)\n> +#define MBOX_TX\t\t\t\t(0x1)\n> +\n> +#define MBOX_BASE(mbox, ch)\t\t((mbox)->base + ((ch) * 0x40))\n> +#define MBOX_SRC_REG\t\t\t(0x00)\n> +#define MBOX_DST_REG\t\t\t(0x04)\n> +#define MBOX_DCLR_REG\t\t\t(0x08)\n> +#define MBOX_DSTAT_REG\t\t\t(0x0c)\n> +#define MBOX_MODE_REG\t\t\t(0x10)\n> +#define MBOX_IMASK_REG\t\t\t(0x14)\n> +#define MBOX_ICLR_REG\t\t\t(0x18)\n> +#define MBOX_SEND_REG\t\t\t(0x1c)\n> +#define MBOX_DATA_REG\t\t\t(0x20)\n> +\n> +#define MBOX_IPC_LOCK_REG\t\t(0xa00)\n> +#define MBOX_IPC_UNLOCK\t\t\t(0x1acce551)\n> +\n> +#define MBOX_AUTOMATIC_ACK\t\t(1)\n> +\n> +#define MBOX_STATE_IDLE\t\t\tBIT(4)\n> +#define MBOX_STATE_ACK\t\t\tBIT(7)\n> +\n> +#define MBOX_MSG_LEN\t\t\t8\n> +\n> +/**\n> + * Hi3660 mailbox channel device data\n> + *\n> + * A channel can be used for TX or RX, it can trigger remote\n> + * processor interrupt to notify remote processor and can receive\n> + * interrupt if has incoming message.\n> + *\n> + * @dst_irq:\tInterrupt vector for remote processor\n> + * @ack_irq:\tInterrupt vector for local processor\n> + */\n> +struct hi3660_mbox_dev {\n> +\tunsigned int dst_irq;\n> +\tunsigned int ack_irq;\n> +};\n> +\n> +/**\n> + * Hi3660 mailbox controller data\n> + *\n> + * Mailbox controller includes 32 channels and can allocate\n> + * channel for message transferring.\n> + *\n> + * @dev:\tDevice to which it is attached\n> + * @base:\tBase address of the register mapping region\n> + * @chan:\tRepresentation of channels in mailbox controller\n> + * @mdev:\tRepresentation of channel device data\n> + * @controller:\tRepresentation of a communication channel controller\n> + */\n> +struct hi3660_mbox {\n> +\tstruct device *dev;\n> +\tvoid __iomem *base;\n> +\tstruct mbox_chan chan[MBOX_CHAN_MAX];\n> +\tstruct hi3660_mbox_dev mdev[MBOX_CHAN_MAX];\n> +\tstruct mbox_controller controller;\n> +};\n> +\n> +static inline struct hi3660_mbox *to_hi3660_mbox(struct mbox_chan *chan)\n> +{\n> +\treturn container_of(chan->mbox, struct hi3660_mbox, controller);\n> +}\n> +\n> +static int hi3660_mbox_check_state(struct mbox_chan *chan)\n> +{\n> +\tunsigned long ch = (unsigned long)chan->con_priv;\n> +\tstruct hi3660_mbox *mbox = to_hi3660_mbox(chan);\n> +\tstruct hi3660_mbox_dev *mdev = &mbox->mdev[ch];\n> +\tvoid __iomem *base = MBOX_BASE(mbox, ch);\n> +\tunsigned long val;\n> +\tunsigned int state, ret;\n> +\n> +\t/* Mailbox is idle so directly bail out */\n> +\tstate = readl_relaxed(base + MBOX_MODE_REG);\n> +\tif (state & MBOX_STATE_IDLE)\n> +\t\treturn 0;\n> +\n> +\t/* Wait for acknowledge from remote */\n> +\tret = readx_poll_timeout_atomic(readl_relaxed, base + MBOX_MODE_REG,\n> +\t\t\tval, (val & MBOX_STATE_ACK), 1000, 300000);\n> +\tif (ret) {\n> +\t\tdev_err(mbox->dev, \"%s: timeout for receiving ack\\n\", __func__);\n> +\t\treturn ret;\n> +\t}\n> +\n> +\t/* Ensure channel is released */\n> +\twritel_relaxed(0xffffffff, base + MBOX_IMASK_REG);\n> +\twritel_relaxed(BIT(mdev->ack_irq), base + MBOX_SRC_REG);\n> +\t__asm__ volatile (\"sev\");\n\nThere is an existing sev() macro for this.\n\n> +\treturn 0;\n> +}\n> +\n> +static int hi3660_mbox_unlock(struct mbox_chan *chan)\n> +{\n> +\tstruct hi3660_mbox *mbox = to_hi3660_mbox(chan);\n> +\tunsigned int val, retry = 3;\n> +\n> +\tdo {\n> +\t\twritel_relaxed(MBOX_IPC_UNLOCK, mbox->base + MBOX_IPC_LOCK_REG);\n> +\n> +\t\tval = readl_relaxed(mbox->base + MBOX_IPC_LOCK_REG);\n> +\t\tif (!val)\n> +\t\t\tbreak;\n> +\n> +\t\tudelay(10);\n> +\t} while (retry--);\n> +\n> +\treturn (!val) ? 0 : -ETIMEDOUT;\n> +}\n> +\n> +static int hi3660_mbox_acquire_channel(struct mbox_chan *chan)\n> +{\n> +\tunsigned long ch = (unsigned long)chan->con_priv;\n> +\tstruct hi3660_mbox *mbox = to_hi3660_mbox(chan);\n> +\tstruct hi3660_mbox_dev *mdev = &mbox->mdev[ch];\n> +\tvoid __iomem *base = MBOX_BASE(mbox, ch);\n> +\tunsigned int val = 0, retry = 10;\n> +\n> +\t/*\n> +\t * Hardware locking for exclusive accessing within CPUs\n> +\t * without exclusive monitor mechanism.\n> +\t */\n> +\tdo {\n> +\t\tval = readl_relaxed(base + MBOX_MODE_REG);\n> +\t\tif (!(val & MBOX_STATE_IDLE)) {\n> +\t\t\t__asm__ volatile (\"wfe\");\n> +\t\t\tcontinue;\n\nSo this is going to \"wfe\" when retry == 0 and the continue statement \nwill take us out of the loop?\n\nAlso, there is a wfe() macro for arm and arm64 which could be used here.\n\n> +\t\t}\n> +\n> +\t\t/* Check if channel has be acquired */\n> +\t\twritel_relaxed(BIT(mdev->ack_irq), base + MBOX_SRC_REG);\n> +\t\tval = readl_relaxed(base + MBOX_SRC_REG) & BIT(mdev->ack_irq);\n> +\t\tif (val)\n> +\t\t\tbreak;\n> +\n> +\t} while (retry--);\n> +\n> +\treturn (val) ? 0 : -ETIMEDOUT;\n\nIf timeout occurs while waiting for the MBOX to be idle, val will hold \nthe last value from MBOX_MODE_REG, and if this can be different than 0, \nthis will hide the fact it timed out.\n\nMaybe the following would be more appropriate:\n\nreturn (retry >= 0) ? 0 : -ETIMEDOUT;\n\nAlso, your do {} while loops for the timeouts falsely give the \nimpression we do \"retry\" attempts when we actually do \"retry + 1\" \nattempts (but I guess it doesn't make a big difference from the \nfunctional point of view).\n\n> +}\n> +\n> +static int hi3660_mbox_send(struct mbox_chan *chan, u32 *msg)\n> +{\n> +\tunsigned long ch = (unsigned long)chan->con_priv;\n> +\tstruct hi3660_mbox *mbox = to_hi3660_mbox(chan);\n> +\tstruct hi3660_mbox_dev *mdev = &mbox->mdev[ch];\n> +\tvoid __iomem *base = MBOX_BASE(mbox, ch);\n> +\tunsigned int i;\n> +\n> +\t/* Clear mask for destination interrupt */\n> +\twritel_relaxed(~BIT(mdev->dst_irq), base + MBOX_IMASK_REG);\n> +\n> +\t/* Config destination for interrupt vector */\n> +\twritel_relaxed(BIT(mdev->dst_irq), base + MBOX_DST_REG);\n> +\n> +\t/* Automatic acknowledge mode */\n> +\twritel_relaxed(MBOX_AUTOMATIC_ACK, base + MBOX_MODE_REG);\n> +\n> +\t/* Fill message data */\n> +\tfor (i = 0; i < MBOX_MSG_LEN; i++)\n> +\t\twritel_relaxed(msg[i], base + MBOX_DATA_REG + i * 4);\n> +\n> +\t/* Trigger data transferring */\n> +\twritel_relaxed(BIT(mdev->ack_irq), base + MBOX_SEND_REG);\n> +\treturn 0;\n> +}\n> +\n> +static int hi3660_mbox_send_data(struct mbox_chan *chan, void *msg)\n> +{\n> +\tstruct hi3660_mbox *mbox = to_hi3660_mbox(chan);\n> +\tint err;\n> +\n> +\terr = hi3660_mbox_check_state(chan);\n> +\tif (err) {\n> +\t\tdev_err(mbox->dev, \"checking state failed\\n\");\n> +\t\treturn err;\n> +\t}\n> +\n> +\terr = hi3660_mbox_unlock(chan);\n> +\tif (err) {\n> +\t\tdev_err(mbox->dev, \"unlocking mailbox failed\\n\");\n> +\t\treturn err;\n> +\t}\n> +\n> +\terr = hi3660_mbox_acquire_channel(chan);\n> +\tif (err) {\n> +\t\tdev_err(mbox->dev, \"acquiring channel failed\\n\");\n> +\t\treturn err;\n> +\t}\n> +\n> +\treturn hi3660_mbox_send(chan, msg);\n> +}\n> +\n> +static struct mbox_chan_ops hi3660_mbox_ops = {\n> +\t.send_data = hi3660_mbox_send_data,\n> +};\n> +\n> +static struct mbox_chan *hi3660_mbox_xlate(struct mbox_controller *controller,\n> +\t\t\t\t\t const struct of_phandle_args *spec)\n> +{\n> +\tstruct hi3660_mbox *mbox = dev_get_drvdata(controller->dev);\n\nnit:\nIn to_hi3660_mbox, you use the fact that the mbox_controller structure \nis part of hi3660_mbox and use container of to retrieve hi3660_mbox.\n\nI think it would be nice to be consistent about this, either use \ncontainer_of or dev drvdata, but not both.\n\nCheers,","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yNgQW5YH0z9t2d\n\tfor ;\n\tFri, 27 Oct 2017 21:41:06 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752118AbdJ0KlF (ORCPT\n\t);\n\tFri, 27 Oct 2017 06:41:05 -0400","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:56544 \"EHLO\n\tfoss.arm.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751158AbdJ0KlE (ORCPT );\n\tFri, 27 Oct 2017 06:41:04 -0400","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D36FD15AD;\n\tFri, 27 Oct 2017 03:41:03 -0700 (PDT)","from [10.1.207.56] (e112298-lin.cambridge.arm.com [10.1.207.56])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t1CBE43F24A; Fri, 27 Oct 2017 03:41:00 -0700 (PDT)"],"Subject":"Re: [PATCH v2 2/3] mailbox: Add support for Hi3660 mailbox","To":"Kaihua Zhong , robh+dt@kernel.org,\n\tmark.rutland@arm.com, xuwei5@hisilicon.com,\n\tcatalin.marinas@arm.com, will.deacon@arm.com, jassisinghbrar@gmail.com","Cc":"xuezhiliang@hisilicon.com, devicetree@vger.kernel.org,\n\tguodong.xu@linaro.org, suzhuangluan@hisilicon.com,\n\tlinux-kernel@vger.kernel.org, haojian.zhuang@linaro.org,\n\tkevin.wangtao@hisilicon.com, linux-arm-kernel@lists.infradead.org","References":"<1509084904-2505-1-git-send-email-zhongkaihua@huawei.com>\n\t<1509084904-2505-3-git-send-email-zhongkaihua@huawei.com>","From":"Julien Thierry ","Message-ID":"<90d25374-cc83-7f75-eb38-766f0cdb9c53@arm.com>","Date":"Fri, 27 Oct 2017 11:40:59 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<1509084904-2505-3-git-send-email-zhongkaihua@huawei.com>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1794803,"web_url":"http://patchwork.ozlabs.org/comment/1794803/","msgid":"<20171027104559.em5n5ogro46ethmq@salmiak>","list_archive_url":null,"date":"2017-10-27T10:46:00","subject":"Re: [PATCH v2 2/3] mailbox: Add support for Hi3660 mailbox","submitter":{"id":8806,"url":"http://patchwork.ozlabs.org/api/people/8806/","name":"Mark Rutland","email":"mark.rutland@arm.com"},"content":"On Fri, Oct 27, 2017 at 02:15:03PM +0800, Kaihua Zhong wrote:\n> Hi3660 mailbox controller is used to send message within multiple\n> processors, MCU, HIFI, etc. It supports 32 mailbox channels and every\n> channel can only be used for single transferring direction. Once the\n> channel is enabled, it needs to specify the destination interrupt and\n> acknowledge interrupt, these two interrupt vectors are used to create\n> the connection between the mailbox and interrupt controllers.\n> \n> The application processor (or from point of view of kernel) is not the\n> only one master which can launch the data transferring, other\n> processors or MCU/DSP also can kick off the data transferring. So this\n> driver implements a locking mechanism to support exclusive accessing.\n\n... and that locking mechanism is what precisely?\n\nWhere is the protocol defined?\n\n> +static int hi3660_mbox_check_state(struct mbox_chan *chan)\n> +{\n> +\tunsigned long ch = (unsigned long)chan->con_priv;\n> +\tstruct hi3660_mbox *mbox = to_hi3660_mbox(chan);\n> +\tstruct hi3660_mbox_dev *mdev = &mbox->mdev[ch];\n> +\tvoid __iomem *base = MBOX_BASE(mbox, ch);\n> +\tunsigned long val;\n> +\tunsigned int state, ret;\n> +\n> +\t/* Mailbox is idle so directly bail out */\n> +\tstate = readl_relaxed(base + MBOX_MODE_REG);\n> +\tif (state & MBOX_STATE_IDLE)\n> +\t\treturn 0;\n> +\n> +\t/* Wait for acknowledge from remote */\n> +\tret = readx_poll_timeout_atomic(readl_relaxed, base + MBOX_MODE_REG,\n> +\t\t\tval, (val & MBOX_STATE_ACK), 1000, 300000);\n> +\tif (ret) {\n> +\t\tdev_err(mbox->dev, \"%s: timeout for receiving ack\\n\", __func__);\n> +\t\treturn ret;\n> +\t}\n> +\n> +\t/* Ensure channel is released */\n> +\twritel_relaxed(0xffffffff, base + MBOX_IMASK_REG);\n> +\twritel_relaxed(BIT(mdev->ack_irq), base + MBOX_SRC_REG);\n> +\t__asm__ volatile (\"sev\");\n> +\treturn 0;\n> +}\n\nDrivers really shouldn't be using SEV directly (even if via the sev() macro)...\n\nThis SEV isn't ordered w.r.t. anything, and it's unclear what ordering you\nneed, so this simply does not work.\n\n> +static int hi3660_mbox_acquire_channel(struct mbox_chan *chan)\n> +{\n> +\tunsigned long ch = (unsigned long)chan->con_priv;\n> +\tstruct hi3660_mbox *mbox = to_hi3660_mbox(chan);\n> +\tstruct hi3660_mbox_dev *mdev = &mbox->mdev[ch];\n> +\tvoid __iomem *base = MBOX_BASE(mbox, ch);\n> +\tunsigned int val = 0, retry = 10;\n> +\n> +\t/*\n> +\t * Hardware locking for exclusive accessing within CPUs\n> +\t * without exclusive monitor mechanism.\n> +\t */\n> +\tdo {\n> +\t\tval = readl_relaxed(base + MBOX_MODE_REG);\n> +\t\tif (!(val & MBOX_STATE_IDLE)) {\n> +\t\t\t__asm__ volatile (\"wfe\");\n\n... and likewise for WFE / wfe().\n\n> +\t\t\tcontinue;\n> +\t\t}\n> +\n> +\t\t/* Check if channel has be acquired */\n> +\t\twritel_relaxed(BIT(mdev->ack_irq), base + MBOX_SRC_REG);\n> +\t\tval = readl_relaxed(base + MBOX_SRC_REG) & BIT(mdev->ack_irq);\n> +\t\tif (val)\n> +\t\t\tbreak;\n> +\n> +\t} while (retry--);\n> +\n> +\treturn (val) ? 0 : -ETIMEDOUT;\n> +}\n\nPlease elaborate on how this synchronisation mechanism is expected to work, and\nwhy it is necessary in the first place.\n\nThanks,\nMark.\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yNjTP5ZDKz9t2h\n\tfor ;\n\tFri, 27 Oct 2017 23:13:45 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752537AbdJ0MNo (ORCPT\n\t);\n\tFri, 27 Oct 2017 08:13:44 -0400","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:58216 \"EHLO\n\tfoss.arm.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1752326AbdJ0MNn (ORCPT );\n\tFri, 27 Oct 2017 08:13:43 -0400","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 47A3280D;\n\tFri, 27 Oct 2017 05:13:43 -0700 (PDT)","from salmiak (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t5DC653F24A; Fri, 27 Oct 2017 05:13:40 -0700 (PDT)"],"Date":"Fri, 27 Oct 2017 11:46:00 +0100","From":"Mark Rutland ","To":"Kaihua Zhong ","Cc":"robh+dt@kernel.org, xuwei5@hisilicon.com, catalin.marinas@arm.com,\n\twill.deacon@arm.com, jassisinghbrar@gmail.com,\n\tdevicetree@vger.kernel.org, linux-kernel@vger.kernel.org,\n\tlinux-arm-kernel@lists.infradead.org, guodong.xu@linaro.org,\n\thaojian.zhuang@linaro.org, suzhuangluan@hisilicon.com,\n\txuezhiliang@hisilicon.com, kevin.wangtao@hisilicon.com","Subject":"Re: [PATCH v2 2/3] mailbox: Add support for Hi3660 mailbox","Message-ID":"<20171027104559.em5n5ogro46ethmq@salmiak>","References":"<1509084904-2505-1-git-send-email-zhongkaihua@huawei.com>\n\t<1509084904-2505-3-git-send-email-zhongkaihua@huawei.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<1509084904-2505-3-git-send-email-zhongkaihua@huawei.com>","User-Agent":"NeoMutt/20170113 (1.7.2)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1795630,"web_url":"http://patchwork.ozlabs.org/comment/1795630/","msgid":"<20171030044506.GE31478@leoy-ThinkPad-T440>","list_archive_url":null,"date":"2017-10-30T04:45:06","subject":"Re: [PATCH v2 2/3] mailbox: Add support for Hi3660 mailbox","submitter":{"id":66057,"url":"http://patchwork.ozlabs.org/api/people/66057/","name":"Leo Yan","email":"leo.yan@linaro.org"},"content":"Hi Mark,\n\nOn Fri, Oct 27, 2017 at 11:46:00AM +0100, Mark Rutland wrote:\n> On Fri, Oct 27, 2017 at 02:15:03PM +0800, Kaihua Zhong wrote:\n> > Hi3660 mailbox controller is used to send message within multiple\n> > processors, MCU, HIFI, etc. It supports 32 mailbox channels and every\n> > channel can only be used for single transferring direction. Once the\n> > channel is enabled, it needs to specify the destination interrupt and\n> > acknowledge interrupt, these two interrupt vectors are used to create\n> > the connection between the mailbox and interrupt controllers.\n> > \n> > The application processor (or from point of view of kernel) is not the\n> > only one master which can launch the data transferring, other\n> > processors or MCU/DSP also can kick off the data transferring. So this\n> > driver implements a locking mechanism to support exclusive accessing.\n> \n> ... and that locking mechanism is what precisely?\n> \n> Where is the protocol defined?\n> \n> > +static int hi3660_mbox_check_state(struct mbox_chan *chan)\n> > +{\n> > +\tunsigned long ch = (unsigned long)chan->con_priv;\n> > +\tstruct hi3660_mbox *mbox = to_hi3660_mbox(chan);\n> > +\tstruct hi3660_mbox_dev *mdev = &mbox->mdev[ch];\n> > +\tvoid __iomem *base = MBOX_BASE(mbox, ch);\n> > +\tunsigned long val;\n> > +\tunsigned int state, ret;\n> > +\n> > +\t/* Mailbox is idle so directly bail out */\n> > +\tstate = readl_relaxed(base + MBOX_MODE_REG);\n> > +\tif (state & MBOX_STATE_IDLE)\n> > +\t\treturn 0;\n> > +\n> > +\t/* Wait for acknowledge from remote */\n> > +\tret = readx_poll_timeout_atomic(readl_relaxed, base + MBOX_MODE_REG,\n> > +\t\t\tval, (val & MBOX_STATE_ACK), 1000, 300000);\n> > +\tif (ret) {\n> > +\t\tdev_err(mbox->dev, \"%s: timeout for receiving ack\\n\", __func__);\n> > +\t\treturn ret;\n> > +\t}\n> > +\n> > +\t/* Ensure channel is released */\n> > +\twritel_relaxed(0xffffffff, base + MBOX_IMASK_REG);\n> > +\twritel_relaxed(BIT(mdev->ack_irq), base + MBOX_SRC_REG);\n> > +\t__asm__ volatile (\"sev\");\n> > +\treturn 0;\n> > +}\n> \n> Drivers really shouldn't be using SEV directly (even if via the sev() macro)...\n> \n> This SEV isn't ordered w.r.t. anything, and it's unclear what ordering you\n> need, so this simply does not work.\n\nI will leave your questions for Hisilicon colleagues, essentially\nyour questions are related with mailbox mechanism.\n\nBut I'd like to firstly get clear your question for \"This SEV isn't\nordered w.r.t. anything\". From my understanding, ARMv8 architecture\nnatually adds DMB before SEV so all previous register writing\nopreations should be ensured to endpoint before SEV?\n\n[...]\n\nThanks,\nLeo Yan\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=linaro.org header.i=@linaro.org\n\theader.b=\"UYR4O14x\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yQMNg3rg7z9t3Z\n\tfor ;\n\tMon, 30 Oct 2017 15:45:23 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751557AbdJ3EpV (ORCPT\n\t);\n\tMon, 30 Oct 2017 00:45:21 -0400","from mail-wm0-f65.google.com ([74.125.82.65]:49592 \"EHLO\n\tmail-wm0-f65.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751302AbdJ3EpU (ORCPT\n\t); Mon, 30 Oct 2017 00:45:20 -0400","by mail-wm0-f65.google.com with SMTP id b189so13117656wmd.4\n\tfor ;\n\tSun, 29 Oct 2017 21:45:20 -0700 (PDT)","from leoy-ThinkPad-T440 (li1530-42.members.linode.com.\n\t[139.162.245.42]) by smtp.gmail.com with ESMTPSA id\n\th66sm3637174wmd.11.2017.10.29.21.45.13\n\t(version=TLS1_2 cipher=AES128-SHA bits=128/128);\n\tSun, 29 Oct 2017 21:45:18 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=9es4clMr1pSx9mQQITN7FhPRpPc/QAjvuokKWitan80=;\n\tb=UYR4O14x+zwj2OkzrFDq4xfJ/KkOVtTFcfrXEA3WMI7LNQSp+xupzz+IgVfL+AlaXF\n\tpcgWbARqllDrLa/wy3tP3y3D6yVDwWFXg2eoybPogUVu30LyHGUiMrksu4Rau9DsWxB4\n\tThAFQdSkBDnxvwF9h+sUzCbpBOWL8H1g5Q0No=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=9es4clMr1pSx9mQQITN7FhPRpPc/QAjvuokKWitan80=;\n\tb=VdFgmvAT3In3ntN8j9eDR3Xa7NpOcQmJ2difI6v4Wt/hVBOif/z1z4/7WhLZppBTFy\n\tRwVlAbl3x75e4BUSLUimEQiTytaZCYND/xx+Y8hvNt7n81YOq6fsmEZbFhABjCxjcYwZ\n\tLs1mSSfR9HXMKnxvMk1W6k6h3My+eqwjznTHXKbpM9wboAorKVOmWdnGPoKT1E7Gmrlb\n\t+MDmz13b6YdgtLrxWvV/GnbZ9+uihzhkHjnxZrtD3olnUzzSbNzbIFDT/nAN8w+oH4Gy\n\tzuyHx2LN3AlbxC8QcQYA80jTWQJoEb16qur/PwR+LLC0iyP0tQ3qC9w2iM9uw5GYHAt+\n\tqiTw==","X-Gm-Message-State":"AMCzsaVO+dK+URqzXhMggSlMRp1o5ZpJDsvbDwuUq7hWqonR8vc638Xv\n\tbwfDUPsb3tMWDsNqe5sRnV9+qw==","X-Google-Smtp-Source":"ABhQp+QHQilRitIAkF77kN3qDMOzdBYK7N4LnC2OPO9QD+AmMMQ4QHScuG8ZT2ZsCmHYYRa0tkiDLg==","X-Received":"by 10.28.64.198 with SMTP id n189mr2347846wma.0.1509338719699;\n\tSun, 29 Oct 2017 21:45:19 -0700 (PDT)","Date":"Mon, 30 Oct 2017 12:45:06 +0800","From":"Leo Yan ","To":"Mark Rutland ","Cc":"Kaihua Zhong , robh+dt@kernel.org,\n\txuwei5@hisilicon.com, catalin.marinas@arm.com, will.deacon@arm.com,\n\tjassisinghbrar@gmail.com, devicetree@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tguodong.xu@linaro.org, haojian.zhuang@linaro.org,\n\tsuzhuangluan@hisilicon.com, xuezhiliang@hisilicon.com,\n\tkevin.wangtao@hisilicon.com","Subject":"Re: [PATCH v2 2/3] mailbox: Add support for Hi3660 mailbox","Message-ID":"<20171030044506.GE31478@leoy-ThinkPad-T440>","References":"<1509084904-2505-1-git-send-email-zhongkaihua@huawei.com>\n\t<1509084904-2505-3-git-send-email-zhongkaihua@huawei.com>\n\t<20171027104559.em5n5ogro46ethmq@salmiak>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20171027104559.em5n5ogro46ethmq@salmiak>","User-Agent":"Mutt/1.5.21 (2010-09-15)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1795804,"web_url":"http://patchwork.ozlabs.org/comment/1795804/","msgid":"<20171030101940.dtf6rw7alhkn6irf@lakrids.cambridge.arm.com>","list_archive_url":null,"date":"2017-10-30T10:19:40","subject":"Re: [PATCH v2 2/3] mailbox: Add support for Hi3660 mailbox","submitter":{"id":8806,"url":"http://patchwork.ozlabs.org/api/people/8806/","name":"Mark Rutland","email":"mark.rutland@arm.com"},"content":"Hi,\n\nOn Mon, Oct 30, 2017 at 12:45:06PM +0800, Leo Yan wrote:\n> On Fri, Oct 27, 2017 at 11:46:00AM +0100, Mark Rutland wrote:\n> > On Fri, Oct 27, 2017 at 02:15:03PM +0800, Kaihua Zhong wrote:\n> > > +static int hi3660_mbox_check_state(struct mbox_chan *chan)\n> > > +{\n\n> > > +\t/* Ensure channel is released */\n> > > +\twritel_relaxed(0xffffffff, base + MBOX_IMASK_REG);\n> > > +\twritel_relaxed(BIT(mdev->ack_irq), base + MBOX_SRC_REG);\n> > > +\t__asm__ volatile (\"sev\");\n> > > +\treturn 0;\n> > > +}\n> > \n> > Drivers really shouldn't be using SEV directly (even if via the\n> > sev() macro)...\n> > \n> > This SEV isn't ordered w.r.t. anything, and it's unclear what\n> > ordering you need, so this simply does not work.\n> \n> I will leave your questions for Hisilicon colleagues, essentially your\n> questions are related with mailbox mechanism.\n> \n> But I'd like to firstly get clear your question for \"This SEV isn't\n> ordered w.r.t. anything\". From my understanding, ARMv8 architecture\n> natually adds DMB before SEV so all previous register writing\n> opreations should be ensured to endpoint before SEV?\n\nThis is not the case; SEV does not add any implicit memory barrier, and\nis not ordered w.r.t. memory accesses.\n\nSee ARM DDI 0487B.b, page D1-1905, \"The Send Event instructions\":\n\n The PE is not required to guarantee the ordering of this event with\n respect to the completion of memory accesses by instructions before\n the SEV instruction. Therefore, ARM recommends that software\n includes a DSB instruction before any SEV instruction.\n\nNote that a DMB is not sufficient, as SEV is not a memory access.\n\nThanks,\nMark.\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yQVpb0P1vz9t3s\n\tfor ;\n\tMon, 30 Oct 2017 21:19:51 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S932594AbdJ3KTt (ORCPT );\n\tMon, 30 Oct 2017 06:19:49 -0400","from foss.arm.com ([217.140.101.70]:50330 \"EHLO foss.arm.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S932575AbdJ3KTs (ORCPT );\n\tMon, 30 Oct 2017 06:19:48 -0400","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 613921596;\n\tMon, 30 Oct 2017 03:19:48 -0700 (PDT)","from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com\n\t[10.72.51.249])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\tD70383F483; Mon, 30 Oct 2017 03:19:45 -0700 (PDT)"],"Date":"Mon, 30 Oct 2017 10:19:40 +0000","From":"Mark Rutland ","To":"Leo Yan ","Cc":"Kaihua Zhong , robh+dt@kernel.org,\n\txuwei5@hisilicon.com, catalin.marinas@arm.com, will.deacon@arm.com,\n\tjassisinghbrar@gmail.com, devicetree@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tguodong.xu@linaro.org, haojian.zhuang@linaro.org,\n\tsuzhuangluan@hisilicon.com, xuezhiliang@hisilicon.com,\n\tkevin.wangtao@hisilicon.com","Subject":"Re: [PATCH v2 2/3] mailbox: Add support for Hi3660 mailbox","Message-ID":"<20171030101940.dtf6rw7alhkn6irf@lakrids.cambridge.arm.com>","References":"<1509084904-2505-1-git-send-email-zhongkaihua@huawei.com>\n\t<1509084904-2505-3-git-send-email-zhongkaihua@huawei.com>\n\t<20171027104559.em5n5ogro46ethmq@salmiak>\n\t<20171030044506.GE31478@leoy-ThinkPad-T440>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20171030044506.GE31478@leoy-ThinkPad-T440>","User-Agent":"NeoMutt/20170113 (1.7.2)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1795837,"web_url":"http://patchwork.ozlabs.org/comment/1795837/","msgid":"<20171030111313.GF31478@leoy-ThinkPad-T440>","list_archive_url":null,"date":"2017-10-30T11:13:13","subject":"Re: [PATCH v2 2/3] mailbox: Add support for Hi3660 mailbox","submitter":{"id":66057,"url":"http://patchwork.ozlabs.org/api/people/66057/","name":"Leo Yan","email":"leo.yan@linaro.org"},"content":"Hi Mark,\n\nOn Mon, Oct 30, 2017 at 10:19:40AM +0000, Mark Rutland wrote:\n> Hi,\n> \n> On Mon, Oct 30, 2017 at 12:45:06PM +0800, Leo Yan wrote:\n> > On Fri, Oct 27, 2017 at 11:46:00AM +0100, Mark Rutland wrote:\n> > > On Fri, Oct 27, 2017 at 02:15:03PM +0800, Kaihua Zhong wrote:\n> > > > +static int hi3660_mbox_check_state(struct mbox_chan *chan)\n> > > > +{\n> \n> > > > +\t/* Ensure channel is released */\n> > > > +\twritel_relaxed(0xffffffff, base + MBOX_IMASK_REG);\n> > > > +\twritel_relaxed(BIT(mdev->ack_irq), base + MBOX_SRC_REG);\n> > > > +\t__asm__ volatile (\"sev\");\n> > > > +\treturn 0;\n> > > > +}\n> > > \n> > > Drivers really shouldn't be using SEV directly (even if via the\n> > > sev() macro)...\n> > > \n> > > This SEV isn't ordered w.r.t. anything, and it's unclear what\n> > > ordering you need, so this simply does not work.\n> > \n> > I will leave your questions for Hisilicon colleagues, essentially your\n> > questions are related with mailbox mechanism.\n> > \n> > But I'd like to firstly get clear your question for \"This SEV isn't\n> > ordered w.r.t. anything\". From my understanding, ARMv8 architecture\n> > natually adds DMB before SEV so all previous register writing\n> > opreations should be ensured to endpoint before SEV?\n> \n> This is not the case; SEV does not add any implicit memory barrier, and\n> is not ordered w.r.t. memory accesses.\n> \n> See ARM DDI 0487B.b, page D1-1905, \"The Send Event instructions\":\n> \n> The PE is not required to guarantee the ordering of this event with\n> respect to the completion of memory accesses by instructions before\n> the SEV instruction. Therefore, ARM recommends that software\n> includes a DSB instruction before any SEV instruction.\n\nMy fault and thanks for explanation.\n\n> Note that a DMB is not sufficient, as SEV is not a memory access.\n\nUnderstood now, so below code should be safe?\n\nwmb(); -> dsb(st);\nsev();\n\nThanks,\nLeo Yan\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=linaro.org header.i=@linaro.org\n\theader.b=\"WS+TuVK3\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yQX0l0YL4z9t3R\n\tfor ;\n\tMon, 30 Oct 2017 22:13:41 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752045AbdJ3LN2 (ORCPT\n\t);\n\tMon, 30 Oct 2017 07:13:28 -0400","from mail-wm0-f66.google.com ([74.125.82.66]:51143 \"EHLO\n\tmail-wm0-f66.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752013AbdJ3LN1 (ORCPT\n\t); Mon, 30 Oct 2017 07:13:27 -0400","by mail-wm0-f66.google.com with SMTP id s66so14973408wmf.5\n\tfor ;\n\tMon, 30 Oct 2017 04:13:27 -0700 (PDT)","from leoy-ThinkPad-T440 (li1530-42.members.linode.com.\n\t[139.162.245.42]) by smtp.gmail.com with ESMTPSA id\n\tf132sm3349196wmf.38.2017.10.30.04.13.20\n\t(version=TLS1_2 cipher=AES128-SHA bits=128/128);\n\tMon, 30 Oct 2017 04:13:24 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=ZsYkx3yMOjbMcSi10bBcynX8Y2Ofn+deAtAiLk6U+0c=;\n\tb=WS+TuVK35DHjUwde2yj+hNPsfxcSmhBiINai5xxwcTlH1s+KtvP9B0ndIdzOXkxyRI\n\tESH8P5aIZC+RuT2Bz+4REnYwYrNThReRNMg1jyPDLMUOugl50CLL61rvAPTyKw5n8iVI\n\t240XDuufFQ0I1WkGxGQDXDc4VA/XFiBpILX4I=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=ZsYkx3yMOjbMcSi10bBcynX8Y2Ofn+deAtAiLk6U+0c=;\n\tb=i14aP7rM1AWQppxWi5hhjDaZRMyRVzS1OTiS/Ch+V4SSJggmR8h9D66M76jkRUpwKx\n\tU4x8T4nahNpQKZg7dzrRZXv0LLAIfy3+4zkQIp38SCW/BF3cHWimj0ipg4kgYy+ZhdAc\n\tDklNB2DK2J/GopFuwMye4050h6U4qlXoBh2tFTwD8yrbGqgj3oEjZgSV71H6IRVINs59\n\tSIfxYIROZSuFr/PYA/PY982ylcymRzyQLD+C/5BmMLWVaW9QLb+4KYsU9zen9FQKcVll\n\tLwMw7SVyP7AjAC3FCE1DK4mXKAPj2jue8PqE9v+IAp+IcIWKM2XJ9muux+bE55fGJHWT\n\tnVog==","X-Gm-Message-State":"AMCzsaWRkOzu2Z8nogrH07s4z+bd4D7uBOixjfGrOCX5LqaTLl12WzyK\n\tN79g4I9remOkQ5856L+VTjKgtg==","X-Google-Smtp-Source":"ABhQp+TGezso5M/sD90tiaQIPD/ycacv1SDxoJTLIuQKkC/ePGHZLG7JEc6hn884mn7G4rj0ciLaBw==","X-Received":"by 10.28.169.21 with SMTP id s21mr3190377wme.87.1509362006407;\n\tMon, 30 Oct 2017 04:13:26 -0700 (PDT)","Date":"Mon, 30 Oct 2017 19:13:13 +0800","From":"Leo Yan ","To":"Mark Rutland ","Cc":"Kaihua Zhong , robh+dt@kernel.org,\n\txuwei5@hisilicon.com, catalin.marinas@arm.com, will.deacon@arm.com,\n\tjassisinghbrar@gmail.com, devicetree@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tguodong.xu@linaro.org, haojian.zhuang@linaro.org,\n\tsuzhuangluan@hisilicon.com, xuezhiliang@hisilicon.com,\n\tkevin.wangtao@hisilicon.com","Subject":"Re: [PATCH v2 2/3] mailbox: Add support for Hi3660 mailbox","Message-ID":"<20171030111313.GF31478@leoy-ThinkPad-T440>","References":"<1509084904-2505-1-git-send-email-zhongkaihua@huawei.com>\n\t<1509084904-2505-3-git-send-email-zhongkaihua@huawei.com>\n\t<20171027104559.em5n5ogro46ethmq@salmiak>\n\t<20171030044506.GE31478@leoy-ThinkPad-T440>\n\t<20171030101940.dtf6rw7alhkn6irf@lakrids.cambridge.arm.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20171030101940.dtf6rw7alhkn6irf@lakrids.cambridge.arm.com>","User-Agent":"Mutt/1.5.21 (2010-09-15)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1795850,"web_url":"http://patchwork.ozlabs.org/comment/1795850/","msgid":"<20171030113732.dajsdj3lcm2qjxke@lakrids.cambridge.arm.com>","list_archive_url":null,"date":"2017-10-30T11:37:32","subject":"Re: [PATCH v2 2/3] mailbox: Add support for Hi3660 mailbox","submitter":{"id":8806,"url":"http://patchwork.ozlabs.org/api/people/8806/","name":"Mark Rutland","email":"mark.rutland@arm.com"},"content":"On Mon, Oct 30, 2017 at 07:13:13PM +0800, Leo Yan wrote:\n> Hi Mark,\n> \n> On Mon, Oct 30, 2017 at 10:19:40AM +0000, Mark Rutland wrote:\n> > Hi,\n> > \n> > On Mon, Oct 30, 2017 at 12:45:06PM +0800, Leo Yan wrote:\n> > > On Fri, Oct 27, 2017 at 11:46:00AM +0100, Mark Rutland wrote:\n> > > > On Fri, Oct 27, 2017 at 02:15:03PM +0800, Kaihua Zhong wrote:\n> > > > > +static int hi3660_mbox_check_state(struct mbox_chan *chan)\n> > > > > +{\n> > \n> > > > > +\t/* Ensure channel is released */\n> > > > > +\twritel_relaxed(0xffffffff, base + MBOX_IMASK_REG);\n> > > > > +\twritel_relaxed(BIT(mdev->ack_irq), base + MBOX_SRC_REG);\n> > > > > +\t__asm__ volatile (\"sev\");\n> > > > > +\treturn 0;\n> > > > > +}\n> > > > \n> > > > Drivers really shouldn't be using SEV directly (even if via the\n> > > > sev() macro)...\n> > > > \n> > > > This SEV isn't ordered w.r.t. anything, and it's unclear what\n> > > > ordering you need, so this simply does not work.\n> > > \n> > > I will leave your questions for Hisilicon colleagues, essentially your\n> > > questions are related with mailbox mechanism.\n> > > \n> > > But I'd like to firstly get clear your question for \"This SEV isn't\n> > > ordered w.r.t. anything\". From my understanding, ARMv8 architecture\n> > > natually adds DMB before SEV so all previous register writing\n> > > opreations should be ensured to endpoint before SEV?\n> > \n> > This is not the case; SEV does not add any implicit memory barrier, and\n> > is not ordered w.r.t. memory accesses.\n> > \n> > See ARM DDI 0487B.b, page D1-1905, \"The Send Event instructions\":\n> > \n> > The PE is not required to guarantee the ordering of this event with\n> > respect to the completion of memory accesses by instructions before\n> > the SEV instruction. Therefore, ARM recommends that software\n> > includes a DSB instruction before any SEV instruction.\n> \n> My fault and thanks for explanation.\n> \n> > Note that a DMB is not sufficient, as SEV is not a memory access.\n> \n> Understood now, so below code should be safe?\n> \n> wmb(); -> dsb(st);\n> sev();\n\nWhether that is safe depends on what you are trying to ensure is\nordered, and what the other side (with the WFE) is doing.\n\nFor example, my understanding is that in general, WFE is also not\nordered w.r.t. memory accesses.\n\nThis is a very subtle part of the architecture, and I'm very much not\nkeen on using WFE and SEV outside of architecture code implementing\nlocking primitives.\n\nThanks,\nMark.\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yQXXl0TgQz9sRm\n\tfor ;\n\tMon, 30 Oct 2017 22:37:59 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753164AbdJ3Lhk (ORCPT\n\t);\n\tMon, 30 Oct 2017 07:37:40 -0400","from foss.arm.com ([217.140.101.70]:51048 \"EHLO foss.arm.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1752821AbdJ3Lhi (ORCPT );\n\tMon, 30 Oct 2017 07:37:38 -0400","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C8DDE1529;\n\tMon, 30 Oct 2017 04:37:37 -0700 (PDT)","from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com\n\t[10.72.51.249])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t1DF1B3F483; Mon, 30 Oct 2017 04:37:34 -0700 (PDT)"],"Date":"Mon, 30 Oct 2017 11:37:32 +0000","From":"Mark Rutland ","To":"Leo Yan ","Cc":"Kaihua Zhong , robh+dt@kernel.org,\n\txuwei5@hisilicon.com, catalin.marinas@arm.com, will.deacon@arm.com,\n\tjassisinghbrar@gmail.com, devicetree@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tguodong.xu@linaro.org, haojian.zhuang@linaro.org,\n\tsuzhuangluan@hisilicon.com, xuezhiliang@hisilicon.com,\n\tkevin.wangtao@hisilicon.com","Subject":"Re: [PATCH v2 2/3] mailbox: Add support for Hi3660 mailbox","Message-ID":"<20171030113732.dajsdj3lcm2qjxke@lakrids.cambridge.arm.com>","References":"<1509084904-2505-1-git-send-email-zhongkaihua@huawei.com>\n\t<1509084904-2505-3-git-send-email-zhongkaihua@huawei.com>\n\t<20171027104559.em5n5ogro46ethmq@salmiak>\n\t<20171030044506.GE31478@leoy-ThinkPad-T440>\n\t<20171030101940.dtf6rw7alhkn6irf@lakrids.cambridge.arm.com>\n\t<20171030111313.GF31478@leoy-ThinkPad-T440>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20171030111313.GF31478@leoy-ThinkPad-T440>","User-Agent":"NeoMutt/20170113 (1.7.2)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1797752,"web_url":"http://patchwork.ozlabs.org/comment/1797752/","msgid":"<59FAE221.3080600@huawei.com>","list_archive_url":null,"date":"2017-11-02T09:15:13","subject":"Re: [PATCH v2 2/3] mailbox: Add support for Hi3660 mailbox","submitter":{"id":67537,"url":"http://patchwork.ozlabs.org/api/people/67537/","name":"Kaihua Zhong","email":"zhongkaihua@huawei.com"},"content":"Hi, Julien,\n\nOn 2017/10/27 18:40, Julien Thierry wrote:\n> Hi Kaihua,\n> \n> On 27/10/17 07:15, Kaihua Zhong wrote:\n>> Hi3660 mailbox controller is used to send message within multiple\n>> processors, MCU, HIFI, etc. It supports 32 mailbox channels and every\n>> channel can only be used for single transferring direction. Once the\n>> channel is enabled, it needs to specify the destination interrupt and\n>> acknowledge interrupt, these two interrupt vectors are used to create\n>> the connection between the mailbox and interrupt controllers.\n>>\n>> The application processor (or from point of view of kernel) is not the\n>> only one master which can launch the data transferring, other\n>> processors or MCU/DSP also can kick off the data transferring. So this\n>> driver implements a locking mechanism to support exclusive accessing.\n>>\n>> The data transferring supports two modes, one is named as \"automatic\n>> acknowledge\" mode so after send message the kernel doesn't need to wait\n>> for acknowledge from remote and directly return; there have another mode\n>> is to rely on handling interrupt for acknowledge.\n>>\n>> This commit is for initial version driver, which only supports\n>> \"automatic acknowledge\" mode to support CPU clock, which is the only\n>> one consumer to use mailbox and has been verified. Later may enhance\n>> this driver for interrupt mode (e.g. for supporting HIFI).\n>>\n>> Cc: John Stultz \n>> Cc: Guodong Xu \n>> Cc: Haojian Zhuang \n>> Cc: Niranjan Yadla \n>> Cc: Raj Pawate \n>> Signed-off-by: Leo Yan \n>> Signed-off-by: Ruyi Wang \n>> Signed-off-by: Kaihua Zhong \n>> Signed-off-by: Kevin Wang \n>> ---\n>> drivers/mailbox/Kconfig | 8 +\n>> drivers/mailbox/Makefile | 2 +\n>> drivers/mailbox/hi3660-mailbox.c | 331 +++++++++++++++++++++++++++++++++++++++\n>> 3 files changed, 341 insertions(+)\n>> create mode 100644 drivers/mailbox/hi3660-mailbox.c\n>>\n>> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig\n>> index c5731e5..4b5d6e9 100644\n>> --- a/drivers/mailbox/Kconfig\n>> +++ b/drivers/mailbox/Kconfig\n>> @@ -108,6 +108,14 @@ config TI_MESSAGE_MANAGER\n>> multiple processors within the SoC. Select this driver if your\n>> platform has support for the hardware block.\n>> +config HI3660_MBOX\n>> + tristate \"Hi3660 Mailbox\"\n>> + depends on ARCH_HISI && OF\n>> + help\n>> + An implementation of the hi3660 mailbox. It is used to send message\n>> + between application processors and other processors/MCU/DSP. Select\n>> + Y here if you want to use Hi3660 mailbox controller.\n>> +\n>> config HI6220_MBOX\n>> tristate \"Hi6220 Mailbox\"\n>> depends on ARCH_HISI\n>> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile\n>> index d54e412..7d1bd51 100644\n>> --- a/drivers/mailbox/Makefile\n>> +++ b/drivers/mailbox/Makefile\n>> @@ -26,6 +26,8 @@ obj-$(CONFIG_TI_MESSAGE_MANAGER) += ti-msgmgr.o\n>> obj-$(CONFIG_XGENE_SLIMPRO_MBOX) += mailbox-xgene-slimpro.o\n>> +obj-$(CONFIG_HI3660_MBOX) += hi3660-mailbox.o\n>> +\n>> obj-$(CONFIG_HI6220_MBOX) += hi6220-mailbox.o\n>> obj-$(CONFIG_BCM_PDC_MBOX) += bcm-pdc-mailbox.o\n>> diff --git a/drivers/mailbox/hi3660-mailbox.c b/drivers/mailbox/hi3660-mailbox.c\n>> new file mode 100644\n>> index 0000000..67df8f8\n>> --- /dev/null\n>> +++ b/drivers/mailbox/hi3660-mailbox.c\n>> @@ -0,0 +1,331 @@\n>> +/*\n>> + * Hisilicon's Hi3660 mailbox controller driver\n>> + *\n>> + * Copyright (c) 2017 Hisilicon Limited.\n>> + * Copyright (c) 2017 Linaro Limited.\n>> + *\n>> + * Author: Leo Yan \n>> + *\n>> + * This program is free software: you can redistribute it and/or modify\n>> + * it under the terms of the GNU General Public License as published by\n>> + * the Free Software Foundation, version 2 of the License.\n>> + *\n>> + * This program is distributed in the hope that it will be useful,\n>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of\n>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\n>> + * GNU General Public License for more details.\n>> + *\n>> + */\n>> +\n>> +#include \n>> +#include \n>> +#include \n>> +#include \n>> +#include \n>> +#include \n>> +#include \n>> +#include \n>> +#include \n>> +#include \n>> +#include \n>> +\n>> +#include \"mailbox.h\"\n>> +\n>> +#define MBOX_CHAN_MAX 32\n>> +\n>> +#define MBOX_RX (0x0)\n>> +#define MBOX_TX (0x1)\n>> +\n>> +#define MBOX_BASE(mbox, ch) ((mbox)->base + ((ch) * 0x40))\n>> +#define MBOX_SRC_REG (0x00)\n>> +#define MBOX_DST_REG (0x04)\n>> +#define MBOX_DCLR_REG (0x08)\n>> +#define MBOX_DSTAT_REG (0x0c)\n>> +#define MBOX_MODE_REG (0x10)\n>> +#define MBOX_IMASK_REG (0x14)\n>> +#define MBOX_ICLR_REG (0x18)\n>> +#define MBOX_SEND_REG (0x1c)\n>> +#define MBOX_DATA_REG (0x20)\n>> +\n>> +#define MBOX_IPC_LOCK_REG (0xa00)\n>> +#define MBOX_IPC_UNLOCK (0x1acce551)\n>> +\n>> +#define MBOX_AUTOMATIC_ACK (1)\n>> +\n>> +#define MBOX_STATE_IDLE BIT(4)\n>> +#define MBOX_STATE_ACK BIT(7)\n>> +\n>> +#define MBOX_MSG_LEN 8\n>> +\n>> +/**\n>> + * Hi3660 mailbox channel device data\n>> + *\n>> + * A channel can be used for TX or RX, it can trigger remote\n>> + * processor interrupt to notify remote processor and can receive\n>> + * interrupt if has incoming message.\n>> + *\n>> + * @dst_irq: Interrupt vector for remote processor\n>> + * @ack_irq: Interrupt vector for local processor\n>> + */\n>> +struct hi3660_mbox_dev {\n>> + unsigned int dst_irq;\n>> + unsigned int ack_irq;\n>> +};\n>> +\n>> +/**\n>> + * Hi3660 mailbox controller data\n>> + *\n>> + * Mailbox controller includes 32 channels and can allocate\n>> + * channel for message transferring.\n>> + *\n>> + * @dev: Device to which it is attached\n>> + * @base: Base address of the register mapping region\n>> + * @chan: Representation of channels in mailbox controller\n>> + * @mdev: Representation of channel device data\n>> + * @controller: Representation of a communication channel controller\n>> + */\n>> +struct hi3660_mbox {\n>> + struct device *dev;\n>> + void __iomem *base;\n>> + struct mbox_chan chan[MBOX_CHAN_MAX];\n>> + struct hi3660_mbox_dev mdev[MBOX_CHAN_MAX];\n>> + struct mbox_controller controller;\n>> +};\n>> +\n>> +static inline struct hi3660_mbox *to_hi3660_mbox(struct mbox_chan *chan)\n>> +{\n>> + return container_of(chan->mbox, struct hi3660_mbox, controller);\n>> +}\n>> +\n>> +static int hi3660_mbox_check_state(struct mbox_chan *chan)\n>> +{\n>> + unsigned long ch = (unsigned long)chan->con_priv;\n>> + struct hi3660_mbox *mbox = to_hi3660_mbox(chan);\n>> + struct hi3660_mbox_dev *mdev = &mbox->mdev[ch];\n>> + void __iomem *base = MBOX_BASE(mbox, ch);\n>> + unsigned long val;\n>> + unsigned int state, ret;\n>> +\n>> + /* Mailbox is idle so directly bail out */\n>> + state = readl_relaxed(base + MBOX_MODE_REG);\n>> + if (state & MBOX_STATE_IDLE)\n>> + return 0;\n>> +\n>> + /* Wait for acknowledge from remote */\n>> + ret = readx_poll_timeout_atomic(readl_relaxed, base + MBOX_MODE_REG,\n>> + val, (val & MBOX_STATE_ACK), 1000, 300000);\n>> + if (ret) {\n>> + dev_err(mbox->dev, \"%s: timeout for receiving ack\\n\", __func__);\n>> + return ret;\n>> + }\n>> +\n>> + /* Ensure channel is released */\n>> + writel_relaxed(0xffffffff, base + MBOX_IMASK_REG);\n>> + writel_relaxed(BIT(mdev->ack_irq), base + MBOX_SRC_REG);\n>> + __asm__ volatile (\"sev\");\n> \n> There is an existing sev() macro for this.\n> \nMacro will be used in next patch，if this function is not redesigned.\nMark and Leo is discussing memory barrier protection issues.\n\n>> + return 0;\n>> +}\n>> +\n>> +static int hi3660_mbox_unlock(struct mbox_chan *chan)\n>> +{\n>> + struct hi3660_mbox *mbox = to_hi3660_mbox(chan);\n>> + unsigned int val, retry = 3;\n>> +\n>> + do {\n>> + writel_relaxed(MBOX_IPC_UNLOCK, mbox->base + MBOX_IPC_LOCK_REG);\n>> +\n>> + val = readl_relaxed(mbox->base + MBOX_IPC_LOCK_REG);\n>> + if (!val)\n>> + break;\n>> +\n>> + udelay(10);\n>> + } while (retry--);\n>> +\n>> + return (!val) ? 0 : -ETIMEDOUT;\n>> +}\n>> +\n>> +static int hi3660_mbox_acquire_channel(struct mbox_chan *chan)\n>> +{\n>> + unsigned long ch = (unsigned long)chan->con_priv;\n>> + struct hi3660_mbox *mbox = to_hi3660_mbox(chan);\n>> + struct hi3660_mbox_dev *mdev = &mbox->mdev[ch];\n>> + void __iomem *base = MBOX_BASE(mbox, ch);\n>> + unsigned int val = 0, retry = 10;\n>> +\n>> + /*\n>> + * Hardware locking for exclusive accessing within CPUs\n>> + * without exclusive monitor mechanism.\n>> + */\n>> + do {\n>> + val = readl_relaxed(base + MBOX_MODE_REG);\n>> + if (!(val & MBOX_STATE_IDLE)) {\n>> + __asm__ volatile (\"wfe\");\n>> + continue;\n> \n> So this is going to \"wfe\" when retry == 0 and the continue statement will take us out of the loop?\n> \n> Also, there is a wfe() macro for arm and arm64 which could be used here.\n> \n>> + }\n>> +\n>> + /* Check if channel has be acquired */\n>> + writel_relaxed(BIT(mdev->ack_irq), base + MBOX_SRC_REG);\n>> + val = readl_relaxed(base + MBOX_SRC_REG) & BIT(mdev->ack_irq);\n>> + if (val)\n>> + break;\n>> +\n>> + } while (retry--);\n>> +\n>> + return (val) ? 0 : -ETIMEDOUT;\n> \n> If timeout occurs while waiting for the MBOX to be idle, val will hold the last value from MBOX_MODE_REG, and if this can be different than 0, this will hide the fact it timed out.\n> \n> Maybe the following would be more appropriate:\n> \n> return (retry >= 0) ? 0 : -ETIMEDOUT;\n> \n> Also, your do {} while loops for the timeouts falsely give the impression we do \"retry\" attempts when we actually do \"retry + 1\" attempts (but I guess it doesn't make a big difference from the functional point of view).\n> \n\nAgreed. The current logic of code is confusing as val is used twice.\n\n>> +}\n>> +\n>> +static int hi3660_mbox_send(struct mbox_chan *chan, u32 *msg)\n>> +{\n>> + unsigned long ch = (unsigned long)chan->con_priv;\n>> + struct hi3660_mbox *mbox = to_hi3660_mbox(chan);\n>> + struct hi3660_mbox_dev *mdev = &mbox->mdev[ch];\n>> + void __iomem *base = MBOX_BASE(mbox, ch);\n>> + unsigned int i;\n>> +\n>> + /* Clear mask for destination interrupt */\n>> + writel_relaxed(~BIT(mdev->dst_irq), base + MBOX_IMASK_REG);\n>> +\n>> + /* Config destination for interrupt vector */\n>> + writel_relaxed(BIT(mdev->dst_irq), base + MBOX_DST_REG);\n>> +\n>> + /* Automatic acknowledge mode */\n>> + writel_relaxed(MBOX_AUTOMATIC_ACK, base + MBOX_MODE_REG);\n>> +\n>> + /* Fill message data */\n>> + for (i = 0; i < MBOX_MSG_LEN; i++)\n>> + writel_relaxed(msg[i], base + MBOX_DATA_REG + i * 4);\n>> +\n>> + /* Trigger data transferring */\n>> + writel_relaxed(BIT(mdev->ack_irq), base + MBOX_SEND_REG);\n>> + return 0;\n>> +}\n>> +\n>> +static int hi3660_mbox_send_data(struct mbox_chan *chan, void *msg)\n>> +{\n>> + struct hi3660_mbox *mbox = to_hi3660_mbox(chan);\n>> + int err;\n>> +\n>> + err = hi3660_mbox_check_state(chan);\n>> + if (err) {\n>> + dev_err(mbox->dev, \"checking state failed\\n\");\n>> + return err;\n>> + }\n>> +\n>> + err = hi3660_mbox_unlock(chan);\n>> + if (err) {\n>> + dev_err(mbox->dev, \"unlocking mailbox failed\\n\");\n>> + return err;\n>> + }\n>> +\n>> + err = hi3660_mbox_acquire_channel(chan);\n>> + if (err) {\n>> + dev_err(mbox->dev, \"acquiring channel failed\\n\");\n>> + return err;\n>> + }\n>> +\n>> + return hi3660_mbox_send(chan, msg);\n>> +}\n>> +\n>> +static struct mbox_chan_ops hi3660_mbox_ops = {\n>> + .send_data = hi3660_mbox_send_data,\n>> +};\n>> +\n>> +static struct mbox_chan *hi3660_mbox_xlate(struct mbox_controller *controller,\n>> + const struct of_phandle_args *spec)\n>> +{\n>> + struct hi3660_mbox *mbox = dev_get_drvdata(controller->dev);\n> \n> nit:\n> In to_hi3660_mbox, you use the fact that the mbox_controller structure is part of hi3660_mbox and use container of to retrieve hi3660_mbox.\n> \n> I think it would be nice to be consistent about this, either use container_of or dev drvdata, but not both.\n> \n> Cheers,\n> \nI will discuss with Leo.\n\nThanks for your comments.\n\nBest Regards,\n\n\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3ySKH1443Zz9sNw\n\tfor ;\n\tThu, 2 Nov 2017 20:17:17 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1755330AbdKBJRQ (ORCPT\n\t);\n\tThu, 2 Nov 2017 05:17:16 -0400","from szxga05-in.huawei.com ([45.249.212.191]:9998 \"EHLO\n\tszxga05-in.huawei.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1755317AbdKBJRN (ORCPT\n\t); Thu, 2 Nov 2017 05:17:13 -0400","from 172.30.72.60 (EHLO DGGEMS401-HUB.china.huawei.com)\n\t([172.30.72.60])\n\tby dggrg05-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id DKG94079; Thu, 02 Nov 2017 17:17:09 +0800 (CST)","from [127.0.0.1] (10.142.146.73) by DGGEMS401-HUB.china.huawei.com\n\t(10.3.19.201) with Microsoft SMTP Server id 14.3.361.1;\n\tThu, 2 Nov 2017 17:16:45 +0800"],"Message-ID":"<59FAE221.3080600@huawei.com>","Date":"Thu, 2 Nov 2017 17:15:13 +0800","From":"Zhong Kaihua ","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64;\n\trv:17.0) Gecko/20130509 Thunderbird/17.0.6","MIME-Version":"1.0","To":"Julien Thierry ","CC":", ,\n\t, ,\n\t, ,\n\t, ,\n\t, ,\n\t, ,\n\t, ","Subject":"Re: [PATCH v2 2/3] mailbox: Add support for Hi3660 mailbox","References":"<1509084904-2505-1-git-send-email-zhongkaihua@huawei.com>\n\t<1509084904-2505-3-git-send-email-zhongkaihua@huawei.com>\n\t<90d25374-cc83-7f75-eb38-766f0cdb9c53@arm.com>","In-Reply-To":"<90d25374-cc83-7f75-eb38-766f0cdb9c53@arm.com>","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"8bit","X-Originating-IP":"[10.142.146.73]","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A020202.59FAE295.007B, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"b2ac9fd7cf6b4824a3fe9b7aa4b70c21","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}}]