* [PATCH 1/3] drm/i915: Remove struct_mutex for destroying framebuffers @ 2017-02-15 10:59 Chris Wilson 2017-02-15 10:59 ` [PATCH 2/3] drm/i915: struct_mutex is not required for allocating the framebuffer Chris Wilson ` (5 more replies) 0 siblings, 6 replies; 12+ messages in thread From: Chris Wilson @ 2017-02-15 10:59 UTC (permalink / raw) To: intel-gfx We do not need to hold struct_mutex for destroying drm_i915_gem_objects any longer, and with a little care taken over tracking obj->framebuffer_references, we can relinquish BKL locking around the destroy of intel_framebuffer. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> --- drivers/gpu/drm/i915/i915_gem_object.h | 2 +- drivers/gpu/drm/i915/i915_gem_shrinker.c | 2 +- drivers/gpu/drm/i915/i915_gem_tiling.c | 2 +- drivers/gpu/drm/i915/intel_display.c | 10 +++++----- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_object.h b/drivers/gpu/drm/i915/i915_gem_object.h index 02365a5f7c80..ef4893a4f08c 100644 --- a/drivers/gpu/drm/i915/i915_gem_object.h +++ b/drivers/gpu/drm/i915/i915_gem_object.h @@ -165,7 +165,7 @@ struct drm_i915_gem_object { struct reservation_object *resv; /** References from framebuffers, locks out tiling changes. */ - unsigned long framebuffer_references; + atomic_t framebuffer_references; /** Record of address bit 17 of each page at last unbind. */ unsigned long *bit_17; diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c b/drivers/gpu/drm/i915/i915_gem_shrinker.c index f249a1eb46ac..8bc515e8b2a2 100644 --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c @@ -207,7 +207,7 @@ i915_gem_shrink(struct drm_i915_private *dev_priv, if (!(flags & I915_SHRINK_ACTIVE) && (i915_gem_object_is_active(obj) || - obj->framebuffer_references)) + atomic_read(&obj->framebuffer_references))) continue; if (!can_release_pages(obj)) diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c b/drivers/gpu/drm/i915/i915_gem_tiling.c index 8b2b507bdf7e..46ade36dcee6 100644 --- a/drivers/gpu/drm/i915/i915_gem_tiling.c +++ b/drivers/gpu/drm/i915/i915_gem_tiling.c @@ -238,7 +238,7 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object *obj, if ((tiling | stride) == obj->tiling_and_stride) return 0; - if (obj->framebuffer_references) + if (atomic_read(&obj->framebuffer_references)) return -EBUSY; /* We need to rebind the object if its current allocation diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 0d46a8db5c6f..60549508cdee 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -14266,14 +14266,14 @@ static void intel_setup_outputs(struct drm_i915_private *dev_priv) static void intel_user_framebuffer_destroy(struct drm_framebuffer *fb) { - struct drm_device *dev = fb->dev; struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb); drm_framebuffer_cleanup(fb); - mutex_lock(&dev->struct_mutex); - WARN_ON(!intel_fb->obj->framebuffer_references--); + + WARN_ON(atomic_read(&intel_fb->obj->framebuffer_references) == 0); + atomic_dec(&intel_fb->obj->framebuffer_references); i915_gem_object_put(intel_fb->obj); - mutex_unlock(&dev->struct_mutex); + kfree(intel_fb); } @@ -14510,7 +14510,7 @@ static int intel_framebuffer_init(struct drm_device *dev, return ret; } - intel_fb->obj->framebuffer_references++; + atomic_inc(&intel_fb->obj->framebuffer_references); return 0; } -- 2.11.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH 2/3] drm/i915: struct_mutex is not required for allocating the framebuffer 2017-02-15 10:59 [PATCH 1/3] drm/i915: Remove struct_mutex for destroying framebuffers Chris Wilson @ 2017-02-15 10:59 ` Chris Wilson 2017-02-16 13:55 ` Joonas Lahtinen 2017-02-15 10:59 ` [PATCH 3/3] drm/i915: Drop struct_mutex around frontbuffer flushes Chris Wilson ` (4 subsequent siblings) 5 siblings, 1 reply; 12+ messages in thread From: Chris Wilson @ 2017-02-15 10:59 UTC (permalink / raw) To: intel-gfx We do not need the BKL struct_mutex in order to allocate a GEM object, nor to create the framebuffer, so resist the temptation to take the BKL willy nilly. As this changes the locking contract around internal API calls, the patch is a little larger than a plain removal of a pair of mutex_lock/unlock. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> --- drivers/gpu/drm/i915/intel_display.c | 109 +++++++++++++++-------------------- drivers/gpu/drm/i915/intel_drv.h | 7 +-- drivers/gpu/drm/i915/intel_fbdev.c | 21 +++---- 3 files changed, 59 insertions(+), 78 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 60549508cdee..388a25f4881d 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -96,10 +96,9 @@ static void i9xx_crtc_clock_get(struct intel_crtc *crtc, static void ironlake_pch_clock_get(struct intel_crtc *crtc, struct intel_crtc_state *pipe_config); -static int intel_framebuffer_init(struct drm_device *dev, - struct intel_framebuffer *ifb, - struct drm_mode_fb_cmd2 *mode_cmd, - struct drm_i915_gem_object *obj); +static int intel_framebuffer_init(struct intel_framebuffer *ifb, + struct drm_i915_gem_object *obj, + struct drm_mode_fb_cmd2 *mode_cmd); static void i9xx_set_pipeconf(struct intel_crtc *intel_crtc); static void intel_set_pipe_timings(struct intel_crtc *intel_crtc); static void intel_set_pipe_src_size(struct intel_crtc *intel_crtc); @@ -2052,11 +2051,13 @@ static void intel_tile_dims(const struct drm_i915_private *dev_priv, } unsigned int -intel_fb_align_height(struct drm_device *dev, unsigned int height, - uint32_t pixel_format, uint64_t fb_modifier) +intel_fb_align_height(struct drm_i915_private *dev_priv, + unsigned int height, + uint32_t pixel_format, + uint64_t fb_modifier) { unsigned int cpp = drm_format_plane_cpp(pixel_format, 0); - unsigned int tile_height = intel_tile_height(to_i915(dev), fb_modifier, cpp); + unsigned int tile_height = intel_tile_height(dev_priv, fb_modifier, cpp); return ALIGN(height, tile_height); } @@ -2622,15 +2623,13 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc, return false; mutex_lock(&dev->struct_mutex); - obj = i915_gem_object_create_stolen_for_preallocated(dev_priv, base_aligned, base_aligned, size_aligned); - if (!obj) { - mutex_unlock(&dev->struct_mutex); + mutex_unlock(&dev->struct_mutex); + if (!obj) return false; - } if (plane_config->tiling == I915_TILING_X) obj->tiling_and_stride = fb->pitches[0] | I915_TILING_X; @@ -2642,20 +2641,17 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc, mode_cmd.modifier[0] = fb->modifier; mode_cmd.flags = DRM_MODE_FB_MODIFIERS; - if (intel_framebuffer_init(dev, to_intel_framebuffer(fb), - &mode_cmd, obj)) { + if (intel_framebuffer_init(to_intel_framebuffer(fb), obj, &mode_cmd)) { DRM_DEBUG_KMS("intel fb init failed\n"); goto out_unref_obj; } - mutex_unlock(&dev->struct_mutex); DRM_DEBUG_KMS("initial plane fb obj %p\n", obj); return true; out_unref_obj: i915_gem_object_put(obj); - mutex_unlock(&dev->struct_mutex); return false; } @@ -7435,7 +7431,8 @@ i9xx_get_initial_plane_config(struct intel_crtc *crtc, val = I915_READ(DSPSTRIDE(pipe)); fb->pitches[0] = val & 0xffffffc0; - aligned_height = intel_fb_align_height(dev, fb->height, + aligned_height = intel_fb_align_height(dev_priv, + fb->height, fb->format->format, fb->modifier); @@ -8476,7 +8473,8 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc, fb->format->format); fb->pitches[0] = (val & 0x3ff) * stride_mult; - aligned_height = intel_fb_align_height(dev, fb->height, + aligned_height = intel_fb_align_height(dev_priv, + fb->height, fb->format->format, fb->modifier); @@ -8574,7 +8572,8 @@ ironlake_get_initial_plane_config(struct intel_crtc *crtc, val = I915_READ(DSPSTRIDE(pipe)); fb->pitches[0] = val & 0xffffffc0; - aligned_height = intel_fb_align_height(dev, fb->height, + aligned_height = intel_fb_align_height(dev_priv, + fb->height, fb->format->format, fb->modifier); @@ -9400,9 +9399,8 @@ static struct drm_display_mode load_detect_mode = { }; struct drm_framebuffer * -__intel_framebuffer_create(struct drm_device *dev, - struct drm_mode_fb_cmd2 *mode_cmd, - struct drm_i915_gem_object *obj) +intel_framebuffer_create(struct drm_i915_gem_object *obj, + struct drm_mode_fb_cmd2 *mode_cmd) { struct intel_framebuffer *intel_fb; int ret; @@ -9411,7 +9409,7 @@ __intel_framebuffer_create(struct drm_device *dev, if (!intel_fb) return ERR_PTR(-ENOMEM); - ret = intel_framebuffer_init(dev, intel_fb, mode_cmd, obj); + ret = intel_framebuffer_init(intel_fb, obj, mode_cmd); if (ret) goto err; @@ -9422,23 +9420,6 @@ __intel_framebuffer_create(struct drm_device *dev, return ERR_PTR(ret); } -static struct drm_framebuffer * -intel_framebuffer_create(struct drm_device *dev, - struct drm_mode_fb_cmd2 *mode_cmd, - struct drm_i915_gem_object *obj) -{ - struct drm_framebuffer *fb; - int ret; - - ret = i915_mutex_lock_interruptible(dev); - if (ret) - return ERR_PTR(ret); - fb = __intel_framebuffer_create(dev, mode_cmd, obj); - mutex_unlock(&dev->struct_mutex); - - return fb; -} - static u32 intel_framebuffer_pitch_for_width(int width, int bpp) { @@ -9473,7 +9454,7 @@ intel_framebuffer_create_for_mode(struct drm_device *dev, bpp); mode_cmd.pixel_format = drm_mode_legacy_fb_format(bpp, depth); - fb = intel_framebuffer_create(dev, &mode_cmd, obj); + fb = intel_framebuffer_create(obj, &mode_cmd); if (IS_ERR(fb)) i915_gem_object_put(obj); @@ -14321,7 +14302,7 @@ static u32 intel_fb_pitch_limit(struct drm_i915_private *dev_priv, uint64_t fb_modifier, uint32_t pixel_format) { - u32 gen = INTEL_INFO(dev_priv)->gen; + u32 gen = INTEL_GEN(dev_priv); if (gen >= 9) { int cpp = drm_format_plane_cpp(pixel_format, 0); @@ -14348,18 +14329,17 @@ u32 intel_fb_pitch_limit(struct drm_i915_private *dev_priv, } } -static int intel_framebuffer_init(struct drm_device *dev, - struct intel_framebuffer *intel_fb, - struct drm_mode_fb_cmd2 *mode_cmd, - struct drm_i915_gem_object *obj) +static int intel_framebuffer_init(struct intel_framebuffer *intel_fb, + struct drm_i915_gem_object *obj, + struct drm_mode_fb_cmd2 *mode_cmd) { - struct drm_i915_private *dev_priv = to_i915(dev); + struct drm_i915_private *dev_priv = to_i915(obj->base.dev); unsigned int tiling = i915_gem_object_get_tiling(obj); - int ret; u32 pitch_limit, stride_alignment; struct drm_format_name_buf format_name; + int ret = -EINVAL; - WARN_ON(!mutex_is_locked(&dev->struct_mutex)); + atomic_inc(&obj->framebuffer_references); if (mode_cmd->flags & DRM_MODE_FB_MODIFIERS) { /* @@ -14369,14 +14349,14 @@ static int intel_framebuffer_init(struct drm_device *dev, if (tiling != I915_TILING_NONE && tiling != intel_fb_modifier_to_tiling(mode_cmd->modifier[0])) { DRM_DEBUG("tiling_mode doesn't match fb modifier\n"); - return -EINVAL; + goto err; } } else { if (tiling == I915_TILING_X) { mode_cmd->modifier[0] = I915_FORMAT_MOD_X_TILED; } else if (tiling == I915_TILING_Y) { DRM_DEBUG("No Y tiling for legacy addfb\n"); - return -EINVAL; + goto err; } } @@ -14387,7 +14367,7 @@ static int intel_framebuffer_init(struct drm_device *dev, if (INTEL_GEN(dev_priv) < 9) { DRM_DEBUG("Unsupported tiling 0x%llx!\n", mode_cmd->modifier[0]); - return -EINVAL; + goto err; } case DRM_FORMAT_MOD_NONE: case I915_FORMAT_MOD_X_TILED: @@ -14395,7 +14375,7 @@ static int intel_framebuffer_init(struct drm_device *dev, default: DRM_DEBUG("Unsupported fb modifier 0x%llx!\n", mode_cmd->modifier[0]); - return -EINVAL; + goto err; } /* @@ -14414,7 +14394,7 @@ static int intel_framebuffer_init(struct drm_device *dev, if (mode_cmd->pitches[0] & (stride_alignment - 1)) { DRM_DEBUG("pitch (%d) must be at least %u byte aligned\n", mode_cmd->pitches[0], stride_alignment); - return -EINVAL; + goto err; } pitch_limit = intel_fb_pitch_limit(dev_priv, mode_cmd->modifier[0], @@ -14424,7 +14404,7 @@ static int intel_framebuffer_init(struct drm_device *dev, mode_cmd->modifier[0] != DRM_FORMAT_MOD_NONE ? "tiled" : "linear", mode_cmd->pitches[0], pitch_limit); - return -EINVAL; + goto err; } /* @@ -14436,7 +14416,7 @@ static int intel_framebuffer_init(struct drm_device *dev, DRM_DEBUG("pitch (%d) must match tiling stride (%d)\n", mode_cmd->pitches[0], i915_gem_object_get_stride(obj)); - return -EINVAL; + goto err; } /* Reject formats not supported by any plane early. */ @@ -14495,24 +14475,29 @@ static int intel_framebuffer_init(struct drm_device *dev, /* FIXME need to adjust LINOFF/TILEOFF accordingly. */ if (mode_cmd->offsets[0] != 0) - return -EINVAL; + goto err; - drm_helper_mode_fill_fb_struct(dev, &intel_fb->base, mode_cmd); + drm_helper_mode_fill_fb_struct(&dev_priv->drm, + &intel_fb->base, mode_cmd); intel_fb->obj = obj; ret = intel_fill_fb_info(dev_priv, &intel_fb->base); if (ret) return ret; - ret = drm_framebuffer_init(dev, &intel_fb->base, &intel_fb_funcs); + ret = drm_framebuffer_init(obj->base.dev, + &intel_fb->base, + &intel_fb_funcs); if (ret) { DRM_ERROR("framebuffer init failed %d\n", ret); - return ret; + goto err; } - atomic_inc(&intel_fb->obj->framebuffer_references); - return 0; + +err: + atomic_dec(&obj->framebuffer_references); + return ret; } static struct drm_framebuffer * @@ -14528,7 +14513,7 @@ intel_user_framebuffer_create(struct drm_device *dev, if (!obj) return ERR_PTR(-ENOENT); - fb = intel_framebuffer_create(dev, &mode_cmd, obj); + fb = intel_framebuffer_create(obj, &mode_cmd); if (IS_ERR(fb)) i915_gem_object_put(obj); diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 6e37fbab76f1..e633546a6dd8 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -1232,7 +1232,7 @@ void intel_ddi_clock_get(struct intel_encoder *encoder, struct intel_crtc_state *pipe_config); void intel_ddi_set_vc_payload_alloc(struct drm_crtc *crtc, bool state); uint32_t ddi_signal_levels(struct intel_dp *intel_dp); -unsigned int intel_fb_align_height(struct drm_device *dev, +unsigned int intel_fb_align_height(struct drm_i915_private *dev_priv, unsigned int height, uint32_t pixel_format, uint64_t fb_format_modifier); @@ -1342,9 +1342,8 @@ struct i915_vma * intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb, unsigned int rotation); void intel_unpin_fb_vma(struct i915_vma *vma); struct drm_framebuffer * -__intel_framebuffer_create(struct drm_device *dev, - struct drm_mode_fb_cmd2 *mode_cmd, - struct drm_i915_gem_object *obj); +intel_framebuffer_create(struct drm_i915_gem_object *obj, + struct drm_mode_fb_cmd2 *mode_cmd); void intel_finish_page_flip_cs(struct drm_i915_private *dev_priv, int pipe); void intel_finish_page_flip_mmio(struct drm_i915_private *dev_priv, int pipe); void intel_check_page_flip(struct drm_i915_private *dev_priv, int pipe); diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c index e6f3eb2d0b02..02113357b55a 100644 --- a/drivers/gpu/drm/i915/intel_fbdev.c +++ b/drivers/gpu/drm/i915/intel_fbdev.c @@ -121,7 +121,7 @@ static int intelfb_alloc(struct drm_fb_helper *helper, struct drm_i915_private *dev_priv = to_i915(dev); struct i915_ggtt *ggtt = &dev_priv->ggtt; struct drm_mode_fb_cmd2 mode_cmd = {}; - struct drm_i915_gem_object *obj = NULL; + struct drm_i915_gem_object *obj; int size, ret; /* we don't do packed 24bpp */ @@ -136,14 +136,13 @@ static int intelfb_alloc(struct drm_fb_helper *helper, mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp, sizes->surface_depth); - mutex_lock(&dev->struct_mutex); - size = mode_cmd.pitches[0] * mode_cmd.height; size = PAGE_ALIGN(size); /* If the FB is too big, just don't use it since fbdev is not very * important and we should probably use that space with FBC or other * features. */ + obj = NULL; if (size * 2 < ggtt->stolen_usable_size) obj = i915_gem_object_create_stolen(dev_priv, size); if (obj == NULL) @@ -151,24 +150,22 @@ static int intelfb_alloc(struct drm_fb_helper *helper, if (IS_ERR(obj)) { DRM_ERROR("failed to allocate framebuffer\n"); ret = PTR_ERR(obj); - goto out; + goto err; } - fb = __intel_framebuffer_create(dev, &mode_cmd, obj); + fb = intel_framebuffer_create(obj, &mode_cmd); if (IS_ERR(fb)) { - i915_gem_object_put(obj); ret = PTR_ERR(fb); - goto out; + goto err_obj; } - mutex_unlock(&dev->struct_mutex); - ifbdev->fb = to_intel_framebuffer(fb); return 0; -out: - mutex_unlock(&dev->struct_mutex); +err_obj: + i915_gem_object_put(obj); +err: return ret; } @@ -628,7 +625,7 @@ static bool intel_fbdev_init_bios(struct drm_device *dev, } cur_size = intel_crtc->config->base.adjusted_mode.crtc_vdisplay; - cur_size = intel_fb_align_height(dev, cur_size, + cur_size = intel_fb_align_height(to_i915(dev), cur_size, fb->base.format->format, fb->base.modifier); cur_size *= fb->base.pitches[0]; -- 2.11.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH 2/3] drm/i915: struct_mutex is not required for allocating the framebuffer 2017-02-15 10:59 ` [PATCH 2/3] drm/i915: struct_mutex is not required for allocating the framebuffer Chris Wilson @ 2017-02-16 13:55 ` Joonas Lahtinen 0 siblings, 0 replies; 12+ messages in thread From: Joonas Lahtinen @ 2017-02-16 13:55 UTC (permalink / raw) To: Chris Wilson, intel-gfx On ke, 2017-02-15 at 10:59 +0000, Chris Wilson wrote: > We do not need the BKL struct_mutex in order to allocate a GEM object, > nor to create the framebuffer, so resist the temptation to take the BKL > willy nilly. As this changes the locking contract around internal API > calls, the patch is a little larger than a plain removal of a pair of > mutex_lock/unlock. > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Looks good, assuming we have enough lockdep_assert_held sprinkled; Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH 3/3] drm/i915: Drop struct_mutex around frontbuffer flushes 2017-02-15 10:59 [PATCH 1/3] drm/i915: Remove struct_mutex for destroying framebuffers Chris Wilson 2017-02-15 10:59 ` [PATCH 2/3] drm/i915: struct_mutex is not required for allocating the framebuffer Chris Wilson @ 2017-02-15 10:59 ` Chris Wilson 2017-02-16 13:49 ` Joonas Lahtinen 2017-02-15 13:22 ` ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Remove struct_mutex for destroying framebuffers Patchwork ` (3 subsequent siblings) 5 siblings, 1 reply; 12+ messages in thread From: Chris Wilson @ 2017-02-15 10:59 UTC (permalink / raw) To: intel-gfx Since the frontbuffer has self-contained locking, it does not require us to hold the BKL struct_mutex as we send invalidate and flush messages. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> --- drivers/gpu/drm/i915/intel_fbdev.c | 43 +++++++++++++++----------------------- 1 file changed, 17 insertions(+), 26 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c index 02113357b55a..041322fef607 100644 --- a/drivers/gpu/drm/i915/intel_fbdev.c +++ b/drivers/gpu/drm/i915/intel_fbdev.c @@ -45,6 +45,14 @@ #include <drm/i915_drm.h> #include "i915_drv.h" +static void intel_fbdev_invalidate(struct intel_fbdev *ifbdev) +{ + struct drm_i915_gem_object *obj = ifbdev->fb->obj; + unsigned int origin = ifbdev->vma->fence ? ORIGIN_GTT : ORIGIN_CPU; + + intel_fb_obj_invalidate(obj, origin); +} + static int intel_fbdev_set_par(struct fb_info *info) { struct drm_fb_helper *fb_helper = info->par; @@ -53,12 +61,8 @@ static int intel_fbdev_set_par(struct fb_info *info) int ret; ret = drm_fb_helper_set_par(info); - - if (ret == 0) { - mutex_lock(&fb_helper->dev->struct_mutex); - intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT); - mutex_unlock(&fb_helper->dev->struct_mutex); - } + if (ret == 0) + intel_fbdev_invalidate(ifbdev); return ret; } @@ -71,12 +75,8 @@ static int intel_fbdev_blank(int blank, struct fb_info *info) int ret; ret = drm_fb_helper_blank(blank, info); - - if (ret == 0) { - mutex_lock(&fb_helper->dev->struct_mutex); - intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT); - mutex_unlock(&fb_helper->dev->struct_mutex); - } + if (ret == 0) + intel_fbdev_invalidate(ifbdev); return ret; } @@ -87,15 +87,11 @@ static int intel_fbdev_pan_display(struct fb_var_screeninfo *var, struct drm_fb_helper *fb_helper = info->par; struct intel_fbdev *ifbdev = container_of(fb_helper, struct intel_fbdev, helper); - int ret; - ret = drm_fb_helper_pan_display(var, info); - if (ret == 0) { - mutex_lock(&fb_helper->dev->struct_mutex); - intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT); - mutex_unlock(&fb_helper->dev->struct_mutex); - } + ret = drm_fb_helper_pan_display(var, info); + if (ret == 0) + intel_fbdev_invalidate(ifbdev); return ret; } @@ -835,11 +831,6 @@ void intel_fbdev_restore_mode(struct drm_device *dev) if (!ifbdev->fb) return; - if (drm_fb_helper_restore_fbdev_mode_unlocked(&ifbdev->helper)) { - DRM_DEBUG("failed to restore crtc mode\n"); - } else { - mutex_lock(&dev->struct_mutex); - intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT); - mutex_unlock(&dev->struct_mutex); - } + if (drm_fb_helper_restore_fbdev_mode_unlocked(&ifbdev->helper) == 0) + intel_fbdev_invalidate(ifbdev); } -- 2.11.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH 3/3] drm/i915: Drop struct_mutex around frontbuffer flushes 2017-02-15 10:59 ` [PATCH 3/3] drm/i915: Drop struct_mutex around frontbuffer flushes Chris Wilson @ 2017-02-16 13:49 ` Joonas Lahtinen 0 siblings, 0 replies; 12+ messages in thread From: Joonas Lahtinen @ 2017-02-16 13:49 UTC (permalink / raw) To: Chris Wilson, intel-gfx On ke, 2017-02-15 at 10:59 +0000, Chris Wilson wrote: > Since the frontbuffer has self-contained locking, it does not require us > to hold the BKL struct_mutex as we send invalidate and flush messages. > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 12+ messages in thread
* ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Remove struct_mutex for destroying framebuffers 2017-02-15 10:59 [PATCH 1/3] drm/i915: Remove struct_mutex for destroying framebuffers Chris Wilson 2017-02-15 10:59 ` [PATCH 2/3] drm/i915: struct_mutex is not required for allocating the framebuffer Chris Wilson 2017-02-15 10:59 ` [PATCH 3/3] drm/i915: Drop struct_mutex around frontbuffer flushes Chris Wilson @ 2017-02-15 13:22 ` Patchwork 2017-02-15 13:59 ` [PATCH 1/3] " Joonas Lahtinen ` (2 subsequent siblings) 5 siblings, 0 replies; 12+ messages in thread From: Patchwork @ 2017-02-15 13:22 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx == Series Details == Series: series starting with [1/3] drm/i915: Remove struct_mutex for destroying framebuffers URL : https://patchwork.freedesktop.org/series/19692/ State : success == Summary == Series 19692v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/19692/revisions/1/mbox/ fi-bdw-5557u total:252 pass:241 dwarn:0 dfail:0 fail:0 skip:11 fi-bsw-n3050 total:252 pass:213 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:252 pass:233 dwarn:0 dfail:0 fail:0 skip:19 fi-bxt-t5700 total:83 pass:70 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:252 pass:225 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:252 pass:221 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:252 pass:236 dwarn:0 dfail:0 fail:0 skip:16 fi-hsw-4770r total:252 pass:236 dwarn:0 dfail:0 fail:0 skip:16 fi-ilk-650 total:252 pass:202 dwarn:0 dfail:0 fail:0 skip:50 fi-ivb-3520m total:252 pass:234 dwarn:0 dfail:0 fail:0 skip:18 fi-ivb-3770 total:252 pass:234 dwarn:0 dfail:0 fail:0 skip:18 fi-kbl-7500u total:252 pass:234 dwarn:0 dfail:0 fail:0 skip:18 fi-skl-6260u total:252 pass:242 dwarn:0 dfail:0 fail:0 skip:10 fi-skl-6700hq total:252 pass:235 dwarn:0 dfail:0 fail:0 skip:17 fi-skl-6700k total:252 pass:230 dwarn:4 dfail:0 fail:0 skip:18 fi-skl-6770hq total:252 pass:242 dwarn:0 dfail:0 fail:0 skip:10 fi-snb-2520m total:252 pass:224 dwarn:0 dfail:0 fail:0 skip:28 fi-snb-2600 total:252 pass:223 dwarn:0 dfail:0 fail:0 skip:29 78640dff39ba539190c519d5b210c9e28fb886bb drm-tip: 2017y-02m-15d-10h-08m-38s UTC integration manifest 2cbf254 drm/i915: Drop struct_mutex around frontbuffer flushes 84ba144 drm/i915: struct_mutex is not required for allocating the framebuffer 2ea5ea7 drm/i915: Remove struct_mutex for destroying framebuffers == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3821/ _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/3] drm/i915: Remove struct_mutex for destroying framebuffers 2017-02-15 10:59 [PATCH 1/3] drm/i915: Remove struct_mutex for destroying framebuffers Chris Wilson ` (2 preceding siblings ...) 2017-02-15 13:22 ` ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Remove struct_mutex for destroying framebuffers Patchwork @ 2017-02-15 13:59 ` Joonas Lahtinen 2017-02-15 14:09 ` Chris Wilson 2017-02-16 9:46 ` [PATCH v2] " Chris Wilson 2017-02-16 14:21 ` ✓ Fi.CI.BAT: success for series starting with [v2] drm/i915: Remove struct_mutex for destroying framebuffers (rev2) Patchwork 5 siblings, 1 reply; 12+ messages in thread From: Joonas Lahtinen @ 2017-02-15 13:59 UTC (permalink / raw) To: Chris Wilson, intel-gfx On ke, 2017-02-15 at 10:59 +0000, Chris Wilson wrote: > We do not need to hold struct_mutex for destroying drm_i915_gem_objects > any longer, and with a little care taken over tracking > obj->framebuffer_references, we can relinquish BKL locking around the > destroy of intel_framebuffer. > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> <SNIP> > @@ -14266,14 +14266,14 @@ static void intel_setup_outputs(struct drm_i915_private *dev_priv) > > static void intel_user_framebuffer_destroy(struct drm_framebuffer *fb) > { > - struct drm_device *dev = fb->dev; > struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb); > > drm_framebuffer_cleanup(fb); > - mutex_lock(&dev->struct_mutex); > - WARN_ON(!intel_fb->obj->framebuffer_references--); > + > + WARN_ON(atomic_read(&intel_fb->obj->framebuffer_references) == 0); > + atomic_dec(&intel_fb->obj->framebuffer_references); Umm isn't the point of atomicity that you do this in one step? Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/3] drm/i915: Remove struct_mutex for destroying framebuffers 2017-02-15 13:59 ` [PATCH 1/3] " Joonas Lahtinen @ 2017-02-15 14:09 ` Chris Wilson 0 siblings, 0 replies; 12+ messages in thread From: Chris Wilson @ 2017-02-15 14:09 UTC (permalink / raw) To: Joonas Lahtinen; +Cc: intel-gfx On Wed, Feb 15, 2017 at 03:59:23PM +0200, Joonas Lahtinen wrote: > On ke, 2017-02-15 at 10:59 +0000, Chris Wilson wrote: > > We do not need to hold struct_mutex for destroying drm_i915_gem_objects > > any longer, and with a little care taken over tracking > > obj->framebuffer_references, we can relinquish BKL locking around the > > destroy of intel_framebuffer. > > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > <SNIP> > > > @@ -14266,14 +14266,14 @@ static void intel_setup_outputs(struct drm_i915_private *dev_priv) > > > > static void intel_user_framebuffer_destroy(struct drm_framebuffer *fb) > > { > > - struct drm_device *dev = fb->dev; > > struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb); > > > > drm_framebuffer_cleanup(fb); > > - mutex_lock(&dev->struct_mutex); > > - WARN_ON(!intel_fb->obj->framebuffer_references--); > > + > > + WARN_ON(atomic_read(&intel_fb->obj->framebuffer_references) == 0); > > + atomic_dec(&intel_fb->obj->framebuffer_references); > > Umm isn't the point of atomicity that you do this in one step? Sure, just wasn't actually thinking of it a as real atomic. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v2] drm/i915: Remove struct_mutex for destroying framebuffers 2017-02-15 10:59 [PATCH 1/3] drm/i915: Remove struct_mutex for destroying framebuffers Chris Wilson ` (3 preceding siblings ...) 2017-02-15 13:59 ` [PATCH 1/3] " Joonas Lahtinen @ 2017-02-16 9:46 ` Chris Wilson 2017-02-16 10:18 ` Joonas Lahtinen 2017-02-16 14:21 ` ✓ Fi.CI.BAT: success for series starting with [v2] drm/i915: Remove struct_mutex for destroying framebuffers (rev2) Patchwork 5 siblings, 1 reply; 12+ messages in thread From: Chris Wilson @ 2017-02-16 9:46 UTC (permalink / raw) To: intel-gfx We do not need to hold struct_mutex for destroying drm_i915_gem_objects any longer, and with a little care taken over tracking obj->framebuffer_references, we can relinquish BKL locking around the destroy of intel_framebuffer. v2: Use atomic check for WARN_ON framebuffer miscounting Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> --- drivers/gpu/drm/i915/i915_gem_object.h | 2 +- drivers/gpu/drm/i915/i915_gem_shrinker.c | 2 +- drivers/gpu/drm/i915/i915_gem_tiling.c | 2 +- drivers/gpu/drm/i915/intel_display.c | 9 ++++----- 4 files changed, 7 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_object.h b/drivers/gpu/drm/i915/i915_gem_object.h index 02365a5f7c80..ef4893a4f08c 100644 --- a/drivers/gpu/drm/i915/i915_gem_object.h +++ b/drivers/gpu/drm/i915/i915_gem_object.h @@ -165,7 +165,7 @@ struct drm_i915_gem_object { struct reservation_object *resv; /** References from framebuffers, locks out tiling changes. */ - unsigned long framebuffer_references; + atomic_t framebuffer_references; /** Record of address bit 17 of each page at last unbind. */ unsigned long *bit_17; diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c b/drivers/gpu/drm/i915/i915_gem_shrinker.c index f249a1eb46ac..8bc515e8b2a2 100644 --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c @@ -207,7 +207,7 @@ i915_gem_shrink(struct drm_i915_private *dev_priv, if (!(flags & I915_SHRINK_ACTIVE) && (i915_gem_object_is_active(obj) || - obj->framebuffer_references)) + atomic_read(&obj->framebuffer_references))) continue; if (!can_release_pages(obj)) diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c b/drivers/gpu/drm/i915/i915_gem_tiling.c index 8b2b507bdf7e..46ade36dcee6 100644 --- a/drivers/gpu/drm/i915/i915_gem_tiling.c +++ b/drivers/gpu/drm/i915/i915_gem_tiling.c @@ -238,7 +238,7 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object *obj, if ((tiling | stride) == obj->tiling_and_stride) return 0; - if (obj->framebuffer_references) + if (atomic_read(&obj->framebuffer_references)) return -EBUSY; /* We need to rebind the object if its current allocation diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 0d46a8db5c6f..3b0ef752cd8b 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -14266,14 +14266,13 @@ static void intel_setup_outputs(struct drm_i915_private *dev_priv) static void intel_user_framebuffer_destroy(struct drm_framebuffer *fb) { - struct drm_device *dev = fb->dev; struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb); drm_framebuffer_cleanup(fb); - mutex_lock(&dev->struct_mutex); - WARN_ON(!intel_fb->obj->framebuffer_references--); + + WARN_ON(atomic_dec_return(&intel_fb->obj->framebuffer_references) < 0); i915_gem_object_put(intel_fb->obj); - mutex_unlock(&dev->struct_mutex); + kfree(intel_fb); } @@ -14510,7 +14509,7 @@ static int intel_framebuffer_init(struct drm_device *dev, return ret; } - intel_fb->obj->framebuffer_references++; + atomic_inc(&intel_fb->obj->framebuffer_references); return 0; } -- 2.11.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH v2] drm/i915: Remove struct_mutex for destroying framebuffers 2017-02-16 9:46 ` [PATCH v2] " Chris Wilson @ 2017-02-16 10:18 ` Joonas Lahtinen 0 siblings, 0 replies; 12+ messages in thread From: Joonas Lahtinen @ 2017-02-16 10:18 UTC (permalink / raw) To: Chris Wilson, intel-gfx On to, 2017-02-16 at 09:46 +0000, Chris Wilson wrote: > We do not need to hold struct_mutex for destroying drm_i915_gem_objects > any longer, and with a little care taken over tracking > obj->framebuffer_references, we can relinquish BKL locking around the > destroy of intel_framebuffer. > > v2: Use atomic check for WARN_ON framebuffer miscounting > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 12+ messages in thread
* ✓ Fi.CI.BAT: success for series starting with [v2] drm/i915: Remove struct_mutex for destroying framebuffers (rev2) 2017-02-15 10:59 [PATCH 1/3] drm/i915: Remove struct_mutex for destroying framebuffers Chris Wilson ` (4 preceding siblings ...) 2017-02-16 9:46 ` [PATCH v2] " Chris Wilson @ 2017-02-16 14:21 ` Patchwork 2017-02-16 21:55 ` Chris Wilson 5 siblings, 1 reply; 12+ messages in thread From: Patchwork @ 2017-02-16 14:21 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx == Series Details == Series: series starting with [v2] drm/i915: Remove struct_mutex for destroying framebuffers (rev2) URL : https://patchwork.freedesktop.org/series/19692/ State : success == Summary == Series 19692v2 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/19692/revisions/2/mbox/ fi-bdw-5557u total:252 pass:241 dwarn:0 dfail:0 fail:0 skip:11 fi-bsw-n3050 total:252 pass:213 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:252 pass:233 dwarn:0 dfail:0 fail:0 skip:19 fi-bxt-t5700 total:83 pass:70 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:252 pass:225 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:252 pass:221 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:252 pass:236 dwarn:0 dfail:0 fail:0 skip:16 fi-hsw-4770r total:252 pass:236 dwarn:0 dfail:0 fail:0 skip:16 fi-ilk-650 total:252 pass:202 dwarn:0 dfail:0 fail:0 skip:50 fi-ivb-3520m total:252 pass:234 dwarn:0 dfail:0 fail:0 skip:18 fi-ivb-3770 total:252 pass:234 dwarn:0 dfail:0 fail:0 skip:18 fi-kbl-7500u total:252 pass:234 dwarn:0 dfail:0 fail:0 skip:18 fi-skl-6260u total:252 pass:242 dwarn:0 dfail:0 fail:0 skip:10 fi-skl-6700hq total:252 pass:235 dwarn:0 dfail:0 fail:0 skip:17 fi-skl-6700k total:252 pass:230 dwarn:4 dfail:0 fail:0 skip:18 fi-skl-6770hq total:252 pass:242 dwarn:0 dfail:0 fail:0 skip:10 fi-snb-2520m total:252 pass:224 dwarn:0 dfail:0 fail:0 skip:28 fi-snb-2600 total:252 pass:223 dwarn:0 dfail:0 fail:0 skip:29 89a932d98b6e1733011019c9872583a9c7c8fda3 drm-tip: 2017y-02m-16d-10h-06m-42s UTC integration manifest b17bccf drm/i915: Drop struct_mutex around frontbuffer flushes 9dde3cf drm/i915: struct_mutex is not required for allocating the framebuffer 7e17535 drm/i915: Remove struct_mutex for destroying framebuffers == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3850/ _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ✓ Fi.CI.BAT: success for series starting with [v2] drm/i915: Remove struct_mutex for destroying framebuffers (rev2) 2017-02-16 14:21 ` ✓ Fi.CI.BAT: success for series starting with [v2] drm/i915: Remove struct_mutex for destroying framebuffers (rev2) Patchwork @ 2017-02-16 21:55 ` Chris Wilson 0 siblings, 0 replies; 12+ messages in thread From: Chris Wilson @ 2017-02-16 21:55 UTC (permalink / raw) To: intel-gfx On Thu, Feb 16, 2017 at 02:21:55PM -0000, Patchwork wrote: > == Series Details == > > Series: series starting with [v2] drm/i915: Remove struct_mutex for destroying framebuffers (rev2) > URL : https://patchwork.freedesktop.org/series/19692/ > State : success > > == Summary == > > Series 19692v2 Series without cover letter > https://patchwork.freedesktop.org/api/1.0/series/19692/revisions/2/mbox/ > > fi-bdw-5557u total:252 pass:241 dwarn:0 dfail:0 fail:0 skip:11 > fi-bsw-n3050 total:252 pass:213 dwarn:0 dfail:0 fail:0 skip:39 > fi-bxt-j4205 total:252 pass:233 dwarn:0 dfail:0 fail:0 skip:19 > fi-bxt-t5700 total:83 pass:70 dwarn:0 dfail:0 fail:0 skip:12 > fi-byt-j1900 total:252 pass:225 dwarn:0 dfail:0 fail:0 skip:27 > fi-byt-n2820 total:252 pass:221 dwarn:0 dfail:0 fail:0 skip:31 > fi-hsw-4770 total:252 pass:236 dwarn:0 dfail:0 fail:0 skip:16 > fi-hsw-4770r total:252 pass:236 dwarn:0 dfail:0 fail:0 skip:16 > fi-ilk-650 total:252 pass:202 dwarn:0 dfail:0 fail:0 skip:50 > fi-ivb-3520m total:252 pass:234 dwarn:0 dfail:0 fail:0 skip:18 > fi-ivb-3770 total:252 pass:234 dwarn:0 dfail:0 fail:0 skip:18 > fi-kbl-7500u total:252 pass:234 dwarn:0 dfail:0 fail:0 skip:18 > fi-skl-6260u total:252 pass:242 dwarn:0 dfail:0 fail:0 skip:10 > fi-skl-6700hq total:252 pass:235 dwarn:0 dfail:0 fail:0 skip:17 > fi-skl-6700k total:252 pass:230 dwarn:4 dfail:0 fail:0 skip:18 > fi-skl-6770hq total:252 pass:242 dwarn:0 dfail:0 fail:0 skip:10 > fi-snb-2520m total:252 pass:224 dwarn:0 dfail:0 fail:0 skip:28 > fi-snb-2600 total:252 pass:223 dwarn:0 dfail:0 fail:0 skip:29 > > 89a932d98b6e1733011019c9872583a9c7c8fda3 drm-tip: 2017y-02m-16d-10h-06m-42s UTC integration manifest > b17bccf drm/i915: Drop struct_mutex around frontbuffer flushes > 9dde3cf drm/i915: struct_mutex is not required for allocating the framebuffer > 7e17535 drm/i915: Remove struct_mutex for destroying framebuffers Thanks for the review, pushed. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2017-02-16 21:55 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-02-15 10:59 [PATCH 1/3] drm/i915: Remove struct_mutex for destroying framebuffers Chris Wilson 2017-02-15 10:59 ` [PATCH 2/3] drm/i915: struct_mutex is not required for allocating the framebuffer Chris Wilson 2017-02-16 13:55 ` Joonas Lahtinen 2017-02-15 10:59 ` [PATCH 3/3] drm/i915: Drop struct_mutex around frontbuffer flushes Chris Wilson 2017-02-16 13:49 ` Joonas Lahtinen 2017-02-15 13:22 ` ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Remove struct_mutex for destroying framebuffers Patchwork 2017-02-15 13:59 ` [PATCH 1/3] " Joonas Lahtinen 2017-02-15 14:09 ` Chris Wilson 2017-02-16 9:46 ` [PATCH v2] " Chris Wilson 2017-02-16 10:18 ` Joonas Lahtinen 2017-02-16 14:21 ` ✓ Fi.CI.BAT: success for series starting with [v2] drm/i915: Remove struct_mutex for destroying framebuffers (rev2) Patchwork 2017-02-16 21:55 ` Chris Wilson
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.