diff options
author | Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> | 2025-09-08 11:49:51 +0200 |
---|---|---|
committer | Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> | 2025-09-09 17:24:25 +0300 |
commit | cb55f39bf7b1e687b88dc9825c21a7d3454b5acb (patch) | |
tree | 36167ae81b12f942f89856ce9479dc24f05e1e43 /rust/helpers/vmalloc.c | |
parent | 6341516bc25cef7dff078132905a792790303d59 (diff) |
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>
Diffstat (limited to 'rust/helpers/vmalloc.c')
0 files changed, 0 insertions, 0 deletions