All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: LKML <linux-kernel@vger.kernel.org>
Cc: DRI Development <dri-devel@lists.freedesktop.org>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Thomas Gleixner <tglx@linutronix.de>,
	Arjan van de Ven <arjan@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: [PATCH 2/2] drm/edid: report latency due to reading edids
Date: Tue,  1 Dec 2015 16:29:28 +0100	[thread overview]
Message-ID: <1448983768-22324-2-git-send-email-daniel.vetter@ffwll.ch> (raw)
In-Reply-To: <1448983768-22324-1-git-send-email-daniel.vetter@ffwll.ch>

A forced EDID read takes 22.5ms best-case, and that's per 128byte
block. HDMI screens tend to have 2-3 of those. Mutliply that by a few
outputs and then it's clear that userspace really never ever should
re-probe connector state on its own and trust the kernel to tell it
when anything changed. The only exception is a manual reprobe button that
the user must press itself (for extremely shitty KVM switches that
don't wire up hotplug handling properly).

There have been bugs in the past, but we're slowly fixing them up. To
the point even that some of the most abused interfaces (e.g. in sysfs)
have been changed to only return the cached state ever due to too much
polling by userspace.

But there's other places where we can't pull these tricks, so give
userspace the tools to notice their abuse and expose delays due to
EDID reads in latencytop.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/drm_edid.c | 27 +++++++++++++++++++--------
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c214f1246cb4..370003e0cc69 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -32,6 +32,7 @@
 #include <linux/hdmi.h>
 #include <linux/i2c.h>
 #include <linux/module.h>
+#include <linux/latencytop.h>
 #include <drm/drmP.h>
 #include <drm/drm_edid.h>
 #include <drm/drm_displayid.h>
@@ -1272,14 +1273,17 @@ struct edid *drm_do_get_edid(struct drm_connector *connector,
 	int i, j = 0, valid_extensions = 0;
 	u8 *block, *new;
 	bool print_bad_edid = !connector->bad_edid_counter || (drm_debug & DRM_UT_KMS);
+	u64 before, after;
 
 	if ((block = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
 		return NULL;
 
+	before = ktime_get_raw_ns();
+
 	/* base block fetch */
 	for (i = 0; i < 4; i++) {
 		if (get_edid_block(data, block, 0, EDID_LENGTH))
-			goto out;
+			goto none;
 		if (drm_edid_block_valid(block, 0, print_bad_edid,
 					 &connector->edid_corrupt))
 			break;
@@ -1293,11 +1297,11 @@ struct edid *drm_do_get_edid(struct drm_connector *connector,
 
 	/* if there's no extensions, we're done */
 	if (block[0x7e] == 0)
-		return (struct edid *)block;
+		goto out;
 
 	new = krealloc(block, (block[0x7e] + 1) * EDID_LENGTH, GFP_KERNEL);
 	if (!new)
-		goto out;
+		goto none;
 	block = new;
 
 	for (j = 1; j <= block[0x7e]; j++) {
@@ -1305,7 +1309,7 @@ struct edid *drm_do_get_edid(struct drm_connector *connector,
 			if (get_edid_block(data,
 				  block + (valid_extensions + 1) * EDID_LENGTH,
 				  j, EDID_LENGTH))
-				goto out;
+				goto none;
 			if (drm_edid_block_valid(block + (valid_extensions + 1)
 						 * EDID_LENGTH, j,
 						 print_bad_edid,
@@ -1329,11 +1333,11 @@ struct edid *drm_do_get_edid(struct drm_connector *connector,
 		block[0x7e] = valid_extensions;
 		new = krealloc(block, (valid_extensions + 1) * EDID_LENGTH, GFP_KERNEL);
 		if (!new)
-			goto out;
+			goto none;
 		block = new;
 	}
 
-	return (struct edid *)block;
+	goto out;
 
 carp:
 	if (print_bad_edid) {
@@ -1342,9 +1346,16 @@ carp:
 	}
 	connector->bad_edid_counter++;
 
-out:
+none:
 	kfree(block);
-	return NULL;
+	block = NULL;
+
+out:
+	after = ktime_get_raw_ns();
+
+	account_latency(DIV_ROUND_UP_ULL(after - before, 1000));
+
+	return (struct edid *)block;
 }
 EXPORT_SYMBOL_GPL(drm_do_get_edid);
 
-- 
2.5.1


WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	Daniel Vetter <daniel.vetter@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arjan van de Ven <arjan@linux.intel.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: [PATCH 2/2] drm/edid: report latency due to reading edids
Date: Tue,  1 Dec 2015 16:29:28 +0100	[thread overview]
Message-ID: <1448983768-22324-2-git-send-email-daniel.vetter@ffwll.ch> (raw)
In-Reply-To: <1448983768-22324-1-git-send-email-daniel.vetter@ffwll.ch>

A forced EDID read takes 22.5ms best-case, and that's per 128byte
block. HDMI screens tend to have 2-3 of those. Mutliply that by a few
outputs and then it's clear that userspace really never ever should
re-probe connector state on its own and trust the kernel to tell it
when anything changed. The only exception is a manual reprobe button that
the user must press itself (for extremely shitty KVM switches that
don't wire up hotplug handling properly).

There have been bugs in the past, but we're slowly fixing them up. To
the point even that some of the most abused interfaces (e.g. in sysfs)
have been changed to only return the cached state ever due to too much
polling by userspace.

But there's other places where we can't pull these tricks, so give
userspace the tools to notice their abuse and expose delays due to
EDID reads in latencytop.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/drm_edid.c | 27 +++++++++++++++++++--------
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c214f1246cb4..370003e0cc69 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -32,6 +32,7 @@
 #include <linux/hdmi.h>
 #include <linux/i2c.h>
 #include <linux/module.h>
+#include <linux/latencytop.h>
 #include <drm/drmP.h>
 #include <drm/drm_edid.h>
 #include <drm/drm_displayid.h>
@@ -1272,14 +1273,17 @@ struct edid *drm_do_get_edid(struct drm_connector *connector,
 	int i, j = 0, valid_extensions = 0;
 	u8 *block, *new;
 	bool print_bad_edid = !connector->bad_edid_counter || (drm_debug & DRM_UT_KMS);
+	u64 before, after;
 
 	if ((block = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
 		return NULL;
 
+	before = ktime_get_raw_ns();
+
 	/* base block fetch */
 	for (i = 0; i < 4; i++) {
 		if (get_edid_block(data, block, 0, EDID_LENGTH))
-			goto out;
+			goto none;
 		if (drm_edid_block_valid(block, 0, print_bad_edid,
 					 &connector->edid_corrupt))
 			break;
@@ -1293,11 +1297,11 @@ struct edid *drm_do_get_edid(struct drm_connector *connector,
 
 	/* if there's no extensions, we're done */
 	if (block[0x7e] == 0)
-		return (struct edid *)block;
+		goto out;
 
 	new = krealloc(block, (block[0x7e] + 1) * EDID_LENGTH, GFP_KERNEL);
 	if (!new)
-		goto out;
+		goto none;
 	block = new;
 
 	for (j = 1; j <= block[0x7e]; j++) {
@@ -1305,7 +1309,7 @@ struct edid *drm_do_get_edid(struct drm_connector *connector,
 			if (get_edid_block(data,
 				  block + (valid_extensions + 1) * EDID_LENGTH,
 				  j, EDID_LENGTH))
-				goto out;
+				goto none;
 			if (drm_edid_block_valid(block + (valid_extensions + 1)
 						 * EDID_LENGTH, j,
 						 print_bad_edid,
@@ -1329,11 +1333,11 @@ struct edid *drm_do_get_edid(struct drm_connector *connector,
 		block[0x7e] = valid_extensions;
 		new = krealloc(block, (valid_extensions + 1) * EDID_LENGTH, GFP_KERNEL);
 		if (!new)
-			goto out;
+			goto none;
 		block = new;
 	}
 
-	return (struct edid *)block;
+	goto out;
 
 carp:
 	if (print_bad_edid) {
@@ -1342,9 +1346,16 @@ carp:
 	}
 	connector->bad_edid_counter++;
 
-out:
+none:
 	kfree(block);
-	return NULL;
+	block = NULL;
+
+out:
+	after = ktime_get_raw_ns();
+
+	account_latency(DIV_ROUND_UP_ULL(after - before, 1000));
+
+	return (struct edid *)block;
 }
 EXPORT_SYMBOL_GPL(drm_do_get_edid);
 
-- 
2.5.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2015-12-01 15:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-01 15:29 [PATCH 1/2] kernel/latencytop: Add non-scheduler interface for latency reporting Daniel Vetter
2015-12-01 15:29 ` Daniel Vetter
2015-12-01 15:29 ` Daniel Vetter [this message]
2015-12-01 15:29   ` [PATCH 2/2] drm/edid: report latency due to reading edids Daniel Vetter
2015-12-01 15:46 ` [PATCH 1/2] kernel/latencytop: Add non-scheduler interface for latency reporting Chris Wilson
2015-12-01 15:46   ` Chris Wilson
2015-12-01 15:54 ` [PATCH] " Daniel Vetter
2015-12-01 15:54   ` Daniel Vetter

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=1448983768-22324-2-git-send-email-daniel.vetter@ffwll.ch \
    --to=daniel.vetter@ffwll.ch \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@linux.intel.com \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.