All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC 1/2] drm/i915: Move ioremap_wc tracking onto VMA
@ 2016-04-12 15:56 Tvrtko Ursulin
  2016-04-12 15:56 ` [RFC 2/2] drm/i915: Use i915_vma_iomap from the ringbuffer Tvrtko Ursulin
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Tvrtko Ursulin @ 2016-04-12 15:56 UTC (permalink / raw)
  To: Intel-gfx

From: Chris Wilson <chris@chris-wilson.co.uk>

By tracking the iomapping on the VMA itself, we can share that area
between multiple users. Also by only revoking the iomapping upon
unbinding from the mappable portion of the GGTT, we can keep that iomap
across multiple invocations (e.g. execlists context pinning).

v2:
  * Rebase on nightly;
  * added kerneldoc. (Tvrtko Ursulin)

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
 drivers/gpu/drm/i915/i915_gem.c     |  2 ++
 drivers/gpu/drm/i915/i915_gem_gtt.c | 38 +++++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/i915_gem_gtt.h | 38 +++++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_fbdev.c  |  8 +++-----
 4 files changed, 81 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b37ffea8b458..6a485630595e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3393,6 +3393,8 @@ static int __i915_vma_unbind(struct i915_vma *vma, bool wait)
 		ret = i915_gem_object_put_fence(obj);
 		if (ret)
 			return ret;
+
+		i915_vma_iounmap(vma);
 	}
 
 	trace_i915_vma_unbind(vma);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
index c5cb04907525..b2a8a14e8dcb 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3626,3 +3626,41 @@ i915_ggtt_view_size(struct drm_i915_gem_object *obj,
 		return obj->base.size;
 	}
 }
+
+void *i915_vma_iomap(struct drm_i915_private *dev_priv,
+		     struct i915_vma *vma)
+{
+	struct drm_i915_gem_object *obj = vma->obj;
+	struct i915_ggtt *ggtt = &dev_priv->ggtt;
+
+	if (WARN_ON(!obj->map_and_fenceable))
+		return ERR_PTR(-ENODEV);
+
+	BUG_ON(!vma->is_ggtt);
+	BUG_ON(vma->ggtt_view.type != I915_GGTT_VIEW_NORMAL);
+	BUG_ON((vma->bound & GLOBAL_BIND) == 0);
+
+	if (vma->iomap == NULL) {
+		void *ptr;
+
+		ptr = ioremap_wc(ggtt->mappable_base + vma->node.start,
+				 obj->base.size);
+		if (ptr == NULL) {
+			int ret;
+
+			/* Too many areas already allocated? */
+			ret = i915_gem_evict_vm(vma->vm, true);
+			if (ret)
+				return ERR_PTR(ret);
+
+			ptr = ioremap_wc(ggtt->mappable_base + vma->node.start,
+					 obj->base.size);
+			if (ptr == NULL)
+				return ERR_PTR(-ENOMEM);
+		}
+
+		vma->iomap = ptr;
+	}
+
+	return vma->iomap;
+}
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h
index d7dd3d8a8758..526fdbc71ace 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -175,6 +175,7 @@ struct i915_vma {
 	struct drm_mm_node node;
 	struct drm_i915_gem_object *obj;
 	struct i915_address_space *vm;
+	void *iomap;
 
 	/** Flags and address space this VMA is bound to */
 #define GLOBAL_BIND	(1<<0)
@@ -559,4 +560,41 @@ size_t
 i915_ggtt_view_size(struct drm_i915_gem_object *obj,
 		    const struct i915_ggtt_view *view);
 
+/**
+ * i915_vma_iomap - calls ioremap_wc to map the GGTT VMA via the aperture
+ * @dev_priv: i915 private pointer
+ * @vma: VMA to iomap
+ *
+ * The passed in VMA has to be pinned in the global GTT mappable region. Or in
+ * other words callers are responsible for managing the VMA pinned lifetime and
+ * ensuring it covers the use of the returned mapping.
+ *
+ * Callers must hold the struct_mutex.
+ *
+ * Returns a valid iomapped pointer or ERR_PTR.
+ */
+void *i915_vma_iomap(struct drm_i915_private *dev_priv,
+		     struct i915_vma *vma);
+
+/**
+ * i915_vma_iounmap - unmaps the mapping returned from i915_vma_iomap
+ * @dev_priv: i915 private pointer
+ * @vma: VMA to unmap
+ *
+ * Unmaps the previously iomapped VMA using iounmap.
+ *
+ * Users of i915_vma_iomap should not manually unmap by calling this function
+ * if they want to take advantage of the mapping getting cached in the VMA.
+ *
+ * Callers must hold the struct_mutex.
+ */
+static inline void i915_vma_iounmap(struct i915_vma *vma)
+{
+	if (vma->iomap == NULL)
+		return;
+
+	iounmap(vma->iomap);
+	vma->iomap = NULL;
+}
+
 #endif
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c
index 79ac202f3870..515a2214827e 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -251,12 +251,10 @@ static int intelfb_create(struct drm_fb_helper *helper,
 	info->fix.smem_start = dev->mode_config.fb_base + i915_gem_obj_ggtt_offset(obj);
 	info->fix.smem_len = size;
 
-	info->screen_base =
-		ioremap_wc(ggtt->mappable_base + i915_gem_obj_ggtt_offset(obj),
-			   size);
-	if (!info->screen_base) {
+	info->screen_base = i915_vma_iomap(dev_priv, i915_gem_obj_to_ggtt(obj));
+	if (IS_ERR(info->screen_base)) {
 		DRM_ERROR("Failed to remap framebuffer into virtual memory\n");
-		ret = -ENOSPC;
+		ret = PTR_ERR(info->screen_base);
 		goto out_destroy_fbi;
 	}
 	info->screen_size = size;
-- 
1.9.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* [RFC 2/2] drm/i915: Use i915_vma_iomap from the ringbuffer
  2016-04-12 15:56 [RFC 1/2] drm/i915: Move ioremap_wc tracking onto VMA Tvrtko Ursulin
@ 2016-04-12 15:56 ` Tvrtko Ursulin
  2016-04-12 16:23   ` Chris Wilson
  2016-04-12 16:21 ` [RFC 1/2] drm/i915: Move ioremap_wc tracking onto VMA Chris Wilson
  2016-04-13  6:58 ` ✗ Fi.CI.BAT: failure for series starting with [RFC,1/2] " Patchwork
  2 siblings, 1 reply; 9+ messages in thread
From: Tvrtko Ursulin @ 2016-04-12 15:56 UTC (permalink / raw)
  To: Intel-gfx

From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Similarly to i915_gem_object_pin_map on LLC platforms, we can
use the new VMA based io mapping on !LLC to decrease the cost
of ringbuf pinning and unpinning.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
 drivers/gpu/drm/i915/i915_gem_gtt.h     |  2 ++
 drivers/gpu/drm/i915/intel_ringbuffer.c | 20 ++++++++++++--------
 2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 526fdbc71ace..5dd0ddba5488 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -560,6 +560,8 @@ size_t
 i915_ggtt_view_size(struct drm_i915_gem_object *obj,
 		    const struct i915_ggtt_view *view);
 
+struct drm_i915_private;
+
 /**
  * i915_vma_iomap - calls ioremap_wc to map the GGTT VMA via the aperture
  * @dev_priv: i915 private pointer
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 41b604e69db7..8ac3342b4bdd 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2084,8 +2084,6 @@ void intel_unpin_ringbuffer_obj(struct intel_ringbuffer *ringbuf)
 {
 	if (HAS_LLC(ringbuf->obj->base.dev) && !ringbuf->obj->stolen)
 		i915_gem_object_unpin_map(ringbuf->obj);
-	else
-		iounmap(ringbuf->virtual_start);
 	ringbuf->vma = NULL;
 	i915_gem_object_ggtt_unpin(ringbuf->obj);
 }
@@ -2094,8 +2092,9 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device *dev,
 				     struct intel_ringbuffer *ringbuf)
 {
 	struct drm_i915_private *dev_priv = to_i915(dev);
-	struct i915_ggtt *ggtt = &dev_priv->ggtt;
 	struct drm_i915_gem_object *obj = ringbuf->obj;
+	struct i915_vma *vma;
+	void *addr;
 	int ret;
 
 	if (HAS_LLC(dev_priv) && !obj->stolen) {
@@ -2112,6 +2111,8 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device *dev,
 			ret = -ENOMEM;
 			goto err_unpin;
 		}
+
+		vma = i915_gem_obj_to_ggtt(obj);
 	} else {
 		ret = i915_gem_obj_ggtt_pin(obj, PAGE_SIZE, PIN_MAPPABLE);
 		if (ret)
@@ -2124,15 +2125,18 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device *dev,
 		/* Access through the GTT requires the device to be awake. */
 		assert_rpm_wakelock_held(dev_priv);
 
-		ringbuf->virtual_start = ioremap_wc(ggtt->mappable_base +
-						    i915_gem_obj_ggtt_offset(obj), ringbuf->size);
-		if (ringbuf->virtual_start == NULL) {
-			ret = -ENOMEM;
+		vma = i915_gem_obj_to_ggtt(obj);
+
+		addr = i915_vma_iomap(dev_priv, vma);
+		if (IS_ERR(addr)) {
+			ret = PTR_ERR(ringbuf->virtual_start);
 			goto err_unpin;
 		}
+
+		ringbuf->virtual_start = addr;
 	}
 
-	ringbuf->vma = i915_gem_obj_to_ggtt(obj);
+	ringbuf->vma = vma;
 	return 0;
 
 err_unpin:
-- 
1.9.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [RFC 1/2] drm/i915: Move ioremap_wc tracking onto VMA
  2016-04-12 15:56 [RFC 1/2] drm/i915: Move ioremap_wc tracking onto VMA Tvrtko Ursulin
  2016-04-12 15:56 ` [RFC 2/2] drm/i915: Use i915_vma_iomap from the ringbuffer Tvrtko Ursulin
