From patchwork Wed Nov 7 15:30:17 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 10672581 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 1BC3B15E9 for ; Wed, 7 Nov 2018 15:30:47 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0C6832C6B3 for ; Wed, 7 Nov 2018 15:30:47 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0AB022C5AB; Wed, 7 Nov 2018 15:30:47 +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=-5.2 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED 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 A77612C6C0 for ; Wed, 7 Nov 2018 15:30:46 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 0BD126E1DE; Wed, 7 Nov 2018 15:30:46 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mail-ed1-x543.google.com (mail-ed1-x543.google.com [IPv6:2a00:1450:4864:20::543]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3E5F36E1D2 for ; Wed, 7 Nov 2018 15:30:41 +0000 (UTC) Received: by mail-ed1-x543.google.com with SMTP id a14-v6so9559638edr.7 for ; Wed, 07 Nov 2018 07:30:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=+bVedit8FfTohFwRYeI746na2GBbCY7NLCo3hjifxZA=; b=mO9t4sRTgPHmFEfW3hk0maVdcvf5rRjmG9t7uxvP4xe0XVdWUMO96qUVg1LukNNr+q XDAmGCOlvFEM5OzTNCDEw9bwcT0sv77FRYB3B+kykdhT52hnDkKFjUtzdYy2Htt9cMI1 PJhIb94wmUfCV4ApkmBE2Tu35CHhFd53VyPM+14kBJJTysPVhNNeaI5CmUqkxSJ/rQWZ 0sUzLSz+qTLicxUE/5eRm7u2S+OWf3A95iD0qMlWHgiwP8gvKj/O9lIMyWfJwxViA9PP p4HQZ+FE1PF7Ay7eJViQdw2Xn+Kf9HI3VXJetXuodV3OWFzPgrF5ht+l9rBneCCxVV0Q lrig== X-Gm-Message-State: AGRZ1gJHp0hyCelgBPKLgV4tmoydAijfTDZoqQTLfpj1Wlv6IUL6NWpY v/aw8q3/PY8J2hd25SQQc80Xsswfdms= X-Google-Smtp-Source: AJdET5fjxLnfDJulWsk2j5KEMvWtk3ybsa4Oi+PG10ChlrLee99zYEIHfRL1pA4J4vYqnh0vRaXYPA== X-Received: by 2002:aa7:c35a:: with SMTP id j26-v6mr511164edr.295.1541604639370; Wed, 07 Nov 2018 07:30:39 -0800 (PST) Received: from phenom.ffwll.local ([2a02:168:569e:0:3106:d637:d723:e855]) by smtp.gmail.com with ESMTPSA id b48-v6sm322425edb.27.2018.11.07.07.30.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Nov 2018 07:30:38 -0800 (PST) From: Daniel Vetter To: Intel Graphics Development Date: Wed, 7 Nov 2018 16:30:17 +0100 Message-Id: <20181107153019.26401-11-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.19.1 In-Reply-To: <20181107153019.26401-1-daniel.vetter@ffwll.ch> References: <20181107153019.26401-1-daniel.vetter@ffwll.ch> MIME-Version: 1.0 Subject: [Intel-gfx] [PATCH 11/13] drm/i915: annotate intel_atomic_commit_fence_wait X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP In i915 we also have i915_sw_fence, as some kind of super fence. Since those include dma-fences (it's the main use really, aside from chaining them for the scheduler) they're relevant for any lockdep cycles involving dma_fence. But i915_sw_fence is also really tough to properly annonate: - Most of the use (all of it in the scheduler) is entirely driven by callbacks. That creates dependency chains, but for all practical purposes we could treat that as part of the hw magic that executes requests for us. Eventually a dma_fence_signal() comes out of that, which we do annotate. - For dma-fences we only annotate cpu waits, and don't follow any of the chains going through the hardware. Since dma_fence are supposed to be ordered an always complete that should be good enough, as long as we don't accidentally deadlock on the cpu side. So treating i915_sw_fence as part of the hw magic shouldn't reduce our deadlock coverage, as long as i915_sw_fence itself doesn't deadlock. And there's lots of debug checks for that already. - There's one exception: intel_atomic_commit_fence_wait() is the only cpu wait on a i915_sw_fence we have. That one we should annotate, and annotate should be able to teach lockdep about our gpu reset vs modeset locking inversion. But in reality this is a dma-fence wait, and it using i915_sw_fence is really just an implementation detail. All other kms drivers use drm_atomic_helper_wait_for_fences() instead. - There is a i915_sw_fence_wait for normal cpu waits (the one in the modeset code is open-coded because it also waits for gpu reset wakups), but that's only used for selftests. So the simplest solution for annotating i915_sw_fence is therefore to annotate intel_atomic_commit_fence() as a dma_fence wait. Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_display.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index bbf8ca21a7a2..cf9240625ae3 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -12747,6 +12747,7 @@ static void intel_atomic_commit_fence_wait(struct intel_atomic_state *intel_stat struct wait_queue_entry wait_fence, wait_reset; struct drm_i915_private *dev_priv = to_i915(intel_state->base.dev); + dma_fence_wait_acquire(); init_wait_entry(&wait_fence, 0); init_wait_entry(&wait_reset, 0); for (;;) { @@ -12764,6 +12765,7 @@ static void intel_atomic_commit_fence_wait(struct intel_atomic_state *intel_stat } finish_wait(&intel_state->commit_ready.wait, &wait_fence); finish_wait(&dev_priv->gpu_error.wait_queue, &wait_reset); + dma_fence_wait_release(); } static void intel_atomic_cleanup_work(struct work_struct *work)