All of lore.kernel.org
 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


WARNING: multiple messages have this Message-ID (diff)
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: freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
	Bjorn Andersson <andersson@kernel.org>,
	dri-devel@lists.freedesktop.org,
	Stephen Boyd <swboyd@chromium.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: 176+ 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 ` 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 18:21   ` Dmitry Baryshkov
2023-02-03 19:31   ` Abhinav Kumar
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   ` 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   ` 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   ` 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 18:21   ` Dmitry Baryshkov
2023-02-03 19:34   ` Abhinav Kumar
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   ` 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   ` 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   ` 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 18:21   ` Dmitry Baryshkov
2023-02-03 19:36   ` Abhinav Kumar
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 18:21   ` Dmitry Baryshkov
2023-02-03 20:36   ` Abhinav Kumar
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 18:21   ` Dmitry Baryshkov
2023-02-03 20:37   ` Abhinav Kumar
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   ` 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   ` 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 18:21   ` Dmitry Baryshkov
2023-02-03 20:42   ` Abhinav Kumar
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 18:21   ` Dmitry Baryshkov
2023-02-03 22:44   ` Abhinav Kumar
2023-02-03 22:44     ` Abhinav Kumar
2023-02-03 22:55     ` Dmitry Baryshkov
2023-02-03 22:55       ` Dmitry Baryshkov
2023-02-14 23:25       ` Abhinav Kumar
2023-02-14 23:25         ` Abhinav Kumar
2023-02-15  0:08         ` Dmitry Baryshkov
2023-02-15  0:08           ` Dmitry Baryshkov
2023-03-03 11:43           ` Dmitry Baryshkov [this message]
2023-03-03 11:43             ` Dmitry Baryshkov
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 18:21   ` Dmitry Baryshkov
2023-02-03 22:57   ` Abhinav Kumar
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 18:21   ` Dmitry Baryshkov
2023-02-03 23:07   ` Abhinav Kumar
2023-02-03 23:07     ` Abhinav Kumar
2023-02-03 23:20     ` Dmitry Baryshkov
2023-02-03 23:20       ` Dmitry Baryshkov
2023-02-08 23:09       ` Abhinav Kumar
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 18:21   ` Dmitry Baryshkov
2023-02-03 23:35   ` Abhinav Kumar
2023-02-03 23:35     ` Abhinav Kumar
2023-02-04  2:29     ` Dmitry Baryshkov
2023-02-04  2:29       ` Dmitry Baryshkov
2023-02-04  2:43       ` Abhinav Kumar
2023-02-04  2:43         ` Abhinav Kumar
2023-02-04  4:10         ` Dmitry Baryshkov
2023-02-04  4:10           ` Dmitry Baryshkov
2023-02-04  5:10           ` Abhinav Kumar
2023-02-04  5:10             ` Abhinav Kumar
2023-02-04 10:43             ` Dmitry Baryshkov
2023-02-04 10:43               ` Dmitry Baryshkov
2023-02-04 18:35               ` Abhinav Kumar
2023-02-04 18:35                 ` Abhinav Kumar
2023-02-04 21:08                 ` Dmitry Baryshkov
2023-02-04 21:08                   ` Dmitry Baryshkov
2023-02-04 23:20                   ` Abhinav Kumar
2023-02-04 23:20                     ` Abhinav Kumar
2023-02-05  0:29                     ` Dmitry Baryshkov
2023-02-05  0:29                       ` Dmitry Baryshkov
2023-02-05  0:36                       ` Abhinav Kumar
2023-02-05  0:36                         ` Abhinav Kumar
2023-02-08 23:53                         ` Dmitry Baryshkov
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-03 18:21   ` Dmitry Baryshkov
2023-02-06 18:48   ` Abhinav Kumar
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-03 18:21   ` Dmitry Baryshkov
2023-02-06 19:07   ` Abhinav Kumar
2023-02-06 19:07     ` Abhinav Kumar
2023-02-16 16:49     ` Dmitry Baryshkov
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-03 18:21   ` Dmitry Baryshkov
2023-02-06 22:40   ` Abhinav Kumar
2023-02-06 22:40     ` Abhinav Kumar
2023-02-07  0:27     ` Dmitry Baryshkov
2023-02-07  0:27       ` Dmitry Baryshkov
2023-02-07  0:42       ` Abhinav Kumar
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-03 18:21   ` Dmitry Baryshkov
2023-02-07  0:22   ` Abhinav Kumar
2023-02-07  0:22     ` Abhinav Kumar
2023-02-09  0:49     ` Dmitry Baryshkov
2023-02-09  0:49       ` Dmitry Baryshkov
2023-02-09  0:51     ` Dmitry Baryshkov
2023-02-09  0:51       ` Dmitry Baryshkov
2023-02-09 11:46     ` 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-03 18:21   ` Dmitry Baryshkov
2023-02-07 17:49   ` Abhinav Kumar
2023-02-07 17:49     ` Abhinav Kumar
2023-02-07 17:51     ` Dmitry Baryshkov
2023-02-07 17:51       ` Dmitry Baryshkov
2023-02-07 17:57       ` Abhinav Kumar
2023-02-07 17:57         ` Abhinav Kumar
2023-02-07 17:59         ` Dmitry Baryshkov
2023-02-07 17:59           ` Dmitry Baryshkov
2023-02-07 18:08           ` Abhinav Kumar
2023-02-07 18:08             ` Abhinav Kumar
2023-02-07 19:51             ` Dmitry Baryshkov
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-03 18:21   ` Dmitry Baryshkov
2023-02-07 20:05   ` Abhinav Kumar
2023-02-07 20:05     ` Abhinav Kumar
2023-02-07 20:44     ` Dmitry Baryshkov
2023-02-07 20:44       ` Dmitry Baryshkov
2023-02-07 20:57       ` Abhinav Kumar
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-03 18:21   ` Dmitry Baryshkov
2023-02-08 22:34   ` Abhinav Kumar
2023-02-08 22:34     ` Abhinav Kumar
2023-02-09  0:53     ` Dmitry Baryshkov
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-03 18:21   ` Dmitry Baryshkov
2023-02-08 23:44   ` Abhinav Kumar
2023-02-08 23:44     ` Abhinav Kumar
2023-02-08 23:47     ` Dmitry Baryshkov
2023-02-08 23:47       ` Dmitry Baryshkov
2023-03-03 12:18     ` 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-03 18:21   ` Dmitry Baryshkov
2023-02-09  2:19   ` Abhinav Kumar
2023-02-09  2:19     ` Abhinav Kumar
2023-02-09 11:45     ` Dmitry Baryshkov
2023-02-09 11:45       ` Dmitry Baryshkov
2023-02-09 19:25       ` Abhinav Kumar
2023-02-09 19:25         ` Abhinav Kumar
2023-02-09 21:23         ` Dmitry Baryshkov
2023-02-09 21:23           ` Dmitry Baryshkov
2023-02-09 22:12           ` [Freedreno] " Abhinav Kumar
2023-02-09 22:12             ` Abhinav Kumar
2023-02-10  0:09             ` Dmitry Baryshkov
2023-02-10  0:09               ` Dmitry Baryshkov
2023-02-10  1:12               ` Abhinav Kumar
2023-02-10  1:12                 ` Abhinav Kumar
2023-02-10  2:46                 ` Dmitry Baryshkov
2023-02-10  2:46                   ` Dmitry Baryshkov
2023-02-03 18:24 ` [PATCH v3 00/27] drm/msm/dpu: wide planes support Dmitry Baryshkov
2023-02-03 18:24   ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.