From: Manasi Navare <manasi.d.navare@intel.com>
To: Puthikorn Voravootivat <puthik@chromium.org>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>,
"Ville Syrjälä" <ville.syrjala@intel.com>,
"Dhinakaran Pandiyan" <dhinakaran.pandiyan@intel.com>,
"Rich Chen" <rich.chen@intel.com>,
"Rodrigo Vivi" <rodrigo.vivi@intel.com>
Subject: Re: [PATCH] drm/i915: Don't recheck link status for eDP display.
Date: Tue, 17 Oct 2017 16:29:12 -0700 [thread overview]
Message-ID: <20171017232912.GC30469@intel.com> (raw)
In-Reply-To: <CANCcNXePb=d92eWso2rp5y4h0Dg=RbzManBwQbtvgcref6-HBw@mail.gmail.com>
On Tue, Oct 17, 2017 at 03:46:00PM -0700, Puthikorn Voravootivat wrote:
> I tried https://patchwork.freedesktop.org/series/30670/ but it doesn't work.
>
> > When you see the display blinking, do you know for sure that drm_dp_channel_eq_ok() returns false?
> Yes. Repro is running "modetest" while PSR is on (easier to repro with
> PSR2 but PSR1 is fine too)
>
> > lane_align = dp_link_status(link_status,
> > DP_LANE_ALIGN_STATUS_UPDATED);
> > if ((lane_align & DP_INTERLANE_ALIGN_DONE) == 0)
> > return false;
>
> I always got lane_align = 128 (DP_LINK_STATUS_UPDATED)
> So drm_dp_channel_eq_ok() always return false.
Hmm, it looks like there is a bug somewhere else that is causing the
link status to get updated and bit LINK_STATUS_UPDATED from LANE_ALIGN_STATUS_UPDATED register
is not being read so not being cleared causing the link to be retrained again.
So I still feel that this patch is a workaround for another bug in the PSR code.
But I will let others comment on this.
Regards
Manasi
>
> If I disable PSR, drm_dp_channel_eq_ok() will return true and no
> blinking occurs.
>
> On Tue, Oct 17, 2017 at 2:21 PM, Manasi Navare
> <manasi.d.navare@intel.com> wrote:
> > On Tue, Oct 17, 2017 at 02:01:56PM -0700, Puthikorn Voravootivat wrote:
> >> intel_dp_long_pulse() is always checking link status because
> >> there has been known issues of link loss triggerring long pulse.
> >>
> >> However this is not needed for eDP display since we won't have
> >> link loss for internal display. Also there are reports that
> >> screens are flickering during link status check. (repro by
> >> running modetest command repeatedly)
> >>
> >> Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org>
> >> ---
> >> drivers/gpu/drm/i915/intel_dp.c | 7 ++++++-
> >> 1 file changed, 6 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> >> index 4b65cf137f79..75a77ef257e2 100644
> >> --- a/drivers/gpu/drm/i915/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >> @@ -4763,7 +4763,8 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
> >> */
> >> status = connector_status_disconnected;
> >> goto out;
> >> - } else {
> >> + } else if (status != connector_status_connected ||
> >> + intel_encoder->type != INTEL_OUTPUT_EDP) {
> >> /*
> >> * If display is now connected check links status,
> >> * there has been known issues of link loss triggerring
> >> @@ -4775,6 +4776,10 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
> >> * going back up soon after. And once that happens we must
> >> * retrain the link to get a picture. That's in case no
> >> * userspace component reacted to intermittent HPD dip.
> >> + *
> >> + * Skip checking links status for connected eDP display.
> >> + * There are known issues of display blinking during checking
> >> + * link status and we don't have link loss for internal display.
> >> */
> >
> > Inside intel_dp_check_link_status(), it actually checks if link status is good by
> > checking both clock recovery and Channel EQ bits in DPCD, only then it will retrain.
> > So in case of eDP panel, if there is no link loss then it should always return link
> > status as good and not retrain.
> > So IMHO I dont think we need to explicitly avoid this for eDP.
> >
> > When you see the display blinking, do you know for sure that drm_dp_channel_eq_ok() returns false?
> > Also look at this patch: https://patchwork.freedesktop.org/series/30670/
> > This makes sure none of the eDP training parameters change unless link is bad. So with this patch, if the
> > link is good then it should never retrain even in intel_dp_check_link_status() for eDP.
> >
> > Manasi
> >> intel_dp_check_link_status(intel_dp);
> >> }
> >> --
> >> 2.15.0.rc0.271.g36b669edcc-goog
> >>
> >> _______________________________________________
> >> Intel-gfx mailing list
> >> Intel-gfx@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2017-10-17 23:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-17 21:01 [PATCH] drm/i915: Don't recheck link status for eDP display Puthikorn Voravootivat
2017-10-17 21:21 ` Manasi Navare
2017-10-17 22:46 ` Puthikorn Voravootivat
2017-10-17 23:29 ` Manasi Navare [this message]
2017-10-17 23:31 ` Puthikorn Voravootivat
2017-10-17 23:39 ` Rodrigo Vivi
2017-10-17 23:43 ` Puthikorn Voravootivat
2017-10-17 21:44 ` ✓ Fi.CI.BAT: success for " Patchwork
2017-10-18 9:36 ` ✓ Fi.CI.IGT: " Patchwork
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=20171017232912.GC30469@intel.com \
--to=manasi.d.navare@intel.com \
--cc=dhinakaran.pandiyan@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=puthik@chromium.org \
--cc=rich.chen@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=ville.syrjala@intel.com \
/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.