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 A7C85C433EF for ; Wed, 12 Jan 2022 10:28:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352537AbiALK2K (ORCPT ); Wed, 12 Jan 2022 05:28:10 -0500 Received: from smtp-relay-internal-1.canonical.com ([185.125.188.123]:59752 "EHLO smtp-relay-internal-1.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352530AbiALK2D (ORCPT ); Wed, 12 Jan 2022 05:28:03 -0500 Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 643944001C for ; Wed, 12 Jan 2022 10:28:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1641983282; bh=QRI3RyqVgPy+I4GidDpfSQY18QjzUt/rAxNK//Q3/V4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Y1fNjQm7w8ub4ZmMRDuneay/9gYtEqous4JlodGBJscrJyHmdFuvRyo14jy6wKSvY V+9zPbFYSD/HIiBBFFIUlsP3XBHT8FEwl886jLinoFVKartxi89F8fVvh6htIqII74 ZVDQ4UzsefUGTSEE4oKAi+Xkk+hQwAYmlpsa/AGdoYVEbW7UluARh4dW6+hhAWmUwb qN7btD0U7yr1fGtw8rJZRrrMhfB/LXEkIS/LiSdp0kGBL+At50xn7wmPoht+F44fRF AQ1BDAlT1PpE4A++eXpfAPgurJL3ekOOkwmUZoL02um/eUPUaBR3oYJyIBLXoo8Jbl oLBYVQAGtG4LQ== Received: by mail-ed1-f69.google.com with SMTP id b8-20020a056402350800b003f8f42a883dso1850261edd.16 for ; Wed, 12 Jan 2022 02:28:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=QRI3RyqVgPy+I4GidDpfSQY18QjzUt/rAxNK//Q3/V4=; b=dKQwkIHIn8x04AxB9DIaPQ4+4RJ9QlEI8ZASS9Fwc/uYJQzQ3Jm6lVvCris2r0lufj 2JigPhZvzqN8syXOgzkLshmAWNkebbR+yFuHvKppB4v8KIzeEV66ZsYJphLxFgosufVo xAae9gGtHou2F4gDKJpEISq91Ni6+WCUw85GsW++dDb9lioI6szg8JJYGJB8SnFMk58X 0IQRdgp2HPCY0oFQFDTz/T8xbG5UGFBIsradJ3fLs6ZkgCmzUjWlcTGFCX/grX+4t/eN y4wrRZOJioiD0SvJc0Ubfvu+Y0Y2eYF6w9hEHpSBqfJh5mAOMhXKgkJPEdb4akzOAHHM mQ2Q== X-Gm-Message-State: AOAM530c6j18KWHt8ot735KFQS7mr474QzujexVimarUUQGUzTcKHfIm bAMuo//jSkSYgSDM4BYm2JwLMq+sFX0eDUy4LH4li3lhaUR8sq/nFPGd9QreqQmy5GFgdwLCm0d 7SZhgcSUw5SuDxtaP4DFyJIxIvPvQc8hfXQDhuJ/bfA== X-Received: by 2002:aa7:d554:: with SMTP id u20mr8492734edr.322.1641983281841; Wed, 12 Jan 2022 02:28:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJxNl0142m+NR0mNOStdmmNLcUcWydkHPUn0K/3hwATxqUffiAMouRTvD80ezk7JLym0RGyLwA== X-Received: by 2002:aa7:d554:: with SMTP id u20mr8492708edr.322.1641983281648; Wed, 12 Jan 2022 02:28:01 -0800 (PST) Received: from [192.168.0.29] (xdsl-188-155-168-84.adslplus.ch. [188.155.168.84]) by smtp.gmail.com with ESMTPSA id e16sm5905001edu.15.2022.01.12.02.28.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Jan 2022 02:28:00 -0800 (PST) Message-ID: <22935ffa-469c-a609-c30b-919ba85b842c@canonical.com> Date: Wed, 12 Jan 2022 11:27:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: [PATCH v2 5/6] memory: mtk-smi: Add sleep ctrl function Content-Language: en-US To: Yong Wu , Rob Herring , Matthias Brugger Cc: Krzysztof Kozlowski , Joerg Roedel , Will Deacon , Robin Murphy , Tomasz Figa , linux-mediatek@lists.infradead.org, srv_heupstream@mediatek.com, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, iommu@lists.linux-foundation.org, youlin.pei@mediatek.com, anan.sun@mediatek.com, lc.kan@mediatek.com, yi.kuo@mediatek.com, anthony.huang@mediatek.com, AngeloGioacchino Del Regno References: <20220111063904.7583-1-yong.wu@mediatek.com> <20220111063904.7583-6-yong.wu@mediatek.com> From: Krzysztof Kozlowski In-Reply-To: <20220111063904.7583-6-yong.wu@mediatek.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/01/2022 07:39, Yong Wu wrote: > Sleep control means that when the larb goes to sleep, we should wait a bit > until all the current commands are finished. Thus, when the larb runtime > suspends, we need to enable this function to wait until all the existed > commands are finished. When the larb resumes, just disable this function. > This function only improves the safety of bus. Add a new flag for this > function. Prepare for mt8186. > > Signed-off-by: Anan Sun > Signed-off-by: Yong Wu > --- > drivers/memory/mtk-smi.c | 35 ++++++++++++++++++++++++++++++++++- > 1 file changed, 34 insertions(+), 1 deletion(-) > > diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c > index e7b1a22b12ea..d8552f4caba4 100644 > --- a/drivers/memory/mtk-smi.c > +++ b/drivers/memory/mtk-smi.c > @@ -8,6 +8,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -32,6 +33,10 @@ > #define SMI_DUMMY 0x444 > > /* SMI LARB */ > +#define SMI_LARB_SLP_CON 0xc > +#define SLP_PROT_EN BIT(0) > +#define SLP_PROT_RDY BIT(16) > + > #define SMI_LARB_CMD_THRT_CON 0x24 > #define SMI_LARB_THRT_RD_NU_LMT_MSK GENMASK(7, 4) > #define SMI_LARB_THRT_RD_NU_LMT (5 << 4) > @@ -81,6 +86,7 @@ > > #define MTK_SMI_FLAG_THRT_UPDATE BIT(0) > #define MTK_SMI_FLAG_SW_FLAG BIT(1) > +#define MTK_SMI_FLAG_SLEEP_CTL BIT(2) > #define MTK_SMI_CAPS(flags, _x) (!!((flags) & (_x))) > > struct mtk_smi_reg_pair { > @@ -371,6 +377,26 @@ static const struct of_device_id mtk_smi_larb_of_ids[] = { > {} > }; > > +static int mtk_smi_larb_sleep_ctrl_enable(struct mtk_smi_larb *larb) > +{ > + int ret; > + u32 tmp; > + > + writel_relaxed(SLP_PROT_EN, larb->base + SMI_LARB_SLP_CON); > + ret = readl_poll_timeout_atomic(larb->base + SMI_LARB_SLP_CON, > + tmp, !!(tmp & SLP_PROT_RDY), 10, 1000); > + if (ret) { > + /* TODO: Reset this larb if it fails here. */ > + dev_warn(larb->smi.dev, "sleep ctrl is not ready(0x%x).\n", tmp); > + } > + return ret; > +} > + > +static void mtk_smi_larb_sleep_ctrl_disable(struct mtk_smi_larb *larb) > +{ > + writel_relaxed(0, larb->base + SMI_LARB_SLP_CON); > +} > + > static int mtk_smi_device_link_common(struct device *dev, struct device **com_dev) > { > struct platform_device *smi_com_pdev; > @@ -483,6 +509,9 @@ static int __maybe_unused mtk_smi_larb_resume(struct device *dev) > if (ret) > return ret; > > + if (MTK_SMI_CAPS(larb->larb_gen->flags_general, MTK_SMI_FLAG_SLEEP_CTL)) > + mtk_smi_larb_sleep_ctrl_disable(larb); > + > /* Configure the basic setting for this larb */ > larb_gen->config_port(dev); > > @@ -492,9 +521,13 @@ static int __maybe_unused mtk_smi_larb_resume(struct device *dev) > static int __maybe_unused mtk_smi_larb_suspend(struct device *dev) > { > struct mtk_smi_larb *larb = dev_get_drvdata(dev); > + int ret = 0; > + > + if (MTK_SMI_CAPS(larb->larb_gen->flags_general, MTK_SMI_FLAG_SLEEP_CTL)) > + ret = mtk_smi_larb_sleep_ctrl_enable(larb); > > clk_bulk_disable_unprepare(larb->smi.clk_num, larb->smi.clks); > - return 0; > + return ret; I am wondering whether disabling clocks in error case is a proper step. On suspend error, the PM core won't run any further callbacks on this device. This means, it won't be resumed and your clocks stay disabled. I think you should return early and leave the device in active state in case of error. Best regards, Krzysztof 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 smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.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 52E9BC433F5 for ; Wed, 12 Jan 2022 10:28:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 0969D409CC; Wed, 12 Jan 2022 10:28:09 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hc9Y91x_VxZh; Wed, 12 Jan 2022 10:28:07 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [IPv6:2605:bc80:3010:104::8cd3:938]) by smtp2.osuosl.org (Postfix) with ESMTPS id 66945409A9; Wed, 12 Jan 2022 10:28:07 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 38E30C0030; Wed, 12 Jan 2022 10:28:07 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 0F26EC001E for ; Wed, 12 Jan 2022 10:28:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id F1E8D408D8 for ; Wed, 12 Jan 2022 10:28:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=canonical.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T77o-_h5gtS6 for ; Wed, 12 Jan 2022 10:28:04 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from smtp-relay-internal-1.canonical.com (smtp-relay-internal-1.canonical.com [185.125.188.123]) by smtp4.osuosl.org (Postfix) with ESMTPS id 2838C4049F for ; Wed, 12 Jan 2022 10:28:04 +0000 (UTC) Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 6E2DE402DE for ; Wed, 12 Jan 2022 10:28:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1641983282; bh=QRI3RyqVgPy+I4GidDpfSQY18QjzUt/rAxNK//Q3/V4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Y1fNjQm7w8ub4ZmMRDuneay/9gYtEqous4JlodGBJscrJyHmdFuvRyo14jy6wKSvY V+9zPbFYSD/HIiBBFFIUlsP3XBHT8FEwl886jLinoFVKartxi89F8fVvh6htIqII74 ZVDQ4UzsefUGTSEE4oKAi+Xkk+hQwAYmlpsa/AGdoYVEbW7UluARh4dW6+hhAWmUwb qN7btD0U7yr1fGtw8rJZRrrMhfB/LXEkIS/LiSdp0kGBL+At50xn7wmPoht+F44fRF AQ1BDAlT1PpE4A++eXpfAPgurJL3ekOOkwmUZoL02um/eUPUaBR3oYJyIBLXoo8Jbl oLBYVQAGtG4LQ== Received: by mail-ed1-f71.google.com with SMTP id l14-20020aa7cace000000b003f7f8e1cbbdso1832474edt.20 for ; Wed, 12 Jan 2022 02:28:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=QRI3RyqVgPy+I4GidDpfSQY18QjzUt/rAxNK//Q3/V4=; b=fzWM5/wXARq8gc7Wiaks63R5r92B3uVQ70re7O8GMpOvlgao3XztFHGoctEW4re8Be 7cmuSUd3QPwvawlmYZYvnMImbM1shP7+05Cn06r8veGFi3FLkE0d1OwLAAaO+vEcCziU W0bN9/fJb6U3ck0WZ5JlVMg+FGUWTbtLH6NOvR50mssU4y5OJ6bYA237VwWJWkqWwavp Qli5Bu14FVZVWi4jXbRWMBSXTztFC+u33D5UL7DhWxUeS9bB5O9JajdLwZGZCN9Li4ux yyDliDEC/YdXCTyPwkYBI/3hhzvgLg8NQOrWKbIY9rYWx0Epmx3QlUkEJsXcWyj5o7Pe FdXA== X-Gm-Message-State: AOAM531MsS2+bCWOkcVsUWWm5rE9zEqDUJuZM5UiMI1mbcowMtHcoesN Dy046gqLINIfAC3pwFYjMfJqW0Mnut7PZvmJY9GfkyudrlTrGhtgFqK9KY9+1m/3unQ2nC/Os/w r/7DvXij8LEjWoGbeKD8ZTO5jl43pjXnmsSxF2r36g5PJtqo= X-Received: by 2002:aa7:d554:: with SMTP id u20mr8492738edr.322.1641983281842; Wed, 12 Jan 2022 02:28:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJxNl0142m+NR0mNOStdmmNLcUcWydkHPUn0K/3hwATxqUffiAMouRTvD80ezk7JLym0RGyLwA== X-Received: by 2002:aa7:d554:: with SMTP id u20mr8492708edr.322.1641983281648; Wed, 12 Jan 2022 02:28:01 -0800 (PST) Received: from [192.168.0.29] (xdsl-188-155-168-84.adslplus.ch. [188.155.168.84]) by smtp.gmail.com with ESMTPSA id e16sm5905001edu.15.2022.01.12.02.28.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Jan 2022 02:28:00 -0800 (PST) Message-ID: <22935ffa-469c-a609-c30b-919ba85b842c@canonical.com> Date: Wed, 12 Jan 2022 11:27:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: [PATCH v2 5/6] memory: mtk-smi: Add sleep ctrl function Content-Language: en-US To: Yong Wu , Rob Herring , Matthias Brugger References: <20220111063904.7583-1-yong.wu@mediatek.com> <20220111063904.7583-6-yong.wu@mediatek.com> From: Krzysztof Kozlowski In-Reply-To: <20220111063904.7583-6-yong.wu@mediatek.com> Cc: youlin.pei@mediatek.com, devicetree@vger.kernel.org, yi.kuo@mediatek.com, srv_heupstream@mediatek.com, Will Deacon , linux-kernel@vger.kernel.org, Krzysztof Kozlowski , iommu@lists.linux-foundation.org, linux-mediatek@lists.infradead.org, lc.kan@mediatek.com, anthony.huang@mediatek.com, anan.sun@mediatek.com, Robin Murphy , linux-arm-kernel@lists.infradead.org, AngeloGioacchino Del Regno X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On 11/01/2022 07:39, Yong Wu wrote: > Sleep control means that when the larb goes to sleep, we should wait a bit > until all the current commands are finished. Thus, when the larb runtime > suspends, we need to enable this function to wait until all the existed > commands are finished. When the larb resumes, just disable this function. > This function only improves the safety of bus. Add a new flag for this > function. Prepare for mt8186. > > Signed-off-by: Anan Sun > Signed-off-by: Yong Wu > --- > drivers/memory/mtk-smi.c | 35 ++++++++++++++++++++++++++++++++++- > 1 file changed, 34 insertions(+), 1 deletion(-) > > diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c > index e7b1a22b12ea..d8552f4caba4 100644 > --- a/drivers/memory/mtk-smi.c > +++ b/drivers/memory/mtk-smi.c > @@ -8,6 +8,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -32,6 +33,10 @@ > #define SMI_DUMMY 0x444 > > /* SMI LARB */ > +#define SMI_LARB_SLP_CON 0xc > +#define SLP_PROT_EN BIT(0) > +#define SLP_PROT_RDY BIT(16) > + > #define SMI_LARB_CMD_THRT_CON 0x24 > #define SMI_LARB_THRT_RD_NU_LMT_MSK GENMASK(7, 4) > #define SMI_LARB_THRT_RD_NU_LMT (5 << 4) > @@ -81,6 +86,7 @@ > > #define MTK_SMI_FLAG_THRT_UPDATE BIT(0) > #define MTK_SMI_FLAG_SW_FLAG BIT(1) > +#define MTK_SMI_FLAG_SLEEP_CTL BIT(2) > #define MTK_SMI_CAPS(flags, _x) (!!((flags) & (_x))) > > struct mtk_smi_reg_pair { > @@ -371,6 +377,26 @@ static const struct of_device_id mtk_smi_larb_of_ids[] = { > {} > }; > > +static int mtk_smi_larb_sleep_ctrl_enable(struct mtk_smi_larb *larb) > +{ > + int ret; > + u32 tmp; > + > + writel_relaxed(SLP_PROT_EN, larb->base + SMI_LARB_SLP_CON); > + ret = readl_poll_timeout_atomic(larb->base + SMI_LARB_SLP_CON, > + tmp, !!(tmp & SLP_PROT_RDY), 10, 1000); > + if (ret) { > + /* TODO: Reset this larb if it fails here. */ > + dev_warn(larb->smi.dev, "sleep ctrl is not ready(0x%x).\n", tmp); > + } > + return ret; > +} > + > +static void mtk_smi_larb_sleep_ctrl_disable(struct mtk_smi_larb *larb) > +{ > + writel_relaxed(0, larb->base + SMI_LARB_SLP_CON); > +} > + > static int mtk_smi_device_link_common(struct device *dev, struct device **com_dev) > { > struct platform_device *smi_com_pdev; > @@ -483,6 +509,9 @@ static int __maybe_unused mtk_smi_larb_resume(struct device *dev) > if (ret) > return ret; > > + if (MTK_SMI_CAPS(larb->larb_gen->flags_general, MTK_SMI_FLAG_SLEEP_CTL)) > + mtk_smi_larb_sleep_ctrl_disable(larb); > + > /* Configure the basic setting for this larb */ > larb_gen->config_port(dev); > > @@ -492,9 +521,13 @@ static int __maybe_unused mtk_smi_larb_resume(struct device *dev) > static int __maybe_unused mtk_smi_larb_suspend(struct device *dev) > { > struct mtk_smi_larb *larb = dev_get_drvdata(dev); > + int ret = 0; > + > + if (MTK_SMI_CAPS(larb->larb_gen->flags_general, MTK_SMI_FLAG_SLEEP_CTL)) > + ret = mtk_smi_larb_sleep_ctrl_enable(larb); > > clk_bulk_disable_unprepare(larb->smi.clk_num, larb->smi.clks); > - return 0; > + return ret; I am wondering whether disabling clocks in error case is a proper step. On suspend error, the PM core won't run any further callbacks on this device. This means, it won't be resumed and your clocks stay disabled. I think you should return early and leave the device in active state in case of error. Best regards, Krzysztof _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu 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 78C2CC433F5 for ; Wed, 12 Jan 2022 10:28: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:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=rXWt8NP7WBZSa2caAalzSKnXQuguGJBAFerxlINhel4=; b=LcNmsvAbHgUaiP To43vRtX29pUULFghQIuLPw/XSdPlZZrQiBxCWaQa+EDf1uogJrk96l5a8pesvIcB87IixDo+F8sn wLeMGxYCrB6l5Whk/DEdkb9CMlxyxuL9we8L8uVKbMaDibTNq3u8HBhWDwdFs+mVjPWcMQ0Mbliwi CpMuw7pH5CSJk6BbxqdfdyKhUzJ8TgIou1mWSzORiUp+UYuvpg70zSQdEKm/OUc0SlWHcymkBj6/q X6ZqEk3l8l1sVMsFzeSsTC8LlG3HCnCWY8rXhrjPSRVB7WwxyB+edQjHA/O0V5p4sv/3e2pGAFd24 wCl0L5aar2pEsOrloudA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n7arO-0026Y3-9p; Wed, 12 Jan 2022 10:28:06 +0000 Received: from smtp-relay-internal-1.canonical.com ([185.125.188.123]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n7arL-0026WN-Gw for linux-mediatek@lists.infradead.org; Wed, 12 Jan 2022 10:28:05 +0000 Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 2F8D93FFDB for ; Wed, 12 Jan 2022 10:28:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1641983282; bh=QRI3RyqVgPy+I4GidDpfSQY18QjzUt/rAxNK//Q3/V4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Y1fNjQm7w8ub4ZmMRDuneay/9gYtEqous4JlodGBJscrJyHmdFuvRyo14jy6wKSvY V+9zPbFYSD/HIiBBFFIUlsP3XBHT8FEwl886jLinoFVKartxi89F8fVvh6htIqII74 ZVDQ4UzsefUGTSEE4oKAi+Xkk+hQwAYmlpsa/AGdoYVEbW7UluARh4dW6+hhAWmUwb qN7btD0U7yr1fGtw8rJZRrrMhfB/LXEkIS/LiSdp0kGBL+At50xn7wmPoht+F44fRF AQ1BDAlT1PpE4A++eXpfAPgurJL3ekOOkwmUZoL02um/eUPUaBR3oYJyIBLXoo8Jbl oLBYVQAGtG4LQ== Received: by mail-ed1-f72.google.com with SMTP id y18-20020a056402271200b003fa16a5debcso1856493edd.14 for ; Wed, 12 Jan 2022 02:28:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=QRI3RyqVgPy+I4GidDpfSQY18QjzUt/rAxNK//Q3/V4=; b=rm49YZTdTmqIFq62oo1cjhPiMPNIcJ+5dig+b5w7xpwSN9TkdZ8c9YfrXx3XAjgvNG HzWmT8RJOffSZtnZqb+d3dCvABD7yE16CqnrNhZvwD5YjPCde1AUyKM6+nHwUX1EI93H 6RUwT13NwJjLiEA/l3BQzvYIf59Z2b8PV3dhd1VpU6eNpK8BddjSelXO6776V6fft4pT M6BNmdHxtoh6GoFXdfPqSwao3GkSigE5jJg3m4+G0rWGzBDK3lKixPYhUJBzhwsiQFVl 8SpM2wOtOBJ2VHdmcl9Zsa2bLkgZ4/Blpr+PIqfJ8TML439poo/3D+/kYdRS7LjVxkCi 19+A== X-Gm-Message-State: AOAM533VW/IkVnXiPLI4U5aRoNhnLNjEOrq5kOZfK84DQcEYig+GJRdy 4EThvylNkXFOSJuSmBkxEK2AHTNyeW4trWfDOg0BFFbNpSAc2KBPVxX8cEfD1828iZ1ZmnKa2wr iDwBQ9ipIXPz0/SqNO9OQHnho1CMcZ9M80DDY+PTKhgih3xe08Q== X-Received: by 2002:aa7:d554:: with SMTP id u20mr8492733edr.322.1641983281841; Wed, 12 Jan 2022 02:28:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJxNl0142m+NR0mNOStdmmNLcUcWydkHPUn0K/3hwATxqUffiAMouRTvD80ezk7JLym0RGyLwA== X-Received: by 2002:aa7:d554:: with SMTP id u20mr8492708edr.322.1641983281648; Wed, 12 Jan 2022 02:28:01 -0800 (PST) Received: from [192.168.0.29] (xdsl-188-155-168-84.adslplus.ch. [188.155.168.84]) by smtp.gmail.com with ESMTPSA id e16sm5905001edu.15.2022.01.12.02.28.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Jan 2022 02:28:00 -0800 (PST) Message-ID: <22935ffa-469c-a609-c30b-919ba85b842c@canonical.com> Date: Wed, 12 Jan 2022 11:27:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: [PATCH v2 5/6] memory: mtk-smi: Add sleep ctrl function Content-Language: en-US To: Yong Wu , Rob Herring , Matthias Brugger Cc: Krzysztof Kozlowski , Joerg Roedel , Will Deacon , Robin Murphy , Tomasz Figa , linux-mediatek@lists.infradead.org, srv_heupstream@mediatek.com, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, iommu@lists.linux-foundation.org, youlin.pei@mediatek.com, anan.sun@mediatek.com, lc.kan@mediatek.com, yi.kuo@mediatek.com, anthony.huang@mediatek.com, AngeloGioacchino Del Regno References: <20220111063904.7583-1-yong.wu@mediatek.com> <20220111063904.7583-6-yong.wu@mediatek.com> From: Krzysztof Kozlowski In-Reply-To: <20220111063904.7583-6-yong.wu@mediatek.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220112_022803_757752_39E95665 X-CRM114-Status: GOOD ( 31.86 ) 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 11/01/2022 07:39, Yong Wu wrote: > Sleep control means that when the larb goes to sleep, we should wait a bit > until all the current commands are finished. Thus, when the larb runtime > suspends, we need to enable this function to wait until all the existed > commands are finished. When the larb resumes, just disable this function. > This function only improves the safety of bus. Add a new flag for this > function. Prepare for mt8186. > > Signed-off-by: Anan Sun > Signed-off-by: Yong Wu > --- > drivers/memory/mtk-smi.c | 35 ++++++++++++++++++++++++++++++++++- > 1 file changed, 34 insertions(+), 1 deletion(-) > > diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c > index e7b1a22b12ea..d8552f4caba4 100644 > --- a/drivers/memory/mtk-smi.c > +++ b/drivers/memory/mtk-smi.c > @@ -8,6 +8,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -32,6 +33,10 @@ > #define SMI_DUMMY 0x444 > > /* SMI LARB */ > +#define SMI_LARB_SLP_CON 0xc > +#define SLP_PROT_EN BIT(0) > +#define SLP_PROT_RDY BIT(16) > + > #define SMI_LARB_CMD_THRT_CON 0x24 > #define SMI_LARB_THRT_RD_NU_LMT_MSK GENMASK(7, 4) > #define SMI_LARB_THRT_RD_NU_LMT (5 << 4) > @@ -81,6 +86,7 @@ > > #define MTK_SMI_FLAG_THRT_UPDATE BIT(0) > #define MTK_SMI_FLAG_SW_FLAG BIT(1) > +#define MTK_SMI_FLAG_SLEEP_CTL BIT(2) > #define MTK_SMI_CAPS(flags, _x) (!!((flags) & (_x))) > > struct mtk_smi_reg_pair { > @@ -371,6 +377,26 @@ static const struct of_device_id mtk_smi_larb_of_ids[] = { > {} > }; > > +static int mtk_smi_larb_sleep_ctrl_enable(struct mtk_smi_larb *larb) > +{ > + int ret; > + u32 tmp; > + > + writel_relaxed(SLP_PROT_EN, larb->base + SMI_LARB_SLP_CON); > + ret = readl_poll_timeout_atomic(larb->base + SMI_LARB_SLP_CON, > + tmp, !!(tmp & SLP_PROT_RDY), 10, 1000); > + if (ret) { > + /* TODO: Reset this larb if it fails here. */ > + dev_warn(larb->smi.dev, "sleep ctrl is not ready(0x%x).\n", tmp); > + } > + return ret; > +} > + > +static void mtk_smi_larb_sleep_ctrl_disable(struct mtk_smi_larb *larb) > +{ > + writel_relaxed(0, larb->base + SMI_LARB_SLP_CON); > +} > + > static int mtk_smi_device_link_common(struct device *dev, struct device **com_dev) > { > struct platform_device *smi_com_pdev; > @@ -483,6 +509,9 @@ static int __maybe_unused mtk_smi_larb_resume(struct device *dev) > if (ret) > return ret; > > + if (MTK_SMI_CAPS(larb->larb_gen->flags_general, MTK_SMI_FLAG_SLEEP_CTL)) > + mtk_smi_larb_sleep_ctrl_disable(larb); > + > /* Configure the basic setting for this larb */ > larb_gen->config_port(dev); > > @@ -492,9 +521,13 @@ static int __maybe_unused mtk_smi_larb_resume(struct device *dev) > static int __maybe_unused mtk_smi_larb_suspend(struct device *dev) > { > struct mtk_smi_larb *larb = dev_get_drvdata(dev); > + int ret = 0; > + > + if (MTK_SMI_CAPS(larb->larb_gen->flags_general, MTK_SMI_FLAG_SLEEP_CTL)) > + ret = mtk_smi_larb_sleep_ctrl_enable(larb); > > clk_bulk_disable_unprepare(larb->smi.clk_num, larb->smi.clks); > - return 0; > + return ret; I am wondering whether disabling clocks in error case is a proper step. On suspend error, the PM core won't run any further callbacks on this device. This means, it won't be resumed and your clocks stay disabled. I think you should return early and leave the device in active state in case of error. Best regards, Krzysztof _______________________________________________ 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 736C0C433EF for ; Wed, 12 Jan 2022 10:29:33 +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:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=17qDPct0ul0bzRDtKLZj/qnvrfROCaWeMAsNHep/w3I=; b=y5j2jHgCLid6r+ Jfe6wU/O1tA3lx/xJ9NlOa7SrHBFVPjl4SIIHmxAAffUgK9wi17GkyIqe6/+WfDHW4otWJ3qX9ZEb 34kN9fYoJdKImDYMzVuMF5Kev6eTDtWCT5p4juSG1+KORxCu26lvcze0vBpK2QJmWUqeCMMr7TGPp X3dFkfpOouXheqnGwrncaX9ik4gAufSQMrUl00lZUzDazzeO0cY+EfwtgxR7TpGWWOPN0SN4JO8ed bGXdhv+UP+Ki5hGRL0cXfCIlPlCeeRNRWe9fhPub/oxWZY2h+Nkp9LqXB/WqgGVY2cL2M66CsTeIk j2oMIoMrSUXoxzVKNSWQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n7arU-0026YR-C6; Wed, 12 Jan 2022 10:28:13 +0000 Received: from smtp-relay-internal-1.canonical.com ([185.125.188.123]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n7arL-0026WU-Nx for linux-arm-kernel@lists.infradead.org; Wed, 12 Jan 2022 10:28:05 +0000 Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 5EA6A40019 for ; Wed, 12 Jan 2022 10:28:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1641983282; bh=QRI3RyqVgPy+I4GidDpfSQY18QjzUt/rAxNK//Q3/V4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Y1fNjQm7w8ub4ZmMRDuneay/9gYtEqous4JlodGBJscrJyHmdFuvRyo14jy6wKSvY V+9zPbFYSD/HIiBBFFIUlsP3XBHT8FEwl886jLinoFVKartxi89F8fVvh6htIqII74 ZVDQ4UzsefUGTSEE4oKAi+Xkk+hQwAYmlpsa/AGdoYVEbW7UluARh4dW6+hhAWmUwb qN7btD0U7yr1fGtw8rJZRrrMhfB/LXEkIS/LiSdp0kGBL+At50xn7wmPoht+F44fRF AQ1BDAlT1PpE4A++eXpfAPgurJL3ekOOkwmUZoL02um/eUPUaBR3oYJyIBLXoo8Jbl oLBYVQAGtG4LQ== Received: by mail-ed1-f70.google.com with SMTP id eg24-20020a056402289800b003fe7f91df01so1885449edb.6 for ; Wed, 12 Jan 2022 02:28:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=QRI3RyqVgPy+I4GidDpfSQY18QjzUt/rAxNK//Q3/V4=; b=HCRKVsrgVnIz0Xgtqbm1TiLpp2iZQr0cTx3PqxRBhNdlBMkh5Gf1wW5OWlYtye3eSt sRvEM5ZBJV278NGHpagvTxPmdXjGbfMrcrWgR9ezlshlQ+AGPkJXxdw/nh8XXqr4FS0b mjT2gNgSPybCEk344pDv7teR9MwSJuyx0lv3fl1vg/fLKN9V3TV2iVwlxrAOHiP6ezkm Hn1IqB9F+sdiqNRRkGzH7sZgKQIaZdVhgvhH1nmaQ4ebV3hm/yW792Y1nZNdUzuEXWtq zv7bAjegnzeSVh7QJIA7QbksD7nFGTDrUsCbI88/Poo3eKL0l2IKT9E7x/mRQSEvZvMY yN5A== X-Gm-Message-State: AOAM531zFw0XfG88d9eCJFPhcC37EvIqXr++5M3Z/02Ppafci5aId206 t2bHc3SnXFO8pvNs3vPyGN5XhT7lJRpeY7me789iOvvq/Af+TkKhXm/kgu9IijRKaVXzgoBuQtu NmX6WtjhV5w7yy3nds01wqatF/8THEJsX0aTxJ6aLX8ZykEDXcM+L X-Received: by 2002:aa7:d554:: with SMTP id u20mr8492727edr.322.1641983281841; Wed, 12 Jan 2022 02:28:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJxNl0142m+NR0mNOStdmmNLcUcWydkHPUn0K/3hwATxqUffiAMouRTvD80ezk7JLym0RGyLwA== X-Received: by 2002:aa7:d554:: with SMTP id u20mr8492708edr.322.1641983281648; Wed, 12 Jan 2022 02:28:01 -0800 (PST) Received: from [192.168.0.29] (xdsl-188-155-168-84.adslplus.ch. [188.155.168.84]) by smtp.gmail.com with ESMTPSA id e16sm5905001edu.15.2022.01.12.02.28.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Jan 2022 02:28:00 -0800 (PST) Message-ID: <22935ffa-469c-a609-c30b-919ba85b842c@canonical.com> Date: Wed, 12 Jan 2022 11:27:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: [PATCH v2 5/6] memory: mtk-smi: Add sleep ctrl function Content-Language: en-US To: Yong Wu , Rob Herring , Matthias Brugger Cc: Krzysztof Kozlowski , Joerg Roedel , Will Deacon , Robin Murphy , Tomasz Figa , linux-mediatek@lists.infradead.org, srv_heupstream@mediatek.com, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, iommu@lists.linux-foundation.org, youlin.pei@mediatek.com, anan.sun@mediatek.com, lc.kan@mediatek.com, yi.kuo@mediatek.com, anthony.huang@mediatek.com, AngeloGioacchino Del Regno References: <20220111063904.7583-1-yong.wu@mediatek.com> <20220111063904.7583-6-yong.wu@mediatek.com> From: Krzysztof Kozlowski In-Reply-To: <20220111063904.7583-6-yong.wu@mediatek.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220112_022803_971603_AB3B9626 X-CRM114-Status: GOOD ( 33.23 ) 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 11/01/2022 07:39, Yong Wu wrote: > Sleep control means that when the larb goes to sleep, we should wait a bit > until all the current commands are finished. Thus, when the larb runtime > suspends, we need to enable this function to wait until all the existed > commands are finished. When the larb resumes, just disable this function. > This function only improves the safety of bus. Add a new flag for this > function. Prepare for mt8186. > > Signed-off-by: Anan Sun > Signed-off-by: Yong Wu > --- > drivers/memory/mtk-smi.c | 35 ++++++++++++++++++++++++++++++++++- > 1 file changed, 34 insertions(+), 1 deletion(-) > > diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c > index e7b1a22b12ea..d8552f4caba4 100644 > --- a/drivers/memory/mtk-smi.c > +++ b/drivers/memory/mtk-smi.c > @@ -8,6 +8,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -32,6 +33,10 @@ > #define SMI_DUMMY 0x444 > > /* SMI LARB */ > +#define SMI_LARB_SLP_CON 0xc > +#define SLP_PROT_EN BIT(0) > +#define SLP_PROT_RDY BIT(16) > + > #define SMI_LARB_CMD_THRT_CON 0x24 > #define SMI_LARB_THRT_RD_NU_LMT_MSK GENMASK(7, 4) > #define SMI_LARB_THRT_RD_NU_LMT (5 << 4) > @@ -81,6 +86,7 @@ > > #define MTK_SMI_FLAG_THRT_UPDATE BIT(0) > #define MTK_SMI_FLAG_SW_FLAG BIT(1) > +#define MTK_SMI_FLAG_SLEEP_CTL BIT(2) > #define MTK_SMI_CAPS(flags, _x) (!!((flags) & (_x))) > > struct mtk_smi_reg_pair { > @@ -371,6 +377,26 @@ static const struct of_device_id mtk_smi_larb_of_ids[] = { > {} > }; > > +static int mtk_smi_larb_sleep_ctrl_enable(struct mtk_smi_larb *larb) > +{ > + int ret; > + u32 tmp; > + > + writel_relaxed(SLP_PROT_EN, larb->base + SMI_LARB_SLP_CON); > + ret = readl_poll_timeout_atomic(larb->base + SMI_LARB_SLP_CON, > + tmp, !!(tmp & SLP_PROT_RDY), 10, 1000); > + if (ret) { > + /* TODO: Reset this larb if it fails here. */ > + dev_warn(larb->smi.dev, "sleep ctrl is not ready(0x%x).\n", tmp); > + } > + return ret; > +} > + > +static void mtk_smi_larb_sleep_ctrl_disable(struct mtk_smi_larb *larb) > +{ > + writel_relaxed(0, larb->base + SMI_LARB_SLP_CON); > +} > + > static int mtk_smi_device_link_common(struct device *dev, struct device **com_dev) > { > struct platform_device *smi_com_pdev; > @@ -483,6 +509,9 @@ static int __maybe_unused mtk_smi_larb_resume(struct device *dev) > if (ret) > return ret; > > + if (MTK_SMI_CAPS(larb->larb_gen->flags_general, MTK_SMI_FLAG_SLEEP_CTL)) > + mtk_smi_larb_sleep_ctrl_disable(larb); > + > /* Configure the basic setting for this larb */ > larb_gen->config_port(dev); > > @@ -492,9 +521,13 @@ static int __maybe_unused mtk_smi_larb_resume(struct device *dev) > static int __maybe_unused mtk_smi_larb_suspend(struct device *dev) > { > struct mtk_smi_larb *larb = dev_get_drvdata(dev); > + int ret = 0; > + > + if (MTK_SMI_CAPS(larb->larb_gen->flags_general, MTK_SMI_FLAG_SLEEP_CTL)) > + ret = mtk_smi_larb_sleep_ctrl_enable(larb); > > clk_bulk_disable_unprepare(larb->smi.clk_num, larb->smi.clks); > - return 0; > + return ret; I am wondering whether disabling clocks in error case is a proper step. On suspend error, the PM core won't run any further callbacks on this device. This means, it won't be resumed and your clocks stay disabled. I think you should return early and leave the device in active state in case of error. Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel