summaryrefslogtreecommitdiffstats
path: root/arch/s390/lib
diff options
context:
space:
mode:
authorPin-yen Lin <treapking@chromium.org>2024-06-13 20:02:28 +0800
committerStephen Boyd <sboyd@kernel.org>2024-07-01 13:49:07 -0700
commit878e845d8db04df9ff3bbbaac09d335b24153704 (patch)
tree202947b4048abf387f9fd83cd8dd0d054535050b /arch/s390/lib
parentf7275fdf945cc91217dfba75d8c9e984c1dab05c (diff)
downloadlinux-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 'arch/s390/lib')
0 files changed, 0 insertions, 0 deletions