linux-kernel - Re: [PATCH v4 10/16] drm/msm/dpu: handle pipes as array

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABymUCPa_k7OriJcDNZmCER9zhK-vk78NaK5HpV8-+Ta+MQQMg@mail.gmail.com>
Date: Thu, 16 Jan 2025 23:36:21 +0800
From: Jun Nie <jun.nie@...aro.org>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: Rob Clark <robdclark@...il.com>, Abhinav Kumar <quic_abhinavk@...cinc.com>, 
	Sean Paul <sean@...rly.run>, Marijn Suijten <marijn.suijten@...ainline.org>, 
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, linux-arm-msm@...r.kernel.org, 
	dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 10/16] drm/msm/dpu: handle pipes as array

Dmitry Baryshkov <dmitry.baryshkov@...aro.org> 于2025年1月16日周四 18:08写道：
>
> On Thu, Jan 16, 2025 at 05:49:43PM +0800, Jun Nie wrote:
> > Dmitry Baryshkov <dmitry.baryshkov@...aro.org> 于2025年1月16日周四 16:00写道：
> > >
> > > On Thu, Jan 16, 2025 at 03:25:59PM +0800, Jun Nie wrote:
> > > > Store pipes in array with removing dedicated r_pipe. There are
> > > > 2 pipes in a drm plane at most currently, while 4 pipes are
> > > > required for quad-pipe case. Generalize the handling to pipe pair
> > > > and ease handling to another pipe pair later.
> > >
> > > With the first sentence being moved to the end of the commit message:
> > >
> > > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
> > >
> > > Minor issues below, please address them in the next version.
> > >
> > > >
> > > > Signed-off-by: Jun Nie <jun.nie@...aro.org>
> > > > ---
> > > >  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |  35 +++----
> > > >  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 167 +++++++++++++++++-------------
> > > >  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h |  12 +--
> > > >  3 files changed, 112 insertions(+), 102 deletions(-)
> > >
> > > > @@ -853,6 +855,9 @@ static int dpu_plane_atomic_check_nosspp(struct drm_plane *plane,
> > > >               return -EINVAL;
> > > >       }
> > > >
> > > > +     /* move the assignment here, to ease handling to another pairs later */
> > >
> > > Is it a TODO comment? It reads like an order.
> > >
> > > > +     pipe_cfg = &pstate->pipe_cfg[0];
> > > > +     r_pipe_cfg = &pstate->pipe_cfg[1];
> > > >       /* state->src is 16.16, src_rect is not */
> > > >       drm_rect_fp_to_int(&pipe_cfg->src_rect, &new_plane_state->src);
> > > >
> > >
> > > > @@ -1387,17 +1394,28 @@ static void _dpu_plane_atomic_disable(struct drm_plane *plane)
> > > >  {
> > > >       struct drm_plane_state *state = plane->state;
> > > >       struct dpu_plane_state *pstate = to_dpu_plane_state(state);
> > > > -     struct dpu_sw_pipe *r_pipe = &pstate->r_pipe;
> > > > +     struct dpu_sw_pipe *pipe;
> > > > +     int i;
> > > >
> > > > -     trace_dpu_plane_disable(DRMID(plane), false,
> > > > -                             pstate->pipe.multirect_mode);
> > > > +     for (i = 0; i < PIPES_PER_STAGE; i += 1) {
> > > > +             pipe = &pstate->pipe[i];
> > > > +             if (!pipe->sspp)
> > > > +                     continue;
> > > >
> > > > -     if (r_pipe->sspp) {
> > > > -             r_pipe->multirect_index = DPU_SSPP_RECT_SOLO;
> > > > -             r_pipe->multirect_mode = DPU_SSPP_MULTIRECT_NONE;
> > > > +             trace_dpu_plane_disable(DRMID(plane), false,
> > > > +                                     pstate->pipe[i].multirect_mode);
> > > >
> > > > -             if (r_pipe->sspp->ops.setup_multirect)
> > > > -                     r_pipe->sspp->ops.setup_multirect(r_pipe);
> > > > +             /*
> > > > +              * clear multirect for the right pipe so that the SSPP
> > > > +              * can be further reused in the solo mode
> > > > +              */
> > > > +             if (pipe->sspp && i == 1) {
> > >
> > > Wouldn't it be better to `&& i % 2 != 0`? Then, I think, this condition
> > > can stay even in quad-pipe case.
> >
> > If all pipes are in solo mode, there is no need to test ' i %2 != 0 '. Below
> > test shall be better, right?
> > if (pipe->sspp && pipe->multirect_index == DPU_SSPP_RECT_1)
>
> Again, this will not work as expected for the SSPP-sharing case as it
> will then clear pipe 0 for the sharing planes.
>
> Let me think a bit... This code resets multirect for right pipes. It was
> added back in 4.9 to fix the case of 'master' aka RECT_0 not being a
> part of the atomic update. However I don't think this is applicable
> anymore. We use z_pos normalization, so all planes for a CRTC are added
> to the commit. Please drop this piece in a separate commit.

You mean only testing sspp as below? We have to handle the default
 non-shared case as existing implementation. Maybe we add a flag after
sharing SSPP among planes? Otherwise, how to distinct the shared
SSPP case and disable multi-rect mode in non-shared case?

               if (pipe->sspp) {

>
> >
> > >
> > > > +                     pipe->multirect_index = DPU_SSPP_RECT_SOLO;
> > > > +                     pipe->multirect_mode = DPU_SSPP_MULTIRECT_NONE;
> > > > +
> > > > +                     if (pipe->sspp->ops.setup_multirect)
> > > > +                             pipe->sspp->ops.setup_multirect(pipe);
> > > > +             }
> > > >       }
> > > >
> > > >       pstate->pending = true;
> > >
> > > --
> > > With best wishes
> > > Dmitry
>
> --
> With best wishes
> Dmitry