All of lore.kernel.org
 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 32/35] drm: only grab the crtc lock for pageflips
Date: Thu, 10 Jan 2013 21:48:13 +0100	[thread overview]
Message-ID: <1357850897-27102-33-git-send-email-daniel.vetter@ffwll.ch> (raw)
In-Reply-To: <1357850897-27102-1-git-send-email-daniel.vetter@ffwll.ch>

The pagelip ioctl itself is rather simply, so the hard work for this
patch is auditing all the drivers:

- exynos: Pageflip is protect with dev->struct_mutex and ...
  synchronous. But nothing fancy going on, besides a check whether the
  crtc is enabled, which should probably be somewhere in the drm core
  so that we have unified behaviour across all drivers.

- i915: hw-state is protected with dev->struct_mutex, the delayed
  unpin work together with the other stuff the pageflip complete irq
  handler needs is protected by the event_lock spinlock.

- nouveau: With the pin/unpin functions fixed, everything looks safe:
  A bit of ttm wrestling and refcounting, and a few channel accesses.
  The later are either already proteced sufficiently, or are now safe
  with the channel locking introduced to make cursor updates safe.

- radeon: The irq_get/put functions look a bit race, since the
  atomic_inc/dec isn't protect with locks. Otoh they're all per-crtc,
  so we should be safe with per-crtc locking from the drm core. Then
  there's tons of per-crtc register access, which could potentially go
  through the indirect reg acces. But that's fixed to make cursor
  updates concurrent. Bookeeping for the drm even is also protected
  with the even_lock, which also protects against the pageflip irq
  handler since radeon hw seems to have no way to queue these up
  asynchronously. Otherwise just a bit of ttm-based buffer handling
  and fencing, which is now safe with the previous patch to hold
  bdev->fence_lock while grabbing the ttm fence.

- shmob: Only one crtc. That's an easy one ...

- vmwgfx: As usual a bit special with tons different things:
  - Flippable check using is_implicit and num_implicit. Changes to
    those seem to be nicely covered with the global modeset lock, so
    we should be fine.
  - Some dirty cliprect handling stuff, or at least that is my guess.
    Looks like it's fine since either it's per-crtc, invariant or
    (like the execbuf stuff launched) protected otherwise.
  - Adding the actual flip to the fence_event list. On a quick look
    this seems to have solid locking in place, too.
  ... but generally this is all way over my head.

- imx: Impressive display of races between the page_flip
  implementation and the irq handler. Also, ipu_drm_set_base which
  gets eventually called from the irq handler to update the display
  base isn't really protected against concurrent set_config calls from
  process context.  In any case, going for per-crtc locking won't make
  this worse, so nothing to do.

- omap: Does just some prep work on per-crtc data and grabs a ref on
  the backing storage, then calls down into omap_gem_op_async which
  does some nicely-protected async callback stuff, or directly calls
  the passed-in page_flip_cb. That seems to lock most of the stuff it
  touches properly, safe for the eventually called omap_plane_dpms,
  which updates modeset state. Which will be a problem if this is
  called asynchronously, since the sync_op waiter callback code in
  omap_gem.c does not seem to take the right modeset locks. So looks a
  bit racy already with the old locking, and no worse off with the new
  per-crtc locks.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/drm_crtc.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 1e238c1..16ee864 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3699,12 +3699,12 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
 	    page_flip->reserved != 0)
 		return -EINVAL;
 
-	drm_modeset_lock_all(dev);
 	obj = drm_mode_object_find(dev, page_flip->crtc_id, DRM_MODE_OBJECT_CRTC);
 	if (!obj)
-		goto out;
+		return -EINVAL;
 	crtc = obj_to_crtc(obj);
 
