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

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

[Daniel J Blueman]

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.

Thanks,
  Dan

Link: https://gitlab.freedesktop.org/drm/msm/-/work_items/89
-- 
Daniel J Blueman

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

[Konrad Dybcio]

On 01-Jun-26 07:37, Daniel J Blueman 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.

This is not a very useful reply, but FYI Adreno is the GPU part,
which is wholly separate from the display engine (which we refer
to as DPU)

Konrad

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

[Daniel J Blueman]

On Mon, 1 Jun 2026 at 13:37, Daniel J Blueman <daniel@quora.org> 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

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

[Daniel J Blueman]

On Sun, 14 Jun 2026 at 18:27, Daniel J Blueman <daniel@quora.org> wrote:
> On Mon, 1 Jun 2026 at 13:37, Daniel J Blueman <daniel@quora.org> 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.

Guys, further debug reveals the Windows driver (which doesn't exhibit
the issue) doesn't use the same register access as Linux to reprogram
all LUT entries on DPMS wake. Instead, it appears to submit a DMA
descriptor to fetch LUT values which get internally loaded in a stable
manner.

Is it possible for Qualcomm to attempt a minimal fix, or share the DMA
description struct and doorbell/completion register offsets and
related so the community can?

Also, it would be good to hear if anyone with an X1E running a 7.0
kernel or newer with a 4K monitor *doesn't* see palette corruption
across DPMS sleep-wake, as this could indicate another possible
solution.

Thanks,
  Dan
-- 
Daniel J Blueman

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@quora.org> 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

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

[Daniel J Blueman]

On Sun, 12 Jul 2026 at 19:56, Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
>
> 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@quora.org> 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.

Adjusting like so [1] didn't resolve the issue, however it was worth
ruling out. Perhaps you could check with the Windows driver team why
the DMA descriptor approach was used for LUT setup?

> > 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.

Good tip on ruling this out too!

Thanks,
  Dan

-- [1]

--- a/drivers/gpu/drm/msm/msm_mdss.c
+++ b/drivers/gpu/drm/msm/msm_mdss.c
@@ -22,7 +22,7 @@

 #include <generated/mdss.xml.h>

-#define MIN_IB_BW      400000000UL /* Min ib vote 400MB */
+#define MIN_IB_BW      800000000UL /* Min ib vote 400MB */

 struct msm_mdss_data {
        u32 reg_bus_bw;
@@ -521,7 +521,7 @@ static const struct msm_mdss_data data_76k8 = {
 };

 static const struct msm_mdss_data data_153k6 = {
-       .reg_bus_bw = 153600,
+       .reg_bus_bw = 153600*16,
 };

 static const struct of_device_id mdss_dt_match[] = {
-- 
Daniel J Blueman

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

[Dmitry Baryshkov]

On Sun, 12 Jul 2026 at 15:47, Daniel J Blueman <daniel@quora.org> wrote:
>
> On Sun, 12 Jul 2026 at 19:56, Dmitry Baryshkov
> <dmitry.baryshkov@oss.qualcomm.com> wrote:
> >
> > 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@quora.org> 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.
>
> Adjusting like so [1] didn't resolve the issue, however it was worth
> ruling out. Perhaps you could check with the Windows driver team why
> the DMA descriptor approach was used for LUT setup?

Thanks for the test.

SDE driver also uses LUT DMA, it's just another piece of code that has
not been ported from the downstream.


-- 
With best wishes
Dmitry