[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e3579cea-1764-26ff-ba9d-6eb23a0aaef0@linaro.org>
Date: Fri, 12 May 2023 21:50:37 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Abhinav Kumar <quic_abhinavk@...cinc.com>,
Kuogee Hsieh <quic_khsieh@...cinc.com>,
dri-devel@...ts.freedesktop.org, robdclark@...il.com,
sean@...rly.run, swboyd@...omium.org, dianders@...omium.org,
vkoul@...nel.org, daniel@...ll.ch, airlied@...il.com,
agross@...nel.org, andersson@...nel.org
Cc: quic_jesszhan@...cinc.com, quic_sbillaka@...cinc.com,
marijn.suijten@...ainline.org, freedreno@...ts.freedesktop.org,
linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 6/8] drm/msm/dpu: separate DSC flush update out of
interface
On 12/05/2023 21:47, Abhinav Kumar wrote:
>
>
> On 5/12/2023 11:21 AM, Dmitry Baryshkov wrote:
>> On 12/05/2023 21:00, Kuogee Hsieh wrote:
>>> Current DSC flush update is piggyback inside dpu_hw_ctl_intf_cfg_v1().
>>> This patch separates DSC flush away from dpu_hw_ctl_intf_cfg_v1() by
>>> adding dpu_hw_ctl_update_pending_flush_dsc_v1() to handle both per
>>> DSC engine and DSC flush bits at same time to make it consistent with
>>> the location of flush programming of other dpu sub blocks.
>>>
>>> Signed-off-by: Kuogee Hsieh <quic_khsieh@...cinc.com>
>>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
>>> ---
>>> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 14 ++++++++++++--
>>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 22
>>> ++++++++++++++++------
>>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 10 ++++++++++
>>> 3 files changed, 38 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>>> index ffa6f04..5cae70e 100644
>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>>> @@ -1834,12 +1834,18 @@ dpu_encoder_dsc_initial_line_calc(struct
>>> drm_dsc_config *dsc,
>>> return DIV_ROUND_UP(total_pixels, dsc->slice_width);
>>> }
>>> -static void dpu_encoder_dsc_pipe_cfg(struct dpu_hw_dsc *hw_dsc,
>>> +static void dpu_encoder_dsc_pipe_cfg(struct dpu_encoder_virt *dpu_enc,
>>> + struct dpu_hw_dsc *hw_dsc,
>>> struct dpu_hw_pingpong *hw_pp,
>>> struct drm_dsc_config *dsc,
>>> u32 common_mode,
>>> u32 initial_lines)
>>> {
>>> + struct dpu_encoder_phys *cur_master = dpu_enc->cur_master;
>>> + struct dpu_hw_ctl *ctl;
>>> +
>>> + ctl = cur_master->hw_ctl;
>>
>> Just for my understanding: if we have a bonded DSI @ sdm845, should
>> both flashes go to the master CTL or each flush should go to the
>> corresponding CTL?
>>
>
> Is this question for DSC or just general question about flush?
>
> I dont see an explicit DSC flush needed in sdm845 at the ctl level.
>
> If the question is about general flush involving two control paths, we
> need to combine the flushes and they goto the master only. Please refer
> to below part in sde_encoder.c
And this is because we have a single CTL to flush on sm8150+, isn't it?
>
> 4243 /* for split flush, combine pending flush masks and send to
> master */
> 4244 if (pending_flush.pending_flush_mask && sde_enc->cur_master) {
> 4245 ctl = sde_enc->cur_master->hw_ctl;
> 4246 if (config_changed && ctl->ops.reg_dma_flush)
> 4247 ctl->ops.reg_dma_flush(ctl, is_regdma_blocking);
> 4248 _sde_encoder_trigger_flush(&sde_enc->base,
> sde_enc->cur_master,
> 4249 &pending_flush,
> 4250 config_changed);
> 4251 }
--
With best wishes
Dmitry
Powered by blists - more mailing lists