From: Martin Peres <martin.peres@linux.intel.com>
To: xorg-devel@lists.x.org
Cc: Manasi Navare <manasi.d.navare@intel.com>,
dri-devel@lists.freedesktop.org
Subject: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD
Date: Thu, 26 Jan 2017 14:37:28 +0200 [thread overview]
Message-ID: <20170126123728.5680-1-martin.peres@linux.intel.com> (raw)
Despite all the careful planing of the kernel, a link may become
insufficient to handle the currently-set mode. At this point, the
kernel should mark this particular configuration as being broken
and potentially prune the mode before setting the offending connector's
link-status to BAD and send the userspace a hotplug event. This may
happen right after a modeset or later on.
When available, we should use the link-status information to reset
the wanted mode.
Signed-off-by: Martin Peres <martin.peres@linux.intel.com>
---
WARNING: The patches have not been merged in the kernel yet, so this patch is
merely an RFC.
This patch is the result of discussions happening mostly in DRI-devel and
Intel-GFX on how to handle link training failures. I would advise reading the
thread [0] first and then this thread [1] which explain in great length why this
is needed and why the selected approach seems to be the best.
The relevant kernel patches + this patch are enough to pass the relevant
DisplayPort compliance tests, provided that the Desktop Environment or another
program ([2]?) provides the initial modesetting on hotplug.
Would this patch be acceptable to you? Any comments or suggestions?
[0] https://lists.freedesktop.org/archives/dri-devel/2016-November/123366.html
[1] https://lists.freedesktop.org/archives/dri-devel/2016-November/124736.html
[2] https://cgit.freedesktop.org/~mperes/auto-randr/
hw/xfree86/drivers/modesetting/drmmode_display.c | 51 ++++++++++++++++++++++++
1 file changed, 51 insertions(+)
diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 6e755e9482..3144620c67 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -2262,6 +2262,10 @@ drmmode_setup_colormap(ScreenPtr pScreen, ScrnInfoPtr pScrn)
}
#ifdef CONFIG_UDEV_KMS
+
+#define DRM_MODE_LINK_STATUS_GOOD 0
+#define DRM_MODE_LINK_STATUS_BAD 1
+
static void
drmmode_handle_uevents(int fd, void *closure)
{
@@ -2281,6 +2285,49 @@ drmmode_handle_uevents(int fd, void *closure)
if (!found)
return;
+ /* Try to re-set the mode on all the connectors with a BAD link-state:
+ * This may happen if a link degrades and a new modeset is necessary, using
+ * different link-training parameters. If the kernel found that the current
+ * mode is not achievable anymore, it should have pruned the mode before
+ * sending the hotplug event. Try to re-set the currently-set mode to keep
+ * the display alive, this will fail if the mode has been pruned.
+ * In any case, we will send randr events for the Desktop Environment to
+ * deal with it, if it wants to.
+ */
+ for (i = 0; i < config->num_output; i++) {
+ xf86OutputPtr output = config->output[i];
+ drmmode_output_private_ptr drmmode_output = output->driver_private;
+ uint32_t con_id = drmmode_output->mode_output->connector_id;
+ drmModeConnectorPtr koutput;
+
+ /* Get an updated view of the properties for the current connector and
+ * look for the link-status property
+ */
+ koutput = drmModeGetConnectorCurrent(drmmode->fd, con_id);
+ for (j = 0; koutput && j < koutput->count_props; j++) {
+ drmModePropertyPtr props;
+ props = drmModeGetProperty(drmmode->fd, koutput->props[j]);
+ if (props && props->flags & DRM_MODE_PROP_ENUM &&
+ !strcmp(props->name, "link-status") &&
+ koutput->prop_values[j] == DRM_MODE_LINK_STATUS_BAD) {
+ xf86CrtcPtr crtc = output->crtc;
+ if (!crtc)
+ continue;
+
+ /* the connector got a link failure, re-set the current mode */
+ drmmode_set_mode_major(crtc, &crtc->mode, crtc->rotation,
+ crtc->x, crtc->y);
+
+ xf86DrvMsg(scrn->scrnIndex, X_WARNING,
+ "hotplug event: connector %u's link-state is BAD, "
+ "tried resetting the current mode. You may be left"
+ "with a black screen if this fails...\n", con_id);
+ }
+ drmModeFreeProperty(props);
+ }
+ drmModeFreeConnector(koutput);
+ }
+
mode_res = drmModeGetResources(drmmode->fd);
if (!mode_res)
goto out;
@@ -2345,6 +2392,10 @@ out_free_res:
out:
RRGetInfo(xf86ScrnToScreen(scrn), TRUE);
}
+
+#undef DRM_MODE_LINK_STATUS_BAD
+#undef DRM_MODE_LINK_STATUS_GOOD
+
#endif
void
--
2.11.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next reply other threads:[~2017-01-26 12:37 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-26 12:37 Martin Peres [this message]
2017-01-26 17:21 ` [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD Daniel Vetter
[not found] ` <20170126172120.iflf5b5l4m4wsuus-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2017-01-31 17:08 ` Manasi Navare
2017-02-01 10:17 ` Jani Nikula
2017-01-31 20:13 ` Eric Anholt
2017-02-01 10:03 ` Jani Nikula
2017-02-01 19:58 ` Eric Anholt
2017-02-01 20:05 ` Manasi Navare
[not found] ` <20170201200512.GC21934-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-02-02 23:30 ` Martin Peres
[not found] ` <32b846ee-69c5-1dea-eed4-1bc41bb2958f-GANU6spQydw@public.gmane.org>
2017-02-03 0:30 ` Manasi Navare
2017-02-03 8:04 ` Daniel Vetter
[not found] ` <20170203080451.vrbmoaioqjyd3hhc-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2017-02-06 15:50 ` Martin Peres
[not found] ` <4f8317ff-53e8-4c2d-effa-d074b11b15e6-GANU6spQydw@public.gmane.org>
2017-02-08 16:37 ` Martin Peres
[not found] ` <069473c6-d75e-48eb-e75d-4e65e201b4fb-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-02-13 21:05 ` Eric Anholt
2017-02-13 23:14 ` Manasi Navare
[not found] ` <87k28tkdiq.fsf-omZaPlIz5HhaEpDpdNBo/KxOck334EZe@public.gmane.org>
2017-02-16 7:56 ` Martin Peres
2017-02-24 20:09 ` Manasi Navare
2017-02-26 19:42 ` Daniel Vetter
2017-02-28 4:07 ` Navare, Manasi D
2017-02-28 8:42 ` Daniel Vetter
2017-02-02 9:01 ` Daniel Vetter
2017-02-02 17:57 ` Eric Anholt
2017-02-28 8:43 ` Daniel Vetter
2017-02-01 19:55 ` Manasi Navare
[not found] ` <20170126123728.5680-1-martin.peres-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-03-27 14:12 ` Martin Peres
2017-03-31 0:37 ` Eric Anholt
2017-03-31 0:50 ` Manasi Navare
2017-03-31 20:08 ` Eric Anholt
[not found] ` <87d1cxw6nq.fsf-omZaPlIz5HhaEpDpdNBo/KxOck334EZe@public.gmane.org>
2017-03-31 20:17 ` Manasi Navare
2017-04-01 0:22 ` Eric Anholt
2017-04-02 12:28 ` Daniel Vetter
[not found] ` <20170402122809.trh7oxzz25oao4bu-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2017-04-03 2:21 ` Eric Anholt
[not found] ` <87efxamdt6.fsf-omZaPlIz5HhaEpDpdNBo/KxOck334EZe@public.gmane.org>
2017-04-03 6:25 ` Manasi Navare
2017-04-03 7:19 ` Daniel Vetter
2017-04-05 18:13 ` Manasi Navare
2017-04-06 17:15 ` Manasi Navare
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170126123728.5680-1-martin.peres@linux.intel.com \
--to=martin.peres@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=manasi.d.navare@intel.com \
--cc=xorg-devel@lists.x.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).