From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f66.google.com ([74.125.82.66]:36228 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752721AbcBHBOw (ORCPT ); Sun, 7 Feb 2016 20:14:52 -0500 Received: by mail-wm0-f66.google.com with SMTP id 128so13219693wmz.3 for ; Sun, 07 Feb 2016 17:14:51 -0800 (PST) From: Mario Kleiner To: dri-devel@lists.freedesktop.org Cc: mario.kleiner.de@gmail.com, linux@bernd-steinhauser.de, , michel@daenzer.net, vbabka@suse.cz, ville.syrjala@linux.intel.com, daniel.vetter@ffwll.ch, alexander.deucher@amd.com, christian.koenig@amd.com Subject: [PATCH 5/6] drm: Prevent vblank counter jumps with timestamp based update method. Date: Mon, 8 Feb 2016 02:13:28 +0100 Message-Id: <1454894009-15466-6-git-send-email-mario.kleiner.de@gmail.com> In-Reply-To: <1454894009-15466-1-git-send-email-mario.kleiner.de@gmail.com> References: <1454894009-15466-1-git-send-email-mario.kleiner.de@gmail.com> Sender: stable-owner@vger.kernel.org List-ID: The changes to drm_update_vblank_count() in Linux 4.4 added a method to emulate a hardware vblank counter by use of high precision vblank timestamps if a kms driver supports those, but doesn't suppport hw vblank counters. That method assumes that the old timestamp from a previous invocation is valid, but that is not always the case. E.g., if drm_reset_vblank_timestamp() gets called during drm_vblank_on() or drm_update_vblank_count() gets called outside vblank irq and the high precision timestamping can't deliver a precise timestamp, ie. drm_get_last_vbltimestamp() delivers a return value of false, then those functions will initialize the old timestamp to zero to mark it as invalid. A following call to drm_update_vblank_count() would then calculate elapsed time with vblank irqs off as current vblank timestamp minus the zero old timestamp and compute a software vblank counter increment that corresponds to system uptime, causing a large forward jump of the software vblank counter. That jump in turn can cause too long waits in drmWaitVblank and very long delays in delivery of vblank events, resulting in hangs of userspace clients. This problem can be observed on nouveau-kms during machine suspend->resume cycles, where drm_vblank_off is called during suspend, drm_vblank_on is called during resume and the first queries to drm_get_last_vbltimestamp() don't deliver high precision timestamps, resulting in a large harmful counter jump. Fix this by checking if the old timestamp used for this calculations is zero == invalid. If so, perform a counter increment of +1 to prevent large counter jumps and reinitialize the timestamps to sane values. Signed-off-by: Mario Kleiner Cc: # 4.4+ Cc: michel@daenzer.net Cc: vbabka@suse.cz Cc: ville.syrjala@linux.intel.com Cc: daniel.vetter@ffwll.ch Cc: dri-devel@lists.freedesktop.org Cc: alexander.deucher@amd.com Cc: christian.koenig@amd.com --- drivers/gpu/drm/drm_irq.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index fb17c45..88bdf19 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -216,6 +216,13 @@ static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe, DRM_DEBUG_VBL("crtc %u: Redundant vblirq ignored." " diff_ns = %lld, framedur_ns = %d)\n", pipe, (long long) diff_ns, framedur_ns); + + /* No valid t_old to calculate diff? Bump +1 to force reinit. */ + if (t_old->tv_sec == 0 && t_old->tv_usec == 0) { + DRM_DEBUG_VBL("crtc %u: No baseline ts. Bump +1.\n", + pipe); + diff = 1; + } } else { /* some kind of default for drivers w/o accurate vbl timestamping */ diff = (flags & DRM_CALLED_FROM_VBLIRQ) != 0; -- 1.9.1 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mario Kleiner Subject: [PATCH 5/6] drm: Prevent vblank counter jumps with timestamp based update method. Date: Mon, 8 Feb 2016 02:13:28 +0100 Message-ID: <1454894009-15466-6-git-send-email-mario.kleiner.de@gmail.com> References: <1454894009-15466-1-git-send-email-mario.kleiner.de@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67]) by gabe.freedesktop.org (Postfix) with ESMTPS id 40FCC6E32B for ; Sun, 7 Feb 2016 17:14:52 -0800 (PST) Received: by mail-wm0-f67.google.com with SMTP id g62so13234771wme.2 for ; Sun, 07 Feb 2016 17:14:52 -0800 (PST) In-Reply-To: <1454894009-15466-1-git-send-email-mario.kleiner.de@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org Cc: daniel.vetter@ffwll.ch, michel@daenzer.net, linux@bernd-steinhauser.de, stable@vger.kernel.org, alexander.deucher@amd.com, christian.koenig@amd.com, vbabka@suse.cz List-Id: dri-devel@lists.freedesktop.org VGhlIGNoYW5nZXMgdG8gZHJtX3VwZGF0ZV92YmxhbmtfY291bnQoKSBpbiBMaW51eCA0LjQgYWRk ZWQgYQptZXRob2QgdG8gZW11bGF0ZSBhIGhhcmR3YXJlIHZibGFuayBjb3VudGVyIGJ5IHVzZSBv ZiBoaWdoCnByZWNpc2lvbiB2YmxhbmsgdGltZXN0YW1wcyBpZiBhIGttcyBkcml2ZXIgc3VwcG9y dHMgdGhvc2UsCmJ1dCBkb2Vzbid0IHN1cHBwb3J0IGh3IHZibGFuayBjb3VudGVycy4KClRoYXQg bWV0aG9kIGFzc3VtZXMgdGhhdCB0aGUgb2xkIHRpbWVzdGFtcCBmcm9tIGEgcHJldmlvdXMKaW52 b2NhdGlvbiBpcyB2YWxpZCwgYnV0IHRoYXQgaXMgbm90IGFsd2F5cyB0aGUgY2FzZS4gRS5nLiwK aWYgZHJtX3Jlc2V0X3ZibGFua190aW1lc3RhbXAoKSBnZXRzIGNhbGxlZCBkdXJpbmcgZHJtX3Zi bGFua19vbigpCm9yIGRybV91cGRhdGVfdmJsYW5rX2NvdW50KCkgZ2V0cyBjYWxsZWQgb3V0c2lk ZSB2YmxhbmsgaXJxIGFuZAp0aGUgaGlnaCBwcmVjaXNpb24gdGltZXN0YW1waW5nIGNhbid0IGRl bGl2ZXIgYSBwcmVjaXNlIHRpbWVzdGFtcCwKaWUuIGRybV9nZXRfbGFzdF92Ymx0aW1lc3RhbXAo KSBkZWxpdmVycyBhIHJldHVybiB2YWx1ZSBvZiBmYWxzZSwKdGhlbiB0aG9zZSBmdW5jdGlvbnMg d2lsbCBpbml0aWFsaXplIHRoZSBvbGQgdGltZXN0YW1wIHRvIHplcm8KdG8gbWFyayBpdCBhcyBp bnZhbGlkLgoKQSBmb2xsb3dpbmcgY2FsbCB0byBkcm1fdXBkYXRlX3ZibGFua19jb3VudCgpIHdv dWxkIHRoZW4gY2FsY3VsYXRlCmVsYXBzZWQgdGltZSB3aXRoIHZibGFuayBpcnFzIG9mZiBhcyBj dXJyZW50IHZibGFuayB0aW1lc3RhbXAgbWludXMKdGhlIHplcm8gb2xkIHRpbWVzdGFtcCBhbmQg Y29tcHV0ZSBhIHNvZnR3YXJlIHZibGFuayBjb3VudGVyIGluY3JlbWVudAp0aGF0IGNvcnJlc3Bv bmRzIHRvIHN5c3RlbSB1cHRpbWUsIGNhdXNpbmcgYSBsYXJnZSBmb3J3YXJkIGp1bXAgb2YgdGhl CnNvZnR3YXJlIHZibGFuayBjb3VudGVyLiBUaGF0IGp1bXAgaW4gdHVybiBjYW4gY2F1c2UgdG9v IGxvbmcgd2FpdHMKaW4gZHJtV2FpdFZibGFuayBhbmQgdmVyeSBsb25nIGRlbGF5cyBpbiBkZWxp dmVyeSBvZiB2YmxhbmsgZXZlbnRzLApyZXN1bHRpbmcgaW4gaGFuZ3Mgb2YgdXNlcnNwYWNlIGNs aWVudHMuCgpUaGlzIHByb2JsZW0gY2FuIGJlIG9ic2VydmVkIG9uIG5vdXZlYXUta21zIGR1cmlu ZyBtYWNoaW5lCnN1c3BlbmQtPnJlc3VtZSBjeWNsZXMsIHdoZXJlIGRybV92Ymxhbmtfb2ZmIGlz IGNhbGxlZCBkdXJpbmcKc3VzcGVuZCwgZHJtX3ZibGFua19vbiBpcyBjYWxsZWQgZHVyaW5nIHJl c3VtZSBhbmQgdGhlIGZpcnN0CnF1ZXJpZXMgdG8gZHJtX2dldF9sYXN0X3ZibHRpbWVzdGFtcCgp IGRvbid0IGRlbGl2ZXIgaGlnaApwcmVjaXNpb24gdGltZXN0YW1wcywgcmVzdWx0aW5nIGluIGEg bGFyZ2UgaGFybWZ1bCBjb3VudGVyIGp1bXAuCgpGaXggdGhpcyBieSBjaGVja2luZyBpZiB0aGUg b2xkIHRpbWVzdGFtcCB1c2VkIGZvciB0aGlzIGNhbGN1bGF0aW9ucwppcyB6ZXJvID09IGludmFs aWQuIElmIHNvLCBwZXJmb3JtIGEgY291bnRlciBpbmNyZW1lbnQgb2YgKzEgdG8KcHJldmVudCBs YXJnZSBjb3VudGVyIGp1bXBzIGFuZCByZWluaXRpYWxpemUgdGhlIHRpbWVzdGFtcHMgdG8Kc2Fu ZSB2YWx1ZXMuCgpTaWduZWQtb2ZmLWJ5OiBNYXJpbyBLbGVpbmVyIDxtYXJpby5rbGVpbmVyLmRl QGdtYWlsLmNvbT4KQ2M6IDxzdGFibGVAdmdlci5rZXJuZWwub3JnPiAjIDQuNCsKQ2M6IG1pY2hl bEBkYWVuemVyLm5ldApDYzogdmJhYmthQHN1c2UuY3oKQ2M6IHZpbGxlLnN5cmphbGFAbGludXgu aW50ZWwuY29tCkNjOiBkYW5pZWwudmV0dGVyQGZmd2xsLmNoCkNjOiBkcmktZGV2ZWxAbGlzdHMu ZnJlZWRlc2t0b3Aub3JnCkNjOiBhbGV4YW5kZXIuZGV1Y2hlckBhbWQuY29tCkNjOiBjaHJpc3Rp YW4ua29lbmlnQGFtZC5jb20KLS0tCiBkcml2ZXJzL2dwdS9kcm0vZHJtX2lycS5jIHwgNyArKysr KysrCiAxIGZpbGUgY2hhbmdlZCwgNyBpbnNlcnRpb25zKCspCgpkaWZmIC0tZ2l0IGEvZHJpdmVy cy9ncHUvZHJtL2RybV9pcnEuYyBiL2RyaXZlcnMvZ3B1L2RybS9kcm1faXJxLmMKaW5kZXggZmIx N2M0NS4uODhiZGYxOSAxMDA2NDQKLS0tIGEvZHJpdmVycy9ncHUvZHJtL2RybV9pcnEuYworKysg Yi9kcml2ZXJzL2dwdS9kcm0vZHJtX2lycS5jCkBAIC0yMTYsNiArMjE2LDEzIEBAIHN0YXRpYyB2 b2lkIGRybV91cGRhdGVfdmJsYW5rX2NvdW50KHN0cnVjdCBkcm1fZGV2aWNlICpkZXYsIHVuc2ln bmVkIGludCBwaXBlLAogCQkJRFJNX0RFQlVHX1ZCTCgiY3J0YyAldTogUmVkdW5kYW50IHZibGly cSBpZ25vcmVkLiIKIAkJCQkgICAgICAiIGRpZmZfbnMgPSAlbGxkLCBmcmFtZWR1cl9ucyA9ICVk KVxuIiwKIAkJCQkgICAgICBwaXBlLCAobG9uZyBsb25nKSBkaWZmX25zLCBmcmFtZWR1cl9ucyk7 CisKKwkJLyogTm8gdmFsaWQgdF9vbGQgdG8gY2FsY3VsYXRlIGRpZmY/IEJ1bXAgKzEgdG8gZm9y Y2UgcmVpbml0LiAqLworCQlpZiAodF9vbGQtPnR2X3NlYyA9PSAwICYmIHRfb2xkLT50dl91c2Vj ID09IDApIHsKKwkJCURSTV9ERUJVR19WQkwoImNydGMgJXU6IE5vIGJhc2VsaW5lIHRzLiBCdW1w ICsxLlxuIiwKKwkJCQkgICAgICBwaXBlKTsKKwkJCWRpZmYgPSAxOworCQl9CiAJfSBlbHNlIHsK IAkJLyogc29tZSBraW5kIG9mIGRlZmF1bHQgZm9yIGRyaXZlcnMgdy9vIGFjY3VyYXRlIHZibCB0 aW1lc3RhbXBpbmcgKi8KIAkJZGlmZiA9IChmbGFncyAmIERSTV9DQUxMRURfRlJPTV9WQkxJUlEp ICE9IDA7Ci0tIAoxLjkuMQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KZHJpLWRldmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0 b3Aub3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJp LWRldmVsCg==