From: Konrad Dybcio <[email protected]> There's a small window where the MDP clock could be set to a high rate (say, from the bootloader) without a corresponding RPM(H)PD vote to back it up. This is normally not an issue, but could be, if rmmod fails to shut down the display driver cleanly, and the module is inserted again, or when the providers' .sync_state has timed out.
Mark a TODO to fix it one day. Linking the relevant discussion below. Link: https://lore.kernel.org/linux-arm-msm/[email protected]/ Signed-off-by: Konrad Dybcio <[email protected]> --- drivers/gpu/drm/msm/msm_mdss.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c index 9047e8d9ee89..b783dfec83b8 100644 --- a/drivers/gpu/drm/msm/msm_mdss.c +++ b/drivers/gpu/drm/msm/msm_mdss.c @@ -262,6 +262,14 @@ static int msm_mdss_enable(struct msm_mdss *msm_mdss) icc_set_bw(msm_mdss->reg_bus_path, 0, msm_mdss->reg_bus_bw); + /* + * TODO: + * Previous users (e.g. the bootloader) may have left this clock at a high rate, which + * would remain set, as prepare_enable() doesn't reprogram it. This theoretically poses a + * risk of brownout, but realistically this path is almost exclusively excercised after the + * correct OPP has been set in one of the MDPn or DPU drivers, or during initial probe, + * before the RPM(H)PD sync_state is done. + */ ret = clk_bulk_prepare_enable(msm_mdss->num_clocks, msm_mdss->clocks); if (ret) { dev_err(msm_mdss->dev, "clock enable failed, ret:%d\n", ret); --- base-commit: fc7b1a72c6cd5cbbd989c6c32a6486e3e4e3594d change-id: 20260310-topic-mdss_power_todo-4a19cf5f5183 Best regards, -- Konrad Dybcio <[email protected]>
