]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
drm/msm/dsi/phy: Fix reading zero as PLL rates when unprepared
authorKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Mon, 8 Sep 2025 09:49:51 +0000 (11:49 +0200)
committerDmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Tue, 9 Sep 2025 14:24:25 +0000 (17:24 +0300)
commitcb55f39bf7b1e687b88dc9825c21a7d3454b5acb
tree36167ae81b12f942f89856ce9479dc24f05e1e43
parent6341516bc25cef7dff078132905a792790303d59
drm/msm/dsi/phy: Fix reading zero as PLL rates when unprepared

Hardware Programming Guide for DSI PHY says that PLL_SHUTDOWNB and
DIGTOP_PWRDN_B have to be asserted for any PLL register access.
Whenever dsi_pll_7nm_vco_recalc_rate() or dsi_pll_7nm_vco_set_rate()
were called on unprepared PLL, driver read values of zero leading to all
sort of further troubles, like failing to set pixel and byte clock
rates.

Asserting the PLL shutdown bit is done by dsi_pll_enable_pll_bias() (and
corresponding dsi_pll_disable_pll_bias()) which are called through the
code, including from PLL .prepare() and .unprepare() callbacks.

The .set_rate() and .recalc_rate() can be called almost anytime from
external users including times when PLL is or is not prepared, thus
driver should not interfere with the prepare status.

Implement simple reference counting for the PLL bias, so
set_rate/recalc_rate will not change the status of prepared PLL.

Issue of reading 0 in .recalc_rate() did not show up on existing
devices, but only after re-ordering the code for SM8750.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/673416/
Link: https://lore.kernel.org/r/20250908094950.72877-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c