[PATCH 00/10] drm-intel-collector - update

[PATCH 00/10] drm-intel-collector - update

[Rodrigo Vivi]

This is another drm-intel-collector updated notice:
http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector

Here goes the update list in order for better reviewers assignment:

Patch     drm/i915: Check the minimum pitch for the user framebuffer - Reviewer:
Patch     drm/i915: Make the physical object coherent with GTT - Reviewer:
Patch     drm/i915/chv: Use timeout mode for RC6 on chv - Reviewer:
Patch     drm/i915: Specify bsd rings through exec flag - Reviewer:
Patch     drm/i915: add I915_PARAM_HAS_BSD2 to i915_getparam - Reviewer:
Patch     drm/i915: Enable vblank interrupts for CRC generation - Reviewer:
Patch     drm/i915: Move the ban period onto the context - Reviewer:
Patch     drm/i915: Add ioctl to set per-context parameters - Reviewer:
Patch     drm/i915: Put logical pipe_control emission into a helper. - Reviewer:
Patch     drm/i915: Add WaCsStallBeforeStateCacheInvalidate:bdw, chv to logical ring - Reviewer:


This update refers to five rounds between testing updates:
- Jul 25 to Aug 08
- Aug 08 to Aug 22
- Aug 22 to Sep 09
- Sep 09 to Sep 19
- Sep 19 to Oct 03

As always I just get standalone patches or series of 2 patches that had no obvious nacks or unfinished discussion.
If you thinkg your patch should be here please let me know or rebase over -nightly and resubmit that I collect
later.

Thanks,
Rodrigo.


Chris Wilson (5):
  drm/i915: Check the minimum pitch for the user framebuffer
  drm/i915: Make the physical object coherent with GTT
  drm/i915: Enable vblank interrupts for CRC generation
  drm/i915: Move the ban period onto the context
  drm/i915: Add ioctl to set per-context parameters

Deepak S (1):
  drm/i915/chv: Use timeout mode for RC6 on chv

Rodrigo Vivi (2):
  drm/i915: Put logical pipe_control emission into a helper.
  drm/i915: Add WaCsStallBeforeStateCacheInvalidate:bdw, chv to logical
    ring

Zhipeng Gong (2):
  drm/i915: Specify bsd rings through exec flag
  drm/i915: add I915_PARAM_HAS_BSD2 to i915_getparam

 drivers/gpu/drm/i915/i915_debugfs.c        |   7 +
 drivers/gpu/drm/i915/i915_dma.c            |   8 ++
 drivers/gpu/drm/i915/i915_drv.h            |  15 ++-
 drivers/gpu/drm/i915/i915_gem.c            | 210 ++++++++++++++++++++---------
 drivers/gpu/drm/i915/i915_gem_context.c    |  71 ++++++++++
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  19 ++-
 drivers/gpu/drm/i915/intel_display.c       |  11 ++
 drivers/gpu/drm/i915/intel_dp.c            |   3 +
 drivers/gpu/drm/i915/intel_lrc.c           |  41 ++++--
 drivers/gpu/drm/i915/intel_pm.c            |   4 +-
 include/uapi/drm/i915_drm.h                |  22 ++-
 11 files changed, 326 insertions(+), 85 deletions(-)

-- 
1.9.3

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

[PATCH 01/10] drm/i915: Check the minimum pitch for the user framebuffer

[Rodrigo Vivi]

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

