From: Tzung-Bi Shih <tzungbi@kernel.org>
To: Bjorn Andersson <andersson@kernel.org>,
Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Chen-Yu Tsai <wenst@chromium.org>,
linux-remoteproc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH v2] remoteproc: mediatek: Unprepare SCP clock during system suspend
Date: Fri, 6 Feb 2026 03:40:26 +0000 [thread overview]
Message-ID: <aYViqgirwN2Xgp61@google.com> (raw)
In-Reply-To: <20260206033034.3031781-1-tzungbi@kernel.org>
On Fri, Feb 06, 2026 at 03:30:33AM +0000, Tzung-Bi Shih wrote:
> Prior to commit d935187cfb27 ("remoteproc: mediatek: Break lock
> dependency to prepare_lock"), `scp->clk` was prepared and enabled only
> when it needs to communicate with the SCP. The commit d935187cfb27
> moved the prepare operation to remoteproc's prepare(), keeping the clock
> prepared as long as the SCP is running.
>
> The power consumption due to the prolonged clock preparation can be
> negligible when the system is running, as SCP is designed to be a very
> power efficient processor.
>
> However, the clock remains prepared even when the system enters system
> suspend. This prevents the underlying clock controller (and potentially
> the parent PLLs) from shutting down, which increases power consumption
> and may block the system from entering deep sleep states.
>
> Add suspend and resume callbacks. Unprepare the clock in suspend() if
> it was active and re-prepare it in resume() to ensure the clock is
> properly disabled during system suspend, while maintaining the "always
> prepared" semantics while the system is active. The driver doesn't
> implement .attach() callback, hence it only checks for RPROC_RUNNING.
>
> Fixes: d935187cfb27 ("remoteproc: mediatek: Break lock dependency to prepare_lock")
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
> ---
Pardon me for forgetting to attach changelog before sending the patch. Here
is the changelog:
v2:
- Add note and code comment for RPROC_ATTACHED.
- Use __maybe_unused instead of '#ifdef CONFIG_PM_SLEEP'.
- Add R-b tag.
v1: https://lore.kernel.org/all/20260204085442.1822123-1-tzungbi@kernel.org
> drivers/remoteproc/mtk_scp.c | 39 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
>
> diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
> index 4651311aeb07..bb6f6a16d895 100644
> --- a/drivers/remoteproc/mtk_scp.c
> +++ b/drivers/remoteproc/mtk_scp.c
> @@ -1592,12 +1592,51 @@ static const struct of_device_id mtk_scp_of_match[] = {
> };
> MODULE_DEVICE_TABLE(of, mtk_scp_of_match);
>
> +static int __maybe_unused scp_suspend(struct device *dev)
> +{
> + struct mtk_scp *scp = dev_get_drvdata(dev);
> + struct rproc *rproc = scp->rproc;
> +
> + /*
> + * Only unprepare if the SCP is running and holding the clock.
> + *
> + * Note: `scp_ops` doesn't implement .attach() callback, hence
> + * `rproc->state` can never be RPROC_ATTACHED. Otherwise, it
> + * should also be checked here.
> + */
> + if (rproc->state == RPROC_RUNNING)
> + clk_unprepare(scp->clk);
> + return 0;
> +}
> +
> +static int __maybe_unused scp_resume(struct device *dev)
> +{
> + struct mtk_scp *scp = dev_get_drvdata(dev);
> + struct rproc *rproc = scp->rproc;
> +
> + /*
> + * Only prepare if the SCP was running and holding the clock.
> + *
> + * Note: `scp_ops` doesn't implement .attach() callback, hence
> + * `rproc->state` can never be RPROC_ATTACHED. Otherwise, it
> + * should also be checked here.
> + */
> + if (rproc->state == RPROC_RUNNING)
> + return clk_prepare(scp->clk);
> + return 0;
> +}
> +
> +static const struct dev_pm_ops scp_pm_ops = {
> + SET_SYSTEM_SLEEP_PM_OPS(scp_suspend, scp_resume)
> +};
> +
> static struct platform_driver mtk_scp_driver = {
> .probe = scp_probe,
> .remove = scp_remove,
> .driver = {
> .name = "mtk-scp",
> .of_match_table = mtk_scp_of_match,
> + .pm = &scp_pm_ops,
> },
> };
>
> --
> 2.53.0.rc2.204.g2597b5adb4-goog
>
next prev parent reply other threads:[~2026-02-06 3:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-06 3:30 [PATCH v2] remoteproc: mediatek: Unprepare SCP clock during system suspend Tzung-Bi Shih
2026-02-06 3:40 ` Tzung-Bi Shih [this message]
2026-02-12 16:04 ` Mathieu Poirier
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=aYViqgirwN2Xgp61@google.com \
--to=tzungbi@kernel.org \
--cc=andersson@kernel.org \
--cc=angelogioacchino.delregno@collabora.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=matthias.bgg@gmail.com \
--cc=wenst@chromium.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox