| Message ID | 20211124084514.28002-3-allen-kh.cheng@mediatek.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | This patches provide ADSP IPC support for MT8195. | expand |
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(...);
Hi Tzung-Bi, Thanks for your suggestions. On Wed, 2021-11-24 at 18:25 +0800, Tzung-Bi Shih wrote: > > 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. > > > In ADSP MBOX IPC flow, Host would call mbox send data when the shared data transfer completed. (mtk_adsp_mbox_send_data will notice client using MTK_ADSP_MBOX_IN_CMD) It’s more like a signal. In general case, There may be some hosts use the same mbox channel. I think it’s better using lock to protect access to MTK_ADSP_MBOX_IN_CMD registers Thanks, Allen > > > > +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(...); > > >
On Thu, Nov 25, 2021 at 09:51:27AM +0800, allen-kh.cheng wrote: > On Wed, 2021-11-24 at 18:25 +0800, Tzung-Bi Shih wrote: > > > On Wed, Nov 24, 2021 at 04:45:13PM +0800, allen-kh.cheng wrote: > > > > > +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. > > > > > > > In ADSP MBOX IPC flow, > > Host would call mbox send data when the shared data transfer completed. > > (mtk_adsp_mbox_send_data will notice client using MTK_ADSP_MBOX_IN_CMD) > > It’s more like a signal. > > In general case, > > There may be some hosts use the same mbox channel. > > I think it’s better using lock to protect access to > MTK_ADSP_MBOX_IN_CMD registers I still failed to understand. What if 2 hosts notify the same client by writing MTK_ADSP_MBOX_IN_CMD at the same time?
On Thu, 2021-11-25 at 14:23 +0800, Tzung-Bi Shih wrote: > > On Thu, Nov 25, 2021 at 09:51:27AM +0800, allen-kh.cheng wrote: > > > > On Wed, 2021-11-24 at 18:25 +0800, Tzung-Bi Shih wrote: > > > > > > > > On Wed, Nov 24, 2021 at 04:45:13PM +0800, allen- > > > > kh.cheng wrote: > > > > > > > > > > > > +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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In ADSP MBOX IPC flow, > > > > > > > > Host would call mbox send data when the shared data transfer > > > > completed. > > > > > > > > (mtk_adsp_mbox_send_data will notice client using > > > > MTK_ADSP_MBOX_IN_CMD) > > > > > > > > It’s more like a signal. > > > > > > > > In general case, > > > > > > > > There may be some hosts use the same mbox channel. > > > > > > > > I think it’s better using lock to protect access to > > > > MTK_ADSP_MBOX_IN_CMD registers > > > > > I still failed to understand. What if 2 hosts notify the same > client > > by writing MTK_ADSP_MBOX_IN_CMD at the same time? Hi Tzung-Bi, After I think carefully. There is no need to add lock in mtk_adsp_mbox_send_data. In our dsp ipc design, we only have one host(ap) and one client(dsp). If sof ip message transfer is complete, host will use mbox notice dsp message arrived. (MTK_ADSP_MBOX_IN_CMD is signal to trigger mbox irq) I will remove this in next version.
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. + config ZYNQMP_IPI_MBOX bool "Xilinx ZynqMP IPI Mailbox" depends on ARCH_ZYNQMP && OF 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 + obj-$(CONFIG_ZYNQMP_IPI_MBOX) += zynqmp-ipi-mailbox.o obj-$(CONFIG_SUN6I_MSGBOX) += sun6i-msgbox.o diff --git a/drivers/mailbox/mtk-adsp-mailbox.c b/drivers/mailbox/mtk-adsp-mailbox.c new file mode 100644 index 000000000000..b814b003aeb2 --- /dev/null +++ b/drivers/mailbox/mtk-adsp-mailbox.c @@ -0,0 +1,187 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2021 MediaTek Corporation. All rights reserved. + * Author: Allen-KH Cheng <allen-kh.cheng@mediatek.com> + */ + +#include <linux/firmware/mediatek/mtk-adsp-ipc.h> +#include <linux/interrupt.h> +#include <linux/io.h> +#include <linux/iopoll.h> +#include <linux/kernel.h> +#include <linux/mailbox_controller.h> +#include <linux/module.h> +#include <linux/of_device.h> +#include <linux/slab.h> + +/* adsp mbox register offset */ +#define MTK_ADSP_MBOX_IN_CMD 0x00 +#define MTK_ADSP_MBOX_IN_CMD_CLR 0x04 +#define MTK_ADSP_MBOX_OUT_CMD 0x1c +#define MTK_ADSP_MBOX_OUT_CMD_CLR 0x20 +#define MTK_ADSP_MBOX_IN_MSG0 0x08 +#define MTK_ADSP_MBOX_IN_MSG1 0x0C +#define MTK_ADSP_MBOX_OUT_MSG0 0x24 +#define MTK_ADSP_MBOX_OUT_MSG1 0x28 + +struct mtk_adsp_mbox_priv { + struct device *dev; + struct mbox_controller mbox; + void __iomem *va_mboxreg; +}; + +static irqreturn_t mtk_adsp_ipc_irq_handler(int irq, void *data) +{ + struct mbox_chan *ch = (struct mbox_chan *)data; + struct adsp_mbox_ch_info *ch_info = ch->con_priv; + void __iomem *reg = ch_info->va_reg; + u32 op = readl(reg + MTK_ADSP_MBOX_OUT_CMD); + + writel(op, reg + MTK_ADSP_MBOX_OUT_CMD_CLR); + + return IRQ_WAKE_THREAD; +} + +static irqreturn_t mtk_adsp_ipc_handler(int irq, void *data) +{ + struct mbox_chan *ch = (struct mbox_chan *)data; + struct adsp_mbox_ch_info *ch_info = ch->con_priv; + + mbox_chan_received_data(ch, ch_info); + + return IRQ_HANDLED; +} + +static struct mbox_chan *mtk_adsp_mbox_xlate(struct mbox_controller *mbox, + const struct of_phandle_args *sp) +{ + return &mbox->chans[sp->args[0]]; +} + +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; +} + +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); + + return 0; +} + +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; +} + +static const struct mbox_chan_ops adsp_mbox_chan_ops = { + .send_data = mtk_adsp_mbox_send_data, + .startup = mtk_adsp_mbox_startup, + .shutdown = mtk_adsp_mbox_shutdown, + .last_tx_done = mtk_adsp_mbox_last_tx_done, +}; + +static int mtk_adsp_mbox_probe(struct platform_device *pdev) +{ + struct device *dev = &pdev->dev; + struct mbox_controller *mbox; + struct mtk_adsp_mbox_priv *priv; + struct resource *res; + struct adsp_mbox_ch_info *ch_info; + u32 size; + int ret; + int irq; + + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); + if (!priv) + return -ENOMEM; + + mbox = &priv->mbox; + mbox->dev = dev; + mbox->ops = &adsp_mbox_chan_ops; + mbox->txdone_irq = false; + mbox->txdone_poll = true; + mbox->of_xlate = mtk_adsp_mbox_xlate; + mbox->num_chans = 1; + mbox->chans = devm_kzalloc(mbox->dev, sizeof(*mbox->chans), GFP_KERNEL); + if (!mbox->chans) + return -ENOMEM; + + 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); + + irq = platform_get_irq(pdev, 0); + if (irq < 0) + return irq; + + ret = devm_request_threaded_irq(dev, irq, + mtk_adsp_ipc_irq_handler, mtk_adsp_ipc_handler, + IRQF_TRIGGER_NONE, dev_name(dev), + mbox->chans); + if (ret < 0) + return ret; + + /* set adsp mbox channel info */ + ch_info = devm_kzalloc(mbox->dev, sizeof(*ch_info), GFP_KERNEL); + if (!ch_info) + return -ENOMEM; + + spin_lock_init(&ch_info->lock); + ch_info->va_reg = priv->va_mboxreg; + mbox->chans->con_priv = ch_info; + platform_set_drvdata(pdev, priv); + ret = devm_mbox_controller_register(dev, &priv->mbox); + if (ret < 0) + dev_err(dev, "error: failed to register mailbox:%d\n", ret); + + return ret; +} + +static const struct of_device_id mtk_adsp_mbox_of_match[] = { + { .compatible = "mediatek,mt8195-adsp-mbox", }, + {}, +}; +MODULE_DEVICE_TABLE(of, mtk_adsp_mbox_of_match); + +static struct platform_driver mtk_adsp_ipc_mbox_driver = { + .probe = mtk_adsp_mbox_probe, + .driver = { + .name = "mtk_adsp_mbox", + .of_match_table = mtk_adsp_mbox_of_match, + }, +}; +module_platform_driver(mtk_adsp_ipc_mbox_driver); + +MODULE_AUTHOR("Allen-KH Cheng <Allen-KH.Cheng@mediatek.com>"); +MODULE_DESCRIPTION("MTK ADSP mailbox IPC driver"); +MODULE_LICENSE("GPL v2");