On Mon, 1 Jun 2026 at 13:37, Daniel J Blueman <[email protected]> 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.
>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?
Does Qualcomm also see this readback failure [1]?
Thanks!
Dan
-- [1]
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
index 23dcbe1ce1b8..xxxxxxxxxxxx 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
@@ -83,7 +83,7 @@ static void dpu_setup_dspp_pcc(struct dpu_hw_dspp *ctx,
static void dpu_setup_dspp_gc(struct dpu_hw_dspp *ctx,
struct dpu_hw_gc_lut *gc_lut)
{
int i = 0;
- u32 base, reg;
+ u32 base, reg, rb;
if (!ctx) {
DRM_ERROR("invalid ctx\n");
@@ -113,4 +113,8 @@ static void dpu_setup_dspp_gc(struct dpu_hw_dspp *ctx,
reg = GC_EN | ((gc_lut->flags & PGC_8B_ROUND) ? GC_8B_ROUND_EN : 0);
DPU_REG_WRITE(&ctx->hw, base, reg);
+
+ rb = DPU_REG_READ(&ctx->hw, base);
+ if (rb != reg)
+ pr_warn("dpu_dspp_gc: dspp %u wrote %08X but read back %08X\n",
+ ctx->idx - DSPP_0, reg, rb);
}
--
Daniel J Blueman
