From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 16F1BC433EF for ; Wed, 24 Nov 2021 10:26:20 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 3004D1790; Wed, 24 Nov 2021 11:25:28 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 3004D1790 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1637749578; bh=CKHIHTg0Ne21AoP0jZbkP9W/BUZ5h3LG0HezFEK/yl8=; h=Date:From:To:Subject:References:In-Reply-To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=iDBYXUqvn2mvV1MDoIq/RYFfNEPrQThVr0prRKJeQUIKSG9ZtPqP0lfPKFPY6eCW0 lulCCgofvmY0F+qzOARBc9wEYJFg78qjKZffnG2gsrp1cTGdvj4w1504S/UAVzsfAT rrOrBRysmN2+aq/9pWdRi2DqFdvbSmwcquzlgr/w= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id BD0C2F8014D; Wed, 24 Nov 2021 11:25:27 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 1DFB7F8013A; Wed, 24 Nov 2021 11:25:26 +0100 (CET) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 23C6EF8011F for ; Wed, 24 Nov 2021 11:25:21 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 23C6EF8011F Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="TUOz5Mfg" Received: by mail-pg1-x531.google.com with SMTP id m15so1705740pgu.11 for ; Wed, 24 Nov 2021 02:25:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=RWDbxw0O+Eb2MTODPtyb5giEnnTJJaqwqAJtlwbLKPM=; b=TUOz5MfgG5JMzyZ6iwNq72F59avCAePjCoi5R5mYzgjxOabfcPIkv/bF2Tc1L1gGE/ dXLcUIr5YGb2GMc38BMHvZFi8xLHBdoicirIxGj8Q8Fi3qy8Ty+rivQNOn6eNWpXjUeg Ka4IJxZZZyXSDcU342PW0GfzGYlVWPhL4ViLLwvmfTs4rPnjeKv+IqD9ac0NpcZGOnzp ldUTjhKiI7o+vzFrUwyanPTB1KN+3PggPEJWt895E6pucNJ5Hn5rNAvruC2i82QWgyO+ v8fC1QGAyrRZX90+bJFZvUM3DgXMVM4cK9QmtNEc3ZY8zwK9ykP+OvQY7Uy7H2tu06jh Jefg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=RWDbxw0O+Eb2MTODPtyb5giEnnTJJaqwqAJtlwbLKPM=; b=Itv3taXczB00FcvkL6zcz/2Mjbi5pE+o1WzlRT5BK7KMS0denaUcNAq36/UtiHMpvn PYlW0wcFTIXXxp6+dWRbhNtD3KJotEx5VznXLxB1ZYQf1Wfe9W8aHB0nBJ/+VtyiJBM4 zUoD2wnj6Nfyz5VEN/i2fY/sJhMFOEioWFQ/gWcu4DtvUHK7osIvb+NNkz8gnFvvJ1mT e8iEKe0hQXInx9UIIX9euDEqZCBQ7S94g2bxStSGE72V8VLM7j6ozhnp89akTh1vxZ7P ea+PX4KlPDOdvU8u5rie48Gi+ManAiMrieXsLSqeQnc51FEahrQFdy6dacNx3GiO1foc mTOA== X-Gm-Message-State: AOAM531dYthuzIibd4loznQ8DbV0KCGJRM7d59AahYuCHRx5HQ8YNIO/ j1nyqqvhqpYCBLBF7fEh6478LQ== X-Google-Smtp-Source: ABdhPJy4yGk5G/wT8MjPGEmXFxJwr4sD+MfMiZ+bTpsvRjJhdnwJCzHW6W0Mc4xMDUEALiJGPp8oIg== X-Received: by 2002:a63:90c1:: with SMTP id a184mr7144545pge.222.1637749518381; Wed, 24 Nov 2021 02:25:18 -0800 (PST) Received: from google.com ([2401:fa00:1:10:104b:13b9:d53:e2aa]) by smtp.gmail.com with ESMTPSA id f4sm15333725pfg.34.2021.11.24.02.25.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Nov 2021 02:25:18 -0800 (PST) Date: Wed, 24 Nov 2021 18:25:13 +0800 From: Tzung-Bi Shih To: "allen-kh.cheng" Subject: Re: [PATCH v3 2/3] mailbox: mediatek: add support for adsp mailbox controller Message-ID: References: <20211124084514.28002-1-allen-kh.cheng@mediatek.com> <20211124084514.28002-3-allen-kh.cheng@mediatek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211124084514.28002-3-allen-kh.cheng@mediatek.com> Cc: devicetree@vger.kernel.org, Linux-ALSA , Kai Vehmanen , cujomalainey@google.com, Daniel Baluta , Mark Brown , Jassi Brar , Liam Girdwood , linux-kernel@vger.kernel.org, Project_Global_Chrome_Upstream_Group@mediatek.com, Rob Herring , linux-mediatek@lists.infradead.org, Ranjani Sridharan , Matthias Brugger , Takashi Iwai , Pierre-Louis Bossart , linux-arm-kernel@lists.infradead.org, sound-open-firmware@alsa-project.org X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" 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(...); From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 76027C433F5 for ; Wed, 24 Nov 2021 10:25:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=jJqm/xfrEFuw76ubqH1KH8jj5wmaZWRsg2wXagQ0VAA=; b=GQS6+2PW/Vuqt0 nldj91WWvClVCUhnZhNEDhVTc2bV6OzGa9Xc52UvQOpb8dxIxoTtO2ICqlRck0UFLbSvzLV5uFqQt PhLdBCmGp66337Ra/POlAN1UpyCMr3jeToqj9rlJWNae75/eaM9s+aMci9TE7X0a5JYEY3PCDveLa ogs5rjoHvb9WnH9/ppDmmElTeSPALWltniRH2ges4+JHuNMmXmGiL8DpU64V48wjsbeJiLbhkc4ZM +5tuMELwak+B2UMA1wQVAJFxourchRoN+9VR/dUljAGD4b1ujQa5ymnZRS9KNkY532xkblb90bxud jnWXeFphaK3UshuACY/Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mppSt-004Tpe-OT; Wed, 24 Nov 2021 10:25:23 +0000 Received: from mail-pg1-x530.google.com ([2607:f8b0:4864:20::530]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mppSr-004Tov-4O for linux-mediatek@lists.infradead.org; Wed, 24 Nov 2021 10:25:22 +0000 Received: by mail-pg1-x530.google.com with SMTP id l190so1713102pge.7 for ; Wed, 24 Nov 2021 02:25:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=RWDbxw0O+Eb2MTODPtyb5giEnnTJJaqwqAJtlwbLKPM=; b=TUOz5MfgG5JMzyZ6iwNq72F59avCAePjCoi5R5mYzgjxOabfcPIkv/bF2Tc1L1gGE/ dXLcUIr5YGb2GMc38BMHvZFi8xLHBdoicirIxGj8Q8Fi3qy8Ty+rivQNOn6eNWpXjUeg Ka4IJxZZZyXSDcU342PW0GfzGYlVWPhL4ViLLwvmfTs4rPnjeKv+IqD9ac0NpcZGOnzp ldUTjhKiI7o+vzFrUwyanPTB1KN+3PggPEJWt895E6pucNJ5Hn5rNAvruC2i82QWgyO+ v8fC1QGAyrRZX90+bJFZvUM3DgXMVM4cK9QmtNEc3ZY8zwK9ykP+OvQY7Uy7H2tu06jh Jefg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=RWDbxw0O+Eb2MTODPtyb5giEnnTJJaqwqAJtlwbLKPM=; b=qbI5abgKNj24LCY7nJuUsd4FaUFigdofSXjZyA277kgBhENJqvPS6OQ0AzIC8Gi/Pt SIPnrL73VDbsBESSsCwBvDIouQseC3IkbWs6+FU72ffk/1eSKwLuO6JBkxFFX0iOK4Wk 7bmog/pYvFnaJ5/xji6/x5e4sCWG8ZJyrhWCXw8JLSBBoD/7Tnr7h9RKFw3c5e9yD5Q/ a+BBMWRo3bj69C2tLySdkEUqx9BKa8ug2wBhW3CF/0jjr1ZDDwQIJDW08uvWRXy6HmV1 m12uH8F2IdIyG6OgpRmCC1/VNUT05Rd+kB+tEro2BX6dNhV5EQUnJYcoj73qT0umhLS7 8wBA== X-Gm-Message-State: AOAM53269FsKo+Qg2LsXZjJXFMtVUaXY+2EVyrVhnn/YzNMdOxgz33e3 TcBcXEu82b5U9sINAI68GUwZbg== X-Google-Smtp-Source: ABdhPJy4yGk5G/wT8MjPGEmXFxJwr4sD+MfMiZ+bTpsvRjJhdnwJCzHW6W0Mc4xMDUEALiJGPp8oIg== X-Received: by 2002:a63:90c1:: with SMTP id a184mr7144545pge.222.1637749518381; Wed, 24 Nov 2021 02:25:18 -0800 (PST) Received: from google.com ([2401:fa00:1:10:104b:13b9:d53:e2aa]) by smtp.gmail.com with ESMTPSA id f4sm15333725pfg.34.2021.11.24.02.25.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Nov 2021 02:25:18 -0800 (PST) Date: Wed, 24 Nov 2021 18:25:13 +0800 From: Tzung-Bi Shih To: "allen-kh.cheng" Cc: Jassi Brar , Rob Herring , Matthias Brugger , devicetree@vger.kernel.org, Linux-ALSA , Kai Vehmanen , Liam Girdwood , cujomalainey@google.com, linux-kernel@vger.kernel.org, Takashi Iwai , Ranjani Sridharan , Pierre-Louis Bossart , Project_Global_Chrome_Upstream_Group@mediatek.com, Mark Brown , linux-mediatek@lists.infradead.org, Daniel Baluta , 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 Message-ID: References: <20211124084514.28002-1-allen-kh.cheng@mediatek.com> <20211124084514.28002-3-allen-kh.cheng@mediatek.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20211124084514.28002-3-allen-kh.cheng@mediatek.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211124_022521_228887_37297E46 X-CRM114-Status: GOOD ( 24.00 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 862F7C433EF for ; Wed, 24 Nov 2021 10:27:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=dxHjCNrutPWzq+RtYDmxxYxNtrV8uAElJkIAYUr3Xl4=; b=hHbFRk5/GYpbRn iuPw5F1KYo0Rt7nYcySm2Uq8Ff8PDeF0Dhj+OA3sesFkRvCeOkP8rhi95eMpmflYX3i3XpmRyKANg Vwdkr6pwy4s4u9da9/CLh3kv/u68jKYC0oIkX2UNNBDGGYhvXMM2/O4h6TlKwFEtpf8/Y3oFjtwTs 0AMFAzQNyiBGyLSCUL+UtDW/9gatPUxjj6H19gSoY1rJxYNtvE42Qqb+MYyOKGIzCiMYkTcnfcR7M Qw5tydgelBgoSw02w4UAv+PaJuw9fbz0Qez3uyaTulmrS3or+rLl9hq7IzipINyrGSVK6SY9jb3j+ /xkMUHUgKVhugVZnyk/g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mppSv-004Tpi-HC; Wed, 24 Nov 2021 10:25:25 +0000 Received: from mail-pg1-x52c.google.com ([2607:f8b0:4864:20::52c]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mppSr-004Tow-4U for linux-arm-kernel@lists.infradead.org; Wed, 24 Nov 2021 10:25:22 +0000 Received: by mail-pg1-x52c.google.com with SMTP id r5so1717295pgi.6 for ; Wed, 24 Nov 2021 02:25:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=RWDbxw0O+Eb2MTODPtyb5giEnnTJJaqwqAJtlwbLKPM=; b=TUOz5MfgG5JMzyZ6iwNq72F59avCAePjCoi5R5mYzgjxOabfcPIkv/bF2Tc1L1gGE/ dXLcUIr5YGb2GMc38BMHvZFi8xLHBdoicirIxGj8Q8Fi3qy8Ty+rivQNOn6eNWpXjUeg Ka4IJxZZZyXSDcU342PW0GfzGYlVWPhL4ViLLwvmfTs4rPnjeKv+IqD9ac0NpcZGOnzp ldUTjhKiI7o+vzFrUwyanPTB1KN+3PggPEJWt895E6pucNJ5Hn5rNAvruC2i82QWgyO+ v8fC1QGAyrRZX90+bJFZvUM3DgXMVM4cK9QmtNEc3ZY8zwK9ykP+OvQY7Uy7H2tu06jh Jefg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=RWDbxw0O+Eb2MTODPtyb5giEnnTJJaqwqAJtlwbLKPM=; b=QkZjhKKMaD33kxJ4z0SjnqvetaUWBzQoNqqTXEIVzfmOifOem8/+hduuObZg/Mb32+ lgSljfQ43NUniDVOLL087bfJc9CNwOZ4nRjIrByCXZoNMbAfoZj59E0OAGTJexjqaj6Y XomvPhZfsc3CxAKpnRfpTKgBcRgPvrTatQHR8F5CRfPEpczw8t7u5R60r+aGJtPiwGIh HYoBXX+jwPvNfMU5urwCtbiXLyO6dBJQFnUs9pjf2ANmMnby7Fjp6/FVo+3VJF/5oKYP +WeZGut3lKbyGpu6D9SooBFwugMPBMag7IDkGATBANL5FLXN7SiU2S9cyDBuJHiRavkO 6Mtg== X-Gm-Message-State: AOAM530NSlp68ddRyu8L9il2ZaIH7gbFOAkHgljnEqt/HO3tSCfuIGXf txrjXgeNEcBhvZhU+9nDZDLs/g== X-Google-Smtp-Source: ABdhPJy4yGk5G/wT8MjPGEmXFxJwr4sD+MfMiZ+bTpsvRjJhdnwJCzHW6W0Mc4xMDUEALiJGPp8oIg== X-Received: by 2002:a63:90c1:: with SMTP id a184mr7144545pge.222.1637749518381; Wed, 24 Nov 2021 02:25:18 -0800 (PST) Received: from google.com ([2401:fa00:1:10:104b:13b9:d53:e2aa]) by smtp.gmail.com with ESMTPSA id f4sm15333725pfg.34.2021.11.24.02.25.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Nov 2021 02:25:18 -0800 (PST) Date: Wed, 24 Nov 2021 18:25:13 +0800 From: Tzung-Bi Shih To: "allen-kh.cheng" Cc: Jassi Brar , Rob Herring , Matthias Brugger , devicetree@vger.kernel.org, Linux-ALSA , Kai Vehmanen , Liam Girdwood , cujomalainey@google.com, linux-kernel@vger.kernel.org, Takashi Iwai , Ranjani Sridharan , Pierre-Louis Bossart , Project_Global_Chrome_Upstream_Group@mediatek.com, Mark Brown , linux-mediatek@lists.infradead.org, Daniel Baluta , 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 Message-ID: References: <20211124084514.28002-1-allen-kh.cheng@mediatek.com> <20211124084514.28002-3-allen-kh.cheng@mediatek.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20211124084514.28002-3-allen-kh.cheng@mediatek.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211124_022521_229002_04730227 X-CRM114-Status: GOOD ( 25.31 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CE22AC433F5 for ; Wed, 24 Nov 2021 10:25:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231826AbhKXK2b (ORCPT ); Wed, 24 Nov 2021 05:28:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50774 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229977AbhKXK22 (ORCPT ); Wed, 24 Nov 2021 05:28:28 -0500 Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 44EF3C061714 for ; Wed, 24 Nov 2021 02:25:19 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id q16so1703920pgq.10 for ; Wed, 24 Nov 2021 02:25:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=RWDbxw0O+Eb2MTODPtyb5giEnnTJJaqwqAJtlwbLKPM=; b=TUOz5MfgG5JMzyZ6iwNq72F59avCAePjCoi5R5mYzgjxOabfcPIkv/bF2Tc1L1gGE/ dXLcUIr5YGb2GMc38BMHvZFi8xLHBdoicirIxGj8Q8Fi3qy8Ty+rivQNOn6eNWpXjUeg Ka4IJxZZZyXSDcU342PW0GfzGYlVWPhL4ViLLwvmfTs4rPnjeKv+IqD9ac0NpcZGOnzp ldUTjhKiI7o+vzFrUwyanPTB1KN+3PggPEJWt895E6pucNJ5Hn5rNAvruC2i82QWgyO+ v8fC1QGAyrRZX90+bJFZvUM3DgXMVM4cK9QmtNEc3ZY8zwK9ykP+OvQY7Uy7H2tu06jh Jefg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=RWDbxw0O+Eb2MTODPtyb5giEnnTJJaqwqAJtlwbLKPM=; b=VbPbVUUEkh6Gt2upGsiNRoqLI70qrnqK2b8qLDn+dwXIS56RY53m6NBXZu/qaV8nLC zoULp0RbroxIUPcr8rBhzJmm44C6BcS4JAxhuna+G6csJ/oTNqJZma+VumNG5SZkZT8g mE/7CfQ/B6sshRA40lOn7nxUYnYrNeAgIG3XFRUlNzgiL3MLAMmfgGplsc/FH6aUMzbh jDc86Ll68bdeqL9vXqNOaaHW3N5qjNCFQVBX3MF85LZK7Y7TQ+GsH+f3jXFb+0OegHNd zhxCjxIgs08qfCO7v6ne9c4hLpSJmeI3V6qlj1dzufaTRpOPTv7oltd44AX74U8SdDkP HE+w== X-Gm-Message-State: AOAM532SSEKAv5vior7gAi1fQzfCDj2L09vV6RchBVVXugkWDrVHYqS+ faHBM/g7y8b7yElxFQC+SHwlGoT6KKaktQ== X-Google-Smtp-Source: ABdhPJy4yGk5G/wT8MjPGEmXFxJwr4sD+MfMiZ+bTpsvRjJhdnwJCzHW6W0Mc4xMDUEALiJGPp8oIg== X-Received: by 2002:a63:90c1:: with SMTP id a184mr7144545pge.222.1637749518381; Wed, 24 Nov 2021 02:25:18 -0800 (PST) Received: from google.com ([2401:fa00:1:10:104b:13b9:d53:e2aa]) by smtp.gmail.com with ESMTPSA id f4sm15333725pfg.34.2021.11.24.02.25.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Nov 2021 02:25:18 -0800 (PST) Date: Wed, 24 Nov 2021 18:25:13 +0800 From: Tzung-Bi Shih To: "allen-kh.cheng" Cc: Jassi Brar , Rob Herring , Matthias Brugger , devicetree@vger.kernel.org, Linux-ALSA , Kai Vehmanen , Liam Girdwood , cujomalainey@google.com, linux-kernel@vger.kernel.org, Takashi Iwai , Ranjani Sridharan , Pierre-Louis Bossart , Project_Global_Chrome_Upstream_Group@mediatek.com, Mark Brown , linux-mediatek@lists.infradead.org, Daniel Baluta , 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 Message-ID: References: <20211124084514.28002-1-allen-kh.cheng@mediatek.com> <20211124084514.28002-3-allen-kh.cheng@mediatek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211124084514.28002-3-allen-kh.cheng@mediatek.com> Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org 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(...);