Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Jessica Zhang <quic_jesszhan@quicinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Daniel Vetter <daniel@ffwll.ch>,
	<freedreno@lists.freedesktop.org>,
	<linux-arm-msm@vger.kernel.org>,
	<dri-devel@lists.freedesktop.org>, <robdclark@gmail.com>,
	<seanpaul@chromium.org>, <swboyd@chromium.org>,
	<quic_abhinavk@quicinc.com>, <contact@emersion.fr>,
	<daniel.vetter@ffwll.ch>, <laurent.pinchart@ideasonboard.com>,
	<ppaalanen@gmail.com>, <sebastian.wick@redhat.com>,
	<wayland-devel@lists.freedesktop.org>,
	<ville.syrjala@linux.intel.com>
Subject: Re: [RFC PATCH v3 0/3] Support for Solid Fill Planes
Date: Fri, 6 Jan 2023 11:44:21 -0800	[thread overview]
Message-ID: <5ddc0a33-114c-5fd5-78c0-2ead90accebc@quicinc.com> (raw)
In-Reply-To: <CAA8EJppnAmN6+S-emEfXJEc1iVf+DjeLBmCQpGd-nRY2M2AAQQ@mail.gmail.com>



On 1/5/2023 7:43 PM, Dmitry Baryshkov wrote:
> On Fri, 6 Jan 2023 at 02:38, Jessica Zhang <quic_jesszhan@quicinc.com> wrote:
>>
>>
>>
>> On 1/5/2023 3:33 AM, Daniel Vetter wrote:
>>> On Wed, Jan 04, 2023 at 03:40:33PM -0800, Jessica Zhang wrote:
>>>> Introduce and add support for a solid_fill property. When the solid_fill
>>>> property is set, and the framebuffer is set to NULL, memory fetch will be
>>>> disabled.
>>>>
>>>> In addition, loosen the NULL FB checks within the atomic commit callstack
>>>> to allow a NULL FB when the solid_fill property is set and add FB checks
>>>> in methods where the FB was previously assumed to be non-NULL.
>>>>
>>>> Finally, have the DPU driver use drm_plane_state.solid_fill and instead of
>>>> dpu_plane_state.color_fill, and add extra checks in the DPU atomic commit
>>>> callstack to account for a NULL FB in cases where solid_fill is set.
>>>>
>>>> Some drivers support hardware that have optimizations for solid fill
>>>> planes. This series aims to expose these capabilities to userspace as
>>>> some compositors have a solid fill flag (ex. SOLID_COLOR in the Android
>>>> hardware composer HAL) that can be set by apps like the Android Gears
>>>> app.
>>>>
>>>> Userspace can set the solid_fill property to a blob containing the
>>>> appropriate version number and solid fill color (in RGB323232 format) and
>>>> setting the framebuffer to NULL.
>>>>
>>>> Note: Currently, there's only one version of the solid_fill blob property.
>>>> However if other drivers want to support a similar feature, but require
>>>> more than just the solid fill color, they can extend this feature by
>>>> creating additional versions of the drm_solid_fill struct.
>>>>
>>>> Changes in V2:
>>>> - Dropped SOLID_FILL_FORMAT property (Simon)
>>>> - Switched to implementing solid_fill property as a blob (Simon, Dmitry)
>>>> - Changed to checks for if solid_fill_blob is set (Dmitry)
>>>> - Abstracted (plane_state && !solid_fill_blob) checks to helper method
>>>>     (Dmitry)
>>>> - Removed DPU_PLANE_COLOR_FILL_FLAG
>>>> - Fixed whitespace and indentation issues (Dmitry)
>>>
>>> Now that this is a blob, I do wonder again whether it's not cleaner to set
>>> the blob as the FB pointer. Or create some kind other kind of special data
>>> source objects (because solid fill is by far not the only such thing).
>>>
>>> We'd still end up in special cases like when userspace that doesn't
>>> understand solid fill tries to read out such a framebuffer, but these
>>> cases already exist anyway for lack of priviledges.
>>>
>>> So I still think that feels like the more consistent way to integrate this
>>> feature. Which doesn't mean it has to happen like that, but the
>>> patches/cover letter should at least explain why we don't do it like this.
>>
>> Hi Daniel,
>>
>> IIRC we were facing some issues with this check [1] when trying to set
>> FB to a PROP_BLOB instead. Which is why we went with making it a
>> separate property instead. Will mention this in the cover letter.
> 
> What kind of issues? Could you please describe them?

Hi Dmitry,

PROP_BLOB is defined as a legacy type here [1], but FB_ID is a 
PROP_OBJECT which is defined as an extended type [2]. So, setting a 
property blob as the FB would fail drm_property_flags_valid() due to 
this check [3].

[1] 
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/include/uapi/drm/drm_mode.h#L523

