Uevent for retraining in case of link training failure in atomic commit phase

Uevent for retraining in case of link training failure in atomic commit phase

[Manasi Navare]

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

Re: Uevent for retraining in case of link training failure in atomic commit phase

[Daniel Vetter]

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.
> 
> 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?

I'd say we need to change userspace to be able to handle this. One idea I
tossed around with Chris Wilson for these kind of changes is a
connector epoch counter: Every time anything changes (mode list, link
limits, edid, mst routing, whatever) we increment that connector property.
That way userspace can just compare the old epoch value it has with the
new one, and if it changed it knows something is different with that
specific connector. And it needs to re-read all the state.

That's the only reliable way to send such changes to userspace. It's quite
a bit more workt though (since also we need to update userspace and all
that).

I think one option might be to do upfront link training (if the link isn't
on or otherwise in use) for now, at least if it's not too invasive. And
then work on the full solution with uevents and userspace changes. But I
leave the judgement on "not too invasive" up to you, Jani&Ville (since I
haven't looked at the last round of patches at all).
-Daniel

> 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

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Uevent for retraining in case of link training failure in atomic commit phase

[Ville Syrjälä]

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