| 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
| ||
|
Message-ID: <CABymUCNMe7egDjOfExA8AOqjtkjHHLPspibG6OZMhzHmvn6W+g@mail.gmail.com>
Date: Thu, 16 Jan 2025 18:20:48 +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 13/16] drm/msm/dpu: support plane splitting in
quad-pipe case
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.
>
> > };
> >
> > /**
> > 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
Powered by blists - more mailing lists