@ 2016-04-12 16:21 ` Chris Wilson
  2016-04-13  8:45   ` Tvrtko Ursulin
  2016-04-13  6:58 ` ✗ Fi.CI.BAT: failure for series starting with [RFC,1/2] " Patchwork
  2 siblings, 1 reply; 9+ messages in thread
From: Chris Wilson @ 2016-04-12 16:21 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: Intel-gfx

On Tue, Apr 12, 2016 at 04:56:51PM +0100, Tvrtko Ursulin wrote:
> From: Chris Wilson <chris@chris-wilson.co.uk>
> 
> By tracking the iomapping on the VMA itself, we can share that area
> between multiple users. Also by only revoking the iomapping upon
> unbinding from the mappable portion of the GGTT, we can keep that iomap
> across multiple invocations (e.g. execlists context pinning).
> 
> v2:
>   * Rebase on nightly;
>   * added kerneldoc. (Tvrtko Ursulin)
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_gem.c     |  2 ++
>  drivers/gpu/drm/i915/i915_gem_gtt.c | 38 +++++++++++++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/i915_gem_gtt.h | 38 +++++++++++++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/intel_fbdev.c  |  8 +++-----
>  4 files changed, 81 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index b37ffea8b458..6a485630595e 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3393,6 +3393,8 @@ static int __i915_vma_unbind(struct i915_vma *vma, bool wait)
>  		ret = i915_gem_object_put_fence(obj);
>  		if (ret)
>  			return ret;
> +
> +		i915_vma_iounmap(vma);
>  	}
>  
>  	trace_i915_vma_unbind(vma);
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index c5cb04907525..b2a8a14e8dcb 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -3626,3 +3626,41 @@ i915_ggtt_view_size(struct drm_i915_gem_object *obj,
>  		return obj->base.size;
>  	}
>  }
> +
> +void *i915_vma_iomap(struct drm_i915_private *dev_priv,
> +		     struct i915_vma *vma)
> +{
> +	struct drm_i915_gem_object *obj = vma->obj;
> +	struct i915_ggtt *ggtt = &dev_priv->ggtt;
> +
> +	if (WARN_ON(!obj->map_and_fenceable))
> +		return ERR_PTR(-ENODEV);
> +
> +	BUG_ON(!vma->is_ggtt);
> +	BUG_ON(vma->ggtt_view.type != I915_GGTT_VIEW_NORMAL);
> +	BUG_ON((vma->bound & GLOBAL_BIND) == 0);
> +
> +	if (vma->iomap == NULL) {
> +		void *ptr;

We could extract ggtt from the is_ggtt vma->vm that would remove the
dev_priv parameter and make the callers a bit tidier.

static inline struct i915_ggtt *to_ggtt(struct i915_address_space *vm)
{
	BUG_ON(!i915_is_ggtt(vm));
	return container_of(vm, struct i915_ggtt, base);
}

> +
> +		ptr = ioremap_wc(ggtt->mappable_base + vma->node.start,
> +				 obj->base.size);
> +		if (ptr == NULL) {
> +			int ret;
> +
> +			/* Too many areas already allocated? */
> +			ret = i915_gem_evict_vm(vma->vm, true);
> +			if (ret)
> +				return ERR_PTR(ret);
> +
> +			ptr = ioremap_wc(ggtt->mappable_base + vma->node.start,
> +					 obj->base.size);

No, we really don't want to create a new ioremap for every caller when
we already have one, ggtt->mappable. Hence,
    io-mapping: Specify mapping size for io_mapping_map_wc
being its preceeding patch. The difference is huge on Braswell.
-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] 9+ messages in thread

* Re: [RFC 2/2] drm/i915: Use i915_vma_iomap from the ringbuffer
  2016-04-12 15:56 ` [RFC 2/2] drm/i915: Use i915_vma_iomap from the ringbuffer Tvrtko Ursulin
