From: Manasi Navare <manasi.d.navare@intel.com>
To: intel-gfx@lists.freedesktop.org
Cc: daniel.vetter@intel.com
Subject: Uevent for retraining in case of link training failure in atomic commit phase
Date: Sun, 16 Oct 2016 22:51:30 -0700 [thread overview]
Message-ID: <20161017055130.GA15654@intel.com> (raw)
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.
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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next reply other threads:[~2016-10-17 5:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-17 5:51 Manasi Navare [this message]
2016-10-17 7:44 ` Uevent for retraining in case of link training failure in atomic commit phase Daniel Vetter
2016-10-17 10:33 ` Ville Syrjälä
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=20161017055130.GA15654@intel.com \
--to=manasi.d.navare@intel.com \
--cc=daniel.vetter@intel.com \
--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