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: <fbw4ehm6e7hq6wv2ek2zokwzgr2vhnpece3iy2y67qe54z7lyb@uncyoewqjydv>
Date: Thu, 16 Jan 2025 12:37:39 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Jun Nie <jun.nie@...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 13/16] drm/msm/dpu: support plane splitting in
 quad-pipe case

On Thu, Jan 16, 2025 at 06:20:48PM +0800, Jun Nie wrote:
> Dmitry Baryshkov <dmitry.baryshkov@...aro.org> 于2025年1月16日周四 16:14写道:
> >
> > On Thu, Jan 16, 2025 at 03:26:02PM +0800, Jun Nie wrote:
> > > The content of every half of screen is sent out via one interface in
> > > dual-DSI case. The content for every interface is blended by a LM
> > > pair in quad-pipe case, thus a LM pair should not blend any content
> > > that cross the half of screen in this case. Clip plane into pipes per
> > > left and right half screen ROI if topology is quad pipe case.
> > >
> > > The clipped rectangle on every half of screen will be split further
> > > by half if its width still exceeds limit.
> >
> > futher handled by two pipes if its width exceeds a limit for a single
> > pipe.
> 
> Accepted.
> >
> > >
> > > Signed-off-by: Jun Nie <jun.nie@...aro.org>
> > > ---
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c    |  11 +++
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h    |   2 +
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h |   2 +
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c   | 138 +++++++++++++++++++---------
> > >  4 files changed, 112 insertions(+), 41 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > > index 5ae640da53fbf..a900220deeb35 100644
> > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > > @@ -1361,6 +1361,17 @@ int dpu_crtc_vblank(struct drm_crtc *crtc, bool en)
> > >       return 0;
> > >  }
> > >
> > > +/**
> > > + * dpu_crtc_get_num_lm - Get mixer number in this CRTC pipeline
> > > + * @state: Pointer to drm crtc state object
> > > + */
> > > +unsigned int dpu_crtc_get_num_lm(const struct drm_crtc_state *state)
> > > +{
> > > +     struct dpu_crtc_state *cstate = to_dpu_crtc_state(state);
> > > +
> > > +     return cstate->num_mixers;
> > > +}
> > > +
> > >  #ifdef CONFIG_DEBUG_FS
> > >  static int _dpu_debugfs_status_show(struct seq_file *s, void *data)
> > >  {
> > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> > > index 0b148f3ce0d7a..b14bab2754635 100644
> > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> > > @@ -264,4 +264,6 @@ static inline enum dpu_crtc_client_type dpu_crtc_get_client_type(
> > >
> > >  void dpu_crtc_frame_event_cb(struct drm_crtc *crtc, u32 event);
> > >
> > > +unsigned int dpu_crtc_get_num_lm(const struct drm_crtc_state *state);
> > > +
> > >  #endif /* _DPU_CRTC_H_ */
> > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
> > > index 56a0edf2a57c6..39fe338e76691 100644
> > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
> > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
> > > @@ -145,11 +145,13 @@ struct dpu_hw_pixel_ext {
> > >   *             such as decimation, flip etc to program this field
> > >   * @dest_rect: destination ROI.
> > >   * @rotation: simplified drm rotation hint
> > > + * @valid: notify that this pipe and config is in use
> > >   */
> > >  struct dpu_sw_pipe_cfg {
> > >       struct drm_rect src_rect;
> > >       struct drm_rect dst_rect;
> > >       unsigned int rotation;
> > > +     bool valid;
> >
> > Commit message doesn't describe why this is necessary at all. Why isn't
> > it enough to check pipe->sspp as the code has been doing up to this
> > point?
> 
> We test non-zero width of r_pipe or check pipe->sspp to decide whether
> to allocate SSPP and go thru the routine for the r_pipe when we have 2
> pipes at most. With 4 pipes, it is a bit complex to handle it this way because
> the 2rd and the 4th pipes may be not valid when splitting the plane. A valid
> flag is more straightforward for later handling.

Why? Even for 4-pipe case we need to allocate SSPP rect if
drm_rect_width is non-0, that's for the atomic_check() function. And
later we should be using pipe->sspp to check if it is valid or not.
Adding extra flag complicates code because it can easily become unsync
with the rest of the pipe configuration.

> 
> >
> > >  };
> > >
> > >  /**
> > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > > index 3795576e2eedd..4bcd7b1a05c16 100644
> > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > > @@ -831,8 +831,12 @@ static int dpu_plane_atomic_check_nosspp(struct drm_plane *plane,
> > >       struct dpu_plane_state *pstate = to_dpu_plane_state(new_plane_state);
> > >       struct dpu_sw_pipe_cfg *pipe_cfg;
> > >       struct dpu_sw_pipe_cfg *r_pipe_cfg;
> > > +     struct dpu_sw_pipe_cfg init_pipe_cfg;
> > >       struct drm_rect fb_rect = { 0 };
> > > +     const struct drm_display_mode *mode = &crtc_state->adjusted_mode;
> > >       uint32_t max_linewidth;
> > > +     u32 num_lm;
> > > +     int stage_id, num_stages;
> > >
> > >       min_scale = FRAC_16_16(1, MAX_UPSCALE_RATIO);
> > >       max_scale = MAX_DOWNSCALE_RATIO << 16;
> > > @@ -855,13 +859,10 @@ static int dpu_plane_atomic_check_nosspp(struct drm_plane *plane,
> > >               return -EINVAL;
> > >       }
> > >
> > > -     /* move the assignment here, to ease handling to another pairs later */
> > > -     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);
> > > +     num_lm = dpu_crtc_get_num_lm(crtc_state);
> > >
> > > -     pipe_cfg->dst_rect = new_plane_state->dst;
> > > +     /* state->src is 16.16, src_rect is not */
> > > +     drm_rect_fp_to_int(&init_pipe_cfg.src_rect, &new_plane_state->src);
> > >
> > >       fb_rect.x2 = new_plane_state->fb->width;
> > >       fb_rect.y2 = new_plane_state->fb->height;
> > > @@ -886,35 +887,93 @@ static int dpu_plane_atomic_check_nosspp(struct drm_plane *plane,
> > >
> > >       max_linewidth = pdpu->catalog->caps->max_linewidth;
> > >
> > > -     drm_rect_rotate(&pipe_cfg->src_rect,
> > > +     drm_rect_rotate(&init_pipe_cfg.src_rect,
> > >                       new_plane_state->fb->width, new_plane_state->fb->height,
> > >                       new_plane_state->rotation);
> > >
> > > -     if ((drm_rect_width(&pipe_cfg->src_rect) > max_linewidth) ||
> > > -          _dpu_plane_calc_clk(&crtc_state->adjusted_mode, pipe_cfg) > max_mdp_clk_rate) {
> > > -             if (drm_rect_width(&pipe_cfg->src_rect) > 2 * max_linewidth) {
> > > -                     DPU_DEBUG_PLANE(pdpu, "invalid src " DRM_RECT_FMT " line:%u\n",
> > > -                                     DRM_RECT_ARG(&pipe_cfg->src_rect), max_linewidth);
> > > -                     return -E2BIG;
> > > +     /*
> > > +      * We have 1 mixer pair cfg for 1:1:1 and 2:2:1 topology, 2 mixer pair
> > > +      * configs for left and right half screen in case of 4:4:2 topology.
> > > +      * But we may have 2 rect to split wide plane that exceeds limit with 1
> > > +      * config for 2:2:1. So need to handle both wide plane splitting, and
> > > +      * plane on right half for quad-pipe case. Check dest rectangle
> >
> > only on the right side?
> 
> Yeah, below shall be better.
> So need to handle both wide plane splitting, and two halves of screen splitting
> for quad-pipe case.
> >
> > > +      * left/right clipping first, then check wide rectangle splitting in
> > > +      * every half next.
> > > +      */
> > > +     num_stages = (num_lm + 1) / 2;
> >
> > --
> > With best wishes
> > Dmitry

-- 
With best wishes
Dmitry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