dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: DRI Development <dri-devel@lists.freedesktop.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: [PATCH 06/10] drm/nouveau: protect evo_wait/evo_kick sections with a channel mutex
Date: Tue, 18 Dec 2012 22:25:09 +0100	[thread overview]
Message-ID: <1355865913-14858-7-git-send-email-daniel.vetter@ffwll.ch> (raw)
In-Reply-To: <1355865913-14858-1-git-send-email-daniel.vetter@ffwll.ch>

With per-crtc locks modeset operations can run in parallel, and the
cursor code uses the device-global evo master channel for hw frobbing.
But the pageflip code can also sync with the master under some
circumstances. Hence just wrap things up in a mutex to ensure that
pushbuf access doesn't intermingle.

The approach here is a bit overkill since the per-crtc channels used
to schedule the pageflips could probably be used without this pushbuf
locking, but I'm not familiar enough with the nouveau codebase to be
sure of that.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/nouveau/nv50_display.c |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nv50_display.c b/drivers/gpu/drm/nouveau/nv50_display.c
index 3587408..5751d63 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -128,6 +128,11 @@ struct nv50_dmac {
 	struct nv50_chan base;
 	dma_addr_t handle;
 	u32 *ptr;
+
+	/* Protects against concurrent pushbuf access to this channel, lock is
+	 * grabbed by evo_wait (if the pushbuf reservation is successful) and
+	 * dropped again by evo_kick. */
+	struct mutex lock;
 };
 
 static void
@@ -395,11 +400,13 @@ evo_wait(void *evoc, int nr)
 	struct nv50_dmac *dmac = evoc;
 	u32 put = nv_ro32(dmac->base.user, 0x0000) / 4;
 
+	mutex_lock(&dmac->lock);
 	if (put + nr >= (PAGE_SIZE / 4) - 8) {
 		dmac->ptr[put] = 0x20000000;
 
 		nv_wo32(dmac->base.user, 0x0000, 0x00000000);
 		if (!nv_wait(dmac->base.user, 0x0004, ~0, 0x00000000)) {
+			mutex_unlock(&dmac->lock);
 			NV_ERROR(dmac->base.user, "channel stalled\n");
 			return NULL;
 		}
@@ -415,6 +422,7 @@ evo_kick(u32 *push, void *evoc)
 {
 	struct nv50_dmac *dmac = evoc;
 	nv_wo32(dmac->base.user, 0x0000, (push - dmac->ptr) << 2);
+	mutex_unlock(&dmac->lock);
 }
 
 #define evo_mthd(p,m,s) *((p)++) = (((s) << 18) | (m))
-- 
1.7.10.4

  parent reply	other threads:[~2012-12-18 21:25 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-18 21:25 [PATCH 00/10] kms locking rework prep patches Daniel Vetter
2012-12-18 21:25 ` [PATCH 01/10] drm: review locking rules in drm_crtc.c Daniel Vetter
2012-12-18 21:25 ` [PATCH 02/10] drm/doc: integrate drm_crtc.c kerneldoc Daniel Vetter
2012-12-19 18:19   ` Ville Syrjälä
2012-12-20 10:14     ` Daniel Vetter
2012-12-18 21:25 ` [PATCH 03/10] drm/<drivers>: reorder framebuffer init sequence Daniel Vetter
2012-12-18 21:25 ` [PATCH 04/10] drm/vmwgfx: " Daniel Vetter
2012-12-18 21:25 ` [PATCH 05/10] drm/gma500: move fbcon restore to lastclose Daniel Vetter
2012-12-18 21:25 ` Daniel Vetter [this message]
2012-12-20 13:19   ` [PATCH] drm/nouveau: protect evo_wait/evo_kick sections with a channel mutex Daniel Vetter
2012-12-18 21:25 ` [PATCH 07/10] drm/nouveau: try to protect nbo->pin_refcount Daniel Vetter
2012-12-18 21:25 ` [PATCH 08/10] drm/ttm: fix fence locking in ttm_buffer_object_transfer Daniel Vetter
2012-12-18 21:25 ` [PATCH 09/10] drm/<drivers>: Unified handling of unimplemented fb->create_handle Daniel Vetter
2012-12-18 21:25 ` [PATCH 10/10] drm: encapsulate crtc->set_config calls Daniel Vetter

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=1355865913-14858-7-git-send-email-daniel.vetter@ffwll.ch \
    --to=daniel.vetter@ffwll.ch \
    --cc=dri-devel@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;
as well as URLs for NNTP newsgroup(s).