From: Jessica Zhang <quic_jesszhan@quicinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
Rob Clark <robdclark@gmail.com>, Sean Paul <sean@poorly.run>,
Marijn Suijten <marijn.suijten@somainline.org>
Cc: <quic_abhinavk@quicinc.com>, <ppaalanen@gmail.com>,
<contact@emersion.fr>, <laurent.pinchart@ideasonboard.com>,
<sebastian.wick@redhat.com>, <ville.syrjala@linux.intel.com>,
<dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
<linux-arm-msm@vger.kernel.org>,
<freedreno@lists.freedesktop.org>,
<wayland-devel@lists.freedesktop.org>
Subject: Re: [PATCH RFC v6 08/10] drm/msm/dpu: Allow NULL FBs in atomic commit
Date: Wed, 18 Oct 2023 17:59:22 -0700 [thread overview]
Message-ID: <2dace097-affe-4bc6-ac7c-b5606bd86a89@quicinc.com> (raw)
In-Reply-To: <494ede51-46bf-437b-98b8-2460f4c40285@linaro.org>
On 9/24/2023 3:29 AM, Dmitry Baryshkov wrote:
> On 29/08/2023 03:05, Jessica Zhang wrote:
>> Since solid fill planes allow for a NULL framebuffer in a valid commit,
>> add NULL framebuffer checks to atomic commit calls within DPU.
>>
>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>> Signed-off-by: Jessica Zhang <quic_jesszhan@quicinc.com>
>> ---
>> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 9 ++++++-
>> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 41
>> ++++++++++++++++++++-----------
>> 2 files changed, 34 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>> index 8ce7586e2ddf..5e845510e8c1 100644
>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>> @@ -451,6 +451,7 @@ static void _dpu_crtc_blend_setup_mixer(struct
>> drm_crtc *crtc,
>> struct drm_plane_state *state;
>> struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc->state);
>> struct dpu_plane_state *pstate = NULL;
>> + const struct msm_format *fmt;
>> struct dpu_format *format;
>> struct dpu_hw_ctl *ctl = mixer->lm_ctl;
>> @@ -470,7 +471,13 @@ static void _dpu_crtc_blend_setup_mixer(struct
>> drm_crtc *crtc,
>> pstate = to_dpu_plane_state(state);
>> fb = state->fb;
>> - format = to_dpu_format(msm_framebuffer_format(pstate->base.fb));
>> + if (drm_plane_solid_fill_enabled(state))
>> + fmt = dpu_get_msm_format(&_dpu_crtc_get_kms(crtc)->base,
>> + DRM_FORMAT_ABGR8888, 0);
>> + else
>> + fmt = msm_framebuffer_format(pstate->base.fb);
>> +
>> + format = to_dpu_format(fmt);
>> if (pstate->stage == DPU_STAGE_BASE && format->alpha_enable)
>> bg_alpha_enable = true;
>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
>> index c2aaaded07ed..114c803ff99b 100644
>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
>> @@ -837,8 +837,13 @@ static int dpu_plane_atomic_check(struct
>> drm_plane *plane,
>> pipe_cfg->dst_rect = new_plane_state->dst;
>> - fb_rect.x2 = new_plane_state->fb->width;
>> - fb_rect.y2 = new_plane_state->fb->height;
>> + if (drm_plane_solid_fill_enabled(new_plane_state))
>> + return 0;
>
> This would skip all the width checks, dpu_plane_atomic_check_pipe(),
> etc. Could you please confirm that all of those checks are irrelevant
> for solid fill?
Hi Dmitry,
Good point -- I think it would be good to keep the rect and pipe checks
for solid fill.
>
>> +
>> + if (new_plane_state->pixel_source == DRM_PLANE_PIXEL_SOURCE_FB &&
>> new_plane_state->fb) {
>> + fb_rect.x2 = new_plane_state->fb->width;
>> + fb_rect.y2 = new_plane_state->fb->height;
>> + }
>> /* Ensure fb size is supported */
>> if (drm_rect_width(&fb_rect) > MAX_IMG_WIDTH ||
>> @@ -1082,21 +1087,32 @@ static void
>> dpu_plane_sspp_atomic_update(struct drm_plane *plane)
>> struct drm_crtc *crtc = state->crtc;
>> struct drm_framebuffer *fb = state->fb;
>> bool is_rt_pipe;
>> - const struct dpu_format *fmt =
>> - to_dpu_format(msm_framebuffer_format(fb));
>> + const struct dpu_format *fmt;
>> struct dpu_sw_pipe_cfg *pipe_cfg = &pstate->pipe_cfg;
>> struct dpu_sw_pipe_cfg *r_pipe_cfg = &pstate->r_pipe_cfg;
>> struct dpu_kms *kms = _dpu_plane_get_kms(&pdpu->base);
>> struct msm_gem_address_space *aspace = kms->base.aspace;
>> struct dpu_hw_fmt_layout layout;
>> bool layout_valid = false;
>> - int ret;
>> - ret = dpu_format_populate_layout(aspace, fb, &layout);
>> - if (ret)
>> - DPU_ERROR_PLANE(pdpu, "failed to get format layout, %d\n", ret);
>> - else
>> - layout_valid = true;
>> + if (state->pixel_source == DRM_PLANE_PIXEL_SOURCE_FB && fb) {
>> + int ret;
>> +
>> + fmt = to_dpu_format(msm_framebuffer_format(fb));
>> +
>> + ret = dpu_format_populate_layout(aspace, fb, &layout);
>> + if (ret)
>> + DPU_ERROR_PLANE(pdpu, "failed to get format layout,
>> %d\n", ret);
>> + else
>> + layout_valid = true;
>> +
>> + DPU_DEBUG_PLANE(pdpu, "FB[%u] " DRM_RECT_FP_FMT "->crtc%u "
>> DRM_RECT_FMT
>> + ", %4.4s ubwc %d\n", fb->base.id,
>> DRM_RECT_FP_ARG(&state->src),
>> + crtc->base.id, DRM_RECT_ARG(&state->dst),
>> + (char *)&fmt->base.pixel_format,
>> DPU_FORMAT_IS_UBWC(fmt));
>> + } else {
>> + fmt = dpu_get_dpu_format(DRM_FORMAT_ABGR8888);
>
> #define DPU_SOLID_FILL_FORMAT ?
Acked.
>
> Also, I don't think that solid_fill planes consume bandwidth, so this
> likely needs to be fixed too.
You're right -- I think we can actually return early here if solid fill
is enabled.
Thanks,
Jessica Zhang
>
>
>> + }
>> pstate->pending = true;
>> @@ -1104,11 +1120,6 @@ static void dpu_plane_sspp_atomic_update(struct
>> drm_plane *plane)
>> pstate->needs_qos_remap |= (is_rt_pipe != pdpu->is_rt_pipe);
>> pdpu->is_rt_pipe = is_rt_pipe;
>> - DPU_DEBUG_PLANE(pdpu, "FB[%u] " DRM_RECT_FP_FMT "->crtc%u "
>> DRM_RECT_FMT
>> - ", %4.4s ubwc %d\n", fb->base.id,
>> DRM_RECT_FP_ARG(&state->src),
>> - crtc->base.id, DRM_RECT_ARG(&state->dst),
>> - (char *)&fmt->base.pixel_format, DPU_FORMAT_IS_UBWC(fmt));
>> -
>> dpu_plane_sspp_update_pipe(plane, pipe, pipe_cfg, fmt,
>> drm_mode_vrefresh(&crtc->mode),
>> layout_valid ? &layout : NULL);
>>
>
> --
> With best wishes
> Dmitry
>
next prev parent reply other threads:[~2023-10-19 1:00 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-29 0:05 [PATCH RFC v6 00/10] Support for Solid Fill Planes Jessica Zhang
2023-08-29 0:05 ` [PATCH RFC v6 01/10] drm: Introduce pixel_source DRM plane property Jessica Zhang
2023-08-29 7:48 ` Pekka Paalanen
2023-10-19 10:45 ` Sebastian Wick
2023-09-24 10:06 ` Dmitry Baryshkov
2023-10-19 4:59 ` Jessica Zhang
2023-10-19 14:22 ` Simon Ser
2023-08-29 0:05 ` [PATCH RFC v6 02/10] drm: Introduce solid fill " Jessica Zhang
2023-08-29 8:10 ` Pekka Paalanen
2023-08-29 15:23 ` Sebastian Wick
2023-08-29 0:05 ` [PATCH RFC v6 03/10] drm: Add solid fill pixel source Jessica Zhang
2023-08-29 8:11 ` Pekka Paalanen
2023-08-29 0:05 ` [PATCH RFC v6 04/10] drm/atomic: Add pixel source to plane state dump Jessica Zhang
2023-09-24 10:08 ` Dmitry Baryshkov
2023-08-29 0:05 ` [PATCH RFC v6 05/10] drm/atomic: Add solid fill data " Jessica Zhang
2023-08-29 8:14 ` Pekka Paalanen
2023-09-24 10:09 ` Dmitry Baryshkov
2023-08-29 0:05 ` [PATCH RFC v6 06/10] drm/atomic: Move framebuffer checks to helper Jessica Zhang
2023-08-29 0:05 ` [PATCH RFC v6 07/10] drm/atomic: Loosen FB atomic checks Jessica Zhang
2023-08-29 8:22 ` Pekka Paalanen
2023-09-22 17:49 ` [Freedreno] " Jessica Zhang
2023-09-24 10:23 ` Dmitry Baryshkov
2023-10-17 0:40 ` Jessica Zhang
2023-10-17 7:25 ` Dmitry Baryshkov
2023-09-24 10:19 ` Dmitry Baryshkov
2023-08-29 0:05 ` [PATCH RFC v6 08/10] drm/msm/dpu: Allow NULL FBs in atomic commit Jessica Zhang
2023-09-24 10:29 ` Dmitry Baryshkov
2023-10-19 0:59 ` Jessica Zhang [this message]
2023-08-29 0:05 ` [PATCH RFC v6 09/10] drm/msm/dpu: Use DRM solid_fill property Jessica Zhang
2023-09-25 10:34 ` Dmitry Baryshkov
2023-08-29 0:05 ` [PATCH RFC v6 10/10] drm/msm/dpu: Add solid fill and pixel source properties Jessica Zhang
2023-08-29 15:42 ` [PATCH RFC v6 00/10] Support for Solid Fill Planes Sebastian Wick
2023-09-26 15:25 ` Harry Wentland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2dace097-affe-4bc6-ac7c-b5606bd86a89@quicinc.com \
--to=quic_jesszhan@quicinc.com \
--cc=airlied@gmail.com \
--cc=contact@emersion.fr \
--cc=daniel@ffwll.ch \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=marijn.suijten@somainline.org \
--cc=mripard@kernel.org \
--cc=ppaalanen@gmail.com \
--cc=quic_abhinavk@quicinc.com \
--cc=robdclark@gmail.com \
--cc=sean@poorly.run \
--cc=sebastian.wick@redhat.com \
--cc=tzimmermann@suse.de \
--cc=ville.syrjala@linux.intel.com \
--cc=wayland-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox