From: Kuogee Hsieh <quic_khsieh@quicinc.com>
To: Stephen Boyd <swboyd@chromium.org>, <agross@kernel.org>,
<airlied@linux.ie>, <bjorn.andersson@linaro.org>,
<daniel@ffwll.ch>, <dianders@chromium.org>,
<dmitry.baryshkov@linaro.org>, <robdclark@gmail.com>,
<sean@poorly.run>, <vkoul@kernel.org>
Cc: <quic_abhinavk@quicinc.com>, <quic_aravindh@quicinc.com>,
<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/dp: force link training for display resolution change
Date: Fri, 27 May 2022 08:25:42 -0700 [thread overview]
Message-ID: <1f325de0-a10e-27a8-ce7a-9ecaed75465c@quicinc.com> (raw)
In-Reply-To: <CAE-0n53Nr7o=ZmSsBWOjUxCKxMYNrVwuVdbdL0wG7WZyrPo4Yw@mail.gmail.com>
On 5/26/2022 5:07 PM, Stephen Boyd wrote:
> Quoting Kuogee Hsieh (2022-05-26 10:26:18)
>> During display resolution changes display have to be disabled first
>> followed by display enable with new resolution. This patch force
>> main link always be retrained during display enable procedure to
>> simplify implementation instead of manually kicking of irq_hpd
>> handle.
> How is that better? Can you please describe how it improves things? I
> suppose it avoids some round trips through the event queue just to turn
> on the display?
This try to fix customer issues which only happen on one particular
panel which fails on display resolution changes sometimes.
I will add more description.
>
>> Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com>
> Any Fixes tag? Or it's not fixing anything, just making things simpler?
will add.
>
>> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
>> index 5ddb4e8..8b71013 100644
>> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
>> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
>> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.h b/drivers/gpu/drm/msm/dp/dp_ctrl.h
>> index 2433edb..dcc7af21 100644
>> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.h
>> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.h
>> @@ -20,7 +20,7 @@ struct dp_ctrl {
>> };
>>
>> int dp_ctrl_on_link(struct dp_ctrl *dp_ctrl);
>> -int dp_ctrl_on_stream(struct dp_ctrl *dp_ctrl);
>> +int dp_ctrl_on_stream(struct dp_ctrl *dp_ctrl, bool force_link_train);
> Can we have another API like dp_ctrl_on_stream_retrain()? Or name
> 'force_link_train' to 'retrain'?
>
>> int dp_ctrl_off_link_stream(struct dp_ctrl *dp_ctrl);
>> int dp_ctrl_off(struct dp_ctrl *dp_ctrl);
>> void dp_ctrl_push_idle(struct dp_ctrl *dp_ctrl);
>> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
>> index bfc6581..9246421 100644
>> --- a/drivers/gpu/drm/msm/dp/dp_display.c
>> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
>> @@ -892,7 +892,7 @@ static int dp_display_enable(struct dp_display_private *dp, u32 data)
> Any reason why dp_display_enable() is forward declared and why it takes
> a u32 data argument? It's not part of the eventqueue calling code from
> what I can tell so we should be able to rename 'data' to 'retrain_link'?
>
>> return 0;
>> }
>>
>> - rc = dp_ctrl_on_stream(dp->ctrl);
>> + rc = dp_ctrl_on_stream(dp->ctrl, data);
>> if (!rc)
>> dp_display->power_on = true;
>>
>> @@ -1594,6 +1594,7 @@ int msm_dp_display_enable(struct msm_dp *dp, struct drm_encoder *encoder)
>> int rc = 0;
>> struct dp_display_private *dp_display;
>> u32 state;
>> + bool force_link_train = false;
>>
>> dp_display = container_of(dp, struct dp_display_private, dp_display);
>> if (!dp_display->dp_mode.drm_mode.clock) {
>> @@ -1622,10 +1623,12 @@ int msm_dp_display_enable(struct msm_dp *dp, struct drm_encoder *encoder)
>>
>> state = dp_display->hpd_state;
>>
>> - if (state == ST_DISPLAY_OFF)
>> + if (state == ST_DISPLAY_OFF) {
>> dp_display_host_phy_init(dp_display);
>> + force_link_train = 1;
> Use true instead of 1 if the type is a bool please.
>
>> + }
>>
>> - dp_display_enable(dp_display, 0);
>> + dp_display_enable(dp_display, force_link_train);
>>
>> rc = dp_display_post_enable(dp);
>> if (rc) {
prev parent reply other threads:[~2022-05-27 15:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-26 17:26 [PATCH] drm/msm/dp: force link training for display resolution change Kuogee Hsieh
2022-05-27 0:07 ` Stephen Boyd
2022-05-27 15:25 ` Kuogee Hsieh [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=1f325de0-a10e-27a8-ce7a-9ecaed75465c@quicinc.com \
--to=quic_khsieh@quicinc.com \
--cc=agross@kernel.org \
--cc=airlied@linux.ie \
--cc=bjorn.andersson@linaro.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_abhinavk@quicinc.com \
--cc=quic_aravindh@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;
as well as URLs for NNTP newsgroup(s).