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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
