On Mon, Jul 06, 2026 at 11:07:53AM -0700, Kavan Smith wrote: > msm_dsi_host_xfer_prepare() runs for every DSI command, including runtime > DCS writes such as backlight (MIPI DCS 0x51), and unconditionally calls > link_clk_set_rate() before enabling the link clocks. On MSM8916 (DSI 6G > v1.3.1) the requested byte-clock rate never exactly equals the DSI PHY > PLL's achievable rate (e.g. 56250000 Hz requested vs 56246337 Hz from the > PLL), so the clk framework treats every call as a rate change and re-locks > the PLL. > > During video-mode operation the byte, pixel and byte-intf clocks are > already running and feeding continuous scanout. Re-locking the PLL glitches > that live clock. On a video-mode panel with no internal timing generator > (e.g. samsung,s6d7aa0 / lsl080al03 on the Samsung Galaxy Tab A 8.0, which > regenerates its H/V timing directly from the DSI clock lane) the glitch > makes the panel lose pixel lock, producing ~1 second of displaced/wrapped > scanout on every DCS command. No FIFO underrun or dsi_err_worker error > fires; it is a silent clock-domain glitch. Stock (downstream MDSS) firmware > sends the same 0x51 with CMD_CLK_CTRL, which only refcount-enables the > clocks and never re-runs clk_set_rate, and does not glitch. > > The link rate is already programmed at power-on by msm_dsi_host_power_on(), > so skip the redundant re-set once the link is up; init-time transfers > (before power_on) still set the rate.
THe problem is that by definition the transfer callbacks can be sent at any time, see the comment at mipi_dsi_host_ops. I think the proper fix would be to call clk_round_rate() beforehand, making the CCF skip all further rate sets. > > Link: https://lists.freedesktop.org/archives/dri-devel/2018-April/172218.html This should be Reported-by / Closes. Also probably add Fixes and cc:stable. > Signed-off-by: Kavan Smith <[email protected]> > --- > drivers/gpu/drm/msm/dsi/dsi_host.c | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) > -- With best wishes Dmitry
