* [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
* [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
* ✓ 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
* 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
* 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
* ✓ 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.