On Sun, 12 Jul 2026 at 19:56, Dmitry Baryshkov
<[email protected]> 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 <[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.
>
> 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
