[PATCH] drm/msm/disp/dpu: consider SSPP line width during mode valid

[PATCH] drm/msm/disp/dpu: consider SSPP line width during mode valid

[Vishnu Saini]

Few targets have lesser SSPP line width compared to mixer width,
SSPP line width also needs to be considered during mode valid
to avoid failures during atomic_check.

Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 6bf7c46379ae..af245c44959d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1591,6 +1591,7 @@ static enum drm_mode_status dpu_crtc_mode_valid(struct drm_crtc *crtc,
 {
 	struct dpu_kms *dpu_kms = _dpu_crtc_get_kms(crtc);
 	u64 adjusted_mode_clk;
+	u32 max_width;
 
 	/* if there is no 3d_mux block we cannot merge LMs so we cannot
 	 * split the large layer into 2 LMs, filter out such modes
@@ -1613,11 +1614,14 @@ static enum drm_mode_status dpu_crtc_mode_valid(struct drm_crtc *crtc,
 		return MODE_CLOCK_HIGH;
 
 	/*
-	 * max crtc width is equal to the max mixer width * 2 and max height is 4K
+	 * max crtc width is equal to the min of max mixer width * 2 and max sspp line width * 2
+	 * max height is 4K
 	 */
-	return drm_mode_validate_size(mode,
-				      2 * dpu_kms->catalog->caps->max_mixer_width,
-				      4096);
+	max_width = 2 * min_t(u32,
+			      dpu_kms->catalog->caps->max_mixer_width,
+			      dpu_kms->catalog->caps->max_linewidth);
+
+	return drm_mode_validate_size(mode, max_width, 4096);
 }
 
 /**

---
base-commit: 6efced27f5df9d7a57e4847fe2898cdd19f72311
change-id: 20260328-msm-next-70eb896ff64d

Best regards,
-- 
Vishnu Saini <vishnu.saini@oss.qualcomm.com>

Re: [PATCH] drm/msm/disp/dpu: consider SSPP line width during mode valid

[Dmitry Baryshkov]

On Sat, Mar 28, 2026 at 10:45:35PM +0530, Vishnu Saini wrote:
> Few targets have lesser SSPP line width compared to mixer width,
> SSPP line width also needs to be considered during mode valid
> to avoid failures during atomic_check.

Technically this is not correct. There is no requirement for the
planes to cover the whole CRTC. Nor is there a requirement to use only 2
rectangles to cover the screen. As such, it is perfectly fine in
mode_valid, if CRTC is wider than 2x max_linewidth. It would be an error
if the user tries to stretch 2 rectangles in such a case.

> 
> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 12 ++++++++----
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 

-- 
With best wishes
Dmitry

Re: [PATCH] drm/msm/disp/dpu: consider SSPP line width during mode valid

[Vishnu Saini]

On Sun, Mar 29, 2026 at 02:24:53AM +0200, Dmitry Baryshkov wrote:
> On Sat, Mar 28, 2026 at 10:45:35PM +0530, Vishnu Saini wrote:
> > Few targets have lesser SSPP line width compared to mixer width,
> > SSPP line width also needs to be considered during mode valid
> > to avoid failures during atomic_check.
> 
> Technically this is not correct. There is no requirement for the
> planes to cover the whole CRTC. Nor is there a requirement to use only 2
> rectangles to cover the screen. As such, it is perfectly fine in
> mode_valid, if CRTC is wider than 2x max_linewidth. It would be an error
> if the user tries to stretch 2 rectangles in such a case.

This is to fix an issue with 5k monitor on rb3gen2, since SSPP maxlinewidth is 2400
it can't cover the whole 5k buffer in left right split mode.
Do we need to fix it from drm backend by dividing 5k buffer into 2 planes and 
use 2 pipes in split mode.
4 SSPP rects --> 2 LMs --> 3d_mux --> DP
 
> > 
> > Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
> > ---
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 12 ++++++++----
> >  1 file changed, 8 insertions(+), 4 deletions(-)
> > 
> 
> -- 
> With best wishes
> Dmitry

Re: [PATCH] drm/msm/disp/dpu: consider SSPP line width during mode valid

[Dmitry Baryshkov]

On Tue, Mar 31, 2026 at 12:00:07AM +0530, Vishnu Saini wrote:
> On Sun, Mar 29, 2026 at 02:24:53AM +0200, Dmitry Baryshkov wrote:
> > On Sat, Mar 28, 2026 at 10:45:35PM +0530, Vishnu Saini wrote:
> > > Few targets have lesser SSPP line width compared to mixer width,
> > > SSPP line width also needs to be considered during mode valid
> > > to avoid failures during atomic_check.
> > 
> > Technically this is not correct. There is no requirement for the
> > planes to cover the whole CRTC. Nor is there a requirement to use only 2
> > rectangles to cover the screen. As such, it is perfectly fine in
> > mode_valid, if CRTC is wider than 2x max_linewidth. It would be an error
> > if the user tries to stretch 2 rectangles in such a case.
> 
> This is to fix an issue with 5k monitor on rb3gen2, since SSPP maxlinewidth is 2400
> it can't cover the whole 5k buffer in left right split mode.
> Do we need to fix it from drm backend by dividing 5k buffer into 2 planes and 
> use 2 pipes in split mode.

Quad pipe is pending for 7.2, most likely. However, I think, instead you
should teach compositor that if the commit fails, it should retry with
the lower resolution (it might require somethi g like -E2BIG from te
commit).

> 4 SSPP rects --> 2 LMs --> 3d_mux --> DP
>  
> > > 
> > > Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
> > > ---
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 12 ++++++++----
> > >  1 file changed, 8 insertions(+), 4 deletions(-)
> > > 
> > 
> > -- 
> > With best wishes
> > Dmitry

-- 
With best wishes
Dmitry

Re: [PATCH] drm/msm/disp/dpu: consider SSPP line width during mode valid

[Vishnu Saini]

On Mon, Mar 30, 2026 at 09:39:31PM +0300, Dmitry Baryshkov wrote:
> On Tue, Mar 31, 2026 at 12:00:07AM +0530, Vishnu Saini wrote:
> > On Sun, Mar 29, 2026 at 02:24:53AM +0200, Dmitry Baryshkov wrote:
> > > On Sat, Mar 28, 2026 at 10:45:35PM +0530, Vishnu Saini wrote:
> > > > Few targets have lesser SSPP line width compared to mixer width,
> > > > SSPP line width also needs to be considered during mode valid
> > > > to avoid failures during atomic_check.
> > > 
> > > Technically this is not correct. There is no requirement for the
> > > planes to cover the whole CRTC. Nor is there a requirement to use only 2
> > > rectangles to cover the screen. As such, it is perfectly fine in
> > > mode_valid, if CRTC is wider than 2x max_linewidth. It would be an error
> > > if the user tries to stretch 2 rectangles in such a case.
> > 
> > This is to fix an issue with 5k monitor on rb3gen2, since SSPP maxlinewidth is 2400
> > it can't cover the whole 5k buffer in left right split mode.
> > Do we need to fix it from drm backend by dividing 5k buffer into 2 planes and 
> > use 2 pipes in split mode.
> 
> Quad pipe is pending for 7.2, most likely. However, I think, instead you
> should teach compositor that if the commit fails, it should retry with
> the lower resolution (it might require somethi g like -E2BIG from te
> commit).
Yes, from driver we are returning "-E2BIG" during atomic_check.
Thank you for the clarity, will try to fix it from compositor.
 
> > 4 SSPP rects --> 2 LMs --> 3d_mux --> DP
> >  
> > > > 
> > > > Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
> > > > ---
> > > >  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 12 ++++++++----
> > > >  1 file changed, 8 insertions(+), 4 deletions(-)
> > > > 
> > > 
> > > -- 
> > > With best wishes
> > > Dmitry
> 
> -- 
> With best wishes
> Dmitry

Re: [PATCH] drm/msm/disp/dpu: consider SSPP line width during mode valid

[Dmitry Baryshkov]

On Tue, Mar 31, 2026 at 12:27:19AM +0530, Vishnu Saini wrote:
> On Mon, Mar 30, 2026 at 09:39:31PM +0300, Dmitry Baryshkov wrote:
> > On Tue, Mar 31, 2026 at 12:00:07AM +0530, Vishnu Saini wrote:
> > > On Sun, Mar 29, 2026 at 02:24:53AM +0200, Dmitry Baryshkov wrote:
> > > > On Sat, Mar 28, 2026 at 10:45:35PM +0530, Vishnu Saini wrote:
> > > > > Few targets have lesser SSPP line width compared to mixer width,
> > > > > SSPP line width also needs to be considered during mode valid
> > > > > to avoid failures during atomic_check.
> > > > 
> > > > Technically this is not correct. There is no requirement for the
> > > > planes to cover the whole CRTC. Nor is there a requirement to use only 2
> > > > rectangles to cover the screen. As such, it is perfectly fine in
> > > > mode_valid, if CRTC is wider than 2x max_linewidth. It would be an error
> > > > if the user tries to stretch 2 rectangles in such a case.
> > > 
> > > This is to fix an issue with 5k monitor on rb3gen2, since SSPP maxlinewidth is 2400
> > > it can't cover the whole 5k buffer in left right split mode.
> > > Do we need to fix it from drm backend by dividing 5k buffer into 2 planes and 
> > > use 2 pipes in split mode.
> > 
> > Quad pipe is pending for 7.2, most likely. However, I think, instead you
> > should teach compositor that if the commit fails, it should retry with
> > the lower resolution (it might require somethi g like -E2BIG from te
> > commit).
> Yes, from driver we are returning "-E2BIG" during atomic_check.
> Thank you for the clarity, will try to fix it from compositor.

Just to point out: it's not different from the driver not being able to
perform the atomic commit for any other reason. For example, if card has
3 outputs but can support only 2 concurrent outputs, then each connector
will still have a list of valid modes, but trying to enable outputs on
all three of them would still fail (or trying to enable high-enough
resolution on all three, if that removes a possible question of limiting
number of outputs by other means).

>  
> > > 4 SSPP rects --> 2 LMs --> 3d_mux --> DP
> > >  
> > > > > 
> > > > > Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
> > > > > ---
> > > > >  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 12 ++++++++----
> > > > >  1 file changed, 8 insertions(+), 4 deletions(-)
> > > > > 
> > > > 
> > > > -- 
> > > > With best wishes
> > > > Dmitry
> > 
> > -- 
> > With best wishes
> > Dmitry

-- 
With best wishes
Dmitry

Re: [PATCH] drm/msm/disp/dpu: consider SSPP line width during mode valid

[Vishnu Saini]

On Mon, Mar 30, 2026 at 10:38:15PM +0300, Dmitry Baryshkov wrote:
> On Tue, Mar 31, 2026 at 12:27:19AM +0530, Vishnu Saini wrote:
> > On Mon, Mar 30, 2026 at 09:39:31PM +0300, Dmitry Baryshkov wrote:
> > > On Tue, Mar 31, 2026 at 12:00:07AM +0530, Vishnu Saini wrote:
> > > > On Sun, Mar 29, 2026 at 02:24:53AM +0200, Dmitry Baryshkov wrote:
> > > > > On Sat, Mar 28, 2026 at 10:45:35PM +0530, Vishnu Saini wrote:
> > > > > > Few targets have lesser SSPP line width compared to mixer width,
> > > > > > SSPP line width also needs to be considered during mode valid
> > > > > > to avoid failures during atomic_check.
> > > > > 
> > > > > Technically this is not correct. There is no requirement for the
> > > > > planes to cover the whole CRTC. Nor is there a requirement to use only 2
> > > > > rectangles to cover the screen. As such, it is perfectly fine in
> > > > > mode_valid, if CRTC is wider than 2x max_linewidth. It would be an error
> > > > > if the user tries to stretch 2 rectangles in such a case.
> > > > 
> > > > This is to fix an issue with 5k monitor on rb3gen2, since SSPP maxlinewidth is 2400
> > > > it can't cover the whole 5k buffer in left right split mode.
> > > > Do we need to fix it from drm backend by dividing 5k buffer into 2 planes and 
> > > > use 2 pipes in split mode.
> > > 
> > > Quad pipe is pending for 7.2, most likely. However, I think, instead you
> > > should teach compositor that if the commit fails, it should retry with
> > > the lower resolution (it might require somethi g like -E2BIG from te
> > > commit).
> > Yes, from driver we are returning "-E2BIG" during atomic_check.
> > Thank you for the clarity, will try to fix it from compositor.
> 
> Just to point out: it's not different from the driver not being able to
> perform the atomic commit for any other reason. For example, if card has
> 3 outputs but can support only 2 concurrent outputs, then each connector
> will still have a list of valid modes, but trying to enable outputs on
> all three of them would still fail (or trying to enable high-enough
> resolution on all three, if that removes a possible question of limiting
> number of outputs by other means).

Thanks for pointing this out. Agreed, this is consistent with other atomic
commit failure scenarios caused by resource limits.
The compositor team is looking into this from their end.
 
> >  
> > > > 4 SSPP rects --> 2 LMs --> 3d_mux --> DP
> > > >  
> > > > > > 
> > > > > > Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
> > > > > > ---
> > > > > >  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 12 ++++++++----
> > > > > >  1 file changed, 8 insertions(+), 4 deletions(-)
> > > > > > 
> > > > > 
> > > > > -- 
> > > > > With best wishes
> > > > > Dmitry
> > > 
> > > -- 
> > > With best wishes
> > > Dmitry
> 
> -- 
> With best wishes
> Dmitry