+	mutex_lock(&crtc->mutex);
 	if (crtc->fb == NULL) {
 		/* The framebuffer is currently unbound, presumably
 		 * due to a hotplug event, that userspace has not
@@ -3786,7 +3786,8 @@ out:
 		drm_framebuffer_unreference(fb);
 	if (old_fb)
 		drm_framebuffer_unreference(old_fb);
-	drm_modeset_unlock_all(dev);
+	mutex_unlock(&crtc->mutex);
+
 	return ret;
 }
 
-- 
1.7.10.4

  parent reply	other threads:[~2013-01-10 20:48 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-10 20:47 [PATCH 00/36] kms locking rework Daniel Vetter
2013-01-10 20:47 ` [PATCH 01/35] drm: review locking rules in drm_crtc.c Daniel Vetter
2013-01-10 20:47 ` [PATCH 02/35] drm/doc: integrate drm_crtc.c kerneldoc Daniel Vetter
2013-01-10 20:47 ` [PATCH 03/35] drm/<drivers>: reorder framebuffer init sequence Daniel Vetter
2013-01-11 21:06   ` Rob Clark
2013-01-10 20:47 ` [PATCH 04/35] drm/vmwgfx: " Daniel Vetter
2013-01-10 20:47 ` [PATCH 05/35] drm/gma500: move fbcon restore to lastclose Daniel Vetter
2013-01-10 20:47 ` [PATCH 06/35] drm/nouveau: protect evo_wait/evo_kick sections with a channel mutex Daniel Vetter
2013-01-10 20:47 ` [PATCH 07/35] drm/nouveau: try to protect nbo->pin_refcount Daniel Vetter
2013-01-10 20:47 ` [PATCH 08/35] drm/<drivers>: Unified handling of unimplemented fb->create_handle Daniel Vetter
2013-01-18 15:00   ` Thierry Reding
2013-01-18 18:32     ` Daniel Vetter
2013-01-10 20:47 ` [PATCH 09/35] drm: encapsulate crtc->set_config calls Daniel Vetter
2013-01-10 20:47 ` [PATCH 10/35] drm: add drm_modeset_lock|unlock_all Daniel Vetter
2013-01-10 20:47 ` [PATCH 11/35] drm/i915: use drm_modeset_lock_all Daniel Vetter
2013-01-10 20:47 ` [PATCH 12/35] drm/gma500: " Daniel Vetter
2013-01-10 22:36   ` Alan Cox
2013-01-11 13:25     ` Daniel Vetter
2013-01-10 20:47 ` [PATCH 13/35] drm/ast: " Daniel Vetter
2013-01-10 20:47 ` [PATCH 14/35] drm/shmobile: " Daniel Vetter
2013-01-10 20:47 ` [PATCH 15/35] drm/vmgfx: " Daniel Vetter
2013-01-10 20:47 ` [PATCH 16/35] drm: add per-crtc locks Daniel Vetter
2013-01-10 20:47 ` [PATCH 17/35] drm: only take the crtc lock for ->cursor_set Daniel Vetter
2013-01-10 20:47 ` [PATCH 18/35] drm: only take the crtc lock for ->cursor_move Daniel Vetter
2013-01-10 20:48 ` [PATCH 19/35] drm: revamp locking around fb creation/destruction Daniel Vetter
2013-01-10 20:48 ` [PATCH 20/35] drm: create drm_framebuffer_lookup Daniel Vetter
2013-01-10 20:48 ` [PATCH 21/35] drm: revamp framebuffer cleanup interfaces Daniel Vetter
2013-01-10 20:48 ` [PATCH 22/35] drm: reference framebuffers which are on the idr Daniel Vetter
2013-01-10 20:48 ` [PATCH 23/35] drm: nest modeset locks within fpriv->fbs_lock Daniel Vetter
2013-01-10 20:48 ` [PATCH 24/35] drm: push modeset_lock_all into ->fb_create driver callbacks Daniel Vetter
2013-01-10 20:48 ` [PATCH 25/35] drm: don't take modeset locks in getfb ioctl Daniel Vetter
2013-01-10 20:48 ` [PATCH 26/35] drm: fb refcounting for dirtyfb_ioctl Daniel Vetter
2013-01-10 20:48 ` [PATCH 27/35] drm: refcounting for sprite framebuffers Daniel Vetter
2013-01-10 20:48 ` [PATCH 28/35] drm: refcounting for crtc framebuffers Daniel Vetter
2013-01-10 20:48 ` [PATCH 29/35] drm/i915: dump refcount into framebuffer debugfs file Daniel Vetter
2013-01-11 22:20   ` Rob Clark
2013-01-10 20:48 ` [PATCH 30/35] drm/vmwgfx: add proper framebuffer refcounting Daniel Vetter
2013-01-10 20:48 ` [PATCH 31/35] drm: optimize drm_framebuffer_remove Daniel Vetter
2013-01-10 20:48 ` Daniel Vetter [this message]
2013-01-10 20:48 ` [PATCH 33/35] drm: don't hold crtc mutexes for connector ->detect callbacks Daniel Vetter
2013-01-10 20:48 ` [PATCH 34/35] drm/doc: updates for new framebuffer lifetime rules Daniel Vetter
2013-01-10 20:48 ` [PATCH 35/35] drm/fb_helper: check whether fbcon is bound Daniel Vetter
2013-01-10 20:48 ` [PATCH 36/36] drm/i915: wake up all pageflip waiters Daniel Vetter
2013-01-10 20:50   ` Daniel Vetter
2013-01-11 23:17 ` [PATCH 00/36] kms locking rework Rob Clark

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=1357850897-27102-33-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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.