From patchwork Sat Sep 17 12:25:38 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Mario Kleiner X-Patchwork-Id: 9337081 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 024006077F for ; Sat, 17 Sep 2016 12:26:46 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E85B9297A5 for ; Sat, 17 Sep 2016 12:26:45 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id DAFF8297B8; Sat, 17 Sep 2016 12:26:45 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_MED, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 52D6C297A5 for ; Sat, 17 Sep 2016 12:26:45 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9EDB76E0FE; Sat, 17 Sep 2016 12:26:42 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) by gabe.freedesktop.org (Postfix) with ESMTPS id D0BC46E386 for ; Sat, 17 Sep 2016 12:26:13 +0000 (UTC) Received: by mail-wm0-x243.google.com with SMTP id w84so387056wmg.0 for ; Sat, 17 Sep 2016 05:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=hhxUS22Lq7p4KHD0VOmm2aFoi9hhXUgst7Gey3KzjJQ=; b=IKT0jWYb9RGVos29xNn7CZbKXhxg33x5UV2tG9KirA7DTzXKvlF8oA+DHvmk3dkNxY ETCiSdTV7nFt5sJVi2L1XcFHrsjzZyV2ynh3QKK68NzSXpQyYmWDkERzgFa8m4H9ZBMW FsIeg6jug4oHNNTgqGZ3OpfX2zKWlh3Jg/uGkLSvKq7GjwuVI5gDXKy6DVlmh00GnksS waNGRMjUzyzpDOIFuCWb0YiPMO82UwU8q2870WPkY9MOrZjwQEEc41W9Q/wS7yQ/ElXE j6PtiUI8NjoUVuqjnYJ/CFCZH/XR5JenRMcVToK/ou+QsWG6xgymePl7XuhWmXg/KHHj oPdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=hhxUS22Lq7p4KHD0VOmm2aFoi9hhXUgst7Gey3KzjJQ=; b=JRSPm4Xvco5HQWzBAAey31ncVBPBR5E0ft15nnGMkuOpnHdKkVlEHbsz1nKgSpT9eX B+x3Ycnj1wRl+99tZGBnOkQ+s901qIL1CHGiErC3OXjMJ0v677rp8ToS3UAgXNuSQuqP hFffmYV/ueDecKU7T9xNMdHWCiCd+UTX2GmqR81geBRZ/md3pL3JLHnvx9PAS2BTRYa5 jJlLg7p4RwH10m657DuZfF4Y8A2yBCE84nx2Ul1u33o6DH22BYAzctt/Aac5m7os1XYd XNaH4eBLXIyLCGdQ5ikkA8mj5SNxRprPigEltBU1steEHzGFqUGuhcbWIbRmY5vsSki1 D5/g== X-Gm-Message-State: AE9vXwORnVe14q8FkBwBtNtxViAQ4s12DKryNFc5lct28nPUyAmabQEFBLGlWRWDOpLPXA== X-Received: by 10.28.127.196 with SMTP id a187mr2019868wmd.115.1474115171377; Sat, 17 Sep 2016 05:26:11 -0700 (PDT) Received: from twisty.fritz.box (x5f703dd8.dyn.telefonica.de. [95.112.61.216]) by smtp.gmail.com with ESMTPSA id bw9sm12964797wjc.33.2016.09.17.05.26.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 17 Sep 2016 05:26:10 -0700 (PDT) From: Mario Kleiner To: dri-devel@lists.freedesktop.org Subject: [PATCH 1/2] drm/radeon: Slightly more robust flip completion handling for < DCE-4 Date: Sat, 17 Sep 2016 14:25:38 +0200 Message-Id: <1474115139-25201-2-git-send-email-mario.kleiner.de@gmail.com> X-Mailer: git-send-email 2.7.0 In-Reply-To: <1474115139-25201-1-git-send-email-mario.kleiner.de@gmail.com> References: <1474115139-25201-1-git-send-email-mario.kleiner.de@gmail.com> Cc: alexander.deucher@amd.com, michel.daenzer@amd.com X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Virus-Scanned: ClamAV using ClamSMTP Pre DCE4 hardware doesn't have (reliable) pageflip completion irqs, therefore we have to use the old polling method for flip completion handling in vblank irq. As vblank irqs fire a bit before start of vblank (when the linebuffer fifo read position reaches end of scanout), we have some fudge for flip completion handling in the last lines of active scanout. Old code assumed the threshold to be 99% of active scanout height, a ballpark estimate which worked ok. Since we know since a while how to calculate the actual threshold from linebuffer size, lets make use of it to get a more accurate threshold. This completion path is still prone to some races in corner cases, especially on pre-AVIVO hardware, so document them a bit better in the code comments. Signed-off-by: Mario Kleiner Acked-by: Michel Dänzer --- drivers/gpu/drm/radeon/radeon_display.c | 30 ++++++++++++++++++++++-------- 1 file changed, 22 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c index 890171f..5070646 100644 --- a/drivers/gpu/drm/radeon/radeon_display.c +++ b/drivers/gpu/drm/radeon/radeon_display.c @@ -321,16 +321,30 @@ void radeon_crtc_handle_vblank(struct radeon_device *rdev, int crtc_id) update_pending = radeon_page_flip_pending(rdev, crtc_id); /* Has the pageflip already completed in crtc, or is it certain - * to complete in this vblank? + * to complete in this vblank? GET_DISTANCE_TO_VBLANKSTART provides + * distance to start of "fudged earlier" vblank in vpos, distance to + * start of real vblank in hpos. vpos >= 0 && hpos < 0 means we are in + * the last few scanlines before start of real vblank, where the vblank + * irq can fire, so we have sampled update_pending a bit too early and + * know the flip will complete at leading edge of the upcoming real + * vblank. On pre-AVIVO hardware, flips also complete inside the real + * vblank, not only at leading edge, so if update_pending for hpos >= 0 + * == inside real vblank, the flip will complete almost immediately. + * Note that this method of completion handling is still not 100% race + * free, as we could execute before the radeon_flip_work_func managed + * to run and set the RADEON_FLIP_SUBMITTED status, thereby we no-op, + * but the flip still gets programmed into hw and completed during + * vblank, leading to a delayed emission of the flip completion event. + * This applies at least to pre-AVIVO hardware, where flips are always + * completing inside vblank, not only at leading edge of vblank. */ if (update_pending && - (DRM_SCANOUTPOS_VALID & radeon_get_crtc_scanoutpos(rdev->ddev, - crtc_id, - USE_REAL_VBLANKSTART, - &vpos, &hpos, NULL, NULL, - &rdev->mode_info.crtcs[crtc_id]->base.hwmode)) && - ((vpos >= (99 * rdev->mode_info.crtcs[crtc_id]->base.hwmode.crtc_vdisplay)/100) || - (vpos < 0 && !ASIC_IS_AVIVO(rdev)))) { + (DRM_SCANOUTPOS_VALID & + radeon_get_crtc_scanoutpos(rdev->ddev, crtc_id, + GET_DISTANCE_TO_VBLANKSTART, + &vpos, &hpos, NULL, NULL, + &rdev->mode_info.crtcs[crtc_id]->base.hwmode)) && + ((vpos >= 0 && hpos < 0) || (hpos >= 0 && !ASIC_IS_AVIVO(rdev)))) { /* crtc didn't flip in this target vblank interval, * but flip is pending in crtc. Based on the current * scanout position we know that the current frame is