linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: Abhinav Kumar <quic_abhinavk@quicinc.com>,
	Rob Clark <robdclark@gmail.com>, Sean Paul <sean@poorly.run>
Cc: Stephen Boyd <swboyd@chromium.org>,
	David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
	Bjorn Andersson <andersson@kernel.org>,
	linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
	freedreno@lists.freedesktop.org
Subject: Re: [PATCH v3 15/27] drm/msm/dpu: move the rest of plane checks to dpu_plane_atomic_check()
Date: Fri, 3 Mar 2023 13:43:07 +0200	[thread overview]
Message-ID: <84781db7-b3f2-2bc2-511f-f07e05a428de@linaro.org> (raw)
In-Reply-To: <005030a5-bcc3-14ea-121f-fba794555626@linaro.org>

On 15/02/2023 02:08, Dmitry Baryshkov wrote:
> On 15/02/2023 01:25, Abhinav Kumar wrote:
>> Hi Dmitry
>>
>> Sorry for the late response on this one.
>>
>> On 2/3/2023 2:55 PM, Dmitry Baryshkov wrote:
>>> On 04/02/2023 00:44, Abhinav Kumar wrote:
>>>>
>>>>
>>>> On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
>>>>> Move plane state updates from dpu_crtc_atomic_check() to the function
>>>>> where they belong: to dpu_plane_atomic_check().
>>>>>
>>>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>>>> ---
>>>>>   drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  | 18 +-----------------
>>>>>   drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 18 ++++++++++--------
>>>>>   drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h |  6 ------
>>>>>   3 files changed, 11 insertions(+), 31 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
>>>>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>>>>> index b485234eefb2..bd09bb319a58 100644
>>>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>>>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>>>>> @@ -1129,7 +1129,6 @@ static int dpu_crtc_atomic_check(struct 
>>>>> drm_crtc *crtc,
>>>>>                                         crtc);
>>>>>       struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
>>>>>       struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc_state);
>>>>> -    struct dpu_kms *dpu_kms = _dpu_crtc_get_kms(crtc);
>>>>>       const struct drm_plane_state *pstate;
>>>>>       struct drm_plane *plane;
>>>>> @@ -1161,11 +1160,10 @@ static int dpu_crtc_atomic_check(struct 
>>>>> drm_crtc *crtc,
>>>>>       crtc_rect.x2 = mode->hdisplay;
>>>>>       crtc_rect.y2 = mode->vdisplay;
>>>>> -     /* get plane state for all drm planes associated with crtc 
>>>>> state */
>>>>> +    /* FIXME: move this to dpu_plane_atomic_check? */
>>>>>       drm_atomic_crtc_state_for_each_plane_state(plane, pstate, 
>>>>> crtc_state) {
>>>>>           struct dpu_plane_state *dpu_pstate = 
>>>>> to_dpu_plane_state(pstate);
>>>>>           struct drm_rect dst, clip = crtc_rect;
>>>>> -        int stage;
>>>>>           if (IS_ERR_OR_NULL(pstate)) {
>>>>>               rc = PTR_ERR(pstate);
>>>>> @@ -1179,8 +1177,6 @@ static int dpu_crtc_atomic_check(struct 
>>>>> drm_crtc *crtc,
>>>>>           dpu_pstate->needs_dirtyfb = needs_dirtyfb;
>>>>> -        dpu_plane_clear_multirect(pstate);
>>>>> -
>>>>>           dst = drm_plane_state_dest(pstate);
>>>>>           if (!drm_rect_intersect(&clip, &dst)) {
>>>>>               DPU_ERROR("invalid vertical/horizontal destination\n");
>>>>> @@ -1189,18 +1185,6 @@ static int dpu_crtc_atomic_check(struct 
>>>>> drm_crtc *crtc,
>>>>>                     DRM_RECT_ARG(&dst));
>>>>>               return -E2BIG;
>>>>>           }
>>>>> -
>>>>> -        /* verify stage setting before using it */
>>>>> -        stage = DPU_STAGE_0 + pstate->normalized_zpos;
>>>>> -        if (stage >= dpu_kms->catalog->caps->max_mixer_blendstages) {
>>>>> -            DPU_ERROR("> %d plane stages assigned\n",
>>>>> -                    dpu_kms->catalog->caps->max_mixer_blendstages 
>>>>> - DPU_STAGE_0);
>>>>> -            return -EINVAL;
>>>>> -        }
>>>>> -
>>>>> -        to_dpu_plane_state(pstate)->stage = stage;
>>>>> -        DRM_DEBUG_ATOMIC("%s: stage %d\n", dpu_crtc->name, stage);
>>>>> -
>>>>>       }
>>>>>       atomic_inc(&_dpu_crtc_get_kms(crtc)->bandwidth_ref);
>>>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
>>>>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
>>>>> index 1b3033b15bfa..5aabf9694a53 100644
>>>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
>>>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
>>>>> @@ -733,14 +733,6 @@ static int _dpu_plane_color_fill(struct 
>>>>> dpu_plane *pdpu,
>>>>>       return 0;
>>>>>   }
>>>>> -void dpu_plane_clear_multirect(const struct drm_plane_state 
>>>>> *drm_state)
>>>>> -{
>>>>> -    struct dpu_plane_state *pstate = to_dpu_plane_state(drm_state);
>>>>> -
>>>>> -    pstate->pipe.multirect_index = DPU_SSPP_RECT_SOLO;
>>>>> -    pstate->pipe.multirect_mode = DPU_SSPP_MULTIRECT_NONE;
>>>>> -}
>>>>> -
>>>>>   int dpu_plane_validate_multirect_v2(struct 
>>>>> dpu_multirect_plane_states *plane)
>>>>>   {
>>>>>       struct dpu_plane_state *pstate[R_MAX];
>>>>> @@ -994,6 +986,16 @@ static int dpu_plane_atomic_check(struct 
>>>>> drm_plane *plane,
>>>>>       if (!new_plane_state->visible)
>>>>>           return 0;
>>>>> +    pstate->pipe.multirect_index = DPU_SSPP_RECT_SOLO;
>>>>> +    pstate->pipe.multirect_mode = DPU_SSPP_MULTIRECT_NONE;
>>>>> +
>>>>
>>>> But I am not sure if clearing the multirect belongs here and now I 
>>>> want to clarify one thing about 
>>>> https://patchwork.freedesktop.org/patch/521354/?series=99909&rev=4 
>>>> which was R-bed in the v1 and carried fwd since then.
>>>>
>>>> So prior to that change, we were only clearing the multirects of the 
>>>> planes that were staged to the crtc and we were getting those from 
>>>> the crtc state. But now we are clearing the multirect of all the 
>>>> planes.
>>>>
>>>> Dont we have to keep that in the crtc_atomic_check() since we do 
>>>> that on all the planes attached to a certain CRTC.
>>>>
>>>> In that case shouldnt we keep this in the crtc_atomic_check() and 
>>>> bring back pipe_staged[] without the multirect and source split 
>>>> cases ofcourse.
>>>
>>> What for? In other words, what would be the difference?
>>>
>>
>> So, please correct my understanding here. drm_plane's atomic_check() 
>> will be called for all the planes which are getting updated in this 
>> atomic commit using for_each_oldnew_plane_in_state() and drm_crtc's 
>> atomic_check() will be called for all the CRTC's in this atomic update 
>> using for_each_new_crtc_in_state() >
>> If the plane is not connected to any CRTC, why do we need to clear the 
>> multirect pstates.
> 
> If the plane is not connected to any CRTC, then we just don't care what 
> is there in the multirect state, so we might clear it as well.
> 
>>
>> OR in that case would atomic_commit not even be called if the plane is 
>> not connected to any CRTC?
>>
>> One case i can think of is the disable commit where the no planes will 
>> be connected to the CRTC so in that case, before this change we would 
>> explicitly clear out all the planes connected to the CRTC but now with 
>> this change is there a possibility that only if the plane state 
>> changed we would clear it out?
> 
> Ah. Maybe I understand your point. I think 
> drm_atomic_add_affected_planes() will ensure that all planes attached to 
> CRTCs are also a part of the atomic state.

Checked, it works as expected. But on the other hand, this pointed me to 
a possible issue in dpu_plane_atomic_disable. Probably we should drop 
the multirect setup there.

> 
> Regarding the change itself. Think about encapsulation. CRTC should not 
> care about plane's multirect state. It is a plane implementation detail. 
> As we delve upon a path of using rect1 and then even using different 
> SSPPs for the plane, these implementation details will change (mostly) 
> behind CRTC's back.
> 
>>
>>
>>>>
>>>>> +    pstate->stage = DPU_STAGE_0 + pstate->base.normalized_zpos;
>>>>> +    if (pstate->stage >= 
>>>>> pdpu->catalog->caps->max_mixer_blendstages) {
>>>>> +        DPU_ERROR("> %d plane stages assigned\n",
>>>>> +                pdpu->catalog->caps->max_mixer_blendstages - 
>>>>> DPU_STAGE_0);
>>>>> +        return -EINVAL;
>>>>> +    }
>>>>> +
>>>>
>>>> I agree that this check belongs to the plane_atomic_check().
>>>>
>>>>>       src.x1 = new_plane_state->src_x >> 16;
>>>>>       src.y1 = new_plane_state->src_y >> 16;
>>>>>       src.x2 = src.x1 + (new_plane_state->src_w >> 16);
>>>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h 
>>>>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
>>>>> index 228db401e905..a08b0539513b 100644
>>>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
>>>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
>>>>> @@ -88,12 +88,6 @@ struct drm_plane *dpu_plane_init(struct 
>>>>> drm_device *dev,
>>>>>    */
>>>>>   int dpu_plane_validate_multirect_v2(struct 
>>>>> dpu_multirect_plane_states *plane);
>>>>> -/**
>>>>> - * dpu_plane_clear_multirect - clear multirect bits for the given 
>>>>> pipe
>>>>> - * @drm_state: Pointer to DRM plane state
>>>>> - */
>>>>> -void dpu_plane_clear_multirect(const struct drm_plane_state 
>>>>> *drm_state);
>>>>> -
>>>>>   /**
>>>>>    * dpu_plane_color_fill - enables color fill on plane
>>>>>    * @plane:  Pointer to DRM plane object
>>>
> 

-- 
With best wishes
Dmitry


  reply	other threads:[~2023-03-03 11:43 UTC|newest]

Thread overview: 88+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-03 18:21 [PATCH v3 00/27] drm/msm/dpu: wide planes support Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 01/27] drm/msm/dpu: rename struct dpu_hw_pipe(_cfg) to dpu_hw_sspp(_cfg) Dmitry Baryshkov
2023-02-03 19:31   ` Abhinav Kumar
2023-02-03 18:21 ` [PATCH v3 02/27] drm/msm/dpu: move SSPP allocation to the RM Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 03/27] drm/msm/dpu: move SSPP debugfs creation to dpu_kms.c Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 04/27] drm/msm/dpu: drop EAGAIN check from dpu_format_populate_layout Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 05/27] drm/msm/dpu: move pipe_hw to dpu_plane_state Dmitry Baryshkov
2023-02-03 19:34   ` Abhinav Kumar
2023-02-03 18:21 ` [PATCH v3 06/27] drm/msm/dpu: drop dpu_plane_pipe function Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 07/27] drm/msm/dpu: introduce struct dpu_sw_pipe Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 08/27] drm/msm/dpu: use dpu_sw_pipe for dpu_hw_sspp callbacks Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 09/27] drm/msm/dpu: pass dpu_format to _dpu_hw_sspp_setup_scaler3() Dmitry Baryshkov
2023-02-03 19:36   ` Abhinav Kumar
2023-02-03 18:21 ` [PATCH v3 10/27] drm/msm/dpu: clean up SRC addresses when setting up SSPP for solid fill Dmitry Baryshkov
2023-02-03 20:36   ` Abhinav Kumar
2023-02-03 18:21 ` [PATCH v3 11/27] drm/msm/dpu: move stride programming to dpu_hw_sspp_setup_sourceaddress Dmitry Baryshkov
2023-02-03 20:37   ` Abhinav Kumar
2023-02-03 18:21 ` [PATCH v3 12/27] drm/msm/dpu: remove dpu_hw_fmt_layout from struct dpu_hw_sspp_cfg Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 13/27] drm/msm/dpu: drop src_split and multirect check from dpu_crtc_atomic_check Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 14/27] drm/msm/dpu: don't use unsupported blend stages Dmitry Baryshkov
2023-02-03 20:42   ` Abhinav Kumar
2023-02-03 18:21 ` [PATCH v3 15/27] drm/msm/dpu: move the rest of plane checks to dpu_plane_atomic_check() Dmitry Baryshkov
2023-02-03 22:44   ` Abhinav Kumar
2023-02-03 22:55     ` Dmitry Baryshkov
2023-02-14 23:25       ` Abhinav Kumar
2023-02-15  0:08         ` Dmitry Baryshkov
2023-03-03 11:43           ` Dmitry Baryshkov [this message]
2023-02-03 18:21 ` [PATCH v3 16/27] drm/msm/dpu: drop redundant plane dst check from dpu_crtc_atomic_check() Dmitry Baryshkov
2023-02-03 22:57   ` Abhinav Kumar
2023-02-03 18:21 ` [PATCH v3 17/27] drm/msm/dpu: rewrite plane's QoS-related functions to take dpu_sw_pipe and dpu_format Dmitry Baryshkov
2023-02-03 23:07   ` Abhinav Kumar
2023-02-03 23:20     ` Dmitry Baryshkov
2023-02-08 23:09       ` Abhinav Kumar
2023-02-03 18:21 ` [PATCH v3 18/27] drm/msm/dpu: populate SmartDMA features in hw catalog Dmitry Baryshkov
2023-02-03 23:35   ` Abhinav Kumar
2023-02-04  2:29     ` Dmitry Baryshkov
2023-02-04  2:43       ` Abhinav Kumar
2023-02-04  4:10         ` Dmitry Baryshkov
2023-02-04  5:10           ` Abhinav Kumar
2023-02-04 10:43             ` Dmitry Baryshkov
2023-02-04 18:35               ` Abhinav Kumar
2023-02-04 21:08                 ` Dmitry Baryshkov
2023-02-04 23:20                   ` Abhinav Kumar
2023-02-05  0:29                     ` Dmitry Baryshkov
2023-02-05  0:36                       ` Abhinav Kumar
2023-02-08 23:53                         ` Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 19/27] drm/msm/dpu: make _dpu_plane_calc_clk accept mode directly Dmitry Baryshkov
2023-02-06 18:48   ` Abhinav Kumar
2023-02-03 18:21 ` [PATCH v3 20/27] drm/msm/dpu: add dpu_hw_pipe_cfg to dpu_plane_state Dmitry Baryshkov
2023-02-06 19:07   ` Abhinav Kumar
2023-02-16 16:49     ` Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 21/27] drm/msm/dpu: simplify dpu_plane_validate_src() Dmitry Baryshkov
2023-02-06 22:40   ` Abhinav Kumar
2023-02-07  0:27     ` Dmitry Baryshkov
2023-02-07  0:42       ` Abhinav Kumar
2023-02-03 18:21 ` [PATCH v3 22/27] drm/msm/dpu: rework dpu_plane_sspp_atomic_update() Dmitry Baryshkov
2023-02-07  0:22   ` Abhinav Kumar
2023-02-09  0:49     ` Dmitry Baryshkov
2023-02-09  0:51     ` Dmitry Baryshkov
2023-02-09 11:46     ` Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 23/27] drm/msm/dpu: rework dpu_plane_atomic_check() Dmitry Baryshkov
2023-02-07 17:49   ` Abhinav Kumar
2023-02-07 17:51     ` Dmitry Baryshkov
2023-02-07 17:57       ` Abhinav Kumar
2023-02-07 17:59         ` Dmitry Baryshkov
2023-02-07 18:08           ` Abhinav Kumar
2023-02-07 19:51             ` Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 24/27] drm/msm/dpu: rework plane CSC setting Dmitry Baryshkov
2023-02-07 20:05   ` Abhinav Kumar
2023-02-07 20:44     ` Dmitry Baryshkov
2023-02-07 20:57       ` Abhinav Kumar
2023-02-03 18:21 ` [PATCH v3 25/27] drm/msm/dpu: rework static color fill code Dmitry Baryshkov
2023-02-08 22:34   ` Abhinav Kumar
2023-02-09  0:53     ` Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 26/27] drm/msm/dpu: split pipe handling from _dpu_crtc_blend_setup_mixer Dmitry Baryshkov
2023-02-08 23:44   ` Abhinav Kumar
2023-02-08 23:47     ` Dmitry Baryshkov
2023-03-03 12:18     ` Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 27/27] drm/msm/dpu: add support for wide planes Dmitry Baryshkov
2023-02-09  2:19   ` Abhinav Kumar
2023-02-09 11:45     ` Dmitry Baryshkov
2023-02-09 19:25       ` Abhinav Kumar
2023-02-09 21:23         ` Dmitry Baryshkov
2023-02-09 22:12           ` [Freedreno] " Abhinav Kumar
2023-02-10  0:09             ` Dmitry Baryshkov
2023-02-10  1:12               ` Abhinav Kumar
2023-02-10  2:46                 ` Dmitry Baryshkov
2023-02-03 18:24 ` [PATCH v3 00/27] drm/msm/dpu: wide planes support Dmitry Baryshkov

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=84781db7-b3f2-2bc2-511f-f07e05a428de@linaro.org \
    --to=dmitry.baryshkov@linaro.org \
    --cc=airlied@gmail.com \
    --cc=andersson@kernel.org \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=quic_abhinavk@quicinc.com \
    --cc=robdclark@gmail.com \
    --cc=sean@poorly.run \
    --cc=swboyd@chromium.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;
as well as URLs for NNTP newsgroup(s).