The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Abhinav Kumar <quic_abhinavk@quicinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	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: Tue, 11 Apr 2023 16:32:07 -0700	[thread overview]
Message-ID: <ec045d6b-4ffd-0f8c-4011-8db45edc6978@quicinc.com> (raw)
In-Reply-To: <30585d08-88ca-e3a9-6f83-128d49d1d1fc@linaro.org>



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 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,
> 

  reply	other threads:[~2023-04-11 23:32 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 [this message]
2023-04-11 23:36     ` 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=ec045d6b-4ffd-0f8c-4011-8db45edc6978@quicinc.com \
    --to=quic_abhinavk@quicinc.com \
    --cc=agross@kernel.org \
    --cc=airlied@gmail.com \
    --cc=andersson@kernel.org \
    --cc=daniel@ffwll.ch \
    --cc=dianders@chromium.org \
    --cc=dmitry.baryshkov@linaro.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_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