Re: [Intel-gfx] [PATCH v2 4/5] drm/i915: Change locking for struct_mutex, v2.

2015-11-02 Thread Maarten Lankhorst
Op 02-11-15 om 14:06 schreef Chris Wilson:
> On Mon, Nov 02, 2015 at 01:57:59PM +0100, Maarten Lankhorst wrote:
>> struct_mutex is being locked for every plane in intel_prepare_plane_fb and
>> intel_cleanup_plane_fb. This can be optimized by acquiring struct_mutex first
>> before calling the atomic helpers. This way the lock only needs to be 
>> acquired
>> twice in ->atomic_commit(). Once for pinning new framebuffers at the start,
>> the second time for unpinning old framebuffer.
> A little explanation that you move the locking into the caller would
> help clarify the patch.
>
>> @@ -13453,10 +13461,6 @@ intel_prepare_plane_fb(struct drm_plane *plane,
>> @@ -13520,7 +13521,6 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
> Please document that you now expect both of these functions to be called
> with struct_mutex held. Also is there any opportunity to reduce the
> struct_mutex lock time?
>
Patch 5/5 reduces locking time. It moves most waiting out of struct_mutex 
except for the full idle during modesets. :)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 4/5] drm/i915: Change locking for struct_mutex, v2.

2015-11-02 Thread Maarten Lankhorst
struct_mutex is being locked for every plane in intel_prepare_plane_fb and
intel_cleanup_plane_fb. This can be optimized by acquiring struct_mutex first
before calling the atomic helpers. This way the lock only needs to be acquired
twice in ->atomic_commit(). Once for pinning new framebuffers at the start,
the second time for unpinning old framebuffer.

Changes since v1:
- Use mutex_lock_interruptible instead of i915 variant,
  to prevent a deadlock when atomic_commit is called from the reset code.

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Matt Roper 
---
Does this look better?

 drivers/gpu/drm/i915/intel_display.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 36e7e29ea266..13aaae38f7f8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13165,8 +13165,13 @@ static int intel_atomic_prepare_commit(struct 
drm_device *dev,
return ret;
}
 
+   ret = mutex_lock_interruptible(>struct_mutex);
+   if (ret)
+   return ret;
+
ret = drm_atomic_helper_prepare_planes(dev, state);
 
+   mutex_unlock(>struct_mutex);
return ret;
 }
 
@@ -13268,7 +13273,10 @@ static int intel_atomic_commit(struct drm_device *dev,
/* FIXME: add subpixel order */
 
drm_atomic_helper_wait_for_vblanks(dev, state);
+
+   mutex_lock(>struct_mutex);
drm_atomic_helper_cleanup_planes(dev, state);
+   mutex_unlock(>struct_mutex);
 
if (any_ms)
intel_modeset_check_state(dev, state);
@@ -13453,10 +13461,6 @@ intel_prepare_plane_fb(struct drm_plane *plane,
if (!obj && !old_obj)
return 0;
 
-   ret = i915_mutex_lock_interruptible(dev);
-   if (ret)
-   return ret;
-
if (old_obj) {
struct drm_crtc_state *crtc_state =
drm_atomic_get_existing_crtc_state(new_state->state, 
plane->state->crtc);
@@ -13477,7 +13481,7 @@ intel_prepare_plane_fb(struct drm_plane *plane,
 
/* Swallow -EIO errors to allow updates during hw lockup. */
if (ret && ret != -EIO)
-   goto out;
+   return ret;
}
 
if (!obj) {
@@ -13495,9 +13499,6 @@ intel_prepare_plane_fb(struct drm_plane *plane,
if (ret == 0)
i915_gem_track_fb(old_obj, obj, intel_plane->frontbuffer_bit);
 
-out:
-   mutex_unlock(>struct_mutex);
-
return ret;
 }
 
@@ -13520,7 +13521,6 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
if (!obj && !old_obj)
return;
 
-   mutex_lock(>struct_mutex);
if (old_obj && (plane->type != DRM_PLANE_TYPE_CURSOR ||
!INTEL_INFO(dev)->cursor_needs_physical))
intel_unpin_fb_obj(old_state->fb, old_state);
@@ -13529,7 +13529,6 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
if ((old_obj && (old_obj->frontbuffer_bits & 
intel_plane->frontbuffer_bit)) ||
(obj && !(obj->frontbuffer_bits & intel_plane->frontbuffer_bit)))
i915_gem_track_fb(old_obj, obj, intel_plane->frontbuffer_bit);
-   mutex_unlock(>struct_mutex);
 }
 
 int
-- 
2.1.0


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 4/5] drm/i915: Change locking for struct_mutex, v2.

2015-11-02 Thread Chris Wilson
On Mon, Nov 02, 2015 at 01:57:59PM +0100, Maarten Lankhorst wrote:
> struct_mutex is being locked for every plane in intel_prepare_plane_fb and
> intel_cleanup_plane_fb. This can be optimized by acquiring struct_mutex first
> before calling the atomic helpers. This way the lock only needs to be acquired
> twice in ->atomic_commit(). Once for pinning new framebuffers at the start,
> the second time for unpinning old framebuffer.

A little explanation that you move the locking into the caller would
help clarify the patch.

> @@ -13453,10 +13461,6 @@ intel_prepare_plane_fb(struct drm_plane *plane,
> @@ -13520,7 +13521,6 @@ intel_cleanup_plane_fb(struct drm_plane *plane,

Please document that you now expect both of these functions to be called
with struct_mutex held. Also is there any opportunity to reduce the
struct_mutex lock time?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx