From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
DRI Development <dri-devel@lists.freedesktop.org>
Cc: "Daniel Vetter" <daniel.vetter@intel.com>,
"Daniel Vetter" <daniel.vetter@ffwll.ch>,
"Christian König" <christian.koenig@amd.com>
Subject: [PATCH 1/3] drm/modeset: Prime modeset lock vs dma_resv
Date: Tue, 19 Nov 2019 22:08:42 +0100 [thread overview]
Message-ID: <20191119210844.16947-2-daniel.vetter@ffwll.ch> (raw)
In-Reply-To: <20191119210844.16947-1-daniel.vetter@ffwll.ch>
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 <maarten.lankhorst@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
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 <drm/drm_file.h>
#include <drm/drm_mode_config.h>
#include <drm/drm_print.h>
+#include <linux/dma-resv.h>
#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);
--
2.24.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
DRI Development <dri-devel@lists.freedesktop.org>
Cc: "Daniel Vetter" <daniel.vetter@intel.com>,
"Daniel Vetter" <daniel.vetter@ffwll.ch>,
"Christian König" <christian.koenig@amd.com>
Subject: [Intel-gfx] [PATCH 1/3] drm/modeset: Prime modeset lock vs dma_resv
Date: Tue, 19 Nov 2019 22:08:42 +0100 [thread overview]
Message-ID: <20191119210844.16947-2-daniel.vetter@ffwll.ch> (raw)
Message-ID: <20191119210842.AlhjYFig-r4on6Uy4tRHTpAAbCyGr-WRBSyEUOv1J7c@z> (raw)
In-Reply-To: <20191119210844.16947-1-daniel.vetter@ffwll.ch>
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 <maarten.lankhorst@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
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 <drm/drm_file.h>
#include <drm/drm_mode_config.h>
#include <drm/drm_print.h>
+#include <linux/dma-resv.h>
#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);
--
2.24.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-11-19 21:08 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-19 21:08 [PATCH 0/3] more dma-buf lockdep priming Daniel Vetter
2019-11-19 21:08 ` [Intel-gfx] " Daniel Vetter
2019-11-19 21:08 ` Daniel Vetter [this message]
2019-11-19 21:08 ` [Intel-gfx] [PATCH 1/3] drm/modeset: Prime modeset lock vs dma_resv Daniel Vetter
2019-11-20 8:34 ` Christian König
2019-11-20 8:34 ` [Intel-gfx] " Christian König
2019-11-20 10:55 ` Daniel Vetter
2019-11-20 10:55 ` [Intel-gfx] " Daniel Vetter
2019-11-19 21:08 ` [PATCH 2/3] dma-resv: Also prime acquire ctx for lockdep Daniel Vetter
2019-11-19 21:08 ` [Intel-gfx] " Daniel Vetter
2019-11-20 11:30 ` Christian König
2019-11-20 11:30 ` [Intel-gfx] " Christian König
2019-11-20 13:56 ` Maarten Lankhorst
2019-11-20 13:56 ` [Intel-gfx] " Maarten Lankhorst
2019-11-19 21:08 ` [PATCH 3/3] drm/msm: Don't init ww_mutec acquire ctx before needed Daniel Vetter
2019-11-19 21:08 ` [Intel-gfx] " Daniel Vetter
[not found] ` <20191119210844.16947-4-daniel.vetter-/w4YWyX8dFk@public.gmane.org>
2019-11-20 2:07 ` Rob Clark
2019-11-20 2:07 ` [Intel-gfx] " Rob Clark
[not found] ` <CAF6AEGuPtwFjM12MRBf_X7GUqJBHt+Xb8vKrT+dddic093Ki6g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-11-20 10:22 ` Daniel Vetter
2019-11-20 10:22 ` [Intel-gfx] " Daniel Vetter
2019-11-20 10:56 ` [PATCH] " Daniel Vetter
2019-11-20 10:56 ` [Intel-gfx] " Daniel Vetter
[not found] ` <20191120105607.3023-1-daniel.vetter-/w4YWyX8dFk@public.gmane.org>
2019-11-21 0:24 ` Rob Clark
2019-11-21 0:24 ` [Intel-gfx] " Rob Clark
2019-11-21 10:03 ` Daniel Vetter
2019-11-21 10:03 ` [Intel-gfx] " Daniel Vetter
2019-11-19 22:31 ` ✗ Fi.CI.CHECKPATCH: warning for more dma-buf lockdep priming Patchwork
2019-11-19 22:31 ` [Intel-gfx] " Patchwork
2019-11-19 22:53 ` ✓ Fi.CI.BAT: success " Patchwork
2019-11-19 22:53 ` [Intel-gfx] " Patchwork
2019-11-20 13:55 ` ✓ Fi.CI.IGT: " Patchwork
2019-11-20 13:55 ` [Intel-gfx] " Patchwork
2019-11-20 15:31 ` ✗ Fi.CI.BUILD: failure for more dma-buf lockdep priming (rev2) Patchwork
2019-11-20 15:31 ` [Intel-gfx] " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191119210844.16947-2-daniel.vetter@ffwll.ch \
--to=daniel.vetter@ffwll.ch \
--cc=christian.koenig@amd.com \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox