Re: [Intel-gfx] Uevent for retraining in case of link training failure in atomic commit phase
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
Re: [Intel-gfx] Uevent for retraining in case of link training failure in atomic commit phase
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 (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
[Intel-gfx] Uevent for retraining in case of link training failure in atomic commit phase
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
