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@xxxxxxxxxxxxxxxx>
> > > > > > ---
> > > > > >  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