public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Manasi Navare <manasi.d.navare@intel.com>
To: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: daniel.vetter@intel.com
Subject: Do no reset the max link parameters when userspace reprobes modes
Date: Mon, 6 Feb 2017 17:35:17 -0800	[thread overview]
Message-ID: <20170207013516.GA25740@intel.com> (raw)

Hi,

I am working on a solution for handling link failures during or after
the modeset. 

In case of link failure, the max link rate/lane count values
are updated to lower link rate/lane count as per the spec and uevent is
sent to the userspace with link-status BAD. The userspace is expected to first
retry the existing mode and do a a full reprobe if this fails.

When userspace reprobes the modes, it calls drmModeGetConnector() IOCTL, that
eventually calls drm_helper_probe_single_connector_modes(). This helper function
calls the connector->func->detect() which in case of i915 calls intel_dp_detect()
which calls intel_dp_long_pulse() that resets the max_link_rate and max_link_lane_count
values. 

Now during the link training retry, it uses the reset values of link rate/lane count
instead of using the lowered link rate/lane count values from link failure.
For this to work properly, we should not reset the link rate/lane count values
during the fill_modes() operation from userspace. However the current driver calls
the long pulse handler again during fill_modes and resets all the values as per DPCD reads
which fails to retrain the link at lower rate.

How can we handle this situation? Do we need to call long pulse handler
again during fill_modes()? Any ideas/suggestions?

Regards
Manasi 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

                 reply	other threads:[~2017-02-07  1:35 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20170207013516.GA25740@intel.com \
    --to=manasi.d.navare@intel.com \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.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