On most of the platforms only some mixers have connected DSPP blocks.
If DSPP is not required for the CRTC, try looking for the LM with no
DSSP block, leaving DSPP-enabled LMs to CRTCs which actually require
those.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 52 +++++++++++++++++++++++++---------
1 file changed, 38 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 7e77d88f8959..451a4fcf3e65 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -350,28 +350,26 @@ static bool _dpu_rm_check_lm_and_get_connected_blks(struct dpu_rm *rm,
return true;
}
-static int _dpu_rm_reserve_lms(struct dpu_rm *rm,
- struct dpu_global_state *global_state,
- uint32_t crtc_id,
- struct msm_display_topology *topology)
+static bool dpu_rm_find_lms(struct dpu_rm *rm,
+ struct dpu_global_state *global_state,
+ uint32_t crtc_id, bool skip_dspp,
+ struct msm_display_topology *topology,
+ int *lm_idx, int *pp_idx, int *dspp_idx)
{
- int lm_idx[MAX_BLOCKS];
- int pp_idx[MAX_BLOCKS];
- int dspp_idx[MAX_BLOCKS] = {0};
int i, lm_count = 0;
- if (!topology->num_lm) {
- DPU_ERROR("zero LMs in topology\n");
- return -EINVAL;
- }
-
/* Find a primary mixer */
for (i = 0; i < ARRAY_SIZE(rm->mixer_blks) &&
lm_count < topology->num_lm; i++) {
if (!rm->mixer_blks[i])
continue;
+ if (skip_dspp && to_dpu_hw_mixer(rm->mixer_blks[i])->cap->dspp) {
+ DPU_DEBUG("Skipping LM_%d, skipping LMs with DSPPs\n", i);
+ continue;
+ }
+
/*
* Reset lm_count to an even index. This will drop the previous
* primary mixer if failed to find its peer.
@@ -410,12 +408,38 @@ static int _dpu_rm_reserve_lms(struct dpu_rm *rm,
}
}
- if (lm_count != topology->num_lm) {
+ return lm_count == topology->num_lm;
+}
+
+static int _dpu_rm_reserve_lms(struct dpu_rm *rm,
+ struct dpu_global_state *global_state,
+ uint32_t crtc_id,
+ struct msm_display_topology *topology)
+
+{
+ int lm_idx[MAX_BLOCKS];
+ int pp_idx[MAX_BLOCKS];
+ int dspp_idx[MAX_BLOCKS] = {0};
+ int i;
+ bool found;
+
+ if (!topology->num_lm) {
+ DPU_ERROR("zero LMs in topology\n");
+ return -EINVAL;
+ }
+
+ /* Try using non-DSPP LM blocks first */
+ found = dpu_rm_find_lms(rm, global_state, crtc_id, !topology->num_dspp,
+ topology, lm_idx, pp_idx, dspp_idx);
+ if (!found && !topology->num_dspp)
+ found = dpu_rm_find_lms(rm, global_state, crtc_id, false,
+ topology, lm_idx, pp_idx, dspp_idx);
+ if (!found) {
DPU_DEBUG("unable to find appropriate mixers\n");
return -ENAVAIL;
}
- for (i = 0; i < lm_count; i++) {
+ for (i = 0; i < topology->num_lm; i++) {
global_state->mixer_to_crtc_id[lm_idx[i]] = crtc_id;
global_state->pingpong_to_crtc_id[pp_idx[i]] = crtc_id;
global_state->dspp_to_crtc_id[dspp_idx[i]] =
--
2.47.3Hi, On 1/15/26 5:05 PM, Dmitry Baryshkov wrote: > On most of the platforms only some mixers have connected DSPP blocks. > If DSPP is not required for the CRTC, try looking for the LM with no > DSSP block, leaving DSPP-enabled LMs to CRTCs which actually require > those. > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 52 +++++++++++++++++++++++++--------- > 1 file changed, 38 insertions(+), 14 deletions(-) this has massively broken things on my x1e device (latitude-7455): - upon booting into gdm, the internal display is all dark blue - suspend-resume makes gdm appear fine, then logging in results in another blue screen, again bypassed by suspend-resume (vt switching back to gdm makes it appear fine but switching back to the session, it's still blue) - OR blindly logging in on the blue gdm makes the session appear - plugging in an external display makes the blue screen flash constantly over the contents, there is also a flashing vertical gap between 2 halves of the internal screen (amazing effect) and the external display doesn't actually refresh the contents under the blue (https://owo.packett.cool/dbg/dspp-lm-boom.webm) Consistently across 3 reboots. Reverted only this commit and it's back to normal, so I'm pretty sure it's this. /sys/kernel/debug/dri..: https://owo.packett.cool/dbg/bluewtf.dri ~val
On Tue, Jan 27, 2026 at 06:43:32AM -0300, Val Packett wrote: > Hi, > > On 1/15/26 5:05 PM, Dmitry Baryshkov wrote: > > On most of the platforms only some mixers have connected DSPP blocks. > > If DSPP is not required for the CRTC, try looking for the LM with no > > DSSP block, leaving DSPP-enabled LMs to CRTCs which actually require > > those. > > > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> > > --- > > drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 52 +++++++++++++++++++++++++--------- > > 1 file changed, 38 insertions(+), 14 deletions(-) > > > this has massively broken things on my x1e device (latitude-7455): > > - upon booting into gdm, the internal display is all dark blue > - suspend-resume makes gdm appear fine, then logging in results in another > blue screen, again bypassed by suspend-resume (vt switching back to gdm > makes it appear fine but switching back to the session, it's still blue) > - OR blindly logging in on the blue gdm makes the session appear > - plugging in an external display makes the blue screen flash constantly > over the contents, there is also a flashing vertical gap between 2 halves of > the internal screen (amazing effect) and the external display doesn't > actually refresh the contents under the blue > (https://owo.packett.cool/dbg/dspp-lm-boom.webm) > > Consistently across 3 reboots. > > Reverted only this commit and it's back to normal, so I'm pretty sure it's > this. Interesting. Could you please capture the dri-state (only the last part, resource mapping) with the external monitor attached and with this commit reverted? Also, could you please run another check: - revert this commit - comment out LM_2, LM_3 in the catalog - try the resulting kernel with the external monitor > > /sys/kernel/debug/dri..: https://owo.packett.cool/dbg/bluewtf.dri > > > ~val > -- With best wishes Dmitry
On 1/27/26 7:34 AM, Dmitry Baryshkov wrote: > On Tue, Jan 27, 2026 at 06:43:32AM -0300, Val Packett wrote: >> this has massively broken things on my x1e device (latitude-7455): >> [..] >> Reverted only this commit and it's back to normal, so I'm pretty sure it's >> this. > Interesting. Could you please capture the dri-state (only the last part, > resource mapping) with the external monitor attached and with this > commit reverted? Just reverted: crtc[106]: crtc-0 [..] mode: "2560x1600": 60 280710 2560 2608 2640 2720 1600 1603 1609 1720 0x48 0x9 lm[0]=0 ctl[0]=0 dspp[0]=0 lm[1]=1 ctl[1]=0 dspp[1]=1 crtc[107]: crtc-1 [..] mode: "3840x2560": 60 631750 3840 3888 3920 4000 2560 2563 2573 2633 0x48 0x9 lm[0]=2 ctl[0]=1 lm[1]=3 ctl[1]=1 resource mapping: pingpong=106 106 107 107 # # - - # # - - - mixer=106 106 107 107 # # - - ctl=106 107 # # # # - - dspp=# # # # - - - - dsc=# # # # - - - - cdm=# sspp=# # # # - - - - # # # # # # - - cwb=- - - - > Also, could you please run another check: > - revert this commit > - comment out LM_2, LM_3 in the catalog > - try the resulting kernel with the external monitor Commented out: crtc[106]: crtc-0 [..] mode: "2560x1600": 60 280710 2560 2608 2640 2720 1600 1603 1609 1720 0x48 0x9 lm[0]=0 ctl[0]=0 dspp[0]=0 lm[1]=1 ctl[1]=0 dspp[1]=1 crtc[107]: crtc-1 [..] mode: "3840x2560": 60 631750 3840 3888 3920 4000 2560 2563 2573 2633 0x48 0x9 lm[0]=4 ctl[0]=1 lm[1]=5 ctl[1]=1 resource mapping: pingpong=106 106 # # 107 107 - - # # - - - mixer=106 106 - - 107 107 - - ctl=106 107 # # # # - - dspp=# # # # - - - - dsc=# # # # - - - - cdm=# sspp=# # # # - - - - # # # # # # - - cwb=- - - - Not sure why the dspp= line in resource mapping doesn't show any numbers when a crtc has dspp[0]= and dspp[1]= o.0 But with LM 4+5, gamma control doesn't affect the external monitor. ~val
On Tue, Jan 27, 2026 at 07:59:34AM -0300, Val Packett wrote: > > On 1/27/26 7:34 AM, Dmitry Baryshkov wrote: > > On Tue, Jan 27, 2026 at 06:43:32AM -0300, Val Packett wrote: > > > this has massively broken things on my x1e device (latitude-7455): > > > [..] > > > Reverted only this commit and it's back to normal, so I'm pretty sure it's > > > this. > > Interesting. Could you please capture the dri-state (only the last part, > > resource mapping) with the external monitor attached and with this > > commit reverted? > > Just reverted: > > crtc[106]: crtc-0 [..] > mode: "2560x1600": 60 280710 2560 2608 2640 2720 1600 1603 1609 1720 > 0x48 0x9 > lm[0]=0 > ctl[0]=0 > dspp[0]=0 > lm[1]=1 > ctl[1]=0 > dspp[1]=1 > crtc[107]: crtc-1 [..] > mode: "3840x2560": 60 631750 3840 3888 3920 4000 2560 2563 2573 2633 > 0x48 0x9 > lm[0]=2 > ctl[0]=1 > lm[1]=3 > ctl[1]=1 > resource mapping: pingpong=106 106 107 107 # # - - # # - - - mixer=106 106 > 107 107 # # - - ctl=106 107 # # # # - - dspp=# # # # - - - - dsc=# # # # - - > - - cdm=# sspp=# # # # - - - - # # # # # # - - cwb=- - - - > > > Also, could you please run another check: > > - revert this commit > > - comment out LM_2, LM_3 in the catalog > > - try the resulting kernel with the external monitor > > Commented out: Thanks! I assume external monitor is working fine? > > crtc[106]: crtc-0 [..] > mode: "2560x1600": 60 280710 2560 2608 2640 2720 1600 1603 1609 1720 > 0x48 0x9 > lm[0]=0 > ctl[0]=0 > dspp[0]=0 > lm[1]=1 > ctl[1]=0 > dspp[1]=1 > crtc[107]: crtc-1 [..] > mode: "3840x2560": 60 631750 3840 3888 3920 4000 2560 2563 2573 2633 > 0x48 0x9 > lm[0]=4 > ctl[0]=1 > lm[1]=5 > ctl[1]=1 > resource mapping: > pingpong=106 106 # # 107 107 - - # # - - - > mixer=106 106 - - 107 107 - - > ctl=106 107 # # # # - - > dspp=# # # # - - - - > dsc=# # # # - - - - > cdm=# > sspp=# # # # - - - - # # # # # # - - > cwb=- - - - > > Not sure why the dspp= line in resource mapping doesn't show any numbers > when a crtc has dspp[0]= and dspp[1]= o.0 Ah, it might be confusing. The crtc-N blocks shows that LM in theory has DSPP blocks. Resource mapping shows if the DSPP is actually allocated (aka used for the post processing). > > But with LM 4+5, gamma control doesn't affect the external monitor. Yes, that's expected. > > > ~val > -- With best wishes Dmitry
On 1/15/26 9:05 PM, Dmitry Baryshkov wrote: > On most of the platforms only some mixers have connected DSPP blocks. > If DSPP is not required for the CRTC, try looking for the LM with no > DSSP block, leaving DSPP-enabled LMs to CRTCs which actually require > those. > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> > --- Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Konrad
© 2016 - 2026 Red Hat, Inc.