[PATCH 0/2] drm/msm/dpu: improve LM allocation

[PATCH 0/2] drm/msm/dpu: improve LM allocation

[Dmitry Baryshkov]

Not all Line Mixers have corresponding DSPP blocks, which are necessary
for CTM or Gamma Correction. Currently it is possible for CTM-less CRTCs
to get a grip of DSPP-enabled LMs, making it impossible to use CTM (or
GC, once enabled) for other CRTCs. Make sure that RM allocates simpler
LMs first, leaving LMs with attached DSPP for the CRTCs which need them.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
Dmitry Baryshkov (2):
      drm/msm/dpu: correct error messages in RM
      drm/msm/dpu: try reserving the DSPP-less LM first

 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 72 ++++++++++++++++++++++------------
 1 file changed, 47 insertions(+), 25 deletions(-)
---
base-commit: b775e489bec70895b7ef6b66927886bbac79598f
change-id: 20260115-dpu-fix-dspp-803dee634153

Best regards,
-- 
With best wishes
Dmitry

[PATCH 1/2] drm/msm/dpu: correct error messages in RM

[Dmitry Baryshkov]

Some of error messages in RM reference block index, while other print
the enum value (which is shifted by 1), not to mention that some of the
messages are misleading. Reformat the messages, making them more clear
and also always printing the hardware block name.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 22 ++++++++++------------
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index f6568ed8375f..7e77d88f8959 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -315,20 +315,19 @@ static bool _dpu_rm_check_lm_and_get_connected_blks(struct dpu_rm *rm,
 
 	/* Already reserved? */
 	if (reserved_by_other(global_state->mixer_to_crtc_id, lm_idx, crtc_id)) {
-		DPU_DEBUG("lm %d already reserved\n", lm_idx + LM_0);
+		DPU_DEBUG("LM_%d already reserved\n", lm_idx);
 		return false;
 	}
 
 	lm_cfg = to_dpu_hw_mixer(rm->mixer_blks[lm_idx])->cap;
 	idx = lm_cfg->pingpong - PINGPONG_0;
-	if (idx < 0 || idx >= ARRAY_SIZE(rm->pingpong_blks)) {
-		DPU_ERROR("failed to get pp on lm %d\n", lm_cfg->pingpong);
+	if (idx < 0 || idx >= ARRAY_SIZE(rm->pingpong_blks) || !rm->pingpong_blks[idx]) {
+		DPU_ERROR("LM_%d, invalid PP_%d\n", lm_idx, idx);
 		return false;
 	}
 
 	if (reserved_by_other(global_state->pingpong_to_crtc_id, idx, crtc_id)) {
-		DPU_DEBUG("lm %d pp %d already reserved\n", lm_cfg->id,
-				lm_cfg->pingpong);
+		DPU_DEBUG("LM_%d PP_%d already reserved\n", lm_idx, idx);
 		return false;
 	}
 	*pp_idx = idx;
@@ -337,14 +336,13 @@ static bool _dpu_rm_check_lm_and_get_connected_blks(struct dpu_rm *rm,
 		return true;
 
 	idx = lm_cfg->dspp - DSPP_0;
-	if (idx < 0 || idx >= ARRAY_SIZE(rm->dspp_blks)) {
-		DPU_ERROR("failed to get dspp on lm %d\n", lm_cfg->dspp);
+	if (idx < 0 || idx >= ARRAY_SIZE(rm->dspp_blks) || !rm->dspp_blks[idx]) {
+		DPU_ERROR("LM_%d, invalid DSPP_%d\n", lm_idx, idx);
 		return false;
 	}
 
 	if (reserved_by_other(global_state->dspp_to_crtc_id, idx, crtc_id)) {
-		DPU_DEBUG("lm %d dspp %d already reserved\n", lm_cfg->id,
-				lm_cfg->dspp);
+		DPU_DEBUG("LM_%d DSPP_%d already reserved\n", lm_idx, idx);
 		return false;
 	}
 	*dspp_idx = idx;
@@ -364,7 +362,7 @@ static int _dpu_rm_reserve_lms(struct dpu_rm *rm,
 	int i, lm_count = 0;
 
 	if (!topology->num_lm) {
-		DPU_ERROR("invalid number of lm: %d\n", topology->num_lm);
+		DPU_ERROR("zero LMs in topology\n");
 		return -EINVAL;
 	}
 
@@ -468,13 +466,13 @@ static int _dpu_rm_reserve_ctls(
 		features = ctl->caps->features;
 		has_split_display = BIT(DPU_CTL_SPLIT_DISPLAY) & features;
 
-		DPU_DEBUG("ctl %d caps 0x%lX\n", j + CTL_0, features);
+		DPU_DEBUG("CTL_%d caps 0x%lX\n", j, features);
 
 		if (needs_split_display != has_split_display)
 			continue;
 
 		ctl_idx[i] = j;
-		DPU_DEBUG("ctl %d match\n", j + CTL_0);
+		DPU_DEBUG("CTL_%d match\n", j);
 
 		if (++i == num_ctls)
 			break;

-- 
2.47.3

[PATCH 2/2] drm/msm/dpu: try reserving the DSPP-less LM first

[Dmitry Baryshkov]

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

Re: [PATCH 1/2] drm/msm/dpu: correct error messages in RM

[Konrad Dybcio]

On 1/15/26 9:05 PM, Dmitry Baryshkov wrote:
> Some of error messages in RM reference block index, while other print
> the enum value (which is shifted by 1), not to mention that some of the
> messages are misleading. Reformat the messages, making them more clear
> and also always printing the hardware block name.
> 
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

Re: [PATCH 2/2] drm/msm/dpu: try reserving the DSPP-less LM first

[Konrad Dybcio]

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

Re: [PATCH 0/2] drm/msm/dpu: improve LM allocation

[Dmitry Baryshkov]

On Thu, 15 Jan 2026 22:05:37 +0200, Dmitry Baryshkov wrote:
> Not all Line Mixers have corresponding DSPP blocks, which are necessary
> for CTM or Gamma Correction. Currently it is possible for CTM-less CRTCs
> to get a grip of DSPP-enabled LMs, making it impossible to use CTM (or
> GC, once enabled) for other CRTCs. Make sure that RM allocates simpler
> LMs first, leaving LMs with attached DSPP for the CRTCs which need them.
> 
> 
> [...]

Applied to msm-next, thanks!

[1/2] drm/msm/dpu: correct error messages in RM
      https://gitlab.freedesktop.org/lumag/msm/-/commit/98c8f146f574
[2/2] drm/msm/dpu: try reserving the DSPP-less LM first
      https://gitlab.freedesktop.org/lumag/msm/-/commit/42f62cd79578

Best regards,
-- 
With best wishes
Dmitry

Re: [PATCH 2/2] drm/msm/dpu: try reserving the DSPP-less LM first

[Val Packett]

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.

/sys/kernel/debug/dri..: https://owo.packett.cool/dbg/bluewtf.dri


~val

Re: [PATCH 2/2] drm/msm/dpu: try reserving the DSPP-less LM first

[Dmitry Baryshkov]

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

Re: [PATCH 2/2] drm/msm/dpu: try reserving the DSPP-less LM first

[Val Packett]

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

Re: [PATCH 2/2] drm/msm/dpu: try reserving the DSPP-less LM first

[Dmitry Baryshkov]

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