From patchwork Tue Nov 19 21:08:42 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 11252675 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 3E913930 for ; Tue, 19 Nov 2019 21:09:06 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 27AEB22311 for ; Tue, 19 Nov 2019 21:09:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 27AEB22311 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 5748D6E8EB; Tue, 19 Nov 2019 21:08:59 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) by gabe.freedesktop.org (Postfix) with ESMTPS id 302706E409 for ; Tue, 19 Nov 2019 21:08:53 +0000 (UTC) Received: by mail-wm1-x344.google.com with SMTP id q70so4781460wme.1 for ; Tue, 19 Nov 2019 13:08:53 -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:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Y5re2skVyJQ7FpMrRORrHIC5wQLtJ6SKEG1wsk2e/c8=; b=SVFDkLjASvyEeQ4/FWzdMnKfa4rMNq/FBQeukbVTDc5c2S5PTiCdWtNeu0pIePqi4W hrS4NHY0xObse1sVN1f9VFtkTzxtiOKm6pQtqows8DZT6gSJsXttjyEYeQRr5LAxNlK6 5+mecI22KV7k2BkVZV6XwjHNRlYiotdlrcbO0Uz1kwLHwdWHiKnWtfufkCmiCY0CfRQY pfhP0Tb/2U5zztAVPwnuRKb1BmBSX18iurZtSjc00MuksUZ/XHBuuuzt8pxHzWL8dm07 24qI8E2cPj9KIYqKWpnLMrp4zO0T7ATz5S1WSnUIarmkBJ2LQI/Le+vVbCkVv6CHqz8E brRQ== X-Gm-Message-State: APjAAAX/d716RZUQsVusdxRVnoSDybKhmJXQuMiKnmrjntGxRzdrv/aM K8+em0qaCOBPrx/V1qkiXGzjygZiQKs= X-Google-Smtp-Source: APXvYqxn4yUMFVNXmX0Xjpq+0vGRwbmPXPP6r0C+gI7qXZ1ejuLf1nVKs6zO925z06kdmayUJfilyw== X-Received: by 2002:a05:600c:2911:: with SMTP id i17mr8204593wmd.83.1574197731570; Tue, 19 Nov 2019 13:08:51 -0800 (PST) Received: from phenom.ffwll.local (212-51-149-96.fiber7.init7.net. [212.51.149.96]) by smtp.gmail.com with ESMTPSA id z14sm28005126wrl.60.2019.11.19.13.08.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Nov 2019 13:08:50 -0800 (PST) From: Daniel Vetter To: Intel Graphics Development , DRI Development Date: Tue, 19 Nov 2019 22:08:42 +0100 Message-Id: <20191119210844.16947-2-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.24.0 In-Reply-To: <20191119210844.16947-1-daniel.vetter@ffwll.ch> References: <20191119210844.16947-1-daniel.vetter@ffwll.ch> MIME-Version: 1.0 X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Y5re2skVyJQ7FpMrRORrHIC5wQLtJ6SKEG1wsk2e/c8=; b=CtdDUX6ku/xkoV851l2hN+CPJdfXJJF7vzF85lu3Rs4abv8F6/wEHa0YUGyEZum8AD aE9GVZmVMJJqnb4QYj6A0QvtB6cqajcCVa0VZxeBlONCgKYHdIyQRzN1uuAoKONPEOZ7 sUqF8Aux8kdMpdEaWOOX1ljq52drczoeqW3Bk= Subject: [Intel-gfx] [PATCH 1/3] drm/modeset: Prime modeset lock vs dma_resv 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: , Cc: Daniel Vetter , Daniel Vetter , =?utf-8?q?Christian_K=C3=B6nig?= Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" It's kinda really hard to get this wrong on a driver with both display and dma_resv locking. But who ever knows, so better to make sure that really all drivers nest these the same way. For actual lock semantics the acquire context nesting doesn't matter. But to teach lockdep what's going on with ww_mutex the acquire ctx is a fake lockdep lock, hence from a lockdep pov it does matter. That's why I figured better to include it. Cc: Maarten Lankhorst Cc: Chris Wilson Cc: Christian König Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_mode_config.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c index 3b570a404933..08e6eff6a179 100644 --- a/drivers/gpu/drm/drm_mode_config.c +++ b/drivers/gpu/drm/drm_mode_config.c @@ -27,6 +27,7 @@ #include #include #include +#include #include "drm_crtc_internal.h" #include "drm_internal.h" @@ -415,6 +416,33 @@ void drm_mode_config_init(struct drm_device *dev) dev->mode_config.num_crtc = 0; dev->mode_config.num_encoder = 0; dev->mode_config.num_total_plane = 0; + + if (IS_ENABLED(CONFIG_LOCKDEP)) { + struct drm_modeset_acquire_ctx modeset_ctx; + struct ww_acquire_ctx resv_ctx; + struct dma_resv resv; + int ret; + + dma_resv_init(&resv); + + drm_modeset_acquire_init(&modeset_ctx, 0); + ret = drm_modeset_lock(&dev->mode_config.connection_mutex, + &modeset_ctx); + if (ret == -EDEADLK) + ret = drm_modeset_backoff(&modeset_ctx); + + ww_acquire_init(&resv_ctx, &reservation_ww_class); + ret = dma_resv_lock(&resv, &resv_ctx); + if (ret == -EDEADLK) + dma_resv_lock_slow(&resv, &resv_ctx); + + dma_resv_unlock(&resv); + ww_acquire_fini(&resv_ctx); + + drm_modeset_drop_locks(&modeset_ctx); + drm_modeset_acquire_fini(&modeset_ctx); + dma_resv_fini(&resv); + } } EXPORT_SYMBOL(drm_mode_config_init);