From patchwork Tue Nov 6 13:55:27 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 10670525 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 D6EAF15E9 for ; Tue, 6 Nov 2018 13:55:38 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C402429E95 for ; Tue, 6 Nov 2018 13:55:38 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B53D629E96; Tue, 6 Nov 2018 13:55:38 +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 4AAD5293FB for ; Tue, 6 Nov 2018 13:55:38 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 1A1C86E2C9; Tue, 6 Nov 2018 13:55:37 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) by gabe.freedesktop.org (Postfix) with ESMTPS id ABF466E2C5 for ; Tue, 6 Nov 2018 13:55:35 +0000 (UTC) Received: by mail-ed1-x541.google.com with SMTP id c25-v6so10534683edt.8 for ; Tue, 06 Nov 2018 05:55:35 -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=1Jok8ho8jhb6vYSsincAJxmareqeFSpG/Jyi+TOoGic=; b=OPtDd6Y3eE/TI9vJn6xkzXiDI4UmDVhxoRvtTgfoxmiHhWqcPtGLh5jzvhOK9QDtb7 hOLq6vgFB8UtuzJkCXTk375SzzUALISJlc1zJk0VRejHkAoflitDOTTlmHRrOMo2k+no DV0XoMRsKfvrzMIQIwb3kTFgCE7zDsN7dsFU/ej09KgHCWIVoTrFzEjXNQRNe1YHBBAV DYpPpkk/HG5n0p3nt4w8sDrEAh2HJHKKDbGm4+Pef/8JM1xCkX33OgnRRb2yKyD0Vd7w chZTYaKteOB6IGTlgdVkv/5oFvTtus4vFqCoCGg0qyY5cJIXIo8aJdUT4ibr7pU9Ywt9 aeKA== X-Gm-Message-State: AGRZ1gLINUQvvyxaJZX+MhN5JWugd3nN25pBaeowCjVRHjUVrJDRN2BZ r9KZiIiPn8I0pfU325MA0KROy6251tw= X-Google-Smtp-Source: AJdET5eGzOpHwvv5mMRo+VV/ZoT3cwEcni6mPowkTOeBcHtIhhjVsunlAm88T+day/gqDIkzx/9Q1w== X-Received: by 2002:a50:ba4d:: with SMTP id 13-v6mr21544417eds.239.1541512533955; Tue, 06 Nov 2018 05:55:33 -0800 (PST) Received: from phenom.ffwll.local ([2a02:168:569e:0:3106:d637:d723:e855]) by smtp.gmail.com with ESMTPSA id d1-v6sm6316933edr.16.2018.11.06.05.55.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Nov 2018 05:55:32 -0800 (PST) From: Daniel Vetter To: Intel Graphics Development Date: Tue, 6 Nov 2018 14:55:27 +0100 Message-Id: <20181106135527.28354-1-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.19.1 In-Reply-To: <20181102091531.7775-10-daniel.vetter@ffwll.ch> References: <20181102091531.7775-10-daniel.vetter@ffwll.ch> MIME-Version: 1.0 Subject: [Intel-gfx] [PATCH] drm/i915: Annotate dma_fence waits 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 i915_request_wait is simply our i915-optimized version of dma_fence_wait. They both use the exact same code. To help lockdep discovering all the dependencies, annotate it. v2: We do opportunistic retiring of dma-fences while holding struct_mutex. The recursion this causes is intentional, and we do have other paths which (hopefully) do depend upon the struct_mutex. 2nd option to fix these annotations (and probably even better) would be creating a dma_fence_signal_opportunistic, which doesnt have the lockdep annotations. But that also doesn't guarantee that we'll actually manage to signal fences without depending upon struct_mutex somewhere, so might as well go with this trick here. Aside, for non-i915 people: struct_mutex is our bkl. The locking rules are ... complicated. Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_request.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 71107540581d..0f800b8967a4 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -30,6 +30,10 @@ #include "i915_drv.h" +static long __i915_request_wait(struct i915_request *rq, + unsigned int flags, + long timeout); + static const char *i915_fence_get_driver_name(struct dma_fence *fence) { return "i915"; @@ -66,7 +70,7 @@ static signed long i915_fence_wait(struct dma_fence *fence, bool interruptible, signed long timeout) { - return i915_request_wait(to_request(fence), interruptible, timeout); + return __i915_request_wait(to_request(fence), interruptible, timeout); } static void i915_fence_release(struct dma_fence *fence) @@ -1201,6 +1205,21 @@ static bool __i915_wait_request_check_and_reset(struct i915_request *request) long i915_request_wait(struct i915_request *rq, unsigned int flags, long timeout) +{ + long ret; + + if (!lockdep_is_held(&rq->i915->drm.struct_mutex)) + dma_fence_wait_acquire(); + ret = __i915_request_wait(rq, flags, timeout); + if (!lockdep_is_held(&rq->i915->drm.struct_mutex)) + dma_fence_wait_release(); + + return ret; +} + +static long __i915_request_wait(struct i915_request *rq, + unsigned int flags, + long timeout) { const int state = flags & I915_WAIT_INTERRUPTIBLE ? TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE;