Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755107AbbLAPaR (ORCPT ); Tue, 1 Dec 2015 10:30:17 -0500 Received: from mail-wm0-f52.google.com ([74.125.82.52]:37300 "EHLO mail-wm0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752328AbbLAP3i (ORCPT ); Tue, 1 Dec 2015 10:29:38 -0500 From: Daniel Vetter To: LKML Cc: DRI Development , Intel Graphics Development , Daniel Vetter , Thomas Gleixner , Arjan van de Ven , Andrew Morton , Daniel Vetter Subject: [PATCH 2/2] drm/edid: report latency due to reading edids Date: Tue, 1 Dec 2015 16:29:28 +0100 Message-Id: <1448983768-22324-2-git-send-email-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.5.1 In-Reply-To: <1448983768-22324-1-git-send-email-daniel.vetter@ffwll.ch> References: <1448983768-22324-1-git-send-email-daniel.vetter@ffwll.ch> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3722 Lines: 120 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 Cc: Arjan van de Ven Cc: Andrew Morton Signed-off-by: Daniel Vetter --- 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 #include #include +#include #include #include #include @@ -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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/