public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Manasi Navare <manasi.d.navare@intel.com>
Cc: daniel.vetter@intel.com, intel-gfx@lists.freedesktop.org
Subject: Re: Uevent for retraining in case of link training failure in atomic commit phase
Date: Mon, 17 Oct 2016 13:33:58 +0300	[thread overview]
Message-ID: <20161017103358.GK4329@intel.com> (raw)
In-Reply-To: <20161017055130.GA15654@intel.com>

On Sun, Oct 16, 2016 at 10:51:30PM -0700, Manasi Navare wrote:
> Hi,
> 
> I am working on adding a link rate fallback in case of link training failure.
> If the link training fails at a specific link rate/lane count in atomic
> commit phase, I validate the modes again based on the link rate lower than
> the failed link rate and prune the invalid modes accordingly to update the
> connector->modes list. I then send a hotplug uevent to the userspace, expecting
> it to detect the change in the mode list and trigger a modeset during which
> the link would be retrained to a lower link rate.
> 
> After looking at the userspace debug logs, I see that after it recieves this
> uevent on link failure, xf86-video-intel/src/sna/sna_mode_display.c/sna_mode_discover(),
> calls output_check_status() which only detects a state change if it is changed from 
> connected to disconnected or vice versa. So change in the modelist does not get detected 
> as connector status changed and it notifies "state retained", does not call RRGetInfo() 
> and does not trigger a new modeset.

Hmm. The code definitely checks if the number of modes has changed. Oh,
but maybe there's just a little bug:

 	if (output->num_modes != compat_conn.conn.count_modes)
-	                return true;
+	                return false;

Chris, does that look right?

> 
> If in case of link train failure, I force the connector status to be disconnected
> then it clears the state, disables all the PLLs, triggers a new modeset. However during
> this time, the CTS test times out (10ms) and hence compliance fails.
> 
> Is there any other way, we can force the userspace to detect a change in the connector
> state so that it triggers a full modeset without forcing the connector state to be disconnected?
> 
> The pieces of  /var/log/Xorg.0.log that capture the sna_mode_discover are pasted here:
> http://paste.ubuntu.com/23337284/
> In this log, the third call to sna_mode_discover maps to the uevent sent due to link
> failure where it indicates state retained and does not do anything further.
> 
> The Kernel dmesg log in case of forcing the connector status to disconnected is:
> http://paste.ubuntu.com/23337285/
> 
> Please let me know if any of you have suggestions, I am not a userspace expert.
> This test is done with Ubuntu 16.04 and CTS run using DPR-120 test 4.3.1.3
> 
> Regards
> Manasi

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

      parent reply	other threads:[~2016-10-17 10:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-17  5:51 Uevent for retraining in case of link training failure in atomic commit phase Manasi Navare
2016-10-17  7:44 ` Daniel Vetter
2016-10-17 10:33 ` Ville Syrjälä [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=20161017103358.GK4329@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=daniel.vetter@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=manasi.d.navare@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox