From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: Abhinav Kumar <quic_abhinavk@quicinc.com>,
Kuogee Hsieh <quic_khsieh@quicinc.com>,
robdclark@gmail.com, sean@poorly.run, swboyd@chromium.org,
dianders@chromium.org, vkoul@kernel.org, daniel@ffwll.ch,
airlied@gmail.com, agross@kernel.org, andersson@kernel.org
Cc: quic_sbillaka@quicinc.com, freedreno@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/msm/dpu: always program dsc active bits
Date: Wed, 12 Apr 2023 02:36:50 +0300 [thread overview]
Message-ID: <c0161f2b-b8cb-4dd3-8cec-a2dba40ff924@linaro.org> (raw)
In-Reply-To: <ec045d6b-4ffd-0f8c-4011-8db45edc6978@quicinc.com>
On 12/04/2023 02:32, Abhinav Kumar wrote:
>
>
> On 4/11/2023 3:17 PM, Dmitry Baryshkov wrote:
>> On 12/04/2023 00:04, Kuogee Hsieh wrote:
>>> In current code, the dsc active bits are set only if the cfg->dsc is
>>> set.
>>> However, for displays which are hot-pluggable, there can be a use-case
>>> of disconnecting a DSC supported sink and connecting a non-DSC sink.
>>>
>>> For those cases we need to clear DSC active bits during teardown.
>>
>> Please correct me if I'm wrong here, shouldn't we start using
>> reset_intf_cfg() during teardown / unplug?
>>
>
> This is actually a good point. Since PSR landed this cycle, we are doing
> dpu_encoder_helper_phys_cleanup() even for video mode path,
>
> 22cb02bc96ff ("drm/msm/disp/dpu: reset the datapath after timing engine
> disable")
>
> I was doing it only for writeback path as I had not validated video mode
> enough with the dpu_encoder_helper_phys_cleanup() API.
>
> But looking closely, I think there is an issue with the flush logic in
> that API for video mode.
>
> The reset API, calls a ctl->ops.trigger_flush(ctl); but its getting
> called after timing engine turns off today so this wont take any effect.
>
> We need to improve that API and add the missing pieces for it to work
> correctly with video mode and re-validate the issue for which PSR made
> that change. So needs more work there.
>
> This change works because the timing engine is enabled right after this
> call and will trigger the flush with it.
>
> The only drawback of this change is DSC_ACTIVE will always get written
> to either with 0 or the right value but only once during enable.
>
> I think this change is fine till we finish the rest of the pieces. We
> can add the if (cfg->dsc) back to this when we fix the reset_intf_cfg()
> to handle DSC and dpu_encoder_helper_phys_cleanup() to handle flush
> correctly.
I'd agree here. Then a FIXME comment would be nice.
>
> I will take up that work.
>
>>>
>>> Fixes: ede3c6bb00c ("drm/msm/disp/dpu1: Add DSC support in hw_ctl")
>>> Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com>
>>> ---
>>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 7 +++----
>>> 1 file changed, 3 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
>>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
>>> index bbdc95c..88e4efe 100644
>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
>>> @@ -541,10 +541,9 @@ static void dpu_hw_ctl_intf_cfg_v1(struct
>>> dpu_hw_ctl *ctx,
>>> if (cfg->merge_3d)
>>> DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
>>> BIT(cfg->merge_3d - MERGE_3D_0));
>>> - if (cfg->dsc) {
>>> - DPU_REG_WRITE(&ctx->hw, CTL_FLUSH, DSC_IDX);
>>> - DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
>>> - }
>>> +
>>> + DPU_REG_WRITE(&ctx->hw, CTL_FLUSH, DSC_IDX);
>>> + DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
>>> }
>>> static void dpu_hw_ctl_intf_cfg(struct dpu_hw_ctl *ctx,
>>
--
With best wishes
Dmitry
prev parent reply other threads:[~2023-04-11 23:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-11 21:04 [PATCH] drm/msm/dpu: always program dsc active bits Kuogee Hsieh
2023-04-11 21:39 ` Abhinav Kumar
2023-04-11 22:14 ` Marijn Suijten
2023-04-11 23:45 ` Abhinav Kumar
2023-04-12 7:24 ` Marijn Suijten
2023-04-12 17:33 ` Abhinav Kumar
2023-04-14 7:35 ` Marijn Suijten
2023-04-14 15:48 ` Abhinav Kumar
2023-04-14 17:34 ` Marijn Suijten
2023-04-14 17:57 ` [Freedreno] " Abhinav Kumar
2023-04-14 23:11 ` Marijn Suijten
2023-04-14 23:51 ` Abhinav Kumar
2023-04-27 20:32 ` Marijn Suijten
2023-04-11 22:17 ` Dmitry Baryshkov
2023-04-11 23:32 ` Abhinav Kumar
2023-04-11 23:36 ` Dmitry Baryshkov [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=c0161f2b-b8cb-4dd3-8cec-a2dba40ff924@linaro.org \
--to=dmitry.baryshkov@linaro.org \
--cc=agross@kernel.org \
--cc=airlied@gmail.com \
--cc=andersson@kernel.org \
--cc=daniel@ffwll.ch \
--cc=dianders@chromium.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_abhinavk@quicinc.com \
--cc=quic_khsieh@quicinc.com \
--cc=quic_sbillaka@quicinc.com \
--cc=robdclark@gmail.com \
--cc=sean@poorly.run \
--cc=swboyd@chromium.org \
--cc=vkoul@kernel.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