Compute the smallest pitch required for a linear framebuffer and assert
that the user has declared a pitch that meets that minimum requirement.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
 drivers/gpu/drm/i915/intel_display.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 7d891e5..0b1e193 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12414,6 +12414,8 @@ static int intel_framebuffer_init(struct drm_device *dev,
 {
 	int aligned_height;
 	int pitch_limit;
+	int depth;
+	int bpp;
 	int ret;
 
 	WARN_ON(!mutex_is_locked(&dev->struct_mutex));
@@ -12429,6 +12431,15 @@ static int intel_framebuffer_init(struct drm_device *dev,
 		return -EINVAL;
 	}
 
+	drm_fb_get_bpp_depth(mode_cmd->pixel_format, &bpp, &depth);
+	if (mode_cmd->pitches[0] < intel_framebuffer_pitch_for_width(mode_cmd->width,
+								     bpp)) {
+		DRM_DEBUG("pitch (%d) must be at least the linear stride (%d)\n",
+			  mode_cmd->pitches[0],
+			  intel_framebuffer_pitch_for_width(mode_cmd->width, bpp));
+		return -EINVAL;
+	}
+
 	if (INTEL_INFO(dev)->gen >= 5 && !IS_VALLEYVIEW(dev)) {
 		pitch_limit = 32*1024;
 	} else if (INTEL_INFO(dev)->gen >= 4) {
-- 
1.9.3

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

[PATCH 02/10] drm/i915: Make the physical object coherent with GTT

[Rodrigo Vivi]

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

Currently objects for which the hardware needs a contiguous physical
address are allocated a shadow backing storage to satisfy the contraint.
This shadow buffer is not wired into the normal obj->pages and so the
physical object is incoherent with accesses via the GPU, GTT and CPU. By
setting up the appropriate scatter-gather table, we can allow userspace
to access the physical object via either a GTT mmaping of or by rendering
into the GEM bo. However, keeping the CPU mmap of the shmemfs backing
storage coherent with the contiguous shadow is not yet possible.
Fortuituously, CPU mmaps of objects requiring physical addresses are not
expected to be coherent anyway.

This allows the physical constraint of the GEM object to be transparent
to userspace and allow it to efficiently render into or update them via
the GTT and GPU.

v2: Fix leak of pci handle spotted by Ville
v3: Remove the now duplicate call to detach_phys_object during free.
v4: Wait for rendering before pwrite. As this patch makes it possible to
render into the phys object, we should make it correct as well!

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
 drivers/gpu/drm/i915/i915_dma.c |   3 +
 drivers/gpu/drm/i915/i915_drv.h |   6 +-
 drivers/gpu/drm/i915/i915_gem.c | 207 +++++++++++++++++++++++++++-------------
 include/uapi/drm/i915_drm.h     |   1 +
 4 files changed, 150 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 9a73533..5dc37f0 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1027,6 +1027,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
 	case I915_PARAM_CMD_PARSER_VERSION:
 		value = i915_cmd_parser_get_version();
 		break;
+	case I915_PARAM_HAS_COHERENT_PHYS_GTT:
+		value = 1;
+		break;
 	default:
 		DRM_DEBUG("Unknown parameter %d\n", param->param);
 		return -EINVAL;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 059330c..929d78d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1890,10 +1890,10 @@ struct drm_i915_gem_object {
 	unsigned long user_pin_count;
 	struct drm_file *pin_filp;
 
-	/** for phy allocated objects */
-	struct drm_dma_handle *phys_handle;
-
 	union {
+		/** for phy allocated objects */
+		struct drm_dma_handle *phys_handle;
+
 		struct i915_gem_userptr {
 			uintptr_t ptr;
 			unsigned read_only :1;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 827edb5..5223e98 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -208,40 +208,137 @@ i915_gem_get_aperture_ioctl(struct drm_device *dev, void *data,
 	return 0;
 }
 
-static void i915_gem_object_detach_phys(struct drm_i915_gem_object *obj)
+static int
+i915_gem_object_get_pages_phys(struct drm_i915_gem_object *obj)
 {
-	drm_dma_handle_t *phys = obj->phys_handle;
+	struct address_space *mapping = file_inode(obj->base.filp)->i_mapping;
+	char *vaddr = obj->phys_handle->vaddr;
+	struct sg_table *st;
+	struct scatterlist *sg;
+	int i;
 
-	if (!phys)
-		return;
+	if (WARN_ON(i915_gem_object_needs_bit17_swizzle(obj)))
+		return -EINVAL;
+
+	for (i = 0; i < obj->base.size / PAGE_SIZE; i++) {
+		struct page *page;
+		char *src;
+
+		page = shmem_read_mapping_page(mapping, i);
+		if (IS_ERR(page))
+			return PTR_ERR(page);
+
+		src = kmap_atomic(page);
+		memcpy(vaddr, src, PAGE_SIZE);
+		drm_clflush_virt_range(vaddr, PAGE_SIZE);
+		kunmap_atomic(src);
+
+		page_cache_release(page);
+		vaddr += PAGE_SIZE;
+	}
+
+	i915_gem_chipset_flush(obj->base.dev);
+
+	st = kmalloc(sizeof(*st), GFP_KERNEL);
+	if (st == NULL)
+		return -ENOMEM;
+
+	if (sg_alloc_table(st, 1, GFP_KERNEL)) {
+		kfree(st);
+		return -ENOMEM;
+	}
+
+	sg = st->sgl;
+	sg->offset = 0;
+	sg->length = obj->base.size;
 
-	if (obj->madv == I915_MADV_WILLNEED) {
+	sg_dma_address(sg) = obj->phys_handle->busaddr;
+	sg_dma_len(sg) = obj->base.size;
+
+	obj->pages = st;
+	obj->has_dma_mapping = true;
+	return 0;
+}
+
+static void
+i915_gem_object_put_pages_phys(struct drm_i915_gem_object *obj)
+{
+	int ret;
+
+	BUG_ON(obj->madv == __I915_MADV_PURGED);
+
+	ret = i915_gem_object_set_to_cpu_domain(obj, true);
+	if (ret) {
+		/* In the event of a disaster, abandon all caches and
+		 * hope for the best.
+		 */
+		WARN_ON(ret != -EIO);
+		obj->base.read_domains = obj->base.write_domain = I915_GEM_DOMAIN_CPU;
+	}
+
+	if (obj->madv == I915_MADV_DONTNEED)
+		obj->dirty = 0;
+
+	if (obj->dirty) {
 		struct address_space *mapping = file_inode(obj->base.filp)->i_mapping;
-		char *vaddr = phys->vaddr;
+		char *vaddr = obj->phys_handle->vaddr;
 		int i;
 
 		for (i = 0; i < obj->base.size / PAGE_SIZE; i++) {
-			struct page *page = shmem_read_mapping_page(mapping, i);
-			if (!IS_ERR(page)) {
-				char *dst = kmap_atomic(page);
-				memcpy(dst, vaddr, PAGE_SIZE);
-				drm_clflush_virt_range(dst, PAGE_SIZE);
-				kunmap_atomic(dst);
-
-				set_page_dirty(page);
+			struct page *page;
+			char *dst;
+
+			page = shmem_read_mapping_page(mapping, i);
+			if (IS_ERR(page))
+				continue;
+
+			dst = kmap_atomic(page);
+			drm_clflush_virt_range(vaddr, PAGE_SIZE);
+			memcpy(dst, vaddr, PAGE_SIZE);
+			kunmap_atomic(dst);
+
+			set_page_dirty(page);
+			if (obj->madv == I915_MADV_WILLNEED)
 				mark_page_accessed(page);
-				page_cache_release(page);
-			}
+			page_cache_release(page);
 			vaddr += PAGE_SIZE;
 		}
-		i915_gem_chipset_flush(obj->base.dev);
+		obj->dirty = 0;
 	}
 
-#ifdef CONFIG_X86
-	set_memory_wb((unsigned long)phys->vaddr, phys->size / PAGE_SIZE);
-#endif
-	drm_pci_free(obj->base.dev, phys);
-	obj->phys_handle = NULL;
+	sg_free_table(obj->pages);
+	kfree(obj->pages);
+
+	obj->has_dma_mapping = false;
+}
+
+static void
+i915_gem_object_release_phys(struct drm_i915_gem_object *obj)
+{
+	drm_pci_free(obj->base.dev, obj->phys_handle);
+}
+
+static const struct drm_i915_gem_object_ops i915_gem_phys_ops = {
+	.get_pages = i915_gem_object_get_pages_phys,
+	.put_pages = i915_gem_object_put_pages_phys,
+	.release = i915_gem_object_release_phys,
+};
+
+static int
+drop_pages(struct drm_i915_gem_object *obj)
+{
+	struct i915_vma *vma, *next;
+	int ret;
+
+	drm_gem_object_reference(&obj->base);
+	list_for_each_entry_safe(vma, next, &obj->vma_list, vma_link)
+		if (i915_vma_unbind(vma))
+			break;
+
+	ret = i915_gem_object_put_pages(obj);
+	drm_gem_object_unreference(&obj->base);
+
+	return ret;
 }
 
 int
@@ -249,9 +346,7 @@ i915_gem_object_attach_phys(struct drm_i915_gem_object *obj,
 			    int align)
 {
 	drm_dma_handle_t *phys;
-	struct address_space *mapping;
-	char *vaddr;
-	int i;
+	int ret;
 
 	if (obj->phys_handle) {
 		if ((unsigned long)obj->phys_handle->vaddr & (align -1))
@@ -266,41 +361,19 @@ i915_gem_object_attach_phys(struct drm_i915_gem_object *obj,
 	if (obj->base.filp == NULL)
 		return -EINVAL;
 
+	ret = drop_pages(obj);
+	if (ret)
+		return ret;
+
 	/* create a new object */
 	phys = drm_pci_alloc(obj->base.dev, obj->base.size, align);
 	if (!phys)
 		return -ENOMEM;
 
-	vaddr = phys->vaddr;
-#ifdef CONFIG_X86
-	set_memory_wc((unsigned long)vaddr, phys->size / PAGE_SIZE);
-#endif
-	mapping = file_inode(obj->base.filp)->i_mapping;
-	for (i = 0; i < obj->base.size / PAGE_SIZE; i++) {
-		struct page *page;
-		char *src;
-
-		page = shmem_read_mapping_page(mapping, i);
-		if (IS_ERR(page)) {
-#ifdef CONFIG_X86
-			set_memory_wb((unsigned long)phys->vaddr, phys->size / PAGE_SIZE);
-#endif
-			drm_pci_free(obj->base.dev, phys);
-			return PTR_ERR(page);
-		}
-
-		src = kmap_atomic(page);
-		memcpy(vaddr, src, PAGE_SIZE);
-		kunmap_atomic(src);
-
-		mark_page_accessed(page);
-		page_cache_release(page);
-
-		vaddr += PAGE_SIZE;
-	}
-
 	obj->phys_handle = phys;
-	return 0;
+	obj->ops = &i915_gem_phys_ops;
+
+	return i915_gem_object_get_pages(obj);
 }
 
 static int
@@ -311,6 +384,14 @@ i915_gem_phys_pwrite(struct drm_i915_gem_object *obj,
 	struct drm_device *dev = obj->base.dev;
 	void *vaddr = obj->phys_handle->vaddr + args->offset;
 	char __user *user_data = to_user_ptr(args->data_ptr);
+	int ret;
+
+	/* We manually control the domain here and pretend that it
+	 * remains coherent i.e. in the GTT domain, like shmem_pwrite.
+	 */
+	ret = i915_gem_object_wait_rendering(obj, false);
+	if (ret)
+		return ret;
 
 	if (__copy_from_user_inatomic_nocache(vaddr, user_data, args->size)) {
 		unsigned long unwritten;
@@ -326,6 +407,7 @@ i915_gem_phys_pwrite(struct drm_i915_gem_object *obj,
 			return -EFAULT;
 	}
 
+	drm_clflush_virt_range(vaddr, args->size);
 	i915_gem_chipset_flush(dev);
 	return 0;
 }
@@ -1046,11 +1128,6 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
 	 * pread/pwrite currently are reading and writing from the CPU
 	 * perspective, requiring manual detiling by the client.
 	 */
-	if (obj->phys_handle) {
-		ret = i915_gem_phys_pwrite(obj, args, file);
-		goto out;
-	}
-
 	if (obj->tiling_mode == I915_TILING_NONE &&
 	    obj->base.write_domain != I915_GEM_DOMAIN_CPU &&
 	    cpu_write_needs_clflush(obj)) {
@@ -1060,8 +1137,12 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
 		 * textures). Fallback to the shmem path in that case. */
 	}
 
-	if (ret == -EFAULT || ret == -ENOSPC)
-		ret = i915_gem_shmem_pwrite(dev, obj, args, file);
+	if (ret == -EFAULT || ret == -ENOSPC) {
+		if (obj->phys_handle)
+			ret = i915_gem_phys_pwrite(obj, args, file);
+		else
+			ret = i915_gem_shmem_pwrite(dev, obj, args, file);
+	}
 
 out:
 	drm_gem_object_unreference(&obj->base);
@@ -3522,7 +3603,7 @@ i915_gem_clflush_object(struct drm_i915_gem_object *obj,
 	 * Stolen memory is always coherent with the GPU as it is explicitly
 	 * marked as wc by the system, or the system is cache-coherent.
 	 */
-	if (obj->stolen)
+	if (obj->stolen || obj->phys_handle)
 		return false;
 
 	/* If the GPU is snooping the contents of the CPU cache,
@@ -4456,8 +4537,6 @@ void i915_gem_free_object(struct drm_gem_object *gem_obj)
 		}
 	}
 
-	i915_gem_object_detach_phys(obj);
-
 	/* Stolen objects don't hold a ref, but do hold pin count. Fix that up
 	 * before progressing. */
 	if (obj->stolen)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index ff57f07..c6b229f 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -340,6 +340,7 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_HAS_EXEC_HANDLE_LUT   26
 #define I915_PARAM_HAS_WT     	 	 27
 #define I915_PARAM_CMD_PARSER_VERSION	 28
+#define I915_PARAM_HAS_COHERENT_PHYS_GTT 29
 
 typedef struct drm_i915_getparam {
 	int param;
-- 
1.9.3

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

[PATCH 03/10] drm/i915/chv: Use timeout mode for RC6 on chv

[Rodrigo Vivi]

From: Deepak S <deepak.s@linux.intel.com>

Higher RC6 residency is observed using timeout mode
instead of EI mode. It's Recommended to use TO Method for RC6.

Signed-off-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
 drivers/gpu/drm/i915/intel_pm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7a69eba..0bfcd83 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4348,7 +4348,7 @@ static void cherryview_enable_rps(struct drm_device *dev)
 		I915_WRITE(RING_MAX_IDLE(ring->mmio_base), 10);
 	I915_WRITE(GEN6_RC_SLEEP, 0);
 
-	I915_WRITE(GEN6_RC6_THRESHOLD, 50000); /* 50/125ms per EI */
+	I915_WRITE(GEN6_RC6_THRESHOLD, 0x557);
 
 	/* allows RC6 residency counter to work */
 	I915_WRITE(VLV_COUNTER_CONTROL,
@@ -4364,7 +4364,7 @@ static void cherryview_enable_rps(struct drm_device *dev)
 	/* 3: Enable RC6 */
 	if ((intel_enable_rc6(dev) & INTEL_RC6_ENABLE) &&
 						(pcbr >> VLV_PCBR_ADDR_SHIFT))
-		rc6_mode = GEN6_RC_CTL_EI_MODE(1);
+		rc6_mode = GEN7_RC_CTL_TO_MODE;
 
 	I915_WRITE(GEN6_RC_CONTROL, rc6_mode);
 
-- 
1.9.3

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

Re: [PATCH 03/10] drm/i915/chv: Use timeout mode for RC6 on chv

[O'Rourke, Tom]

On Tue, Nov 04, 2014 at 04:51:41AM -0800, Rodrigo Vivi wrote:
> From: Deepak S <deepak.s@linux.intel.com>
> 
> Higher RC6 residency is observed using timeout mode
> instead of EI mode. It's Recommended to use TO Method for RC6.
> 
[TOR:] My comments on the previous version of this patch are at
http://lists.freedesktop.org/archives/intel-gfx/2014-August/050203.html

Based on the understanding this patch will provide benefit
on some pre-production CHV steppings and no benefit on the
production CHV steppings, this patch should not be merged.

> Signed-off-by: Deepak S <deepak.s@linux.intel.com>
> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 7a69eba..0bfcd83 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4348,7 +4348,7 @@ static void cherryview_enable_rps(struct drm_device *dev)
>  		I915_WRITE(RING_MAX_IDLE(ring->mmio_base), 10);
>  	I915_WRITE(GEN6_RC_SLEEP, 0);
>  
> -	I915_WRITE(GEN6_RC6_THRESHOLD, 50000); /* 50/125ms per EI */
> +	I915_WRITE(GEN6_RC6_THRESHOLD, 0x557);
>  
>  	/* allows RC6 residency counter to work */
>  	I915_WRITE(VLV_COUNTER_CONTROL,
> @@ -4364,7 +4364,7 @@ static void cherryview_enable_rps(struct drm_device *dev)
>  	/* 3: Enable RC6 */
>  	if ((intel_enable_rc6(dev) & INTEL_RC6_ENABLE) &&
>  						(pcbr >> VLV_PCBR_ADDR_SHIFT))
> -		rc6_mode = GEN6_RC_CTL_EI_MODE(1);
> +		rc6_mode = GEN7_RC_CTL_TO_MODE;
>  
>  	I915_WRITE(GEN6_RC_CONTROL, rc6_mode);
>  
> -- 
> 1.9.3
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 04/10] drm/i915: Specify bsd rings through exec flag

[Rodrigo Vivi]

From: Zhipeng Gong <zhipeng.gong@intel.com>

On Broadwell GT3 we have 2 Video Command Streamers (VCS), but userspace
has no control when using VCS1 or VCS2. This patch introduces a mechanism
to avoid the default ping-pong mode and use one specific ring through
execution flag.

v2: fix whitespace (Rodrigo)

Signed-off-by: Zhipeng Gong <zhipeng.gong@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 19 +++++++++++++++++--
 drivers/gpu/drm/i915/intel_dp.c            |  3 +++
 include/uapi/drm/i915_drm.h                |  8 +++++++-
 3 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 1a0611b..859e917 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1276,8 +1276,23 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
 	else if ((args->flags & I915_EXEC_RING_MASK) == I915_EXEC_BSD) {
 		if (HAS_BSD2(dev)) {
 			int ring_id;
-			ring_id = gen8_dispatch_bsd_ring(dev, file);
-			ring = &dev_priv->ring[ring_id];
+
+			switch (args->flags & I915_EXEC_BSD_MASK) {
+			case I915_EXEC_BSD_DEFAULT:
+				ring_id = gen8_dispatch_bsd_ring(dev, file);
+				ring = &dev_priv->ring[ring_id];
+				break;
+			case I915_EXEC_BSD_RING1:
+				ring = &dev_priv->ring[VCS];
+				break;
+			case I915_EXEC_BSD_RING2:
+				ring = &dev_priv->ring[VCS2];
+				break;
+			default:
+				DRM_DEBUG("execbuf with unknown bsd ring: %d\n",
+					  (int)(args->flags & I915_EXEC_BSD_MASK));
+				return -EINVAL;
+			}
 		} else
 			ring = &dev_priv->ring[VCS];
 	} else
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4455009..76ca5c0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4635,6 +4635,9 @@ intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
 		if (HAS_PCH_SPLIT(dev)) {
 			if (!ibx_digital_port_connected(dev_priv, intel_dig_port))
 				goto mst_fail;
+		if (!intel_dp->output_reg)
+			goto mst_fail;
+
 		} else {
 			if (g4x_digital_port_connected(dev, intel_dig_port) != 1)
 				goto mst_fail;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index c6b229f..b8ed3c1 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -737,7 +737,13 @@ struct drm_i915_gem_execbuffer2 {
  */
 #define I915_EXEC_HANDLE_LUT		(1<<12)
 
-#define __I915_EXEC_UNKNOWN_FLAGS -(I915_EXEC_HANDLE_LUT<<1)
+/** Used for switching BSD rings on the platforms with two BSD rings */
+#define I915_EXEC_BSD_MASK		(3<<13)
+#define I915_EXEC_BSD_DEFAULT		(0<<13) /* default ping-pong mode */
+#define I915_EXEC_BSD_RING1		(1<<13)
+#define I915_EXEC_BSD_RING2		(2<<13)
+
+#define __I915_EXEC_UNKNOWN_FLAGS -(1<<15)
 
 #define I915_EXEC_CONTEXT_ID_MASK	(0xffffffff)
 #define i915_execbuffer2_set_context_id(eb2, context) \
-- 
1.9.3

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

[PATCH 05/10] drm/i915: add I915_PARAM_HAS_BSD2 to i915_getparam

[Rodrigo Vivi]

From: Zhipeng Gong <zhipeng.gong@intel.com>

This will let userland only try to use the new ring
when the appropriate kernel is present

Signed-off-by: Zhipeng Gong <zhipeng.gong@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
 drivers/gpu/drm/i915/i915_dma.c | 3 +++
 include/uapi/drm/i915_drm.h     | 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5dc37f0..1c145ed 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -979,6 +979,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
 	case I915_PARAM_HAS_VEBOX:
 		value = intel_ring_initialized(&dev_priv->ring[VECS]);
 		break;
+	case I915_PARAM_HAS_BSD2:
+		value = intel_ring_initialized(&dev_priv->ring[VCS2]);
+		break;
 	case I915_PARAM_HAS_RELAXED_FENCING:
 		value = 1;
 		break;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index b8ed3c1..56007dc 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -341,6 +341,7 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_HAS_WT     	 	 27
 #define I915_PARAM_CMD_PARSER_VERSION	 28
 #define I915_PARAM_HAS_COHERENT_PHYS_GTT 29
+#define I915_PARAM_HAS_BSD2		 30
 
 typedef struct drm_i915_getparam {
 	int param;
-- 
1.9.3

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

[PATCH 06/10] drm/i915: Enable vblank interrupts for CRC generation

[Rodrigo Vivi]

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

Pineview requires this. But this changes the debug API...

References: https://bugs.freedesktop.org/show_bug.cgi?id=82280
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
 drivers/gpu/drm/i915/i915_debugfs.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
index e60d5c2..465a17b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2711,10 +2711,15 @@ static int i915_pipe_crc_open(struct inode *inode, struct file *filep)
 	struct pipe_crc_info *info = inode->i_private;
 	struct drm_i915_private *dev_priv = info->dev->dev_private;
 	struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[info->pipe];
+	int ret;
 
 	if (info->pipe >= INTEL_INFO(info->dev)->num_pipes)
 		return -ENODEV;
 
+	ret = drm_vblank_get(dev_priv->dev, info->pipe);
+	if (ret)
+		return ret;
+
 	spin_lock_irq(&pipe_crc->lock);
 
 	if (pipe_crc->opened) {
@@ -2740,6 +2745,8 @@ static int i915_pipe_crc_release(struct inode *inode, struct file *filep)
 	pipe_crc->opened = false;
 	spin_unlock_irq(&pipe_crc->lock);
 
+	drm_vblank_put(dev_priv->dev, info->pipe);
+
 	return 0;
 }
 
-- 
1.9.3

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

Re: [PATCH 06/10] drm/i915: Enable vblank interrupts for CRC generation

[Damien Lespiau]

On Tue, Nov 04, 2014 at 04:51:44AM -0800, Rodrigo Vivi wrote:
> From: Chris Wilson <chris@chris-wilson.co.uk>
> 
> Pineview requires this. But this changes the debug API...
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=82280
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

Chris already retracted this patch.

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

[PATCH 07/10] drm/i915: Move the ban period onto the context

[Rodrigo Vivi]

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

This will allow us to set per-file, or even per-context, periods in the
future.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
 drivers/gpu/drm/i915/i915_drv.h         | 5 +++++
 drivers/gpu/drm/i915/i915_gem.c         | 3 ++-
 drivers/gpu/drm/i915/i915_gem_context.c | 2 ++
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 929d78d..a76869c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -613,6 +613,11 @@ struct i915_ctx_hang_stats {
 	/* Time when this context was last blamed for a GPU reset */
 	unsigned long guilty_ts;
 
+	/* If the contexts causes a second GPU hang within this time,
+	 * it is permanently banned from submitting any more work.
+	 */
+	unsigned long ban_period_seconds;
+
 	/* This context is banned to submit more work */
 	bool banned;
 };
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5223e98..1da4a79 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2539,7 +2539,8 @@ static bool i915_context_is_banned(struct drm_i915_private *dev_priv,
 	if (ctx->hang_stats.banned)
 		return true;
 
-	if (elapsed <= DRM_I915_CTX_BAN_PERIOD) {
+	if (ctx->hang_stats.ban_period_seconds &&
+	    elapsed <= ctx->hang_stats.ban_period_seconds) {
 		if (!i915_gem_context_is_default(ctx)) {
 			DRM_DEBUG("context hanging too fast, banning!\n");
 			return true;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c
index a5221d8..9da78d5 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -219,6 +219,8 @@ __create_hw_context(struct drm_device *dev,
 	 * is no remap info, it will be a NOP. */
 	ctx->remap_slice = (1 << NUM_L3_SLICES(dev)) - 1;
 
+	ctx->hang_stats.ban_period_seconds = DRM_I915_CTX_BAN_PERIOD;
+
 	return ctx;
 
 err_out:
-- 
1.9.3

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

[PATCH 08/10] drm/i915: Add ioctl to set per-context parameters

[Rodrigo Vivi]

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

Sometimes we wish to tweak how an individual context behaves. Since we
always create a context for every filp, this means that individual
processes can fine tune their behaviour even if they do not explicitly
create a context.

The first example parameter here is to enable multi-process GPU testing,
but the interface should be able to cope with passing arbitrarily complex
parameters.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
 drivers/gpu/drm/i915/i915_dma.c         |  2 +
 drivers/gpu/drm/i915/i915_drv.h         |  4 ++
 drivers/gpu/drm/i915/i915_gem_context.c | 69 +++++++++++++++++++++++++++++++++
 include/uapi/drm/i915_drm.h             | 12 ++++++
 4 files changed, 87 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 1c145ed..04a6f77 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -2042,6 +2042,8 @@ const struct drm_ioctl_desc i915_ioctls[] = {
 	DRM_IOCTL_DEF_DRV(I915_REG_READ, i915_reg_read_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
 	DRM_IOCTL_DEF_DRV(I915_GET_RESET_STATS, i915_get_reset_stats_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
 	DRM_IOCTL_DEF_DRV(I915_GEM_USERPTR, i915_gem_userptr_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
+	DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM, i915_gem_context_getparam_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
+	DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM, i915_gem_context_setparam_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
 };
 
 int i915_max_ioctl = ARRAY_SIZE(i915_ioctls);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a76869c..82af38e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2679,6 +2679,10 @@ int i915_gem_context_create_ioctl(struct drm_device *dev, void *data,
 				  struct drm_file *file);
 int i915_gem_context_destroy_ioctl(struct drm_device *dev, void *data,
 				   struct drm_file *file);
+int i915_gem_context_getparam_ioctl(struct drm_device *dev, void *data,
+				    struct drm_file *file_priv);
+int i915_gem_context_setparam_ioctl(struct drm_device *dev, void *data,
+				    struct drm_file *file_priv);
 
 /* i915_gem_evict.c */
 int __must_check i915_gem_evict_something(struct drm_device *dev,
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c
index 9da78d5..958d2cf 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -743,3 +743,72 @@ int i915_gem_context_destroy_ioctl(struct drm_device *dev, void *data,
 	DRM_DEBUG_DRIVER("HW context %d destroyed\n", args->ctx_id);
 	return 0;
 }
+
+int i915_gem_context_getparam_ioctl(struct drm_device *dev, void *data,
+				    struct drm_file *file)
+{
+	struct drm_i915_file_private *file_priv = file->driver_priv;
+	struct drm_i915_gem_context_param *args = data;
+	struct intel_context *ctx;
+	int ret;
+
+	ret = i915_mutex_lock_interruptible(dev);
+	if (ret)
+		return ret;
+
+	ctx = i915_gem_context_get(file_priv, args->ctx_id);
+	if (IS_ERR(ctx)) {
+		mutex_unlock(&dev->struct_mutex);
+		return PTR_ERR(ctx);
+	}
+
+	args->size = 0;
+	switch (args->param) {
+	case I915_CONTEXT_PARAM_BAN_PERIOD:
+		args->value = ctx->hang_stats.ban_period_seconds;
+		break;
+	default:
+		ret = -EINVAL;
+		break;
+	}
+	mutex_unlock(&dev->struct_mutex);
+
+	return ret;
+}
+
+int i915_gem_context_setparam_ioctl(struct drm_device *dev, void *data,
+				    struct drm_file *file)
+{
+	struct drm_i915_file_private *file_priv = file->driver_priv;
+	struct drm_i915_gem_context_param *args = data;
+	struct intel_context *ctx;
+	int ret;
+
+	ret = i915_mutex_lock_interruptible(dev);
+	if (ret)
+		return ret;
+
+	ctx = i915_gem_context_get(file_priv, args->ctx_id);
+	if (IS_ERR(ctx)) {
+		mutex_unlock(&dev->struct_mutex);
+		return PTR_ERR(ctx);
+	}
+
+	switch (args->param) {
+	case I915_CONTEXT_PARAM_BAN_PERIOD:
+		if (args->size)
+			ret = -EINVAL;
+		else if (args->value < ctx->hang_stats.ban_period_seconds &&
+			 !capable(CAP_SYS_ADMIN))
+			ret = -EPERM;
+		else
+			ctx->hang_stats.ban_period_seconds = args->value;
+		break;
+	default:
+		ret = -EINVAL;
+		break;
+	}
+	mutex_unlock(&dev->struct_mutex);
+
+	return ret;
+}
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 56007dc..2403894 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -224,6 +224,8 @@ typedef struct _drm_i915_sarea {
 #define DRM_I915_REG_READ		0x31
 #define DRM_I915_GET_RESET_STATS	0x32
 #define DRM_I915_GEM_USERPTR		0x33
+#define DRM_I915_GEM_CONTEXT_GETPARAM	0x34
+#define DRM_I915_GEM_CONTEXT_SETPARAM	0x35
 
 #define DRM_IOCTL_I915_INIT		DRM_IOW( DRM_COMMAND_BASE + DRM_I915_INIT, drm_i915_init_t)
 #define DRM_IOCTL_I915_FLUSH		DRM_IO ( DRM_COMMAND_BASE + DRM_I915_FLUSH)
@@ -275,6 +277,8 @@ typedef struct _drm_i915_sarea {
 #define DRM_IOCTL_I915_REG_READ			DRM_IOWR (DRM_COMMAND_BASE + DRM_I915_REG_READ, struct drm_i915_reg_read)
 #define DRM_IOCTL_I915_GET_RESET_STATS		DRM_IOWR (DRM_COMMAND_BASE + DRM_I915_GET_RESET_STATS, struct drm_i915_reset_stats)
 #define DRM_IOCTL_I915_GEM_USERPTR			DRM_IOWR (DRM_COMMAND_BASE + DRM_I915_GEM_USERPTR, struct drm_i915_gem_userptr)
+#define DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM	DRM_IOWR (DRM_COMMAND_BASE + DRM_I915_GEM_CONTEXT_GETPARAM, struct drm_i915_gem_context_param)
+#define DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM	DRM_IOWR (DRM_COMMAND_BASE + DRM_I915_GEM_CONTEXT_SETPARAM, struct drm_i915_gem_context_param)
 
 /* Allow drivers to submit batchbuffers directly to hardware, relying
  * on the security mechanisms provided by hardware.
@@ -1074,4 +1078,12 @@ struct drm_i915_gem_userptr {
 	__u32 handle;
 };
 
+struct drm_i915_gem_context_param {
+	__u32 ctx_id;
+	__u32 size;
+	__u64 param;
+#define I915_CONTEXT_PARAM_BAN_PERIOD 0x1
+	__u64 value;
+};
+
 #endif /* _UAPI_I915_DRM_H_ */
-- 
1.9.3

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

[PATCH 09/10] drm/i915: Put logical pipe_control emission into a helper.

[Rodrigo Vivi]

To be used for a Workaroud. Similar to:

commit 884ceacee308f0e4616d0c933518af2639f7b1d8
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Sat Jun 28 02:04:20 2014 +0300

    drm/i915: Refactor Broadwell PIPE_CONTROL emission into a helper.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
 drivers/gpu/drm/i915/intel_lrc.c | 35 +++++++++++++++++++++--------------
 1 file changed, 21 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index cd74e5c..578a181 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1128,6 +1128,26 @@ static int gen8_emit_flush(struct intel_ringbuffer *ringbuf,
 	return 0;
 }
 
+static int gen8_emit_pipe_control(struct intel_ringbuffer *ringbuf,
+				  u32 flags, u32 scratch_addr)
+{
+	int ret;
+
+	ret = intel_logical_ring_begin(ringbuf, 6);
+	if (ret)
+		return ret;
+
+	intel_logical_ring_emit(ringbuf, GFX_OP_PIPE_CONTROL(6));
+	intel_logical_ring_emit(ringbuf, flags);
+	intel_logical_ring_emit(ringbuf, scratch_addr);
+	intel_logical_ring_emit(ringbuf, 0);
+	intel_logical_ring_emit(ringbuf, 0);
+	intel_logical_ring_emit(ringbuf, 0);
+	intel_logical_ring_advance(ringbuf);
+
+	return 0;
+}
+
 static int gen8_emit_flush_render(struct intel_ringbuffer *ringbuf,
 				  u32 invalidate_domains,
 				  u32 flush_domains)
@@ -1135,7 +1155,6 @@ static int gen8_emit_flush_render(struct intel_ringbuffer *ringbuf,
 	struct intel_engine_cs *ring = ringbuf->ring;
 	u32 scratch_addr = ring->scratch.gtt_offset + 2 * CACHELINE_BYTES;
 	u32 flags = 0;
-	int ret;
 
 	flags |= PIPE_CONTROL_CS_STALL;
 
@@ -1155,19 +1174,7 @@ static int gen8_emit_flush_render(struct intel_ringbuffer *ringbuf,
 		flags |= PIPE_CONTROL_GLOBAL_GTT_IVB;
 	}
 
-	ret = intel_logical_ring_begin(ringbuf, 6);
-	if (ret)
-		return ret;
-
-	intel_logical_ring_emit(ringbuf, GFX_OP_PIPE_CONTROL(6));
-	intel_logical_ring_emit(ringbuf, flags);
-	intel_logical_ring_emit(ringbuf, scratch_addr);
-	intel_logical_ring_emit(ringbuf, 0);
-	intel_logical_ring_emit(ringbuf, 0);
-	intel_logical_ring_emit(ringbuf, 0);
-	intel_logical_ring_advance(ringbuf);
-
-	return 0;
+	return gen8_emit_pipe_control(ringbuf, flags, scratch_addr);
 }
 
 static u32 gen8_get_seqno(struct intel_engine_cs *ring, bool lazy_coherency)
-- 
1.9.3

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

[PATCH 10/10] drm/i915: Add WaCsStallBeforeStateCacheInvalidate:bdw, chv to logical ring

[Rodrigo Vivi]

Similar to:

commit 02c9f7e3cfe76a7f54ef03438c36aade86cc1c8b
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Mon Jan 27 14:20:16 2014 -0800

    drm/i915: Add the WaCsStallBeforeStateCacheInvalidate:bdw workaround.

    On Broadwell, any PIPE_CONTROL with the "State Cache Invalidate" bit set
    must be preceded by a PIPE_CONTROL with the "CS Stall" bit set.

    Documented on the BSpec 3D workarounds page.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
 drivers/gpu/drm/i915/intel_lrc.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 578a181..485a5ee 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1155,6 +1155,7 @@ static int gen8_emit_flush_render(struct intel_ringbuffer *ringbuf,
 	struct intel_engine_cs *ring = ringbuf->ring;
 	u32 scratch_addr = ring->scratch.gtt_offset + 2 * CACHELINE_BYTES;
 	u32 flags = 0;
+	int ret;
 
 	flags |= PIPE_CONTROL_CS_STALL;
 
@@ -1172,6 +1173,15 @@ static int gen8_emit_flush_render(struct intel_ringbuffer *ringbuf,
 		flags |= PIPE_CONTROL_STATE_CACHE_INVALIDATE;
 		flags |= PIPE_CONTROL_QW_WRITE;
 		flags |= PIPE_CONTROL_GLOBAL_GTT_IVB;
+
+
+		/* WaCsStallBeforeStateCacheInvalidate:bdw,chv */
+		ret = gen8_emit_pipe_control(ring,
+					     PIPE_CONTROL_CS_STALL |
+					     PIPE_CONTROL_STALL_AT_SCOREBOARD,
+					     0);
+		if (ret)
+			return ret;
 	}
 
 	return gen8_emit_pipe_control(ringbuf, flags, scratch_addr);
-- 
1.9.3

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

Re: [PATCH 00/10] drm-intel-collector - update

[Rodrigo Vivi]

Just a warning that this round collector had many differences on PRTS:

HSw:
Testing: http://tinderbox.sh.intel.com/PRTS_UI/prtsresult.php?task_id=3869
Collector: http://tinderbox.sh.intel.com/PRTS_UI/prtsresult.php?task_id=3874
Comparison: http://tinderbox.sh.intel.com/PRTS_UI/prtscompareresult.php?sub_task_id1=15868&sub_task_id2=15873

ILK:
Testing: http://tinderbox.sh.intel.com/PRTS_UI/prtsresult.php?task_id=3872
Collector: http://tinderbox.sh.intel.com/PRTS_UI/prtsresult.php?task_id=3870
Comparison: http://tinderbox.sh.intel.com/PRTS_UI/prtscompareresult.php?sub_task_id1=15871&sub_task_id2=15869

IVB:
Testing: http://tinderbox.sh.intel.com/PRTS_UI/prtsresult.php?task_id=3871
Collector: http://tinderbox.sh.intel.com/PRTS_UI/prtsresult.php?task_id=3873
Comparison: http://tinderbox.sh.intel.com/PRTS_UI/prtscompareresult.php?sub_task_id1=15870&sub_task_id2=15872

Most of differences related to kms_flip and kms_plane, gem_evic and
gem_concurrent. And most breaking more stuff than fixing them.


On Tue, Nov 4, 2014 at 4:51 AM, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
>
> This is another drm-intel-collector updated notice:
> http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector
>
> Here goes the update list in order for better reviewers assignment:
>
> Patch     drm/i915: Check the minimum pitch for the user framebuffer - Reviewer:
> Patch     drm/i915: Make the physical object coherent with GTT - Reviewer:
> Patch     drm/i915/chv: Use timeout mode for RC6 on chv - Reviewer:
> Patch     drm/i915: Specify bsd rings through exec flag - Reviewer:
> Patch     drm/i915: add I915_PARAM_HAS_BSD2 to i915_getparam - Reviewer:
> Patch     drm/i915: Enable vblank interrupts for CRC generation - Reviewer:
> Patch     drm/i915: Move the ban period onto the context - Reviewer:
> Patch     drm/i915: Add ioctl to set per-context parameters - Reviewer:
> Patch     drm/i915: Put logical pipe_control emission into a helper. - Reviewer:
> Patch     drm/i915: Add WaCsStallBeforeStateCacheInvalidate:bdw, chv to logical ring - Reviewer:
>
>
> This update refers to five rounds between testing updates:
> - Jul 25 to Aug 08
> - Aug 08 to Aug 22
> - Aug 22 to Sep 09
> - Sep 09 to Sep 19
> - Sep 19 to Oct 03
>
> As always I just get standalone patches or series of 2 patches that had no obvious nacks or unfinished discussion.
> If you thinkg your patch should be here please let me know or rebase over -nightly and resubmit that I collect
> later.
>
> Thanks,
> Rodrigo.
>
>
> Chris Wilson (5):
>   drm/i915: Check the minimum pitch for the user framebuffer
>   drm/i915: Make the physical object coherent with GTT
>   drm/i915: Enable vblank interrupts for CRC generation
>   drm/i915: Move the ban period onto the context
>   drm/i915: Add ioctl to set per-context parameters
>
> Deepak S (1):
>   drm/i915/chv: Use timeout mode for RC6 on chv
>
> Rodrigo Vivi (2):
>   drm/i915: Put logical pipe_control emission into a helper.
>   drm/i915: Add WaCsStallBeforeStateCacheInvalidate:bdw, chv to logical
>     ring
>
> Zhipeng Gong (2):
>   drm/i915: Specify bsd rings through exec flag
>   drm/i915: add I915_PARAM_HAS_BSD2 to i915_getparam
>
>  drivers/gpu/drm/i915/i915_debugfs.c        |   7 +
>  drivers/gpu/drm/i915/i915_dma.c            |   8 ++
>  drivers/gpu/drm/i915/i915_drv.h            |  15 ++-
>  drivers/gpu/drm/i915/i915_gem.c            | 210 ++++++++++++++++++++---------
>  drivers/gpu/drm/i915/i915_gem_context.c    |  71 ++++++++++
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c |  19 ++-
>  drivers/gpu/drm/i915/intel_display.c       |  11 ++
>  drivers/gpu/drm/i915/intel_dp.c            |   3 +
>  drivers/gpu/drm/i915/intel_lrc.c           |  41 ++++--
>  drivers/gpu/drm/i915/intel_pm.c            |   4 +-
>  include/uapi/drm/i915_drm.h                |  22 ++-
>  11 files changed, 326 insertions(+), 85 deletions(-)
>
> --
> 1.9.3
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 00/10] drm-intel-collector - update

[Ville Syrjälä]

On Tue, Nov 04, 2014 at 04:51:38AM -0800, Rodrigo Vivi wrote:
> 
> This is another drm-intel-collector updated notice:
> http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector
> 
> Here goes the update list in order for better reviewers assignment:
> 
> Patch     drm/i915: Check the minimum pitch for the user framebuffer - Reviewer:

My comment still stands that the core checks should have caught this.
Actually now I think about it, addfb didn't call framebuffer_check()
until very recently, which could explain this. So the problem might be
fixed by

commit 228f2cb32f0dbeef0b88dc97ea66a3c31b03de99
Author: Chuck Ebbert <cebbert.lkml@gmail.com>
Date:   Wed Oct 8 11:40:34 2014 -0500

    drm/crtc: Remove duplicated ioctl code

> Patch     drm/i915: Make the physical object coherent with GTT - Reviewer:

Already has my r-b.

> Patch     drm/i915: Enable vblank interrupts for CRC generation - Reviewer:

IIRC everyone agreed that this isn't needed.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 00/10] drm-intel-collector - update

[Daniel Vetter]

On Thu, Nov 06, 2014 at 09:57:29AM +0200, Ville Syrjälä wrote:
> On Tue, Nov 04, 2014 at 04:51:38AM -0800, Rodrigo Vivi wrote:
> > Patch     drm/i915: Make the physical object coherent with GTT - Reviewer:
> 
> Already has my r-b.

I still would like to see a little testcase here, e.g. a new mode to
kms_cursor_crc which uses gtt mmap uploads instead of pwrite.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 00/10] drm-intel-collector - update

[Chris Wilson]

On Tue, Nov 11, 2014 at 11:20:14AM +0100, Daniel Vetter wrote:
> On Thu, Nov 06, 2014 at 09:57:29AM +0200, Ville Syrjälä wrote:
> > On Tue, Nov 04, 2014 at 04:51:38AM -0800, Rodrigo Vivi wrote:
> > > Patch     drm/i915: Make the physical object coherent with GTT - Reviewer:
> > 
> > Already has my r-b.
> 
> I still would like to see a little testcase here, e.g. a new mode to
> kms_cursor_crc which uses gtt mmap uploads instead of pwrite.

But that doesn't block this patch, as the kernel already exposes and
userspace already uses gtt mmap updates to the cursor. The patch just
removes the barrier to do so using early chipsets as well.
-Chris

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

Re: [PATCH 00/10] drm-intel-collector - update

[Daniel Vetter]

On Tue, Nov 11, 2014 at 10:22:11AM +0000, Chris Wilson wrote:
> On Tue, Nov 11, 2014 at 11:20:14AM +0100, Daniel Vetter wrote:
> > On Thu, Nov 06, 2014 at 09:57:29AM +0200, Ville Syrjälä wrote:
> > > On Tue, Nov 04, 2014 at 04:51:38AM -0800, Rodrigo Vivi wrote:
> > > > Patch     drm/i915: Make the physical object coherent with GTT - Reviewer:
> > > 
> > > Already has my r-b.
> > 
> > I still would like to see a little testcase here, e.g. a new mode to
> > kms_cursor_crc which uses gtt mmap uploads instead of pwrite.
> 
> But that doesn't block this patch, as the kernel already exposes and
> userspace already uses gtt mmap updates to the cursor. The patch just
> removes the barrier to do so using early chipsets as well.

Well yeah, but that existing code has piles of tests already to make sure
that gtt writes are somewhat coherent with pwrite, and another test that
pwrite is coherent with the actual cursor scanned out by hw.

This otoh adds new code, without igt test coverage. So there is a new test
coverage gap.

Anyway I've decided that the cleanup is worth it on its own and the
platform this applies to are too old to really care, so merged the patch
without tests.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 00/10] drm-intel-collector - update

[Chris Wilson]

On Tue, Nov 11, 2014 at 12:54:13PM +0100, Daniel Vetter wrote:
> On Tue, Nov 11, 2014 at 10:22:11AM +0000, Chris Wilson wrote:
> > On Tue, Nov 11, 2014 at 11:20:14AM +0100, Daniel Vetter wrote:
> > > On Thu, Nov 06, 2014 at 09:57:29AM +0200, Ville Syrjälä wrote:
> > > > On Tue, Nov 04, 2014 at 04:51:38AM -0800, Rodrigo Vivi wrote:
> > > > > Patch     drm/i915: Make the physical object coherent with GTT - Reviewer:
> > > > 
> > > > Already has my r-b.
> > > 
> > > I still would like to see a little testcase here, e.g. a new mode to
> > > kms_cursor_crc which uses gtt mmap uploads instead of pwrite.
> > 
> > But that doesn't block this patch, as the kernel already exposes and
> > userspace already uses gtt mmap updates to the cursor. The patch just
> > removes the barrier to do so using early chipsets as well.
> 
> Well yeah, but that existing code has piles of tests already to make sure
> that gtt writes are somewhat coherent with pwrite, and another test that
> pwrite is coherent with the actual cursor scanned out by hw.

Really? I doubt the current coverage since I keep seeing cursor bugs...
-Chris

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

Re: [PATCH 00/10] drm-intel-collector - update

[Daniel Vetter]

On Tue, Nov 11, 2014 at 11:57:16AM +0000, Chris Wilson wrote:
> On Tue, Nov 11, 2014 at 12:54:13PM +0100, Daniel Vetter wrote:
> > On Tue, Nov 11, 2014 at 10:22:11AM +0000, Chris Wilson wrote:
> > > On Tue, Nov 11, 2014 at 11:20:14AM +0100, Daniel Vetter wrote:
> > > > On Thu, Nov 06, 2014 at 09:57:29AM +0200, Ville Syrjälä wrote:
> > > > > On Tue, Nov 04, 2014 at 04:51:38AM -0800, Rodrigo Vivi wrote:
> > > > > > Patch     drm/i915: Make the physical object coherent with GTT - Reviewer:
> > > > > 
> > > > > Already has my r-b.
> > > > 
> > > > I still would like to see a little testcase here, e.g. a new mode to
> > > > kms_cursor_crc which uses gtt mmap uploads instead of pwrite.
> > > 
> > > But that doesn't block this patch, as the kernel already exposes and
> > > userspace already uses gtt mmap updates to the cursor. The patch just
> > > removes the barrier to do so using early chipsets as well.
> > 
> > Well yeah, but that existing code has piles of tests already to make sure
> > that gtt writes are somewhat coherent with pwrite, and another test that
> > pwrite is coherent with the actual cursor scanned out by hw.
> 
> Really? I doubt the current coverage since I keep seeing cursor bugs...

Well they do tend to randomly fail here. Not sure whether that's the same
bug or a different one ... Ofc tests without people looking aren't too
useful, but we have to start somewhere.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 00/10] drm-intel-collector - update

[Ville Syrjälä]

On Tue, Nov 11, 2014 at 12:54:13PM +0100, Daniel Vetter wrote:
> On Tue, Nov 11, 2014 at 10:22:11AM +0000, Chris Wilson wrote:
> > On Tue, Nov 11, 2014 at 11:20:14AM +0100, Daniel Vetter wrote:
> > > On Thu, Nov 06, 2014 at 09:57:29AM +0200, Ville Syrjälä wrote:
> > > > On Tue, Nov 04, 2014 at 04:51:38AM -0800, Rodrigo Vivi wrote:
> > > > > Patch     drm/i915: Make the physical object coherent with GTT - Reviewer:
> > > > 
> > > > Already has my r-b.
> > > 
> > > I still would like to see a little testcase here, e.g. a new mode to
> > > kms_cursor_crc which uses gtt mmap uploads instead of pwrite.
> > 
> > But that doesn't block this patch, as the kernel already exposes and
> > userspace already uses gtt mmap updates to the cursor. The patch just
> > removes the barrier to do so using early chipsets as well.
> 
> Well yeah, but that existing code has piles of tests already to make sure
> that gtt writes are somewhat coherent with pwrite, and another test that
> pwrite is coherent with the actual cursor scanned out by hw.

Actually pwrite isn't coherent with scanout currently on LLC platforms
if you do the pwrite when the bo already has cache_level==NONE but it's
not yet pinned to the display. So seems our pwrite tests aren't entirely
comprehensive currently if they don't hit this. I still haven't seen
the fabled patch from Chris that would fix this.

> 
> This otoh adds new code, without igt test coverage. So there is a new test
> coverage gap.
> 
> Anyway I've decided that the cleanup is worth it on its own and the
> platform this applies to are too old to really care, so merged the patch
> without tests.
> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 00/10] drm-intel-collector - update

[Chris Wilson]

On Tue, Nov 11, 2014 at 02:16:32PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 11, 2014 at 12:54:13PM +0100, Daniel Vetter wrote:
> > On Tue, Nov 11, 2014 at 10:22:11AM +0000, Chris Wilson wrote:
> > > On Tue, Nov 11, 2014 at 11:20:14AM +0100, Daniel Vetter wrote:
> > > > On Thu, Nov 06, 2014 at 09:57:29AM +0200, Ville Syrjälä wrote:
> > > > > On Tue, Nov 04, 2014 at 04:51:38AM -0800, Rodrigo Vivi wrote:
> > > > > > Patch     drm/i915: Make the physical object coherent with GTT - Reviewer:
> > > > > 
> > > > > Already has my r-b.
> > > > 
> > > > I still would like to see a little testcase here, e.g. a new mode to
> > > > kms_cursor_crc which uses gtt mmap uploads instead of pwrite.
> > > 
> > > But that doesn't block this patch, as the kernel already exposes and
> > > userspace already uses gtt mmap updates to the cursor. The patch just
> > > removes the barrier to do so using early chipsets as well.
> > 
> > Well yeah, but that existing code has piles of tests already to make sure
> > that gtt writes are somewhat coherent with pwrite, and another test that
> > pwrite is coherent with the actual cursor scanned out by hw.
> 
> Actually pwrite isn't coherent with scanout currently on LLC platforms
> if you do the pwrite when the bo already has cache_level==NONE but it's
> not yet pinned to the display. So seems our pwrite tests aren't entirely
> comprehensive currently if they don't hit this. I still haven't seen
> the fabled patch from Chris that would fix this.

This patch includes an unconditional clflush for phys writes (or at
least this patch should be that patch) which is what I thought we were
arguing about at the time.
-Chris

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

Re: [PATCH 00/10] drm-intel-collector - update

[Ville Syrjälä]

On Tue, Nov 11, 2014 at 12:26:59PM +0000, Chris Wilson wrote:
> On Tue, Nov 11, 2014 at 02:16:32PM +0200, Ville Syrjälä wrote:
> > On Tue, Nov 11, 2014 at 12:54:13PM +0100, Daniel Vetter wrote:
> > > On Tue, Nov 11, 2014 at 10:22:11AM +0000, Chris Wilson wrote:
> > > > On Tue, Nov 11, 2014 at 11:20:14AM +0100, Daniel Vetter wrote:
> > > > > On Thu, Nov 06, 2014 at 09:57:29AM +0200, Ville Syrjälä wrote:
> > > > > > On Tue, Nov 04, 2014 at 04:51:38AM -0800, Rodrigo Vivi wrote:
> > > > > > > Patch     drm/i915: Make the physical object coherent with GTT - Reviewer:
> > > > > > 
> > > > > > Already has my r-b.
> > > > > 
> > > > > I still would like to see a little testcase here, e.g. a new mode to
> > > > > kms_cursor_crc which uses gtt mmap uploads instead of pwrite.
> > > > 
> > > > But that doesn't block this patch, as the kernel already exposes and
> > > > userspace already uses gtt mmap updates to the cursor. The patch just
> > > > removes the barrier to do so using early chipsets as well.
> > > 
> > > Well yeah, but that existing code has piles of tests already to make sure
> > > that gtt writes are somewhat coherent with pwrite, and another test that
> > > pwrite is coherent with the actual cursor scanned out by hw.
> > 
> > Actually pwrite isn't coherent with scanout currently on LLC platforms
> > if you do the pwrite when the bo already has cache_level==NONE but it's
> > not yet pinned to the display. So seems our pwrite tests aren't entirely
> > comprehensive currently if they don't hit this. I still haven't seen
> > the fabled patch from Chris that would fix this.
> 
> This patch includes an unconditional clflush for phys writes (or at
> least this patch should be that patch) which is what I thought we were
> arguing about at the time.

Ah, so there's no patch then? I must have misundestood. I do remember you
had a quick hack to always flush in set_cache_level(), but I guess it
never went beyond that.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 00/10] drm-intel-collector - update

[Chris Wilson]

On Tue, Nov 11, 2014 at 02:38:15PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 11, 2014 at 12:26:59PM +0000, Chris Wilson wrote:
> > This patch includes an unconditional clflush for phys writes (or at
> > least this patch should be that patch) which is what I thought we were
> > arguing about at the time.
> 
> Ah, so there's no patch then? I must have misundestood. I do remember you
> had a quick hack to always flush in set_cache_level(), but I guess it
> never went beyond that.

I have nothing in my tree. The last I remember on that subject was the
obj->pin_display forcing the clflush.
-Chris

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

Re: [PATCH 00/10] drm-intel-collector - update

[Daniel Vetter]

On Tue, Nov 11, 2014 at 02:16:32PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 11, 2014 at 12:54:13PM +0100, Daniel Vetter wrote:
> > On Tue, Nov 11, 2014 at 10:22:11AM +0000, Chris Wilson wrote:
> > > On Tue, Nov 11, 2014 at 11:20:14AM +0100, Daniel Vetter wrote:
> > > > On Thu, Nov 06, 2014 at 09:57:29AM +0200, Ville Syrjälä wrote:
> > > > > On Tue, Nov 04, 2014 at 04:51:38AM -0800, Rodrigo Vivi wrote:
> > > > > > Patch     drm/i915: Make the physical object coherent with GTT - Reviewer:
> > > > > 
> > > > > Already has my r-b.
> > > > 
> > > > I still would like to see a little testcase here, e.g. a new mode to
> > > > kms_cursor_crc which uses gtt mmap uploads instead of pwrite.
> > > 
> > > But that doesn't block this patch, as the kernel already exposes and
> > > userspace already uses gtt mmap updates to the cursor. The patch just
> > > removes the barrier to do so using early chipsets as well.
> > 
> > Well yeah, but that existing code has piles of tests already to make sure
> > that gtt writes are somewhat coherent with pwrite, and another test that
> > pwrite is coherent with the actual cursor scanned out by hw.
> 
> Actually pwrite isn't coherent with scanout currently on LLC platforms
> if you do the pwrite when the bo already has cache_level==NONE but it's
> not yet pinned to the display. So seems our pwrite tests aren't entirely
> comprehensive currently if they don't hit this. I still haven't seen
> the fabled patch from Chris that would fix this.

Yeah they don't check the display using CRCs for all corner cases, that
seems to indeed be missing. But should be fairly simple to add a new
subtest to kms_cursor_crc to rotate the color quadrants a bit with pwrite
for each frame.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx