From: Pekka Paalanen <ppaalanen@gmail.com>
To: Jessica Zhang <quic_jesszhan@quicinc.com>
Cc: 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>,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
"Sean Paul" <sean@poorly.run>,
Marijn Suijten <marijn.suijten@somainline.org>,
<quic_abhinavk@quicinc.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 v4 7/7] drm/msm/dpu: Use DRM solid_fill property
Date: Fri, 30 Jun 2023 11:26:49 +0300 [thread overview]
Message-ID: <20230630112649.263331b4@eldfell> (raw)
In-Reply-To: <20230404-solid-fill-v4-7-f4ec0caa742d@quicinc.com>
[-- Attachment #1: Type: text/plain, Size: 3256 bytes --]
On Thu, 29 Jun 2023 17:25:06 -0700
Jessica Zhang <quic_jesszhan@quicinc.com> wrote:
> Drop DPU_PLANE_COLOR_FILL_FLAG and check the DRM solid_fill property to
> determine if the plane is solid fill. In addition drop the DPU plane
> color_fill field as we can now use drm_plane_state.solid_fill instead,
> and pass in drm_plane_state.alpha to _dpu_plane_color_fill_pipe() to
> allow userspace to configure the alpha value for the solid fill color.
>
> Signed-off-by: Jessica Zhang <quic_jesszhan@quicinc.com>
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 21 +++++++++++++++------
> 1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> index 4476722f03bb..11d4fb771a1f 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> @@ -42,7 +42,6 @@
> #define SHARP_SMOOTH_THR_DEFAULT 8
> #define SHARP_NOISE_THR_DEFAULT 2
>
> -#define DPU_PLANE_COLOR_FILL_FLAG BIT(31)
> #define DPU_ZPOS_MAX 255
>
> /*
> @@ -82,7 +81,6 @@ struct dpu_plane {
>
> enum dpu_sspp pipe;
>
> - uint32_t color_fill;
> bool is_error;
> bool is_rt_pipe;
> const struct dpu_mdss_cfg *catalog;
> @@ -606,6 +604,17 @@ static void _dpu_plane_color_fill_pipe(struct dpu_plane_state *pstate,
> _dpu_plane_setup_scaler(pipe, fmt, true, &pipe_cfg, pstate->rotation);
> }
>
> +static uint32_t _dpu_plane_get_fill_color(struct drm_solid_fill solid_fill)
> +{
> + uint32_t ret = 0;
> +
> + ret |= ((uint8_t) solid_fill.b) << 16;
> + ret |= ((uint8_t) solid_fill.g) << 8;
> + ret |= ((uint8_t) solid_fill.r);
solid_fill.r, g and b are uint32_t, yes?
What's the value encoding in the UAPI? That doc was missing.
I wouldn't expect the UAPI to use 32-bit variables if it was
essentially 8-bit, so this conversion looks wrong.
Nominal color value 1.0 in u8 is 0xff. The same in u32 is probably
0xffffffff? So a simple cast to u8 won't work. You'd want to take the
upper 8 bits instead.
Thanks,
pq
> +
> + return ret;
> +}
> +
> /**
> * _dpu_plane_color_fill - enables color fill on plane
> * @pdpu: Pointer to DPU plane object
> @@ -977,9 +986,9 @@ void dpu_plane_flush(struct drm_plane *plane)
> if (pdpu->is_error)
> /* force white frame with 100% alpha pipe output on error */
> _dpu_plane_color_fill(pdpu, 0xFFFFFF, 0xFF);
> - else if (pdpu->color_fill & DPU_PLANE_COLOR_FILL_FLAG)
> - /* force 100% alpha */
> - _dpu_plane_color_fill(pdpu, pdpu->color_fill, 0xFF);
> + else if (drm_plane_solid_fill_enabled(plane->state))
> + _dpu_plane_color_fill(pdpu, _dpu_plane_get_fill_color(plane->state->solid_fill),
> + plane->state->alpha);
> else {
> dpu_plane_flush_csc(pdpu, &pstate->pipe);
> dpu_plane_flush_csc(pdpu, &pstate->r_pipe);
> @@ -1024,7 +1033,7 @@ static void dpu_plane_sspp_update_pipe(struct drm_plane *plane,
> }
>
> /* override for color fill */
> - if (pdpu->color_fill & DPU_PLANE_COLOR_FILL_FLAG) {
> + if (drm_plane_solid_fill_enabled(plane->state)) {
> _dpu_plane_set_qos_ctrl(plane, pipe, false);
>
> /* skip remaining processing on color fill */
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-06-30 8:27 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-30 0:24 [PATCH RFC v4 0/7] Support for Solid Fill Planes Jessica Zhang
2023-06-30 0:25 ` [PATCH RFC v4 1/7] drm: Introduce solid fill DRM plane property Jessica Zhang
2023-06-30 8:27 ` Pekka Paalanen
2023-07-10 23:12 ` [Freedreno] " Jessica Zhang
2023-07-11 7:42 ` Pekka Paalanen
2023-07-11 21:47 ` Jessica Zhang
2023-06-30 10:33 ` Dmitry Baryshkov
2023-06-30 17:54 ` Jessica Zhang
2023-06-30 0:25 ` [PATCH RFC v4 2/7] drm: Introduce pixel_source " Jessica Zhang
2023-06-30 0:42 ` Dmitry Baryshkov
2023-06-30 8:27 ` Pekka Paalanen
2023-07-10 19:51 ` Jessica Zhang
2023-07-10 20:11 ` Dmitry Baryshkov
2023-07-11 22:07 ` Jessica Zhang
2023-07-11 22:19 ` Dmitry Baryshkov
2023-07-11 22:42 ` Abhinav Kumar
2023-07-11 23:00 ` Dmitry Baryshkov
2023-07-12 7:35 ` Pekka Paalanen
2023-06-30 14:43 ` Sebastian Wick
2023-06-30 21:27 ` Jessica Zhang
2023-07-03 11:49 ` Sebastian Wick
2023-06-30 0:25 ` [PATCH RFC v4 3/7] drm/atomic: Move framebuffer checks to helper Jessica Zhang
2023-06-30 0:43 ` Dmitry Baryshkov
2023-06-30 17:59 ` Jessica Zhang
2023-06-30 0:25 ` [PATCH RFC v4 4/7] drm/atomic: Loosen FB atomic checks Jessica Zhang
2023-06-30 0:48 ` Dmitry Baryshkov
2023-06-30 23:41 ` Jessica Zhang
2023-06-30 0:25 ` [PATCH RFC v4 5/7] drm/msm/dpu: Add solid fill and pixel source properties Jessica Zhang
2023-06-30 0:49 ` Dmitry Baryshkov
2023-06-30 23:41 ` Jessica Zhang
2023-06-30 0:25 ` [PATCH RFC v4 6/7] drm/msm/dpu: Allow NULL FBs in atomic commit Jessica Zhang
2023-06-30 0:52 ` Dmitry Baryshkov
2023-06-30 8:21 ` Pekka Paalanen
2023-07-01 1:14 ` Jessica Zhang
2023-06-30 0:25 ` [PATCH RFC v4 7/7] drm/msm/dpu: Use DRM solid_fill property Jessica Zhang
2023-06-30 0:59 ` Dmitry Baryshkov
2023-07-01 1:26 ` Jessica Zhang
2023-06-30 8:26 ` Pekka Paalanen [this message]
2023-07-03 7:42 ` Pekka Paalanen
2023-07-12 0:01 ` Jessica Zhang
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=20230630112649.263331b4@eldfell \
--to=ppaalanen@gmail.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=quic_abhinavk@quicinc.com \
--cc=quic_jesszhan@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