diff options
author | Pin-yen Lin <treapking@chromium.org> | 2024-06-13 20:02:28 +0800 |
---|---|---|
committer | Stephen Boyd <sboyd@kernel.org> | 2024-07-01 13:49:07 -0700 |
commit | 878e845d8db04df9ff3bbbaac09d335b24153704 (patch) | |
tree | 202947b4048abf387f9fd83cd8dd0d054535050b /sound/soc/codecs/wcd934x.c | |
parent | f7275fdf945cc91217dfba75d8c9e984c1dab05c (diff) | |
download | linux-878e845d8db04df9ff3bbbaac09d335b24153704.tar.gz linux-878e845d8db04df9ff3bbbaac09d335b24153704.tar.bz2 linux-878e845d8db04df9ff3bbbaac09d335b24153704.zip |
clk: mediatek: mt8183: Only enable runtime PM on mt8183-mfgcfg
Commit 2f7b1d8b5505 ("clk: mediatek: Do a runtime PM get on controllers
during probe") enabled runtime PM for all mediatek clock controllers,
but this introduced an issue on the resume path.
If a device resumes earlier than the clock controller and calls
clk_prepare() when runtime PM is enabled on the controller, it will end
up calling clk_pm_runtime_get(). But the subsequent
pm_runtime_resume_and_get() call will fail because the runtime PM is
temporarily disabled during suspend.
To workaround this, introduce a need_runtime_pm flag and only enable it
on mt8183-mfgcfg, which is the driver that observed deadlock previously.
Hopefully mt8183-cfgcfg won't run into the issue at the resume stage
because the GPU should have stopped rendering before the system calls
suspend.
Fixes: 2f7b1d8b5505 ("clk: mediatek: Do a runtime PM get on controllers during probe")
Signed-off-by: Pin-yen Lin <treapking@chromium.org>
Link: https://lore.kernel.org/r/20240613120357.1043342-1-treapking@chromium.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Diffstat (limited to 'sound/soc/codecs/wcd934x.c')
0 files changed, 0 insertions, 0 deletions