Re: [BUG] qcom: x1: GAMMA_LUT corruption on DPMS wake

[Dmitry Baryshkov]

On Sun, Jun 14, 2026 at 06:27:50PM +0800, Daniel J Blueman wrote:
> On Mon, 1 Jun 2026 at 13:37, Daniel J Blueman <daniel@xxxxxxxxx> wrote:
> > Since Adreno X1-85 GAMMA_LUT support was introduced in Linux v7.0 (eg
> > Ubuntu 26.04), when waking from DPMS-off, palette corruption is
> > frequently seen; this manifests as purple banding. If GNOME night
> > light or similar is enabled, the visual impact is greater.
> >
> > Further, on larger panel monitors or laptops eg the Lenovo Yoga Slim
> > 7x (2944x1840), a second INT2 block is used for the right half of the
> > screen, which may remain totally blank on wake; major usability
> > impact.
> >
> > Intuitively, the symptoms feel like the LUT SRAM clock isn't being
> > driven soon enough during the wakeup, thus state loss may depend on
> > silicon binning/variation or related. No such symptom is seen in
> > Windows on the same hardware. I found a workaround supporting this
> > mechanism is to activate the GNOME night light and adjust the slider
> > to update the LUT - any black right half of the screen always
> > reappears.
> >
> > Please can someone with X1-85 Adreno insight check the Linux clock and
> > power domain behaviour around GC_EN, Layer Mixer, INTerFace and INT2
> > on DPMS wake? Happy to test changes; this is a stunning platform
> > otherwise.
> ...
> > Link: https://gitlab.freedesktop.org/drm/msm/-/work_items/89
> 
> Just a heads-up on this with additional findings. Note this issue
> could be the only remaining daily friction on X1 laptops with suspend,
> once my video decode reboot workaround or similar is merged. Also note
> in my case, without GNOME night light active, only a few LUT entries
> render purple so visual artifacts often go unnoticed until a gradient
> eg in an image is visible.

Could you please check if increasing reg_bus_bw in msm_mdss.c would fix
the issue? It's not a proper fix yet, but it might help me to understand
the issue.

> 
> From DPMS wake on a dual-LM panel (>2560 pixels wide) with
> INTF_5/DSPP_0 (master) and INTF_6/DSPP_1, I find DSPP_1's registers
> are intermittently unresponsive just after MDSS resume. DSPP_0 doesn't
> exhibit this issue, suggesting some missing slave/second unit setup,
> despite booting clk_ignore_unused pd_ignore_unused.
> 
> I found the extracted Windows DSDT \_SB.PEP0.G0MD F-state EXIT block
> enables disp_cc_mdss_rscc_ahb_clk and disp_cc_mdss_rscc_vsync_clk;
> could this relate? RSCC being the RPMh bridge subblock. Also, could
> any of the *1_CLK or MDSS_INT2_GDSC entries in dispcc-x1e80100.c lack
> setup?

RSCC should not affect these blocks.

-- 
With best wishes
Dmitry