On Tue, Mar 10, 2026 at 02:20:25PM +0100, Konrad Dybcio wrote: > 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. > + */
I'd have preferred if it was not exercising 100-char limit, but there is no reason to enforce that. Reviewed-by: Dmitry Baryshkov <[email protected]> > 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]> > -- With best wishes Dmitry