@ 2016-04-12 16:23   ` Chris Wilson
  0 siblings, 0 replies; 9+ messages in thread
From: Chris Wilson @ 2016-04-12 16:23 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: Intel-gfx

On Tue, Apr 12, 2016 at 04:56:52PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> 
> Similarly to i915_gem_object_pin_map on LLC platforms, we can
> use the new VMA based io mapping on !LLC to decrease the cost
> of ringbuf pinning and unpinning.

If you are going to mention pin_map, you open up the discussion that we
can avoid the mappable apertures requirement on !llc if we use pin_map
with a pgprot_writecombine. That's my preferred solution, caching the
ioremap is just a stopgap, or fallback for when we can't use direct CPU
access.
-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] 9+ messages in thread

* ✗ Fi.CI.BAT: failure for series starting with [RFC,1/2] drm/i915: Move ioremap_wc tracking onto VMA
  2016-04-12 15:56 [RFC 1/2] drm/i915: Move ioremap_wc tracking onto VMA Tvrtko Ursulin
  2016-04-12 15:56 ` [RFC 2/2] drm/i915: Use i915_vma_iomap from the ringbuffer Tvrtko Ursulin
  2016-04-12 16:21 ` [RFC 1/2] drm/i915: Move ioremap_wc tracking onto VMA Chris Wilson
@ 2016-04-13  6:58 ` Patchwork
  2 siblings, 0 replies; 9+ messages in thread
From: Patchwork @ 2016-04-13  6:58 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: intel-gfx

== Series Details ==

Series: series starting with [RFC,1/2] drm/i915: Move ioremap_wc tracking onto VMA
URL   : https://patchwork.freedesktop.org/series/5599/
State : failure

== Summary ==

Series 5599v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5599/revisions/1/mbox/

Test drv_getparams_basic:
        Subgroup basic-eu-total:
                dmesg-warn -> PASS       (bsw-nuc-2)
Test drv_hangman:
        Subgroup error-state-basic:
                skip       -> PASS       (bsw-nuc-2)
Test gem_busy:
        Subgroup basic-bsd:
                skip       -> PASS       (bsw-nuc-2)
