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,
calls output_check_status() which only detects a state change if it is changed
connected to disconnected or vice versa. So change in the modelist does not get
as connector status changed and it notifies "state retained", does not call
and does not trigger a new modeset.
If in case of link train failure, I force the connector status to be
then it clears the state, disables all the PLLs, triggers a new modeset.
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
state so that it triggers a full modeset without forcing the connector state to
The pieces of /var/log/Xorg.0.log that capture the sna_mode_discover are
In this log, the third call to sna_mode_discover maps to the uevent sent due to
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:
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 188.8.131.52
Intel-gfx mailing list