[2] 
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/include/uapi/drm/drm_mode.h#L534

[3] 
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/drm_property.c#L71

Thanks,

Jessica Zhang

> 
>>
>> [1]
>> https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/drm_property.c#L71
>>
>> Thanks,
>>
>> Jessica Zhang
>>
>>> -Daniel
>>>
>>>>
>>>> Changes in V3:
>>>> - Fixed some logic errors in atomic checks (Dmitry)
>>>> - Introduced drm_plane_has_visible_data() and drm_atomic_check_fb() helper
>>>>     methods (Dmitry)
>>>>
>>>> Jessica Zhang (3):
>>>>     drm: Introduce solid fill property for drm plane
>>>>     drm: Adjust atomic checks for solid fill color
>>>>     drm/msm/dpu: Use color_fill property for DPU planes
>>>>
>>>>    drivers/gpu/drm/drm_atomic.c              | 136 +++++++++++++---------
>>>>    drivers/gpu/drm/drm_atomic_helper.c       |  34 +++---
>>>>    drivers/gpu/drm/drm_atomic_state_helper.c |   9 ++
>>>>    drivers/gpu/drm/drm_atomic_uapi.c         |  59 ++++++++++
>>>>    drivers/gpu/drm/drm_blend.c               |  17 +++
>>>>    drivers/gpu/drm/drm_plane.c               |   8 +-
>>>>    drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |   9 +-
>>>>    drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c |  65 +++++++----
>>>>    include/drm/drm_atomic_helper.h           |   5 +-
>>>>    include/drm/drm_blend.h                   |   1 +
>>>>    include/drm/drm_plane.h                   |  62 ++++++++++
>>>>    11 files changed, 302 insertions(+), 103 deletions(-)
>>>>
>>>> --
>>>> 2.38.1
>>>>
>>>
>>> --
>>> Daniel Vetter
>>> Software Engineer, Intel Corporation
>>> http://blog.ffwll.ch
> 
> 
> 
> -- 
> With best wishes
> Dmitry

      parent reply	other threads:[~2023-01-06 19:44 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-04 23:40 [RFC PATCH v3 0/3] Support for Solid Fill Planes Jessica Zhang
2023-01-04 23:40 ` [RFC PATCH v3 1/3] drm: Introduce solid fill property for drm plane Jessica Zhang
2023-01-05  1:50   ` Dmitry Baryshkov
2023-01-05  2:12   ` Dmitry Baryshkov
2023-01-18 18:57   ` Harry Wentland
2023-01-18 22:53     ` Jessica Zhang
2023-01-19 15:57       ` Harry Wentland
2023-01-19 16:24         ` Jessica Zhang
2023-01-19 16:27           ` Harry Wentland
2023-01-04 23:40 ` [RFC PATCH v3 2/3] drm: Adjust atomic checks for solid fill color Jessica Zhang
2023-01-05  1:57   ` Dmitry Baryshkov
2023-01-06 20:51     ` Jessica Zhang
2023-01-04 23:40 ` [RFC PATCH v3 3/3] drm/msm/dpu: Use color_fill property for DPU planes Jessica Zhang
2023-01-05  2:16   ` Dmitry Baryshkov
2023-01-06 20:57     ` [Freedreno] " Jessica Zhang
2023-01-06 21:56       ` Dmitry Baryshkov
2023-01-05 11:33 ` [RFC PATCH v3 0/3] Support for Solid Fill Planes Daniel Vetter
2023-01-06  0:37   ` Jessica Zhang
2023-01-06  3:43     ` Dmitry Baryshkov
2023-01-06 18:41       ` Daniel Vetter
2023-01-06 21:49         ` Dmitry Baryshkov
2023-01-07  0:33           ` Abhinav Kumar
2023-01-11 22:29             ` Daniel Vetter
2023-01-24 10:42               ` Simon Ser
2023-01-31  9:25           ` Pekka Paalanen
2023-01-31 10:06             ` Simon Ser
2023-01-31 11:13               ` Pekka Paalanen
2023-01-31 11:21                 ` Simon Ser
2023-01-31 12:49                   ` Pekka Paalanen
2023-02-02  2:06                     ` Jessica Zhang
2023-02-02  8:55                       ` Pekka Paalanen
2023-01-06 19:44       ` Jessica Zhang [this message]

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=5ddc0a33-114c-5fd5-78c0-2ead90accebc@quicinc.com \
    --to=quic_jesszhan@quicinc.com \
    --cc=contact@emersion.fr \
    --cc=daniel.vetter@ffwll.ch \
    --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=ppaalanen@gmail.com \
    --cc=quic_abhinavk@quicinc.com \
    --cc=robdclark@gmail.com \
    --cc=seanpaul@chromium.org \
    --cc=sebastian.wick@redhat.com \
    --cc=swboyd@chromium.org \
    --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