Test gem_cs_tlb:
        Subgroup basic-default:
                skip       -> PASS       (bsw-nuc-2)
Test gem_ctx_param_basic:
        Subgroup invalid-ctx-get:
                dmesg-warn -> PASS       (bsw-nuc-2)
        Subgroup non-root-set-no-zeromap:
                dmesg-warn -> PASS       (bsw-nuc-2)
Test gem_ctx_switch:
        Subgroup basic-default:
                skip       -> PASS       (bsw-nuc-2)
Test gem_exec_basic:
        Subgroup basic-blt:
                skip       -> PASS       (bsw-nuc-2)
        Subgroup basic-default:
                incomplete -> PASS       (bsw-nuc-2)
        Subgroup basic-render:
                skip       -> PASS       (bsw-nuc-2)
        Subgroup readonly-render:
                skip       -> PASS       (bsw-nuc-2)
Test gem_exec_create:
        Subgroup basic:
                skip       -> PASS       (bsw-nuc-2)
Test gem_exec_nop:
        Subgroup basic:
                skip       -> PASS       (bsw-nuc-2)
Test gem_flink_basic:
        Subgroup double-flink:
                dmesg-warn -> PASS       (bsw-nuc-2)
Test gem_mmap_gtt:
        Subgroup basic-copy:
                dmesg-warn -> PASS       (bsw-nuc-2)
        Subgroup basic-read-write:
                dmesg-warn -> PASS       (bsw-nuc-2)
        Subgroup basic-read-write-distinct:
                dmesg-warn -> PASS       (bsw-nuc-2)
        Subgroup basic-small-bo:
                dmesg-warn -> PASS       (bsw-nuc-2)
        Subgroup basic-small-copy:
                dmesg-warn -> PASS       (bsw-nuc-2)
        Subgroup basic-small-copy-xy:
                dmesg-warn -> PASS       (bsw-nuc-2)
        Subgroup basic-write-gtt-no-prefault:
                dmesg-warn -> PASS       (bsw-nuc-2)
        Subgroup basic-write-no-prefault:
                dmesg-warn -> PASS       (bsw-nuc-2)
Test gem_ringfill:
        Subgroup basic-default-hang:
                skip       -> PASS       (bsw-nuc-2)
        Subgroup basic-default-interruptible:
                skip       -> PASS       (bsw-nuc-2)
Test gem_sync:
        Subgroup basic-all:
                skip       -> PASS       (bsw-nuc-2)
        Subgroup basic-default:
                skip       -> PASS       (bsw-nuc-2)
Test gem_tiled_fence_blits:
        Subgroup basic:
                dmesg-fail -> PASS       (bsw-nuc-2)
Test gem_tiled_pread_basic:
                dmesg-warn -> PASS       (bsw-nuc-2)
Test kms_addfb_basic:
        Subgroup addfb25-y-tiled:
                dmesg-warn -> PASS       (bsw-nuc-2)
        Subgroup bad-pitch-0:
                dmesg-warn -> PASS       (bsw-nuc-2)
        Subgroup bad-pitch-1024:
                dmesg-warn -> PASS       (bsw-nuc-2)
        Subgroup bad-pitch-256:
                dmesg-warn -> PASS       (bsw-nuc-2)
        Subgroup bad-pitch-63:
                dmesg-warn -> PASS       (bsw-nuc-2)
        Subgroup bad-pitch-999:
                dmesg-warn -> PASS       (bsw-nuc-2)
        Subgroup basic:
                dmesg-warn -> PASS       (bsw-nuc-2)
        Subgroup framebuffer-vs-set-tiling:
                dmesg-warn -> PASS       (bsw-nuc-2)
        Subgroup no-handle:
                dmesg-warn -> PASS       (bsw-nuc-2)
        Subgroup size-max:
                dmesg-warn -> PASS       (bsw-nuc-2)
Test kms_flip:
        Subgroup basic-flip-vs-wf_vblank:
                pass       -> FAIL       (snb-x220t)
Test kms_frontbuffer_tracking:
        Subgroup basic:
                dmesg-warn -> PASS       (bsw-nuc-2)
Test kms_pipe_crc_basic:
        Subgroup bad-nb-words-3:
                dmesg-warn -> PASS       (bsw-nuc-2)
        Subgroup hang-read-crc-pipe-c:
                skip       -> PASS       (bsw-nuc-2)
        Subgroup read-crc-pipe-c-frame-sequence:
                dmesg-fail -> PASS       (bsw-nuc-2)
Test prime_self_import:
        Subgroup basic-llseek-bad:
                dmesg-warn -> PASS       (bsw-nuc-2)
        Subgroup basic-with_fd_dup:
                dmesg-warn -> PASS       (bsw-nuc-2)
        Subgroup basic-with_one_bo:
                dmesg-warn -> PASS       (bsw-nuc-2)

bdw-nuci7        total:203  pass:191  dwarn:0   dfail:0   fail:0   skip:12 
bsw-nuc-2        total:202  pass:163  dwarn:0   dfail:0   fail:0   skip:39 
byt-nuc          total:202  pass:164  dwarn:0   dfail:0   fail:0   skip:38 
hsw-brixbox      total:203  pass:179  dwarn:0   dfail:0   fail:0   skip:24 
ivb-t430s        total:203  pass:175  dwarn:0   dfail:0   fail:0   skip:28 
skl-i7k-2        total:203  pass:178  dwarn:0   dfail:0   fail:0   skip:25 
snb-dellxps      total:203  pass:165  dwarn:0   dfail:0   fail:0   skip:38 
snb-x220t        total:203  pass:164  dwarn:0   dfail:0   fail:2   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_1876/

