From patchwork Wed Nov 7 15:30:16 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 10672585 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 CECC3109C for ; Wed, 7 Nov 2018 15:30:51 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BF1F52C6D7 for ; Wed, 7 Nov 2018 15:30:51 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id BD8E02C680; Wed, 7 Nov 2018 15:30:51 +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 644D42C680 for ; Wed, 7 Nov 2018 15:30:51 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D0E0E6E204; Wed, 7 Nov 2018 15:30:50 +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 BF6886E1D2 for ; Wed, 7 Nov 2018 15:30:39 +0000 (UTC) Received: by mail-ed1-x543.google.com with SMTP id b34-v6so1507812ede.13 for ; Wed, 07 Nov 2018 07:30:39 -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=robsG/pBcSCzfjBHMvBVUsRGhw2k4Cg2Wf987U5k/4q9JEl8t5zOSXw24ovWYWCW36 ahef9y1oj4jEU5235kcB7trW89H/PQyNRyyItPDqETi6LIUdpTW8O4Aw2fkZ6k3+eLCd DK0AS0GmonvqQJiqdwbAh1WrQ0NL8mccU1kNsHncP6xKJmSuHMO/aR+8i/4wGM0SDamw 5innFpsaI1LLwXEJC8d63hDE+/aTBkwRw+10hbJsNdG+tuVBanRtxKLUhnXtpxvd90Hy FxNdA4gIhlHToWmd9pE2IkoRcm8VVVGmd3QXsFJiPG7CeE21B/YJnscq2ZAXGE81npIT vKkg== X-Gm-Message-State: AGRZ1gLINTnddz9S1/1heqzyRXHTSLUCDh1d4dKY7//WGAocttWZGQC0 JKLYb26fc31+6OdA9T/wX9pFUMikzuA= X-Google-Smtp-Source: AJdET5f+Ut1xvsGcmwXgjFTN1F3JScnPKiwggcizquhZDjROOA6ppoWf0l1hJTHnJoVLx3VhAoZGwQ== X-Received: by 2002:a17:906:3105:: with SMTP id 5-v6mr457601ejx.122.1541604638023; Wed, 07 Nov 2018 07:30:38 -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.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Nov 2018 07:30:37 -0800 (PST) From: Daniel Vetter To: Intel Graphics Development Date: Wed, 7 Nov 2018 16:30:16 +0100 Message-Id: <20181107153019.26401-10-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 10/13] 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;