summaryrefslogtreecommitdiff
path: root/rust/helpers/vmalloc.c
diff options
context:
space:
mode:
authorKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>2025-09-08 11:49:51 +0200
committerDmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>2025-09-09 17:24:25 +0300
commitcb55f39bf7b1e687b88dc9825c21a7d3454b5acb (patch)
tree36167ae81b12f942f89856ce9479dc24f05e1e43 /rust/helpers/vmalloc.c
parent6341516bc25cef7dff078132905a792790303d59 (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