ffa8c4ed8c8a2b2c198a3bf1d3f92a6a0a251a45 drm-intel-nightly: 2016y-04m-12d-18h-33m-51s UTC integration manifest
58a867e drm/i915: Use i915_vma_iomap from the ringbuffer
05beaa8 drm/i915: Move ioremap_wc tracking onto VMA

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RFC 1/2] drm/i915: Move ioremap_wc tracking onto VMA
  2016-04-12 16:21 ` [RFC 1/2] drm/i915: Move ioremap_wc tracking onto VMA Chris Wilson
@ 2016-04-13  8:45   ` Tvrtko Ursulin
  2016-04-13  9:04     ` Chris Wilson
  0 siblings, 1 reply; 9+ messages in thread
From: Tvrtko Ursulin @ 2016-04-13  8:45 UTC (permalink / raw)
  To: Chris Wilson, Intel-gfx, Tvrtko Ursulin


On 12/04/16 17:21, Chris Wilson wrote:
> On Tue, Apr 12, 2016 at 04:56:51PM +0100, Tvrtko Ursulin wrote:
>> From: Chris Wilson <chris@chris-wilson.co.uk>
>>
>> By tracking the iomapping on the VMA itself, we can share that area
>> between multiple users. Also by only revoking the iomapping upon
>> unbinding from the mappable portion of the GGTT, we can keep that iomap
>> across multiple invocations (e.g. execlists context pinning).
>>
>> v2:
>>    * Rebase on nightly;
>>    * added kerneldoc. (Tvrtko Ursulin)
>>
>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> ---
>>   drivers/gpu/drm/i915/i915_gem.c     |  2 ++
>>   drivers/gpu/drm/i915/i915_gem_gtt.c | 38 +++++++++++++++++++++++++++++++++++++
>>   drivers/gpu/drm/i915/i915_gem_gtt.h | 38 +++++++++++++++++++++++++++++++++++++
>>   drivers/gpu/drm/i915/intel_fbdev.c  |  8 +++-----
>>   4 files changed, 81 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
>> index b37ffea8b458..6a485630595e 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.c
>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>> @@ -3393,6 +3393,8 @@ static int __i915_vma_unbind(struct i915_vma *vma, bool wait)
>>   		ret = i915_gem_object_put_fence(obj);
>>   		if (ret)
>>   			return ret;
>> +
>> +		i915_vma_iounmap(vma);
>>   	}
>>
>>   	trace_i915_vma_unbind(vma);
>> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
>> index c5cb04907525..b2a8a14e8dcb 100644
>> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
>> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
>> @@ -3626,3 +3626,41 @@ i915_ggtt_view_size(struct drm_i915_gem_object *obj,
>>   		return obj->base.size;
>>   	}
>>   }
>> +
>> +void *i915_vma_iomap(struct drm_i915_private *dev_priv,
>> +		     struct i915_vma *vma)
>> +{
>> +	struct drm_i915_gem_object *obj = vma->obj;
>> +	struct i915_ggtt *ggtt = &dev_priv->ggtt;
>> +
>> +	if (WARN_ON(!obj->map_and_fenceable))
>> +		return ERR_PTR(-ENODEV);
>> +
>> +	BUG_ON(!vma->is_ggtt);
>> +	BUG_ON(vma->ggtt_view.type != I915_GGTT_VIEW_NORMAL);
>> +	BUG_ON((vma->bound & GLOBAL_BIND) == 0);
>> +
>> +	if (vma->iomap == NULL) {
>> +		void *ptr;
>
> We could extract ggtt from the is_ggtt vma->vm that would remove the
> dev_priv parameter and make the callers a bit tidier.
>
> static inline struct i915_ggtt *to_ggtt(struct i915_address_space *vm)
> {
> 	BUG_ON(!i915_is_ggtt(vm));
> 	return container_of(vm, struct i915_ggtt, base);
> }
>
>> +
>> +		ptr = ioremap_wc(ggtt->mappable_base + vma->node.start,
>> +				 obj->base.size);
>> +		if (ptr == NULL) {
>> +			int ret;
>> +
>> +			/* Too many areas already allocated? */
>> +			ret = i915_gem_evict_vm(vma->vm, true);
>> +			if (ret)
>> +				return ERR_PTR(ret);
>> +
>> +			ptr = ioremap_wc(ggtt->mappable_base + vma->node.start,
>> +					 obj->base.size);
>
> No, we really don't want to create a new ioremap for every caller when
> we already have one, ggtt->mappable. Hence,
>      io-mapping: Specify mapping size for io_mapping_map_wc
> being its preceeding patch. The difference is huge on Braswell.

I was following the principle of least change for this one since it does 
remain the same in that respect as the current code. Goal was to unblock 
the GuC early unpin / execlist no retired queue series and not get into 
the trap of inflating the dependencies too much. I thought to add this 
and default context cleanup but you keep adding things to the pile. :)

I'll have a look at your io_mapping stuff to see how much it would add 
to the series. Remember I said I'll add the stable ctx id patches as 
well. Do we need to come up with a plan here?

I could have two separate series to simplify dependencies a bit:

  1. GuC premature unpin and
  2. execlist no retired queue.

The stack for the first one could look like (not as patches but 
conceptually):

  1. default context cleanup
  2. any io_mapping patches of yours
  3. i915_vma_iomap or WC pin_map as you suggested in the other reply.
  4. previous / pinned context

Execlist no retired queue would then be:

  1. stable ctx id
  2. removal of i915_gem_request_unreference__unlocked
  3. execlist no retired queue

If I did not forget about something.

At any point in any series we could add things like i915_gem_request.c 
or those patches which move around the context init.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RFC 1/2] drm/i915: Move ioremap_wc tracking onto VMA
  2016-04-13  8:45   ` Tvrtko Ursulin
