From: Tzung-Bi Shih <tzungbi@google.com>
To: "allen-kh.cheng" <allen-kh.cheng@mediatek.com>
Cc: devicetree@vger.kernel.org,
Linux-ALSA <alsa-devel@alsa-project.org>,
Kai Vehmanen <kai.vehmanen@linux.intel.com>,
cujomalainey@google.com, Daniel Baluta <daniel.baluta@nxp.com>,
Mark Brown <broonie@kernel.org>,
Jassi Brar <jassisinghbrar@gmail.com>,
Liam Girdwood <lgirdwood@gmail.com>,
linux-kernel@vger.kernel.org,
Project_Global_Chrome_Upstream_Group@mediatek.com,
Rob Herring <robh+dt@kernel.org>,
linux-mediatek@lists.infradead.org,
Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
Takashi Iwai <tiwai@suse.com>,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
linux-arm-kernel@lists.infradead.org,
sound-open-firmware@alsa-project.org
Subject: Re: [PATCH v3 2/3] mailbox: mediatek: add support for adsp mailbox controller
Date: Wed, 24 Nov 2021 18:25:13 +0800 [thread overview]
Message-ID: <YZ4TCYmvegnC/kR0@google.com> (raw)
In-Reply-To: <20211124084514.28002-3-allen-kh.cheng@mediatek.com>
On Wed, Nov 24, 2021 at 04:45:13PM +0800, allen-kh.cheng wrote:
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> index c9fc06c7e685..fc99d9fc80af 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -236,6 +236,13 @@ config MTK_CMDQ_MBOX
> critical time limitation, such as updating display configuration
> during the vblank.
>
> +config MTK_ADSP_IPC_MBOX
> + tristate "MediaTek ADSP Mailbox Controller"
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> + help
> + Say yes here to add support for MediaTek ADSP IPC mailbox controller
> + driver. It is used to send short messages between processors with dsp.
Although the file didn't maintain alphabetical order, to be neat, moving MTK_ADSP_IPC_MBOX before MTK_CMDQ_MBOX makes more sense.
> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> index c2089f04887e..479a9ae56d5e 100644
> --- a/drivers/mailbox/Makefile
> +++ b/drivers/mailbox/Makefile
> @@ -51,6 +51,8 @@ obj-$(CONFIG_STM32_IPCC) += stm32-ipcc.o
>
> obj-$(CONFIG_MTK_CMDQ_MBOX) += mtk-cmdq-mailbox.o
>
> +obj-$(CONFIG_MTK_ADSP_IPC_MBOX) += mtk-adsp-mailbox.o
> +
Ditto. Move CONFIG_MTK_ADSP_IPC_MBOX before CONFIG_MTK_CMDQ_MBOX without blank line separation.
> diff --git a/drivers/mailbox/mtk-adsp-mailbox.c b/drivers/mailbox/mtk-adsp-mailbox.c
[...]
> +static irqreturn_t mtk_adsp_ipc_irq_handler(int irq, void *data)
> +{
> + struct mbox_chan *ch = (struct mbox_chan *)data;
The cast should be able to remove.
> +static irqreturn_t mtk_adsp_ipc_handler(int irq, void *data)
> +{
> + struct mbox_chan *ch = (struct mbox_chan *)data;
The cast should be able to remove.
> +static int mtk_adsp_mbox_startup(struct mbox_chan *chan)
> +{
> + struct adsp_mbox_ch_info *ch_info = chan->con_priv;
> + void __iomem *reg = ch_info->va_reg;
> +
> + /* Clear DSP mbox command */
> + writel(0xFFFFFFFF, reg + MTK_ADSP_MBOX_IN_CMD_CLR);
> + writel(0xFFFFFFFF, reg + MTK_ADSP_MBOX_OUT_CMD_CLR);
> +
> + return 0;
> +}
> +
> +static void mtk_adsp_mbox_shutdown(struct mbox_chan *chan)
> +{
> + chan->con_priv = NULL;
> +}
Shall mtk_adsp_mbox_shutdown() also clear DSP mbox? I.e.:
writel(0xFFFFFFFF, reg + MTK_ADSP_MBOX_IN_CMD_CLR);
writel(0xFFFFFFFF, reg + MTK_ADSP_MBOX_OUT_CMD_CLR);
> +static int mtk_adsp_mbox_send_data(struct mbox_chan *chan, void *data)
> +{
> + struct adsp_mbox_ch_info *ch_info = chan->con_priv;
> + void __iomem *reg = ch_info->va_reg;
> +
> + spin_lock(&ch_info->lock);
> + writel(ch_info->ipc_op_val, reg + MTK_ADSP_MBOX_IN_CMD);
> + spin_unlock(&ch_info->lock);
Why does it need the lock?
Is the write to MTK_ADSP_MBOX_IN_CMD a synchronous operation?
- If yes, I failed to understand why does it need the lock. Every calls to mtk_adsp_mbox_send_data() should wait for the data transfer completion.
- If no, I also failed to understand why. mtk_adsp_mbox_send_data() has no way to be aware of the transfer completion. Would expect a loop for checking the completion for the case.
> +static bool mtk_adsp_mbox_last_tx_done(struct mbox_chan *chan)
> +{
> + struct adsp_mbox_ch_info *ch_info = chan->con_priv;
> + void __iomem *reg = ch_info->va_reg;
> + u32 op = readl(reg + MTK_ADSP_MBOX_IN_CMD);
> +
> + return (op == 0) ? true : false;
To be concise, return readl(...) == 0;
> +static int mtk_adsp_mbox_probe(struct platform_device *pdev)
> +{
[...]
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> + dev_err(dev, "no adsp mbox register resource\n");
> + return -ENXIO;
> + }
> +
> + size = resource_size(res);
> + priv->va_mboxreg = devm_ioremap(dev, (phys_addr_t)res->start, size);
> + if (IS_ERR(priv->va_mboxreg))
> + return PTR_ERR(priv->va_mboxreg);
Use devm_platform_ioremap_resource(), it should be equivalent.
> + /* set adsp mbox channel info */
> + ch_info = devm_kzalloc(mbox->dev, sizeof(*ch_info), GFP_KERNEL);
To be neat, use dev instead of mbox->dev.
> + ret = devm_mbox_controller_register(dev, &priv->mbox);
> + if (ret < 0)
> + dev_err(dev, "error: failed to register mailbox:%d\n", ret);
> +
> + return ret;
To be concise, return devm_mbox_controller_register(...);
WARNING: multiple messages have this Message-ID (diff)
From: Tzung-Bi Shih <tzungbi@google.com>
To: "allen-kh.cheng" <allen-kh.cheng@mediatek.com>
Cc: Jassi Brar <jassisinghbrar@gmail.com>,
Rob Herring <robh+dt@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
devicetree@vger.kernel.org,
Linux-ALSA <alsa-devel@alsa-project.org>,
Kai Vehmanen <kai.vehmanen@linux.intel.com>,
Liam Girdwood <lgirdwood@gmail.com>,
cujomalainey@google.com, linux-kernel@vger.kernel.org,
Takashi Iwai <tiwai@suse.com>,
Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
Project_Global_Chrome_Upstream_Group@mediatek.com,
Mark Brown <broonie@kernel.org>,
linux-mediatek@lists.infradead.org,
Daniel Baluta <daniel.baluta@nxp.com>,
linux-arm-kernel@lists.infradead.org,
sound-open-firmware@alsa-project.org
Subject: Re: [PATCH v3 2/3] mailbox: mediatek: add support for adsp mailbox controller
Date: Wed, 24 Nov 2021 18:25:13 +0800 [thread overview]
Message-ID: <YZ4TCYmvegnC/kR0@google.com> (raw)
In-Reply-To: <20211124084514.28002-3-allen-kh.cheng@mediatek.com>
On Wed, Nov 24, 2021 at 04:45:13PM +0800, allen-kh.cheng wrote:
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> index c9fc06c7e685..fc99d9fc80af 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -236,6 +236,13 @@ config MTK_CMDQ_MBOX
> critical time limitation, such as updating display configuration
> during the vblank.
>
> +config MTK_ADSP_IPC_MBOX
> + tristate "MediaTek ADSP Mailbox Controller"
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> + help
> + Say yes here to add support for MediaTek ADSP IPC mailbox controller
> + driver. It is used to send short messages between processors with dsp.
Although the file didn't maintain alphabetical order, to be neat, moving MTK_ADSP_IPC_MBOX before MTK_CMDQ_MBOX makes more sense.
> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> index c2089f04887e..479a9ae56d5e 100644
> --- a/drivers/mailbox/Makefile
> +++ b/drivers/mailbox/Makefile
> @@ -51,6 +51,8 @@ obj-$(CONFIG_STM32_IPCC) += stm32-ipcc.o
>
> obj-$(CONFIG_MTK_CMDQ_MBOX) += mtk-cmdq-mailbox.o
>
> +obj-$(CONFIG_MTK_ADSP_IPC_MBOX) += mtk-adsp-mailbox.o
> +
Ditto. Move CONFIG_MTK_ADSP_IPC_MBOX before CONFIG_MTK_CMDQ_MBOX without blank line separation.
> diff --git a/drivers/mailbox/mtk-adsp-mailbox.c b/drivers/mailbox/mtk-adsp-mailbox.c
[...]
> +static irqreturn_t mtk_adsp_ipc_irq_handler(int irq, void *data)
> +{
> + struct mbox_chan *ch = (struct mbox_chan *)data;
The cast should be able to remove.
> +static irqreturn_t mtk_adsp_ipc_handler(int irq, void *data)
> +{
> + struct mbox_chan *ch = (struct mbox_chan *)data;
The cast should be able to remove.
> +static int mtk_adsp_mbox_startup(struct mbox_chan *chan)
> +{
> + struct adsp_mbox_ch_info *ch_info = chan->con_priv;
> + void __iomem *reg = ch_info->va_reg;
> +
> + /* Clear DSP mbox command */
> + writel(0xFFFFFFFF, reg + MTK_ADSP_MBOX_IN_CMD_CLR);
> + writel(0xFFFFFFFF, reg + MTK_ADSP_MBOX_OUT_CMD_CLR);
> +
> + return 0;
> +}
> +
> +static void mtk_adsp_mbox_shutdown(struct mbox_chan *chan)
> +{
> + chan->con_priv = NULL;
> +}
Shall mtk_adsp_mbox_shutdown() also clear DSP mbox? I.e.:
writel(0xFFFFFFFF, reg + MTK_ADSP_MBOX_IN_CMD_CLR);
writel(0xFFFFFFFF, reg + MTK_ADSP_MBOX_OUT_CMD_CLR);
> +static int mtk_adsp_mbox_send_data(struct mbox_chan *chan, void *data)
> +{
> + struct adsp_mbox_ch_info *ch_info = chan->con_priv;
> + void __iomem *reg = ch_info->va_reg;
> +
> + spin_lock(&ch_info->lock);
> + writel(ch_info->ipc_op_val, reg + MTK_ADSP_MBOX_IN_CMD);
> + spin_unlock(&ch_info->lock);
Why does it need the lock?
Is the write to MTK_ADSP_MBOX_IN_CMD a synchronous operation?
- If yes, I failed to understand why does it need the lock. Every calls to mtk_adsp_mbox_send_data() should wait for the data transfer completion.
- If no, I also failed to understand why. mtk_adsp_mbox_send_data() has no way to be aware of the transfer completion. Would expect a loop for checking the completion for the case.
> +static bool mtk_adsp_mbox_last_tx_done(struct mbox_chan *chan)
> +{
> + struct adsp_mbox_ch_info *ch_info = chan->con_priv;
> + void __iomem *reg = ch_info->va_reg;
> + u32 op = readl(reg + MTK_ADSP_MBOX_IN_CMD);
> +
> + return (op == 0) ? true : false;
To be concise, return readl(...) == 0;
> +static int mtk_adsp_mbox_probe(struct platform_device *pdev)
> +{
[...]
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> + dev_err(dev, "no adsp mbox register resource\n");
> + return -ENXIO;
> + }
> +
> + size = resource_size(res);
> + priv->va_mboxreg = devm_ioremap(dev, (phys_addr_t)res->start, size);
> + if (IS_ERR(priv->va_mboxreg))
> + return PTR_ERR(priv->va_mboxreg);
Use devm_platform_ioremap_resource(), it should be equivalent.
> + /* set adsp mbox channel info */
> + ch_info = devm_kzalloc(mbox->dev, sizeof(*ch_info), GFP_KERNEL);
To be neat, use dev instead of mbox->dev.
> + ret = devm_mbox_controller_register(dev, &priv->mbox);
> + if (ret < 0)
> + dev_err(dev, "error: failed to register mailbox:%d\n", ret);
> +
> + return ret;
To be concise, return devm_mbox_controller_register(...);
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
WARNING: multiple messages have this Message-ID (diff)
From: Tzung-Bi Shih <tzungbi@google.com>
To: "allen-kh.cheng" <allen-kh.cheng@mediatek.com>
Cc: Jassi Brar <jassisinghbrar@gmail.com>,
Rob Herring <robh+dt@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
devicetree@vger.kernel.org,
Linux-ALSA <alsa-devel@alsa-project.org>,
Kai Vehmanen <kai.vehmanen@linux.intel.com>,
Liam Girdwood <lgirdwood@gmail.com>,
cujomalainey@google.com, linux-kernel@vger.kernel.org,
Takashi Iwai <tiwai@suse.com>,
Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
Project_Global_Chrome_Upstream_Group@mediatek.com,
Mark Brown <broonie@kernel.org>,
linux-mediatek@lists.infradead.org,
Daniel Baluta <daniel.baluta@nxp.com>,
linux-arm-kernel@lists.infradead.org,
sound-open-firmware@alsa-project.org
Subject: Re: [PATCH v3 2/3] mailbox: mediatek: add support for adsp mailbox controller
Date: Wed, 24 Nov 2021 18:25:13 +0800 [thread overview]
Message-ID: <YZ4TCYmvegnC/kR0@google.com> (raw)
In-Reply-To: <20211124084514.28002-3-allen-kh.cheng@mediatek.com>
On Wed, Nov 24, 2021 at 04:45:13PM +0800, allen-kh.cheng wrote:
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> index c9fc06c7e685..fc99d9fc80af 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -236,6 +236,13 @@ config MTK_CMDQ_MBOX
> critical time limitation, such as updating display configuration
> during the vblank.
>
> +config MTK_ADSP_IPC_MBOX
> + tristate "MediaTek ADSP Mailbox Controller"
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> + help
> + Say yes here to add support for MediaTek ADSP IPC mailbox controller
> + driver. It is used to send short messages between processors with dsp.
Although the file didn't maintain alphabetical order, to be neat, moving MTK_ADSP_IPC_MBOX before MTK_CMDQ_MBOX makes more sense.
> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> index c2089f04887e..479a9ae56d5e 100644
> --- a/drivers/mailbox/Makefile
> +++ b/drivers/mailbox/Makefile
> @@ -51,6 +51,8 @@ obj-$(CONFIG_STM32_IPCC) += stm32-ipcc.o
>
> obj-$(CONFIG_MTK_CMDQ_MBOX) += mtk-cmdq-mailbox.o
>
> +obj-$(CONFIG_MTK_ADSP_IPC_MBOX) += mtk-adsp-mailbox.o
> +
Ditto. Move CONFIG_MTK_ADSP_IPC_MBOX before CONFIG_MTK_CMDQ_MBOX without blank line separation.
> diff --git a/drivers/mailbox/mtk-adsp-mailbox.c b/drivers/mailbox/mtk-adsp-mailbox.c
[...]
> +static irqreturn_t mtk_adsp_ipc_irq_handler(int irq, void *data)
> +{
> + struct mbox_chan *ch = (struct mbox_chan *)data;
The cast should be able to remove.
> +static irqreturn_t mtk_adsp_ipc_handler(int irq, void *data)
> +{
> + struct mbox_chan *ch = (struct mbox_chan *)data;
The cast should be able to remove.
> +static int mtk_adsp_mbox_startup(struct mbox_chan *chan)
> +{
> + struct adsp_mbox_ch_info *ch_info = chan->con_priv;
> + void __iomem *reg = ch_info->va_reg;
> +
> + /* Clear DSP mbox command */
> + writel(0xFFFFFFFF, reg + MTK_ADSP_MBOX_IN_CMD_CLR);
> + writel(0xFFFFFFFF, reg + MTK_ADSP_MBOX_OUT_CMD_CLR);
> +
> + return 0;
> +}
> +
> +static void mtk_adsp_mbox_shutdown(struct mbox_chan *chan)
> +{
> + chan->con_priv = NULL;
> +}
Shall mtk_adsp_mbox_shutdown() also clear DSP mbox? I.e.:
writel(0xFFFFFFFF, reg + MTK_ADSP_MBOX_IN_CMD_CLR);
writel(0xFFFFFFFF, reg + MTK_ADSP_MBOX_OUT_CMD_CLR);
> +static int mtk_adsp_mbox_send_data(struct mbox_chan *chan, void *data)
> +{
> + struct adsp_mbox_ch_info *ch_info = chan->con_priv;
> + void __iomem *reg = ch_info->va_reg;
> +
> + spin_lock(&ch_info->lock);
> + writel(ch_info->ipc_op_val, reg + MTK_ADSP_MBOX_IN_CMD);
> + spin_unlock(&ch_info->lock);
Why does it need the lock?
Is the write to MTK_ADSP_MBOX_IN_CMD a synchronous operation?
- If yes, I failed to understand why does it need the lock. Every calls to mtk_adsp_mbox_send_data() should wait for the data transfer completion.
- If no, I also failed to understand why. mtk_adsp_mbox_send_data() has no way to be aware of the transfer completion. Would expect a loop for checking the completion for the case.
> +static bool mtk_adsp_mbox_last_tx_done(struct mbox_chan *chan)
> +{
> + struct adsp_mbox_ch_info *ch_info = chan->con_priv;
> + void __iomem *reg = ch_info->va_reg;
> + u32 op = readl(reg + MTK_ADSP_MBOX_IN_CMD);
> +
> + return (op == 0) ? true : false;
To be concise, return readl(...) == 0;
> +static int mtk_adsp_mbox_probe(struct platform_device *pdev)
> +{
[...]
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> + dev_err(dev, "no adsp mbox register resource\n");
> + return -ENXIO;
> + }
> +
> + size = resource_size(res);
> + priv->va_mboxreg = devm_ioremap(dev, (phys_addr_t)res->start, size);
> + if (IS_ERR(priv->va_mboxreg))
> + return PTR_ERR(priv->va_mboxreg);
Use devm_platform_ioremap_resource(), it should be equivalent.
> + /* set adsp mbox channel info */
> + ch_info = devm_kzalloc(mbox->dev, sizeof(*ch_info), GFP_KERNEL);
To be neat, use dev instead of mbox->dev.
> + ret = devm_mbox_controller_register(dev, &priv->mbox);
> + if (ret < 0)
> + dev_err(dev, "error: failed to register mailbox:%d\n", ret);
> +
> + return ret;
To be concise, return devm_mbox_controller_register(...);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Tzung-Bi Shih <tzungbi@google.com>
To: "allen-kh.cheng" <allen-kh.cheng@mediatek.com>
Cc: Jassi Brar <jassisinghbrar@gmail.com>,
Rob Herring <robh+dt@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
devicetree@vger.kernel.org,
Linux-ALSA <alsa-devel@alsa-project.org>,
Kai Vehmanen <kai.vehmanen@linux.intel.com>,
Liam Girdwood <lgirdwood@gmail.com>,
cujomalainey@google.com, linux-kernel@vger.kernel.org,
Takashi Iwai <tiwai@suse.com>,
Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
Project_Global_Chrome_Upstream_Group@mediatek.com,
Mark Brown <broonie@kernel.org>,
linux-mediatek@lists.infradead.org,
Daniel Baluta <daniel.baluta@nxp.com>,
linux-arm-kernel@lists.infradead.org,
sound-open-firmware@alsa-project.org
Subject: Re: [PATCH v3 2/3] mailbox: mediatek: add support for adsp mailbox controller
Date: Wed, 24 Nov 2021 18:25:13 +0800 [thread overview]
Message-ID: <YZ4TCYmvegnC/kR0@google.com> (raw)
In-Reply-To: <20211124084514.28002-3-allen-kh.cheng@mediatek.com>
On Wed, Nov 24, 2021 at 04:45:13PM +0800, allen-kh.cheng wrote:
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> index c9fc06c7e685..fc99d9fc80af 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -236,6 +236,13 @@ config MTK_CMDQ_MBOX
> critical time limitation, such as updating display configuration
> during the vblank.
>
> +config MTK_ADSP_IPC_MBOX
> + tristate "MediaTek ADSP Mailbox Controller"
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> + help
> + Say yes here to add support for MediaTek ADSP IPC mailbox controller
> + driver. It is used to send short messages between processors with dsp.
Although the file didn't maintain alphabetical order, to be neat, moving MTK_ADSP_IPC_MBOX before MTK_CMDQ_MBOX makes more sense.
> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> index c2089f04887e..479a9ae56d5e 100644
> --- a/drivers/mailbox/Makefile
> +++ b/drivers/mailbox/Makefile
> @@ -51,6 +51,8 @@ obj-$(CONFIG_STM32_IPCC) += stm32-ipcc.o
>
> obj-$(CONFIG_MTK_CMDQ_MBOX) += mtk-cmdq-mailbox.o
>
> +obj-$(CONFIG_MTK_ADSP_IPC_MBOX) += mtk-adsp-mailbox.o
> +
Ditto. Move CONFIG_MTK_ADSP_IPC_MBOX before CONFIG_MTK_CMDQ_MBOX without blank line separation.
> diff --git a/drivers/mailbox/mtk-adsp-mailbox.c b/drivers/mailbox/mtk-adsp-mailbox.c
[...]
> +static irqreturn_t mtk_adsp_ipc_irq_handler(int irq, void *data)
> +{
> + struct mbox_chan *ch = (struct mbox_chan *)data;
The cast should be able to remove.
> +static irqreturn_t mtk_adsp_ipc_handler(int irq, void *data)
> +{
> + struct mbox_chan *ch = (struct mbox_chan *)data;
The cast should be able to remove.
> +static int mtk_adsp_mbox_startup(struct mbox_chan *chan)
> +{
> + struct adsp_mbox_ch_info *ch_info = chan->con_priv;
> + void __iomem *reg = ch_info->va_reg;
> +
> + /* Clear DSP mbox command */
> + writel(0xFFFFFFFF, reg + MTK_ADSP_MBOX_IN_CMD_CLR);
> + writel(0xFFFFFFFF, reg + MTK_ADSP_MBOX_OUT_CMD_CLR);
> +
> + return 0;
> +}
> +
> +static void mtk_adsp_mbox_shutdown(struct mbox_chan *chan)
> +{
> + chan->con_priv = NULL;
> +}
Shall mtk_adsp_mbox_shutdown() also clear DSP mbox? I.e.:
writel(0xFFFFFFFF, reg + MTK_ADSP_MBOX_IN_CMD_CLR);
writel(0xFFFFFFFF, reg + MTK_ADSP_MBOX_OUT_CMD_CLR);
> +static int mtk_adsp_mbox_send_data(struct mbox_chan *chan, void *data)
> +{
> + struct adsp_mbox_ch_info *ch_info = chan->con_priv;
> + void __iomem *reg = ch_info->va_reg;
> +
> + spin_lock(&ch_info->lock);
> + writel(ch_info->ipc_op_val, reg + MTK_ADSP_MBOX_IN_CMD);
> + spin_unlock(&ch_info->lock);
Why does it need the lock?
Is the write to MTK_ADSP_MBOX_IN_CMD a synchronous operation?
- If yes, I failed to understand why does it need the lock. Every calls to mtk_adsp_mbox_send_data() should wait for the data transfer completion.
- If no, I also failed to understand why. mtk_adsp_mbox_send_data() has no way to be aware of the transfer completion. Would expect a loop for checking the completion for the case.
> +static bool mtk_adsp_mbox_last_tx_done(struct mbox_chan *chan)
> +{
> + struct adsp_mbox_ch_info *ch_info = chan->con_priv;
> + void __iomem *reg = ch_info->va_reg;
> + u32 op = readl(reg + MTK_ADSP_MBOX_IN_CMD);
> +
> + return (op == 0) ? true : false;
To be concise, return readl(...) == 0;
> +static int mtk_adsp_mbox_probe(struct platform_device *pdev)
> +{
[...]
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> + dev_err(dev, "no adsp mbox register resource\n");
> + return -ENXIO;
> + }
> +
> + size = resource_size(res);
> + priv->va_mboxreg = devm_ioremap(dev, (phys_addr_t)res->start, size);
> + if (IS_ERR(priv->va_mboxreg))
> + return PTR_ERR(priv->va_mboxreg);
Use devm_platform_ioremap_resource(), it should be equivalent.
> + /* set adsp mbox channel info */
> + ch_info = devm_kzalloc(mbox->dev, sizeof(*ch_info), GFP_KERNEL);
To be neat, use dev instead of mbox->dev.
> + ret = devm_mbox_controller_register(dev, &priv->mbox);
> + if (ret < 0)
> + dev_err(dev, "error: failed to register mailbox:%d\n", ret);
> +
> + return ret;
To be concise, return devm_mbox_controller_register(...);
next prev parent reply other threads:[~2021-11-24 10:26 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-24 8:45 [PATCH v3 0/3] This patches provide ADSP IPC support for MT8195 allen-kh.cheng
2021-11-24 8:45 ` allen-kh.cheng
2021-11-24 8:45 ` allen-kh.cheng
2021-11-24 8:45 ` [PATCH v3 1/3] dt-bindings: mediatek: add adsp-mbox document allen-kh.cheng
2021-11-24 8:45 ` allen-kh.cheng
2021-11-24 8:45 ` allen-kh.cheng
2021-11-24 8:45 ` [PATCH v3 2/3] mailbox: mediatek: add support for adsp mailbox controller allen-kh.cheng
2021-11-24 8:45 ` allen-kh.cheng
2021-11-24 8:45 ` allen-kh.cheng
2021-11-24 10:25 ` Tzung-Bi Shih [this message]
2021-11-24 10:25 ` Tzung-Bi Shih
2021-11-24 10:25 ` Tzung-Bi Shih
2021-11-24 10:25 ` Tzung-Bi Shih
2021-11-25 1:51 ` allen-kh.cheng
2021-11-25 1:51 ` allen-kh.cheng
2021-11-25 1:51 ` allen-kh.cheng
2021-11-25 6:23 ` Tzung-Bi Shih
2021-11-25 6:23 ` Tzung-Bi Shih
2021-11-25 6:23 ` Tzung-Bi Shih
2021-11-25 6:23 ` Tzung-Bi Shih
2021-11-25 8:24 ` allen-kh.cheng
2021-11-25 8:24 ` allen-kh.cheng
2021-11-25 8:24 ` allen-kh.cheng
2021-11-24 8:45 ` [PATCH v3 3/3] firmware: mediatek: add adsp ipc protocol interface allen-kh.cheng
2021-11-24 8:45 ` allen-kh.cheng
2021-11-24 8:45 ` allen-kh.cheng
2021-11-24 10:25 ` Tzung-Bi Shih
2021-11-24 10:25 ` Tzung-Bi Shih
2021-11-24 10:25 ` Tzung-Bi Shih
2021-11-24 10:25 ` Tzung-Bi Shih
2021-11-25 1:47 ` allen-kh.cheng
2021-11-25 1:47 ` allen-kh.cheng
2021-11-25 1:47 ` allen-kh.cheng
2021-11-25 6:26 ` Tzung-Bi Shih
2021-11-25 6:26 ` Tzung-Bi Shih
2021-11-25 6:26 ` Tzung-Bi Shih
2021-11-25 6:26 ` Tzung-Bi Shih
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=YZ4TCYmvegnC/kR0@google.com \
--to=tzungbi@google.com \
--cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
--cc=allen-kh.cheng@mediatek.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=cujomalainey@google.com \
--cc=daniel.baluta@nxp.com \
--cc=devicetree@vger.kernel.org \
--cc=jassisinghbrar@gmail.com \
--cc=kai.vehmanen@linux.intel.com \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=ranjani.sridharan@linux.intel.com \
--cc=robh+dt@kernel.org \
--cc=sound-open-firmware@alsa-project.org \
--cc=tiwai@suse.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.