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
> Regards
> Manasi

Ville Syrjälä
Intel OTC
Intel-gfx mailing list

Reply via email to