@ 2016-04-13  9:04     ` Chris Wilson
  2016-04-13  9:14       ` Tvrtko Ursulin
  0 siblings, 1 reply; 9+ messages in thread
From: Chris Wilson @ 2016-04-13  9:04 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: Intel-gfx

On Wed, Apr 13, 2016 at 09:45:03AM +0100, Tvrtko Ursulin wrote:
> 
> On 12/04/16 17:21, Chris Wilson wrote:
> >On Tue, Apr 12, 2016 at 04:56:51PM +0100, Tvrtko Ursulin wrote:
> >>From: Chris Wilson <chris@chris-wilson.co.uk>
> >>
> >>By tracking the iomapping on the VMA itself, we can share that area
> >>between multiple users. Also by only revoking the iomapping upon
> >>unbinding from the mappable portion of the GGTT, we can keep that iomap
> >>across multiple invocations (e.g. execlists context pinning).
> >>
> >>v2:
> >>   * Rebase on nightly;
> >>   * added kerneldoc. (Tvrtko Ursulin)
> >>
> >>Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> >>Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> >>---
> >>  drivers/gpu/drm/i915/i915_gem.c     |  2 ++
> >>  drivers/gpu/drm/i915/i915_gem_gtt.c | 38 +++++++++++++++++++++++++++++++++++++
> >>  drivers/gpu/drm/i915/i915_gem_gtt.h | 38 +++++++++++++++++++++++++++++++++++++
> >>  drivers/gpu/drm/i915/intel_fbdev.c  |  8 +++-----
> >>  4 files changed, 81 insertions(+), 5 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> >>index b37ffea8b458..6a485630595e 100644
> >>--- a/drivers/gpu/drm/i915/i915_gem.c
> >>+++ b/drivers/gpu/drm/i915/i915_gem.c
> >>@@ -3393,6 +3393,8 @@ static int __i915_vma_unbind(struct i915_vma *vma, bool wait)
> >>  		ret = i915_gem_object_put_fence(obj);
> >>  		if (ret)
> >>  			return ret;
> >>+
> >>+		i915_vma_iounmap(vma);
> >>  	}
> >>
> >>  	trace_i915_vma_unbind(vma);
> >>diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
> >>index c5cb04907525..b2a8a14e8dcb 100644
> >>--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> >>+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> >>@@ -3626,3 +3626,41 @@ i915_ggtt_view_size(struct drm_i915_gem_object *obj,
> >>  		return obj->base.size;
> >>  	}
> >>  }
> >>+
> >>+void *i915_vma_iomap(struct drm_i915_private *dev_priv,
> >>+		     struct i915_vma *vma)
> >>+{
> >>+	struct drm_i915_gem_object *obj = vma->obj;
> >>+	struct i915_ggtt *ggtt = &dev_priv->ggtt;
> >>+
> >>+	if (WARN_ON(!obj->map_and_fenceable))
> >>+		return ERR_PTR(-ENODEV);
> >>+
> >>+	BUG_ON(!vma->is_ggtt);
> >>+	BUG_ON(vma->ggtt_view.type != I915_GGTT_VIEW_NORMAL);
> >>+	BUG_ON((vma->bound & GLOBAL_BIND) == 0);
> >>+
> >>+	if (vma->iomap == NULL) {
> >>+		void *ptr;
> >
> >We could extract ggtt from the is_ggtt vma->vm that would remove the
> >dev_priv parameter and make the callers a bit tidier.
> >
> >static inline struct i915_ggtt *to_ggtt(struct i915_address_space *vm)
> >{
> >	BUG_ON(!i915_is_ggtt(vm));
> >	return container_of(vm, struct i915_ggtt, base);
> >}
> >
> >>+
> >>+		ptr = ioremap_wc(ggtt->mappable_base + vma->node.start,
> >>+				 obj->base.size);
> >>+		if (ptr == NULL) {
> >>+			int ret;
> >>+
> >>+			/* Too many areas already allocated? */
> >>+			ret = i915_gem_evict_vm(vma->vm, true);
> >>+			if (ret)
> >>+				return ERR_PTR(ret);
> >>+
> >>+			ptr = ioremap_wc(ggtt->mappable_base + vma->node.start,
> >>+					 obj->base.size);
> >
> >No, we really don't want to create a new ioremap for every caller when
> >we already have one, ggtt->mappable. Hence,
> >     io-mapping: Specify mapping size for io_mapping_map_wc
> >being its preceeding patch. The difference is huge on Braswell.
> 
> I was following the principle of least change for this one since it
> does remain the same in that respect as the current code. Goal was
> to unblock the GuC early unpin / execlist no retired queue series
> and not get into the trap of inflating the dependencies too much. I
> thought to add this and default context cleanup but you keep adding
> things to the pile. :)

Tip of the iceberg. Only we have lots of icebergs. And the occasional
dragon.
 
> I'll have a look at your io_mapping stuff to see how much it would
> add to the series. Remember I said I'll add the stable ctx id
> patches as well. Do we need to come up with a plan here?

We more or less own io_mapping, for this it is just one patch to add a
pass-through parameter to ioremap_wc that's required for 32bit.

I could mutter about the patch before this being quite a major
bugfix...

> I could have two separate series to simplify dependencies a bit:
> 
>  1. GuC premature unpin and
>  2. execlist no retired queue.
> 
> The stack for the first one could look like (not as patches but
> conceptually):
> 
>  1. default context cleanup
>  2. any io_mapping patches of yours
>  3. i915_vma_iomap or WC pin_map as you suggested in the other reply.
>  4. previous / pinned context
> 
> Execlist no retired queue would then be:
> 
>  1. stable ctx id
>  2. removal of i915_gem_request_unreference__unlocked
>  3. execlist no retired queue
> 
> If I did not forget about something.
> 
> At any point in any series we could add things like
> i915_gem_request.c or those patches which move around the context
> init.

Could I see you some drm_mm.c patches after that?
-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] 9+ messages in thread

* Re: [RFC 1/2] drm/i915: Move ioremap_wc tracking onto VMA
  2016-04-13  9:04     ` Chris Wilson
@ 2016-04-13  9:14       ` Tvrtko Ursulin
  2016-04-13  9:56         ` Chris Wilson
  0 siblings, 1 reply; 9+ messages in thread
From: Tvrtko Ursulin @ 2016-04-13  9:14 UTC (permalink / raw)
  To: Chris Wilson, Intel-gfx, Tvrtko Ursulin


On 13/04/16 10:04, Chris Wilson wrote:
> On Wed, Apr 13, 2016 at 09:45:03AM +0100, Tvrtko Ursulin wrote:
>>
>> On 12/04/16 17:21, Chris Wilson wrote:
>>> On Tue, Apr 12, 2016 at 04:56:51PM +0100, Tvrtko Ursulin wrote:
>>>> From: Chris Wilson <chris@chris-wilson.co.uk>
>>>>
>>>> By tracking the iomapping on the VMA itself, we can share that area
>>>> between multiple users. Also by only revoking the iomapping upon
>>>> unbinding from the mappable portion of the GGTT, we can keep that iomap
>>>> across multiple invocations (e.g. execlists context pinning).
>>>>
>>>> v2:
>>>>    * Rebase on nightly;
>>>>    * added kerneldoc. (Tvrtko Ursulin)
>>>>
>>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>> ---
>>>>   drivers/gpu/drm/i915/i915_gem.c     |  2 ++
>>>>   drivers/gpu/drm/i915/i915_gem_gtt.c | 38 +++++++++++++++++++++++++++++++++++++
>>>>   drivers/gpu/drm/i915/i915_gem_gtt.h | 38 +++++++++++++++++++++++++++++++++++++
>>>>   drivers/gpu/drm/i915/intel_fbdev.c  |  8 +++-----
>>>>   4 files changed, 81 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
>>>> index b37ffea8b458..6a485630595e 100644
>>>> --- a/drivers/gpu/drm/i915/i915_gem.c
>>>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>>>> @@ -3393,6 +3393,8 @@ static int __i915_vma_unbind(struct i915_vma *vma, bool wait)
>>>>   		ret = i915_gem_object_put_fence(obj);
>>>>   		if (ret)
>>>>   			return ret;
>>>> +
>>>> +		i915_vma_iounmap(vma);
>>>>   	}
>>>>
>>>>   	trace_i915_vma_unbind(vma);
>>>> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
>>>> index c5cb04907525..b2a8a14e8dcb 100644
>>>> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
>>>> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
>>>> @@ -3626,3 +3626,41 @@ i915_ggtt_view_size(struct drm_i915_gem_object *obj,
>>>>   		return obj->base.size;
>>>>   	}
>>>>   }
>>>> +
>>>> +void *i915_vma_iomap(struct drm_i915_private *dev_priv,
>>>> +		     struct i915_vma *vma)
>>>> +{
>>>> +	struct drm_i915_gem_object *obj = vma->obj;
>>>> +	struct i915_ggtt *ggtt = &dev_priv->ggtt;
>>>> +
>>>> +	if (WARN_ON(!obj->map_and_fenceable))
>>>> +		return ERR_PTR(-ENODEV);
>>>> +
>>>> +	BUG_ON(!vma->is_ggtt);
>>>> +	BUG_ON(vma->ggtt_view.type != I915_GGTT_VIEW_NORMAL);
>>>> +	BUG_ON((vma->bound & GLOBAL_BIND) == 0);
>>>> +
>>>> +	if (vma->iomap == NULL) {
>>>> +		void *ptr;
>>>
>>> We could extract ggtt from the is_ggtt vma->vm that would remove the
>>> dev_priv parameter and make the callers a bit tidier.
>>>
>>> static inline struct i915_ggtt *to_ggtt(struct i915_address_space *vm)
>>> {
>>> 	BUG_ON(!i915_is_ggtt(vm));
>>> 	return container_of(vm, struct i915_ggtt, base);
>>> }
>>>
>>>> +
>>>> +		ptr = ioremap_wc(ggtt->mappable_base + vma->node.start,
>>>> +				 obj->base.size);
>>>> +		if (ptr == NULL) {
>>>> +			int ret;
>>>> +
>>>> +			/* Too many areas already allocated? */
>>>> +			ret = i915_gem_evict_vm(vma->vm, true);
>>>> +			if (ret)
>>>> +				return ERR_PTR(ret);
>>>> +
>>>> +			ptr = ioremap_wc(ggtt->mappable_base + vma->node.start,
>>>> +					 obj->base.size);
>>>
>>> No, we really don't want to create a new ioremap for every caller when
>>> we already have one, ggtt->mappable. Hence,
>>>      io-mapping: Specify mapping size for io_mapping_map_wc
>>> being its preceeding patch. The difference is huge on Braswell.
>>
>> I was following the principle of least change for this one since it
>> does remain the same in that respect as the current code. Goal was
>> to unblock the GuC early unpin / execlist no retired queue series
>> and not get into the trap of inflating the dependencies too much. I
>> thought to add this and default context cleanup but you keep adding
>> things to the pile. :)
>
> Tip of the iceberg. Only we have lots of icebergs. And the occasional
> dragon.
>
>> I'll have a look at your io_mapping stuff to see how much it would
>> add to the series. Remember I said I'll add the stable ctx id
>> patches as well. Do we need to come up with a plan here?
>
> We more or less own io_mapping, for this it is just one patch to add a
> pass-through parameter to ioremap_wc that's required for 32bit.
>
> I could mutter about the patch before this being quite a major
> bugfix...
>
>> I could have two separate series to simplify dependencies a bit:
>>
>>   1. GuC premature unpin and
>>   2. execlist no retired queue.
>>
>> The stack for the first one could look like (not as patches but
>> conceptually):
>>
>>   1. default context cleanup
>>   2. any io_mapping patches of yours
>>   3. i915_vma_iomap or WC pin_map as you suggested in the other reply.
>>   4. previous / pinned context
>>
>> Execlist no retired queue would then be:
>>
>>   1. stable ctx id
>>   2. removal of i915_gem_request_unreference__unlocked
>>   3. execlist no retired queue
>>
>> If I did not forget about something.
>>
>> At any point in any series we could add things like
>> i915_gem_request.c or those patches which move around the context
>> init.
>
> Could I see you some drm_mm.c patches after that?

If I am competent enough to help with them sure.

Does this mean above sounds like a plan to you? Two series containing 
the listed items?

Regards,

Tvrtko


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RFC 1/2] drm/i915: Move ioremap_wc tracking onto VMA
  2016-04-13  9:14       ` Tvrtko Ursulin
@ 2016-04-13  9:56         ` Chris Wilson
  0 siblings, 0 replies; 9+ messages in thread
From: Chris Wilson @ 2016-04-13  9:56 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: Intel-gfx

On Wed, Apr 13, 2016 at 10:14:50AM +0100, Tvrtko Ursulin wrote:
> On 13/04/16 10:04, Chris Wilson wrote:
> >On Wed, Apr 13, 2016 at 09:45:03AM +0100, Tvrtko Ursulin wrote:
> >>I could have two separate series to simplify dependencies a bit:
> >>
> >>  1. GuC premature unpin and
> >>  2. execlist no retired queue.
> >>
> >>The stack for the first one could look like (not as patches but
> >>conceptually):
> >>
> >>  1. default context cleanup
> >>  2. any io_mapping patches of yours
> >>  3. i915_vma_iomap or WC pin_map as you suggested in the other reply.
> >>  4. previous / pinned context
> >>
> >>Execlist no retired queue would then be:
> >>
> >>  1. stable ctx id
> >>  2. removal of i915_gem_request_unreference__unlocked
> >>  3. execlist no retired queue
> >>
> >>If I did not forget about something.
> >>
> >>At any point in any series we could add things like
> >>i915_gem_request.c or those patches which move around the context
> >>init.
> >
> >Could I see you some drm_mm.c patches after that?
> 
> If I am competent enough to help with them sure.

There's a nice tweak in there to help with the aperture thrashing
scenario (speeds up the aperture thrash tests in gem_concurrent_blit by
~60x). You mentioned you were interested in similar scenarios.

Besides which they actually fix the u64 alignment issues and some
residual u32 problems.
 
> Does this mean above sounds like a plan to you? Two series
> containing the listed items?

3. I'll get io_mapping changes ratified, and that can happen in parallel
to these two series.
-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] 9+ messages in thread

end of thread, other threads:[~2016-04-13  9:56 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-12 15:56 [RFC 1/2] drm/i915: Move ioremap_wc tracking onto VMA Tvrtko Ursulin
2016-04-12 15:56 ` [RFC 2/2] drm/i915: Use i915_vma_iomap from the ringbuffer Tvrtko Ursulin
2016-04-12 16:23   ` Chris Wilson
2016-04-12 16:21 ` [RFC 1/2] drm/i915: Move ioremap_wc tracking onto VMA Chris Wilson
2016-04-13  8:45   ` Tvrtko Ursulin
2016-04-13  9:04     ` Chris Wilson
2016-04-13  9:14       ` Tvrtko Ursulin
2016-04-13  9:56         ` Chris Wilson
2016-04-13  6:58 ` ✗ Fi.CI.BAT: failure for series starting with [RFC,1/2] " Patchwork

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.