All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v14 0/11] Support for creating/using Stolen memory backed objects
@ 2016-01-14  6:16 ankitprasad.r.sharma
  2016-01-14  6:16 ` [PATCH 01/11] drm/i915: Add support for mapping an object page by page ankitprasad.r.sharma
                   ` (11 more replies)
  0 siblings, 12 replies; 118+ messages in thread
From: ankitprasad.r.sharma @ 2016-01-14  6:16 UTC (permalink / raw)
  To: intel-gfx; +Cc: akash.goel, shashidhar.hiremath, Ankitprasad Sharma

From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>

This patch series adds support for creating/using Stolen memory backed
objects.

Despite being a unified memory architecture (UMA) some bits of memory
are more equal than others. In particular we have the thorny issue of
stolen memory, memory stolen from the system by the BIOS and reserved
for igfx use. Stolen memory is required for some functions of the GPU
and display engine, but in general it goes wasted. Whilst we cannot
return it back to the system, we need to find some other method for
utilising it. As we do not support direct access to the physical address
in the stolen region, it behaves like a different class of memory,
closer in kin to local GPU memory. This strongly suggests that we need a
placement model like TTM if we are to fully utilize these discrete
chunks of differing memory.

To add support for creating Stolen memory backed objects, we extend the
drm_i915_gem_create structure, by adding a new flag through which user
can specify the preference to allocate the object from stolen memory,
which if set, an attempt will be made to allocate the object from stolen
memory subject to the availability of free space in the stolen region.

This patch series adds support for clearing buffer objects via CPU/GTT.
This is particularly useful for clearing out the memory from stolen
region, but can also be used for other shmem allocated objects. Currently
being used for buffers allocated in the stolen region. Also adding support
for stealing purgable stolen pages, if we run out of stolen memory when
trying to allocate an object.

v2: Added support for read/write from/to objects not backed by
shmem using the pread/pwrite interface.
Also extended the current get_aperture ioctl to retrieve the
total and available size of the stolen region.

v3: Removed the extended get_aperture ioctl patch 5 (to be submitted as
part of other patch series), addressed comments by Chris about pread/pwrite
for non shmem backed objects.

v4: Rebased to the latest drm-intel-nightly.

v5: Addressed comments, replaced patch 1/4 "Clearing buffers via blitter
engine" by "Clearing buffers via CPU/GTT".

v6: Rebased to the latest drm-intel-nightly, Addressed comments, updated
stolen memory purging logic by maintaining a list for purgable stolen
memory objects, enabled pread/pwrite for all non-shmem backed objects
without tiling restrictions.

v7: Addressed comments, compiler optimization, new patch added for correct
error code propagation to the userspace.

v8: Added a new patch to the series to Migrate stolen objects before
hibernation, as stolen memory is not preserved across hibernation. Added
correct error propagation for shmem as well non-shmem backed object allocation.

v9: Addressed comments, use of insert_page helper function to map object page
by page which can be helpful in low aperture space availability.

v10: Addressed comments, use insert_page for clearing out the stolen memory

v11: Addressed comments, 3 new patches added to support allocation from Stolen
memory
1. Allow use of i915_gem_object_get_dma_address for stolen backed objects
2. Use insert_page for pwrite_fast
3. Fail the execbuff using stolen objects as batchbuffers

v12: Addressed comments, Removed patch "Fail the execbuff using stolen objects
as batchbuffers"

v13: Addressed comments, Added 2 patches to detect Intel RST and disable stolen
for persistent data if RST device found
1. acpi: Export acpi_bus_type
2. drm/i915: Disable use of stolen area by User when Intel RST is present

v14: Addressed comments, Added 2 base patches to the series
1. drm/i915: Add support for mapping an object page by page
2. drm/i915: Introduce i915_gem_object_get_dma_address()

This can be verified using IGT tests: igt/gem_stolen, igt/gem_create

Ankitprasad Sharma (7):
  drm/i915: Use insert_page for pwrite_fast
  drm/i915: Clearing buffer objects via CPU/GTT
  drm/i915: Support for creating Stolen memory backed objects
  drm/i915: Propagating correct error codes to the userspace
  drm/i915: Support for pread/pwrite from/to non shmem backed objects
  acpi: Export acpi_bus_type
  drm/i915: Disable use of stolen area by User when Intel RST is present

Chris Wilson (4):
  drm/i915: Add support for mapping an object page by page
  drm/i915: Introduce i915_gem_object_get_dma_address()
  drm/i915: Add support for stealing purgable stolen pages
  drm/i915: Migrate stolen objects before hibernation

 drivers/acpi/bus.c                           |   1 +
 drivers/char/agp/intel-gtt.c                 |   9 +
 drivers/gpu/drm/i915/i915_debugfs.c          |   6 +-
 drivers/gpu/drm/i915/i915_dma.c              |   3 +
 drivers/gpu/drm/i915/i915_drv.c              |  17 +-
 drivers/gpu/drm/i915/i915_drv.h              |  58 ++-
 drivers/gpu/drm/i915/i915_gem.c              | 576 +++++++++++++++++++++++----
 drivers/gpu/drm/i915/i915_gem_batch_pool.c   |   4 +-
 drivers/gpu/drm/i915/i915_gem_context.c      |   4 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c          |  49 +++
 drivers/gpu/drm/i915/i915_gem_gtt.h          |   5 +
 drivers/gpu/drm/i915/i915_gem_render_state.c |   7 +-
 drivers/gpu/drm/i915/i915_gem_stolen.c       | 281 +++++++++++--
 drivers/gpu/drm/i915/i915_guc_submission.c   |  52 ++-
 drivers/gpu/drm/i915/intel_acpi.c            |  20 +
 drivers/gpu/drm/i915/intel_display.c         |   5 +-
 drivers/gpu/drm/i915/intel_fbdev.c           |  12 +-
 drivers/gpu/drm/i915/intel_lrc.c             |  10 +-
 drivers/gpu/drm/i915/intel_overlay.c         |   4 +-
 drivers/gpu/drm/i915/intel_pm.c              |  13 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c      |  27 +-
 include/drm/intel-gtt.h                      |   3 +
 include/uapi/drm/i915_drm.h                  |  19 +
 23 files changed, 1022 insertions(+), 163 deletions(-)

-- 
1.9.1

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

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

* [PATCH 01/11] drm/i915: Add support for mapping an object page by page
  2016-01-14  6:16 [PATCH v14 0/11] Support for creating/using Stolen memory backed objects ankitprasad.r.sharma
@ 2016-01-14  6:16 ` ankitprasad.r.sharma
  2016-01-14 10:32   ` Tvrtko Ursulin
  2016-01-14  6:16 ` [PATCH 02/11] drm/i915: Introduce i915_gem_object_get_dma_address() ankitprasad.r.sharma
                   ` (10 subsequent siblings)
  11 siblings, 1 reply; 118+ messages in thread
From: ankitprasad.r.sharma @ 2016-01-14  6:16 UTC (permalink / raw)
  To: intel-gfx; +Cc: akash.goel, Ankitprasad Sharma, shashidhar.hiremath

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

Introduced a new vm specfic callback insert_page() to program a single pte in
ggtt or ppgtt. This allows us to map a single page in to the mappable aperture
space. This can be iterated over to access the whole object by using space as
meagre as page size.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
---
 drivers/char/agp/intel-gtt.c        |  9 +++++++
 drivers/gpu/drm/i915/i915_gem_gtt.c | 49 +++++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/i915_gem_gtt.h |  5 ++++
 include/drm/intel-gtt.h             |  3 +++
 4 files changed, 66 insertions(+)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 1341a94..7c68576 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -838,6 +838,15 @@ static bool i830_check_flags(unsigned int flags)
 	return false;
 }
 
+void intel_gtt_insert_page(dma_addr_t addr,
+			   unsigned int pg,
+			   unsigned int flags)
+{
+	intel_private.driver->write_entry(addr, pg, flags);
+	wmb();
+}
+EXPORT_SYMBOL(intel_gtt_insert_page);
+
 void intel_gtt_insert_sg_entries(struct sg_table *st,
 				 unsigned int pg_start,
 				 unsigned int flags)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 56f4f2e..48bd6a4 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2339,6 +2339,23 @@ static void gen8_set_pte(void __iomem *addr, gen8_pte_t pte)
 #endif
 }
 
+static void gen8_ggtt_insert_page(struct i915_address_space *vm,
+				  dma_addr_t addr,
+				  uint64_t offset,
+				  enum i915_cache_level level,
+				  u32 unused)
+{
+	struct drm_i915_private *dev_priv = to_i915(vm->dev);
+	gen8_pte_t __iomem *pte =
+		(gen8_pte_t __iomem *)dev_priv->gtt.gsm +
+		(offset >> PAGE_SHIFT);
+
+	gen8_set_pte(pte, gen8_pte_encode(addr, level, true));
+	wmb();
+
+	I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
+}
+
 static void gen8_ggtt_insert_entries(struct i915_address_space *vm,
 				     struct sg_table *st,
 				     uint64_t start,
@@ -2410,6 +2427,23 @@ static void gen8_ggtt_insert_entries__BKL(struct i915_address_space *vm,
 	stop_machine(gen8_ggtt_insert_entries__cb, &arg, NULL);
 }
 
+static void gen6_ggtt_insert_page(struct i915_address_space *vm,
+				  dma_addr_t addr,
+				  uint64_t offset,
+				  enum i915_cache_level level,
+				  u32 flags)
+{
+	struct drm_i915_private *dev_priv = to_i915(vm->dev);
+	gen6_pte_t __iomem *pte =
+		(gen6_pte_t __iomem *)dev_priv->gtt.gsm +
+		(offset >> PAGE_SHIFT);
+
+	iowrite32(vm->pte_encode(addr, level, true, flags), pte);
+	wmb();
+
+	I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
+}
+
 /*
  * Binds an object into the global gtt with the specified cache level. The object
  * will be accessible to the GPU via commands whose operands reference offsets
@@ -2521,6 +2555,18 @@ static void gen6_ggtt_clear_range(struct i915_address_space *vm,
 	assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
 }
 
+static void i915_ggtt_insert_page(struct i915_address_space *vm,
+				  dma_addr_t addr,
+				  uint64_t offset,
+				  enum i915_cache_level cache_level,
+				  u32 unused)
+{
+	unsigned int flags = (cache_level == I915_CACHE_NONE) ?
+		AGP_USER_MEMORY : AGP_USER_CACHED_MEMORY;
+
+	intel_gtt_insert_page(addr, offset >> PAGE_SHIFT, flags);
+}
+
 static void i915_ggtt_insert_entries(struct i915_address_space *vm,
 				     struct sg_table *pages,
 				     uint64_t start,
@@ -3050,6 +3096,7 @@ static int gen8_gmch_probe(struct drm_device *dev,
 	ret = ggtt_probe_common(dev, gtt_size);
 
 	dev_priv->gtt.base.clear_range = gen8_ggtt_clear_range;
+	dev_priv->gtt.base.insert_page = gen8_ggtt_insert_page;
 	dev_priv->gtt.base.insert_entries = gen8_ggtt_insert_entries;
 	dev_priv->gtt.base.bind_vma = ggtt_bind_vma;
 	dev_priv->gtt.base.unbind_vma = ggtt_unbind_vma;
@@ -3095,6 +3142,7 @@ static int gen6_gmch_probe(struct drm_device *dev,
 	ret = ggtt_probe_common(dev, gtt_size);
 
 	dev_priv->gtt.base.clear_range = gen6_ggtt_clear_range;
+	dev_priv->gtt.base.insert_page = gen6_ggtt_insert_page;
 	dev_priv->gtt.base.insert_entries = gen6_ggtt_insert_entries;
 	dev_priv->gtt.base.bind_vma = ggtt_bind_vma;
 	dev_priv->gtt.base.unbind_vma = ggtt_unbind_vma;
@@ -3129,6 +3177,7 @@ static int i915_gmch_probe(struct drm_device *dev,
 	intel_gtt_get(gtt_total, stolen, mappable_base, mappable_end);
 
 	dev_priv->gtt.do_idle_maps = needs_idle_maps(dev_priv->dev);
+	dev_priv->gtt.base.insert_page = i915_ggtt_insert_page;
 	dev_priv->gtt.base.insert_entries = i915_ggtt_insert_entries;
 	dev_priv->gtt.base.clear_range = i915_ggtt_clear_range;
 	dev_priv->gtt.base.bind_vma = ggtt_bind_vma;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h
index b448ad8..5f86596 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -317,6 +317,11 @@ struct i915_address_space {
 			    uint64_t start,
 			    uint64_t length,
 			    bool use_scratch);
+	void (*insert_page)(struct i915_address_space *vm,
+			    dma_addr_t addr,
+			    uint64_t offset,
+			    enum i915_cache_level cache_level,
+			    u32 flags);
 	void (*insert_entries)(struct i915_address_space *vm,
 			       struct sg_table *st,
 			       uint64_t start,
diff --git a/include/drm/intel-gtt.h b/include/drm/intel-gtt.h
index 9e9bddaa5..f49edec 100644
--- a/include/drm/intel-gtt.h
+++ b/include/drm/intel-gtt.h
@@ -13,6 +13,9 @@ void intel_gmch_remove(void);
 bool intel_enable_gtt(void);
 
 void intel_gtt_chipset_flush(void);
+void intel_gtt_insert_page(dma_addr_t addr,
+			   unsigned int pg,
+			   unsigned int flags);
 void intel_gtt_insert_sg_entries(struct sg_table *st,
 				 unsigned int pg_start,
 				 unsigned int flags);
-- 
1.9.1

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

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

* [PATCH 02/11] drm/i915: Introduce i915_gem_object_get_dma_address()
  2016-01-14  6:16 [PATCH v14 0/11] Support for creating/using Stolen memory backed objects ankitprasad.r.sharma
  2016-01-14  6:16 ` [PATCH 01/11] drm/i915: Add support for mapping an object page by page ankitprasad.r.sharma
@ 2016-01-14  6:16 ` ankitprasad.r.sharma
  2016-01-14  6:16 ` [PATCH 03/11] drm/i915: Use insert_page for pwrite_fast ankitprasad.r.sharma
                   ` (9 subsequent siblings)
  11 siblings, 0 replies; 118+ messages in thread
From: ankitprasad.r.sharma @ 2016-01-14  6:16 UTC (permalink / raw)
  To: intel-gfx; +Cc: akash.goel, Ankitprasad Sharma, shashidhar.hiremath

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

This utility function is a companion to i915_gem_object_get_page() that
uses the same cached iterator for the scatterlist to perform fast
sequential lookup of the dma address associated with any page within the
object.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
---
 drivers/gpu/drm/i915/i915_drv.h | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 747d2d8..7dc122f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2902,6 +2902,23 @@ static inline int __sg_page_count(struct scatterlist *sg)
 struct page *
 i915_gem_object_get_dirty_page(struct drm_i915_gem_object *obj, int n);
 
+static inline dma_addr_t
+i915_gem_object_get_dma_address(struct drm_i915_gem_object *obj, int n)
+{
+	if (n < obj->get_page.last) {
+		obj->get_page.sg = obj->pages->sgl;
+		obj->get_page.last = 0;
+	}
+
+	while (obj->get_page.last + __sg_page_count(obj->get_page.sg) <= n) {
+		obj->get_page.last += __sg_page_count(obj->get_page.sg++);
+		if (unlikely(sg_is_chain(obj->get_page.sg)))
+			obj->get_page.sg = sg_chain_ptr(obj->get_page.sg);
+	}
+
+	return sg_dma_address(obj->get_page.sg) + ((n - obj->get_page.last) << PAGE_SHIFT);
+}
+
 static inline struct page *
 i915_gem_object_get_page(struct drm_i915_gem_object *obj, int n)
 {
-- 
1.9.1

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

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

* [PATCH 03/11] drm/i915: Use insert_page for pwrite_fast
  2016-01-14  6:16 [PATCH v14 0/11] Support for creating/using Stolen memory backed objects ankitprasad.r.sharma
  2016-01-14  6:16 ` [PATCH 01/11] drm/i915: Add support for mapping an object page by page ankitprasad.r.sharma
  2016-01-14  6:16 ` [PATCH 02/11] drm/i915: Introduce i915_gem_object_get_dma_address() ankitprasad.r.sharma
@ 2016-01-14  6:16 ` ankitprasad.r.sharma
  2016-01-14  9:46   ` Chris Wilson
  2016-01-14  6:16 ` [PATCH 04/11] drm/i915: Clearing buffer objects via CPU/GTT ankitprasad.r.sharma
                   ` (8 subsequent siblings)
  11 siblings, 1 reply; 118+ messages in thread
From: ankitprasad.r.sharma @ 2016-01-14  6:16 UTC (permalink / raw)
  To: intel-gfx; +Cc: akash.goel, shashidhar.hiremath, Ankitprasad Sharma

From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>

In pwrite_fast, map an object page by page if obj_ggtt_pin fails. First,
we try a nonblocking pin for the whole object (since that is fastest if
reused), then failing that we try to grab one page in the mappable
aperture. It also allows us to handle objects larger than the mappable
aperture (e.g. if we need to pwrite with vGPU restricting the aperture
to a measely 8MiB or something like that).

v2: Pin pages before starting pwrite, Combined duplicate loops (Chris)

v3: Combined loops based on local patch by Chris (Chris)

v4: Added i915 wrapper function for drm_mm_insert_node_in_range (Chris)

v5: Renamed wrapper function for drm_mm_insert_node_in_range (Chris)

v5: Added wrapper for drm_mm_remove_node() (Chris)

v6: Added get_pages call before pinning the pages (Tvrtko)
Added remove_mappable_node() wrapper for drm_mm_remove_node() (Chris)

v7: Added size argument for insert_mappable_node (Tvrtko)

Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
 drivers/gpu/drm/i915/i915_gem.c | 94 +++++++++++++++++++++++++++++++----------
 1 file changed, 72 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6c60e04..4ef74cf 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -61,6 +61,23 @@ static bool cpu_write_needs_clflush(struct drm_i915_gem_object *obj)
 	return obj->pin_display;
 }
 
+static int
+insert_mappable_node(struct drm_i915_private *i915,
+                     struct drm_mm_node *node, u32 size)
+{
+	return drm_mm_insert_node_in_range_generic(&i915->gtt.base.mm, node,
+						   size, 0, 0, 0,
+						   i915->gtt.mappable_end,
+						   DRM_MM_SEARCH_DEFAULT,
+						   DRM_MM_CREATE_DEFAULT);
+}
+
+static void
+remove_mappable_node(struct drm_mm_node *node)
+{
+	drm_mm_remove_node(node);
+}
+
 /* some bookkeeping */
 static void i915_gem_info_add_obj(struct drm_i915_private *dev_priv,
 				  size_t size)
@@ -760,20 +777,34 @@ fast_user_write(struct io_mapping *mapping,
  * user into the GTT, uncached.
  */
 static int
-i915_gem_gtt_pwrite_fast(struct drm_device *dev,
+i915_gem_gtt_pwrite_fast(struct drm_i915_private *i915,
 			 struct drm_i915_gem_object *obj,
 			 struct drm_i915_gem_pwrite *args,
 			 struct drm_file *file)
 {
-	struct drm_i915_private *dev_priv = dev->dev_private;
-	ssize_t remain;
-	loff_t offset, page_base;
+	struct drm_mm_node node;
+	uint64_t remain, offset;
 	char __user *user_data;
-	int page_offset, page_length, ret;
+	int ret;
 
 	ret = i915_gem_obj_ggtt_pin(obj, 0, PIN_MAPPABLE | PIN_NONBLOCK);
-	if (ret)
-		goto out;
+	if (ret) {
+		memset(&node, 0, sizeof(node));
+		ret = insert_mappable_node(i915, &node, PAGE_SIZE);
+		if (ret)
+			goto out;
+
+		ret = i915_gem_object_get_pages(obj);
+		if (ret) {
+			remove_mappable_node(&node);
+			goto out;
+		}
+
+		i915_gem_object_pin_pages(obj);
+	} else {
+		node.start = i915_gem_obj_ggtt_offset(obj);
+		node.allocated = false;
+	}
 
 	ret = i915_gem_object_set_to_gtt_domain(obj, true);
 	if (ret)
@@ -783,31 +814,39 @@ i915_gem_gtt_pwrite_fast(struct drm_device *dev,
 	if (ret)
 		goto out_unpin;
 
-	user_data = to_user_ptr(args->data_ptr);
-	remain = args->size;
-
-	offset = i915_gem_obj_ggtt_offset(obj) + args->offset;
-
 	intel_fb_obj_invalidate(obj, ORIGIN_GTT);
+	obj->dirty = true;
 
-	while (remain > 0) {
+	user_data = to_user_ptr(args->data_ptr);
+	offset = args->offset;
+	remain = args->size;
+	while (remain) {
 		/* Operation in this page
 		 *
 		 * page_base = page offset within aperture
 		 * page_offset = offset within page
 		 * page_length = bytes to copy for this page
 		 */
-		page_base = offset & PAGE_MASK;
-		page_offset = offset_in_page(offset);
-		page_length = remain;
-		if ((page_offset + remain) > PAGE_SIZE)
-			page_length = PAGE_SIZE - page_offset;
-
+		u32 page_base = node.start;
+		unsigned page_offset = offset_in_page(offset);
+		unsigned page_length = PAGE_SIZE - page_offset;
+		page_length = remain < page_length ? remain : page_length;
+		if (node.allocated) {
+			wmb();
+			i915->gtt.base.insert_page(&i915->gtt.base,
+						   i915_gem_object_get_dma_address(obj, offset >> PAGE_SHIFT),
+						   node.start,
+						   I915_CACHE_NONE,
+						   0);
+			wmb();
+		} else {
+			page_base += offset & PAGE_MASK;
+		}
 		/* If we get a fault while copying data, then (presumably) our
 		 * source page isn't available.  Return the error and we'll
 		 * retry in the slow path.
 		 */
-		if (fast_user_write(dev_priv->gtt.mappable, page_base,
+		if (fast_user_write(i915->gtt.mappable, page_base,
 				    page_offset, user_data, page_length)) {
 			ret = -EFAULT;
 			goto out_flush;
@@ -821,7 +860,18 @@ i915_gem_gtt_pwrite_fast(struct drm_device *dev,
 out_flush:
 	intel_fb_obj_flush(obj, false, ORIGIN_GTT);
 out_unpin:
-	i915_gem_object_ggtt_unpin(obj);
+	if (node.allocated) {
+		wmb();
+		i915->gtt.base.clear_range(&i915->gtt.base,
+					   node.start, node.size,
+					   true);
+		remove_mappable_node(&node);
+		i915_gem_object_unpin_pages(obj);
+		i915_gem_object_put_pages(obj);
+	}
+	else {
+		i915_gem_object_ggtt_unpin(obj);
+	}
 out:
 	return ret;
 }
@@ -1086,7 +1136,7 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
 	if (obj->tiling_mode == I915_TILING_NONE &&
 	    obj->base.write_domain != I915_GEM_DOMAIN_CPU &&
 	    cpu_write_needs_clflush(obj)) {
-		ret = i915_gem_gtt_pwrite_fast(dev, obj, args, file);
+		ret = i915_gem_gtt_pwrite_fast(dev_priv, obj, args, file);
 		/* Note that the gtt paths might fail with non-page-backed user
 		 * pointers (e.g. gtt mappings when moving data between
 		 * textures). Fallback to the shmem path in that case. */
-- 
1.9.1

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

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

* [PATCH 04/11] drm/i915: Clearing buffer objects via CPU/GTT
  2016-01-14  6:16 [PATCH v14 0/11] Support for creating/using Stolen memory backed objects ankitprasad.r.sharma
                   ` (2 preceding siblings ...)
  2016-01-14  6:16 ` [PATCH 03/11] drm/i915: Use insert_page for pwrite_fast ankitprasad.r.sharma
@ 2016-01-14  6:16 ` ankitprasad.r.sharma
  2016-01-14 10:06   ` Chris Wilson
  2016-01-14  6:16 ` [PATCH 05/11] drm/i915: Support for creating Stolen memory backed objects ankitprasad.r.sharma
                   ` (7 subsequent siblings)
  11 siblings, 1 reply; 118+ messages in thread
From: ankitprasad.r.sharma @ 2016-01-14  6:16 UTC (permalink / raw)
  To: intel-gfx; +Cc: akash.goel, shashidhar.hiremath, Ankitprasad Sharma

From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>

This patch adds support for clearing buffer objects via CPU/GTT. This
is particularly useful for clearing out the non shmem backed objects.
Currently intend to use this only for buffers allocated from stolen
region.

v2: Added kernel doc for i915_gem_clear_object(), corrected/removed
variable assignments (Tvrtko)

v3: Map object page by page to the gtt if the pinning of the whole object
to the ggtt fails, Corrected function name (Chris)

v4: Clear the buffer page by page, and not map the whole object in the gtt
aperture. Use i915 wrapper function in place of drm_mm_insert_node_in_range.

v5: Use renamed wrapper function for drm_mm_insert_node_in_range,
updated barrier positioning (Chris)

v6: Use PAGE_SIZE instead of 4096, use get_pages call before pinning pages
(Tvrtko)

Testcase: igt/gem_stolen

Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem.c | 49 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 50 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7dc122f..1153150 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2893,6 +2893,7 @@ int i915_gem_obj_prepare_shmem_read(struct drm_i915_gem_object *obj,
 				    int *needs_clflush);
 
 int __must_check i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
+int i915_gem_object_clear(struct drm_i915_gem_object *obj);
 
 static inline int __sg_page_count(struct scatterlist *sg)
 {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4ef74cf..a2138c0 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5359,3 +5359,52 @@ fail:
 	drm_gem_object_unreference(&obj->base);
 	return ERR_PTR(ret);
 }
+
+/**
+ * i915_gem_object_clear() - Clear buffer object via CPU/GTT
+ * @obj: Buffer object to be cleared
+ *
+ * Return: 0 - success, non-zero - failure
+ */
+int i915_gem_object_clear(struct drm_i915_gem_object *obj)
+{
+	int ret, i;
+	char __iomem *base;
+	size_t size = obj->base.size;
+	struct drm_i915_private *i915 = to_i915(obj->base.dev);
+	struct drm_mm_node node;
+
+	lockdep_assert_held(&obj->base.dev->struct_mutex);
+	memset(&node, 0, sizeof(node));
+	ret = insert_mappable_node(i915, &node, PAGE_SIZE);
+	if (ret)
+		goto out;
+
+	ret = i915_gem_object_get_pages(obj);
+	if (ret) {
+		remove_mappable_node(&node);
+		goto out;
+	}
+
+	i915_gem_object_pin_pages(obj);
+	base = io_mapping_map_wc(i915->gtt.mappable, node.start);
+	for (i = 0; i < size/PAGE_SIZE; i++) {
+		i915->gtt.base.insert_page(&i915->gtt.base,
+					   i915_gem_object_get_dma_address(obj, i),
+					   node.start,
+					   I915_CACHE_NONE, 0);
+		wmb();
+		memset_io(base, 0, PAGE_SIZE);
+		wmb();
+	}
+
+	io_mapping_unmap(base);
+	i915->gtt.base.clear_range(&i915->gtt.base,
+			node.start, node.size,
+			true);
+	remove_mappable_node(&node);
+	i915_gem_object_unpin_pages(obj);
+	i915_gem_object_put_pages(obj);
+out:
+	return ret;
+}
-- 
1.9.1

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

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

* [PATCH 05/11] drm/i915: Support for creating Stolen memory backed objects
  2016-01-14  6:16 [PATCH v14 0/11] Support for creating/using Stolen memory backed objects ankitprasad.r.sharma
                   ` (3 preceding siblings ...)
  2016-01-14  6:16 ` [PATCH 04/11] drm/i915: Clearing buffer objects via CPU/GTT ankitprasad.r.sharma
@ 2016-01-14  6:16 ` ankitprasad.r.sharma
  2016-01-14 10:24   ` Chris Wilson
  2016-01-14  6:16 ` [PATCH 06/11] drm/i915: Propagating correct error codes to the userspace ankitprasad.r.sharma
                   ` (6 subsequent siblings)
  11 siblings, 1 reply; 118+ messages in thread
From: ankitprasad.r.sharma @ 2016-01-14  6:16 UTC (permalink / raw)
  To: intel-gfx; +Cc: akash.goel, shashidhar.hiremath, Ankitprasad Sharma

From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>

Extend the drm_i915_gem_create structure to add support for
creating Stolen memory backed objects. Added a new flag through
which user can specify the preference to allocate the object from
stolen memory, which if set, an attempt will be made to allocate
the object from stolen memory subject to the availability of
free space in the stolen region.

v2: Rebased to the latest drm-intel-nightly (Ankit)

v3: Changed versioning of GEM_CREATE param, added new comments (Tvrtko)

v4: Changed size from 32b to 64b to prevent userspace overflow (Tvrtko)
Corrected function arguments ordering (Chris)

v5: Corrected function name (Chris)

v6: Updated datatype for flags to keep sizeof(drm_i915_gem_create) u64
aligned (Chris)

v7: Use first 8 bits of gem_create flags for placement (Chris), Add helper
function for object allocation from stolen region (Ankit)

Testcase: igt/gem_stolen

Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
---
 drivers/gpu/drm/i915/i915_dma.c        |  3 +++
 drivers/gpu/drm/i915/i915_drv.h        |  2 +-
 drivers/gpu/drm/i915/i915_gem.c        | 46 +++++++++++++++++++++++++++++++---
 drivers/gpu/drm/i915/i915_gem_stolen.c |  4 +--
 include/uapi/drm/i915_drm.h            | 19 ++++++++++++++
 5 files changed, 68 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 44a896c..73e1670 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -172,6 +172,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
 	case I915_PARAM_HAS_EXEC_SOFTPIN:
 		value = 1;
 		break;
+	case I915_PARAM_CREATE_VERSION:
+		value = 2;
+		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 1153150..4ae8b0b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3256,7 +3256,7 @@ void i915_gem_stolen_remove_node(struct drm_i915_private *dev_priv,
 int i915_gem_init_stolen(struct drm_device *dev);
 void i915_gem_cleanup_stolen(struct drm_device *dev);
 struct drm_i915_gem_object *
-i915_gem_object_create_stolen(struct drm_device *dev, u32 size);
+i915_gem_object_create_stolen(struct drm_device *dev, u64 size);
 struct drm_i915_gem_object *
 i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
 					       u32 stolen_offset,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a2138c0..6a429c0 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -388,22 +388,62 @@ void i915_gem_object_free(struct drm_i915_gem_object *obj)
 	kmem_cache_free(dev_priv->objects, obj);
 }
 
+static struct drm_i915_gem_object *
+i915_gem_alloc_object_stolen(struct drm_device *dev, size_t size)
+{
+	struct drm_i915_gem_object *obj;
+	int ret;
+
+	mutex_lock(&dev->struct_mutex);
+	obj = i915_gem_object_create_stolen(dev, size);
+	if (!obj) {
+		mutex_unlock(&dev->struct_mutex);
+		return NULL;
+	}
+
+	/* Always clear fresh buffers before handing to userspace */
+	ret = i915_gem_object_clear(obj);
+	if (ret) {
+		drm_gem_object_unreference(&obj->base);
+		mutex_unlock(&dev->struct_mutex);
+		return NULL;
+	}
+
+	mutex_unlock(&dev->struct_mutex);
+	return obj;
+}
+
 static int
 i915_gem_create(struct drm_file *file,
 		struct drm_device *dev,
 		uint64_t size,
+		uint64_t flags,
 		uint32_t *handle_p)
 {
 	struct drm_i915_gem_object *obj;
 	int ret;
 	u32 handle;
+	u32 placement = flags & I915_CREATE_PLACEMENT_MASK;
 
 	size = roundup(size, PAGE_SIZE);
 	if (size == 0)
 		return -EINVAL;
 
+	if (flags & __I915_CREATE_UNKNOWN_FLAGS)
+		return -EINVAL;
+
 	/* Allocate the new object */
-	obj = i915_gem_alloc_object(dev, size);
+	switch (placement) {
+	case I915_CREATE_PLACEMENT_NORMAL:
+		obj = i915_gem_alloc_object(dev, size);
+		break;
+	case I915_CREATE_PLACEMENT_STOLEN:
+		obj = i915_gem_alloc_object_stolen(dev, size);
+		break;
+	default:
+		return -EINVAL;
+	}
+
 	if (obj == NULL)
 		return -ENOMEM;
 
@@ -426,7 +466,7 @@ i915_gem_dumb_create(struct drm_file *file,
 	args->pitch = ALIGN(args->width * DIV_ROUND_UP(args->bpp, 8), 64);
 	args->size = args->pitch * args->height;
 	return i915_gem_create(file, dev,
-			       args->size, &args->handle);
+			       args->size, 0, &args->handle);
 }
 
 /**
@@ -439,7 +479,7 @@ i915_gem_create_ioctl(struct drm_device *dev, void *data,
 	struct drm_i915_gem_create *args = data;
 
 	return i915_gem_create(file, dev,
-			       args->size, &args->handle);
+			       args->size, args->flags, &args->handle);
 }
 
 static inline int
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
index c384dc9..8203157 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -586,7 +586,7 @@ cleanup:
 }
 
 struct drm_i915_gem_object *
-i915_gem_object_create_stolen(struct drm_device *dev, u32 size)
+i915_gem_object_create_stolen(struct drm_device *dev, u64 size)
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
 	struct drm_i915_gem_object *obj;
@@ -596,7 +596,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32 size)
 	if (!drm_mm_initialized(&dev_priv->mm.stolen))
 		return NULL;
 
-	DRM_DEBUG_KMS("creating stolen object: size=%x\n", size);
+	DRM_DEBUG_KMS("creating stolen object: size=%llx\n", size);
 	if (size == 0)
 		return NULL;
 
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index acf2102..ec01e20 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -357,6 +357,7 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_HAS_GPU_RESET	 35
 #define I915_PARAM_HAS_RESOURCE_STREAMER 36
 #define I915_PARAM_HAS_EXEC_SOFTPIN	 37
+#define I915_PARAM_CREATE_VERSION	 38
 
 typedef struct drm_i915_getparam {
 	__s32 param;
@@ -456,6 +457,24 @@ struct drm_i915_gem_create {
 	 */
 	__u32 handle;
 	__u32 pad;
+	/**
+	 * Requested flags (currently used for placement
+	 * (which memory domain))
+	 *
+	 * You can request that the object be created from special memory
+	 * rather than regular system pages using this parameter. Such
+	 * irregular objects may have certain restrictions (such as CPU
+	 * access to a stolen object is verboten).
+	 *
+	 * This can be used in the future for other purposes too
+	 * e.g. specifying tiling/caching/madvise
+	 */
+	__u64 flags;
+#define I915_CREATE_PLACEMENT_NORMAL 	0 /* standard swappable bo  */
+#define I915_CREATE_PLACEMENT_STOLEN 	1 /* Cannot use CPU mmaps */
+
+#define I915_CREATE_PLACEMENT_MASK	0xff
+#define __I915_CREATE_UNKNOWN_FLAGS	~I915_CREATE_PLACEMENT_MASK
 };
 
 struct drm_i915_gem_pread {
-- 
1.9.1

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

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

* [PATCH 06/11] drm/i915: Propagating correct error codes to the userspace
  2016-01-14  6:16 [PATCH v14 0/11] Support for creating/using Stolen memory backed objects ankitprasad.r.sharma
                   ` (4 preceding siblings ...)
  2016-01-14  6:16 ` [PATCH 05/11] drm/i915: Support for creating Stolen memory backed objects ankitprasad.r.sharma
@ 2016-01-14  6:16 ` ankitprasad.r.sharma
  2016-01-14 10:25   ` Chris Wilson
  2016-01-14  6:16 ` [PATCH 07/11] drm/i915: Add support for stealing purgable stolen pages ankitprasad.r.sharma
                   ` (5 subsequent siblings)
  11 siblings, 1 reply; 118+ messages in thread
From: ankitprasad.r.sharma @ 2016-01-14  6:16 UTC (permalink / raw)
  To: intel-gfx; +Cc: akash.goel, shashidhar.hiremath, Ankitprasad Sharma

From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>

Propagating correct error codes to userspace by using ERR_PTR and
PTR_ERR macros for stolen memory based object allocation. We generally
return -ENOMEM to the user whenever there is a failure in object
allocation. This patch helps user to identify the correct reason for the
failure and not just -ENOMEM each time.

v2: Moved the patch up in the series, added error propagation for
i915_gem_alloc_object too (Chris)

v3: Removed storing of error pointer inside structs, Corrected error
propagation in caller functions (Chris)

v4: Remove assignments inside the predicate (Chris)

v5: Removed unnecessary initializations, updated kerneldoc for
i915_guc_client, corrected missed error pointer handling (Tvrtko)

v6: Use ERR_CAST/temporary variable to avoid storing invalid pointer
in a common field (Chris)

v7: Resolved rebasing conflicts (Ankit)

Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
---
 drivers/gpu/drm/i915/i915_gem.c              | 21 +++++------
 drivers/gpu/drm/i915/i915_gem_batch_pool.c   |  4 +--
 drivers/gpu/drm/i915/i915_gem_context.c      |  4 +--
 drivers/gpu/drm/i915/i915_gem_render_state.c |  7 ++--
 drivers/gpu/drm/i915/i915_gem_stolen.c       | 53 +++++++++++++++-------------
 drivers/gpu/drm/i915/i915_guc_submission.c   | 52 +++++++++++++++++----------
 drivers/gpu/drm/i915/intel_display.c         |  2 +-
 drivers/gpu/drm/i915/intel_fbdev.c           |  6 ++--
 drivers/gpu/drm/i915/intel_lrc.c             | 10 +++---
 drivers/gpu/drm/i915/intel_overlay.c         |  4 +--
 drivers/gpu/drm/i915/intel_pm.c              |  7 ++--
 drivers/gpu/drm/i915/intel_ringbuffer.c      | 21 +++++------
 12 files changed, 109 insertions(+), 82 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6a429c0..b7dcd21 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -396,19 +396,18 @@ i915_gem_alloc_object_stolen(struct drm_device *dev, size_t size)
 
 	mutex_lock(&dev->struct_mutex);
 	obj = i915_gem_object_create_stolen(dev, size);
-	if (!obj) {
-		mutex_unlock(&dev->struct_mutex);
-		return NULL;
-	}
+	if (IS_ERR(obj))
+		goto out;
 
 	/* Always clear fresh buffers before handing to userspace */
 	ret = i915_gem_object_clear(obj);
 	if (ret) {
 		drm_gem_object_unreference(&obj->base);
 		mutex_unlock(&dev->struct_mutex);
-		return NULL;
+		return ERR_PTR(ret);
 	}
 
+out:
 	mutex_unlock(&dev->struct_mutex);
 	return obj;
 }
@@ -444,8 +443,8 @@ i915_gem_create(struct drm_file *file,
 		return -EINVAL;
 	}
 
-	if (obj == NULL)
-		return -ENOMEM;
+	if (IS_ERR(obj))
+		return PTR_ERR(obj);
 
 	ret = drm_gem_handle_create(file, &obj->base, &handle);
 	/* drop reference from allocate - handle holds it now */
@@ -4525,14 +4524,16 @@ struct drm_i915_gem_object *i915_gem_alloc_object(struct drm_device *dev,
 	struct drm_i915_gem_object *obj;
 	struct address_space *mapping;
 	gfp_t mask;
+	int ret;
 
 	obj = i915_gem_object_alloc(dev);
 	if (obj == NULL)
-		return NULL;
+		return ERR_PTR(-ENOMEM);
 
-	if (drm_gem_object_init(dev, &obj->base, size) != 0) {
+	ret = drm_gem_object_init(dev, &obj->base, size);
+	if (ret) {
 		i915_gem_object_free(obj);
-		return NULL;
+		return ERR_PTR(ret);
 	}
 
 	mask = GFP_HIGHUSER | __GFP_RECLAIMABLE;
diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.c b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
index 7bf2f3f..d79caa2 100644
--- a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
+++ b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
@@ -135,8 +135,8 @@ i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool,
 		int ret;
 
 		obj = i915_gem_alloc_object(pool->dev, size);
-		if (obj == NULL)
-			return ERR_PTR(-ENOMEM);
+		if (IS_ERR(obj))
+			return obj;
 
 		ret = i915_gem_object_get_pages(obj);
 		if (ret)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c
index c25083c..734a615 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -179,8 +179,8 @@ i915_gem_alloc_context_obj(struct drm_device *dev, size_t size)
 	int ret;
 
 	obj = i915_gem_alloc_object(dev, size);
-	if (obj == NULL)
-		return ERR_PTR(-ENOMEM);
+	if (IS_ERR(obj))
+		return obj;
 
 	/*
 	 * Try to make the context utilize L3 as well as LLC.
diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c b/drivers/gpu/drm/i915/i915_gem_render_state.c
index fc7e6d5..a2c3f44 100644
--- a/drivers/gpu/drm/i915/i915_gem_render_state.c
+++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
@@ -58,8 +58,11 @@ static int render_state_init(struct render_state *so, struct drm_device *dev)
 		return -EINVAL;
 
 	so->obj = i915_gem_alloc_object(dev, 4096);
-	if (so->obj == NULL)
-		return -ENOMEM;
+	if (IS_ERR(so->obj)) {
+		ret = PTR_ERR(so->obj);
+		so->obj = NULL;
+		return ret;
+	}
 
 	ret = i915_gem_obj_ggtt_pin(so->obj, 4096, 0);
 	if (ret)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 8203157..4daf28f 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -492,6 +492,7 @@ i915_pages_create_for_stolen(struct drm_device *dev,
 	struct drm_i915_private *dev_priv = dev->dev_private;
 	struct sg_table *st;
 	struct scatterlist *sg;
+	int ret;
 
 	DRM_DEBUG_DRIVER("offset=0x%x, size=%d\n", offset, size);
 	BUG_ON(offset > dev_priv->gtt.stolen_size - size);
@@ -503,11 +504,12 @@ i915_pages_create_for_stolen(struct drm_device *dev,
 
 	st = kmalloc(sizeof(*st), GFP_KERNEL);
 	if (st == NULL)
-		return NULL;
+		return ERR_PTR(-ENOMEM);
 
-	if (sg_alloc_table(st, 1, GFP_KERNEL)) {
+	ret = sg_alloc_table(st, 1, GFP_KERNEL);
+	if (ret) {
 		kfree(st);
-		return NULL;
+		return ERR_PTR(ret);
 	}
 
 	sg = st->sgl;
@@ -556,18 +558,23 @@ _i915_gem_object_create_stolen(struct drm_device *dev,
 			       struct drm_mm_node *stolen)
 {
 	struct drm_i915_gem_object *obj;
+	struct sg_table *pages;
 
 	obj = i915_gem_object_alloc(dev);
 	if (obj == NULL)
-		return NULL;
+		return ERR_PTR(-ENOMEM);
 
 	drm_gem_private_object_init(dev, &obj->base, stolen->size);
 	i915_gem_object_init(obj, &i915_gem_object_stolen_ops);
 
-	obj->pages = i915_pages_create_for_stolen(dev,
-						  stolen->start, stolen->size);
-	if (obj->pages == NULL)
-		goto cleanup;
+	pages = i915_pages_create_for_stolen(dev,
+					     stolen->start, stolen->size);
+	if (IS_ERR(pages)) {
+		i915_gem_object_free(obj);
+		return ERR_CAST(pages);
+	}
+
+	obj->pages = pages;
 
 	obj->get_page.sg = obj->pages->sgl;
 	obj->get_page.last = 0;
@@ -579,10 +586,6 @@ _i915_gem_object_create_stolen(struct drm_device *dev,
 	obj->cache_level = HAS_LLC(dev) ? I915_CACHE_LLC : I915_CACHE_NONE;
 
 	return obj;
-
-cleanup:
-	i915_gem_object_free(obj);
-	return NULL;
 }
 
 struct drm_i915_gem_object *
@@ -594,29 +597,29 @@ i915_gem_object_create_stolen(struct drm_device *dev, u64 size)
 	int ret;
 
 	if (!drm_mm_initialized(&dev_priv->mm.stolen))
-		return NULL;
+		return ERR_PTR(-ENODEV);
 
 	DRM_DEBUG_KMS("creating stolen object: size=%llx\n", size);
 	if (size == 0)
-		return NULL;
+		return ERR_PTR(-EINVAL);
 
 	stolen = kzalloc(sizeof(*stolen), GFP_KERNEL);
 	if (!stolen)
-		return NULL;
+		return ERR_PTR(-ENOMEM);
 
 	ret = i915_gem_stolen_insert_node(dev_priv, stolen, size, 4096);
 	if (ret) {
 		kfree(stolen);
-		return NULL;
+		return ERR_PTR(ret);
 	}
 
 	obj = _i915_gem_object_create_stolen(dev, stolen);
-	if (obj)
+	if (!IS_ERR(obj))
 		return obj;
 
 	i915_gem_stolen_remove_node(dev_priv, stolen);
 	kfree(stolen);
-	return NULL;
+	return obj;
 }
 
 struct drm_i915_gem_object *
@@ -633,7 +636,7 @@ i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
 	int ret;
 
 	if (!drm_mm_initialized(&dev_priv->mm.stolen))
-		return NULL;
+		return ERR_PTR(-ENODEV);
 
 	DRM_DEBUG_KMS("creating preallocated stolen object: stolen_offset=%x, gtt_offset=%x, size=%x\n",
 			stolen_offset, gtt_offset, size);
@@ -641,11 +644,11 @@ i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
 	/* KISS and expect everything to be page-aligned */
 	if (WARN_ON(size == 0) || WARN_ON(size & 4095) ||
 	    WARN_ON(stolen_offset & 4095))
-		return NULL;
+		return ERR_PTR(-EINVAL);
 
 	stolen = kzalloc(sizeof(*stolen), GFP_KERNEL);
 	if (!stolen)
-		return NULL;
+		return ERR_PTR(-ENOMEM);
 
 	stolen->start = stolen_offset;
 	stolen->size = size;
@@ -655,15 +658,15 @@ i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
 	if (ret) {
 		DRM_DEBUG_KMS("failed to allocate stolen space\n");
 		kfree(stolen);
-		return NULL;
+		return ERR_PTR(ret);
 	}
 
 	obj = _i915_gem_object_create_stolen(dev, stolen);
-	if (obj == NULL) {
+	if (IS_ERR(obj)) {
 		DRM_DEBUG_KMS("failed to allocate stolen object\n");
 		i915_gem_stolen_remove_node(dev_priv, stolen);
 		kfree(stolen);
-		return NULL;
+		return obj;
 	}
 
 	/* Some objects just need physical mem from stolen space */
@@ -702,5 +705,5 @@ i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
 
 err:
 	drm_gem_object_unreference(&obj->base);
-	return NULL;
+	return ERR_PTR(ret);
 }
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c
index 9c24424..f6e6988 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -636,27 +636,30 @@ int i915_guc_submit(struct i915_guc_client *client,
  * object needs to be pinned lifetime. Also we must pin it to gtt space other
  * than [0, GUC_WOPCM_TOP) because this range is reserved inside GuC.
  *
- * Return:	A drm_i915_gem_object if successful, otherwise NULL.
+ * Return:	A drm_i915_gem_object if successful, otherwise error pointer.
  */
 static struct drm_i915_gem_object *gem_allocate_guc_obj(struct drm_device *dev,
 							u32 size)
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
 	struct drm_i915_gem_object *obj;
+	int ret;
 
 	obj = i915_gem_alloc_object(dev, size);
-	if (!obj)
-		return NULL;
+	if (IS_ERR(obj))
+		return obj;
 
-	if (i915_gem_object_get_pages(obj)) {
+	ret = i915_gem_object_get_pages(obj);
+	if (ret) {
 		drm_gem_object_unreference(&obj->base);
-		return NULL;
+		return ERR_PTR(ret);
 	}
 
-	if (i915_gem_obj_ggtt_pin(obj, PAGE_SIZE,
-			PIN_OFFSET_BIAS | GUC_WOPCM_TOP)) {
+	ret = i915_gem_obj_ggtt_pin(obj, PAGE_SIZE,
+				    PIN_OFFSET_BIAS | GUC_WOPCM_TOP);
+	if (ret) {
 		drm_gem_object_unreference(&obj->base);
-		return NULL;
+		return ERR_PTR(ret);
 	}
 
 	/* Invalidate GuC TLB to let GuC take the latest updates to GTT. */
@@ -724,7 +727,7 @@ static void guc_client_free(struct drm_device *dev,
  * @ctx:	the context that owns the client (we use the default render
  * 		context)
  *
- * Return:	An i915_guc_client object if success.
+ * Return:	An i915_guc_client object if success, error pointer on failure.
  */
 static struct i915_guc_client *guc_client_alloc(struct drm_device *dev,
 						uint32_t priority,
@@ -734,10 +737,11 @@ static struct i915_guc_client *guc_client_alloc(struct drm_device *dev,
 	struct drm_i915_private *dev_priv = dev->dev_private;
 	struct intel_guc *guc = &dev_priv->guc;
 	struct drm_i915_gem_object *obj;
+	int ret;
 
 	client = kzalloc(sizeof(*client), GFP_KERNEL);
 	if (!client)
-		return NULL;
+		return ERR_PTR(-ENOMEM);
 
 	client->doorbell_id = GUC_INVALID_DOORBELL_ID;
 	client->priority = priority;
@@ -748,13 +752,16 @@ static struct i915_guc_client *guc_client_alloc(struct drm_device *dev,
 			GUC_MAX_GPU_CONTEXTS, GFP_KERNEL);
 	if (client->ctx_index >= GUC_MAX_GPU_CONTEXTS) {
 		client->ctx_index = GUC_INVALID_CTX_ID;
+		ret = -EINVAL;
 		goto err;
 	}
 
 	/* The first page is doorbell/proc_desc. Two followed pages are wq. */
 	obj = gem_allocate_guc_obj(dev, GUC_DB_SIZE + GUC_WQ_SIZE);
-	if (!obj)
+	if (IS_ERR(obj)) {
+		ret = PTR_ERR(obj);
 		goto err;
+	}
 
 	client->client_obj = obj;
 	client->wq_offset = GUC_DB_SIZE;
@@ -773,9 +780,11 @@ static struct i915_guc_client *guc_client_alloc(struct drm_device *dev,
 		client->proc_desc_offset = (GUC_DB_SIZE / 2);
 
 	client->doorbell_id = assign_doorbell(guc, client->priority);
-	if (client->doorbell_id == GUC_INVALID_DOORBELL_ID)
+	if (client->doorbell_id == GUC_INVALID_DOORBELL_ID) {
 		/* XXX: evict a doorbell instead */
+		ret = -EINVAL;
 		goto err;
+	}
 
 	guc_init_proc_desc(guc, client);
 	guc_init_ctx_desc(guc, client);
@@ -783,7 +792,8 @@ static struct i915_guc_client *guc_client_alloc(struct drm_device *dev,
 
 	/* XXX: Any cache flushes needed? General domain mgmt calls? */
 
-	if (host2guc_allocate_doorbell(guc, client))
+	ret = host2guc_allocate_doorbell(guc, client);
+	if (ret)
 		goto err;
 
 	DRM_DEBUG_DRIVER("new priority %u client %p: ctx_index %u db_id %u\n",
@@ -795,7 +805,7 @@ err:
 	DRM_ERROR("FAILED to create priority %u GuC client!\n", priority);
 
 	guc_client_free(dev, client);
-	return NULL;
+	return ERR_PTR(ret);
 }
 
 static void guc_create_log(struct intel_guc *guc)
@@ -820,7 +830,7 @@ static void guc_create_log(struct intel_guc *guc)
 	obj = guc->log_obj;
 	if (!obj) {
 		obj = gem_allocate_guc_obj(dev_priv->dev, size);
-		if (!obj) {
+		if (IS_ERR(obj)) {
 			/* logging will be off */
 			i915.guc_log_level = -1;
 			return;
@@ -940,6 +950,7 @@ int i915_guc_submission_init(struct drm_device *dev)
 	const size_t poolsize = GUC_MAX_GPU_CONTEXTS * ctxsize;
 	const size_t gemsize = round_up(poolsize, PAGE_SIZE);
 	struct intel_guc *guc = &dev_priv->guc;
+	int ret;
 
 	if (!i915.enable_guc_submission)
 		return 0; /* not enabled  */
@@ -948,8 +959,11 @@ int i915_guc_submission_init(struct drm_device *dev)
 		return 0; /* already allocated */
 
 	guc->ctx_pool_obj = gem_allocate_guc_obj(dev_priv->dev, gemsize);
-	if (!guc->ctx_pool_obj)
-		return -ENOMEM;
+	if (IS_ERR(guc->ctx_pool_obj)) {
+		ret = PTR_ERR(guc->ctx_pool_obj);
+		guc->ctx_pool_obj = NULL;
+		return ret;
+	}
 
 	ida_init(&guc->ctx_ids);
 
@@ -969,9 +983,9 @@ int i915_guc_submission_enable(struct drm_device *dev)
 
 	/* client for execbuf submission */
 	client = guc_client_alloc(dev, GUC_CTX_PRIORITY_KMD_NORMAL, ctx);
-	if (!client) {
+	if (IS_ERR(client)) {
 		DRM_ERROR("Failed to create execbuf guc_client\n");
-		return -ENOMEM;
+		return PTR_ERR(client);
 	}
 
 	guc->execbuf_client = client;
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 1c4d8fb..3092504 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2538,7 +2538,7 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
 							     base_aligned,
 							     base_aligned,
 							     size_aligned);
-	if (!obj)
+	if (IS_ERR(obj))
 		return false;
 
 	obj->tiling_mode = plane_config->tiling;
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c
index 09840f4..1c897cb 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -148,11 +148,11 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
 	 * features. */
 	if (size * 2 < dev_priv->gtt.stolen_usable_size)
 		obj = i915_gem_object_create_stolen(dev, size);
-	if (obj == NULL)
+	if (IS_ERR_OR_NULL(obj))
 		obj = i915_gem_alloc_object(dev, size);
-	if (!obj) {
+	if (IS_ERR(obj)) {
 		DRM_ERROR("failed to allocate framebuffer\n");
-		ret = -ENOMEM;
+		ret = PTR_ERR(obj);
 		goto out;
 	}
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f7fac5f..27c103d 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1400,9 +1400,11 @@ static int lrc_setup_wa_ctx_obj(struct intel_engine_cs *ring, u32 size)
 	int ret;
 
 	ring->wa_ctx.obj = i915_gem_alloc_object(ring->dev, PAGE_ALIGN(size));
-	if (!ring->wa_ctx.obj) {
+	if (IS_ERR(ring->wa_ctx.obj)) {
 		DRM_DEBUG_DRIVER("alloc LRC WA ctx backing obj failed.\n");
-		return -ENOMEM;
+		ret = PTR_ERR(ring->wa_ctx.obj);
+		ring->wa_ctx.obj = NULL;
+		return ret;
 	}
 
 	ret = i915_gem_obj_ggtt_pin(ring->wa_ctx.obj, PAGE_SIZE, 0);
@@ -2505,9 +2507,9 @@ int intel_lr_context_deferred_alloc(struct intel_context *ctx,
 	context_size += PAGE_SIZE * LRC_PPHWSP_PN;
 
 	ctx_obj = i915_gem_alloc_object(dev, context_size);
-	if (!ctx_obj) {
+	if (IS_ERR(ctx_obj)) {
 		DRM_DEBUG_DRIVER("Alloc LRC backing obj failed.\n");
-		return -ENOMEM;
+		return PTR_ERR(ctx_obj);
 	}
 
 	ringbuf = intel_engine_create_ringbuffer(ring, 4 * PAGE_SIZE);
diff --git a/drivers/gpu/drm/i915/intel_overlay.c b/drivers/gpu/drm/i915/intel_overlay.c
index 76f1980..3a65858 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -1392,9 +1392,9 @@ void intel_setup_overlay(struct drm_device *dev)
 	reg_bo = NULL;
 	if (!OVERLAY_NEEDS_PHYSICAL(dev))
 		reg_bo = i915_gem_object_create_stolen(dev, PAGE_SIZE);
-	if (reg_bo == NULL)
+	if (IS_ERR_OR_NULL(reg_bo))
 		reg_bo = i915_gem_alloc_object(dev, PAGE_SIZE);
-	if (reg_bo == NULL)
+	if (IS_ERR(reg_bo))
 		goto out_free;
 	overlay->reg_bo = reg_bo;
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9df9e9a..f83b24aa 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5252,10 +5252,13 @@ static void valleyview_setup_pctx(struct drm_device *dev)
 								      pcbr_offset,
 								      I915_GTT_OFFSET_NONE,
 								      pctx_size);
+		if (IS_ERR(pctx))
+			pctx = NULL;
+
 		goto out;
 	}
 
-	DRM_DEBUG_DRIVER("BIOS didn't set up PCBR, fixing up\n");
+	DRM_DEBUG_DRIVER("BIOS didn't set up PCBR or prealloc failed, fixing up\n");
 
 	/*
 	 * From the Gunit register HAS:
@@ -5266,7 +5269,7 @@ static void valleyview_setup_pctx(struct drm_device *dev)
 	 * memory, or any other relevant ranges.
 	 */
 	pctx = i915_gem_object_create_stolen(dev, pctx_size);
-	if (!pctx) {
+	if (IS_ERR(pctx)) {
 		DRM_DEBUG("not enough stolen space for PCTX, disabling\n");
 		return;
 	}
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 339701d..efb9b9f 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -662,9 +662,10 @@ intel_init_pipe_control(struct intel_engine_cs *ring)
 	WARN_ON(ring->scratch.obj);
 
 	ring->scratch.obj = i915_gem_alloc_object(ring->dev, 4096);
-	if (ring->scratch.obj == NULL) {
+	if (IS_ERR(ring->scratch.obj)) {
 		DRM_ERROR("Failed to allocate seqno page\n");
-		ret = -ENOMEM;
+		ret = PTR_ERR(ring->scratch.obj);
+		ring->scratch.obj = NULL;
 		goto err;
 	}
 
@@ -1922,9 +1923,9 @@ static int init_status_page(struct intel_engine_cs *ring)
 		int ret;
 
 		obj = i915_gem_alloc_object(ring->dev, 4096);
-		if (obj == NULL) {
+		if (IS_ERR(obj)) {
 			DRM_ERROR("Failed to allocate status page\n");
-			return -ENOMEM;
+			return PTR_ERR(obj);
 		}
 
 		ret = i915_gem_object_set_cache_level(obj, I915_CACHE_LLC);
@@ -2071,10 +2072,10 @@ static int intel_alloc_ringbuffer_obj(struct drm_device *dev,
 	obj = NULL;
 	if (!HAS_LLC(dev))
 		obj = i915_gem_object_create_stolen(dev, ringbuf->size);
-	if (obj == NULL)
+	if (IS_ERR_OR_NULL(obj))
 		obj = i915_gem_alloc_object(dev, ringbuf->size);
-	if (obj == NULL)
-		return -ENOMEM;
+	if (IS_ERR(obj))
+		return PTR_ERR(obj);
 
 	/* mark ring buffers as read-only from GPU side by default */
 	obj->gt_ro = 1;
@@ -2669,7 +2670,7 @@ int intel_init_render_ring_buffer(struct drm_device *dev)
 	if (INTEL_INFO(dev)->gen >= 8) {
 		if (i915_semaphore_is_enabled(dev)) {
 			obj = i915_gem_alloc_object(dev, 4096);
-			if (obj == NULL) {
+			if (IS_ERR(obj)) {
 				DRM_ERROR("Failed to allocate semaphore bo. Disabling semaphores\n");
 				i915.semaphores = 0;
 			} else {
@@ -2776,9 +2777,9 @@ int intel_init_render_ring_buffer(struct drm_device *dev)
 	/* Workaround batchbuffer to combat CS tlb bug. */
 	if (HAS_BROKEN_CS_TLB(dev)) {
 		obj = i915_gem_alloc_object(dev, I830_WA_SIZE);
-		if (obj == NULL) {
+		if (IS_ERR(obj)) {
 			DRM_ERROR("Failed to allocate batch bo\n");
-			return -ENOMEM;
+			return PTR_ERR(obj);
 		}
 
 		ret = i915_gem_obj_ggtt_pin(obj, 0, 0);
-- 
1.9.1

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

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

* [PATCH 07/11] drm/i915: Add support for stealing purgable stolen pages
  2016-01-14  6:16 [PATCH v14 0/11] Support for creating/using Stolen memory backed objects ankitprasad.r.sharma
                   ` (5 preceding siblings ...)
  2016-01-14  6:16 ` [PATCH 06/11] drm/i915: Propagating correct error codes to the userspace ankitprasad.r.sharma
@ 2016-01-14  6:16 ` ankitprasad.r.sharma
  2016-01-14  6:16 ` [PATCH 08/11] drm/i915: Support for pread/pwrite from/to non shmem backed objects ankitprasad.r.sharma
                   ` (4 subsequent siblings)
  11 siblings, 0 replies; 118+ messages in thread
From: ankitprasad.r.sharma @ 2016-01-14  6:16 UTC (permalink / raw)
  To: intel-gfx; +Cc: akash.goel, shashidhar.hiremath, Ankitprasad Sharma

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

If we run out of stolen memory when trying to allocate an object, see if
we can reap enough purgeable objects to free up enough contiguous free
space for the allocation. This is in principle very much like evicting
objects to free up enough contiguous space in the vma when binding
a new object - and you will be forgiven for thinking that the code looks
very similar.

At the moment, we do not allow userspace to allocate objects in stolen,
so there is neither the memory pressure to trigger stolen eviction nor
any purgeable objects inside the stolen arena. However, this will change
in the near future, and so better management and defragmentation of
stolen memory will become a real issue.

v2: Remember to remove the drm_mm_node.

v3: Rebased to the latest drm-intel-nightly (Ankit)

v4: corrected if-else braces format (Tvrtko/kerneldoc)

v5: Rebased to the latest drm-intel-nightly (Ankit)
Added a seperate list to maintain purgable objects from stolen memory
region (Chris/Daniel)

v6: Compiler optimization (merging 2 single loops into one for() loop),
corrected code for object eviction, retire_requests before starting
object eviction (Chris)

v7: Added kernel doc for i915_gem_object_create_stolen()

v8: Check for struct_mutex lock before creating object from stolen
region (Tvrtko)

v9: Renamed variables to make usage clear, added comment, removed onetime
used macro (Tvrtko)

v10: Avoid masking of error when stolen_alloc fails (Tvrtko)

v11: Renamed stolen_link to tmp_link, as it may be used for other
purposes too (Chris)
Used ERR_CAST to cast error pointers while returning

v12: Added lockdep_assert before starting stolen-backed object
eviction (Chris)

Testcase: igt/gem_stolen

Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
 drivers/gpu/drm/i915/i915_debugfs.c    |   6 +-
 drivers/gpu/drm/i915/i915_drv.h        |  17 +++-
 drivers/gpu/drm/i915/i915_gem.c        |  15 +++
 drivers/gpu/drm/i915/i915_gem_stolen.c | 171 +++++++++++++++++++++++++++++----
 drivers/gpu/drm/i915/intel_pm.c        |   4 +-
 5 files changed, 188 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
index e3377ab..68475d6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -174,7 +174,7 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object *obj)
 			seq_puts(m, ")");
 	}
 	if (obj->stolen)
-		seq_printf(m, " (stolen: %08llx)", obj->stolen->start);
+		seq_printf(m, " (stolen: %08llx)", obj->stolen->base.start);
 	if (obj->pin_display || obj->fault_mappable) {
 		char s[3], *t = s;
 		if (obj->pin_display)
@@ -253,9 +253,9 @@ static int obj_rank_by_stolen(void *priv,
 	struct drm_i915_gem_object *b =
 		container_of(B, struct drm_i915_gem_object, obj_exec_link);
 
-	if (a->stolen->start < b->stolen->start)
+	if (a->stolen->base.start < b->stolen->base.start)
 		return -1;
-	if (a->stolen->start > b->stolen->start)
+	if (a->stolen->base.start > b->stolen->base.start)
 		return 1;
 	return 0;
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4ae8b0b..b18b102 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -839,6 +839,12 @@ struct i915_ctx_hang_stats {
 	bool banned;
 };
 
+struct i915_stolen_node {
+	struct drm_mm_node base;
+	struct list_head mm_link;
+	struct drm_i915_gem_object *obj;
+};
+
 /* This must match up with the value previously used for execbuf2.rsvd1. */
 #define DEFAULT_CONTEXT_HANDLE 0
 
@@ -1249,6 +1255,13 @@ struct i915_gem_mm {
 	 */
 	struct list_head unbound_list;
 
+	/**
+	 * List of stolen objects that have been marked as purgeable and
+	 * thus available for reaping if we need more space for a new
+	 * allocation. Ordered by time of marking purgeable.
+	 */
+	struct list_head stolen_list;
+
 	/** Usable portion of the GTT for GEM */
 	unsigned long stolen_base; /* limited to low memory (32-bit) */
 
@@ -2045,7 +2058,7 @@ struct drm_i915_gem_object {
 	struct list_head vma_list;
 
 	/** Stolen memory for this object, instead of being backed by shmem. */
-	struct drm_mm_node *stolen;
+	struct i915_stolen_node *stolen;
 	struct list_head global_list;
 
 	struct list_head ring_list[I915_NUM_RINGS];
@@ -2053,6 +2066,8 @@ struct drm_i915_gem_object {
 	struct list_head obj_exec_link;
 
 	struct list_head batch_pool_link;
+	/** Used to link an object to a list temporarily */
+	struct list_head tmp_link;
 
 	/**
 	 * This is set if the object is on the active lists (has pending
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b7dcd21..7642b1b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4484,6 +4484,20 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void *data,
 	if (obj->madv == I915_MADV_DONTNEED && obj->pages == NULL)
 		i915_gem_object_truncate(obj);
 
+	if (obj->stolen) {
+		switch (obj->madv) {
+		case I915_MADV_WILLNEED:
+			list_del_init(&obj->stolen->mm_link);
+			break;
+		case I915_MADV_DONTNEED:
+			list_move(&obj->stolen->mm_link,
+				  &dev_priv->mm.stolen_list);
+			break;
+		default:
+			break;
+		}
+	}
+
 	args->retained = obj->madv != __I915_MADV_PURGED;
 
 out:
@@ -5111,6 +5125,7 @@ i915_gem_load(struct drm_device *dev)
 	INIT_LIST_HEAD(&dev_priv->context_list);
 	INIT_LIST_HEAD(&dev_priv->mm.unbound_list);
 	INIT_LIST_HEAD(&dev_priv->mm.bound_list);
+	INIT_LIST_HEAD(&dev_priv->mm.stolen_list);
 	INIT_LIST_HEAD(&dev_priv->mm.fence_list);
 	for (i = 0; i < I915_NUM_RINGS; i++)
 		init_ring_lists(&dev_priv->ring[i]);
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 4daf28f..655eb15 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -542,7 +542,8 @@ i915_gem_object_release_stolen(struct drm_i915_gem_object *obj)
 	struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
 
 	if (obj->stolen) {
-		i915_gem_stolen_remove_node(dev_priv, obj->stolen);
+		list_del(&obj->stolen->mm_link);
+		i915_gem_stolen_remove_node(dev_priv, &obj->stolen->base);
 		kfree(obj->stolen);
 		obj->stolen = NULL;
 	}
@@ -555,7 +556,7 @@ static const struct drm_i915_gem_object_ops i915_gem_object_stolen_ops = {
 
 static struct drm_i915_gem_object *
 _i915_gem_object_create_stolen(struct drm_device *dev,
-			       struct drm_mm_node *stolen)
+			       struct i915_stolen_node *stolen)
 {
 	struct drm_i915_gem_object *obj;
 	struct sg_table *pages;
@@ -564,11 +565,12 @@ _i915_gem_object_create_stolen(struct drm_device *dev,
 	if (obj == NULL)
 		return ERR_PTR(-ENOMEM);
 
-	drm_gem_private_object_init(dev, &obj->base, stolen->size);
+	drm_gem_private_object_init(dev, &obj->base, stolen->base.size);
 	i915_gem_object_init(obj, &i915_gem_object_stolen_ops);
 
 	pages = i915_pages_create_for_stolen(dev,
-					     stolen->start, stolen->size);
+					     stolen->base.start,
+					     stolen->base.size);
 	if (IS_ERR(pages)) {
 		i915_gem_object_free(obj);
 		return ERR_CAST(pages);
@@ -582,24 +584,112 @@ _i915_gem_object_create_stolen(struct drm_device *dev,
 	i915_gem_object_pin_pages(obj);
 	obj->stolen = stolen;
 
+	stolen->obj = obj;
+	INIT_LIST_HEAD(&stolen->mm_link);
+
 	obj->base.read_domains = I915_GEM_DOMAIN_CPU | I915_GEM_DOMAIN_GTT;
 	obj->cache_level = HAS_LLC(dev) ? I915_CACHE_LLC : I915_CACHE_NONE;
 
 	return obj;
 }
 
-struct drm_i915_gem_object *
-i915_gem_object_create_stolen(struct drm_device *dev, u64 size)
+static bool
+mark_free(struct drm_i915_gem_object *obj, struct list_head *unwind)
+{
+	BUG_ON(obj->stolen == NULL);
+
+	if (obj->madv != I915_MADV_DONTNEED)
+		return false;
+
+	if (obj->pin_display)
+		return false;
+
+	list_add(&obj->tmp_link, unwind);
+	return drm_mm_scan_add_block(&obj->stolen->base);
+}
+
+static int
+stolen_evict(struct drm_i915_private *dev_priv, u64 size)
 {
-	struct drm_i915_private *dev_priv = dev->dev_private;
 	struct drm_i915_gem_object *obj;
-	struct drm_mm_node *stolen;
-	int ret;
+	struct list_head unwind, evict;
+	struct i915_stolen_node *iter;
+	int ret, active;
 
-	if (!drm_mm_initialized(&dev_priv->mm.stolen))
-		return ERR_PTR(-ENODEV);
+	lockdep_assert_held(&dev_priv->dev->struct_mutex);
+	drm_mm_init_scan(&dev_priv->mm.stolen, size, 0, 0);
+	INIT_LIST_HEAD(&unwind);
+
+	/* Retire all requests before creating the evict list */
+	i915_gem_retire_requests(dev_priv->dev);
+
+	for (active = 0; active <= 1; active++) {
+		list_for_each_entry(iter, &dev_priv->mm.stolen_list, mm_link) {
+			if (iter->obj->active != active)
+				continue;
+
+			if (mark_free(iter->obj, &unwind))
+				goto found;
+		}
+	}
+
+found:
+	INIT_LIST_HEAD(&evict);
+	while (!list_empty(&unwind)) {
+		obj = list_first_entry(&unwind,
+				       struct drm_i915_gem_object,
+				       tmp_link);
+		list_del(&obj->tmp_link);
+
+		if (drm_mm_scan_remove_block(&obj->stolen->base)) {
+			list_add(&obj->tmp_link, &evict);
+			drm_gem_object_reference(&obj->base);
+		}
+	}
+
+	ret = 0;
+	while (!list_empty(&evict)) {
+		obj = list_first_entry(&evict,
+				       struct drm_i915_gem_object,
+				       tmp_link);
+		list_del(&obj->tmp_link);
+
+		if (ret == 0) {
+			struct i915_vma *vma, *vma_next;
+
+			list_for_each_entry_safe(vma, vma_next,
+						 &obj->vma_list,
+						 vma_link)
+				if (i915_vma_unbind(vma))
+					break;
+
+			/* Stolen pins its pages to prevent the
+			 * normal shrinker from processing stolen
+			 * objects.
+			 */
+			i915_gem_object_unpin_pages(obj);
+
+			ret = i915_gem_object_put_pages(obj);
+			if (ret == 0) {
+				i915_gem_object_release_stolen(obj);
+				obj->madv = __I915_MADV_PURGED;
+			} else {
+				i915_gem_object_pin_pages(obj);
+			}
+		}
+
+		drm_gem_object_unreference(&obj->base);
+	}
+
+	return ret;
+}
+
+static struct i915_stolen_node *
+stolen_alloc(struct drm_i915_private *dev_priv, u64 size)
+{
+	struct i915_stolen_node *stolen;
+	int ret;
 
-	DRM_DEBUG_KMS("creating stolen object: size=%llx\n", size);
 	if (size == 0)
 		return ERR_PTR(-EINVAL);
 
@@ -607,17 +697,60 @@ i915_gem_object_create_stolen(struct drm_device *dev, u64 size)
 	if (!stolen)
 		return ERR_PTR(-ENOMEM);
 
-	ret = i915_gem_stolen_insert_node(dev_priv, stolen, size, 4096);
+	ret = i915_gem_stolen_insert_node(dev_priv, &stolen->base, size, 4096);
+	if (ret == 0)
+		goto out;
+
+	/* No more stolen memory available, or too fragmented.
+	 * Try evicting purgeable objects and search again.
+	 */
+	ret = stolen_evict(dev_priv, size);
+	if (ret == 0)
+		ret = i915_gem_stolen_insert_node(dev_priv, &stolen->base,
+						  size, 4096);
+out:
 	if (ret) {
 		kfree(stolen);
 		return ERR_PTR(ret);
 	}
 
+	return stolen;
+}
+
+/**
+ * i915_gem_object_create_stolen() - creates object using the stolen memory
+ * @dev:	drm device
+ * @size:	size of the object requested
+ *
+ * i915_gem_object_create_stolen() tries to allocate memory for the object
+ * from the stolen memory region. If not enough memory is found, it tries
+ * evicting purgeable objects and searching again.
+ *
+ * Returns: Object pointer - success and error pointer - failure
+ */
+struct drm_i915_gem_object *
+i915_gem_object_create_stolen(struct drm_device *dev, u64 size)
+{
+	struct drm_i915_private *dev_priv = dev->dev_private;
+	struct drm_i915_gem_object *obj;
+	struct i915_stolen_node *stolen;
+
+	WARN_ON(!mutex_is_locked(&dev->struct_mutex));
+
+	if (!drm_mm_initialized(&dev_priv->mm.stolen))
+		return ERR_PTR(-ENODEV);
+
+	DRM_DEBUG_KMS("creating stolen object: size=%llx\n", size);
+
+	stolen = stolen_alloc(dev_priv, size);
+	if (IS_ERR(stolen))
+		return ERR_CAST(stolen);
+
 	obj = _i915_gem_object_create_stolen(dev, stolen);
 	if (!IS_ERR(obj))
 		return obj;
 
-	i915_gem_stolen_remove_node(dev_priv, stolen);
+	i915_gem_stolen_remove_node(dev_priv, &stolen->base);
 	kfree(stolen);
 	return obj;
 }
@@ -631,7 +764,7 @@ i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
 	struct drm_i915_private *dev_priv = dev->dev_private;
 	struct i915_address_space *ggtt = &dev_priv->gtt.base;
 	struct drm_i915_gem_object *obj;
-	struct drm_mm_node *stolen;
+	struct i915_stolen_node *stolen;
 	struct i915_vma *vma;
 	int ret;
 
@@ -650,10 +783,10 @@ i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
 	if (!stolen)
 		return ERR_PTR(-ENOMEM);
 
-	stolen->start = stolen_offset;
-	stolen->size = size;
+	stolen->base.start = stolen_offset;
+	stolen->base.size = size;
 	mutex_lock(&dev_priv->mm.stolen_lock);
-	ret = drm_mm_reserve_node(&dev_priv->mm.stolen, stolen);
+	ret = drm_mm_reserve_node(&dev_priv->mm.stolen, &stolen->base);
 	mutex_unlock(&dev_priv->mm.stolen_lock);
 	if (ret) {
 		DRM_DEBUG_KMS("failed to allocate stolen space\n");
@@ -664,7 +797,7 @@ i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
 	obj = _i915_gem_object_create_stolen(dev, stolen);
 	if (IS_ERR(obj)) {
 		DRM_DEBUG_KMS("failed to allocate stolen object\n");
-		i915_gem_stolen_remove_node(dev_priv, stolen);
+		i915_gem_stolen_remove_node(dev_priv, &stolen->base);
 		kfree(stolen);
 		return obj;
 	}
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f83b24aa..d934146 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5197,7 +5197,7 @@ static void valleyview_check_pctx(struct drm_i915_private *dev_priv)
 	unsigned long pctx_addr = I915_READ(VLV_PCBR) & ~4095;
 
 	WARN_ON(pctx_addr != dev_priv->mm.stolen_base +
-			     dev_priv->vlv_pctx->stolen->start);
+			     dev_priv->vlv_pctx->stolen->base.start);
 }
 
 
@@ -5274,7 +5274,7 @@ static void valleyview_setup_pctx(struct drm_device *dev)
 		return;
 	}
 
-	pctx_paddr = dev_priv->mm.stolen_base + pctx->stolen->start;
+	pctx_paddr = dev_priv->mm.stolen_base + pctx->stolen->base.start;
 	I915_WRITE(VLV_PCBR, pctx_paddr);
 
 out:
-- 
1.9.1

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

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

* [PATCH 08/11] drm/i915: Support for pread/pwrite from/to non shmem backed objects
  2016-01-14  6:16 [PATCH v14 0/11] Support for creating/using Stolen memory backed objects ankitprasad.r.sharma
                   ` (6 preceding siblings ...)
  2016-01-14  6:16 ` [PATCH 07/11] drm/i915: Add support for stealing purgable stolen pages ankitprasad.r.sharma
@ 2016-01-14  6:16 ` ankitprasad.r.sharma
  2016-01-14 10:51   ` Chris Wilson
  2016-01-14  6:16 ` [PATCH 09/11] drm/i915: Migrate stolen objects before hibernation ankitprasad.r.sharma
                   ` (3 subsequent siblings)
  11 siblings, 1 reply; 118+ messages in thread
From: ankitprasad.r.sharma @ 2016-01-14  6:16 UTC (permalink / raw)
  To: intel-gfx; +Cc: akash.goel, shashidhar.hiremath, Ankitprasad Sharma

From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>

This patch adds support for extending the pread/pwrite functionality
for objects not backed by shmem. The access will be made through
gtt interface. This will cover objects backed by stolen memory as well
as other non-shmem backed objects.

v2: Drop locks around slow_user_access, prefault the pages before
access (Chris)

v3: Rebased to the latest drm-intel-nightly (Ankit)

v4: Moved page base & offset calculations outside the copy loop,
corrected data types for size and offset variables, corrected if-else
braces format (Tvrtko/kerneldocs)

v5: Enabled pread/pwrite for all non-shmem backed objects including
without tiling restrictions (Ankit)

v6: Using pwrite_fast for non-shmem backed objects as well (Chris)

v7: Updated commit message, Renamed i915_gem_gtt_read to i915_gem_gtt_copy,
added pwrite slow path for non-shmem backed objects (Chris/Tvrtko)

v8: Updated v7 commit message, mutex unlock around pwrite slow path for
non-shmem backed objects (Tvrtko)

v9: Corrected check during pread_ioctl, to avoid shmem_pread being
called for non-shmem backed objects (Tvrtko)

v10: Moved the write_domain check to needs_clflush and tiling mode check
to pwrite_fast (Chris)

v11: Use pwrite_fast fallback for all objects (shmem and non-shmem backed),
call fast_user_write regardless of pagefault in previous iteration

Testcase: igt/gem_stolen

Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
---
 drivers/gpu/drm/i915/i915_gem.c | 155 +++++++++++++++++++++++++++++++++-------
 1 file changed, 129 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7642b1b..ab1d043 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -55,6 +55,9 @@ static bool cpu_cache_is_coherent(struct drm_device *dev,
 
 static bool cpu_write_needs_clflush(struct drm_i915_gem_object *obj)
 {
+	if (obj->base.write_domain == I915_GEM_DOMAIN_CPU)
+		return false;
+
 	if (!cpu_cache_is_coherent(obj->base.dev, obj->cache_level))
 		return true;
 
@@ -646,6 +649,99 @@ shmem_pread_slow(struct page *page, int shmem_page_offset, int page_length,
 	return ret ? - EFAULT : 0;
 }
 
+static inline uint64_t
+slow_user_access(struct io_mapping *mapping,
+		 uint64_t page_base, int page_offset,
+		 char __user *user_data,
+		 int length, bool pwrite)
+{
+	void __iomem *vaddr_inatomic;
+	void *vaddr;
+	uint64_t unwritten;
+
+	vaddr_inatomic = io_mapping_map_wc(mapping, page_base);
+	/* We can use the cpu mem copy function because this is X86. */
+	vaddr = (void __force *)vaddr_inatomic + page_offset;
+	if (pwrite)
+		unwritten = __copy_from_user(vaddr, user_data, length);
+	else
+		unwritten = __copy_to_user(user_data, vaddr, length);
+
+	io_mapping_unmap(vaddr_inatomic);
+	return unwritten;
+}
+
+static int
+i915_gem_gtt_copy(struct drm_device *dev,
+		   struct drm_i915_gem_object *obj, uint64_t size,
+		   uint64_t data_offset, uint64_t data_ptr)
+{
+	struct drm_i915_private *dev_priv = dev->dev_private;
+	char __user *user_data;
+	uint64_t remain;
+	uint64_t offset, page_base;
+	int page_offset, page_length, ret = 0;
+
+	ret = i915_gem_obj_ggtt_pin(obj, 0, PIN_MAPPABLE);
+	if (ret)
+		goto out;
+
+	ret = i915_gem_object_set_to_gtt_domain(obj, false);
+	if (ret)
+		goto out_unpin;
+
+	ret = i915_gem_object_put_fence(obj);
+	if (ret)
+		goto out_unpin;
+
+	user_data = to_user_ptr(data_ptr);
+	remain = size;
+	offset = i915_gem_obj_ggtt_offset(obj) + data_offset;
+
+	mutex_unlock(&dev->struct_mutex);
+	if (likely(!i915.prefault_disable))
+		ret = fault_in_multipages_writeable(user_data, remain);
+
+	/*
+	 * page_offset = offset within page
+	 * page_base = page offset within aperture
+	 */
+	page_offset = offset_in_page(offset);
+	page_base = offset & PAGE_MASK;
+
+	while (remain > 0) {
+		/* page_length = bytes to copy for this page */
+		page_length = remain;
+		if ((page_offset + remain) > PAGE_SIZE)
+			page_length = PAGE_SIZE - page_offset;
+
+		/* This is a slow read/write as it tries to read from
+		 * and write to user memory which may result into page
+		 * faults
+		 */
+		ret = slow_user_access(dev_priv->gtt.mappable, page_base,
+				       page_offset, user_data,
+				       page_length, false);
+
+		if (ret) {
+			ret = -EFAULT;
+			break;
+		}
+
+		remain -= page_length;
+		user_data += page_length;
+		page_base += page_length;
+		page_offset = 0;
+	}
+
+	mutex_lock(&dev->struct_mutex);
+
+out_unpin:
+	i915_gem_object_ggtt_unpin(obj);
+out:
+	return ret;
+}
+
 static int
 i915_gem_shmem_pread(struct drm_device *dev,
 		     struct drm_i915_gem_object *obj,
@@ -769,17 +865,14 @@ i915_gem_pread_ioctl(struct drm_device *dev, void *data,
 		goto out;
 	}
 
-	/* prime objects have no backing filp to GEM pread/pwrite
-	 * pages from.
-	 */
-	if (!obj->base.filp) {
-		ret = -EINVAL;
-		goto out;
-	}
-
 	trace_i915_gem_object_pread(obj, args->offset, args->size);
 
-	ret = i915_gem_shmem_pread(dev, obj, args, file);
+	/* pread for non shmem backed objects */
+	if (!obj->base.filp && obj->tiling_mode == I915_TILING_NONE)
+		ret = i915_gem_gtt_copy(dev, obj, args->size,
+					args->offset, args->data_ptr);
+	else if (obj->base.filp)
+		ret = i915_gem_shmem_pread(dev, obj, args, file);
 
 out:
 	drm_gem_object_unreference(&obj->base);
@@ -821,10 +914,15 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_private *i915,
 			 struct drm_i915_gem_pwrite *args,
 			 struct drm_file *file)
 {
+	struct drm_device *dev = obj->base.dev;
 	struct drm_mm_node node;
 	uint64_t remain, offset;
 	char __user *user_data;
 	int ret;
+	bool hit_slow_path = false;
+
+	if (obj->tiling_mode != I915_TILING_NONE)
+		return -EFAULT;
 
 	ret = i915_gem_obj_ggtt_pin(obj, 0, PIN_MAPPABLE | PIN_NONBLOCK);
 	if (ret) {
@@ -884,11 +982,23 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_private *i915,
 		/* If we get a fault while copying data, then (presumably) our
 		 * source page isn't available.  Return the error and we'll
 		 * retry in the slow path.
+		 * If the object is non-shmem backed, we retry again with the
+		 * path that handles page fault.
 		 */
 		if (fast_user_write(i915->gtt.mappable, page_base,
 				    page_offset, user_data, page_length)) {
-			ret = -EFAULT;
-			goto out_flush;
+			hit_slow_path = true;
+			mutex_unlock(&dev->struct_mutex);
+			if (slow_user_access(i915->gtt.mappable,
+					     page_base,
+					     page_offset, user_data,
+					     page_length, true)) {
+				ret = -EFAULT;
+				mutex_lock(&dev->struct_mutex);
+				goto out_flush;
+			}
+
+			mutex_lock(&dev->struct_mutex);
 		}
 
 		remain -= page_length;
@@ -897,6 +1007,9 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_private *i915,
 	}
 
 out_flush:
+	if (hit_slow_path)
+		ret = i915_gem_object_set_to_gtt_domain(obj, true);
+
 	intel_fb_obj_flush(obj, false, ORIGIN_GTT);
 out_unpin:
 	if (node.allocated) {
@@ -1155,14 +1268,6 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
 		goto out;
 	}
 
-	/* prime objects have no backing filp to GEM pread/pwrite
-	 * pages from.
-	 */
-	if (!obj->base.filp) {
-		ret = -EINVAL;
-		goto out;
-	}
-
 	trace_i915_gem_object_pwrite(obj, args->offset, args->size);
 
 	ret = -EFAULT;
@@ -1172,9 +1277,7 @@ 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->tiling_mode == I915_TILING_NONE &&
-	    obj->base.write_domain != I915_GEM_DOMAIN_CPU &&
-	    cpu_write_needs_clflush(obj)) {
+	if (!obj->base.filp || cpu_write_needs_clflush(obj)) {
 		ret = i915_gem_gtt_pwrite_fast(dev_priv, obj, args, file);
 		/* Note that the gtt paths might fail with non-page-backed user
 		 * pointers (e.g. gtt mappings when moving data between
@@ -1184,8 +1287,10 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
 	if (ret == -EFAULT || ret == -ENOSPC) {
 		if (obj->phys_handle)
 			ret = i915_gem_phys_pwrite(obj, args, file);
-		else
+		else if (obj->base.filp)
 			ret = i915_gem_shmem_pwrite(dev, obj, args, file);
+		else
+			ret = -ENODEV;
 	}
 
 out:
@@ -3952,9 +4057,7 @@ out:
 	 * object is now coherent at its new cache level (with respect
 	 * to the access domain).
 	 */
-	if (obj->cache_dirty &&
-	    obj->base.write_domain != I915_GEM_DOMAIN_CPU &&
-	    cpu_write_needs_clflush(obj)) {
+	if (obj->cache_dirty && cpu_write_needs_clflush(obj)) {
 		if (i915_gem_clflush_object(obj, true))
 			i915_gem_chipset_flush(obj->base.dev);
 	}
-- 
1.9.1

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

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

* [PATCH 09/11] drm/i915: Migrate stolen objects before hibernation
  2016-01-14  6:16 [PATCH v14 0/11] Support for creating/using Stolen memory backed objects ankitprasad.r.sharma
                   ` (7 preceding siblings ...)
  2016-01-14  6:16 ` [PATCH 08/11] drm/i915: Support for pread/pwrite from/to non shmem backed objects ankitprasad.r.sharma
@ 2016-01-14  6:16 ` ankitprasad.r.sharma
  2016-01-14 10:53   ` Chris Wilson
  2016-01-14  6:16   ` ankitprasad.r.sharma
                   ` (2 subsequent siblings)
  11 siblings, 1 reply; 118+ messages in thread
From: ankitprasad.r.sharma @ 2016-01-14  6:16 UTC (permalink / raw)
  To: intel-gfx; +Cc: akash.goel, Ankitprasad Sharma, shashidhar.hiremath

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

Ville reminded us that stolen memory is not preserved across
hibernation, and a result of this was that context objects now being
allocated from stolen were being corrupted on S4 and promptly hanging
the GPU on resume.

We want to utilise stolen for as much as possible (nothing else will use
that wasted memory otherwise), so we need a strategy for handling
general objects allocated from stolen and hibernation. A simple solution
is to do a CPU copy through the GTT of the stolen object into a fresh
shmemfs backing store and thenceforth treat it as a normal objects. This
can be refined in future to either use a GPU copy to avoid the slow
uncached reads (though it's hibernation!) and recreate stolen objects
upon resume/first-use. For now, a simple approach should suffice for
testing the object migration.

v2:
Swap PTE for pinned bindings over to the shmemfs. This adds a
complicated dance, but is required as many stolen objects are likely to
be pinned for use by the hardware. Swapping the PTEs should not result
in externally visible behaviour, as each PTE update should be atomic and
the two pages identical. (danvet)

safe-by-default, or the principle of least surprise. We need a new flag
to mark objects that we can wilfully discard and recreate across
hibernation. (danvet)

Just use the global_list rather than invent a new stolen_list. This is
the slowpath hibernate and so adding a new list and the associated
complexity isn't worth it.

v3: Rebased on drm-intel-nightly (Ankit)

v4: Use insert_page to map stolen memory backed pages for migration to
shmem (Chris)

v5: Acquire mutex lock while copying stolen buffer objects to shmem (Chris)

v6: Handled file leak, Splitted object migration function, added kerneldoc
for migrate_stolen_to_shmemfs() function (Tvrtko)
Use i915 wrapper function for drm_mm_insert_node_in_range()

v7: Keep the object in cpu domain after get_pages, remove the object from
the unbound list only when marked PURGED, Corrected split of object migration
function (Chris)

v8: Split i915_gem_freeze(), removed redundant use of barrier, corrected
use of set_to_cpu_domain() (Chris)

v9: Replaced WARN_ON by BUG_ON and added a comment explaining it (Tvrtko)

Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
 drivers/gpu/drm/i915/i915_drv.c         |  17 ++-
 drivers/gpu/drm/i915/i915_drv.h         |  10 ++
 drivers/gpu/drm/i915/i915_gem.c         | 198 ++++++++++++++++++++++++++++++--
 drivers/gpu/drm/i915/i915_gem_stolen.c  |  49 ++++++++
 drivers/gpu/drm/i915/intel_display.c    |   3 +
 drivers/gpu/drm/i915/intel_fbdev.c      |   6 +
 drivers/gpu/drm/i915/intel_pm.c         |   2 +
 drivers/gpu/drm/i915/intel_ringbuffer.c |   6 +
 8 files changed, 279 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 288fec7..d980263 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -994,6 +994,21 @@ static int i915_pm_suspend(struct device *dev)
 	return i915_drm_suspend(drm_dev);
 }
 
+static int i915_pm_freeze(struct device *dev)
+{
+	int ret;
+
+	ret = i915_gem_freeze(pci_get_drvdata(to_pci_dev(dev)));
+	if (ret)
+		return ret;
+
+	ret = i915_pm_suspend(dev);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
 static int i915_pm_suspend_late(struct device *dev)
 {
 	struct drm_device *drm_dev = dev_to_i915(dev)->dev;
@@ -1642,7 +1657,7 @@ static const struct dev_pm_ops i915_pm_ops = {
 	 * @restore, @restore_early : called after rebooting and restoring the
 	 *                            hibernation image [PMSG_RESTORE]
 	 */
-	.freeze = i915_pm_suspend,
+	.freeze = i915_pm_freeze,
 	.freeze_late = i915_pm_suspend_late,
 	.thaw_early = i915_pm_resume_early,
 	.thaw = i915_pm_resume,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b18b102..829b6f1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2093,6 +2093,12 @@ struct drm_i915_gem_object {
 	 * Advice: are the backing pages purgeable?
 	 */
 	unsigned int madv:2;
+	/**
+	 * Whereas madv is for userspace, there are certain situations
+	 * where we want I915_MADV_DONTNEED behaviour on internal objects
+	 * without conflating the userspace setting.
+	 */
+	unsigned int internal_volatile:1;
 
 	/**
 	 * Current tiling mode for the object.
@@ -3048,6 +3054,9 @@ int i915_gem_l3_remap(struct drm_i915_gem_request *req, int slice);
 void i915_gem_init_swizzling(struct drm_device *dev);
 void i915_gem_cleanup_ringbuffer(struct drm_device *dev);
 int __must_check i915_gpu_idle(struct drm_device *dev);
+int __must_check i915_gem_freeze(struct drm_device *dev);
+int __must_check
+i915_gem_object_migrate_stolen_to_shmemfs(struct drm_i915_gem_object *obj);
 int __must_check i915_gem_suspend(struct drm_device *dev);
 void __i915_add_request(struct drm_i915_gem_request *req,
 			struct drm_i915_gem_object *batch_obj,
@@ -3277,6 +3286,7 @@ i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
 					       u32 stolen_offset,
 					       u32 gtt_offset,
 					       u32 size);
+int __must_check i915_gem_stolen_freeze(struct drm_i915_private *i915);
 
 /* i915_gem_shrinker.c */
 unsigned long i915_gem_shrink(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ab1d043..77ac128 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4635,12 +4635,27 @@ static const struct drm_i915_gem_object_ops i915_gem_object_ops = {
 	.put_pages = i915_gem_object_put_pages_gtt,
 };
 
+static struct address_space *
+i915_gem_set_inode_gfp(struct drm_device *dev, struct file *file)
+{
+	struct address_space *mapping = file_inode(file)->i_mapping;
+	gfp_t mask;
+
+	mask = GFP_HIGHUSER | __GFP_RECLAIMABLE;
+	if (IS_CRESTLINE(dev) || IS_BROADWATER(dev)) {
+		/* 965gm cannot relocate objects above 4GiB. */
+		mask &= ~__GFP_HIGHMEM;
+		mask |= __GFP_DMA32;
+	}
+	mapping_set_gfp_mask(mapping, mask);
+
+	return mapping;
+}
+
 struct drm_i915_gem_object *i915_gem_alloc_object(struct drm_device *dev,
 						  size_t size)
 {
 	struct drm_i915_gem_object *obj;
-	struct address_space *mapping;
-	gfp_t mask;
 	int ret;
 
 	obj = i915_gem_object_alloc(dev);
@@ -4653,15 +4668,7 @@ struct drm_i915_gem_object *i915_gem_alloc_object(struct drm_device *dev,
 		return ERR_PTR(ret);
 	}
 
-	mask = GFP_HIGHUSER | __GFP_RECLAIMABLE;
-	if (IS_CRESTLINE(dev) || IS_BROADWATER(dev)) {
-		/* 965gm cannot relocate objects above 4GiB. */
-		mask &= ~__GFP_HIGHMEM;
-		mask |= __GFP_DMA32;
-	}
-
-	mapping = file_inode(obj->base.filp)->i_mapping;
-	mapping_set_gfp_mask(mapping, mask);
+	i915_gem_set_inode_gfp(dev, obj->base.filp);
 
 	i915_gem_object_init(obj, &i915_gem_object_ops);
 
@@ -4836,6 +4843,175 @@ i915_gem_stop_ringbuffers(struct drm_device *dev)
 		dev_priv->gt.stop_ring(ring);
 }
 
+static int
+copy_content(struct drm_i915_gem_object *obj,
+		struct drm_i915_private *i915,
+		struct address_space *mapping)
+{
+	struct drm_mm_node node;
+	int ret, i;
+
+	ret = i915_gem_object_set_to_gtt_domain(obj, false);
+	if (ret)
+		return ret;
+
+	/* stolen objects are already pinned to prevent shrinkage */
+	memset(&node, 0, sizeof(node));
+	ret = insert_mappable_node(i915, &node, PAGE_SIZE);
+	if (ret)
+		return ret;
+
+	for (i = 0; i < obj->base.size / PAGE_SIZE; i++) {
+		struct page *page;
+		void *__iomem src;
+		void *dst;
+
+		i915->gtt.base.insert_page(&i915->gtt.base,
+					   i915_gem_object_get_dma_address(obj, i),
+					   node.start,
+					   I915_CACHE_NONE,
+					   0);
+
+		page = shmem_read_mapping_page(mapping, i);
+		if (IS_ERR(page)) {
+			ret = PTR_ERR(page);
+			break;
+		}
+
+		src = io_mapping_map_atomic_wc(i915->gtt.mappable, node.start);
+		dst = kmap_atomic(page);
+		wmb();
+		memcpy_fromio(dst, src, PAGE_SIZE);
+		wmb();
+		kunmap_atomic(dst);
+		io_mapping_unmap_atomic(src);
+
+		page_cache_release(page);
+	}
+
+	i915->gtt.base.clear_range(&i915->gtt.base,
+				   node.start, node.size,
+				   true);
+	remove_mappable_node(&node);
+	if (ret)
+		return ret;
+
+	return i915_gem_object_set_to_cpu_domain(obj, true);
+}
+
+/**
+ * i915_gem_object_migrate_stolen_to_shmemfs() - migrates a stolen backed
+ * object to shmemfs
+ * @obj: stolen backed object to be migrated
+ *
+ * Returns: 0 on successful migration, errno on failure
+ */
+
+int
+i915_gem_object_migrate_stolen_to_shmemfs(struct drm_i915_gem_object *obj)
+{
+	struct drm_i915_private *i915 = to_i915(obj->base.dev);
+	struct i915_vma *vma, *vn;
+	struct file *file;
+	struct address_space *mapping;
+	struct sg_table *stolen_pages, *shmemfs_pages;
+	int ret;
+
+	if (WARN_ON_ONCE(i915_gem_object_needs_bit17_swizzle(obj)))
+		return -EINVAL;
+
+	file = shmem_file_setup("drm mm object", obj->base.size, VM_NORESERVE);
+	if (IS_ERR(file))
+		return PTR_ERR(file);
+	mapping = i915_gem_set_inode_gfp(obj->base.dev, file);
+
+	list_for_each_entry_safe(vma, vn, &obj->vma_list, vma_link)
+		if (i915_vma_unbind(vma))
+			continue;
+
+	if (obj->madv != I915_MADV_WILLNEED && list_empty(&obj->vma_list)) {
+		/* Discard the stolen reservation, and replace with
+		 * an unpopulated shmemfs object.
+		 */
+		obj->madv = __I915_MADV_PURGED;
+		list_del(&obj->global_list);
+	} else {
+		ret = copy_content(obj, i915, mapping);
+		if (ret)
+			goto err_file;
+	}
+
+	stolen_pages = obj->pages;
+	obj->pages = NULL;
+
+	obj->base.filp = file;
+
+	/* Recreate any pinned binding with pointers to the new storage */
+	if (!list_empty(&obj->vma_list)) {
+		ret = i915_gem_object_get_pages_gtt(obj);
+		if (ret) {
+			obj->pages = stolen_pages;
+			goto err_file;
+		}
+
+		obj->get_page.sg = obj->pages->sgl;
+		obj->get_page.last = 0;
+
+		list_for_each_entry(vma, &obj->vma_list, vma_link) {
+			if (!drm_mm_node_allocated(&vma->node))
+				continue;
+
+			/* As vma is already allocated and only the PTEs
+			 * have to be reprogrammed, makes this vma_bind
+			 * call extremely unlikely to fail.
+			 */
+			BUG_ON(i915_vma_bind(vma,
+					      obj->cache_level,
+					      PIN_UPDATE));
+		}
+	}
+
+	/* drop the stolen pin and backing */
+	shmemfs_pages = obj->pages;
+	obj->pages = stolen_pages;
+
+	i915_gem_object_unpin_pages(obj);
+	obj->ops->put_pages(obj);
+	if (obj->ops->release)
+		obj->ops->release(obj);
+
+	obj->ops = &i915_gem_object_ops;
+	obj->pages = shmemfs_pages;
+
+	return 0;
+
+err_file:
+	fput(file);
+	obj->base.filp = NULL;
+	return ret;
+}
+
+int
+i915_gem_freeze(struct drm_device *dev)
+{
+	/* Called before i915_gem_suspend() when hibernating */
+	struct drm_i915_private *i915 = to_i915(dev);
+	int ret;
+
+	ret = i915_mutex_lock_interruptible(dev);
+	if (ret)
+		return ret;
+
+	/* Across hibernation, the stolen area is not preserved.
+	 * Anything inside stolen must copied back to normal
+	 * memory if we wish to preserve it.
+	 */
+	ret = i915_gem_stolen_freeze(i915);
+
+	mutex_unlock(&dev->struct_mutex);
+	return ret;
+}
+
 int
 i915_gem_suspend(struct drm_device *dev)
 {
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 655eb15..335a1ef 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -840,3 +840,52 @@ err:
 	drm_gem_object_unreference(&obj->base);
 	return ERR_PTR(ret);
 }
+
+int i915_gem_stolen_freeze(struct drm_i915_private *i915)
+{
+	struct drm_i915_gem_object *obj, *tmp;
+	struct list_head *phase[] = {
+		&i915->mm.unbound_list, &i915->mm.bound_list, NULL
+	}, **p;
+	int ret = 0;
+
+	for (p = phase; *p; p++) {
+		struct list_head migrate;
+		int ret;
+
+		INIT_LIST_HEAD(&migrate);
+		list_for_each_entry_safe(obj, tmp, *p, global_list) {
+			if (obj->stolen == NULL)
+				continue;
+
+			if (obj->internal_volatile)
+				continue;
+
+			/* In the general case, this object may only be alive
+			 * due to an active reference, and that may disappear
+			 * when we unbind any of the objects (and so wait upon
+			 * the GPU and retire requests). To prevent one of the
+			 * objects from disappearing beneath us, we need to
+			 * take a reference to each as we build the migration
+			 * list.
+			 *
+			 * This is similar to the strategy required whilst
+			 * shrinking or evicting objects (for the same reason).
+			 */
+			drm_gem_object_reference(&obj->base);
+			list_move(&obj->global_list, &migrate);
+		}
+
+		ret = 0;
+		list_for_each_entry_safe(obj, tmp, &migrate, global_list) {
+			if (ret == 0)
+				ret = i915_gem_object_migrate_stolen_to_shmemfs(obj);
+			drm_gem_object_unreference(&obj->base);
+		}
+		list_splice(&migrate, *p);
+		if (ret)
+			break;
+	}
+
+	return ret;
+}
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 3092504..66b7253 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2541,6 +2541,9 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
 	if (IS_ERR(obj))
 		return false;
 
+	/* Not to be preserved across hibernation */
+	obj->internal_volatile = true;
+
 	obj->tiling_mode = plane_config->tiling;
 	if (obj->tiling_mode == I915_TILING_X)
 		obj->stride = fb->pitches[0];
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c
index 1c897cb..c8affff 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -156,6 +156,12 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
 		goto out;
 	}
 
+	/* Discard the contents of the BIOS fb across hibernation.
+	 * We really want to completely throwaway the earlier fbdev
+	 * and reconfigure it anyway.
+	 */
+	obj->internal_volatile = true;
+
 	fb = __intel_framebuffer_create(dev, &mode_cmd, obj);
 	if (IS_ERR(fb)) {
 		drm_gem_object_unreference(&obj->base);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d934146..f2f4ae0 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5278,6 +5278,8 @@ static void valleyview_setup_pctx(struct drm_device *dev)
 	I915_WRITE(VLV_PCBR, pctx_paddr);
 
 out:
+	/* The power context need not be preserved across hibernation */
+	pctx->internal_volatile = true;
 	DRM_DEBUG_DRIVER("PCBR: 0x%08x\n", I915_READ(VLV_PCBR));
 	dev_priv->vlv_pctx = pctx;
 }
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index efb9b9f..95cd5e1 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2077,6 +2077,12 @@ static int intel_alloc_ringbuffer_obj(struct drm_device *dev,
 	if (IS_ERR(obj))
 		return PTR_ERR(obj);
 
+	/* Ringbuffer objects are by definition volatile - only the commands
+	 * between HEAD and TAIL need to be preserved and whilst there are
+	 * any commands there, the ringbuffer is pinned by activity.
+	 */
+	obj->internal_volatile = true;
+
 	/* mark ring buffers as read-only from GPU side by default */
 	obj->gt_ro = 1;
 
-- 
1.9.1

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

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

* [PATCH 10/11] acpi: Export acpi_bus_type
  2016-01-14  6:16 [PATCH v14 0/11] Support for creating/using Stolen memory backed objects ankitprasad.r.sharma
@ 2016-01-14  6:16   ` ankitprasad.r.sharma
  2016-01-14  6:16 ` [PATCH 02/11] drm/i915: Introduce i915_gem_object_get_dma_address() ankitprasad.r.sharma
                     ` (10 subsequent siblings)
  11 siblings, 0 replies; 118+ messages in thread
From: ankitprasad.r.sharma @ 2016-01-14  6:16 UTC (permalink / raw)
  To: intel-gfx
  Cc: Ankitprasad Sharma, Rafael J. Wysocki, shashidhar.hiremath,
	linux-kernel, linux-acpi, akash.goel, Len Brown

From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>

Some modules, like i915.ko, needs to detect when certain ACPI features
are active inorder to prevent corruption on contended resources.
In particular, use of BIOS RapidStart Technology may corrupt the contents
of the reserved graphics memory, due to unalarmed hibernation. In which
case i915.ko cannot assume that it (reserved gfx memory) remains
unmodified and must recreate teh contents and importantly not use it to
store unrecoverable user data.

Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Cc: linux-acpi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/acpi/bus.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index a212cef..69509c7 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -814,6 +814,7 @@ struct bus_type acpi_bus_type = {
 	.remove		= acpi_device_remove,
 	.uevent		= acpi_device_uevent,
 };
+EXPORT_SYMBOL_GPL(acpi_bus_type);
 
 /* --------------------------------------------------------------------------
                              Initialization/Cleanup
-- 
1.9.1

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

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

* [PATCH 10/11] acpi: Export acpi_bus_type
@ 2016-01-14  6:16   ` ankitprasad.r.sharma
  0 siblings, 0 replies; 118+ messages in thread
From: ankitprasad.r.sharma @ 2016-01-14  6:16 UTC (permalink / raw)
  To: intel-gfx
  Cc: akash.goel, shashidhar.hiremath, tvrtko.ursulin,
	Ankitprasad Sharma, Rafael J. Wysocki, Len Brown, linux-acpi,
	linux-kernel

From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>

Some modules, like i915.ko, needs to detect when certain ACPI features
are active inorder to prevent corruption on contended resources.
In particular, use of BIOS RapidStart Technology may corrupt the contents
of the reserved graphics memory, due to unalarmed hibernation. In which
case i915.ko cannot assume that it (reserved gfx memory) remains
unmodified and must recreate teh contents and importantly not use it to
store unrecoverable user data.

Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Cc: linux-acpi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/acpi/bus.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index a212cef..69509c7 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -814,6 +814,7 @@ struct bus_type acpi_bus_type = {
 	.remove		= acpi_device_remove,
 	.uevent		= acpi_device_uevent,
 };
+EXPORT_SYMBOL_GPL(acpi_bus_type);
 
 /* --------------------------------------------------------------------------
                              Initialization/Cleanup
-- 
1.9.1

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

* [PATCH 11/11] drm/i915: Disable use of stolen area by User when Intel RST is present
  2016-01-14  6:16 [PATCH v14 0/11] Support for creating/using Stolen memory backed objects ankitprasad.r.sharma
@ 2016-01-14  6:16   ` ankitprasad.r.sharma
  2016-01-14  6:16 ` [PATCH 02/11] drm/i915: Introduce i915_gem_object_get_dma_address() ankitprasad.r.sharma
                     ` (10 subsequent siblings)
  11 siblings, 0 replies; 118+ messages in thread
From: ankitprasad.r.sharma @ 2016-01-14  6:16 UTC (permalink / raw)
  To: intel-gfx
  Cc: Ankitprasad Sharma, Rafael J. Wysocki, shashidhar.hiremath,
	linux-kernel, linux-acpi, akash.goel, Len Brown

From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>

The BIOS RapidStartTechnology may corrupt the stolen memory across S3
suspend due to unalarmed hibernation, in which case we will not be able
to preserve the User data stored in the stolen region. Hence this patch
tries to identify presence of the RST device on the ACPI bus, and
disables use of stolen memory (for persistent data) if found.

v2: Updated comment, updated/corrected new functions private to driver
(Chris/Tvrtko)

Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Cc: linux-acpi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/gpu/drm/i915/i915_drv.h        | 11 +++++++++++
 drivers/gpu/drm/i915/i915_gem.c        |  8 ++++++++
 drivers/gpu/drm/i915/i915_gem_stolen.c | 14 ++++++++++++++
 drivers/gpu/drm/i915/intel_acpi.c      | 20 ++++++++++++++++++++
 4 files changed, 53 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 829b6f1..20d58ba 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1307,6 +1307,16 @@ struct i915_gem_mm {
 	 */
 	bool busy;
 
+	/**
+	 * Stolen will be lost upon hibernate (as the memory is unpowered).
+	 * Across resume, we expect stolen to be intact - however, it may
+	 * also be utililised by third parties (e.g. Intel RapidStart
+	 * Technology) and if so we have to assume that any data stored in
+	 * stolen across resume is lost and we set this flag to indicate that
+	 * the stolen memory is volatile.
+	 */
+	bool nonvolatile_stolen;
+
 	/* the indicator for dispatch video commands on two BSD rings */
 	int bsd_ring_dispatch_index;
 
@@ -3419,6 +3429,7 @@ intel_opregion_notify_adapter(struct drm_device *dev, pci_power_t state)
 #endif
 
 /* intel_acpi.c */
+bool intel_detect_acpi_rst(void);
 #ifdef CONFIG_ACPI
 extern void intel_register_dsm_handler(void);
 extern void intel_unregister_dsm_handler(void);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 77ac128..fd65d95 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -395,8 +395,16 @@ static struct drm_i915_gem_object *
 i915_gem_alloc_object_stolen(struct drm_device *dev, size_t size)
 {
 	struct drm_i915_gem_object *obj;
+	struct drm_i915_private *dev_priv = dev->dev_private;
 	int ret;
 
+	if (!dev_priv->mm.nonvolatile_stolen) {
+		/* Stolen may be overwritten by external parties
+		 * so unsuitable for persistent user data.
+		 */
+		return ERR_PTR(-ENODEV);
+	}
+
 	mutex_lock(&dev->struct_mutex);
 	obj = i915_gem_object_create_stolen(dev, size);
 	if (IS_ERR(obj))
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 335a1ef..4f44531 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -482,6 +482,20 @@ int i915_gem_init_stolen(struct drm_device *dev)
 	 */
 	drm_mm_init(&dev_priv->mm.stolen, 0, dev_priv->gtt.stolen_usable_size);
 
+	/* If the stolen region can be modified behind our backs upon suspend,
+	 * then we cannot use it to store nonvolatile contents (i.e user data)
+	 * as it will be corrupted upon resume.
+	 */
+	dev_priv->mm.nonvolatile_stolen = true;
+#ifdef CONFIG_SUSPEND
+	if (intel_detect_acpi_rst()) {
+		/* BIOSes using RapidStart Technology have been reported
+		 * to overwrite stolen across S3, not just S4.
+		 */
+		dev_priv->mm.nonvolatile_stolen = false;
+	}
+#endif
+
 	return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_acpi.c b/drivers/gpu/drm/i915/intel_acpi.c
index eb638a1..a827b31 100644
--- a/drivers/gpu/drm/i915/intel_acpi.c
+++ b/drivers/gpu/drm/i915/intel_acpi.c
@@ -23,6 +23,11 @@ static const u8 intel_dsm_guid[] = {
 	0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c
 };
 
+static const struct acpi_device_id irst_ids[] = {
+	{"INT3392", 0},
+	{"", 0}
+};
+
 static char *intel_dsm_port_name(u8 id)
 {
 	switch (id) {
@@ -162,3 +167,18 @@ void intel_register_dsm_handler(void)
 void intel_unregister_dsm_handler(void)
 {
 }
+
+static int intel_match_device(struct device *dev, void* ids)
+{
+	if (acpi_match_device(irst_ids, dev))
+		return 1;
+
+	return 0;
+}
+bool intel_detect_acpi_rst(void)
+{
+	if (bus_for_each_dev(&acpi_bus_type, NULL, NULL, intel_match_device))
+		return true;;
+
+	return false;
+}
-- 
1.9.1

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

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

* [PATCH 11/11] drm/i915: Disable use of stolen area by User when Intel RST is present
@ 2016-01-14  6:16   ` ankitprasad.r.sharma
  0 siblings, 0 replies; 118+ messages in thread
From: ankitprasad.r.sharma @ 2016-01-14  6:16 UTC (permalink / raw)
  To: intel-gfx
  Cc: akash.goel, shashidhar.hiremath, tvrtko.ursulin,
	Ankitprasad Sharma, Rafael J. Wysocki, Len Brown, linux-acpi,
	linux-kernel

From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>

The BIOS RapidStartTechnology may corrupt the stolen memory across S3
suspend due to unalarmed hibernation, in which case we will not be able
to preserve the User data stored in the stolen region. Hence this patch
tries to identify presence of the RST device on the ACPI bus, and
disables use of stolen memory (for persistent data) if found.

v2: Updated comment, updated/corrected new functions private to driver
(Chris/Tvrtko)

Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Cc: linux-acpi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/gpu/drm/i915/i915_drv.h        | 11 +++++++++++
 drivers/gpu/drm/i915/i915_gem.c        |  8 ++++++++
 drivers/gpu/drm/i915/i915_gem_stolen.c | 14 ++++++++++++++
 drivers/gpu/drm/i915/intel_acpi.c      | 20 ++++++++++++++++++++
 4 files changed, 53 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 829b6f1..20d58ba 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1307,6 +1307,16 @@ struct i915_gem_mm {
 	 */
 	bool busy;
 
+	/**
+	 * Stolen will be lost upon hibernate (as the memory is unpowered).
+	 * Across resume, we expect stolen to be intact - however, it may
+	 * also be utililised by third parties (e.g. Intel RapidStart
+	 * Technology) and if so we have to assume that any data stored in
+	 * stolen across resume is lost and we set this flag to indicate that
+	 * the stolen memory is volatile.
+	 */
+	bool nonvolatile_stolen;
+
 	/* the indicator for dispatch video commands on two BSD rings */
 	int bsd_ring_dispatch_index;
 
@@ -3419,6 +3429,7 @@ intel_opregion_notify_adapter(struct drm_device *dev, pci_power_t state)
 #endif
 
 /* intel_acpi.c */
+bool intel_detect_acpi_rst(void);
 #ifdef CONFIG_ACPI
 extern void intel_register_dsm_handler(void);
 extern void intel_unregister_dsm_handler(void);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 77ac128..fd65d95 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -395,8 +395,16 @@ static struct drm_i915_gem_object *
 i915_gem_alloc_object_stolen(struct drm_device *dev, size_t size)
 {
 	struct drm_i915_gem_object *obj;
+	struct drm_i915_private *dev_priv = dev->dev_private;
 	int ret;
 
+	if (!dev_priv->mm.nonvolatile_stolen) {
+		/* Stolen may be overwritten by external parties
+		 * so unsuitable for persistent user data.
+		 */
+		return ERR_PTR(-ENODEV);
+	}
+
 	mutex_lock(&dev->struct_mutex);
 	obj = i915_gem_object_create_stolen(dev, size);
 	if (IS_ERR(obj))
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 335a1ef..4f44531 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -482,6 +482,20 @@ int i915_gem_init_stolen(struct drm_device *dev)
 	 */
 	drm_mm_init(&dev_priv->mm.stolen, 0, dev_priv->gtt.stolen_usable_size);
 
+	/* If the stolen region can be modified behind our backs upon suspend,
+	 * then we cannot use it to store nonvolatile contents (i.e user data)
+	 * as it will be corrupted upon resume.
+	 */
+	dev_priv->mm.nonvolatile_stolen = true;
+#ifdef CONFIG_SUSPEND
+	if (intel_detect_acpi_rst()) {
+		/* BIOSes using RapidStart Technology have been reported
+		 * to overwrite stolen across S3, not just S4.
+		 */
+		dev_priv->mm.nonvolatile_stolen = false;
+	}
+#endif
+
 	return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_acpi.c b/drivers/gpu/drm/i915/intel_acpi.c
index eb638a1..a827b31 100644
--- a/drivers/gpu/drm/i915/intel_acpi.c
+++ b/drivers/gpu/drm/i915/intel_acpi.c
@@ -23,6 +23,11 @@ static const u8 intel_dsm_guid[] = {
 	0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c
 };
 
+static const struct acpi_device_id irst_ids[] = {
+	{"INT3392", 0},
+	{"", 0}
+};
+
 static char *intel_dsm_port_name(u8 id)
 {
 	switch (id) {
@@ -162,3 +167,18 @@ void intel_register_dsm_handler(void)
 void intel_unregister_dsm_handler(void)
 {
 }
+
+static int intel_match_device(struct device *dev, void* ids)
+{
+	if (acpi_match_device(irst_ids, dev))
+		return 1;
+
+	return 0;
+}
+bool intel_detect_acpi_rst(void)
+{
+	if (bus_for_each_dev(&acpi_bus_type, NULL, NULL, intel_match_device))
+		return true;;
+
+	return false;
+}
-- 
1.9.1

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

* Re: [PATCH 03/11] drm/i915: Use insert_page for pwrite_fast
  2016-01-14  6:16 ` [PATCH 03/11] drm/i915: Use insert_page for pwrite_fast ankitprasad.r.sharma
@ 2016-01-14  9:46   ` Chris Wilson
  0 siblings, 0 replies; 118+ messages in thread
From: Chris Wilson @ 2016-01-14  9:46 UTC (permalink / raw)
  To: ankitprasad.r.sharma; +Cc: intel-gfx, akash.goel, shashidhar.hiremath

On Thu, Jan 14, 2016 at 11:46:39AM +0530, ankitprasad.r.sharma@intel.com wrote:
>  out_unpin:
> -	i915_gem_object_ggtt_unpin(obj);
> +	if (node.allocated) {
> +		wmb();
> +		i915->gtt.base.clear_range(&i915->gtt.base,
> +					   node.start, node.size,
> +					   true);
> +		remove_mappable_node(&node);
> +		i915_gem_object_unpin_pages(obj);
> +		i915_gem_object_put_pages(obj);

Oops, just unpin the pages don't free (put) them. The API is asymmetic
and greedy, we grab the pages and don't give them back until the system
asks for them back.
-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

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

* Re: [PATCH 04/11] drm/i915: Clearing buffer objects via CPU/GTT
  2016-01-14  6:16 ` [PATCH 04/11] drm/i915: Clearing buffer objects via CPU/GTT ankitprasad.r.sharma
@ 2016-01-14 10:06   ` Chris Wilson
  0 siblings, 0 replies; 118+ messages in thread
From: Chris Wilson @ 2016-01-14 10:06 UTC (permalink / raw)
  To: ankitprasad.r.sharma; +Cc: intel-gfx, akash.goel, shashidhar.hiremath

On Thu, Jan 14, 2016 at 11:46:40AM +0530, ankitprasad.r.sharma@intel.com wrote:
> From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> 
> This patch adds support for clearing buffer objects via CPU/GTT. This
> is particularly useful for clearing out the non shmem backed objects.
> Currently intend to use this only for buffers allocated from stolen
> region.
> 
> v2: Added kernel doc for i915_gem_clear_object(), corrected/removed
> variable assignments (Tvrtko)
> 
> v3: Map object page by page to the gtt if the pinning of the whole object
> to the ggtt fails, Corrected function name (Chris)
> 
> v4: Clear the buffer page by page, and not map the whole object in the gtt
> aperture. Use i915 wrapper function in place of drm_mm_insert_node_in_range.
> 
> v5: Use renamed wrapper function for drm_mm_insert_node_in_range,
> updated barrier positioning (Chris)
> 
> v6: Use PAGE_SIZE instead of 4096, use get_pages call before pinning pages
> (Tvrtko)
> 
> Testcase: igt/gem_stolen
> 
> Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>  drivers/gpu/drm/i915/i915_gem.c | 49 +++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 50 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7dc122f..1153150 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2893,6 +2893,7 @@ int i915_gem_obj_prepare_shmem_read(struct drm_i915_gem_object *obj,
>  				    int *needs_clflush);
>  
>  int __must_check i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
> +int i915_gem_object_clear(struct drm_i915_gem_object *obj);
>  
>  static inline int __sg_page_count(struct scatterlist *sg)
>  {
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 4ef74cf..a2138c0 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -5359,3 +5359,52 @@ fail:
>  	drm_gem_object_unreference(&obj->base);
>  	return ERR_PTR(ret);
>  }
> +
> +/**
> + * i915_gem_object_clear() - Clear buffer object via CPU/GTT
> + * @obj: Buffer object to be cleared
> + *
> + * Return: 0 - success, non-zero - failure
> + */
> +int i915_gem_object_clear(struct drm_i915_gem_object *obj)
> +{
> +	int ret, i;
> +	char __iomem *base;
> +	size_t size = obj->base.size;
> +	struct drm_i915_private *i915 = to_i915(obj->base.dev);
> +	struct drm_mm_node node;
> +
> +	lockdep_assert_held(&obj->base.dev->struct_mutex);
> +	memset(&node, 0, sizeof(node));

We are repeating this? I think every caller has to clear the node before
inserting it (part of the requirement of the drm_mm_insert_node), so we
can move it to insert_mappable_node().

> +	ret = insert_mappable_node(i915, &node, PAGE_SIZE);
> +	if (ret)
		return ret;

> +
> +	ret = i915_gem_object_get_pages(obj);
> +	if (ret) {
		goto err_remove_node;

> +	}
> +
> +	i915_gem_object_pin_pages(obj);
> +	base = io_mapping_map_wc(i915->gtt.mappable, node.start);
> +	for (i = 0; i < size/PAGE_SIZE; i++) {
> +		i915->gtt.base.insert_page(&i915->gtt.base,
> +					   i915_gem_object_get_dma_address(obj, i),
> +					   node.start,
> +					   I915_CACHE_NONE, 0);
> +		wmb();
> +		memset_io(base, 0, PAGE_SIZE);
> +		wmb();
> +	}
> +
> +	io_mapping_unmap(base);
> +	i915->gtt.base.clear_range(&i915->gtt.base,
> +			node.start, node.size,
> +			true);
> +	remove_mappable_node(&node);
> +	i915_gem_object_unpin_pages(obj);
> +	i915_gem_object_put_pages(obj);

Again don't put pages...

> +out:

Fix the onion.
i.e. undo the operation in reverse order;

	put_pages(obj);
err_remove_node:
	remove_mappable_node(&node);
> +	return ret;
-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

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

* Re: [PATCH 05/11] drm/i915: Support for creating Stolen memory backed objects
  2016-01-14  6:16 ` [PATCH 05/11] drm/i915: Support for creating Stolen memory backed objects ankitprasad.r.sharma
@ 2016-01-14 10:24   ` Chris Wilson
  2016-01-14 10:46     ` Tvrtko Ursulin
  0 siblings, 1 reply; 118+ messages in thread
From: Chris Wilson @ 2016-01-14 10:24 UTC (permalink / raw)
  To: ankitprasad.r.sharma; +Cc: intel-gfx, akash.goel, shashidhar.hiremath

On Thu, Jan 14, 2016 at 11:46:41AM +0530, ankitprasad.r.sharma@intel.com wrote:
> From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> 
> Extend the drm_i915_gem_create structure to add support for
> creating Stolen memory backed objects. Added a new flag through
> which user can specify the preference to allocate the object from
> stolen memory, which if set, an attempt will be made to allocate
> the object from stolen memory subject to the availability of
> free space in the stolen region.
> 
> v2: Rebased to the latest drm-intel-nightly (Ankit)
> 
> v3: Changed versioning of GEM_CREATE param, added new comments (Tvrtko)
> 
> v4: Changed size from 32b to 64b to prevent userspace overflow (Tvrtko)
> Corrected function arguments ordering (Chris)
> 
> v5: Corrected function name (Chris)
> 
> v6: Updated datatype for flags to keep sizeof(drm_i915_gem_create) u64
> aligned (Chris)
> 
> v7: Use first 8 bits of gem_create flags for placement (Chris), Add helper
> function for object allocation from stolen region (Ankit)
> 
> Testcase: igt/gem_stolen
> 
> Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>

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

> +	/**
> +	 * Requested flags (currently used for placement
> +	 * (which memory domain))
> +	 *
> +	 * You can request that the object be created from special memory
> +	 * rather than regular system pages using this parameter. Such
> +	 * irregular objects may have certain restrictions (such as CPU
> +	 * access to a stolen object is verboten).
> +	 *
> +	 * This can be used in the future for other purposes too
> +	 * e.g. specifying tiling/caching/madvise
> +	 */
> +	__u64 flags;
> +#define I915_CREATE_PLACEMENT_NORMAL 	0 /* standard swappable bo  */
> +#define I915_CREATE_PLACEMENT_STOLEN 	1 /* Cannot use CPU mmaps */

/* Allocate the object from memory reserved for the igfx (stolen).
 *
 * Objects allocated from stolen are restricted in the API they can use,
 * as direct CPU access to stolen memory is prohibited by the system.
 * This means that you cannot use a regular CPU mmap (either using WB
 * or with the WC extension). You can still use a GTT mmap, pwrite,
 * pread and pass it around for use by execbuffer and between processes
 * like normal.
 *
 * Stolen memory is a very limited resource and certain functions of the
 * hardware can only work from within stolen memory. Userspace's
 * allocations may be evicted from stolen and moved to normal memory as
 * required. If the allocation is marked as purgeable (using madvise),
 * the allocation will be dropped and further access to the object's
 * backing storage will result in -EFAULT. Stolen objects will also be
 * migrated to normal memory across suspend and resume, as the stolen
 * memory is not preserved.
 *
 * Stolen memory is regarded as a resource placement hint, most suitable
 * for medium-sized buffers that are only accessed by the GPU and can be
 * discarded.
 */

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

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

* Re: [PATCH 06/11] drm/i915: Propagating correct error codes to the userspace
  2016-01-14  6:16 ` [PATCH 06/11] drm/i915: Propagating correct error codes to the userspace ankitprasad.r.sharma
@ 2016-01-14 10:25   ` Chris Wilson
  0 siblings, 0 replies; 118+ messages in thread
From: Chris Wilson @ 2016-01-14 10:25 UTC (permalink / raw)
  To: ankitprasad.r.sharma; +Cc: intel-gfx, akash.goel, shashidhar.hiremath

On Thu, Jan 14, 2016 at 11:46:42AM +0530, ankitprasad.r.sharma@intel.com wrote:
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 6a429c0..b7dcd21 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -396,19 +396,18 @@ i915_gem_alloc_object_stolen(struct drm_device *dev, size_t size)
>  
>  	mutex_lock(&dev->struct_mutex);
>  	obj = i915_gem_object_create_stolen(dev, size);
> -	if (!obj) {
> -		mutex_unlock(&dev->struct_mutex);
> -		return NULL;
> -	}
> +	if (IS_ERR(obj))
> +		goto out;
>  
>  	/* Always clear fresh buffers before handing to userspace */
>  	ret = i915_gem_object_clear(obj);
>  	if (ret) {
>  		drm_gem_object_unreference(&obj->base);
>  		mutex_unlock(&dev->struct_mutex);
> -		return NULL;
> +		return ERR_PTR(ret);

ret = i915_gem_object_clear(obj);
if (ret) {
	drm_gem_object_unreference(&obj->base);
	obj = ERR_PTR(ret);
	goto out;
}

>  	}
>  
> +out:
>  	mutex_unlock(&dev->struct_mutex);
>  	return obj;
>  }

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

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

* Re: [PATCH 01/11] drm/i915: Add support for mapping an object page by page
  2016-01-14  6:16 ` [PATCH 01/11] drm/i915: Add support for mapping an object page by page ankitprasad.r.sharma
@ 2016-01-14 10:32   ` Tvrtko Ursulin
  2016-01-14 13:34     ` Chris Wilson
  0 siblings, 1 reply; 118+ messages in thread
From: Tvrtko Ursulin @ 2016-01-14 10:32 UTC (permalink / raw)
  To: ankitprasad.r.sharma, intel-gfx; +Cc: akash.goel, shashidhar.hiremath


On 14/01/16 06:16, ankitprasad.r.sharma@intel.com wrote:
> From: Chris Wilson <chris@chris-wilson.co.uk>
>
> Introduced a new vm specfic callback insert_page() to program a single pte in
> ggtt or ppgtt. This allows us to map a single page in to the mappable aperture
> space. This can be iterated over to access the whole object by using space as
> meagre as page size.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> ---
>   drivers/char/agp/intel-gtt.c        |  9 +++++++
>   drivers/gpu/drm/i915/i915_gem_gtt.c | 49 +++++++++++++++++++++++++++++++++++++
>   drivers/gpu/drm/i915/i915_gem_gtt.h |  5 ++++
>   include/drm/intel-gtt.h             |  3 +++
>   4 files changed, 66 insertions(+)
>
> diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
> index 1341a94..7c68576 100644
> --- a/drivers/char/agp/intel-gtt.c
> +++ b/drivers/char/agp/intel-gtt.c
> @@ -838,6 +838,15 @@ static bool i830_check_flags(unsigned int flags)
>   	return false;
>   }
>
> +void intel_gtt_insert_page(dma_addr_t addr,
> +			   unsigned int pg,
> +			   unsigned int flags)
> +{
> +	intel_private.driver->write_entry(addr, pg, flags);
> +	wmb();
> +}
> +EXPORT_SYMBOL(intel_gtt_insert_page);
> +
>   void intel_gtt_insert_sg_entries(struct sg_table *st,
>   				 unsigned int pg_start,
>   				 unsigned int flags)
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 56f4f2e..48bd6a4 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -2339,6 +2339,23 @@ static void gen8_set_pte(void __iomem *addr, gen8_pte_t pte)
>   #endif
>   }
>
> +static void gen8_ggtt_insert_page(struct i915_address_space *vm,
> +				  dma_addr_t addr,
> +				  uint64_t offset,
> +				  enum i915_cache_level level,
> +				  u32 unused)
> +{
> +	struct drm_i915_private *dev_priv = to_i915(vm->dev);
> +	gen8_pte_t __iomem *pte =
> +		(gen8_pte_t __iomem *)dev_priv->gtt.gsm +
> +		(offset >> PAGE_SHIFT);
> +
> +	gen8_set_pte(pte, gen8_pte_encode(addr, level, true));
> +	wmb();
> +
> +	I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
> +}
> +
>   static void gen8_ggtt_insert_entries(struct i915_address_space *vm,
>   				     struct sg_table *st,
>   				     uint64_t start,
> @@ -2410,6 +2427,23 @@ static void gen8_ggtt_insert_entries__BKL(struct i915_address_space *vm,
>   	stop_machine(gen8_ggtt_insert_entries__cb, &arg, NULL);
>   }
>
> +static void gen6_ggtt_insert_page(struct i915_address_space *vm,
> +				  dma_addr_t addr,
> +				  uint64_t offset,
> +				  enum i915_cache_level level,
> +				  u32 flags)
> +{
> +	struct drm_i915_private *dev_priv = to_i915(vm->dev);
> +	gen6_pte_t __iomem *pte =
> +		(gen6_pte_t __iomem *)dev_priv->gtt.gsm +
> +		(offset >> PAGE_SHIFT);
> +
> +	iowrite32(vm->pte_encode(addr, level, true, flags), pte);
> +	wmb();
> +
> +	I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
> +}
> +
>   /*
>    * Binds an object into the global gtt with the specified cache level. The object
>    * will be accessible to the GPU via commands whose operands reference offsets
> @@ -2521,6 +2555,18 @@ static void gen6_ggtt_clear_range(struct i915_address_space *vm,
>   	assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
>   }
>
> +static void i915_ggtt_insert_page(struct i915_address_space *vm,
> +				  dma_addr_t addr,
> +				  uint64_t offset,
> +				  enum i915_cache_level cache_level,
> +				  u32 unused)
> +{
> +	unsigned int flags = (cache_level == I915_CACHE_NONE) ?
> +		AGP_USER_MEMORY : AGP_USER_CACHED_MEMORY;
> +
> +	intel_gtt_insert_page(addr, offset >> PAGE_SHIFT, flags);
> +}
> +
>   static void i915_ggtt_insert_entries(struct i915_address_space *vm,
>   				     struct sg_table *pages,
>   				     uint64_t start,
> @@ -3050,6 +3096,7 @@ static int gen8_gmch_probe(struct drm_device *dev,
>   	ret = ggtt_probe_common(dev, gtt_size);
>
>   	dev_priv->gtt.base.clear_range = gen8_ggtt_clear_range;
> +	dev_priv->gtt.base.insert_page = gen8_ggtt_insert_page;
>   	dev_priv->gtt.base.insert_entries = gen8_ggtt_insert_entries;
>   	dev_priv->gtt.base.bind_vma = ggtt_bind_vma;
>   	dev_priv->gtt.base.unbind_vma = ggtt_unbind_vma;
> @@ -3095,6 +3142,7 @@ static int gen6_gmch_probe(struct drm_device *dev,
>   	ret = ggtt_probe_common(dev, gtt_size);
>
>   	dev_priv->gtt.base.clear_range = gen6_ggtt_clear_range;
> +	dev_priv->gtt.base.insert_page = gen6_ggtt_insert_page;
>   	dev_priv->gtt.base.insert_entries = gen6_ggtt_insert_entries;
>   	dev_priv->gtt.base.bind_vma = ggtt_bind_vma;
>   	dev_priv->gtt.base.unbind_vma = ggtt_unbind_vma;
> @@ -3129,6 +3177,7 @@ static int i915_gmch_probe(struct drm_device *dev,
>   	intel_gtt_get(gtt_total, stolen, mappable_base, mappable_end);
>
>   	dev_priv->gtt.do_idle_maps = needs_idle_maps(dev_priv->dev);
> +	dev_priv->gtt.base.insert_page = i915_ggtt_insert_page;
>   	dev_priv->gtt.base.insert_entries = i915_ggtt_insert_entries;
>   	dev_priv->gtt.base.clear_range = i915_ggtt_clear_range;
>   	dev_priv->gtt.base.bind_vma = ggtt_bind_vma;
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h
> index b448ad8..5f86596 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -317,6 +317,11 @@ struct i915_address_space {
>   			    uint64_t start,
>   			    uint64_t length,
>   			    bool use_scratch);
> +	void (*insert_page)(struct i915_address_space *vm,
> +			    dma_addr_t addr,
> +			    uint64_t offset,
> +			    enum i915_cache_level cache_level,
> +			    u32 flags);
>   	void (*insert_entries)(struct i915_address_space *vm,
>   			       struct sg_table *st,
>   			       uint64_t start,

Why not extend the current API to support start page offset and number 
of pages? Could default to full object like today if zero. Eg:

  void (*insert_entries)(struct i915_address_space *vm,
			struct sg_table *st,
+			unsigned page_offset,
+			unsigned num_pages,
			uint64_t start,
			enum i915_cache_level cache_level,
			u32 flags);

That way we would not have two functions for effectively the same thing 
operating on different type of input parameters.

If extending insert_entries is not preferable, then still we could add 
another compatible one, like insert_entries_range or something, and then 
both could share the same underlying implementation for less code.

Like this, this patch already does not match current codebase - see 
assert_rpm_atomic_begin in insert_entries.

Also if API between the two was compatible there would be no need for 
i915_gem_object_get_dma_address() and i915_gem_object_get_page() could 
be used instead.

Regards,

Tvrtko

> diff --git a/include/drm/intel-gtt.h b/include/drm/intel-gtt.h
> index 9e9bddaa5..f49edec 100644
> --- a/include/drm/intel-gtt.h
> +++ b/include/drm/intel-gtt.h
> @@ -13,6 +13,9 @@ void intel_gmch_remove(void);
>   bool intel_enable_gtt(void);
>
>   void intel_gtt_chipset_flush(void);
> +void intel_gtt_insert_page(dma_addr_t addr,
> +			   unsigned int pg,
> +			   unsigned int flags);
>   void intel_gtt_insert_sg_entries(struct sg_table *st,
>   				 unsigned int pg_start,
>   				 unsigned int flags);
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [PATCH 05/11] drm/i915: Support for creating Stolen memory backed objects
  2016-01-14 10:24   ` Chris Wilson
@ 2016-01-14 10:46     ` Tvrtko Ursulin
  2016-01-14 11:14       ` Chris Wilson
  0 siblings, 1 reply; 118+ messages in thread
From: Tvrtko Ursulin @ 2016-01-14 10:46 UTC (permalink / raw)
  To: Chris Wilson, ankitprasad.r.sharma, intel-gfx, akash.goel,
	shashidhar.hiremath


On 14/01/16 10:24, Chris Wilson wrote:
> On Thu, Jan 14, 2016 at 11:46:41AM +0530, ankitprasad.r.sharma@intel.com wrote:
>> From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
>>
>> Extend the drm_i915_gem_create structure to add support for
>> creating Stolen memory backed objects. Added a new flag through
>> which user can specify the preference to allocate the object from
>> stolen memory, which if set, an attempt will be made to allocate
>> the object from stolen memory subject to the availability of
>> free space in the stolen region.
>>
>> v2: Rebased to the latest drm-intel-nightly (Ankit)
>>
>> v3: Changed versioning of GEM_CREATE param, added new comments (Tvrtko)
>>
>> v4: Changed size from 32b to 64b to prevent userspace overflow (Tvrtko)
>> Corrected function arguments ordering (Chris)
>>
>> v5: Corrected function name (Chris)
>>
>> v6: Updated datatype for flags to keep sizeof(drm_i915_gem_create) u64
>> aligned (Chris)
>>
>> v7: Use first 8 bits of gem_create flags for placement (Chris), Add helper
>> function for object allocation from stolen region (Ankit)
>>
>> Testcase: igt/gem_stolen
>>
>> Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
>
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
>
>> +	/**
>> +	 * Requested flags (currently used for placement
>> +	 * (which memory domain))
>> +	 *
>> +	 * You can request that the object be created from special memory
>> +	 * rather than regular system pages using this parameter. Such
>> +	 * irregular objects may have certain restrictions (such as CPU
>> +	 * access to a stolen object is verboten).
>> +	 *
>> +	 * This can be used in the future for other purposes too
>> +	 * e.g. specifying tiling/caching/madvise
>> +	 */
>> +	__u64 flags;
>> +#define I915_CREATE_PLACEMENT_NORMAL 	0 /* standard swappable bo  */
>> +#define I915_CREATE_PLACEMENT_STOLEN 	1 /* Cannot use CPU mmaps */
>
> /* Allocate the object from memory reserved for the igfx (stolen).
>   *
>   * Objects allocated from stolen are restricted in the API they can use,
>   * as direct CPU access to stolen memory is prohibited by the system.
>   * This means that you cannot use a regular CPU mmap (either using WB
>   * or with the WC extension). You can still use a GTT mmap, pwrite,
>   * pread and pass it around for use by execbuffer and between processes
>   * like normal.

What happens when a stolen batch buffer gets to relocate_entry_cpu ?

>   *
>   * Stolen memory is a very limited resource and certain functions of the
>   * hardware can only work from within stolen memory. Userspace's
>   * allocations may be evicted from stolen and moved to normal memory as
>   * required. If the allocation is marked as purgeable (using madvise),
>   * the allocation will be dropped and further access to the object's
>   * backing storage will result in -EFAULT. Stolen objects will also be
>   * migrated to normal memory across suspend and resume, as the stolen
>   * memory is not preserved.
>   *
>   * Stolen memory is regarded as a resource placement hint, most suitable
>   * for medium-sized buffers that are only accessed by the GPU and can be
>   * discarded.
>   */

Would it be better if the placement hint did not specifically mention 
stolen memory but specific limitations? Like,

create.flags = NOT_A_BATCHBUFFER | DONT_NEED_MMAP_CPU

?

Regards,

Tvrtko







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

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

* Re: [PATCH 08/11] drm/i915: Support for pread/pwrite from/to non shmem backed objects
  2016-01-14  6:16 ` [PATCH 08/11] drm/i915: Support for pread/pwrite from/to non shmem backed objects ankitprasad.r.sharma
@ 2016-01-14 10:51   ` Chris Wilson
  0 siblings, 0 replies; 118+ messages in thread
From: Chris Wilson @ 2016-01-14 10:51 UTC (permalink / raw)
  To: ankitprasad.r.sharma; +Cc: intel-gfx, akash.goel, shashidhar.hiremath

On Thu, Jan 14, 2016 at 11:46:44AM +0530, ankitprasad.r.sharma@intel.com wrote:
> From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> 
> This patch adds support for extending the pread/pwrite functionality
> for objects not backed by shmem. The access will be made through
> gtt interface. This will cover objects backed by stolen memory as well
> as other non-shmem backed objects.
> 
> v2: Drop locks around slow_user_access, prefault the pages before
> access (Chris)
> 
> v3: Rebased to the latest drm-intel-nightly (Ankit)
> 
> v4: Moved page base & offset calculations outside the copy loop,
> corrected data types for size and offset variables, corrected if-else
> braces format (Tvrtko/kerneldocs)
> 
> v5: Enabled pread/pwrite for all non-shmem backed objects including
> without tiling restrictions (Ankit)
> 
> v6: Using pwrite_fast for non-shmem backed objects as well (Chris)
> 
> v7: Updated commit message, Renamed i915_gem_gtt_read to i915_gem_gtt_copy,
> added pwrite slow path for non-shmem backed objects (Chris/Tvrtko)
> 
> v8: Updated v7 commit message, mutex unlock around pwrite slow path for
> non-shmem backed objects (Tvrtko)
> 
> v9: Corrected check during pread_ioctl, to avoid shmem_pread being
> called for non-shmem backed objects (Tvrtko)
> 
> v10: Moved the write_domain check to needs_clflush and tiling mode check
> to pwrite_fast (Chris)
> 
> v11: Use pwrite_fast fallback for all objects (shmem and non-shmem backed),
> call fast_user_write regardless of pagefault in previous iteration
> 
> Testcase: igt/gem_stolen

Presumably igt/gem_pread and igt/gem_pwrite didn't break?

We could with the help of say vgem create a few 1+GiB objects that have
no obj->base.filp and so stress the pinning code better. (Or even just
stolen on some machines would be enough to create an unmappable object.)

> Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 155 +++++++++++++++++++++++++++++++++-------
>  1 file changed, 129 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 7642b1b..ab1d043 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -55,6 +55,9 @@ static bool cpu_cache_is_coherent(struct drm_device *dev,
>  
>  static bool cpu_write_needs_clflush(struct drm_i915_gem_object *obj)
>  {
> +	if (obj->base.write_domain == I915_GEM_DOMAIN_CPU)
> +		return false;
> +
>  	if (!cpu_cache_is_coherent(obj->base.dev, obj->cache_level))
>  		return true;
>  
> @@ -646,6 +649,99 @@ shmem_pread_slow(struct page *page, int shmem_page_offset, int page_length,
>  	return ret ? - EFAULT : 0;
>  }
>  
> +static inline uint64_t
> +slow_user_access(struct io_mapping *mapping,
> +		 uint64_t page_base, int page_offset,
> +		 char __user *user_data,
> +		 int length, bool pwrite)

static inline bool
> +{
> +	void __iomem *vaddr_inatomic;

inatomic? We are not!
void __iomem *ioaddr;
void *vaddr;

> +	void *vaddr;
> +	uint64_t unwritten;
> +
> +	vaddr_inatomic = io_mapping_map_wc(mapping, page_base);
> +	/* We can use the cpu mem copy function because this is X86. */
> +	vaddr = (void __force *)vaddr_inatomic + page_offset;
> +	if (pwrite)
> +		unwritten = __copy_from_user(vaddr, user_data, length);
> +	else
> +		unwritten = __copy_to_user(user_data, vaddr, length);

> +
> +	io_mapping_unmap(vaddr_inatomic);
> +	return unwritten;
> +}
> +
> +static int
> +i915_gem_gtt_copy(struct drm_device *dev,
> +		   struct drm_i915_gem_object *obj, uint64_t size,
> +		   uint64_t data_offset, uint64_t data_ptr)
> +{
> +	struct drm_i915_private *dev_priv = dev->dev_private;
> +	char __user *user_data;
> +	uint64_t remain;
> +	uint64_t offset, page_base;
> +	int page_offset, page_length, ret = 0;
> +
> +	ret = i915_gem_obj_ggtt_pin(obj, 0, PIN_MAPPABLE);
> +	if (ret)
> +		goto out;
> +
> +	ret = i915_gem_object_set_to_gtt_domain(obj, false);
> +	if (ret)
> +		goto out_unpin;
> +
> +	ret = i915_gem_object_put_fence(obj);
> +	if (ret)
> +		goto out_unpin;
> +
> +	user_data = to_user_ptr(data_ptr);
> +	remain = size;
> +	offset = i915_gem_obj_ggtt_offset(obj) + data_offset;
> +
> +	mutex_unlock(&dev->struct_mutex);
> +	if (likely(!i915.prefault_disable))
> +		ret = fault_in_multipages_writeable(user_data, remain);
> +
> +	/*
> +	 * page_offset = offset within page
> +	 * page_base = page offset within aperture
> +	 */
> +	page_offset = offset_in_page(offset);
> +	page_base = offset & PAGE_MASK;

Where's the page-by-page copy? (Think about objects larger than the
aperture, or trying to operate in parallel with many - pinning aperture
space is bad practice.)

> +	while (remain > 0) {
> +		/* page_length = bytes to copy for this page */
> +		page_length = remain;
> +		if ((page_offset + remain) > PAGE_SIZE)
> +			page_length = PAGE_SIZE - page_offset;
> +
> +		/* This is a slow read/write as it tries to read from
> +		 * and write to user memory which may result into page
> +		 * faults

...and so we cannot perform this under the struct_mutex.

> +		 */
> +		ret = slow_user_access(dev_priv->gtt.mappable, page_base,
> +				       page_offset, user_data,
> +				       page_length, false);
> +
> +		if (ret) {

Fortuituously we don't copy more than a page, so this truncation error
should never hit. Still sloppy though.

> +			ret = -EFAULT;
> +			break;
> +		}
> +
> +		remain -= page_length;
> +		user_data += page_length;
> +		page_base += page_length;
> +		page_offset = 0;
> +	}
> +
> +	mutex_lock(&dev->struct_mutex);

This was the unlocked path, reset the domain. We could do some error
detection, but it is a user error so they get to keep the broken
pieces. (We should be consistent, always restore the domain after the
unlock/lock, or never. I'm actually thinking never, user error and all.)

> +
> +out_unpin:
> +	i915_gem_object_ggtt_unpin(obj);
> +out:
> +	return ret;
> +}
> +
>  static int
>  i915_gem_shmem_pread(struct drm_device *dev,
>  		     struct drm_i915_gem_object *obj,
> @@ -769,17 +865,14 @@ i915_gem_pread_ioctl(struct drm_device *dev, void *data,
>  		goto out;
>  	}
>  
> -	/* prime objects have no backing filp to GEM pread/pwrite
> -	 * pages from.
> -	 */
> -	if (!obj->base.filp) {
> -		ret = -EINVAL;
> -		goto out;
> -	}
> -
>  	trace_i915_gem_object_pread(obj, args->offset, args->size);
>  
> -	ret = i915_gem_shmem_pread(dev, obj, args, file);
> +	/* pread for non shmem backed objects */
> +	if (!obj->base.filp && obj->tiling_mode == I915_TILING_NONE)
> +		ret = i915_gem_gtt_copy(dev, obj, args->size,
> +					args->offset, args->data_ptr);
> +	else if (obj->base.filp)
> +		ret = i915_gem_shmem_pread(dev, obj, args, file);

I think this is much more readable as

ret = i915_gem_shmem_pread(##args);
if (ret == -ENODEV) /* or -EFAULT */
	ret = i915_gem_ggtt_pread(##args);

i.e. push the condition checking down and we know that a read of the
backing storage + clflush is the preferred option and should *always* be
tried first.
-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

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

* Re: [PATCH 09/11] drm/i915: Migrate stolen objects before hibernation
  2016-01-14  6:16 ` [PATCH 09/11] drm/i915: Migrate stolen objects before hibernation ankitprasad.r.sharma
@ 2016-01-14 10:53   ` Chris Wilson
  0 siblings, 0 replies; 118+ messages in thread
From: Chris Wilson @ 2016-01-14 10:53 UTC (permalink / raw)
  To: ankitprasad.r.sharma; +Cc: intel-gfx, akash.goel, shashidhar.hiremath

On Thu, Jan 14, 2016 at 11:46:45AM +0530, ankitprasad.r.sharma@intel.com wrote:
> From: Chris Wilson <chris@chris-wilson.co.uk>
> 
> Ville reminded us that stolen memory is not preserved across
> hibernation, and a result of this was that context objects now being
> allocated from stolen were being corrupted on S4 and promptly hanging
> the GPU on resume.
> 
> We want to utilise stolen for as much as possible (nothing else will use
> that wasted memory otherwise), so we need a strategy for handling
> general objects allocated from stolen and hibernation. A simple solution
> is to do a CPU copy through the GTT of the stolen object into a fresh
> shmemfs backing store and thenceforth treat it as a normal objects. This
> can be refined in future to either use a GPU copy to avoid the slow
> uncached reads (though it's hibernation!) and recreate stolen objects
> upon resume/first-use. For now, a simple approach should suffice for
> testing the object migration.
> 
> v2:
> Swap PTE for pinned bindings over to the shmemfs. This adds a
> complicated dance, but is required as many stolen objects are likely to
> be pinned for use by the hardware. Swapping the PTEs should not result
> in externally visible behaviour, as each PTE update should be atomic and
> the two pages identical. (danvet)
> 
> safe-by-default, or the principle of least surprise. We need a new flag
> to mark objects that we can wilfully discard and recreate across
> hibernation. (danvet)
> 
> Just use the global_list rather than invent a new stolen_list. This is
> the slowpath hibernate and so adding a new list and the associated
> complexity isn't worth it.
> 
> v3: Rebased on drm-intel-nightly (Ankit)
> 
> v4: Use insert_page to map stolen memory backed pages for migration to
> shmem (Chris)
> 
> v5: Acquire mutex lock while copying stolen buffer objects to shmem (Chris)
> 
> v6: Handled file leak, Splitted object migration function, added kerneldoc
> for migrate_stolen_to_shmemfs() function (Tvrtko)
> Use i915 wrapper function for drm_mm_insert_node_in_range()
> 
> v7: Keep the object in cpu domain after get_pages, remove the object from
> the unbound list only when marked PURGED, Corrected split of object migration
> function (Chris)
> 
> v8: Split i915_gem_freeze(), removed redundant use of barrier, corrected
> use of set_to_cpu_domain() (Chris)
> 
> v9: Replaced WARN_ON by BUG_ON and added a comment explaining it (Tvrtko)

I read Daniel's comment as this should be BUG_ON. It is machine death. A
way for userspace to engineer writes to unowned pages.
-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

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

* Re: [PATCH 05/11] drm/i915: Support for creating Stolen memory backed objects
  2016-01-14 10:46     ` Tvrtko Ursulin
@ 2016-01-14 11:14       ` Chris Wilson
  2016-01-14 11:27         ` Tvrtko Ursulin
  0 siblings, 1 reply; 118+ messages in thread
From: Chris Wilson @ 2016-01-14 11:14 UTC (permalink / raw)
  To: Tvrtko Ursulin
  Cc: ankitprasad.r.sharma, intel-gfx, akash.goel, shashidhar.hiremath

On Thu, Jan 14, 2016 at 10:46:39AM +0000, Tvrtko Ursulin wrote:
> 
> On 14/01/16 10:24, Chris Wilson wrote:
> >On Thu, Jan 14, 2016 at 11:46:41AM +0530, ankitprasad.r.sharma@intel.com wrote:
> >>From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> >>
> >>Extend the drm_i915_gem_create structure to add support for
> >>creating Stolen memory backed objects. Added a new flag through
> >>which user can specify the preference to allocate the object from
> >>stolen memory, which if set, an attempt will be made to allocate
> >>the object from stolen memory subject to the availability of
> >>free space in the stolen region.
> >>
> >>v2: Rebased to the latest drm-intel-nightly (Ankit)
> >>
> >>v3: Changed versioning of GEM_CREATE param, added new comments (Tvrtko)
> >>
> >>v4: Changed size from 32b to 64b to prevent userspace overflow (Tvrtko)
> >>Corrected function arguments ordering (Chris)
> >>
> >>v5: Corrected function name (Chris)
> >>
> >>v6: Updated datatype for flags to keep sizeof(drm_i915_gem_create) u64
> >>aligned (Chris)
> >>
> >>v7: Use first 8 bits of gem_create flags for placement (Chris), Add helper
> >>function for object allocation from stolen region (Ankit)
> >>
> >>Testcase: igt/gem_stolen
> >>
> >>Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> >
> >Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> >
> >>+	/**
> >>+	 * Requested flags (currently used for placement
> >>+	 * (which memory domain))
> >>+	 *
> >>+	 * You can request that the object be created from special memory
> >>+	 * rather than regular system pages using this parameter. Such
> >>+	 * irregular objects may have certain restrictions (such as CPU
> >>+	 * access to a stolen object is verboten).
> >>+	 *
> >>+	 * This can be used in the future for other purposes too
> >>+	 * e.g. specifying tiling/caching/madvise
> >>+	 */
> >>+	__u64 flags;
> >>+#define I915_CREATE_PLACEMENT_NORMAL 	0 /* standard swappable bo  */
> >>+#define I915_CREATE_PLACEMENT_STOLEN 	1 /* Cannot use CPU mmaps */
> >
> >/* Allocate the object from memory reserved for the igfx (stolen).
> >  *
> >  * Objects allocated from stolen are restricted in the API they can use,
> >  * as direct CPU access to stolen memory is prohibited by the system.
> >  * This means that you cannot use a regular CPU mmap (either using WB
> >  * or with the WC extension). You can still use a GTT mmap, pwrite,
> >  * pread and pass it around for use by execbuffer and between processes
> >  * like normal.
> 
> What happens when a stolen batch buffer gets to relocate_entry_cpu ?

The kernel goes bang. It is easy to fix. To cover all corner cases, such
as the stolen object being larger than the mappable aperture, requires
the insert-page routines though.

> >  * Stolen memory is a very limited resource and certain functions of the
> >  * hardware can only work from within stolen memory. Userspace's
> >  * allocations may be evicted from stolen and moved to normal memory as
> >  * required. If the allocation is marked as purgeable (using madvise),
> >  * the allocation will be dropped and further access to the object's
> >  * backing storage will result in -EFAULT. Stolen objects will also be
> >  * migrated to normal memory across suspend and resume, as the stolen
> >  * memory is not preserved.
> >  *
> >  * Stolen memory is regarded as a resource placement hint, most suitable
> >  * for medium-sized buffers that are only accessed by the GPU and can be
> >  * discarded.
> >  */
> 
> Would it be better if the placement hint did not specifically
> mention stolen memory but specific limitations? Like,

It is a nice idea, but it doesn't really fit with the other placement
domains I have sketched out (they are all fully featured, or nearly so,
but exist in different pools of memory with different characteristics
and reasons for choice).
-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

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

* ✗ failure: Fi.CI.BAT
  2016-01-14  6:16 [PATCH v14 0/11] Support for creating/using Stolen memory backed objects ankitprasad.r.sharma
                   ` (10 preceding siblings ...)
  2016-01-14  6:16   ` ankitprasad.r.sharma
@ 2016-01-14 11:20 ` Patchwork
  11 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-14 11:20 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Summary ==

Built on 058740f8fced6851aeda34f366f5330322cd585f drm-intel-nightly: 2016y-01m-13d-17h-07m-44s UTC integration manifest

Test gem_pread:
        Subgroup basic:
                pass       -> FAIL       (snb-dellxps)
Test gem_pwrite:
        Subgroup basic:
                pass       -> FAIL       (snb-dellxps)
Test kms_flip:
        Subgroup basic-flip-vs-dpms:
                dmesg-warn -> PASS       (ilk-hp8440p)

bdw-ultra        total:138  pass:132  dwarn:0   dfail:0   fail:0   skip:6  
bsw-nuc-2        total:141  pass:115  dwarn:2   dfail:0   fail:0   skip:24 
hsw-brixbox      total:141  pass:134  dwarn:0   dfail:0   fail:0   skip:7  
ilk-hp8440p      total:141  pass:101  dwarn:3   dfail:0   fail:0   skip:37 
ivb-t430s        total:135  pass:122  dwarn:3   dfail:4   fail:0   skip:6  
skl-i5k-2        total:141  pass:131  dwarn:2   dfail:0   fail:0   skip:8  
skl-i7k-2        total:141  pass:131  dwarn:2   dfail:0   fail:0   skip:8  
snb-dellxps      total:141  pass:120  dwarn:5   dfail:0   fail:2   skip:14 
snb-x220t        total:141  pass:122  dwarn:5   dfail:0   fail:1   skip:13 

Results at /archive/results/CI_IGT_test/Patchwork_1182/

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

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

* Re: [PATCH 05/11] drm/i915: Support for creating Stolen memory backed objects
  2016-01-14 11:14       ` Chris Wilson
@ 2016-01-14 11:27         ` Tvrtko Ursulin
  2016-01-14 11:57           ` Chris Wilson
  0 siblings, 1 reply; 118+ messages in thread
From: Tvrtko Ursulin @ 2016-01-14 11:27 UTC (permalink / raw)
  To: Chris Wilson, ankitprasad.r.sharma, intel-gfx, akash.goel,
	shashidhar.hiremath


On 14/01/16 11:14, Chris Wilson wrote:
> On Thu, Jan 14, 2016 at 10:46:39AM +0000, Tvrtko Ursulin wrote:
>>
>> On 14/01/16 10:24, Chris Wilson wrote:
>>> On Thu, Jan 14, 2016 at 11:46:41AM +0530, ankitprasad.r.sharma@intel.com wrote:
>>>> From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
>>>>
>>>> Extend the drm_i915_gem_create structure to add support for
>>>> creating Stolen memory backed objects. Added a new flag through
>>>> which user can specify the preference to allocate the object from
>>>> stolen memory, which if set, an attempt will be made to allocate
>>>> the object from stolen memory subject to the availability of
>>>> free space in the stolen region.
>>>>
>>>> v2: Rebased to the latest drm-intel-nightly (Ankit)
>>>>
>>>> v3: Changed versioning of GEM_CREATE param, added new comments (Tvrtko)
>>>>
>>>> v4: Changed size from 32b to 64b to prevent userspace overflow (Tvrtko)
>>>> Corrected function arguments ordering (Chris)
>>>>
>>>> v5: Corrected function name (Chris)
>>>>
>>>> v6: Updated datatype for flags to keep sizeof(drm_i915_gem_create) u64
>>>> aligned (Chris)
>>>>
>>>> v7: Use first 8 bits of gem_create flags for placement (Chris), Add helper
>>>> function for object allocation from stolen region (Ankit)
>>>>
>>>> Testcase: igt/gem_stolen
>>>>
>>>> Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
>>>
>>> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
>>>
>>>> +	/**
>>>> +	 * Requested flags (currently used for placement
>>>> +	 * (which memory domain))
>>>> +	 *
>>>> +	 * You can request that the object be created from special memory
>>>> +	 * rather than regular system pages using this parameter. Such
>>>> +	 * irregular objects may have certain restrictions (such as CPU
>>>> +	 * access to a stolen object is verboten).
>>>> +	 *
>>>> +	 * This can be used in the future for other purposes too
>>>> +	 * e.g. specifying tiling/caching/madvise
>>>> +	 */
>>>> +	__u64 flags;
>>>> +#define I915_CREATE_PLACEMENT_NORMAL 	0 /* standard swappable bo  */
>>>> +#define I915_CREATE_PLACEMENT_STOLEN 	1 /* Cannot use CPU mmaps */
>>>
>>> /* Allocate the object from memory reserved for the igfx (stolen).
>>>   *
>>>   * Objects allocated from stolen are restricted in the API they can use,
>>>   * as direct CPU access to stolen memory is prohibited by the system.
>>>   * This means that you cannot use a regular CPU mmap (either using WB
>>>   * or with the WC extension). You can still use a GTT mmap, pwrite,
>>>   * pread and pass it around for use by execbuffer and between processes
>>>   * like normal.
>>
>> What happens when a stolen batch buffer gets to relocate_entry_cpu ?
>
> The kernel goes bang. It is easy to fix. To cover all corner cases, such
> as the stolen object being larger than the mappable aperture, requires
> the insert-page routines though.

I know, I keep pointing it out. :/

>>>   * Stolen memory is a very limited resource and certain functions of the
>>>   * hardware can only work from within stolen memory. Userspace's
>>>   * allocations may be evicted from stolen and moved to normal memory as
>>>   * required. If the allocation is marked as purgeable (using madvise),
>>>   * the allocation will be dropped and further access to the object's
>>>   * backing storage will result in -EFAULT. Stolen objects will also be
>>>   * migrated to normal memory across suspend and resume, as the stolen
>>>   * memory is not preserved.
>>>   *
>>>   * Stolen memory is regarded as a resource placement hint, most suitable
>>>   * for medium-sized buffers that are only accessed by the GPU and can be
>>>   * discarded.
>>>   */
>>
>> Would it be better if the placement hint did not specifically
>> mention stolen memory but specific limitations? Like,
>
> It is a nice idea, but it doesn't really fit with the other placement
> domains I have sketched out (they are all fully featured, or nearly so,
> but exist in different pools of memory with different characteristics
> and reasons for choice).

Perhaps these pools have some characteristics which could be described 
abstractly? I am of course coming back to why would userspace have to 
know about stolen, why would we fail object creation if there is no 
space, and then move objects out of stolen on hibernate and never put 
them back. Sounds like a bad and inflexible interface, and a lying 
kernel to me.

Regards,

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

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

* Re: [PATCH 05/11] drm/i915: Support for creating Stolen memory backed objects
  2016-01-14 11:27         ` Tvrtko Ursulin
@ 2016-01-14 11:57           ` Chris Wilson
  0 siblings, 0 replies; 118+ messages in thread
From: Chris Wilson @ 2016-01-14 11:57 UTC (permalink / raw)
  To: Tvrtko Ursulin
  Cc: ankitprasad.r.sharma, intel-gfx, akash.goel, shashidhar.hiremath

On Thu, Jan 14, 2016 at 11:27:42AM +0000, Tvrtko Ursulin wrote:
> 
> On 14/01/16 11:14, Chris Wilson wrote:
> >On Thu, Jan 14, 2016 at 10:46:39AM +0000, Tvrtko Ursulin wrote:
> >>
> >>On 14/01/16 10:24, Chris Wilson wrote:
> >>>  * Stolen memory is a very limited resource and certain functions of the
> >>>  * hardware can only work from within stolen memory. Userspace's
> >>>  * allocations may be evicted from stolen and moved to normal memory as
> >>>  * required. If the allocation is marked as purgeable (using madvise),
> >>>  * the allocation will be dropped and further access to the object's
> >>>  * backing storage will result in -EFAULT. Stolen objects will also be
> >>>  * migrated to normal memory across suspend and resume, as the stolen
> >>>  * memory is not preserved.
> >>>  *
> >>>  * Stolen memory is regarded as a resource placement hint, most suitable
> >>>  * for medium-sized buffers that are only accessed by the GPU and can be
> >>>  * discarded.
> >>>  */
> >>
> >>Would it be better if the placement hint did not specifically
> >>mention stolen memory but specific limitations? Like,
> >
> >It is a nice idea, but it doesn't really fit with the other placement
> >domains I have sketched out (they are all fully featured, or nearly so,
> >but exist in different pools of memory with different characteristics
> >and reasons for choice).
> 
> Perhaps these pools have some characteristics which could be
> described abstractly? I am of course coming back to why would
> userspace have to know about stolen, why would we fail object
> creation if there is no space, and then move objects out of stolen
> on hibernate and never put them back. Sounds like a bad and
> inflexible interface, and a lying kernel to me.

I agree that migrating and failing because of not enough space is nasty.
I was tempted to suggest we allow stolen to fallback to normal during
creation. (But ABI is tricky, and I think we've got way past the point
where this series is ready, we're down to stray lines and choosing a
colour for the kettle.)

The choice is whether we disable powersaving because userspace allocated
a ton of vertex buffers in stolen, or if we just tell them to get lost
and take back our memory. It's a two-level priority eviction pass at the
moment, kernel vs userspace. We could extend that to several
classes/priorites (anything that maps to an unsigned long), but then we
need to define a policy of whether some levels are privileged etc.
(Overengineering until someone discovers that the kernel kicking their
objects out to enable FBC actually causes regression.)

Some of the abstraction is nice, but I feel that it makes for sloppy
uAPI, and a hindrance to letting userspace decide what it wants. With
complex questions of "where should I allocate this buffer", the answer
has always been to push that as close to the real decision maker as
possible. Making the choice in the kernel, smacks of policy. The
mechanism would be to let userspace know the details and make a choice.
(All the kernel should have to do is make sure userspace doesn't stomp
on each other.)

The question is whether the important API detail is the placement, or the
first/second class nature of the object interface. I favour selecting
placement.
-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

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

* Re: [PATCH 01/11] drm/i915: Add support for mapping an object page by page
  2016-01-14 10:32   ` Tvrtko Ursulin
@ 2016-01-14 13:34     ` Chris Wilson
  2016-01-15  9:53       ` Tvrtko Ursulin
  0 siblings, 1 reply; 118+ messages in thread
From: Chris Wilson @ 2016-01-14 13:34 UTC (permalink / raw)
  To: Tvrtko Ursulin
  Cc: ankitprasad.r.sharma, intel-gfx, akash.goel, shashidhar.hiremath

On Thu, Jan 14, 2016 at 10:32:11AM +0000, Tvrtko Ursulin wrote:
> >diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h
> >index b448ad8..5f86596 100644
> >--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> >+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> >@@ -317,6 +317,11 @@ struct i915_address_space {
> >  			    uint64_t start,
> >  			    uint64_t length,
> >  			    bool use_scratch);
> >+	void (*insert_page)(struct i915_address_space *vm,
> >+			    dma_addr_t addr,
> >+			    uint64_t offset,
> >+			    enum i915_cache_level cache_level,
> >+			    u32 flags);
> >  	void (*insert_entries)(struct i915_address_space *vm,
> >  			       struct sg_table *st,
> >  			       uint64_t start,
> 
> Why not extend the current API to support start page offset and
> number of pages? Could default to full object like today if zero.
> Eg:
> 
>  void (*insert_entries)(struct i915_address_space *vm,
> 			struct sg_table *st,
> +			unsigned page_offset,
> +			unsigned num_pages,

Ouch. That would be quite slow for the insert_page() use case of
page-by-page looping.

> 			uint64_t start,
> 			enum i915_cache_level cache_level,
> 			u32 flags);
> 
> That way we would not have two functions for effectively the same
> thing operating on different type of input parameters.
>
> If extending insert_entries is not preferable, then still we could
> add another compatible one, like insert_entries_range or something,
> and then both could share the same underlying implementation for
> less code.
> 
> Like this, this patch already does not match current codebase - see
> assert_rpm_atomic_begin in insert_entries.
> 
> Also if API between the two was compatible there would be no need
> for i915_gem_object_get_dma_address() and i915_gem_object_get_page()
> could be used instead.

The point was to write a lowlevel analog to provide a complementary API
to insert_entries that could be used for everywhere the we wanted to peek
through the GTT without even touching an object, i.e. for cases where we
might allocate a scratch page and temporarily put it into the GTT.
-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

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

* Re: [PATCH 01/11] drm/i915: Add support for mapping an object page by page
  2016-01-14 13:34     ` Chris Wilson
@ 2016-01-15  9:53       ` Tvrtko Ursulin
  2016-01-15 11:44         ` Chris Wilson
  0 siblings, 1 reply; 118+ messages in thread
From: Tvrtko Ursulin @ 2016-01-15  9:53 UTC (permalink / raw)
  To: Chris Wilson, ankitprasad.r.sharma, intel-gfx, akash.goel,
	shashidhar.hiremath


On 14/01/16 13:34, Chris Wilson wrote:
> On Thu, Jan 14, 2016 at 10:32:11AM +0000, Tvrtko Ursulin wrote:
>>> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h
>>> index b448ad8..5f86596 100644
>>> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
>>> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
>>> @@ -317,6 +317,11 @@ struct i915_address_space {
>>>   			    uint64_t start,
>>>   			    uint64_t length,
>>>   			    bool use_scratch);
>>> +	void (*insert_page)(struct i915_address_space *vm,
>>> +			    dma_addr_t addr,
>>> +			    uint64_t offset,
>>> +			    enum i915_cache_level cache_level,
>>> +			    u32 flags);
>>>   	void (*insert_entries)(struct i915_address_space *vm,
>>>   			       struct sg_table *st,
>>>   			       uint64_t start,
>>
>> Why not extend the current API to support start page offset and
>> number of pages? Could default to full object like today if zero.
>> Eg:
>>
>>   void (*insert_entries)(struct i915_address_space *vm,
>> 			struct sg_table *st,
>> +			unsigned page_offset,
>> +			unsigned num_pages,
>
> Ouch. That would be quite slow for the insert_page() use case of
> page-by-page looping.

It could use the same last page caching trick so why would be be so slow?

>> 			uint64_t start,
>> 			enum i915_cache_level cache_level,
>> 			u32 flags);
>>
>> That way we would not have two functions for effectively the same
>> thing operating on different type of input parameters.
>>
>> If extending insert_entries is not preferable, then still we could
>> add another compatible one, like insert_entries_range or something,
>> and then both could share the same underlying implementation for
>> less code.
>>
>> Like this, this patch already does not match current codebase - see
>> assert_rpm_atomic_begin in insert_entries.
>>
>> Also if API between the two was compatible there would be no need
>> for i915_gem_object_get_dma_address() and i915_gem_object_get_page()
>> could be used instead.
>
> The point was to write a lowlevel analog to provide a complementary API
> to insert_entries that could be used for everywhere the we wanted to peek
> through the GTT without even touching an object, i.e. for cases where we
> might allocate a scratch page and temporarily put it into the GTT.

Well maybe it is not that bad on the API front, but code duplication 
would still not be my first choice, as demonstrated by the divergence 
which already happened. Need to think about it some more.

Regards,

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

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

* Re: [PATCH 01/11] drm/i915: Add support for mapping an object page by page
  2016-01-15  9:53       ` Tvrtko Ursulin
@ 2016-01-15 11:44         ` Chris Wilson
  2016-01-15 15:15           ` Tvrtko Ursulin
  0 siblings, 1 reply; 118+ messages in thread
From: Chris Wilson @ 2016-01-15 11:44 UTC (permalink / raw)
  To: Tvrtko Ursulin
  Cc: ankitprasad.r.sharma, intel-gfx, akash.goel, shashidhar.hiremath

On Fri, Jan 15, 2016 at 09:53:46AM +0000, Tvrtko Ursulin wrote:
> 
> On 14/01/16 13:34, Chris Wilson wrote:
> >On Thu, Jan 14, 2016 at 10:32:11AM +0000, Tvrtko Ursulin wrote:
> >>>diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h
> >>>index b448ad8..5f86596 100644
> >>>--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> >>>+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> >>>@@ -317,6 +317,11 @@ struct i915_address_space {
> >>>  			    uint64_t start,
> >>>  			    uint64_t length,
> >>>  			    bool use_scratch);
> >>>+	void (*insert_page)(struct i915_address_space *vm,
> >>>+			    dma_addr_t addr,
> >>>+			    uint64_t offset,
> >>>+			    enum i915_cache_level cache_level,
> >>>+			    u32 flags);
> >>>  	void (*insert_entries)(struct i915_address_space *vm,
> >>>  			       struct sg_table *st,
> >>>  			       uint64_t start,
> >>
> >>Why not extend the current API to support start page offset and
> >>number of pages? Could default to full object like today if zero.
> >>Eg:
> >>
> >>  void (*insert_entries)(struct i915_address_space *vm,
> >>			struct sg_table *st,
> >>+			unsigned page_offset,
> >>+			unsigned num_pages,
> >
> >Ouch. That would be quite slow for the insert_page() use case of
> >page-by-page looping.
> 
> It could use the same last page caching trick so why would be be so slow?

We don't have the convenient struct? I presumed you were thinking of
passing the offset through to sg_page_iter

for_each_sg_page(st->sgl, &sg_iter, st->nents, page_offset) {
	if (--num_pages)
		break;
	
	/* original pt insertion code */
}

Is it worth expanding struct sg_table for this shortcut?

There are some games where we spend more time in sg_page_iter_next() than
anything else in the kernel. The games have more textures than GTT
space, they aren't playable right now nor will they ever likely to be. :(
Improving these loops would definitely be a boon nevertheless.
-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

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

* Re: [PATCH 10/11] acpi: Export acpi_bus_type
  2016-01-14  6:16   ` ankitprasad.r.sharma
  (?)
@ 2016-01-15 14:51   ` Rafael J. Wysocki
  2016-01-18  9:01       ` Ankitprasad Sharma
  -1 siblings, 1 reply; 118+ messages in thread
From: Rafael J. Wysocki @ 2016-01-15 14:51 UTC (permalink / raw)
  To: ankitprasad.r.sharma
  Cc: intel-gfx, akash.goel, shashidhar.hiremath, tvrtko.ursulin,
	Len Brown, linux-acpi, linux-kernel

On Thursday, January 14, 2016 11:46:46 AM ankitprasad.r.sharma@intel.com wrote:
> From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> 
> Some modules, like i915.ko, needs to detect when certain ACPI features
> are active inorder to prevent corruption on contended resources.
> In particular, use of BIOS RapidStart Technology may corrupt the contents
> of the reserved graphics memory, due to unalarmed hibernation. In which
> case i915.ko cannot assume that it (reserved gfx memory) remains
> unmodified and must recreate teh contents and importantly not use it to
> store unrecoverable user data.
> 
> Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Len Brown <lenb@kernel.org>
> Cc: linux-acpi@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  drivers/acpi/bus.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> index a212cef..69509c7 100644
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -814,6 +814,7 @@ struct bus_type acpi_bus_type = {
>  	.remove		= acpi_device_remove,
>  	.uevent		= acpi_device_uevent,
>  };
> +EXPORT_SYMBOL_GPL(acpi_bus_type);
>  
>  /* --------------------------------------------------------------------------
>                               Initialization/Cleanup
> 

No.

I see no reason whatsoever for doing this.

Thanks,
Rafael

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

* Re: [PATCH 01/11] drm/i915: Add support for mapping an object page by page
  2016-01-15 11:44         ` Chris Wilson
@ 2016-01-15 15:15           ` Tvrtko Ursulin
  0 siblings, 0 replies; 118+ messages in thread
From: Tvrtko Ursulin @ 2016-01-15 15:15 UTC (permalink / raw)
  To: Chris Wilson, ankitprasad.r.sharma, intel-gfx, akash.goel,
	shashidhar.hiremath


On 15/01/16 11:44, Chris Wilson wrote:
> On Fri, Jan 15, 2016 at 09:53:46AM +0000, Tvrtko Ursulin wrote:
>>
>> On 14/01/16 13:34, Chris Wilson wrote:
>>> On Thu, Jan 14, 2016 at 10:32:11AM +0000, Tvrtko Ursulin wrote:
>>>>> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h
>>>>> index b448ad8..5f86596 100644
>>>>> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
>>>>> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
>>>>> @@ -317,6 +317,11 @@ struct i915_address_space {
>>>>>   			    uint64_t start,
>>>>>   			    uint64_t length,
>>>>>   			    bool use_scratch);
>>>>> +	void (*insert_page)(struct i915_address_space *vm,
>>>>> +			    dma_addr_t addr,
>>>>> +			    uint64_t offset,
>>>>> +			    enum i915_cache_level cache_level,
>>>>> +			    u32 flags);
>>>>>   	void (*insert_entries)(struct i915_address_space *vm,
>>>>>   			       struct sg_table *st,
>>>>>   			       uint64_t start,
>>>>
>>>> Why not extend the current API to support start page offset and
>>>> number of pages? Could default to full object like today if zero.
>>>> Eg:
>>>>
>>>>   void (*insert_entries)(struct i915_address_space *vm,
>>>> 			struct sg_table *st,
>>>> +			unsigned page_offset,
>>>> +			unsigned num_pages,
>>>
>>> Ouch. That would be quite slow for the insert_page() use case of
>>> page-by-page looping.
>>
>> It could use the same last page caching trick so why would be be so slow?
>
> We don't have the convenient struct? I presumed you were thinking of
> passing the offset through to sg_page_iter
>
> for_each_sg_page(st->sgl, &sg_iter, st->nents, page_offset) {
> 	if (--num_pages)
> 		break;
> 	
> 	/* original pt insertion code */
> }
>
> Is it worth expanding struct sg_table for this shortcut?
>
> There are some games where we spend more time in sg_page_iter_next() than
> anything else in the kernel. The games have more textures than GTT
> space, they aren't playable right now nor will they ever likely to be. :(
> Improving these loops would definitely be a boon nevertheless.

Okay, dead end, mission abort. :)

Ankit please just sync the patch in next respin with the RPM changes 
which happened in the meantime.

Regards,

Tvrtko


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

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

* Re: [PATCH 10/11] acpi: Export acpi_bus_type
  2016-01-15 14:51   ` Rafael J. Wysocki
@ 2016-01-18  9:01       ` Ankitprasad Sharma
  0 siblings, 0 replies; 118+ messages in thread
From: Ankitprasad Sharma @ 2016-01-18  9:01 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: intel-gfx, shashidhar.hiremath, linux-kernel, linux-acpi,
	akash.goel, Len Brown

On Fri, 2016-01-15 at 15:51 +0100, Rafael J. Wysocki wrote:
> On Thursday, January 14, 2016 11:46:46 AM ankitprasad.r.sharma@intel.com wrote:
> > From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> > 
> > Some modules, like i915.ko, needs to detect when certain ACPI features
> > are active inorder to prevent corruption on contended resources.
> > In particular, use of BIOS RapidStart Technology may corrupt the contents
> > of the reserved graphics memory, due to unalarmed hibernation. In which
> > case i915.ko cannot assume that it (reserved gfx memory) remains
> > unmodified and must recreate teh contents and importantly not use it to
> > store unrecoverable user data.
> > 
> > Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> > Cc: Len Brown <lenb@kernel.org>
> > Cc: linux-acpi@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > ---
> >  drivers/acpi/bus.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> > index a212cef..69509c7 100644
> > --- a/drivers/acpi/bus.c
> > +++ b/drivers/acpi/bus.c
> > @@ -814,6 +814,7 @@ struct bus_type acpi_bus_type = {
> >  	.remove		= acpi_device_remove,
> >  	.uevent		= acpi_device_uevent,
> >  };
> > +EXPORT_SYMBOL_GPL(acpi_bus_type);
> >  
> >  /* --------------------------------------------------------------------------
> >                               Initialization/Cleanup
> > 
> 
> No.
> 
> I see no reason whatsoever for doing this.
> 
> Thanks,
> Rafael
Hi Rafael,

Thanks for the response.

Can you please help me with, how to detect the presence of a certain
acpi device using its id (for example, INT3392 for Intel RST device)? 

As you might have seen (in the next patch in this series), that we use
this symbol (acpi_bus_type) to iterate over all the devices registered
on acpi bus, to check if there is a device with id INT3392 present or
not.

Thanks,
Ankit

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

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

* Re: [PATCH 10/11] acpi: Export acpi_bus_type
@ 2016-01-18  9:01       ` Ankitprasad Sharma
  0 siblings, 0 replies; 118+ messages in thread
From: Ankitprasad Sharma @ 2016-01-18  9:01 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: intel-gfx, akash.goel, shashidhar.hiremath, tvrtko.ursulin,
	Len Brown, linux-acpi, linux-kernel

On Fri, 2016-01-15 at 15:51 +0100, Rafael J. Wysocki wrote:
> On Thursday, January 14, 2016 11:46:46 AM ankitprasad.r.sharma@intel.com wrote:
> > From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> > 
> > Some modules, like i915.ko, needs to detect when certain ACPI features
> > are active inorder to prevent corruption on contended resources.
> > In particular, use of BIOS RapidStart Technology may corrupt the contents
> > of the reserved graphics memory, due to unalarmed hibernation. In which
> > case i915.ko cannot assume that it (reserved gfx memory) remains
> > unmodified and must recreate teh contents and importantly not use it to
> > store unrecoverable user data.
> > 
> > Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> > Cc: Len Brown <lenb@kernel.org>
> > Cc: linux-acpi@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > ---
> >  drivers/acpi/bus.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> > index a212cef..69509c7 100644
> > --- a/drivers/acpi/bus.c
> > +++ b/drivers/acpi/bus.c
> > @@ -814,6 +814,7 @@ struct bus_type acpi_bus_type = {
> >  	.remove		= acpi_device_remove,
> >  	.uevent		= acpi_device_uevent,
> >  };
> > +EXPORT_SYMBOL_GPL(acpi_bus_type);
> >  
> >  /* --------------------------------------------------------------------------
> >                               Initialization/Cleanup
> > 
> 
> No.
> 
> I see no reason whatsoever for doing this.
> 
> Thanks,
> Rafael
Hi Rafael,

Thanks for the response.

Can you please help me with, how to detect the presence of a certain
acpi device using its id (for example, INT3392 for Intel RST device)? 

As you might have seen (in the next patch in this series), that we use
this symbol (acpi_bus_type) to iterate over all the devices registered
on acpi bus, to check if there is a device with id INT3392 present or
not.

Thanks,
Ankit

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

* Re: [PATCH 10/11] acpi: Export acpi_bus_type
  2016-01-18  9:01       ` Ankitprasad Sharma
  (?)
@ 2016-01-18 14:57       ` Rafael J. Wysocki
  2016-01-18 18:26         ` Lukas Wunner
  2016-01-18 22:28         ` Rafael J. Wysocki
  -1 siblings, 2 replies; 118+ messages in thread
From: Rafael J. Wysocki @ 2016-01-18 14:57 UTC (permalink / raw)
  To: Ankitprasad Sharma
  Cc: intel-gfx, akash.goel, shashidhar.hiremath, tvrtko.ursulin,
	Len Brown, linux-acpi, linux-kernel

On Monday, January 18, 2016 02:31:00 PM Ankitprasad Sharma wrote:
> On Fri, 2016-01-15 at 15:51 +0100, Rafael J. Wysocki wrote:
> > On Thursday, January 14, 2016 11:46:46 AM ankitprasad.r.sharma@intel.com wrote:
> > > From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> > > 
> > > Some modules, like i915.ko, needs to detect when certain ACPI features
> > > are active inorder to prevent corruption on contended resources.
> > > In particular, use of BIOS RapidStart Technology may corrupt the contents
> > > of the reserved graphics memory, due to unalarmed hibernation. In which
> > > case i915.ko cannot assume that it (reserved gfx memory) remains
> > > unmodified and must recreate teh contents and importantly not use it to
> > > store unrecoverable user data.
> > > 
> > > Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> > > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> > > Cc: Len Brown <lenb@kernel.org>
> > > Cc: linux-acpi@vger.kernel.org
> > > Cc: linux-kernel@vger.kernel.org
> > > ---
> > >  drivers/acpi/bus.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> > > index a212cef..69509c7 100644
> > > --- a/drivers/acpi/bus.c
> > > +++ b/drivers/acpi/bus.c
> > > @@ -814,6 +814,7 @@ struct bus_type acpi_bus_type = {
> > >  	.remove		= acpi_device_remove,
> > >  	.uevent		= acpi_device_uevent,
> > >  };
> > > +EXPORT_SYMBOL_GPL(acpi_bus_type);
> > >  
> > >  /* --------------------------------------------------------------------------
> > >                               Initialization/Cleanup
> > > 
> > 
> > No.
> > 
> > I see no reason whatsoever for doing this.
> > 
> > Thanks,
> > Rafael
> Hi Rafael,
> 
> Thanks for the response.
> 
> Can you please help me with, how to detect the presence of a certain
> acpi device using its id (for example, INT3392 for Intel RST device)? 

If you want to check if the device ir present at all, you cen use
acpi_device_is_present() introduced recently (although that would need
to be exported if you want to use it from a driver).

> As you might have seen (in the next patch in this series), that we use
> this symbol (acpi_bus_type) to iterate over all the devices registered
> on acpi bus, to check if there is a device with id INT3392 present or
> not.

Please don't do that this way.

I'll have a look at the other patch later.

Thanks,
Rafael


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

* Re: [PATCH 10/11] acpi: Export acpi_bus_type
  2016-01-18 14:57       ` Rafael J. Wysocki
@ 2016-01-18 18:26         ` Lukas Wunner
  2016-01-19  8:15           ` Ankitprasad Sharma
  2016-01-18 22:28         ` Rafael J. Wysocki
  1 sibling, 1 reply; 118+ messages in thread
From: Lukas Wunner @ 2016-01-18 18:26 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Ankitprasad Sharma, intel-gfx, akash.goel, shashidhar.hiremath,
	tvrtko.ursulin, Len Brown, linux-acpi, linux-kernel

Hi,

On Mon, Jan 18, 2016 at 03:57:29PM +0100, Rafael J. Wysocki wrote:
> On Monday, January 18, 2016 02:31:00 PM Ankitprasad Sharma wrote:
> > On Fri, 2016-01-15 at 15:51 +0100, Rafael J. Wysocki wrote:
> > > On Thursday, January 14, 2016 11:46:46 AM ankitprasad.r.sharma@intel.com wrote:
> > > > From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> > > > 
> > > > Some modules, like i915.ko, needs to detect when certain ACPI features
> > > > are active inorder to prevent corruption on contended resources.
> > > > In particular, use of BIOS RapidStart Technology may corrupt the contents
> > > > of the reserved graphics memory, due to unalarmed hibernation. In which
> > > > case i915.ko cannot assume that it (reserved gfx memory) remains
> > > > unmodified and must recreate teh contents and importantly not use it to
> > > > store unrecoverable user data.
> > > > 
> > > > Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> > > > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> > > > Cc: Len Brown <lenb@kernel.org>
> > > > Cc: linux-acpi@vger.kernel.org
> > > > Cc: linux-kernel@vger.kernel.org
> > > > ---
> > > >  drivers/acpi/bus.c | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > > 
> > > > diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> > > > index a212cef..69509c7 100644
> > > > --- a/drivers/acpi/bus.c
> > > > +++ b/drivers/acpi/bus.c
> > > > @@ -814,6 +814,7 @@ struct bus_type acpi_bus_type = {
> > > >  	.remove		= acpi_device_remove,
> > > >  	.uevent		= acpi_device_uevent,
> > > >  };
> > > > +EXPORT_SYMBOL_GPL(acpi_bus_type);
> > > >  
> > > >  /* --------------------------------------------------------------------------
> > > >                               Initialization/Cleanup
> > > > 
> > > 
> > > No.
> > > 
> > > I see no reason whatsoever for doing this.
> > > 
> > > Thanks,
> > > Rafael
> > Hi Rafael,
> > 
> > Thanks for the response.
> > 
> > Can you please help me with, how to detect the presence of a certain
> > acpi device using its id (for example, INT3392 for Intel RST device)? 
> 
> If you want to check if the device ir present at all, you cen use
> acpi_device_is_present() introduced recently (although that would need
> to be exported if you want to use it from a driver).

acpi_dev_present() is exported, so can be used in drivers just fine:
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=2d12b6b381ba059d5f92798f5ea739672a2f5fcf


> > As you might have seen (in the next patch in this series), that we use
> > this symbol (acpi_bus_type) to iterate over all the devices registered
> > on acpi bus, to check if there is a device with id INT3392 present or
> > not.

Ankitprasad, just change your patch [11/11] thusly:

-       if (intel_detect_acpi_rst()) {
+       if (acpi_dev_present("INT3392")) {


Using bus_for_each_dev() was the wrong approach, most drivers call
acpi_get_devices() to detect the presence of a particular HID,
however that necessitates the definition of a callback in each driver,
leading to lots of duplicate code. Hence the introduction of
acpi_dev_present() which is also faster because it just iterates over
a list instead of walking the namespace.

This new API landed in Linus' tree last Tuesday (PST), so you need
to merge Linus' tree back into yours or wait until it gets merged
into drm-intel-nightly.

Best regards,

Lukas

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

* Re: [PATCH 10/11] acpi: Export acpi_bus_type
  2016-01-18 14:57       ` Rafael J. Wysocki
  2016-01-18 18:26         ` Lukas Wunner
@ 2016-01-18 22:28         ` Rafael J. Wysocki
  2016-01-18 22:39           ` Lukas Wunner
  1 sibling, 1 reply; 118+ messages in thread
From: Rafael J. Wysocki @ 2016-01-18 22:28 UTC (permalink / raw)
  To: Ankitprasad Sharma
  Cc: intel-gfx, akash.goel, shashidhar.hiremath, tvrtko.ursulin,
	Len Brown, linux-acpi, linux-kernel, Lukas Wunner

On Monday, January 18, 2016 03:57:29 PM Rafael J. Wysocki wrote:
> On Monday, January 18, 2016 02:31:00 PM Ankitprasad Sharma wrote:
> > On Fri, 2016-01-15 at 15:51 +0100, Rafael J. Wysocki wrote:
> > > On Thursday, January 14, 2016 11:46:46 AM ankitprasad.r.sharma@intel.com wrote:
> > > > From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> > > > 
> > > > Some modules, like i915.ko, needs to detect when certain ACPI features
> > > > are active inorder to prevent corruption on contended resources.
> > > > In particular, use of BIOS RapidStart Technology may corrupt the contents
> > > > of the reserved graphics memory, due to unalarmed hibernation. In which
> > > > case i915.ko cannot assume that it (reserved gfx memory) remains
> > > > unmodified and must recreate teh contents and importantly not use it to
> > > > store unrecoverable user data.
> > > > 
> > > > Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> > > > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> > > > Cc: Len Brown <lenb@kernel.org>
> > > > Cc: linux-acpi@vger.kernel.org
> > > > Cc: linux-kernel@vger.kernel.org
> > > > ---
> > > >  drivers/acpi/bus.c | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > > 
> > > > diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> > > > index a212cef..69509c7 100644
> > > > --- a/drivers/acpi/bus.c
> > > > +++ b/drivers/acpi/bus.c
> > > > @@ -814,6 +814,7 @@ struct bus_type acpi_bus_type = {
> > > >  	.remove		= acpi_device_remove,
> > > >  	.uevent		= acpi_device_uevent,
> > > >  };
> > > > +EXPORT_SYMBOL_GPL(acpi_bus_type);
> > > >  
> > > >  /* --------------------------------------------------------------------------
> > > >                               Initialization/Cleanup
> > > > 
> > > 
> > > No.
> > > 
> > > I see no reason whatsoever for doing this.
> > > 
> > > Thanks,
> > > Rafael
> > Hi Rafael,
> > 
> > Thanks for the response.
> > 
> > Can you please help me with, how to detect the presence of a certain
> > acpi device using its id (for example, INT3392 for Intel RST device)? 
> 
> If you want to check if the device ir present at all, you cen use
> acpi_device_is_present() introduced recently (although that would need
> to be exported if you want to use it from a driver).

I meant acpi_dev_present(), sorry about the mistake.

I guess we should rename it to acpi_device_found() or something similar
to avoid such confusion in the future.

Thanks,
Rafael


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

* Re: [PATCH 10/11] acpi: Export acpi_bus_type
  2016-01-18 22:28         ` Rafael J. Wysocki
@ 2016-01-18 22:39           ` Lukas Wunner
  2016-01-18 22:46             ` Rafael J. Wysocki
  0 siblings, 1 reply; 118+ messages in thread
From: Lukas Wunner @ 2016-01-18 22:39 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Ankitprasad Sharma, intel-gfx, akash.goel, shashidhar.hiremath,
	tvrtko.ursulin, Len Brown, linux-acpi, linux-kernel

Hi,

On Mon, Jan 18, 2016 at 11:28:27PM +0100, Rafael J. Wysocki wrote:
> On Monday, January 18, 2016 03:57:29 PM Rafael J. Wysocki wrote:
> > On Monday, January 18, 2016 02:31:00 PM Ankitprasad Sharma wrote:
> > > On Fri, 2016-01-15 at 15:51 +0100, Rafael J. Wysocki wrote:
> > > > On Thursday, January 14, 2016 11:46:46 AM ankitprasad.r.sharma@intel.com wrote:
> > > > > From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> > > > > 
> > > > > Some modules, like i915.ko, needs to detect when certain ACPI features
> > > > > are active inorder to prevent corruption on contended resources.
> > > > > In particular, use of BIOS RapidStart Technology may corrupt the contents
> > > > > of the reserved graphics memory, due to unalarmed hibernation. In which
> > > > > case i915.ko cannot assume that it (reserved gfx memory) remains
> > > > > unmodified and must recreate teh contents and importantly not use it to
> > > > > store unrecoverable user data.
> > > > > 
> > > > > Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> > > > > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> > > > > Cc: Len Brown <lenb@kernel.org>
> > > > > Cc: linux-acpi@vger.kernel.org
> > > > > Cc: linux-kernel@vger.kernel.org
> > > > > ---
> > > > >  drivers/acpi/bus.c | 1 +
> > > > >  1 file changed, 1 insertion(+)
> > > > > 
> > > > > diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> > > > > index a212cef..69509c7 100644
> > > > > --- a/drivers/acpi/bus.c
> > > > > +++ b/drivers/acpi/bus.c
> > > > > @@ -814,6 +814,7 @@ struct bus_type acpi_bus_type = {
> > > > >  	.remove		= acpi_device_remove,
> > > > >  	.uevent		= acpi_device_uevent,
> > > > >  };
> > > > > +EXPORT_SYMBOL_GPL(acpi_bus_type);
> > > > >  
> > > > >  /* --------------------------------------------------------------------------
> > > > >                               Initialization/Cleanup
> > > > > 
> > > > 
> > > > No.
> > > > 
> > > > I see no reason whatsoever for doing this.
> > > > 
> > > > Thanks,
> > > > Rafael
> > > Hi Rafael,
> > > 
> > > Thanks for the response.
> > > 
> > > Can you please help me with, how to detect the presence of a certain
> > > acpi device using its id (for example, INT3392 for Intel RST device)? 
> > 
> > If you want to check if the device ir present at all, you cen use
> > acpi_device_is_present() introduced recently (although that would need
> > to be exported if you want to use it from a driver).
> 
> I meant acpi_dev_present(), sorry about the mistake.
> 
> I guess we should rename it to acpi_device_found() or something similar
> to avoid such confusion in the future.

The name was chosen because the PCI equivalent is called pci_dev_present()
and I assumed that name already stuck in developers' heads, so if they're
looking for an ACPI presence detection function, that's what they'd look
for first.

Best regards,

Lukas

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

* Re: [PATCH 10/11] acpi: Export acpi_bus_type
  2016-01-18 22:39           ` Lukas Wunner
@ 2016-01-18 22:46             ` Rafael J. Wysocki
  2016-01-18 23:00                 ` Lukas Wunner
  0 siblings, 1 reply; 118+ messages in thread
From: Rafael J. Wysocki @ 2016-01-18 22:46 UTC (permalink / raw)
  To: Lukas Wunner
  Cc: Ankitprasad Sharma, intel-gfx, akash.goel, shashidhar.hiremath,
	tvrtko.ursulin, Len Brown, linux-acpi, linux-kernel

On Monday, January 18, 2016 11:39:07 PM Lukas Wunner wrote:
> Hi,
> 
> On Mon, Jan 18, 2016 at 11:28:27PM +0100, Rafael J. Wysocki wrote:
> > On Monday, January 18, 2016 03:57:29 PM Rafael J. Wysocki wrote:
> > > On Monday, January 18, 2016 02:31:00 PM Ankitprasad Sharma wrote:
> > > > On Fri, 2016-01-15 at 15:51 +0100, Rafael J. Wysocki wrote:
> > > > > On Thursday, January 14, 2016 11:46:46 AM ankitprasad.r.sharma@intel.com wrote:
> > > > > > From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> > > > > > 
> > > > > > Some modules, like i915.ko, needs to detect when certain ACPI features
> > > > > > are active inorder to prevent corruption on contended resources.
> > > > > > In particular, use of BIOS RapidStart Technology may corrupt the contents
> > > > > > of the reserved graphics memory, due to unalarmed hibernation. In which
> > > > > > case i915.ko cannot assume that it (reserved gfx memory) remains
> > > > > > unmodified and must recreate teh contents and importantly not use it to
> > > > > > store unrecoverable user data.
> > > > > > 
> > > > > > Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> > > > > > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> > > > > > Cc: Len Brown <lenb@kernel.org>
> > > > > > Cc: linux-acpi@vger.kernel.org
> > > > > > Cc: linux-kernel@vger.kernel.org
> > > > > > ---
> > > > > >  drivers/acpi/bus.c | 1 +
> > > > > >  1 file changed, 1 insertion(+)
> > > > > > 
> > > > > > diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> > > > > > index a212cef..69509c7 100644
> > > > > > --- a/drivers/acpi/bus.c
> > > > > > +++ b/drivers/acpi/bus.c
> > > > > > @@ -814,6 +814,7 @@ struct bus_type acpi_bus_type = {
> > > > > >  	.remove		= acpi_device_remove,
> > > > > >  	.uevent		= acpi_device_uevent,
> > > > > >  };
> > > > > > +EXPORT_SYMBOL_GPL(acpi_bus_type);
> > > > > >  
> > > > > >  /* --------------------------------------------------------------------------
> > > > > >                               Initialization/Cleanup
> > > > > > 
> > > > > 
> > > > > No.
> > > > > 
> > > > > I see no reason whatsoever for doing this.
> > > > > 
> > > > > Thanks,
> > > > > Rafael
> > > > Hi Rafael,
> > > > 
> > > > Thanks for the response.
> > > > 
> > > > Can you please help me with, how to detect the presence of a certain
> > > > acpi device using its id (for example, INT3392 for Intel RST device)? 
> > > 
> > > If you want to check if the device ir present at all, you cen use
> > > acpi_device_is_present() introduced recently (although that would need
> > > to be exported if you want to use it from a driver).
> > 
> > I meant acpi_dev_present(), sorry about the mistake.
> > 
> > I guess we should rename it to acpi_device_found() or something similar
> > to avoid such confusion in the future.
> 
> The name was chosen because the PCI equivalent is called pci_dev_present()
> and I assumed that name already stuck in developers' heads, so if they're
> looking for an ACPI presence detection function, that's what they'd look
> for first.

But "present" in ACPI really means something different.  There may be ACPI
device objects in the namespace for devices that are not *actually* present.

Thanks,
Rafael


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

* Re: [PATCH 10/11] acpi: Export acpi_bus_type
  2016-01-18 22:46             ` Rafael J. Wysocki
@ 2016-01-18 23:00                 ` Lukas Wunner
  0 siblings, 0 replies; 118+ messages in thread
From: Lukas Wunner @ 2016-01-18 23:00 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Ankitprasad Sharma, intel-gfx, shashidhar.hiremath, linux-kernel,
	linux-acpi, akash.goel, Len Brown

Hi,

On Mon, Jan 18, 2016 at 11:46:18PM +0100, Rafael J. Wysocki wrote:
> On Monday, January 18, 2016 11:39:07 PM Lukas Wunner wrote:
> > Hi,
> > 
> > On Mon, Jan 18, 2016 at 11:28:27PM +0100, Rafael J. Wysocki wrote:
> > > On Monday, January 18, 2016 03:57:29 PM Rafael J. Wysocki wrote:
> > > > On Monday, January 18, 2016 02:31:00 PM Ankitprasad Sharma wrote:
> > > > > On Fri, 2016-01-15 at 15:51 +0100, Rafael J. Wysocki wrote:
> > > > > > On Thursday, January 14, 2016 11:46:46 AM ankitprasad.r.sharma@intel.com wrote:
> > > > > > > From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> > > > > > > 
> > > > > > > Some modules, like i915.ko, needs to detect when certain ACPI features
> > > > > > > are active inorder to prevent corruption on contended resources.
> > > > > > > In particular, use of BIOS RapidStart Technology may corrupt the contents
> > > > > > > of the reserved graphics memory, due to unalarmed hibernation. In which
> > > > > > > case i915.ko cannot assume that it (reserved gfx memory) remains
> > > > > > > unmodified and must recreate teh contents and importantly not use it to
> > > > > > > store unrecoverable user data.
> > > > > > > 
> > > > > > > Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> > > > > > > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> > > > > > > Cc: Len Brown <lenb@kernel.org>
> > > > > > > Cc: linux-acpi@vger.kernel.org
> > > > > > > Cc: linux-kernel@vger.kernel.org
> > > > > > > ---
> > > > > > >  drivers/acpi/bus.c | 1 +
> > > > > > >  1 file changed, 1 insertion(+)
> > > > > > > 
> > > > > > > diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> > > > > > > index a212cef..69509c7 100644
> > > > > > > --- a/drivers/acpi/bus.c
> > > > > > > +++ b/drivers/acpi/bus.c
> > > > > > > @@ -814,6 +814,7 @@ struct bus_type acpi_bus_type = {
> > > > > > >  	.remove		= acpi_device_remove,
> > > > > > >  	.uevent		= acpi_device_uevent,
> > > > > > >  };
> > > > > > > +EXPORT_SYMBOL_GPL(acpi_bus_type);
> > > > > > >  
> > > > > > >  /* --------------------------------------------------------------------------
> > > > > > >                               Initialization/Cleanup
> > > > > > > 
> > > > > > 
> > > > > > No.
> > > > > > 
> > > > > > I see no reason whatsoever for doing this.
> > > > > > 
> > > > > > Thanks,
> > > > > > Rafael
> > > > > Hi Rafael,
> > > > > 
> > > > > Thanks for the response.
> > > > > 
> > > > > Can you please help me with, how to detect the presence of a certain
> > > > > acpi device using its id (for example, INT3392 for Intel RST device)?
> > > > 
> > > > If you want to check if the device ir present at all, you cen use
> > > > acpi_device_is_present() introduced recently (although that would need
> > > > to be exported if you want to use it from a driver).
> > > 
> > > I meant acpi_dev_present(), sorry about the mistake.
> > > 
> > > I guess we should rename it to acpi_device_found() or something similar
> > > to avoid such confusion in the future.
> > 
> > The name was chosen because the PCI equivalent is called pci_dev_present()
> > and I assumed that name already stuck in developers' heads, so if they're
> > looking for an ACPI presence detection function, that's what they'd look
> > for first.
> 
> But "present" in ACPI really means something different.  There may be ACPI
> device objects in the namespace for devices that are not *actually* present.

You mean synthesized devices like LNXSYBUS?
Don't think anyone is going to test for the presence of that.

I've posted 5 patches over the last days which use acpi_dev_present():

http://lists.freedesktop.org/archives/dri-devel/2016-January/098403.html
http://mailman.alsa-project.org/pipermail/alsa-devel/2016-January/103056.html
http://mailman.alsa-project.org/pipermail/alsa-devel/2016-January/103058.html
http://thread.gmane.org/gmane.linux.drivers.platform.x86.devel/8474/focus=8475
http://thread.gmane.org/gmane.linux.drivers.platform.x86.devel/8474/focus=8476

When considering a rename of the function, please bear in mind that it
will cause breakage for anyone testing or merging these patches.
(Postponing a rename until these patches have landed would avoid that.)

Thanks,

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

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

* Re: [PATCH 10/11] acpi: Export acpi_bus_type
@ 2016-01-18 23:00                 ` Lukas Wunner
  0 siblings, 0 replies; 118+ messages in thread
From: Lukas Wunner @ 2016-01-18 23:00 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Ankitprasad Sharma, intel-gfx, akash.goel, shashidhar.hiremath,
	tvrtko.ursulin, Len Brown, linux-acpi, linux-kernel

Hi,

On Mon, Jan 18, 2016 at 11:46:18PM +0100, Rafael J. Wysocki wrote:
> On Monday, January 18, 2016 11:39:07 PM Lukas Wunner wrote:
> > Hi,
> > 
> > On Mon, Jan 18, 2016 at 11:28:27PM +0100, Rafael J. Wysocki wrote:
> > > On Monday, January 18, 2016 03:57:29 PM Rafael J. Wysocki wrote:
> > > > On Monday, January 18, 2016 02:31:00 PM Ankitprasad Sharma wrote:
> > > > > On Fri, 2016-01-15 at 15:51 +0100, Rafael J. Wysocki wrote:
> > > > > > On Thursday, January 14, 2016 11:46:46 AM ankitprasad.r.sharma@intel.com wrote:
> > > > > > > From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> > > > > > > 
> > > > > > > Some modules, like i915.ko, needs to detect when certain ACPI features
> > > > > > > are active inorder to prevent corruption on contended resources.
> > > > > > > In particular, use of BIOS RapidStart Technology may corrupt the contents
> > > > > > > of the reserved graphics memory, due to unalarmed hibernation. In which
> > > > > > > case i915.ko cannot assume that it (reserved gfx memory) remains
> > > > > > > unmodified and must recreate teh contents and importantly not use it to
> > > > > > > store unrecoverable user data.
> > > > > > > 
> > > > > > > Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> > > > > > > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> > > > > > > Cc: Len Brown <lenb@kernel.org>
> > > > > > > Cc: linux-acpi@vger.kernel.org
> > > > > > > Cc: linux-kernel@vger.kernel.org
> > > > > > > ---
> > > > > > >  drivers/acpi/bus.c | 1 +
> > > > > > >  1 file changed, 1 insertion(+)
> > > > > > > 
> > > > > > > diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> > > > > > > index a212cef..69509c7 100644
> > > > > > > --- a/drivers/acpi/bus.c
> > > > > > > +++ b/drivers/acpi/bus.c
> > > > > > > @@ -814,6 +814,7 @@ struct bus_type acpi_bus_type = {
> > > > > > >  	.remove		= acpi_device_remove,
> > > > > > >  	.uevent		= acpi_device_uevent,
> > > > > > >  };
> > > > > > > +EXPORT_SYMBOL_GPL(acpi_bus_type);
> > > > > > >  
> > > > > > >  /* --------------------------------------------------------------------------
> > > > > > >                               Initialization/Cleanup
> > > > > > > 
> > > > > > 
> > > > > > No.
> > > > > > 
> > > > > > I see no reason whatsoever for doing this.
> > > > > > 
> > > > > > Thanks,
> > > > > > Rafael
> > > > > Hi Rafael,
> > > > > 
> > > > > Thanks for the response.
> > > > > 
> > > > > Can you please help me with, how to detect the presence of a certain
> > > > > acpi device using its id (for example, INT3392 for Intel RST device)?
> > > > 
> > > > If you want to check if the device ir present at all, you cen use
> > > > acpi_device_is_present() introduced recently (although that would need
> > > > to be exported if you want to use it from a driver).
> > > 
> > > I meant acpi_dev_present(), sorry about the mistake.
> > > 
> > > I guess we should rename it to acpi_device_found() or something similar
> > > to avoid such confusion in the future.
> > 
> > The name was chosen because the PCI equivalent is called pci_dev_present()
> > and I assumed that name already stuck in developers' heads, so if they're
> > looking for an ACPI presence detection function, that's what they'd look
> > for first.
> 
> But "present" in ACPI really means something different.  There may be ACPI
> device objects in the namespace for devices that are not *actually* present.

You mean synthesized devices like LNXSYBUS?
Don't think anyone is going to test for the presence of that.

I've posted 5 patches over the last days which use acpi_dev_present():

http://lists.freedesktop.org/archives/dri-devel/2016-January/098403.html
http://mailman.alsa-project.org/pipermail/alsa-devel/2016-January/103056.html
http://mailman.alsa-project.org/pipermail/alsa-devel/2016-January/103058.html
http://thread.gmane.org/gmane.linux.drivers.platform.x86.devel/8474/focus=8475
http://thread.gmane.org/gmane.linux.drivers.platform.x86.devel/8474/focus=8476

When considering a rename of the function, please bear in mind that it
will cause breakage for anyone testing or merging these patches.
(Postponing a rename until these patches have landed would avoid that.)

Thanks,

Lukas

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

* Re: [PATCH 10/11] acpi: Export acpi_bus_type
  2016-01-18 23:00                 ` Lukas Wunner
  (?)
@ 2016-01-18 23:59                 ` Rafael J. Wysocki
  2016-01-19 16:31                   ` Lukas Wunner
  -1 siblings, 1 reply; 118+ messages in thread
From: Rafael J. Wysocki @ 2016-01-18 23:59 UTC (permalink / raw)
  To: Lukas Wunner
  Cc: Ankitprasad Sharma, intel-gfx, akash.goel, shashidhar.hiremath,
	tvrtko.ursulin, Len Brown, linux-acpi, linux-kernel

On Tuesday, January 19, 2016 12:00:47 AM Lukas Wunner wrote:
> Hi,
> 
> On Mon, Jan 18, 2016 at 11:46:18PM +0100, Rafael J. Wysocki wrote:
> > On Monday, January 18, 2016 11:39:07 PM Lukas Wunner wrote:

[cut]

> > > > > If you want to check if the device ir present at all, you cen use
> > > > > acpi_device_is_present() introduced recently (although that would need
> > > > > to be exported if you want to use it from a driver).
> > > > 
> > > > I meant acpi_dev_present(), sorry about the mistake.
> > > > 
> > > > I guess we should rename it to acpi_device_found() or something similar
> > > > to avoid such confusion in the future.
> > > 
> > > The name was chosen because the PCI equivalent is called pci_dev_present()
> > > and I assumed that name already stuck in developers' heads, so if they're
> > > looking for an ACPI presence detection function, that's what they'd look
> > > for first.
> > 
> > But "present" in ACPI really means something different.  There may be ACPI
> > device objects in the namespace for devices that are not *actually* present.
> 
> You mean synthesized devices like LNXSYBUS?
> Don't think anyone is going to test for the presence of that.

No, I mean real devices, where the corresponding ACPI object has _STA that
returns 0.

There may be a couple of reasons for that.  The device the ACPI object
corresponds to may not be physically present (eg. it may possible to
hot-add it) or the device may depend on something else for functionality
and that thing hasn't been set up yet etc.

The presence of an ACPI device object in the namespace means that the
platform firmware knows about the device, but it need not mean that
the device is really there.  _STA returns that piece of information.

> 
> I've posted 5 patches over the last days which use acpi_dev_present():
> 
> http://lists.freedesktop.org/archives/dri-devel/2016-January/098403.html
> http://mailman.alsa-project.org/pipermail/alsa-devel/2016-January/103056.html
> http://mailman.alsa-project.org/pipermail/alsa-devel/2016-January/103058.html
> http://thread.gmane.org/gmane.linux.drivers.platform.x86.devel/8474/focus=8475
> http://thread.gmane.org/gmane.linux.drivers.platform.x86.devel/8474/focus=8476
> 
> When considering a rename of the function, please bear in mind that it
> will cause breakage for anyone testing or merging these patches.
> (Postponing a rename until these patches have landed would avoid that.)

No problem with that.  Please let me know when these patches are merged.

Thanks,
Rafael


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

* Re: [PATCH 10/11] acpi: Export acpi_bus_type
  2016-01-18 18:26         ` Lukas Wunner
@ 2016-01-19  8:15           ` Ankitprasad Sharma
  0 siblings, 0 replies; 118+ messages in thread
From: Ankitprasad Sharma @ 2016-01-19  8:15 UTC (permalink / raw)
  To: Lukas Wunner, Rafael J. Wysocki
  Cc: intel-gfx, akash.goel, shashidhar.hiremath, tvrtko.ursulin,
	Len Brown, linux-acpi, linux-kernel

On Mon, 2016-01-18 at 19:26 +0100, Lukas Wunner wrote:
Hi,
> Hi,
> 
> On Mon, Jan 18, 2016 at 03:57:29PM +0100, Rafael J. Wysocki wrote:
> > On Monday, January 18, 2016 02:31:00 PM Ankitprasad Sharma wrote:
> > > On Fri, 2016-01-15 at 15:51 +0100, Rafael J. Wysocki wrote:
> > > > On Thursday, January 14, 2016 11:46:46 AM ankitprasad.r.sharma@intel.com wrote:
> > > > > From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> > > > > 
> > > > > Some modules, like i915.ko, needs to detect when certain ACPI features
> > > > > are active inorder to prevent corruption on contended resources.
> > > > > In particular, use of BIOS RapidStart Technology may corrupt the contents
> > > > > of the reserved graphics memory, due to unalarmed hibernation. In which
> > > > > case i915.ko cannot assume that it (reserved gfx memory) remains
> > > > > unmodified and must recreate teh contents and importantly not use it to
> > > > > store unrecoverable user data.
> > > > > 
> > > > > Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> > > > > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> > > > > Cc: Len Brown <lenb@kernel.org>
> > > > > Cc: linux-acpi@vger.kernel.org
> > > > > Cc: linux-kernel@vger.kernel.org
> > > > > ---
> > > > >  drivers/acpi/bus.c | 1 +
> > > > >  1 file changed, 1 insertion(+)
> > > > > 
> > > > > diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> > > > > index a212cef..69509c7 100644
> > > > > --- a/drivers/acpi/bus.c
> > > > > +++ b/drivers/acpi/bus.c
> > > > > @@ -814,6 +814,7 @@ struct bus_type acpi_bus_type = {
> > > > >  	.remove		= acpi_device_remove,
> > > > >  	.uevent		= acpi_device_uevent,
> > > > >  };
> > > > > +EXPORT_SYMBOL_GPL(acpi_bus_type);
> > > > >  
> > > > >  /* --------------------------------------------------------------------------
> > > > >                               Initialization/Cleanup
> > > > > 
> > > > 
> > > > No.
> > > > 
> > > > I see no reason whatsoever for doing this.
> > > > 
> > > > Thanks,
> > > > Rafael
> > > Hi Rafael,
> > > 
> > > Thanks for the response.
> > > 
> > > Can you please help me with, how to detect the presence of a certain
> > > acpi device using its id (for example, INT3392 for Intel RST device)? 
> > 
> > If you want to check if the device ir present at all, you cen use
> > acpi_device_is_present() introduced recently (although that would need
> > to be exported if you want to use it from a driver).
> 
> acpi_dev_present() is exported, so can be used in drivers just fine:
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=2d12b6b381ba059d5f92798f5ea739672a2f5fcf
> 
> 
> > > As you might have seen (in the next patch in this series), that we use
> > > this symbol (acpi_bus_type) to iterate over all the devices registered
> > > on acpi bus, to check if there is a device with id INT3392 present or
> > > not.
> 
> Ankitprasad, just change your patch [11/11] thusly:
> 
> -       if (intel_detect_acpi_rst()) {
> +       if (acpi_dev_present("INT3392")) {
> 
> 
> Using bus_for_each_dev() was the wrong approach, most drivers call
> acpi_get_devices() to detect the presence of a particular HID,
> however that necessitates the definition of a callback in each driver,
> leading to lots of duplicate code. Hence the introduction of
> acpi_dev_present() which is also faster because it just iterates over
> a list instead of walking the namespace.
> 
> This new API landed in Linus' tree last Tuesday (PST), so you need
> to merge Linus' tree back into yours or wait until it gets merged
> into drm-intel-nightly.
> 
> Best regards,
> 
> Lukas

Thank you, Lukas/Rafael.

-Ankit



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

* Re: [PATCH 10/11] acpi: Export acpi_bus_type
  2016-01-18 23:59                 ` Rafael J. Wysocki
@ 2016-01-19 16:31                   ` Lukas Wunner
  2016-01-19 22:03                     ` Rafael J. Wysocki
  0 siblings, 1 reply; 118+ messages in thread
From: Lukas Wunner @ 2016-01-19 16:31 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Ankitprasad Sharma, intel-gfx, akash.goel, shashidhar.hiremath,
	tvrtko.ursulin, Len Brown, linux-acpi, linux-kernel

Hi Rafael,

On Tue, Jan 19, 2016 at 12:59:13AM +0100, Rafael J. Wysocki wrote:
> On Tuesday, January 19, 2016 12:00:47 AM Lukas Wunner wrote:
> > Hi,
> > 
> > On Mon, Jan 18, 2016 at 11:46:18PM +0100, Rafael J. Wysocki wrote:
> > > On Monday, January 18, 2016 11:39:07 PM Lukas Wunner wrote:
> 
> [cut]
> 
> > > > > > If you want to check if the device ir present at all, you cen use
> > > > > > acpi_device_is_present() introduced recently (although that would need
> > > > > > to be exported if you want to use it from a driver).
> > > > > 
> > > > > I meant acpi_dev_present(), sorry about the mistake.
> > > > > 
> > > > > I guess we should rename it to acpi_device_found() or something similar
> > > > > to avoid such confusion in the future.
> > > > 
> > > > The name was chosen because the PCI equivalent is called pci_dev_present()
> > > > and I assumed that name already stuck in developers' heads, so if they're
> > > > looking for an ACPI presence detection function, that's what they'd look
> > > > for first.
> > > 
> > > But "present" in ACPI really means something different.  There may be ACPI
> > > device objects in the namespace for devices that are not *actually* present.
> > 
> > You mean synthesized devices like LNXSYBUS?
> > Don't think anyone is going to test for the presence of that.
> 
> No, I mean real devices, where the corresponding ACPI object has _STA that
> returns 0.
> 
> There may be a couple of reasons for that.  The device the ACPI object
> corresponds to may not be physically present (eg. it may possible to
> hot-add it) or the device may depend on something else for functionality
> and that thing hasn't been set up yet etc.
> 
> The presence of an ACPI device object in the namespace means that the
> platform firmware knows about the device, but it need not mean that
> the device is really there.  _STA returns that piece of information.

Thank you for the clarification, these are very good points.

The drivers in question use acpi_get_devices() merely to probe for
presence of a device in the namespace. They do not invoke _STA,
nor do they even hold a pointer to the acpi_device or acpi_handle
when detecting presence. Mostly this is about activating quirks
if a certain ACPI device is detected.

Currently about 50% of the calls to acpi_get_devices() in the drivers
fit this pattern and the point of acpi_dev_present() is to give
developers a simple, lightweight tool as an alternative.

However the kernel-doc should be amended to clarify that _STA is not
invoked. The patch below is a suggestion, feel free to rephrase.

Thanks & best regards,

Lukas

-- >8 --
Subject: [PATCH] ACPI / utils: Clarify appropriate usage of acpi_dev_present()

Rafael J. Wysocki pointed out that even though a device is present
in the namespace, its _STA control method might still return 0 in the
"device is present" bit. Amend the documentation accordingly.

Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
---
 drivers/acpi/utils.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
index f2f9873..99af3bc 100644
--- a/drivers/acpi/utils.c
+++ b/drivers/acpi/utils.c
@@ -716,6 +716,8 @@ EXPORT_SYMBOL(acpi_check_dsm);
  *
  * Return %true if the device was present at the moment of invocation.
  * Note that if the device is pluggable, it may since have disappeared.
+ * Also, this merely checks presence in the namespace but does not
+ * invoke the _STA control method.
  *
  * For this function to work, acpi_bus_scan() must have been executed
  * which happens in the subsys_initcall() subsection. Hence, do not
-- 
1.8.5.2 (Apple Git-48)

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

* Re: [PATCH 10/11] acpi: Export acpi_bus_type
  2016-01-19 16:31                   ` Lukas Wunner
@ 2016-01-19 22:03                     ` Rafael J. Wysocki
  0 siblings, 0 replies; 118+ messages in thread
From: Rafael J. Wysocki @ 2016-01-19 22:03 UTC (permalink / raw)
  To: Lukas Wunner
  Cc: Ankitprasad Sharma, intel-gfx, akash.goel, shashidhar.hiremath,
	tvrtko.ursulin, Len Brown, linux-acpi, linux-kernel

On Tuesday, January 19, 2016 05:31:04 PM Lukas Wunner wrote:
> Hi Rafael,
> 
> On Tue, Jan 19, 2016 at 12:59:13AM +0100, Rafael J. Wysocki wrote:
> > On Tuesday, January 19, 2016 12:00:47 AM Lukas Wunner wrote:
> > > Hi,
> > > 
> > > On Mon, Jan 18, 2016 at 11:46:18PM +0100, Rafael J. Wysocki wrote:
> > > > On Monday, January 18, 2016 11:39:07 PM Lukas Wunner wrote:
> > 
> > [cut]
> > 
> > > > > > > If you want to check if the device ir present at all, you cen use
> > > > > > > acpi_device_is_present() introduced recently (although that would need
> > > > > > > to be exported if you want to use it from a driver).
> > > > > > 
> > > > > > I meant acpi_dev_present(), sorry about the mistake.
> > > > > > 
> > > > > > I guess we should rename it to acpi_device_found() or something similar
> > > > > > to avoid such confusion in the future.
> > > > > 
> > > > > The name was chosen because the PCI equivalent is called pci_dev_present()
> > > > > and I assumed that name already stuck in developers' heads, so if they're
> > > > > looking for an ACPI presence detection function, that's what they'd look
> > > > > for first.
> > > > 
> > > > But "present" in ACPI really means something different.  There may be ACPI
> > > > device objects in the namespace for devices that are not *actually* present.
> > > 
> > > You mean synthesized devices like LNXSYBUS?
> > > Don't think anyone is going to test for the presence of that.
> > 
> > No, I mean real devices, where the corresponding ACPI object has _STA that
> > returns 0.
> > 
> > There may be a couple of reasons for that.  The device the ACPI object
> > corresponds to may not be physically present (eg. it may possible to
> > hot-add it) or the device may depend on something else for functionality
> > and that thing hasn't been set up yet etc.
> > 
> > The presence of an ACPI device object in the namespace means that the
> > platform firmware knows about the device, but it need not mean that
> > the device is really there.  _STA returns that piece of information.
> 
> Thank you for the clarification, these are very good points.
> 
> The drivers in question use acpi_get_devices() merely to probe for
> presence of a device in the namespace. They do not invoke _STA,
> nor do they even hold a pointer to the acpi_device or acpi_handle
> when detecting presence. Mostly this is about activating quirks
> if a certain ACPI device is detected.

I know, but it doesn't matter too much.  I don't want people to wonder
what the difference between acpi_dev_present() and acpi_device_is_present()
is and when to use which of them.

> Currently about 50% of the calls to acpi_get_devices() in the drivers
> fit this pattern and the point of acpi_dev_present() is to give
> developers a simple, lightweight tool as an alternative.

Again, I know, but the name of the function should be different.

> However the kernel-doc should be amended to clarify that _STA is not
> invoked. The patch below is a suggestion, feel free to rephrase.

That's OK, but it's not enough.

I guess it won't be a big deal to change the function name and rebase
the patches depending on it on top of that change, will it?

Thanks,
Rafael


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

* Re: ✗ failure:  Fi.CI.BAT
  2016-01-19 14:09       ` Ville Syrjälä
@ 2016-01-19 16:43         ` Daniel Vetter
  0 siblings, 0 replies; 118+ messages in thread
From: Daniel Vetter @ 2016-01-19 16:43 UTC (permalink / raw)
  To: Ville Syrjälä; +Cc: Sarvela, Tomi P, intel-gfx

On Tue, Jan 19, 2016 at 04:09:48PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 19, 2016 at 02:58:14PM +0100, Daniel Vetter wrote:
> > On Thu, Jan 14, 2016 at 04:29:14PM +0200, Ville Syrjälä wrote:
> > > On Thu, Jan 14, 2016 at 02:20:40PM -0000, Patchwork wrote:
> > > > == Summary ==
> > > > 
> > > > Built on 8fb2feecca499d11e104264071ac55e273e23af5 drm-intel-nightly: 2016y-01m-14d-13h-06m-44s UTC integration manifest
> > > > 
> > > > Test gem_basic:
> > > >         Subgroup create-close:
> > > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > > > Test gem_cpu_reloc:
> > > >         Subgroup basic:
> > > >                 pass       -> DMESG-FAIL (skl-i7k-2)
> > > > Test gem_ctx_param_basic:
> > > >         Subgroup basic:
> > > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > > >         Subgroup invalid-param-set:
> > > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > > >         Subgroup non-root-set-no-zeromap:
> > > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > > >         Subgroup root-set-no-zeromap-disabled:
> > > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > > > Test gem_mmap:
> > > >         Subgroup basic:
> > > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > > > Test gem_mmap_gtt:
> > > >         Subgroup basic-read:
> > > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > > >         Subgroup basic-write:
> > > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > > > Test gem_storedw_loop:
> > > >         Subgroup basic-render:
> > > >                 dmesg-warn -> PASS       (skl-i5k-2) UNSTABLE
> > > >                 dmesg-warn -> PASS       (bdw-nuci7)
> > > >                 dmesg-warn -> PASS       (skl-i7k-2) UNSTABLE
> > > > Test kms_addfb_basic:
> > > >         Subgroup addfb25-modifier-no-flag:
> > > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > > >         Subgroup addfb25-x-tiled-mismatch:
> > > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > > >         Subgroup addfb25-yf-tiled:
> > > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > > >         Subgroup bad-pitch-1024:
> > > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > > >         Subgroup bad-pitch-63:
> > > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > > >         Subgroup bad-pitch-999:
> > > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > > >         Subgroup clobberred-modifier:
> > > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > > >         Subgroup too-high:
> > > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > > >         Subgroup too-wide:
> > > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > > >         Subgroup unused-offsets:
> > > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > > > Test kms_flip:
> > > >         Subgroup basic-plain-flip:
> > > >                 pass       -> DMESG-FAIL (skl-i7k-2)
> > > > Test kms_pipe_crc_basic:
> > > >         Subgroup nonblocking-crc-pipe-a-frame-sequence:
> > > >                 pass       -> DMESG-FAIL (skl-i7k-2)
> > > >         Subgroup read-crc-pipe-b-frame-sequence:
> > > >                 pass       -> DMESG-FAIL (skl-i7k-2)
> > > > Test prime_self_import:
> > > >         Subgroup basic-with_two_bos:
> > > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > > 
> > > Looks like the GPU died or something on that skl. Can't imagine it being related
> > > to watermark patches.
> > 
> > Mika created a bugzilla for this since this isn't the first time this
> > happened. We have 2 instances of a failure with matching syptoms in normal
> > -nightly CI runs already:
> > 
> > https://bugs.freedesktop.org/show_bug.cgi?id=93768
> > 
> > In the future if you have a case where an entire machine dies it's useful
> > to look at the machine history. That shows you the results for the last 50
> > runs on only that machine for any testcase where results changed. That
> > helps in figuring out whether there's something wrong with that machine,
> > or whether there might indeed be trouble with your patch set.
> 
> Sadly the link to the machine history is busted for patchwork CI results,
> so doing that is somewhat more tedious than it should be. Might be a
> good idea to fix all the links once and for all. Cc:ing Tomi...

Yeah it only works in the master CI overview, both for the long-term view
for machines and for testcases.

I'll paste you the link to the overall howto on the internal wiki page in
private.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: ✗ failure:  Fi.CI.BAT
  2016-01-19 13:58     ` Daniel Vetter
@ 2016-01-19 14:09       ` Ville Syrjälä
  2016-01-19 16:43         ` Daniel Vetter
  0 siblings, 1 reply; 118+ messages in thread
From: Ville Syrjälä @ 2016-01-19 14:09 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: Sarvela, Tomi P, intel-gfx

On Tue, Jan 19, 2016 at 02:58:14PM +0100, Daniel Vetter wrote:
> On Thu, Jan 14, 2016 at 04:29:14PM +0200, Ville Syrjälä wrote:
> > On Thu, Jan 14, 2016 at 02:20:40PM -0000, Patchwork wrote:
> > > == Summary ==
> > > 
> > > Built on 8fb2feecca499d11e104264071ac55e273e23af5 drm-intel-nightly: 2016y-01m-14d-13h-06m-44s UTC integration manifest
> > > 
> > > Test gem_basic:
> > >         Subgroup create-close:
> > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > > Test gem_cpu_reloc:
> > >         Subgroup basic:
> > >                 pass       -> DMESG-FAIL (skl-i7k-2)
> > > Test gem_ctx_param_basic:
> > >         Subgroup basic:
> > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > >         Subgroup invalid-param-set:
> > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > >         Subgroup non-root-set-no-zeromap:
> > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > >         Subgroup root-set-no-zeromap-disabled:
> > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > > Test gem_mmap:
> > >         Subgroup basic:
> > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > > Test gem_mmap_gtt:
> > >         Subgroup basic-read:
> > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > >         Subgroup basic-write:
> > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > > Test gem_storedw_loop:
> > >         Subgroup basic-render:
> > >                 dmesg-warn -> PASS       (skl-i5k-2) UNSTABLE
> > >                 dmesg-warn -> PASS       (bdw-nuci7)
> > >                 dmesg-warn -> PASS       (skl-i7k-2) UNSTABLE
> > > Test kms_addfb_basic:
> > >         Subgroup addfb25-modifier-no-flag:
> > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > >         Subgroup addfb25-x-tiled-mismatch:
> > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > >         Subgroup addfb25-yf-tiled:
> > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > >         Subgroup bad-pitch-1024:
> > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > >         Subgroup bad-pitch-63:
> > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > >         Subgroup bad-pitch-999:
> > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > >         Subgroup clobberred-modifier:
> > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > >         Subgroup too-high:
> > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > >         Subgroup too-wide:
> > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > >         Subgroup unused-offsets:
> > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > > Test kms_flip:
> > >         Subgroup basic-plain-flip:
> > >                 pass       -> DMESG-FAIL (skl-i7k-2)
> > > Test kms_pipe_crc_basic:
> > >         Subgroup nonblocking-crc-pipe-a-frame-sequence:
> > >                 pass       -> DMESG-FAIL (skl-i7k-2)
> > >         Subgroup read-crc-pipe-b-frame-sequence:
> > >                 pass       -> DMESG-FAIL (skl-i7k-2)
> > > Test prime_self_import:
> > >         Subgroup basic-with_two_bos:
> > >                 pass       -> DMESG-WARN (skl-i7k-2)
> > 
> > Looks like the GPU died or something on that skl. Can't imagine it being related
> > to watermark patches.
> 
> Mika created a bugzilla for this since this isn't the first time this
> happened. We have 2 instances of a failure with matching syptoms in normal
> -nightly CI runs already:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=93768
> 
> In the future if you have a case where an entire machine dies it's useful
> to look at the machine history. That shows you the results for the last 50
> runs on only that machine for any testcase where results changed. That
> helps in figuring out whether there's something wrong with that machine,
> or whether there might indeed be trouble with your patch set.

Sadly the link to the machine history is busted for patchwork CI results,
so doing that is somewhat more tedious than it should be. Might be a
good idea to fix all the links once and for all. Cc:ing Tomi...

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

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

* Re: ✗ failure:  Fi.CI.BAT
  2016-01-14 14:29   ` Ville Syrjälä
@ 2016-01-19 13:58     ` Daniel Vetter
  2016-01-19 14:09       ` Ville Syrjälä
  0 siblings, 1 reply; 118+ messages in thread
From: Daniel Vetter @ 2016-01-19 13:58 UTC (permalink / raw)
  To: Ville Syrjälä; +Cc: intel-gfx

On Thu, Jan 14, 2016 at 04:29:14PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 14, 2016 at 02:20:40PM -0000, Patchwork wrote:
> > == Summary ==
> > 
> > Built on 8fb2feecca499d11e104264071ac55e273e23af5 drm-intel-nightly: 2016y-01m-14d-13h-06m-44s UTC integration manifest
> > 
> > Test gem_basic:
> >         Subgroup create-close:
> >                 pass       -> DMESG-WARN (skl-i7k-2)
> > Test gem_cpu_reloc:
> >         Subgroup basic:
> >                 pass       -> DMESG-FAIL (skl-i7k-2)
> > Test gem_ctx_param_basic:
> >         Subgroup basic:
> >                 pass       -> DMESG-WARN (skl-i7k-2)
> >         Subgroup invalid-param-set:
> >                 pass       -> DMESG-WARN (skl-i7k-2)
> >         Subgroup non-root-set-no-zeromap:
> >                 pass       -> DMESG-WARN (skl-i7k-2)
> >         Subgroup root-set-no-zeromap-disabled:
> >                 pass       -> DMESG-WARN (skl-i7k-2)
> > Test gem_mmap:
> >         Subgroup basic:
> >                 pass       -> DMESG-WARN (skl-i7k-2)
> > Test gem_mmap_gtt:
> >         Subgroup basic-read:
> >                 pass       -> DMESG-WARN (skl-i7k-2)
> >         Subgroup basic-write:
> >                 pass       -> DMESG-WARN (skl-i7k-2)
> > Test gem_storedw_loop:
> >         Subgroup basic-render:
> >                 dmesg-warn -> PASS       (skl-i5k-2) UNSTABLE
> >                 dmesg-warn -> PASS       (bdw-nuci7)
> >                 dmesg-warn -> PASS       (skl-i7k-2) UNSTABLE
> > Test kms_addfb_basic:
> >         Subgroup addfb25-modifier-no-flag:
> >                 pass       -> DMESG-WARN (skl-i7k-2)
> >         Subgroup addfb25-x-tiled-mismatch:
> >                 pass       -> DMESG-WARN (skl-i7k-2)
> >         Subgroup addfb25-yf-tiled:
> >                 pass       -> DMESG-WARN (skl-i7k-2)
> >         Subgroup bad-pitch-1024:
> >                 pass       -> DMESG-WARN (skl-i7k-2)
> >         Subgroup bad-pitch-63:
> >                 pass       -> DMESG-WARN (skl-i7k-2)
> >         Subgroup bad-pitch-999:
> >                 pass       -> DMESG-WARN (skl-i7k-2)
> >         Subgroup clobberred-modifier:
> >                 pass       -> DMESG-WARN (skl-i7k-2)
> >         Subgroup too-high:
> >                 pass       -> DMESG-WARN (skl-i7k-2)
> >         Subgroup too-wide:
> >                 pass       -> DMESG-WARN (skl-i7k-2)
> >         Subgroup unused-offsets:
> >                 pass       -> DMESG-WARN (skl-i7k-2)
> > Test kms_flip:
> >         Subgroup basic-plain-flip:
> >                 pass       -> DMESG-FAIL (skl-i7k-2)
> > Test kms_pipe_crc_basic:
> >         Subgroup nonblocking-crc-pipe-a-frame-sequence:
> >                 pass       -> DMESG-FAIL (skl-i7k-2)
> >         Subgroup read-crc-pipe-b-frame-sequence:
> >                 pass       -> DMESG-FAIL (skl-i7k-2)
> > Test prime_self_import:
> >         Subgroup basic-with_two_bos:
> >                 pass       -> DMESG-WARN (skl-i7k-2)
> 
> Looks like the GPU died or something on that skl. Can't imagine it being related
> to watermark patches.

Mika created a bugzilla for this since this isn't the first time this
happened. We have 2 instances of a failure with matching syptoms in normal
-nightly CI runs already:

https://bugs.freedesktop.org/show_bug.cgi?id=93768

In the future if you have a case where an entire machine dies it's useful
to look at the machine history. That shows you the results for the last 50
runs on only that machine for any testcase where results changed. That
helps in figuring out whether there's something wrong with that machine,
or whether there might indeed be trouble with your patch set.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: ✗ failure:  Fi.CI.BAT
  2016-01-14 11:31   ` Nick Hoath
@ 2016-01-19  9:08     ` Daniel Vetter
  0 siblings, 0 replies; 118+ messages in thread
From: Daniel Vetter @ 2016-01-19  9:08 UTC (permalink / raw)
  To: Nick Hoath; +Cc: intel-gfx

On Thu, Jan 14, 2016 at 11:31:07AM +0000, Nick Hoath wrote:
> On 14/01/2016 07:20, Patchwork wrote:
> >== Summary ==

Our BKM is to link to bugzilla entries to make sure these are all real
failures which are tracked already. Otherwise stuff falls through the
cracks.

> >
> >Built on 058740f8fced6851aeda34f366f5330322cd585f drm-intel-nightly: 2016y-01m-13d-17h-07m-44s UTC integration manifest
> >
> >Test gem_ctx_basic:
> >                 pass       -> FAIL       (bdw-ultra)
> 
> Test failed to load - not patch related
> 
> >Test gem_ctx_param_basic:
> >         Subgroup non-root-set:
> >                 pass       -> DMESG-WARN (bsw-nuc-2)
> 
> gem driver allocated a poisoned slab - not patch related
> 
> >Test kms_flip:
> >         Subgroup basic-flip-vs-dpms:
> >                 pass       -> SKIP       (bsw-nuc-2)
> 
> test reqs not met - not patch related

basic-flip-vs-dpms MUST always work. Well except if you have a chip with
GT only where the display is fused off. I expect more serious analysis
instead of casually shrugging issues away as "not my problem".

Same sloppy analysis with the others imo.
-Daniel


> 
> >                 dmesg-warn -> PASS       (ilk-hp8440p)
> 
> warn to PASS
> 
> >
> >bdw-nuci7        total:138  pass:128  dwarn:1   dfail:0   fail:0   skip:9
> >bdw-ultra        total:138  pass:131  dwarn:0   dfail:0   fail:1   skip:6
> >bsw-nuc-2        total:141  pass:113  dwarn:3   dfail:0   fail:0   skip:25
> >hsw-brixbox      total:141  pass:134  dwarn:0   dfail:0   fail:0   skip:7
> >hsw-gt2          total:141  pass:137  dwarn:0   dfail:0   fail:0   skip:4
> >ilk-hp8440p      total:141  pass:101  dwarn:3   dfail:0   fail:0   skip:37
> >ivb-t430s        total:135  pass:122  dwarn:3   dfail:4   fail:0   skip:6
> >skl-i5k-2        total:141  pass:131  dwarn:2   dfail:0   fail:0   skip:8
> >skl-i7k-2        total:141  pass:131  dwarn:2   dfail:0   fail:0   skip:8
> >snb-dellxps      total:141  pass:122  dwarn:5   dfail:0   fail:0   skip:14
> >snb-x220t        total:141  pass:122  dwarn:5   dfail:0   fail:1   skip:13
> >
> >Results at /archive/results/CI_IGT_test/Patchwork_1174/
> >
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: ✗ failure:  Fi.CI.BAT
  2016-01-14 15:00   ` Ville Syrjälä
@ 2016-01-15 12:03     ` Chris Wilson
  0 siblings, 0 replies; 118+ messages in thread
From: Chris Wilson @ 2016-01-15 12:03 UTC (permalink / raw)
  To: Ville Syrjälä; +Cc: intel-gfx

On Thu, Jan 14, 2016 at 05:00:02PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 14, 2016 at 02:49:45PM -0000, Patchwork wrote:
> > == Summary ==
> > 
> > Built on 8fb2feecca499d11e104264071ac55e273e23af5 drm-intel-nightly: 2016y-01m-14d-13h-06m-44s UTC integration manifest
> > 
> > Test gem_ctx_basic:
> >                 pass       -> FAIL       (bdw-ultra)
> 
> "Returncode -15" and nothing more. Weird.

Strikes me as a bug in the testrunner. That's not one of ours.
-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

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

* ✗ failure: Fi.CI.BAT
  2016-01-14 15:56 [PATCH v5 1/1] drm/i915/bxt: Check BIOS RC6 setup before enabling RC6 Sagar Arun Kamble
@ 2016-01-14 16:30 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-14 16:30 UTC (permalink / raw)
  To: sagar.a.kamble; +Cc: intel-gfx

== Summary ==

HEAD is now at 8fb2fee drm-intel-nightly: 2016y-01m-14d-13h-06m-44s UTC integration manifest
Applying: drm/i915/bxt: Check BIOS RC6 setup before enabling RC6
Using index info to reconstruct a base tree...
M	drivers/gpu/drm/i915/i915_drv.h
M	drivers/gpu/drm/i915/i915_gem_stolen.c
M	drivers/gpu/drm/i915/i915_reg.h
M	drivers/gpu/drm/i915/intel_drv.h
M	drivers/gpu/drm/i915/intel_pm.c
M	drivers/gpu/drm/i915/intel_uncore.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_uncore.c
Auto-merging drivers/gpu/drm/i915/intel_pm.c
Auto-merging drivers/gpu/drm/i915/intel_drv.h
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_drv.h
Auto-merging drivers/gpu/drm/i915/i915_reg.h
Auto-merging drivers/gpu/drm/i915/i915_gem_stolen.c
Auto-merging drivers/gpu/drm/i915/i915_drv.h
Patch failed at 0001 drm/i915/bxt: Check BIOS RC6 setup before enabling RC6

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

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

* ✗ failure: Fi.CI.BAT
  2016-01-14 15:12 [PATCH] drm/i915/bios: Fix the sequence size calculations for MIPI seq v3 Jani Nikula
@ 2016-01-14 16:20 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-14 16:20 UTC (permalink / raw)
  To: Jani Nikula; +Cc: intel-gfx

== Summary ==

Built on 8fb2feecca499d11e104264071ac55e273e23af5 drm-intel-nightly: 2016y-01m-14d-13h-06m-44s UTC integration manifest

Test gem_storedw_loop:
        Subgroup basic-render:
                dmesg-warn -> PASS       (skl-i5k-2) UNSTABLE
                dmesg-warn -> PASS       (bdw-nuci7)
                dmesg-warn -> PASS       (bdw-ultra)
Test kms_flip:
        Subgroup basic-flip-vs-dpms:
                pass       -> DMESG-WARN (ilk-hp8440p)
Test kms_pipe_crc_basic:
        Subgroup read-crc-pipe-b:
                pass       -> DMESG-WARN (bdw-ultra)

bdw-nuci7        total:138  pass:129  dwarn:0   dfail:0   fail:0   skip:9  
bdw-ultra        total:138  pass:131  dwarn:1   dfail:0   fail:0   skip:6  
bsw-nuc-2        total:141  pass:115  dwarn:2   dfail:0   fail:0   skip:24 
hsw-brixbox      total:141  pass:134  dwarn:0   dfail:0   fail:0   skip:7  
hsw-gt2          total:141  pass:137  dwarn:0   dfail:0   fail:0   skip:4  
ilk-hp8440p      total:141  pass:100  dwarn:4   dfail:0   fail:0   skip:37 
ivb-t430s        total:135  pass:122  dwarn:3   dfail:4   fail:0   skip:6  
skl-i5k-2        total:141  pass:132  dwarn:1   dfail:0   fail:0   skip:8  
snb-dellxps      total:141  pass:122  dwarn:5   dfail:0   fail:0   skip:14 
snb-x220t        total:141  pass:122  dwarn:5   dfail:0   fail:1   skip:13 

HANGED skl-i7k-2 in Patchwork_1190/skl-i7k-2/tests/115.json:igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b Patchwork_1190/skl-i7k-2/tests/116.json:igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c Patchwork_1190/skl-i7k-2/tests/117.json:igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a Patchwork_1190/skl-i7k-2/tests/118.json:igt@gem_ctx_create@basic Patchwork_1190/skl-i7k-2/tests/119.json:igt@gem_ctx_param_basic@invalid-ctx-get Patchwork_1190/skl-i7k-2/tests/120.json:igt@kms_addfb_basic@size-max Patchwork_1190/skl-i7k-2/tests/121.json:igt@kms_addfb_basic@no-handle Patchwork_1190/skl-i7k-2/tests/122.json:igt@kms_pipe_crc_basic@read-crc-pipe-a Patchwork_1190/skl-i7k-2/tests/123.json:igt@kms_pipe_crc_basic@read-crc-pipe-c Patchwork_1190/skl-i7k-2/tests/124.json:igt@kms_pipe_crc_basic@read-crc-pipe-b Patchwork_1190/skl-i7k-2/tests/125.json:igt@kms_addfb_basic@bad-pitch-256 Patchwork_1190/skl-i7k-2/tests/126.json:igt@gem_mmap_gtt@basic-write-gtt Patchwork_1190/skl-i7k-2/tests/127.json:igt@kms_s
 etmode@basic-clone-single-crtc Patchwork_1190/skl-i7k-2/tests/128.json:igt@kms_addfb_basic@addfb25-x-tiled Patchwork_1190/skl-i7k-2/tests/129.json:igt@gem_basic@bad-close Patchwork_1190/skl-i7k-2/tests/130.json:igt@gem_render_linear_blits@basic Patchwork_1190/skl-i7k-2/tests/131.json:igt@gem_mmap_gtt@basic-copy Patchwork_1190/skl-i7k-2/tests/132.json:igt@kms_addfb_basic@small-bo Patchwork_1190/skl-i7k-2/tests/133.json:igt@kms_addfb_basic@basic Patchwork_1190/skl-i7k-2/tests/134.json:igt@kms_flip@basic-flip-vs-modeset Patchwork_1190/skl-i7k-2/tests/135.json:igt@kms_addfb_basic@unused-pitches Patchwork_1190/skl-i7k-2/tests/136.json:igt@kms_addfb_basic@bo-too-small-due-to-tiling Patchwork_1190/skl-i7k-2/tests/137.json:igt@gem_storedw_loop@basic-blt Patchwork_1190/skl-i7k-2/tests/138.json:igt@drv_getparams_basic@basic-eu-total Patchwork_1190/skl-i7k-2/tests/139.json:igt@gem_ctx_param_basic@invalid-ctx-set Patchwork_1190/skl-i7k-2/tests/140.json:igt@kms_pipe_crc_basic@read-crc-pipe-a-fra
 me-sequence

Results at /archive/results/CI_IGT_test/Patchwork_1190/

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

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

* ✗ failure: Fi.CI.BAT
  2016-01-14 15:02 [PATCH] drm/i915: Decouple execbuf uAPI from internal implementation Tvrtko Ursulin
@ 2016-01-14 15:49 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-14 15:49 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: intel-gfx

== Summary ==

Built on 8fb2feecca499d11e104264071ac55e273e23af5 drm-intel-nightly: 2016y-01m-14d-13h-06m-44s UTC integration manifest

Test gem_ctx_basic:
                pass       -> FAIL       (bdw-ultra)
Test gem_storedw_loop:
        Subgroup basic-render:
                dmesg-warn -> PASS       (skl-i5k-2) UNSTABLE
                dmesg-warn -> PASS       (bdw-nuci7)
                dmesg-warn -> PASS       (bdw-ultra)
Test kms_flip:
        Subgroup basic-flip-vs-dpms:
                pass       -> DMESG-WARN (ilk-hp8440p)

bdw-nuci7        total:138  pass:129  dwarn:0   dfail:0   fail:0   skip:9  
bdw-ultra        total:138  pass:131  dwarn:0   dfail:0   fail:1   skip:6  
bsw-nuc-2        total:141  pass:115  dwarn:2   dfail:0   fail:0   skip:24 
hsw-brixbox      total:141  pass:134  dwarn:0   dfail:0   fail:0   skip:7  
hsw-gt2          total:141  pass:137  dwarn:0   dfail:0   fail:0   skip:4  
ilk-hp8440p      total:141  pass:100  dwarn:4   dfail:0   fail:0   skip:37 
ivb-t430s        total:135  pass:122  dwarn:3   dfail:4   fail:0   skip:6  
skl-i5k-2        total:141  pass:132  dwarn:1   dfail:0   fail:0   skip:8  
skl-i7k-2        total:141  pass:131  dwarn:2   dfail:0   fail:0   skip:8  
snb-dellxps      total:141  pass:122  dwarn:5   dfail:0   fail:0   skip:14 
snb-x220t        total:141  pass:122  dwarn:5   dfail:0   fail:1   skip:13 

Results at /archive/results/CI_IGT_test/Patchwork_1189/

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

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

* Re: ✗ failure: Fi.CI.BAT
  2016-01-14 14:49 ` ✗ failure: Fi.CI.BAT Patchwork
@ 2016-01-14 15:00   ` Ville Syrjälä
  2016-01-15 12:03     ` Chris Wilson
  0 siblings, 1 reply; 118+ messages in thread
From: Ville Syrjälä @ 2016-01-14 15:00 UTC (permalink / raw)
  To: Patchwork; +Cc: intel-gfx

On Thu, Jan 14, 2016 at 02:49:45PM -0000, Patchwork wrote:
> == Summary ==
> 
> Built on 8fb2feecca499d11e104264071ac55e273e23af5 drm-intel-nightly: 2016y-01m-14d-13h-06m-44s UTC integration manifest
> 
> Test gem_ctx_basic:
>                 pass       -> FAIL       (bdw-ultra)

"Returncode -15" and nothing more. Weird.

> Test gem_storedw_loop:
>         Subgroup basic-render:
>                 dmesg-warn -> PASS       (bdw-nuci7)
>                 dmesg-warn -> PASS       (bdw-ultra)
> 
> bdw-nuci7        total:138  pass:129  dwarn:0   dfail:0   fail:0   skip:9  
> bdw-ultra        total:138  pass:131  dwarn:0   dfail:0   fail:1   skip:6  
> bsw-nuc-2        total:141  pass:115  dwarn:2   dfail:0   fail:0   skip:24 
> hsw-brixbox      total:141  pass:134  dwarn:0   dfail:0   fail:0   skip:7  
> hsw-gt2          total:141  pass:137  dwarn:0   dfail:0   fail:0   skip:4  
> ilk-hp8440p      total:141  pass:101  dwarn:3   dfail:0   fail:0   skip:37 
> ivb-t430s        total:135  pass:122  dwarn:3   dfail:4   fail:0   skip:6  
> skl-i5k-2        total:141  pass:131  dwarn:2   dfail:0   fail:0   skip:8  
> snb-dellxps      total:141  pass:122  dwarn:5   dfail:0   fail:0   skip:14 
> snb-x220t        total:141  pass:122  dwarn:5   dfail:0   fail:1   skip:13 
> 
> Results at /archive/results/CI_IGT_test/Patchwork_1188/

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

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

* ✗ failure: Fi.CI.BAT
  2016-01-14 13:22 [PATCH 0/8] drm/i915: Some more fb offsets[] prep stuff ville.syrjala
@ 2016-01-14 14:49 ` Patchwork
  2016-01-14 15:00   ` Ville Syrjälä
  0 siblings, 1 reply; 118+ messages in thread
From: Patchwork @ 2016-01-14 14:49 UTC (permalink / raw)
  To: ville.syrjala; +Cc: intel-gfx

== Summary ==

Built on 8fb2feecca499d11e104264071ac55e273e23af5 drm-intel-nightly: 2016y-01m-14d-13h-06m-44s UTC integration manifest

Test gem_ctx_basic:
                pass       -> FAIL       (bdw-ultra)
Test gem_storedw_loop:
        Subgroup basic-render:
                dmesg-warn -> PASS       (bdw-nuci7)
                dmesg-warn -> PASS       (bdw-ultra)

bdw-nuci7        total:138  pass:129  dwarn:0   dfail:0   fail:0   skip:9  
bdw-ultra        total:138  pass:131  dwarn:0   dfail:0   fail:1   skip:6  
bsw-nuc-2        total:141  pass:115  dwarn:2   dfail:0   fail:0   skip:24 
hsw-brixbox      total:141  pass:134  dwarn:0   dfail:0   fail:0   skip:7  
hsw-gt2          total:141  pass:137  dwarn:0   dfail:0   fail:0   skip:4  
ilk-hp8440p      total:141  pass:101  dwarn:3   dfail:0   fail:0   skip:37 
ivb-t430s        total:135  pass:122  dwarn:3   dfail:4   fail:0   skip:6  
skl-i5k-2        total:141  pass:131  dwarn:2   dfail:0   fail:0   skip:8  
snb-dellxps      total:141  pass:122  dwarn:5   dfail:0   fail:0   skip:14 
snb-x220t        total:141  pass:122  dwarn:5   dfail:0   fail:1   skip:13 

Results at /archive/results/CI_IGT_test/Patchwork_1188/

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

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

* Re: ✗ failure: Fi.CI.BAT
  2016-01-14 14:20 ` ✗ failure: Fi.CI.BAT Patchwork
@ 2016-01-14 14:29   ` Ville Syrjälä
  2016-01-19 13:58     ` Daniel Vetter
  0 siblings, 1 reply; 118+ messages in thread
From: Ville Syrjälä @ 2016-01-14 14:29 UTC (permalink / raw)
  To: Patchwork; +Cc: intel-gfx

On Thu, Jan 14, 2016 at 02:20:40PM -0000, Patchwork wrote:
> == Summary ==
> 
> Built on 8fb2feecca499d11e104264071ac55e273e23af5 drm-intel-nightly: 2016y-01m-14d-13h-06m-44s UTC integration manifest
> 
> Test gem_basic:
>         Subgroup create-close:
>                 pass       -> DMESG-WARN (skl-i7k-2)
> Test gem_cpu_reloc:
>         Subgroup basic:
>                 pass       -> DMESG-FAIL (skl-i7k-2)
> Test gem_ctx_param_basic:
>         Subgroup basic:
>                 pass       -> DMESG-WARN (skl-i7k-2)
>         Subgroup invalid-param-set:
>                 pass       -> DMESG-WARN (skl-i7k-2)
>         Subgroup non-root-set-no-zeromap:
>                 pass       -> DMESG-WARN (skl-i7k-2)
>         Subgroup root-set-no-zeromap-disabled:
>                 pass       -> DMESG-WARN (skl-i7k-2)
> Test gem_mmap:
>         Subgroup basic:
>                 pass       -> DMESG-WARN (skl-i7k-2)
> Test gem_mmap_gtt:
>         Subgroup basic-read:
>                 pass       -> DMESG-WARN (skl-i7k-2)
>         Subgroup basic-write:
>                 pass       -> DMESG-WARN (skl-i7k-2)
> Test gem_storedw_loop:
>         Subgroup basic-render:
>                 dmesg-warn -> PASS       (skl-i5k-2) UNSTABLE
>                 dmesg-warn -> PASS       (bdw-nuci7)
>                 dmesg-warn -> PASS       (skl-i7k-2) UNSTABLE
> Test kms_addfb_basic:
>         Subgroup addfb25-modifier-no-flag:
>                 pass       -> DMESG-WARN (skl-i7k-2)
>         Subgroup addfb25-x-tiled-mismatch:
>                 pass       -> DMESG-WARN (skl-i7k-2)
>         Subgroup addfb25-yf-tiled:
>                 pass       -> DMESG-WARN (skl-i7k-2)
>         Subgroup bad-pitch-1024:
>                 pass       -> DMESG-WARN (skl-i7k-2)
>         Subgroup bad-pitch-63:
>                 pass       -> DMESG-WARN (skl-i7k-2)
>         Subgroup bad-pitch-999:
>                 pass       -> DMESG-WARN (skl-i7k-2)
>         Subgroup clobberred-modifier:
>                 pass       -> DMESG-WARN (skl-i7k-2)
>         Subgroup too-high:
>                 pass       -> DMESG-WARN (skl-i7k-2)
>         Subgroup too-wide:
>                 pass       -> DMESG-WARN (skl-i7k-2)
>         Subgroup unused-offsets:
>                 pass       -> DMESG-WARN (skl-i7k-2)
> Test kms_flip:
>         Subgroup basic-plain-flip:
>                 pass       -> DMESG-FAIL (skl-i7k-2)
> Test kms_pipe_crc_basic:
>         Subgroup nonblocking-crc-pipe-a-frame-sequence:
>                 pass       -> DMESG-FAIL (skl-i7k-2)
>         Subgroup read-crc-pipe-b-frame-sequence:
>                 pass       -> DMESG-FAIL (skl-i7k-2)
> Test prime_self_import:
>         Subgroup basic-with_two_bos:
>                 pass       -> DMESG-WARN (skl-i7k-2)

Looks like the GPU died or something on that skl. Can't imagine it being related
to watermark patches.

Unfortunately these didn't cure the recent underrun regressions from
the ilk-ivb machines. So seems like there's something more busted
somewhere.

> 
> bdw-nuci7        total:138  pass:129  dwarn:0   dfail:0   fail:0   skip:9  
> bdw-ultra        total:138  pass:131  dwarn:1   dfail:0   fail:0   skip:6  
> bsw-nuc-2        total:141  pass:115  dwarn:2   dfail:0   fail:0   skip:24 
> hsw-brixbox      total:141  pass:134  dwarn:0   dfail:0   fail:0   skip:7  
> hsw-gt2          total:141  pass:137  dwarn:0   dfail:0   fail:0   skip:4  
> ilk-hp8440p      total:141  pass:101  dwarn:3   dfail:0   fail:0   skip:37 
> ivb-t430s        total:135  pass:122  dwarn:3   dfail:4   fail:0   skip:6  
> skl-i5k-2        total:141  pass:132  dwarn:1   dfail:0   fail:0   skip:8  
> skl-i7k-2        total:141  pass:108  dwarn:20  dfail:4   fail:0   skip:8  
> snb-dellxps      total:141  pass:122  dwarn:5   dfail:0   fail:0   skip:14 
> snb-x220t        total:141  pass:122  dwarn:5   dfail:0   fail:1   skip:13 
> 
> Results at /archive/results/CI_IGT_test/Patchwork_1187/

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

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

* ✗ failure: Fi.CI.BAT
  2016-01-14 12:53 [PATCH 1/2] drm/i915: Start WM computation from scratch on ILK-BDW ville.syrjala
@ 2016-01-14 14:20 ` Patchwork
  2016-01-14 14:29   ` Ville Syrjälä
  0 siblings, 1 reply; 118+ messages in thread
From: Patchwork @ 2016-01-14 14:20 UTC (permalink / raw)
  To: ville.syrjala; +Cc: intel-gfx

== Summary ==

Built on 8fb2feecca499d11e104264071ac55e273e23af5 drm-intel-nightly: 2016y-01m-14d-13h-06m-44s UTC integration manifest

Test gem_basic:
        Subgroup create-close:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_cpu_reloc:
        Subgroup basic:
                pass       -> DMESG-FAIL (skl-i7k-2)
Test gem_ctx_param_basic:
        Subgroup basic:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup invalid-param-set:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup non-root-set-no-zeromap:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup root-set-no-zeromap-disabled:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_mmap:
        Subgroup basic:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_mmap_gtt:
        Subgroup basic-read:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup basic-write:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_storedw_loop:
        Subgroup basic-render:
                dmesg-warn -> PASS       (skl-i5k-2) UNSTABLE
                dmesg-warn -> PASS       (bdw-nuci7)
                dmesg-warn -> PASS       (skl-i7k-2) UNSTABLE
Test kms_addfb_basic:
        Subgroup addfb25-modifier-no-flag:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup addfb25-x-tiled-mismatch:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup addfb25-yf-tiled:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup bad-pitch-1024:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup bad-pitch-63:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup bad-pitch-999:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup clobberred-modifier:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup too-high:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup too-wide:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup unused-offsets:
                pass       -> DMESG-WARN (skl-i7k-2)
Test kms_flip:
        Subgroup basic-plain-flip:
                pass       -> DMESG-FAIL (skl-i7k-2)
Test kms_pipe_crc_basic:
        Subgroup nonblocking-crc-pipe-a-frame-sequence:
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup read-crc-pipe-b-frame-sequence:
                pass       -> DMESG-FAIL (skl-i7k-2)
Test prime_self_import:
        Subgroup basic-with_two_bos:
                pass       -> DMESG-WARN (skl-i7k-2)

bdw-nuci7        total:138  pass:129  dwarn:0   dfail:0   fail:0   skip:9  
bdw-ultra        total:138  pass:131  dwarn:1   dfail:0   fail:0   skip:6  
bsw-nuc-2        total:141  pass:115  dwarn:2   dfail:0   fail:0   skip:24 
hsw-brixbox      total:141  pass:134  dwarn:0   dfail:0   fail:0   skip:7  
hsw-gt2          total:141  pass:137  dwarn:0   dfail:0   fail:0   skip:4  
ilk-hp8440p      total:141  pass:101  dwarn:3   dfail:0   fail:0   skip:37 
ivb-t430s        total:135  pass:122  dwarn:3   dfail:4   fail:0   skip:6  
skl-i5k-2        total:141  pass:132  dwarn:1   dfail:0   fail:0   skip:8  
skl-i7k-2        total:141  pass:108  dwarn:20  dfail:4   fail:0   skip:8  
snb-dellxps      total:141  pass:122  dwarn:5   dfail:0   fail:0   skip:14 
snb-x220t        total:141  pass:122  dwarn:5   dfail:0   fail:1   skip:13 

Results at /archive/results/CI_IGT_test/Patchwork_1187/

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

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

* ✗ failure: Fi.CI.BAT
  2016-01-14 10:49 [PATCH] drm/i915: Clear pending reset requests during suspend Arun Siluvery
@ 2016-01-14 12:20 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-14 12:20 UTC (permalink / raw)
  To: arun.siluvery; +Cc: intel-gfx

== Summary ==

Built on 058740f8fced6851aeda34f366f5330322cd585f drm-intel-nightly: 2016y-01m-13d-17h-07m-44s UTC integration manifest

Test gem_ctx_basic:
                pass       -> FAIL       (bdw-ultra)

bdw-nuci7        total:138  pass:128  dwarn:1   dfail:0   fail:0   skip:9  
bdw-ultra        total:138  pass:131  dwarn:0   dfail:0   fail:1   skip:6  
bsw-nuc-2        total:141  pass:115  dwarn:2   dfail:0   fail:0   skip:24 
hsw-brixbox      total:141  pass:134  dwarn:0   dfail:0   fail:0   skip:7  
hsw-gt2          total:141  pass:137  dwarn:0   dfail:0   fail:0   skip:4  
ilk-hp8440p      total:141  pass:100  dwarn:4   dfail:0   fail:0   skip:37 
ivb-t430s        total:135  pass:122  dwarn:3   dfail:4   fail:0   skip:6  
skl-i7k-2        total:141  pass:131  dwarn:2   dfail:0   fail:0   skip:8  
snb-dellxps      total:141  pass:122  dwarn:5   dfail:0   fail:0   skip:14 
snb-x220t        total:141  pass:122  dwarn:5   dfail:0   fail:1   skip:13 

Results at /archive/results/CI_IGT_test/Patchwork_1184/

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

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

* Re: ✗ failure: Fi.CI.BAT
  2016-01-14  7:20 ` ✗ failure: Fi.CI.BAT Patchwork
@ 2016-01-14 11:31   ` Nick Hoath
  2016-01-19  9:08     ` Daniel Vetter
  0 siblings, 1 reply; 118+ messages in thread
From: Nick Hoath @ 2016-01-14 11:31 UTC (permalink / raw)
  To: Patchwork; +Cc: intel-gfx

On 14/01/2016 07:20, Patchwork wrote:
> == Summary ==
>
> Built on 058740f8fced6851aeda34f366f5330322cd585f drm-intel-nightly: 2016y-01m-13d-17h-07m-44s UTC integration manifest
>
> Test gem_ctx_basic:
>                  pass       -> FAIL       (bdw-ultra)

Test failed to load - not patch related

> Test gem_ctx_param_basic:
>          Subgroup non-root-set:
>                  pass       -> DMESG-WARN (bsw-nuc-2)

gem driver allocated a poisoned slab - not patch related

> Test kms_flip:
>          Subgroup basic-flip-vs-dpms:
>                  pass       -> SKIP       (bsw-nuc-2)

test reqs not met - not patch related

>                  dmesg-warn -> PASS       (ilk-hp8440p)

warn to PASS

>
> bdw-nuci7        total:138  pass:128  dwarn:1   dfail:0   fail:0   skip:9
> bdw-ultra        total:138  pass:131  dwarn:0   dfail:0   fail:1   skip:6
> bsw-nuc-2        total:141  pass:113  dwarn:3   dfail:0   fail:0   skip:25
> hsw-brixbox      total:141  pass:134  dwarn:0   dfail:0   fail:0   skip:7
> hsw-gt2          total:141  pass:137  dwarn:0   dfail:0   fail:0   skip:4
> ilk-hp8440p      total:141  pass:101  dwarn:3   dfail:0   fail:0   skip:37
> ivb-t430s        total:135  pass:122  dwarn:3   dfail:4   fail:0   skip:6
> skl-i5k-2        total:141  pass:131  dwarn:2   dfail:0   fail:0   skip:8
> skl-i7k-2        total:141  pass:131  dwarn:2   dfail:0   fail:0   skip:8
> snb-dellxps      total:141  pass:122  dwarn:5   dfail:0   fail:0   skip:14
> snb-x220t        total:141  pass:122  dwarn:5   dfail:0   fail:1   skip:13
>
> Results at /archive/results/CI_IGT_test/Patchwork_1174/
>

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

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

* ✗ failure: Fi.CI.BAT
  2016-01-13 17:28 [PATCH 00/20] TDR/watchdog support for gen8 Arun Siluvery
@ 2016-01-14  8:30 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-14  8:30 UTC (permalink / raw)
  To: Tomas Elf; +Cc: intel-gfx

== Summary ==

HEAD is now at 058740f drm-intel-nightly: 2016y-01m-13d-17h-07m-44s UTC integration manifest
Applying: drm/i915: Make i915_gem_reset_ring_status() public
Applying: drm/i915: Generalise common GPU engine reset request/unrequest code
Applying: drm/i915: TDR / per-engine hang recovery support for gen8.
Using index info to reconstruct a base tree...
M	drivers/gpu/drm/i915/i915_dma.c
M	drivers/gpu/drm/i915/i915_irq.c
M	drivers/gpu/drm/i915/intel_lrc.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_lrc.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_lrc.c
Auto-merging drivers/gpu/drm/i915/i915_irq.c
Auto-merging drivers/gpu/drm/i915/i915_dma.c
Patch failed at 0003 drm/i915: TDR / per-engine hang recovery support for gen8.

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

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

* ✗ failure: Fi.CI.BAT
  2016-01-13 16:19 [PATCH v10] drm/i915: Extend LRC pinning to cover GPU context writeback Nick Hoath
@ 2016-01-14  7:20 ` Patchwork
  2016-01-14 11:31   ` Nick Hoath
  0 siblings, 1 reply; 118+ messages in thread
From: Patchwork @ 2016-01-14  7:20 UTC (permalink / raw)
  To: Nick Hoath; +Cc: intel-gfx

== Summary ==

Built on 058740f8fced6851aeda34f366f5330322cd585f drm-intel-nightly: 2016y-01m-13d-17h-07m-44s UTC integration manifest

Test gem_ctx_basic:
                pass       -> FAIL       (bdw-ultra)
Test gem_ctx_param_basic:
        Subgroup non-root-set:
                pass       -> DMESG-WARN (bsw-nuc-2)
Test kms_flip:
        Subgroup basic-flip-vs-dpms:
                pass       -> SKIP       (bsw-nuc-2)
                dmesg-warn -> PASS       (ilk-hp8440p)

bdw-nuci7        total:138  pass:128  dwarn:1   dfail:0   fail:0   skip:9  
bdw-ultra        total:138  pass:131  dwarn:0   dfail:0   fail:1   skip:6  
bsw-nuc-2        total:141  pass:113  dwarn:3   dfail:0   fail:0   skip:25 
hsw-brixbox      total:141  pass:134  dwarn:0   dfail:0   fail:0   skip:7  
hsw-gt2          total:141  pass:137  dwarn:0   dfail:0   fail:0   skip:4  
ilk-hp8440p      total:141  pass:101  dwarn:3   dfail:0   fail:0   skip:37 
ivb-t430s        total:135  pass:122  dwarn:3   dfail:4   fail:0   skip:6  
skl-i5k-2        total:141  pass:131  dwarn:2   dfail:0   fail:0   skip:8  
skl-i7k-2        total:141  pass:131  dwarn:2   dfail:0   fail:0   skip:8  
snb-dellxps      total:141  pass:122  dwarn:5   dfail:0   fail:0   skip:14 
snb-x220t        total:141  pass:122  dwarn:5   dfail:0   fail:1   skip:13 

Results at /archive/results/CI_IGT_test/Patchwork_1174/

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

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

* Re: ✗ failure:   Fi.CI.BAT
  2016-01-13 16:17   ` Daniel Vetter
@ 2016-01-13 18:03     ` Chris Wilson
  0 siblings, 0 replies; 118+ messages in thread
From: Chris Wilson @ 2016-01-13 18:03 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: Jani Nikula, intel-gfx

On Wed, Jan 13, 2016 at 05:17:03PM +0100, Daniel Vetter wrote:
> On Wed, Jan 13, 2016 at 03:13:40PM -0000, Patchwork wrote:
> > == Summary ==
> > 
> > Built on 4d09810b01441f9124c072a866f608b748f92f6c drm-intel-nightly: 2016y-01m-13d-12h-32m-08s UTC integration manifest
> > 
> > Test gem_ctx_basic:
> >                 pass       -> FAIL       (hsw-gt2)
> 
> This seems to be a complete fluke. I looked at detailed results and
> there's simply no output. Long-term history doesn't show a failure either.
> 
> I think we can shrug this one off (for now at least).
> 
> > Test gem_storedw_loop:
> >         Subgroup basic-render:
> >                 dmesg-warn -> PASS       (skl-i7k-2) UNSTABLE
> > Test kms_pipe_crc_basic:
> >         Subgroup read-crc-pipe-c:
> >                 pass       -> DMESG-WARN (bdw-ultra)
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=93699
> 
> So looks good, I'll apply the patch.

It still does a blocking context-close when all it need do is keep the
last-context pinned until replaced.
-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

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

* Re: ✗ failure:  Fi.CI.BAT
  2016-01-13 15:13 ` ✗ failure: Fi.CI.BAT Patchwork
@ 2016-01-13 16:17   ` Daniel Vetter
  2016-01-13 18:03     ` Chris Wilson
  0 siblings, 1 reply; 118+ messages in thread
From: Daniel Vetter @ 2016-01-13 16:17 UTC (permalink / raw)
  To: Patchwork; +Cc: Jani Nikula, intel-gfx

On Wed, Jan 13, 2016 at 03:13:40PM -0000, Patchwork wrote:
> == Summary ==
> 
> Built on 4d09810b01441f9124c072a866f608b748f92f6c drm-intel-nightly: 2016y-01m-13d-12h-32m-08s UTC integration manifest
> 
> Test gem_ctx_basic:
>                 pass       -> FAIL       (hsw-gt2)

This seems to be a complete fluke. I looked at detailed results and
there's simply no output. Long-term history doesn't show a failure either.

I think we can shrug this one off (for now at least).

> Test gem_storedw_loop:
>         Subgroup basic-render:
>                 dmesg-warn -> PASS       (skl-i7k-2) UNSTABLE
> Test kms_pipe_crc_basic:
>         Subgroup read-crc-pipe-c:
>                 pass       -> DMESG-WARN (bdw-ultra)

https://bugs.freedesktop.org/show_bug.cgi?id=93699

So looks good, I'll apply the patch.
-Daniel

> 
> bdw-nuci7        total:138  pass:129  dwarn:0   dfail:0   fail:0   skip:9  
> bdw-ultra        total:138  pass:131  dwarn:1   dfail:0   fail:0   skip:6  
> bsw-nuc-2        total:141  pass:115  dwarn:2   dfail:0   fail:0   skip:24 
> hsw-brixbox      total:141  pass:134  dwarn:0   dfail:0   fail:0   skip:7  
> hsw-gt2          total:141  pass:136  dwarn:0   dfail:0   fail:1   skip:4  
> hsw-xps12        total:138  pass:133  dwarn:1   dfail:0   fail:0   skip:4  
> ilk-hp8440p      total:141  pass:100  dwarn:4   dfail:0   fail:0   skip:37 
> ivb-t430s        total:135  pass:122  dwarn:3   dfail:4   fail:0   skip:6  
> skl-i5k-2        total:141  pass:132  dwarn:1   dfail:0   fail:0   skip:8  
> skl-i7k-2        total:141  pass:132  dwarn:1   dfail:0   fail:0   skip:8  
> snb-dellxps      total:141  pass:122  dwarn:5   dfail:0   fail:0   skip:14 
> snb-x220t        total:141  pass:122  dwarn:5   dfail:0   fail:1   skip:13 
> 
> Results at /archive/results/CI_IGT_test/Patchwork_1170/
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* ✗ failure: Fi.CI.BAT
  2016-01-13 14:35 [PATCH] drm/i915/dp: fall back to 18 bpp when sink capability is unknown Jani Nikula
@ 2016-01-13 15:13 ` Patchwork
  2016-01-13 16:17   ` Daniel Vetter
  0 siblings, 1 reply; 118+ messages in thread
From: Patchwork @ 2016-01-13 15:13 UTC (permalink / raw)
  To: Jani Nikula; +Cc: intel-gfx

== Summary ==

Built on 4d09810b01441f9124c072a866f608b748f92f6c drm-intel-nightly: 2016y-01m-13d-12h-32m-08s UTC integration manifest

Test gem_ctx_basic:
                pass       -> FAIL       (hsw-gt2)
Test gem_storedw_loop:
        Subgroup basic-render:
                dmesg-warn -> PASS       (skl-i7k-2) UNSTABLE
Test kms_pipe_crc_basic:
        Subgroup read-crc-pipe-c:
                pass       -> DMESG-WARN (bdw-ultra)

bdw-nuci7        total:138  pass:129  dwarn:0   dfail:0   fail:0   skip:9  
bdw-ultra        total:138  pass:131  dwarn:1   dfail:0   fail:0   skip:6  
bsw-nuc-2        total:141  pass:115  dwarn:2   dfail:0   fail:0   skip:24 
hsw-brixbox      total:141  pass:134  dwarn:0   dfail:0   fail:0   skip:7  
hsw-gt2          total:141  pass:136  dwarn:0   dfail:0   fail:1   skip:4  
hsw-xps12        total:138  pass:133  dwarn:1   dfail:0   fail:0   skip:4  
ilk-hp8440p      total:141  pass:100  dwarn:4   dfail:0   fail:0   skip:37 
ivb-t430s        total:135  pass:122  dwarn:3   dfail:4   fail:0   skip:6  
skl-i5k-2        total:141  pass:132  dwarn:1   dfail:0   fail:0   skip:8  
skl-i7k-2        total:141  pass:132  dwarn:1   dfail:0   fail:0   skip:8  
snb-dellxps      total:141  pass:122  dwarn:5   dfail:0   fail:0   skip:14 
snb-x220t        total:141  pass:122  dwarn:5   dfail:0   fail:1   skip:13 

Results at /archive/results/CI_IGT_test/Patchwork_1170/

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

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

* ✗ failure: Fi.CI.BAT
  2016-01-13 12:52 [PATCH] drm/i915: Fix for reserved space WARN_ON when ring begin fails John.C.Harrison
@ 2016-01-13 13:49 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-13 13:49 UTC (permalink / raw)
  To: John.C.Harrison; +Cc: intel-gfx

== Summary ==

Built on 4d09810b01441f9124c072a866f608b748f92f6c drm-intel-nightly: 2016y-01m-13d-12h-32m-08s UTC integration manifest

Test gem_basic:
        Subgroup create-close:
                pass       -> DMESG-WARN (skl-i5k-2)
Test gem_cpu_reloc:
        Subgroup basic:
                pass       -> DMESG-FAIL (skl-i5k-2)
Test gem_ctx_param_basic:
        Subgroup basic:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup invalid-param-set:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup non-root-set-no-zeromap:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup root-set-no-zeromap-disabled:
                pass       -> DMESG-WARN (skl-i5k-2)
Test gem_mmap:
        Subgroup basic:
                pass       -> DMESG-WARN (skl-i5k-2)
Test gem_mmap_gtt:
        Subgroup basic-read:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup basic-write:
                pass       -> DMESG-WARN (skl-i5k-2)
Test gem_storedw_loop:
        Subgroup basic-render:
                pass       -> DMESG-WARN (skl-i5k-2) UNSTABLE
                pass       -> DMESG-WARN (bdw-nuci7)
                pass       -> DMESG-WARN (bdw-ultra)
Test kms_addfb_basic:
        Subgroup addfb25-modifier-no-flag:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup addfb25-x-tiled-mismatch:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup addfb25-yf-tiled:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup bad-pitch-1024:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup bad-pitch-63:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup bad-pitch-999:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup clobberred-modifier:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup too-high:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup too-wide:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup unused-offsets:
                pass       -> DMESG-WARN (skl-i5k-2)
Test kms_flip:
        Subgroup basic-plain-flip:
                pass       -> DMESG-FAIL (skl-i5k-2)
Test kms_pipe_crc_basic:
        Subgroup nonblocking-crc-pipe-a-frame-sequence:
                pass       -> DMESG-FAIL (skl-i5k-2)
        Subgroup read-crc-pipe-b:
                pass       -> DMESG-WARN (ilk-hp8440p)
        Subgroup read-crc-pipe-b-frame-sequence:
                pass       -> DMESG-FAIL (skl-i5k-2)
Test prime_self_import:
        Subgroup basic-with_two_bos:
                pass       -> DMESG-WARN (skl-i5k-2)

bdw-nuci7        total:138  pass:128  dwarn:1   dfail:0   fail:0   skip:9  
bdw-ultra        total:138  pass:131  dwarn:1   dfail:0   fail:0   skip:6  
bsw-nuc-2        total:141  pass:115  dwarn:2   dfail:0   fail:0   skip:24 
hsw-brixbox      total:141  pass:134  dwarn:0   dfail:0   fail:0   skip:7  
hsw-gt2          total:141  pass:137  dwarn:0   dfail:0   fail:0   skip:4  
ilk-hp8440p      total:141  pass:99   dwarn:5   dfail:0   fail:0   skip:37 
ivb-t430s        total:135  pass:122  dwarn:3   dfail:4   fail:0   skip:6  
skl-i5k-2        total:141  pass:107  dwarn:21  dfail:4   fail:0   skip:8  
skl-i7k-2        total:141  pass:131  dwarn:2   dfail:0   fail:0   skip:8  
snb-dellxps      total:141  pass:122  dwarn:5   dfail:0   fail:0   skip:14 
snb-x220t        total:141  pass:122  dwarn:5   dfail:0   fail:1   skip:13 

Results at /archive/results/CI_IGT_test/Patchwork_1165/

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

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

* Re: ✗ failure: Fi.CI.BAT
  2016-01-13  9:39         ` Daniel Vetter
@ 2016-01-13  9:39           ` Daniel Vetter
  0 siblings, 0 replies; 118+ messages in thread
From: Daniel Vetter @ 2016-01-13  9:39 UTC (permalink / raw)
  To: Mika Kuoppala, annie.j.matheson, Barnes, Jesse; +Cc: intel-gfx

Argh, actually add Annie/Jesse!
-Daniel

On Wed, Jan 13, 2016 at 10:39 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Wed, Jan 13, 2016 at 10:20 AM, Mika Kuoppala
> <mika.kuoppala@linux.intel.com> wrote:
>>> But what with all the pass->dmesg-warn changes above? That's considered
>>> BAT failure too, we can't afford to sprinkle warnings all over ... And
>>> it's a bunch of different machines.
>>>
>>
>> Forgot to address this one in previous mail. This patchset
>> added more debug infra and enabled it for bsw/byt. So assumpion
>> is that it did uncover a real problem thus the warns.
>>
>> Is the policy that if your debug infra reveals problems,
>> you need to fix those problems?
>
> We should discuss this in the next meeting (adding Annie/Jesse for
> that), but personally I think adding new WARN/ERROR noise should never
> result in BAT regressions. If your patch uncovers existing failures
> even in BAT then imo the right approach is to first fix up things,
> then apply the WARN patch to make sure we don't break things. The
> problem is that once you have dmesg noise in a test, then no one will
> notice additional noise and regressions. And that's how we got into
> our mess last summer.
>
> Also dmesg noise is not really acceptable anyway and needs to be fixed
> (Linus/Dave will get grumpy).
>
> If that takes too long because there's lots of warn, then maybe we
> need to first add the new sanity check at debug level, just to help
> with tracking down issues. We might need to improve CI reporting so
> that debug level dmesg is still capture completely for BAT runs.
>
>> If so, there is a chicken and egg problem as you don't
>> always have access to hardware that your debug infra
>> will cover.
>
> Yeah, we need to enable manual submission to CI-machines. Abusing CI
> as a test facility simply means that you're ok with blocking everyone
> else with your CI result spam.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch



-- 
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

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

* Re: ✗ failure: Fi.CI.BAT
  2016-01-13  9:20       ` Mika Kuoppala
@ 2016-01-13  9:39         ` Daniel Vetter
  2016-01-13  9:39           ` Daniel Vetter
  0 siblings, 1 reply; 118+ messages in thread
From: Daniel Vetter @ 2016-01-13  9:39 UTC (permalink / raw)
  To: Mika Kuoppala; +Cc: intel-gfx

On Wed, Jan 13, 2016 at 10:20 AM, Mika Kuoppala
<mika.kuoppala@linux.intel.com> wrote:
>> But what with all the pass->dmesg-warn changes above? That's considered
>> BAT failure too, we can't afford to sprinkle warnings all over ... And
>> it's a bunch of different machines.
>>
>
> Forgot to address this one in previous mail. This patchset
> added more debug infra and enabled it for bsw/byt. So assumpion
> is that it did uncover a real problem thus the warns.
>
> Is the policy that if your debug infra reveals problems,
> you need to fix those problems?

We should discuss this in the next meeting (adding Annie/Jesse for
that), but personally I think adding new WARN/ERROR noise should never
result in BAT regressions. If your patch uncovers existing failures
even in BAT then imo the right approach is to first fix up things,
then apply the WARN patch to make sure we don't break things. The
problem is that once you have dmesg noise in a test, then no one will
notice additional noise and regressions. And that's how we got into
our mess last summer.

Also dmesg noise is not really acceptable anyway and needs to be fixed
(Linus/Dave will get grumpy).

If that takes too long because there's lots of warn, then maybe we
need to first add the new sanity check at debug level, just to help
with tracking down issues. We might need to improve CI reporting so
that debug level dmesg is still capture completely for BAT runs.

> If so, there is a chicken and egg problem as you don't
> always have access to hardware that your debug infra
> will cover.

Yeah, we need to enable manual submission to CI-machines. Abusing CI
as a test facility simply means that you're ok with blocking everyone
else with your CI result spam.
-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

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

* Re: ✗ failure: Fi.CI.BAT
  2016-01-12 16:22     ` Daniel Vetter
  2016-01-13  9:16       ` Mika Kuoppala
@ 2016-01-13  9:20       ` Mika Kuoppala
  2016-01-13  9:39         ` Daniel Vetter
  1 sibling, 1 reply; 118+ messages in thread
From: Mika Kuoppala @ 2016-01-13  9:20 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

Daniel Vetter <daniel@ffwll.ch> writes:

> On Mon, Jan 11, 2016 at 02:50:28PM +0200, Mika Kuoppala wrote:
>> Patchwork <patchwork@annarchy.freedesktop.org> writes:
>> 
>> > == Summary ==
>> >
>> > Built on ff88655b3a5467bbc3be8c67d3e05ebf182557d3 drm-intel-nightly: 2016y-01m-11d-07h-30m-16s UTC integration manifest
>> >
>> > Test gem_storedw_loop:
>> >         Subgroup basic-render:
>> >                 pass       -> DMESG-WARN (skl-i5k-2) UNSTABLE
>> >                 dmesg-warn -> PASS       (bdw-ultra)
>> > Test kms_flip:
>> >         Subgroup basic-flip-vs-dpms:
>> >                 dmesg-warn -> PASS       (ilk-hp8440p)
>> >         Subgroup basic-flip-vs-modeset:
>> >                 pass       -> DMESG-WARN (skl-i5k-2)
>> >                 dmesg-warn -> PASS       (bsw-nuc-2)
>> >                 pass       -> DMESG-WARN (ilk-hp8440p)
>> >                 dmesg-warn -> PASS       (byt-nuc)
>> >         Subgroup basic-flip-vs-wf_vblank:
>> >                 pass       -> DMESG-WARN (byt-nuc)
>> >         Subgroup basic-plain-flip:
>> >                 dmesg-warn -> PASS       (bsw-nuc-2)
>> >                 dmesg-warn -> PASS       (byt-nuc)
>> > Test kms_pipe_crc_basic:
>> >         Subgroup nonblocking-crc-pipe-b:
>> >                 pass       -> DMESG-WARN (byt-nuc)
>> >         Subgroup nonblocking-crc-pipe-c:
>> >                 pass       -> DMESG-WARN (bsw-nuc-2)
>> >         Subgroup read-crc-pipe-a:
>> >                 dmesg-warn -> PASS       (byt-nuc)
>> >         Subgroup read-crc-pipe-b:
>> >                 dmesg-warn -> PASS       (byt-nuc)
>> >         Subgroup read-crc-pipe-b-frame-sequence:
>> >                 pass       -> DMESG-WARN (bdw-ultra)
>> >                 dmesg-warn -> PASS       (byt-nuc)
>> >         Subgroup read-crc-pipe-c:
>> >                 dmesg-warn -> PASS       (bsw-nuc-2)
>> >         Subgroup read-crc-pipe-c-frame-sequence:
>> >                 pass       -> DMESG-WARN (bsw-nuc-2)
>
> But what with all the pass->dmesg-warn changes above? That's considered
> BAT failure too, we can't afford to sprinkle warnings all over ... And
> it's a bunch of different machines.
>

Forgot to address this one in previous mail. This patchset
added more debug infra and enabled it for bsw/byt. So assumpion
is that it did uncover a real problem thus the warns.

Is the policy that if your debug infra reveals problems,
you need to fix those problems?

If so, there is a chicken and egg problem as you don't
always have access to hardware that your debug infra
will cover.

Thanks,
-Mika


>> > Test pm_rpm:
>> >         Subgroup basic-pci-d3-state:
>> >                 dmesg-warn -> PASS       (byt-nuc)
>> >
>> > bdw-ultra        total:138  pass:130  dwarn:1   dfail:0   fail:1
>> > skip:6
>> 
>> Tomi suspected this as a fluke fail. There was no igt stdout nor stderr
>> for this case. We did a rerun and bdw-ultra passed.
>> 
>> -Mika
>> 
>> > bsw-nuc-2        total:141  pass:115  dwarn:2   dfail:0   fail:0   skip:24 
>> > byt-nuc          total:141  pass:122  dwarn:4   dfail:0   fail:0   skip:15 
>> > hsw-brixbox      total:141  pass:134  dwarn:0   dfail:0   fail:0   skip:7  
>> > hsw-gt2          total:141  pass:137  dwarn:0   dfail:0   fail:0   skip:4  
>> > ilk-hp8440p      total:141  pass:100  dwarn:4   dfail:0   fail:0   skip:37 
>> > skl-i5k-2        total:141  pass:130  dwarn:3   dfail:0   fail:0   skip:8  
>> > skl-i7k-2        total:141  pass:131  dwarn:2   dfail:0   fail:0   skip:8  
>> > snb-dellxps      total:141  pass:122  dwarn:5   dfail:0   fail:0   skip:14 
>> > snb-x220t        total:141  pass:122  dwarn:5   dfail:0   fail:1   skip:13 
>> >
>> > HANGED ivb-t430s in igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b
>
> So is killing a machine ... pretty sure this is new-ish.
> -Daniel
>
>
>> >
>> > Results at /archive/results/CI_IGT_test/Patchwork_1116/
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: ✗ failure: Fi.CI.BAT
  2016-01-12 16:22     ` Daniel Vetter
@ 2016-01-13  9:16       ` Mika Kuoppala
  2016-01-13  9:20       ` Mika Kuoppala
  1 sibling, 0 replies; 118+ messages in thread
From: Mika Kuoppala @ 2016-01-13  9:16 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

Daniel Vetter <daniel@ffwll.ch> writes:

> On Mon, Jan 11, 2016 at 02:50:28PM +0200, Mika Kuoppala wrote:
>> Patchwork <patchwork@annarchy.freedesktop.org> writes:
>> 
>> > == Summary ==
>> >
>> > Built on ff88655b3a5467bbc3be8c67d3e05ebf182557d3 drm-intel-nightly: 2016y-01m-11d-07h-30m-16s UTC integration manifest
>> >
>> > Test gem_storedw_loop:
>> >         Subgroup basic-render:
>> >                 pass       -> DMESG-WARN (skl-i5k-2) UNSTABLE
>> >                 dmesg-warn -> PASS       (bdw-ultra)
>> > Test kms_flip:
>> >         Subgroup basic-flip-vs-dpms:
>> >                 dmesg-warn -> PASS       (ilk-hp8440p)
>> >         Subgroup basic-flip-vs-modeset:
>> >                 pass       -> DMESG-WARN (skl-i5k-2)
>> >                 dmesg-warn -> PASS       (bsw-nuc-2)
>> >                 pass       -> DMESG-WARN (ilk-hp8440p)
>> >                 dmesg-warn -> PASS       (byt-nuc)
>> >         Subgroup basic-flip-vs-wf_vblank:
>> >                 pass       -> DMESG-WARN (byt-nuc)
>> >         Subgroup basic-plain-flip:
>> >                 dmesg-warn -> PASS       (bsw-nuc-2)
>> >                 dmesg-warn -> PASS       (byt-nuc)
>> > Test kms_pipe_crc_basic:
>> >         Subgroup nonblocking-crc-pipe-b:
>> >                 pass       -> DMESG-WARN (byt-nuc)
>> >         Subgroup nonblocking-crc-pipe-c:
>> >                 pass       -> DMESG-WARN (bsw-nuc-2)
>> >         Subgroup read-crc-pipe-a:
>> >                 dmesg-warn -> PASS       (byt-nuc)
>> >         Subgroup read-crc-pipe-b:
>> >                 dmesg-warn -> PASS       (byt-nuc)
>> >         Subgroup read-crc-pipe-b-frame-sequence:
>> >                 pass       -> DMESG-WARN (bdw-ultra)
>> >                 dmesg-warn -> PASS       (byt-nuc)
>> >         Subgroup read-crc-pipe-c:
>> >                 dmesg-warn -> PASS       (bsw-nuc-2)
>> >         Subgroup read-crc-pipe-c-frame-sequence:
>> >                 pass       -> DMESG-WARN (bsw-nuc-2)
>
> But what with all the pass->dmesg-warn changes above? That's considered
> BAT failure too, we can't afford to sprinkle warnings all over ... And
> it's a bunch of different machines.
>
>> > Test pm_rpm:
>> >         Subgroup basic-pci-d3-state:
>> >                 dmesg-warn -> PASS       (byt-nuc)
>> >
>> > bdw-ultra        total:138  pass:130  dwarn:1   dfail:0   fail:1
>> > skip:6
>> 
>> Tomi suspected this as a fluke fail. There was no igt stdout nor stderr
>> for this case. We did a rerun and bdw-ultra passed.
>> 
>> -Mika
>> 
>> > bsw-nuc-2        total:141  pass:115  dwarn:2   dfail:0   fail:0   skip:24 
>> > byt-nuc          total:141  pass:122  dwarn:4   dfail:0   fail:0   skip:15 
>> > hsw-brixbox      total:141  pass:134  dwarn:0   dfail:0   fail:0   skip:7  
>> > hsw-gt2          total:141  pass:137  dwarn:0   dfail:0   fail:0   skip:4  
>> > ilk-hp8440p      total:141  pass:100  dwarn:4   dfail:0   fail:0   skip:37 
>> > skl-i5k-2        total:141  pass:130  dwarn:3   dfail:0   fail:0   skip:8  
>> > skl-i7k-2        total:141  pass:131  dwarn:2   dfail:0   fail:0   skip:8  
>> > snb-dellxps      total:141  pass:122  dwarn:5   dfail:0   fail:0   skip:14 
>> > snb-x220t        total:141  pass:122  dwarn:5   dfail:0   fail:1   skip:13 
>> >
>> > HANGED ivb-t430s in igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b
>
> So is killing a machine ... pretty sure this is new-ish.
> -Daniel
>

I did cover my back with this one. This happened on other sets
on the same day and I went and asked Tomi. He said that don't
worry about it. So I didn't.

-Mika

>
>> >
>> > Results at /archive/results/CI_IGT_test/Patchwork_1116/
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* ✗ failure: Fi.CI.BAT
  2016-01-06 20:53 [PATCH] drm/i915/guc: Fix a memory leak where guc->execbuf_client is not freed yu.dai
@ 2016-01-13  8:49 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-13  8:49 UTC (permalink / raw)
  To: yu.dai; +Cc: intel-gfx

== Summary ==

Built on 06d0112e293dfdea7f796d4085f755898850947b drm-intel-nightly: 2016y-01m-12d-21h-16m-40s UTC integration manifest

Test gem_basic:
        Subgroup create-close:
                pass       -> DMESG-WARN (skl-i5k-2)
Test gem_cpu_reloc:
        Subgroup basic:
                pass       -> DMESG-FAIL (skl-i5k-2)
Test gem_ctx_param_basic:
        Subgroup basic:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup invalid-param-set:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup non-root-set-no-zeromap:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup root-set-no-zeromap-disabled:
                pass       -> DMESG-WARN (skl-i5k-2)
Test gem_mmap:
        Subgroup basic:
                pass       -> DMESG-WARN (skl-i5k-2)
Test gem_mmap_gtt:
        Subgroup basic-read:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup basic-write:
                pass       -> DMESG-WARN (skl-i5k-2)
Test gem_storedw_loop:
        Subgroup basic-render:
                dmesg-warn -> PASS       (bdw-ultra)
Test kms_addfb_basic:
        Subgroup addfb25-modifier-no-flag:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup addfb25-x-tiled-mismatch:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup addfb25-yf-tiled:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup bad-pitch-1024:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup bad-pitch-63:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup bad-pitch-999:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup clobberred-modifier:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup too-high:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup too-wide:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup unused-offsets:
                pass       -> DMESG-WARN (skl-i5k-2)
Test kms_flip:
        Subgroup basic-flip-vs-dpms:
                dmesg-warn -> PASS       (skl-i7k-2)
                dmesg-warn -> PASS       (ilk-hp8440p)
        Subgroup basic-flip-vs-modeset:
                pass       -> DMESG-WARN (ilk-hp8440p)
        Subgroup basic-plain-flip:
                pass       -> DMESG-FAIL (skl-i5k-2)
Test kms_pipe_crc_basic:
        Subgroup nonblocking-crc-pipe-a-frame-sequence:
                pass       -> DMESG-FAIL (skl-i5k-2)
        Subgroup read-crc-pipe-a-frame-sequence:
                fail       -> PASS       (snb-x220t)
        Subgroup read-crc-pipe-b-frame-sequence:
                pass       -> DMESG-FAIL (skl-i5k-2)
Test prime_self_import:
        Subgroup basic-with_two_bos:
                pass       -> DMESG-WARN (skl-i5k-2)

bdw-nuci7        total:138  pass:129  dwarn:0   dfail:0   fail:0   skip:9  
bdw-ultra        total:138  pass:132  dwarn:0   dfail:0   fail:0   skip:6  
bsw-nuc-2        total:141  pass:115  dwarn:2   dfail:0   fail:0   skip:24 
byt-nuc          total:141  pass:123  dwarn:3   dfail:0   fail:0   skip:15 
hsw-brixbox      total:141  pass:134  dwarn:0   dfail:0   fail:0   skip:7  
hsw-gt2          total:141  pass:137  dwarn:0   dfail:0   fail:0   skip:4  
ilk-hp8440p      total:141  pass:100  dwarn:4   dfail:0   fail:0   skip:37 
skl-i5k-2        total:141  pass:108  dwarn:20  dfail:4   fail:0   skip:8  
skl-i7k-2        total:141  pass:131  dwarn:2   dfail:0   fail:0   skip:8  
snb-dellxps      total:141  pass:122  dwarn:5   dfail:0   fail:0   skip:14 
snb-x220t        total:141  pass:122  dwarn:5   dfail:0   fail:1   skip:13 

Results at /archive/results/CI_IGT_test/Patchwork_1158/

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

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

* Re: ✗ failure: Fi.CI.BAT
  2016-01-11 11:20 ` ✗ failure: Fi.CI.BAT Patchwork
@ 2016-01-12 16:24   ` Daniel Vetter
  0 siblings, 0 replies; 118+ messages in thread
From: Daniel Vetter @ 2016-01-12 16:24 UTC (permalink / raw)
  To: Patchwork; +Cc: Daniel Vetter, intel-gfx

On Mon, Jan 11, 2016 at 11:20:21AM -0000, Patchwork wrote:
> == Summary ==
> 
> HEAD is now at ff88655 drm-intel-nightly: 2016y-01m-11d-07h-30m-16s UTC integration manifest
> Applying: drm: kerneldoc for drm_fops.c
> Repository lacks necessary blobs to fall back on 3-way merge.
> Cannot fall back to three-way merge.
> Patch failed at 0001 drm: kerneldoc for drm_fops.c

Can we please patchwork CI about patch -p1 or maybe even wiggle?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: ✗ failure:  Fi.CI.BAT
  2016-01-11 12:50   ` Mika Kuoppala
@ 2016-01-12 16:22     ` Daniel Vetter
  2016-01-13  9:16       ` Mika Kuoppala
  2016-01-13  9:20       ` Mika Kuoppala
  0 siblings, 2 replies; 118+ messages in thread
From: Daniel Vetter @ 2016-01-12 16:22 UTC (permalink / raw)
  To: Mika Kuoppala; +Cc: intel-gfx

On Mon, Jan 11, 2016 at 02:50:28PM +0200, Mika Kuoppala wrote:
> Patchwork <patchwork@annarchy.freedesktop.org> writes:
> 
> > == Summary ==
> >
> > Built on ff88655b3a5467bbc3be8c67d3e05ebf182557d3 drm-intel-nightly: 2016y-01m-11d-07h-30m-16s UTC integration manifest
> >
> > Test gem_storedw_loop:
> >         Subgroup basic-render:
> >                 pass       -> DMESG-WARN (skl-i5k-2) UNSTABLE
> >                 dmesg-warn -> PASS       (bdw-ultra)
> > Test kms_flip:
> >         Subgroup basic-flip-vs-dpms:
> >                 dmesg-warn -> PASS       (ilk-hp8440p)
> >         Subgroup basic-flip-vs-modeset:
> >                 pass       -> DMESG-WARN (skl-i5k-2)
> >                 dmesg-warn -> PASS       (bsw-nuc-2)
> >                 pass       -> DMESG-WARN (ilk-hp8440p)
> >                 dmesg-warn -> PASS       (byt-nuc)
> >         Subgroup basic-flip-vs-wf_vblank:
> >                 pass       -> DMESG-WARN (byt-nuc)
> >         Subgroup basic-plain-flip:
> >                 dmesg-warn -> PASS       (bsw-nuc-2)
> >                 dmesg-warn -> PASS       (byt-nuc)
> > Test kms_pipe_crc_basic:
> >         Subgroup nonblocking-crc-pipe-b:
> >                 pass       -> DMESG-WARN (byt-nuc)
> >         Subgroup nonblocking-crc-pipe-c:
> >                 pass       -> DMESG-WARN (bsw-nuc-2)
> >         Subgroup read-crc-pipe-a:
> >                 dmesg-warn -> PASS       (byt-nuc)
> >         Subgroup read-crc-pipe-b:
> >                 dmesg-warn -> PASS       (byt-nuc)
> >         Subgroup read-crc-pipe-b-frame-sequence:
> >                 pass       -> DMESG-WARN (bdw-ultra)
> >                 dmesg-warn -> PASS       (byt-nuc)
> >         Subgroup read-crc-pipe-c:
> >                 dmesg-warn -> PASS       (bsw-nuc-2)
> >         Subgroup read-crc-pipe-c-frame-sequence:
> >                 pass       -> DMESG-WARN (bsw-nuc-2)

But what with all the pass->dmesg-warn changes above? That's considered
BAT failure too, we can't afford to sprinkle warnings all over ... And
it's a bunch of different machines.

> > Test pm_rpm:
> >         Subgroup basic-pci-d3-state:
> >                 dmesg-warn -> PASS       (byt-nuc)
> >
> > bdw-ultra        total:138  pass:130  dwarn:1   dfail:0   fail:1
> > skip:6
> 
> Tomi suspected this as a fluke fail. There was no igt stdout nor stderr
> for this case. We did a rerun and bdw-ultra passed.
> 
> -Mika
> 
> > bsw-nuc-2        total:141  pass:115  dwarn:2   dfail:0   fail:0   skip:24 
> > byt-nuc          total:141  pass:122  dwarn:4   dfail:0   fail:0   skip:15 
> > hsw-brixbox      total:141  pass:134  dwarn:0   dfail:0   fail:0   skip:7  
> > hsw-gt2          total:141  pass:137  dwarn:0   dfail:0   fail:0   skip:4  
> > ilk-hp8440p      total:141  pass:100  dwarn:4   dfail:0   fail:0   skip:37 
> > skl-i5k-2        total:141  pass:130  dwarn:3   dfail:0   fail:0   skip:8  
> > skl-i7k-2        total:141  pass:131  dwarn:2   dfail:0   fail:0   skip:8  
> > snb-dellxps      total:141  pass:122  dwarn:5   dfail:0   fail:0   skip:14 
> > snb-x220t        total:141  pass:122  dwarn:5   dfail:0   fail:1   skip:13 
> >
> > HANGED ivb-t430s in igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b

So is killing a machine ... pretty sure this is new-ish.
-Daniel


> >
> > Results at /archive/results/CI_IGT_test/Patchwork_1116/
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* ✗ failure: Fi.CI.BAT
  2016-01-12 15:28 [PATCH 1/1] drm/i915: Reorder shadow registers on gen8 for faster lookup Mika Kuoppala
@ 2016-01-12 16:20 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-12 16:20 UTC (permalink / raw)
  To: Mika Kuoppala; +Cc: intel-gfx

== Summary ==

Built on 37f6c2ae666fbba9eff4355115252b8b0fd43050 drm-intel-nightly: 2016y-01m-12d-14h-25m-44s UTC integration manifest

Test gem_storedw_loop:
        Subgroup basic-render:
                pass       -> DMESG-WARN (skl-i5k-2) UNSTABLE
                dmesg-warn -> PASS       (bdw-nuci7)
                pass       -> DMESG-WARN (bdw-ultra)
Test kms_pipe_crc_basic:
        Subgroup read-crc-pipe-a-frame-sequence:
                dmesg-warn -> PASS       (byt-nuc)
        Subgroup read-crc-pipe-c:
                dmesg-warn -> PASS       (bdw-ultra)

bdw-nuci7        total:138  pass:129  dwarn:0   dfail:0   fail:0   skip:9  
bdw-ultra        total:138  pass:131  dwarn:1   dfail:0   fail:0   skip:6  
bsw-nuc-2        total:141  pass:115  dwarn:2   dfail:0   fail:0   skip:24 
byt-nuc          total:141  pass:123  dwarn:3   dfail:0   fail:0   skip:15 
hsw-brixbox      total:141  pass:134  dwarn:0   dfail:0   fail:0   skip:7  
hsw-xps12        total:138  pass:133  dwarn:1   dfail:0   fail:0   skip:4  
ilk-hp8440p      total:141  pass:101  dwarn:3   dfail:0   fail:0   skip:37 
ivb-t430s        total:135  pass:122  dwarn:3   dfail:4   fail:0   skip:6  
skl-i5k-2        total:141  pass:107  dwarn:26  dfail:0   fail:0   skip:8  
skl-i7k-2        total:141  pass:107  dwarn:26  dfail:0   fail:0   skip:8  
snb-dellxps      total:141  pass:122  dwarn:5   dfail:0   fail:0   skip:14 
snb-x220t        total:141  pass:122  dwarn:5   dfail:0   fail:1   skip:13 

HANGED hsw-gt2 in igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a

Results at /archive/results/CI_IGT_test/Patchwork_1152/

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

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

* ✗ failure: Fi.CI.BAT
  2016-01-11 21:40 [PATCH 00/22] drm_event cleanup, round 2 Daniel Vetter
@ 2016-01-12  8:30 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-12  8:30 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

== Summary ==

HEAD is now at a907968 drm-intel-nightly: 2016y-01m-11d-17h-22m-54s UTC integration manifest
Applying: drm: kerneldoc for drm_fops.c
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 drm: kerneldoc for drm_fops.c

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

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

* ✗ failure: Fi.CI.BAT
  2015-12-14 16:23 [PATCH 00/10] drm/i915: Fixes from my attempt at running igt on gen2 ville.syrjala
@ 2016-01-12  7:49 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-12  7:49 UTC (permalink / raw)
  To: ville.syrjala; +Cc: intel-gfx

== Summary ==

Built on a90796840c30dac6d9907439bf98d1d08046c49d drm-intel-nightly: 2016y-01m-11d-17h-22m-54s UTC integration manifest

Test gem_storedw_loop:
        Subgroup basic-render:
                pass       -> DMESG-WARN (skl-i5k-2) UNSTABLE
Test kms_pipe_crc_basic:
        Subgroup hang-read-crc-pipe-a:
                pass       -> FAIL       (hsw-gt2)
                pass       -> FAIL       (ivb-t430s)
                pass       -> FAIL       (bdw-ultra)
                pass       -> FAIL       (byt-nuc)
                pass       -> FAIL       (snb-x220t)
                pass       -> FAIL       (snb-dellxps)
                pass       -> FAIL       (hsw-brixbox)
                pass       -> FAIL       (ilk-hp8440p)
        Subgroup hang-read-crc-pipe-b:
                pass       -> FAIL       (hsw-gt2)
                pass       -> FAIL       (ivb-t430s)
                pass       -> FAIL       (byt-nuc)
                pass       -> FAIL       (snb-x220t)
                pass       -> FAIL       (snb-dellxps)
                pass       -> FAIL       (ilk-hp8440p)
        Subgroup hang-read-crc-pipe-c:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> FAIL       (skl-i5k-2)
                pass       -> FAIL       (hsw-gt2)
                pass       -> FAIL       (skl-i7k-2)
                pass       -> FAIL       (ivb-t430s)
                pass       -> FAIL       (hsw-brixbox)
                pass       -> FAIL       (bdw-nuci7)
        Subgroup nonblocking-crc-pipe-a:
                pass       -> FAIL       (skl-i5k-2)
                pass       -> FAIL       (hsw-gt2)
                pass       -> FAIL       (bdw-ultra)
                pass       -> FAIL       (skl-i7k-2)
                pass       -> FAIL       (byt-nuc)
                pass       -> FAIL       (snb-x220t)
                pass       -> FAIL       (snb-dellxps)
                pass       -> FAIL       (hsw-brixbox)
                pass       -> FAIL       (bdw-nuci7)
                pass       -> FAIL       (ilk-hp8440p)
        Subgroup nonblocking-crc-pipe-a-frame-sequence:
                pass       -> FAIL       (hsw-gt2)
                pass       -> FAIL       (bdw-ultra)
                pass       -> FAIL       (byt-nuc)
                pass       -> FAIL       (snb-x220t)
                pass       -> FAIL       (snb-dellxps)
                pass       -> FAIL       (hsw-brixbox)
                pass       -> FAIL       (bdw-nuci7)
                pass       -> FAIL       (ilk-hp8440p)
        Subgroup nonblocking-crc-pipe-b:
                dmesg-warn -> DMESG-FAIL (snb-x220t)
                dmesg-warn -> DMESG-FAIL (snb-dellxps)
                pass       -> FAIL       (hsw-gt2)
                pass       -> FAIL       (ilk-hp8440p)
        Subgroup nonblocking-crc-pipe-b-frame-sequence:
                pass       -> FAIL       (snb-x220t)
                pass       -> FAIL       (snb-dellxps)
                pass       -> FAIL       (hsw-gt2)
                pass       -> FAIL       (ilk-hp8440p)
        Subgroup nonblocking-crc-pipe-c:
                pass       -> FAIL       (hsw-gt2)
        Subgroup nonblocking-crc-pipe-c-frame-sequence:
                pass       -> FAIL       (bsw-nuc-2)
                pass       -> FAIL       (skl-i5k-2)
                pass       -> FAIL       (hsw-gt2)
                pass       -> FAIL       (skl-i7k-2)
                pass       -> FAIL       (hsw-brixbox)
                pass       -> FAIL       (bdw-nuci7)
        Subgroup read-crc-pipe-a:
                pass       -> FAIL       (hsw-gt2)
                pass       -> FAIL       (ivb-t430s)
                pass       -> FAIL       (bdw-ultra)
                pass       -> FAIL       (skl-i7k-2)
                pass       -> FAIL       (byt-nuc)
                pass       -> FAIL       (snb-x220t)
                pass       -> FAIL       (snb-dellxps)
                pass       -> FAIL       (hsw-brixbox)
                pass       -> FAIL       (bdw-nuci7)
                pass       -> FAIL       (ilk-hp8440p)
        Subgroup read-crc-pipe-a-frame-sequence:
                pass       -> FAIL       (hsw-gt2)
                pass       -> FAIL       (ivb-t430s)
                pass       -> FAIL       (bdw-ultra)
                pass       -> FAIL       (byt-nuc)
                pass       -> FAIL       (snb-x220t)
                pass       -> FAIL       (snb-dellxps)
                pass       -> FAIL       (hsw-brixbox)
                pass       -> FAIL       (bdw-nuci7)
                pass       -> FAIL       (ilk-hp8440p)
        Subgroup read-crc-pipe-b:
                dmesg-warn -> DMESG-FAIL (snb-x220t)
                dmesg-warn -> DMESG-FAIL (snb-dellxps)
                pass       -> FAIL       (hsw-gt2)
                pass       -> FAIL       (ilk-hp8440p)
        Subgroup read-crc-pipe-b-frame-sequence:
                pass       -> FAIL       (snb-x220t)
                pass       -> FAIL       (snb-dellxps)
                pass       -> FAIL       (hsw-gt2)
                pass       -> FAIL       (ilk-hp8440p)
                pass       -> FAIL       (ivb-t430s)
        Subgroup read-crc-pipe-c:
                pass       -> FAIL       (hsw-gt2)
        Subgroup read-crc-pipe-c-frame-sequence:
                dmesg-warn -> FAIL       (bsw-nuc-2)
                pass       -> FAIL       (skl-i5k-2)
                pass       -> FAIL       (hsw-gt2)
                pass       -> FAIL       (skl-i7k-2)
                pass       -> FAIL       (ivb-t430s)
                pass       -> FAIL       (hsw-brixbox)
                pass       -> FAIL       (bdw-nuci7)
        Subgroup suspend-read-crc-pipe-a:
                pass       -> FAIL       (skl-i5k-2)
                pass       -> FAIL       (hsw-gt2)
                pass       -> FAIL       (snb-x220t)
                pass       -> FAIL       (snb-dellxps)
                pass       -> FAIL       (hsw-brixbox)
                pass       -> FAIL       (ilk-hp8440p)
        Subgroup suspend-read-crc-pipe-b:
                dmesg-warn -> DMESG-FAIL (snb-x220t)
                dmesg-warn -> DMESG-FAIL (snb-dellxps)
                dmesg-warn -> DMESG-FAIL (ilk-hp8440p)

bdw-nuci7        total:138  pass:122  dwarn:0   dfail:0   fail:7   skip:9  
bdw-ultra        total:138  pass:126  dwarn:0   dfail:0   fail:6   skip:6  
bsw-nuc-2        total:141  pass:113  dwarn:2   dfail:0   fail:2   skip:24 
byt-nuc          total:141  pass:117  dwarn:3   dfail:0   fail:6   skip:15 
hsw-brixbox      total:141  pass:125  dwarn:0   dfail:0   fail:9   skip:7  
hsw-gt2          total:141  pass:121  dwarn:0   dfail:0   fail:16  skip:4  
ilk-hp8440p      total:141  pass:90   dwarn:2   dfail:1   fail:11  skip:37 
ivb-t430s        total:135  pass:115  dwarn:3   dfail:4   fail:7   skip:6  
skl-i5k-2        total:141  pass:126  dwarn:2   dfail:0   fail:5   skip:8  
skl-i7k-2        total:141  pass:127  dwarn:1   dfail:0   fail:5   skip:8  
snb-dellxps      total:141  pass:113  dwarn:2   dfail:3   fail:9   skip:14 
snb-x220t        total:141  pass:113  dwarn:2   dfail:3   fail:10  skip:13 

Results at /archive/results/CI_IGT_test/Patchwork_1137/

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

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

* ✗ failure: Fi.CI.BAT
  2016-01-11 12:27 [PATCH v2 0/9] Kill off intel_crtc->atomic! Maarten Lankhorst
  2016-01-11 12:49 ` ✗ failure: Fi.CI.BAT Patchwork
@ 2016-01-11 14:30 ` Patchwork
  1 sibling, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-11 14:30 UTC (permalink / raw)
  To: Maarten Lankhorst; +Cc: intel-gfx

== Summary ==

HEAD is now at ff88655 drm-intel-nightly: 2016y-01m-11d-07h-30m-16s UTC integration manifest
Applying: drm/i915: Kill off intel_crtc->atomic.wait_vblank, v3.
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 drm/i915: Kill off intel_crtc->atomic.wait_vblank, v3.

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

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

* ✗ failure: Fi.CI.BAT
  2015-12-21 13:10 [PATCH 00/15] drm/i915/bios: mipi sequence block v3, etc Jani Nikula
  2016-01-05 16:01 ` ✗ failure: Fi.CI.BAT Patchwork
  2016-01-11 13:30 ` Patchwork
@ 2016-01-11 14:01 ` Patchwork
  2 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-11 14:01 UTC (permalink / raw)
  To: Jani Nikula; +Cc: intel-gfx

== Summary ==

HEAD is now at ff88655 drm-intel-nightly: 2016y-01m-11d-07h-30m-16s UTC integration manifest
Applying: drm/i915/bios: add proper documentation for the Video BIOS Table (VBT)
Using index info to reconstruct a base tree...
M	Documentation/DocBook/gpu.tmpl
M	drivers/gpu/drm/i915/intel_bios.c
M	drivers/gpu/drm/i915/intel_bios.h
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_bios.h
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_bios.h
Auto-merging drivers/gpu/drm/i915/intel_bios.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_bios.c
Patch failed at 0001 drm/i915/bios: add proper documentation for the Video BIOS Table (VBT)

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

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

* ✗ failure: Fi.CI.BAT
  2015-12-21 13:10 [PATCH 00/15] drm/i915/bios: mipi sequence block v3, etc Jani Nikula
  2016-01-05 16:01 ` ✗ failure: Fi.CI.BAT Patchwork
@ 2016-01-11 13:30 ` Patchwork
  2016-01-11 14:01 ` Patchwork
  2 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-11 13:30 UTC (permalink / raw)
  To: Jani Nikula; +Cc: intel-gfx

== Summary ==

HEAD is now at ff88655 drm-intel-nightly: 2016y-01m-11d-07h-30m-16s UTC integration manifest
Applying: drm/i915/bios: add proper documentation for the Video BIOS Table (VBT)
Using index info to reconstruct a base tree...
M	Documentation/DocBook/gpu.tmpl
M	drivers/gpu/drm/i915/intel_bios.c
M	drivers/gpu/drm/i915/intel_bios.h
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_bios.h
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_bios.h
Auto-merging drivers/gpu/drm/i915/intel_bios.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_bios.c
Patch failed at 0001 drm/i915/bios: add proper documentation for the Video BIOS Table (VBT)

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

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

* Re: ✗ failure: Fi.CI.BAT
  2016-01-11  9:59 ` ✗ failure: Fi.CI.BAT Patchwork
@ 2016-01-11 12:50   ` Mika Kuoppala
  2016-01-12 16:22     ` Daniel Vetter
  0 siblings, 1 reply; 118+ messages in thread
From: Mika Kuoppala @ 2016-01-11 12:50 UTC (permalink / raw)
  To: Patchwork; +Cc: intel-gfx

Patchwork <patchwork@annarchy.freedesktop.org> writes:

> == Summary ==
>
> Built on ff88655b3a5467bbc3be8c67d3e05ebf182557d3 drm-intel-nightly: 2016y-01m-11d-07h-30m-16s UTC integration manifest
>
> Test gem_storedw_loop:
>         Subgroup basic-render:
>                 pass       -> DMESG-WARN (skl-i5k-2) UNSTABLE
>                 dmesg-warn -> PASS       (bdw-ultra)
> Test kms_flip:
>         Subgroup basic-flip-vs-dpms:
>                 dmesg-warn -> PASS       (ilk-hp8440p)
>         Subgroup basic-flip-vs-modeset:
>                 pass       -> DMESG-WARN (skl-i5k-2)
>                 dmesg-warn -> PASS       (bsw-nuc-2)
>                 pass       -> DMESG-WARN (ilk-hp8440p)
>                 dmesg-warn -> PASS       (byt-nuc)
>         Subgroup basic-flip-vs-wf_vblank:
>                 pass       -> DMESG-WARN (byt-nuc)
>         Subgroup basic-plain-flip:
>                 dmesg-warn -> PASS       (bsw-nuc-2)
>                 dmesg-warn -> PASS       (byt-nuc)
> Test kms_pipe_crc_basic:
>         Subgroup nonblocking-crc-pipe-b:
>                 pass       -> DMESG-WARN (byt-nuc)
>         Subgroup nonblocking-crc-pipe-c:
>                 pass       -> DMESG-WARN (bsw-nuc-2)
>         Subgroup read-crc-pipe-a:
>                 dmesg-warn -> PASS       (byt-nuc)
>         Subgroup read-crc-pipe-b:
>                 dmesg-warn -> PASS       (byt-nuc)
>         Subgroup read-crc-pipe-b-frame-sequence:
>                 pass       -> DMESG-WARN (bdw-ultra)
>                 dmesg-warn -> PASS       (byt-nuc)
>         Subgroup read-crc-pipe-c:
>                 dmesg-warn -> PASS       (bsw-nuc-2)
>         Subgroup read-crc-pipe-c-frame-sequence:
>                 pass       -> DMESG-WARN (bsw-nuc-2)
> Test pm_rpm:
>         Subgroup basic-pci-d3-state:
>                 dmesg-warn -> PASS       (byt-nuc)
>
> bdw-ultra        total:138  pass:130  dwarn:1   dfail:0   fail:1
> skip:6

Tomi suspected this as a fluke fail. There was no igt stdout nor stderr
for this case. We did a rerun and bdw-ultra passed.

-Mika

> bsw-nuc-2        total:141  pass:115  dwarn:2   dfail:0   fail:0   skip:24 
> byt-nuc          total:141  pass:122  dwarn:4   dfail:0   fail:0   skip:15 
> hsw-brixbox      total:141  pass:134  dwarn:0   dfail:0   fail:0   skip:7  
> hsw-gt2          total:141  pass:137  dwarn:0   dfail:0   fail:0   skip:4  
> ilk-hp8440p      total:141  pass:100  dwarn:4   dfail:0   fail:0   skip:37 
> skl-i5k-2        total:141  pass:130  dwarn:3   dfail:0   fail:0   skip:8  
> skl-i7k-2        total:141  pass:131  dwarn:2   dfail:0   fail:0   skip:8  
> snb-dellxps      total:141  pass:122  dwarn:5   dfail:0   fail:0   skip:14 
> snb-x220t        total:141  pass:122  dwarn:5   dfail:0   fail:1   skip:13 
>
> HANGED ivb-t430s in igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b
>
> Results at /archive/results/CI_IGT_test/Patchwork_1116/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* ✗ failure: Fi.CI.BAT
  2016-01-11 12:27 [PATCH v2 0/9] Kill off intel_crtc->atomic! Maarten Lankhorst
@ 2016-01-11 12:49 ` Patchwork
  2016-01-11 14:30 ` Patchwork
  1 sibling, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-11 12:49 UTC (permalink / raw)
  To: Maarten Lankhorst; +Cc: intel-gfx

== Summary ==

Built on ff88655b3a5467bbc3be8c67d3e05ebf182557d3 drm-intel-nightly: 2016y-01m-11d-07h-30m-16s UTC integration manifest

Test core_auth:
        Subgroup basic-auth:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
Test core_prop_blob:
        Subgroup basic:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
Test drv_getparams_basic:
        Subgroup basic-eu-total:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup basic-subslice-total:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
Test gem_basic:
        Subgroup bad-close:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup create-close:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
Test gem_cpu_reloc:
        Subgroup basic:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
Test gem_ctx_create:
        Subgroup basic:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
Test gem_ctx_param_basic:
        Subgroup basic:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup basic-default:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup invalid-ctx-get:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup invalid-ctx-set:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup invalid-param-set:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup non-root-set:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup non-root-set-no-zeromap:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup root-set-no-zeromap-disabled:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup root-set-no-zeromap-enabled:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
Test gem_flink_basic:
        Subgroup bad-open:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup basic:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
Test gem_linear_blits:
        Subgroup basic:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
Test gem_mmap:
        Subgroup basic:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
Test gem_mmap_gtt:
        Subgroup basic-copy:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup basic-read:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup basic-read-write-distinct:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup basic-small-bo:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup basic-small-bo-tiledx:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup basic-small-bo-tiledy:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup basic-small-copy:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup basic-small-copy-xy:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup basic-write:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup basic-write-gtt:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup basic-write-no-prefault:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup basic-write-read-distinct:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
Test gem_pwrite:
        Subgroup basic:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
Test gem_render_linear_blits:
        Subgroup basic:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
Test gem_render_tiled_blits:
        Subgroup basic:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
Test gem_storedw_loop:
        Subgroup basic-blt:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup basic-bsd:
                pass       -> SKIP       (bdw-ultra)
        Subgroup basic-render:
                dmesg-warn -> PASS       (bdw-ultra)
        Subgroup basic-vebox:
                pass       -> SKIP       (bdw-ultra)
Test kms_addfb_basic:
        Subgroup addfb25-modifier-no-flag:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup addfb25-x-tiled:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup addfb25-x-tiled-mismatch:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup addfb25-y-tiled:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup addfb25-yf-tiled:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup bad-pitch-0:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup bad-pitch-1024:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup bad-pitch-128:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup bad-pitch-256:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup bad-pitch-32:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup bad-pitch-63:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup bad-pitch-65536:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup bad-pitch-999:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup basic:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup basic-y-tiled:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup bo-too-small-due-to-tiling:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup clobberred-modifier:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup framebuffer-vs-set-tiling:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup no-handle:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup size-max:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup small-bo:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup tile-pitch-mismatch:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup too-high:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup too-wide:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup unused-handle:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup unused-modifier:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup unused-offsets:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup unused-pitches:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
Test kms_flip:
        Subgroup basic-flip-vs-dpms:
                pass       -> DMESG-FAIL (bsw-nuc-2)
                pass       -> FAIL       (snb-dellxps)
                pass       -> FAIL       (bdw-ultra)
                dmesg-warn -> PASS       (ilk-hp8440p)
                pass       -> DMESG-FAIL (byt-nuc)
        Subgroup basic-flip-vs-modeset:
                dmesg-warn -> DMESG-FAIL (bsw-nuc-2)
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
                pass       -> DMESG-WARN (ilk-hp8440p)
                dmesg-warn -> DMESG-FAIL (byt-nuc)
        Subgroup basic-flip-vs-wf_vblank:
                pass       -> DMESG-FAIL (bsw-nuc-2)
                dmesg-warn -> PASS       (ivb-t430s)
                pass       -> FAIL       (bdw-ultra)
                pass       -> DMESG-FAIL (byt-nuc)
                dmesg-warn -> PASS       (snb-x220t)
                dmesg-warn -> FAIL       (snb-dellxps)
                dmesg-warn -> PASS       (ilk-hp8440p)
        Subgroup basic-plain-flip:
                dmesg-warn -> DMESG-FAIL (byt-nuc)
                dmesg-warn -> DMESG-FAIL (bsw-nuc-2)
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
                dmesg-warn -> PASS       (ivb-t430s)
Test kms_force_connector_basic:
        Subgroup force-edid:
                pass       -> SKIP       (snb-dellxps)
        Subgroup prune-stale-modes:
                pass       -> SKIP       (snb-dellxps)
Test kms_pipe_crc_basic:
        Subgroup bad-nb-words-1:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup bad-nb-words-3:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup bad-pipe:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup hang-read-crc-pipe-a:
                pass       -> FAIL       (snb-dellxps)
                pass       -> FAIL       (bdw-ultra)
                pass       -> DMESG-FAIL (byt-nuc)
        Subgroup hang-read-crc-pipe-b:
                pass       -> FAIL       (snb-dellxps)
                pass       -> FAIL       (bdw-ultra)
                pass       -> DMESG-FAIL (byt-nuc)
        Subgroup hang-read-crc-pipe-c:
                pass       -> FAIL       (bsw-nuc-2)
                pass       -> FAIL       (bdw-ultra)
        Subgroup nonblocking-crc-pipe-a:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
                pass       -> FAIL       (byt-nuc)
        Subgroup nonblocking-crc-pipe-a-frame-sequence:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
                pass       -> FAIL       (byt-nuc)
        Subgroup nonblocking-crc-pipe-b:
                dmesg-warn -> PASS       (snb-x220t)
                dmesg-warn -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
                pass       -> DMESG-FAIL (byt-nuc)
        Subgroup nonblocking-crc-pipe-b-frame-sequence:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
                pass       -> DMESG-FAIL (byt-nuc)
        Subgroup nonblocking-crc-pipe-c:
                pass       -> FAIL       (bsw-nuc-2)
                pass       -> SKIP       (bdw-ultra)
        Subgroup nonblocking-crc-pipe-c-frame-sequence:
                pass       -> FAIL       (bsw-nuc-2)
                pass       -> FAIL       (bdw-ultra)
        Subgroup read-crc-pipe-a:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
                dmesg-warn -> FAIL       (byt-nuc)
        Subgroup read-crc-pipe-a-frame-sequence:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
                dmesg-warn -> FAIL       (byt-nuc)
        Subgroup read-crc-pipe-b:
                dmesg-warn -> DMESG-FAIL (byt-nuc)
                dmesg-warn -> PASS       (snb-x220t)
                dmesg-warn -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
                dmesg-fail -> PASS       (ivb-t430s)
        Subgroup read-crc-pipe-b-frame-sequence:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
                dmesg-warn -> DMESG-FAIL (byt-nuc)
        Subgroup read-crc-pipe-c:
                dmesg-warn -> FAIL       (bsw-nuc-2)
                pass       -> SKIP       (bdw-ultra)
                dmesg-fail -> PASS       (ivb-t430s)
        Subgroup read-crc-pipe-c-frame-sequence:
                pass       -> FAIL       (bsw-nuc-2)
                pass       -> FAIL       (bdw-ultra)
        Subgroup suspend-read-crc-pipe-a:
                pass       -> SKIP       (snb-dellxps)
                pass       -> DMESG-FAIL (byt-nuc)
        Subgroup suspend-read-crc-pipe-b:
                pass       -> DMESG-FAIL (byt-nuc)
                dmesg-warn -> PASS       (snb-x220t)
                dmesg-warn -> SKIP       (snb-dellxps)
                dmesg-warn -> PASS       (ilk-hp8440p)
                dmesg-fail -> PASS       (ivb-t430s)
        Subgroup suspend-read-crc-pipe-c:
                pass       -> DMESG-FAIL (bsw-nuc-2)
                dmesg-fail -> PASS       (ivb-t430s)
Test kms_psr_sink_crc:
        Subgroup psr_basic:
                pass       -> SKIP       (bdw-ultra)
Test kms_setmode:
        Subgroup basic-clone-single-crtc:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
Test pm_rpm:
        Subgroup basic-pci-d3-state:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup basic-rte:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
Test pm_rps:
        Subgroup basic-api:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
Test prime_self_import:
        Subgroup basic-llseek-bad:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup basic-with_fd_dup:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup basic-with_one_bo_two_files:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)
        Subgroup basic-with_two_bos:
                pass       -> SKIP       (snb-dellxps)
                pass       -> SKIP       (bdw-ultra)

bdw-nuci7        total:138  pass:129  dwarn:0   dfail:0   fail:0   skip:9  
bdw-ultra        total:138  pass:31   dwarn:0   dfail:1   fail:7   skip:99 
bsw-nuc-2        total:141  pass:106  dwarn:1   dfail:5   fail:5   skip:24 
byt-nuc          total:141  pass:107  dwarn:3   dfail:12  fail:4   skip:15 
hsw-brixbox      total:141  pass:134  dwarn:0   dfail:0   fail:0   skip:7  
hsw-gt2          total:141  pass:137  dwarn:0   dfail:0   fail:0   skip:4  
ilk-hp8440p      total:141  pass:103  dwarn:1   dfail:0   fail:0   skip:37 
ivb-t430s        total:135  pass:129  dwarn:0   dfail:0   fail:0   skip:6  
snb-dellxps      total:141  pass:31   dwarn:0   dfail:1   fail:4   skip:105
snb-x220t        total:141  pass:127  dwarn:0   dfail:0   fail:1   skip:13 

HANGED hsw-xps12 in igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a
HANGED skl-i5k-2 in igt@kms_pipe_crc_basic@hang-read-crc-pipe-a
HANGED skl-i7k-2 in igt@kms_pipe_crc_basic@hang-read-crc-pipe-a

Results at /archive/results/CI_IGT_test/Patchwork_1127/

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

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

* ✗ failure: Fi.CI.BAT
  2016-01-08 20:36 [PATCH 00/21] drm_event cleanup Daniel Vetter
@ 2016-01-11 11:20 ` Patchwork
  2016-01-12 16:24   ` Daniel Vetter
  0 siblings, 1 reply; 118+ messages in thread
From: Patchwork @ 2016-01-11 11:20 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

== Summary ==

HEAD is now at ff88655 drm-intel-nightly: 2016y-01m-11d-07h-30m-16s UTC integration manifest
Applying: drm: kerneldoc for drm_fops.c
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 drm: kerneldoc for drm_fops.c

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

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

* ✗ failure: Fi.CI.BAT
  2016-01-08 21:40 [PATCH] drm/i915: Reject invalid-pad for context-destroy ioctl Chris Wilson
@ 2016-01-11 11:07 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-11 11:07 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Summary ==

Built on ff88655b3a5467bbc3be8c67d3e05ebf182557d3 drm-intel-nightly: 2016y-01m-11d-07h-30m-16s UTC integration manifest

Test gem_storedw_loop:
        Subgroup basic-render:
                pass       -> DMESG-WARN (bdw-nuci7)
                dmesg-warn -> PASS       (bdw-ultra)
Test kms_flip:
        Subgroup basic-flip-vs-dpms:
                dmesg-warn -> PASS       (ilk-hp8440p)
Test kms_pipe_crc_basic:
        Subgroup nonblocking-crc-pipe-b-frame-sequence:
                pass       -> DMESG-WARN (bdw-ultra)
        Subgroup read-crc-pipe-a-frame-sequence:
                pass       -> FAIL       (snb-x220t)
        Subgroup read-crc-pipe-b:
                dmesg-warn -> PASS       (byt-nuc)
        Subgroup read-crc-pipe-c:
                dmesg-warn -> PASS       (bsw-nuc-2)

bdw-nuci7        total:138  pass:128  dwarn:1   dfail:0   fail:0   skip:9  
bdw-ultra        total:138  pass:131  dwarn:1   dfail:0   fail:0   skip:6  
bsw-nuc-2        total:141  pass:115  dwarn:2   dfail:0   fail:0   skip:24 
byt-nuc          total:141  pass:119  dwarn:7   dfail:0   fail:0   skip:15 
hsw-brixbox      total:141  pass:134  dwarn:0   dfail:0   fail:0   skip:7  
hsw-gt2          total:141  pass:137  dwarn:0   dfail:0   fail:0   skip:4  
ilk-hp8440p      total:141  pass:101  dwarn:3   dfail:0   fail:0   skip:37 
ivb-t430s        total:135  pass:122  dwarn:3   dfail:4   fail:0   skip:6  
skl-i5k-2        total:141  pass:132  dwarn:1   dfail:0   fail:0   skip:8  
skl-i7k-2        total:141  pass:131  dwarn:2   dfail:0   fail:0   skip:8  
snb-dellxps      total:141  pass:122  dwarn:5   dfail:0   fail:0   skip:14 
snb-x220t        total:141  pass:121  dwarn:5   dfail:0   fail:2   skip:13 

Results at /archive/results/CI_IGT_test/Patchwork_1120/

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

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

* ✗ failure: Fi.CI.BAT
  2016-01-08 16:58 [PATCH 1/2] drm/i915: Store edram capabilities instead of fixed size Mika Kuoppala
@ 2016-01-11 10:27 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-11 10:27 UTC (permalink / raw)
  To: Mika Kuoppala; +Cc: intel-gfx

== Summary ==

Built on ff88655b3a5467bbc3be8c67d3e05ebf182557d3 drm-intel-nightly: 2016y-01m-11d-07h-30m-16s UTC integration manifest

Test gem_storedw_loop:
        Subgroup basic-render:
                dmesg-warn -> PASS       (bdw-ultra)
Test kms_flip:
        Subgroup basic-flip-vs-dpms:
                dmesg-warn -> PASS       (ilk-hp8440p)
Test kms_pipe_crc_basic:
        Subgroup read-crc-pipe-b:
                pass       -> DMESG-WARN (bdw-ultra)
                dmesg-warn -> PASS       (byt-nuc)

bdw-nuci7        total:138  pass:129  dwarn:0   dfail:0   fail:0   skip:9  
bdw-ultra        total:138  pass:131  dwarn:1   dfail:0   fail:0   skip:6  
bsw-nuc-2        total:141  pass:114  dwarn:3   dfail:0   fail:0   skip:24 
byt-nuc          total:141  pass:119  dwarn:7   dfail:0   fail:0   skip:15 
hsw-brixbox      total:141  pass:134  dwarn:0   dfail:0   fail:0   skip:7  
hsw-gt2          total:141  pass:137  dwarn:0   dfail:0   fail:0   skip:4  
ilk-hp8440p      total:141  pass:101  dwarn:3   dfail:0   fail:0   skip:37 
skl-i5k-2        total:141  pass:132  dwarn:1   dfail:0   fail:0   skip:8  
skl-i7k-2        total:141  pass:131  dwarn:2   dfail:0   fail:0   skip:8  
snb-dellxps      total:141  pass:122  dwarn:5   dfail:0   fail:0   skip:14 
snb-x220t        total:141  pass:122  dwarn:5   dfail:0   fail:1   skip:13 

HANGED ivb-t430s in igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b

Results at /archive/results/CI_IGT_test/Patchwork_1118/

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

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

* ✗ failure: Fi.CI.BAT
  2016-01-08 13:51 [PATCH 1/2] drm/i915: Enable mmio_debug for vlv/chv Mika Kuoppala
@ 2016-01-11  9:59 ` Patchwork
  2016-01-11 12:50   ` Mika Kuoppala
  0 siblings, 1 reply; 118+ messages in thread
From: Patchwork @ 2016-01-11  9:59 UTC (permalink / raw)
  To: Mika Kuoppala; +Cc: intel-gfx

== Summary ==

Built on ff88655b3a5467bbc3be8c67d3e05ebf182557d3 drm-intel-nightly: 2016y-01m-11d-07h-30m-16s UTC integration manifest

Test gem_storedw_loop:
        Subgroup basic-render:
                pass       -> DMESG-WARN (skl-i5k-2) UNSTABLE
                dmesg-warn -> PASS       (bdw-ultra)
Test kms_flip:
        Subgroup basic-flip-vs-dpms:
                dmesg-warn -> PASS       (ilk-hp8440p)
        Subgroup basic-flip-vs-modeset:
                pass       -> DMESG-WARN (skl-i5k-2)
                dmesg-warn -> PASS       (bsw-nuc-2)
                pass       -> DMESG-WARN (ilk-hp8440p)
                dmesg-warn -> PASS       (byt-nuc)
        Subgroup basic-flip-vs-wf_vblank:
                pass       -> DMESG-WARN (byt-nuc)
        Subgroup basic-plain-flip:
                dmesg-warn -> PASS       (bsw-nuc-2)
                dmesg-warn -> PASS       (byt-nuc)
Test kms_pipe_crc_basic:
        Subgroup nonblocking-crc-pipe-b:
                pass       -> DMESG-WARN (byt-nuc)
        Subgroup nonblocking-crc-pipe-c:
                pass       -> DMESG-WARN (bsw-nuc-2)
        Subgroup read-crc-pipe-a:
                dmesg-warn -> PASS       (byt-nuc)
        Subgroup read-crc-pipe-b:
                dmesg-warn -> PASS       (byt-nuc)
        Subgroup read-crc-pipe-b-frame-sequence:
                pass       -> DMESG-WARN (bdw-ultra)
                dmesg-warn -> PASS       (byt-nuc)
        Subgroup read-crc-pipe-c:
                dmesg-warn -> PASS       (bsw-nuc-2)
        Subgroup read-crc-pipe-c-frame-sequence:
                pass       -> DMESG-WARN (bsw-nuc-2)
Test pm_rpm:
        Subgroup basic-pci-d3-state:
                dmesg-warn -> PASS       (byt-nuc)

bdw-ultra        total:138  pass:130  dwarn:1   dfail:0   fail:1   skip:6  
bsw-nuc-2        total:141  pass:115  dwarn:2   dfail:0   fail:0   skip:24 
byt-nuc          total:141  pass:122  dwarn:4   dfail:0   fail:0   skip:15 
hsw-brixbox      total:141  pass:134  dwarn:0   dfail:0   fail:0   skip:7  
hsw-gt2          total:141  pass:137  dwarn:0   dfail:0   fail:0   skip:4  
ilk-hp8440p      total:141  pass:100  dwarn:4   dfail:0   fail:0   skip:37 
skl-i5k-2        total:141  pass:130  dwarn:3   dfail:0   fail:0   skip:8  
skl-i7k-2        total:141  pass:131  dwarn:2   dfail:0   fail:0   skip:8  
snb-dellxps      total:141  pass:122  dwarn:5   dfail:0   fail:0   skip:14 
snb-x220t        total:141  pass:122  dwarn:5   dfail:0   fail:1   skip:13 

HANGED ivb-t430s in igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b

Results at /archive/results/CI_IGT_test/Patchwork_1116/

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

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

* ✗ failure: Fi.CI.BAT
  2016-01-08 11:29 [PATCH v2 00/13] Misc cleanups and locking fixes Tvrtko Ursulin
@ 2016-01-11  9:44 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-11  9:44 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: intel-gfx

== Summary ==

Built on ff88655b3a5467bbc3be8c67d3e05ebf182557d3 drm-intel-nightly: 2016y-01m-11d-07h-30m-16s UTC integration manifest

Test gem_basic:
        Subgroup create-close:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_cpu_reloc:
        Subgroup basic:
                pass       -> DMESG-FAIL (skl-i7k-2)
Test gem_ctx_param_basic:
        Subgroup basic:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup invalid-param-set:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup non-root-set-no-zeromap:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup root-set-no-zeromap-disabled:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_mmap:
        Subgroup basic:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_mmap_gtt:
        Subgroup basic-read:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup basic-write:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_storedw_loop:
        Subgroup basic-render:
                dmesg-warn -> PASS       (skl-i7k-2) UNSTABLE
Test kms_addfb_basic:
        Subgroup addfb25-modifier-no-flag:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup addfb25-x-tiled-mismatch:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup addfb25-yf-tiled:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup bad-pitch-1024:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup bad-pitch-63:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup bad-pitch-999:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup clobberred-modifier:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup too-high:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup too-wide:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup unused-offsets:
                pass       -> DMESG-WARN (skl-i7k-2)
Test kms_flip:
        Subgroup basic-flip-vs-dpms:
                dmesg-warn -> PASS       (ilk-hp8440p)
        Subgroup basic-plain-flip:
                pass       -> DMESG-FAIL (skl-i7k-2)
Test kms_pipe_crc_basic:
        Subgroup hang-read-crc-pipe-a:
                pass       -> DMESG-WARN (skl-i5k-2)
                pass       -> DMESG-WARN (bdw-ultra)
                pass       -> DMESG-WARN (skl-i7k-2)
                pass       -> DMESG-WARN (byt-nuc)
                pass       -> DMESG-WARN (snb-x220t)
                pass       -> DMESG-WARN (snb-dellxps)
                pass       -> DMESG-WARN (hsw-brixbox)
                pass       -> DMESG-WARN (ilk-hp8440p)
        Subgroup nonblocking-crc-pipe-a-frame-sequence:
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup read-crc-pipe-b:
                dmesg-warn -> PASS       (byt-nuc)
        Subgroup read-crc-pipe-b-frame-sequence:
                pass       -> DMESG-FAIL (skl-i7k-2)
Test prime_self_import:
        Subgroup basic-with_two_bos:
                pass       -> DMESG-WARN (skl-i7k-2)

bdw-ultra        total:138  pass:129  dwarn:3   dfail:0   fail:0   skip:6  
bsw-nuc-2        total:141  pass:113  dwarn:4   dfail:0   fail:0   skip:24 
byt-nuc          total:141  pass:117  dwarn:9   dfail:0   fail:0   skip:15 
hsw-brixbox      total:141  pass:132  dwarn:2   dfail:0   fail:0   skip:7  
ilk-hp8440p      total:141  pass:100  dwarn:4   dfail:0   fail:0   skip:37 
skl-i5k-2        total:141  pass:130  dwarn:3   dfail:0   fail:0   skip:8  
skl-i7k-2        total:141  pass:106  dwarn:22  dfail:4   fail:0   skip:8  
snb-dellxps      total:141  pass:121  dwarn:6   dfail:0   fail:0   skip:14 
snb-x220t        total:141  pass:121  dwarn:6   dfail:0   fail:1   skip:13 

HANGED hsw-gt2 in igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c

Results at /archive/results/CI_IGT_test/Patchwork_1115/

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

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

* ✗ failure: Fi.CI.BAT
  2016-01-07  9:10 [PATCH] drm/i915: Init power domains early in driver load Daniel Vetter
@ 2016-01-11  9:12 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-11  9:12 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

== Summary ==

Built on ff88655b3a5467bbc3be8c67d3e05ebf182557d3 drm-intel-nightly: 2016y-01m-11d-07h-30m-16s UTC integration manifest

Test gem_storedw_loop:
        Subgroup basic-render:
                pass       -> DMESG-WARN (skl-i5k-2) UNSTABLE
                dmesg-warn -> PASS       (bdw-ultra)
Test kms_flip:
        Subgroup basic-flip-vs-dpms:
                dmesg-warn -> PASS       (ilk-hp8440p)
Test kms_pipe_crc_basic:
        Subgroup read-crc-pipe-b:
                pass       -> DMESG-WARN (ilk-hp8440p)
                dmesg-warn -> PASS       (byt-nuc)

bdw-ultra        total:138  pass:132  dwarn:0   dfail:0   fail:0   skip:6  
bsw-nuc-2        total:141  pass:114  dwarn:3   dfail:0   fail:0   skip:24 
byt-nuc          total:141  pass:119  dwarn:7   dfail:0   fail:0   skip:15 
hsw-brixbox      total:141  pass:134  dwarn:0   dfail:0   fail:0   skip:7  
hsw-gt2          total:141  pass:137  dwarn:0   dfail:0   fail:0   skip:4  
hsw-xps12        total:138  pass:133  dwarn:1   dfail:0   fail:0   skip:4  
ilk-hp8440p      total:141  pass:100  dwarn:4   dfail:0   fail:0   skip:37 
skl-i5k-2        total:141  pass:131  dwarn:2   dfail:0   fail:0   skip:8  
skl-i7k-2        total:141  pass:131  dwarn:2   dfail:0   fail:0   skip:8  
snb-dellxps      total:141  pass:122  dwarn:5   dfail:0   fail:0   skip:14 
snb-x220t        total:141  pass:122  dwarn:5   dfail:0   fail:1   skip:13 

HANGED ivb-t430s in igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b

Results at /archive/results/CI_IGT_test/Patchwork_1112/

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

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

* ✗ failure: Fi.CI.BAT
  2016-01-07 10:54 [PATCH 0/7] Explicitly pass crtc_state and plane_state to plane update functions Maarten Lankhorst
@ 2016-01-11  8:53 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-11  8:53 UTC (permalink / raw)
  To: Maarten Lankhorst; +Cc: intel-gfx

== Summary ==

HEAD is now at ff88655 drm-intel-nightly: 2016y-01m-11d-07h-30m-16s UTC integration manifest
Applying: drm/i915: Use passed plane state for sprite planes, v4.
Using index info to reconstruct a base tree...
M	drivers/gpu/drm/i915/intel_drv.h
M	drivers/gpu/drm/i915/intel_sprite.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_sprite.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_sprite.c
Patch failed at 0001 drm/i915: Use passed plane state for sprite planes, v4.

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

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

* Re: ✗ failure: Fi.CI.BAT
  2016-01-07 14:36       ` Daniel Vetter
  2016-01-07 14:51         ` Jani Nikula
@ 2016-01-07 15:37         ` Dave Gordon
  1 sibling, 0 replies; 118+ messages in thread
From: Dave Gordon @ 2016-01-07 15:37 UTC (permalink / raw)
  To: Daniel Vetter, Jani Nikula; +Cc: intel-gfx

On 07/01/16 14:36, Daniel Vetter wrote:
> On Thu, Jan 07, 2016 at 03:06:13PM +0200, Jani Nikula wrote:
>> On Thu, 07 Jan 2016, Dave Gordon <david.s.gordon@intel.com> wrote:
>>> On 06/01/16 10:20, Patchwork wrote:
>>>> == Summary ==
>>>>
>>>> Built on 24b053acb16b4b3b021575e4ee30ffedd3ab2920 drm-intel-nightly: 2016y-01m-06d-08h-16m-11s UTC integration manifest
>>>>
>>>> Test drv_getparams_basic:
>>>>           Subgroup basic-eu-total:
>>>>                   pass       -> DMESG-FAIL (skl-i5k-2)
>>>>                   pass       -> DMESG-FAIL (skl-i7k-2)
>>
>> [snip]
>>
>>>>
>>>> bdw-nuci7        total:132  pass:122  dwarn:1   dfail:0   fail:0   skip:9
>>>> bdw-ultra        total:132  pass:126  dwarn:0   dfail:0   fail:0   skip:6
>>>> bsw-nuc-2        total:135  pass:115  dwarn:0   dfail:0   fail:0   skip:20
>>>> byt-nuc          total:135  pass:121  dwarn:1   dfail:0   fail:0   skip:13
>>>> hsw-brixbox      total:135  pass:128  dwarn:0   dfail:0   fail:0   skip:7
>>>> hsw-gt2          total:135  pass:131  dwarn:0   dfail:0   fail:0   skip:4
>>>> ilk-hp8440p      total:135  pass:100  dwarn:0   dfail:0   fail:0   skip:35
>>>> ivb-t430s        total:135  pass:129  dwarn:0   dfail:0   fail:0   skip:6
>>>> skl-i5k-2        total:135  pass:2    dwarn:0   dfail:132 fail:0   skip:1
>>>> skl-i7k-2        total:135  pass:2    dwarn:0   dfail:132 fail:0   skip:1
>>>> snb-dellxps      total:135  pass:123  dwarn:0   dfail:0   fail:0   skip:12
>>>> snb-x220t        total:135  pass:123  dwarn:0   dfail:0   fail:1   skip:11
>>>>
>>>> Results at /archive/results/CI_IGT_test/Patchwork_1094/
>>>>
>>>> _______________________________________________
>>>> Intel-gfx mailing list
>>>> Intel-gfx@lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>>
>>> Looks like the CI SKL doesn't have the GuC firmware installed?
>>
>> It's tons of:
>>
>> [   38.169461] [drm:intel_lr_context_deferred_alloc [i915]] *ERROR* ring create req: -5
>>
>> If that gets fixed by installing the GuC firmware, the answer is *not*
>> to install the GuC firmware on the CI machines. The answer is to make
>> the driver handle missing firmware gracefully.
>
> I kinda don't want to support 2 different ways to run things on any given
> platform, because we can't even support one way properly.
>
> But since it took forever to get guc enabled people will indeed scream if
> guc isn't there, so either we enable this only for bxt and later or we
> indeed need to support both cases on skl :(

Yeah, we used to have that ability, until it was vetoed :(
See <20150706142822.GJ2156@phenom.ffwll.local> or
http://www.mail-archive.com/intel-gfx%40lists.freedesktop.org/msg63553.html

> Either way we do need to install guc firmware first on CI boxes, since
> otherwise coverage isn't there.
> -Daniel


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

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

* Re: ✗ failure: Fi.CI.BAT
  2016-01-07 14:36       ` Daniel Vetter
@ 2016-01-07 14:51         ` Jani Nikula
  2016-01-07 15:37         ` Dave Gordon
  1 sibling, 0 replies; 118+ messages in thread
From: Jani Nikula @ 2016-01-07 14:51 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

On Thu, 07 Jan 2016, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Thu, Jan 07, 2016 at 03:06:13PM +0200, Jani Nikula wrote:
>> On Thu, 07 Jan 2016, Dave Gordon <david.s.gordon@intel.com> wrote:
>> > On 06/01/16 10:20, Patchwork wrote:
>> >> == Summary ==
>> >>
>> >> Built on 24b053acb16b4b3b021575e4ee30ffedd3ab2920 drm-intel-nightly: 2016y-01m-06d-08h-16m-11s UTC integration manifest
>> >>
>> >> Test drv_getparams_basic:
>> >>          Subgroup basic-eu-total:
>> >>                  pass       -> DMESG-FAIL (skl-i5k-2)
>> >>                  pass       -> DMESG-FAIL (skl-i7k-2)
>> 
>> [snip]
>> 
>> >>
>> >> bdw-nuci7        total:132  pass:122  dwarn:1   dfail:0   fail:0   skip:9
>> >> bdw-ultra        total:132  pass:126  dwarn:0   dfail:0   fail:0   skip:6
>> >> bsw-nuc-2        total:135  pass:115  dwarn:0   dfail:0   fail:0   skip:20
>> >> byt-nuc          total:135  pass:121  dwarn:1   dfail:0   fail:0   skip:13
>> >> hsw-brixbox      total:135  pass:128  dwarn:0   dfail:0   fail:0   skip:7
>> >> hsw-gt2          total:135  pass:131  dwarn:0   dfail:0   fail:0   skip:4
>> >> ilk-hp8440p      total:135  pass:100  dwarn:0   dfail:0   fail:0   skip:35
>> >> ivb-t430s        total:135  pass:129  dwarn:0   dfail:0   fail:0   skip:6
>> >> skl-i5k-2        total:135  pass:2    dwarn:0   dfail:132 fail:0   skip:1
>> >> skl-i7k-2        total:135  pass:2    dwarn:0   dfail:132 fail:0   skip:1
>> >> snb-dellxps      total:135  pass:123  dwarn:0   dfail:0   fail:0   skip:12
>> >> snb-x220t        total:135  pass:123  dwarn:0   dfail:0   fail:1   skip:11
>> >>
>> >> Results at /archive/results/CI_IGT_test/Patchwork_1094/
>> >>
>> >> _______________________________________________
>> >> Intel-gfx mailing list
>> >> Intel-gfx@lists.freedesktop.org
>> >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> >
>> > Looks like the CI SKL doesn't have the GuC firmware installed?
>> 
>> It's tons of:
>> 
>> [   38.169461] [drm:intel_lr_context_deferred_alloc [i915]] *ERROR* ring create req: -5
>> 
>> If that gets fixed by installing the GuC firmware, the answer is *not*
>> to install the GuC firmware on the CI machines. The answer is to make
>> the driver handle missing firmware gracefully.
>
> I kinda don't want to support 2 different ways to run things on any given
> platform, because we can't even support one way properly.
>
> But since it took forever to get guc enabled people will indeed scream if
> guc isn't there, so either we enable this only for bxt and later or we
> indeed need to support both cases on skl :(

It's probably considered a regression to add a hard requirement on guc
firmware now that skl has been running fine without. Yet we probably
want all the coverage we can get for the guc case, so I don't think we
should rely on bxt alone with that.

> Either way we do need to install guc firmware first on CI boxes, since
> otherwise coverage isn't there.

How about having guc firmware on half the CI boxes, at least for
starters. It's going to blow up anyway...

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: ✗ failure:  Fi.CI.BAT
  2016-01-07 13:06     ` Jani Nikula
@ 2016-01-07 14:36       ` Daniel Vetter
  2016-01-07 14:51         ` Jani Nikula
  2016-01-07 15:37         ` Dave Gordon
  0 siblings, 2 replies; 118+ messages in thread
From: Daniel Vetter @ 2016-01-07 14:36 UTC (permalink / raw)
  To: Jani Nikula; +Cc: intel-gfx

On Thu, Jan 07, 2016 at 03:06:13PM +0200, Jani Nikula wrote:
> On Thu, 07 Jan 2016, Dave Gordon <david.s.gordon@intel.com> wrote:
> > On 06/01/16 10:20, Patchwork wrote:
> >> == Summary ==
> >>
> >> Built on 24b053acb16b4b3b021575e4ee30ffedd3ab2920 drm-intel-nightly: 2016y-01m-06d-08h-16m-11s UTC integration manifest
> >>
> >> Test drv_getparams_basic:
> >>          Subgroup basic-eu-total:
> >>                  pass       -> DMESG-FAIL (skl-i5k-2)
> >>                  pass       -> DMESG-FAIL (skl-i7k-2)
> 
> [snip]
> 
> >>
> >> bdw-nuci7        total:132  pass:122  dwarn:1   dfail:0   fail:0   skip:9
> >> bdw-ultra        total:132  pass:126  dwarn:0   dfail:0   fail:0   skip:6
> >> bsw-nuc-2        total:135  pass:115  dwarn:0   dfail:0   fail:0   skip:20
> >> byt-nuc          total:135  pass:121  dwarn:1   dfail:0   fail:0   skip:13
> >> hsw-brixbox      total:135  pass:128  dwarn:0   dfail:0   fail:0   skip:7
> >> hsw-gt2          total:135  pass:131  dwarn:0   dfail:0   fail:0   skip:4
> >> ilk-hp8440p      total:135  pass:100  dwarn:0   dfail:0   fail:0   skip:35
> >> ivb-t430s        total:135  pass:129  dwarn:0   dfail:0   fail:0   skip:6
> >> skl-i5k-2        total:135  pass:2    dwarn:0   dfail:132 fail:0   skip:1
> >> skl-i7k-2        total:135  pass:2    dwarn:0   dfail:132 fail:0   skip:1
> >> snb-dellxps      total:135  pass:123  dwarn:0   dfail:0   fail:0   skip:12
> >> snb-x220t        total:135  pass:123  dwarn:0   dfail:0   fail:1   skip:11
> >>
> >> Results at /archive/results/CI_IGT_test/Patchwork_1094/
> >>
> >> _______________________________________________
> >> Intel-gfx mailing list
> >> Intel-gfx@lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> > Looks like the CI SKL doesn't have the GuC firmware installed?
> 
> It's tons of:
> 
> [   38.169461] [drm:intel_lr_context_deferred_alloc [i915]] *ERROR* ring create req: -5
> 
> If that gets fixed by installing the GuC firmware, the answer is *not*
> to install the GuC firmware on the CI machines. The answer is to make
> the driver handle missing firmware gracefully.

I kinda don't want to support 2 different ways to run things on any given
platform, because we can't even support one way properly.

But since it took forever to get guc enabled people will indeed scream if
guc isn't there, so either we enable this only for bxt and later or we
indeed need to support both cases on skl :(

Either way we do need to install guc firmware first on CI boxes, since
otherwise coverage isn't there.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: ✗ failure: Fi.CI.BAT
  2016-01-07 10:27   ` Dave Gordon
@ 2016-01-07 13:06     ` Jani Nikula
  2016-01-07 14:36       ` Daniel Vetter
  0 siblings, 1 reply; 118+ messages in thread
From: Jani Nikula @ 2016-01-07 13:06 UTC (permalink / raw)
  To: Dave Gordon, Patchwork, yu.dai; +Cc: intel-gfx

On Thu, 07 Jan 2016, Dave Gordon <david.s.gordon@intel.com> wrote:
> On 06/01/16 10:20, Patchwork wrote:
>> == Summary ==
>>
>> Built on 24b053acb16b4b3b021575e4ee30ffedd3ab2920 drm-intel-nightly: 2016y-01m-06d-08h-16m-11s UTC integration manifest
>>
>> Test drv_getparams_basic:
>>          Subgroup basic-eu-total:
>>                  pass       -> DMESG-FAIL (skl-i5k-2)
>>                  pass       -> DMESG-FAIL (skl-i7k-2)

[snip]

>>
>> bdw-nuci7        total:132  pass:122  dwarn:1   dfail:0   fail:0   skip:9
>> bdw-ultra        total:132  pass:126  dwarn:0   dfail:0   fail:0   skip:6
>> bsw-nuc-2        total:135  pass:115  dwarn:0   dfail:0   fail:0   skip:20
>> byt-nuc          total:135  pass:121  dwarn:1   dfail:0   fail:0   skip:13
>> hsw-brixbox      total:135  pass:128  dwarn:0   dfail:0   fail:0   skip:7
>> hsw-gt2          total:135  pass:131  dwarn:0   dfail:0   fail:0   skip:4
>> ilk-hp8440p      total:135  pass:100  dwarn:0   dfail:0   fail:0   skip:35
>> ivb-t430s        total:135  pass:129  dwarn:0   dfail:0   fail:0   skip:6
>> skl-i5k-2        total:135  pass:2    dwarn:0   dfail:132 fail:0   skip:1
>> skl-i7k-2        total:135  pass:2    dwarn:0   dfail:132 fail:0   skip:1
>> snb-dellxps      total:135  pass:123  dwarn:0   dfail:0   fail:0   skip:12
>> snb-x220t        total:135  pass:123  dwarn:0   dfail:0   fail:1   skip:11
>>
>> Results at /archive/results/CI_IGT_test/Patchwork_1094/
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> Looks like the CI SKL doesn't have the GuC firmware installed?

It's tons of:

[   38.169461] [drm:intel_lr_context_deferred_alloc [i915]] *ERROR* ring create req: -5

If that gets fixed by installing the GuC firmware, the answer is *not*
to install the GuC firmware on the CI machines. The answer is to make
the driver handle missing firmware gracefully.

BR,
Jani.


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

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: ✗ failure: Fi.CI.BAT
  2016-01-06 10:20 ` ✗ failure: Fi.CI.BAT Patchwork
@ 2016-01-07 10:27   ` Dave Gordon
  2016-01-07 13:06     ` Jani Nikula
  0 siblings, 1 reply; 118+ messages in thread
From: Dave Gordon @ 2016-01-07 10:27 UTC (permalink / raw)
  To: Patchwork, yu.dai; +Cc: intel-gfx

On 06/01/16 10:20, Patchwork wrote:
> == Summary ==
>
> Built on 24b053acb16b4b3b021575e4ee30ffedd3ab2920 drm-intel-nightly: 2016y-01m-06d-08h-16m-11s UTC integration manifest
>
> Test drv_getparams_basic:
>          Subgroup basic-eu-total:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-subslice-total:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
> Test drv_hangman:
>          Subgroup error-state-basic:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
> Test gem_basic:
>          Subgroup bad-close:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup create-close:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup create-fd-close:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
> Test gem_cpu_reloc:
>          Subgroup basic:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
> Test gem_ctx_create:
>          Subgroup basic:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
> Test gem_ctx_exec:
>          Subgroup basic:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
> Test gem_ctx_param_basic:
>          Subgroup basic:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-default:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup invalid-ctx-get:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup invalid-ctx-set:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup invalid-param-get:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup invalid-param-set:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup invalid-size-get:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup invalid-size-set:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup non-root-set:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup non-root-set-no-zeromap:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup root-set:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup root-set-no-zeromap-disabled:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup root-set-no-zeromap-enabled:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
> Test gem_exec_parse:
>          Subgroup basic-allowed:
>                  skip       -> DMESG-FAIL (skl-i5k-2)
>                  skip       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-rejected:
>                  skip       -> DMESG-FAIL (skl-i5k-2)
>                  skip       -> DMESG-FAIL (skl-i7k-2)
> Test gem_flink_basic:
>          Subgroup bad-flink:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup bad-open:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup double-flink:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup flink-lifetime:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
> Test gem_linear_blits:
>          Subgroup basic:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
> Test gem_mmap:
>          Subgroup basic:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-small-bo:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
> Test gem_mmap_gtt:
>          Subgroup basic:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-copy:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-read:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-read-no-prefault:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-read-write:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-read-write-distinct:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-short:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-small-bo:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-small-bo-tiledx:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-small-bo-tiledy:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-small-copy:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-small-copy-xy:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-write:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-write-cpu-read-gtt:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-write-gtt:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-write-gtt-no-prefault:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-write-no-prefault:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-write-read:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-write-read-distinct:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
> Test gem_pread:
>          Subgroup basic:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
> Test gem_pwrite:
>          Subgroup basic:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
> Test gem_render_linear_blits:
>          Subgroup basic:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
> Test gem_render_tiled_blits:
>          Subgroup basic:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
> Test gem_storedw_loop:
>          Subgroup basic-blt:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-bsd:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-render:
>                  dmesg-warn -> DMESG-FAIL (skl-i5k-2) UNSTABLE
>                  pass       -> DMESG-WARN (bdw-nuci7) UNSTABLE
>                  pass       -> DMESG-FAIL (skl-i7k-2) UNSTABLE
>                  dmesg-warn -> PASS       (bdw-ultra) UNSTABLE
>          Subgroup basic-vebox:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
> Test gem_tiled_blits:
>          Subgroup basic:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
> Test gem_tiled_fence_blits:
>          Subgroup basic:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
> Test kms_addfb_basic:
>          Subgroup addfb25-bad-modifier:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup addfb25-framebuffer-vs-set-tiling:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup addfb25-modifier-no-flag:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup addfb25-x-tiled:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup addfb25-x-tiled-mismatch:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup addfb25-y-tiled:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup addfb25-y-tiled-small:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup addfb25-yf-tiled:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup bad-pitch-0:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup bad-pitch-1024:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup bad-pitch-128:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup bad-pitch-256:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup bad-pitch-32:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup bad-pitch-63:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup bad-pitch-65536:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup bad-pitch-999:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-x-tiled:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-y-tiled:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup bo-too-small:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup bo-too-small-due-to-tiling:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup clobberred-modifier:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup framebuffer-vs-set-tiling:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup no-handle:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup size-max:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup small-bo:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup tile-pitch-mismatch:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup too-high:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup too-wide:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup unused-handle:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup unused-modifier:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup unused-offsets:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup unused-pitches:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
> Test kms_flip:
>          Subgroup basic-flip-vs-dpms:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-flip-vs-modeset:
>                  pass       -> DMESG-FAIL (skl-i5k-2) UNSTABLE
>                  pass       -> DMESG-FAIL (skl-i7k-2) UNSTABLE
>          Subgroup basic-flip-vs-wf_vblank:
>                  pass       -> DMESG-FAIL (skl-i5k-2) UNSTABLE
>                  pass       -> DMESG-FAIL (skl-i7k-2) UNSTABLE
>          Subgroup basic-plain-flip:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
> Test kms_force_connector_basic:
>          Subgroup force-connector-state:
>                  skip       -> DMESG-FAIL (skl-i5k-2)
>                  skip       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup force-edid:
>                  skip       -> DMESG-FAIL (skl-i5k-2)
>                  skip       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup prune-stale-modes:
>                  skip       -> DMESG-FAIL (skl-i5k-2)
>                  skip       -> DMESG-FAIL (skl-i7k-2)
> Test kms_pipe_crc_basic:
>          Subgroup bad-nb-words-1:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup bad-nb-words-3:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup bad-pipe:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup bad-source:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup hang-read-crc-pipe-a:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup hang-read-crc-pipe-b:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup hang-read-crc-pipe-c:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup read-crc-pipe-a:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2) UNSTABLE
>          Subgroup read-crc-pipe-a-frame-sequence:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup read-crc-pipe-b:
>                  pass       -> DMESG-FAIL (skl-i5k-2) UNSTABLE
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup read-crc-pipe-b-frame-sequence:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup read-crc-pipe-c:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup read-crc-pipe-c-frame-sequence:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup suspend-read-crc-pipe-a:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup suspend-read-crc-pipe-b:
>                  dmesg-warn -> DMESG-FAIL (skl-i5k-2)
>                  dmesg-warn -> DMESG-FAIL (skl-i7k-2)
>          Subgroup suspend-read-crc-pipe-c:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
> Test kms_psr_sink_crc:
>          Subgroup psr_basic:
>                  skip       -> DMESG-FAIL (skl-i5k-2)
>                  skip       -> DMESG-FAIL (skl-i7k-2)
> Test kms_setmode:
>          Subgroup basic-clone-single-crtc:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
> Test pm_rpm:
>          Subgroup basic-pci-d3-state:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-rte:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
> Test pm_rps:
>          Subgroup basic-api:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
> Test prime_self_import:
>          Subgroup basic-llseek-bad:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-llseek-size:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-with_fd_dup:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-with_one_bo:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-with_one_bo_two_files:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>          Subgroup basic-with_two_bos:
>                  pass       -> DMESG-FAIL (skl-i5k-2)
>                  pass       -> DMESG-FAIL (skl-i7k-2)
>
> bdw-nuci7        total:132  pass:122  dwarn:1   dfail:0   fail:0   skip:9
> bdw-ultra        total:132  pass:126  dwarn:0   dfail:0   fail:0   skip:6
> bsw-nuc-2        total:135  pass:115  dwarn:0   dfail:0   fail:0   skip:20
> byt-nuc          total:135  pass:121  dwarn:1   dfail:0   fail:0   skip:13
> hsw-brixbox      total:135  pass:128  dwarn:0   dfail:0   fail:0   skip:7
> hsw-gt2          total:135  pass:131  dwarn:0   dfail:0   fail:0   skip:4
> ilk-hp8440p      total:135  pass:100  dwarn:0   dfail:0   fail:0   skip:35
> ivb-t430s        total:135  pass:129  dwarn:0   dfail:0   fail:0   skip:6
> skl-i5k-2        total:135  pass:2    dwarn:0   dfail:132 fail:0   skip:1
> skl-i7k-2        total:135  pass:2    dwarn:0   dfail:132 fail:0   skip:1
> snb-dellxps      total:135  pass:123  dwarn:0   dfail:0   fail:0   skip:12
> snb-x220t        total:135  pass:123  dwarn:0   dfail:0   fail:1   skip:11
>
> Results at /archive/results/CI_IGT_test/Patchwork_1094/
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Looks like the CI SKL doesn't have the GuC firmware installed?

.Dave.

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

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

* ✗ failure: Fi.CI.BAT
  2016-01-06 11:09 [PATCH 1/3] drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off) Chris Wilson
@ 2016-01-06 13:20 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-06 13:20 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Summary ==

Built on 89d0d1b6f0e9c3a6b90476bd115cfe1881646fd6 drm-intel-nightly: 2016y-01m-06d-10h-37m-17s UTC integration manifest

Test gem_basic:
        Subgroup create-close:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_cpu_reloc:
        Subgroup basic:
                pass       -> DMESG-FAIL (skl-i7k-2)
Test gem_ctx_param_basic:
        Subgroup basic:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup invalid-param-set:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup non-root-set-no-zeromap:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup root-set-no-zeromap-disabled:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_mmap:
        Subgroup basic:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_mmap_gtt:
        Subgroup basic-read:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup basic-write:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_storedw_loop:
        Subgroup basic-render:
                dmesg-warn -> PASS       (skl-i5k-2) UNSTABLE
Test kms_addfb_basic:
        Subgroup addfb25-modifier-no-flag:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup addfb25-x-tiled-mismatch:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup bad-pitch-1024:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup bad-pitch-63:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup bad-pitch-999:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup clobberred-modifier:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup too-high:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup too-wide:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup unused-offsets:
                pass       -> DMESG-WARN (skl-i7k-2)
Test kms_flip:
        Subgroup basic-plain-flip:
                pass       -> DMESG-FAIL (skl-i7k-2)
Test kms_pipe_crc_basic:
        Subgroup read-crc-pipe-b-frame-sequence:
                pass       -> DMESG-FAIL (skl-i7k-2)
Test pm_rpm:
        Subgroup basic-rte:
                pass       -> DMESG-WARN (byt-nuc) UNSTABLE
Test prime_self_import:
        Subgroup basic-with_two_bos:
                pass       -> DMESG-WARN (skl-i7k-2)

bdw-nuci7        total:132  pass:1    dwarn:0   dfail:0   fail:0   skip:131
bsw-nuc-2        total:135  pass:115  dwarn:0   dfail:0   fail:0   skip:20 
byt-nuc          total:135  pass:121  dwarn:1   dfail:0   fail:0   skip:13 
skl-i5k-2        total:135  pass:126  dwarn:1   dfail:0   fail:0   skip:8  
skl-i7k-2        total:135  pass:103  dwarn:20  dfail:3   fail:0   skip:8  
snb-dellxps      total:135  pass:123  dwarn:0   dfail:0   fail:0   skip:12 

Results at /archive/results/CI_IGT_test/Patchwork_1098/

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

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

* ✗ failure: Fi.CI.BAT
  2016-01-06  2:26 [PATCH 1/2] drm/i915: fix get digital port issue in intel_audio libin.yang
@ 2016-01-06 12:49 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-06 12:49 UTC (permalink / raw)
  To: libin.yang; +Cc: intel-gfx

== Summary ==

Built on 89d0d1b6f0e9c3a6b90476bd115cfe1881646fd6 drm-intel-nightly: 2016y-01m-06d-10h-37m-17s UTC integration manifest

Test kms_addfb_basic:
        Subgroup small-bo:
                skip       -> PASS       (bdw-nuci7)
Test pm_rpm:
        Subgroup basic-rte:
                pass       -> DMESG-WARN (byt-nuc) UNSTABLE

bdw-nuci7        total:132  pass:1    dwarn:0   dfail:0   fail:0   skip:131
bsw-nuc-2        total:135  pass:115  dwarn:0   dfail:0   fail:0   skip:20 
byt-nuc          total:135  pass:121  dwarn:1   dfail:0   fail:0   skip:13 
skl-i5k-2        total:135  pass:125  dwarn:2   dfail:0   fail:0   skip:8  
skl-i7k-2        total:135  pass:125  dwarn:2   dfail:0   fail:0   skip:8  

HANGED snb-dellxps in igt@drv_module_reload_basic

Results at /archive/results/CI_IGT_test/Patchwork_1097/

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

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

* ✗ failure: Fi.CI.BAT
  2016-01-05 19:18 [PATCH] drm/i915: Cleaning up DDI translation tables Rodrigo Vivi
@ 2016-01-06 11:30 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-06 11:30 UTC (permalink / raw)
  To: Rodrigo Vivi; +Cc: intel-gfx

== Summary ==

HEAD is now at 89d0d1b drm-intel-nightly: 2016y-01m-06d-10h-37m-17s UTC integration manifest
Applying: drm/i915: Cleaning up DDI translation tables
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 drm/i915: Cleaning up DDI translation tables

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

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

* ✗ failure: Fi.CI.BAT
  2016-01-05 19:10 [PATCH] drm/i915/guc: Enable GuC submission, where supported yu.dai
@ 2016-01-06 10:20 ` Patchwork
  2016-01-07 10:27   ` Dave Gordon
  0 siblings, 1 reply; 118+ messages in thread
From: Patchwork @ 2016-01-06 10:20 UTC (permalink / raw)
  To: yu.dai; +Cc: intel-gfx

== Summary ==

Built on 24b053acb16b4b3b021575e4ee30ffedd3ab2920 drm-intel-nightly: 2016y-01m-06d-08h-16m-11s UTC integration manifest

Test drv_getparams_basic:
        Subgroup basic-eu-total:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-subslice-total:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
Test drv_hangman:
        Subgroup error-state-basic:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
Test gem_basic:
        Subgroup bad-close:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup create-close:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup create-fd-close:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
Test gem_cpu_reloc:
        Subgroup basic:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
Test gem_ctx_create:
        Subgroup basic:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
Test gem_ctx_exec:
        Subgroup basic:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
Test gem_ctx_param_basic:
        Subgroup basic:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-default:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup invalid-ctx-get:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup invalid-ctx-set:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup invalid-param-get:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup invalid-param-set:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup invalid-size-get:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup invalid-size-set:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup non-root-set:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup non-root-set-no-zeromap:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup root-set:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup root-set-no-zeromap-disabled:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup root-set-no-zeromap-enabled:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
Test gem_exec_parse:
        Subgroup basic-allowed:
                skip       -> DMESG-FAIL (skl-i5k-2)
                skip       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-rejected:
                skip       -> DMESG-FAIL (skl-i5k-2)
                skip       -> DMESG-FAIL (skl-i7k-2)
Test gem_flink_basic:
        Subgroup bad-flink:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup bad-open:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup double-flink:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup flink-lifetime:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
Test gem_linear_blits:
        Subgroup basic:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
Test gem_mmap:
        Subgroup basic:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-small-bo:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
Test gem_mmap_gtt:
        Subgroup basic:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-copy:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-read:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-read-no-prefault:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-read-write:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-read-write-distinct:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-short:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-small-bo:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-small-bo-tiledx:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-small-bo-tiledy:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-small-copy:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-small-copy-xy:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-write:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-write-cpu-read-gtt:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-write-gtt:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-write-gtt-no-prefault:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-write-no-prefault:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-write-read:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-write-read-distinct:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
Test gem_pread:
        Subgroup basic:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
Test gem_pwrite:
        Subgroup basic:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
Test gem_render_linear_blits:
        Subgroup basic:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
Test gem_render_tiled_blits:
        Subgroup basic:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
Test gem_storedw_loop:
        Subgroup basic-blt:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-bsd:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-render:
                dmesg-warn -> DMESG-FAIL (skl-i5k-2) UNSTABLE
                pass       -> DMESG-WARN (bdw-nuci7) UNSTABLE
                pass       -> DMESG-FAIL (skl-i7k-2) UNSTABLE
                dmesg-warn -> PASS       (bdw-ultra) UNSTABLE
        Subgroup basic-vebox:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
Test gem_tiled_blits:
        Subgroup basic:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
Test gem_tiled_fence_blits:
        Subgroup basic:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
Test kms_addfb_basic:
        Subgroup addfb25-bad-modifier:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup addfb25-framebuffer-vs-set-tiling:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup addfb25-modifier-no-flag:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup addfb25-x-tiled:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup addfb25-x-tiled-mismatch:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup addfb25-y-tiled:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup addfb25-y-tiled-small:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup addfb25-yf-tiled:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup bad-pitch-0:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup bad-pitch-1024:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup bad-pitch-128:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup bad-pitch-256:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup bad-pitch-32:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup bad-pitch-63:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup bad-pitch-65536:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup bad-pitch-999:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-x-tiled:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-y-tiled:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup bo-too-small:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup bo-too-small-due-to-tiling:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup clobberred-modifier:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup framebuffer-vs-set-tiling:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup no-handle:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup size-max:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup small-bo:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup tile-pitch-mismatch:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup too-high:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup too-wide:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup unused-handle:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup unused-modifier:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup unused-offsets:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup unused-pitches:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
Test kms_flip:
        Subgroup basic-flip-vs-dpms:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-flip-vs-modeset:
                pass       -> DMESG-FAIL (skl-i5k-2) UNSTABLE
                pass       -> DMESG-FAIL (skl-i7k-2) UNSTABLE
        Subgroup basic-flip-vs-wf_vblank:
                pass       -> DMESG-FAIL (skl-i5k-2) UNSTABLE
                pass       -> DMESG-FAIL (skl-i7k-2) UNSTABLE
        Subgroup basic-plain-flip:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
Test kms_force_connector_basic:
        Subgroup force-connector-state:
                skip       -> DMESG-FAIL (skl-i5k-2)
                skip       -> DMESG-FAIL (skl-i7k-2)
        Subgroup force-edid:
                skip       -> DMESG-FAIL (skl-i5k-2)
                skip       -> DMESG-FAIL (skl-i7k-2)
        Subgroup prune-stale-modes:
                skip       -> DMESG-FAIL (skl-i5k-2)
                skip       -> DMESG-FAIL (skl-i7k-2)
Test kms_pipe_crc_basic:
        Subgroup bad-nb-words-1:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup bad-nb-words-3:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup bad-pipe:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup bad-source:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup hang-read-crc-pipe-a:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup hang-read-crc-pipe-b:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup hang-read-crc-pipe-c:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup read-crc-pipe-a:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2) UNSTABLE
        Subgroup read-crc-pipe-a-frame-sequence:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup read-crc-pipe-b:
                pass       -> DMESG-FAIL (skl-i5k-2) UNSTABLE
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup read-crc-pipe-b-frame-sequence:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup read-crc-pipe-c:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup read-crc-pipe-c-frame-sequence:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup suspend-read-crc-pipe-a:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup suspend-read-crc-pipe-b:
                dmesg-warn -> DMESG-FAIL (skl-i5k-2)
                dmesg-warn -> DMESG-FAIL (skl-i7k-2)
        Subgroup suspend-read-crc-pipe-c:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
Test kms_psr_sink_crc:
        Subgroup psr_basic:
                skip       -> DMESG-FAIL (skl-i5k-2)
                skip       -> DMESG-FAIL (skl-i7k-2)
Test kms_setmode:
        Subgroup basic-clone-single-crtc:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
Test pm_rpm:
        Subgroup basic-pci-d3-state:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-rte:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
Test pm_rps:
        Subgroup basic-api:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
Test prime_self_import:
        Subgroup basic-llseek-bad:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-llseek-size:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-with_fd_dup:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-with_one_bo:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-with_one_bo_two_files:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup basic-with_two_bos:
                pass       -> DMESG-FAIL (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)

bdw-nuci7        total:132  pass:122  dwarn:1   dfail:0   fail:0   skip:9  
bdw-ultra        total:132  pass:126  dwarn:0   dfail:0   fail:0   skip:6  
bsw-nuc-2        total:135  pass:115  dwarn:0   dfail:0   fail:0   skip:20 
byt-nuc          total:135  pass:121  dwarn:1   dfail:0   fail:0   skip:13 
hsw-brixbox      total:135  pass:128  dwarn:0   dfail:0   fail:0   skip:7  
hsw-gt2          total:135  pass:131  dwarn:0   dfail:0   fail:0   skip:4  
ilk-hp8440p      total:135  pass:100  dwarn:0   dfail:0   fail:0   skip:35 
ivb-t430s        total:135  pass:129  dwarn:0   dfail:0   fail:0   skip:6  
skl-i5k-2        total:135  pass:2    dwarn:0   dfail:132 fail:0   skip:1  
skl-i7k-2        total:135  pass:2    dwarn:0   dfail:132 fail:0   skip:1  
snb-dellxps      total:135  pass:123  dwarn:0   dfail:0   fail:0   skip:12 
snb-x220t        total:135  pass:123  dwarn:0   dfail:0   fail:1   skip:11 

Results at /archive/results/CI_IGT_test/Patchwork_1094/

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

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

* ✗ failure: Fi.CI.BAT
  2015-12-18 20:00 [PATCH v2 0/5] Add GuC ADS (Addition Data Structure) yu.dai
  2016-01-05 12:30 ` ✗ failure: Fi.CI.BAT Patchwork
@ 2016-01-06  9:01 ` Patchwork
  1 sibling, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-06  9:01 UTC (permalink / raw)
  To: yu.dai; +Cc: intel-gfx

== Summary ==

HEAD is now at 24b053a drm-intel-nightly: 2016y-01m-06d-08h-16m-11s UTC integration manifest
Applying: drm/i915/guc: Expose (intel)_lr_context_size()
Using index info to reconstruct a base tree...
M	drivers/gpu/drm/i915/intel_lrc.c
M	drivers/gpu/drm/i915/intel_lrc.h
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_lrc.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_lrc.c
Patch failed at 0001 drm/i915/guc: Expose (intel)_lr_context_size()

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

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

* ✗ failure: Fi.CI.BAT
  2016-01-05 16:54 [PATCH] drm/i915: Tune down rpm wakelock debug checks Daniel Vetter
@ 2016-01-06  7:49 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-06  7:49 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

== Summary ==

Built on bc303261a81a96298b2f9e02734aeaa0a25421a6 drm-intel-nightly: 2016y-01m-05d-16h-47m-54s UTC integration manifest

Test gem_ctx_param_basic:
        Subgroup basic:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup invalid-param-set:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_mmap_gtt:
        Subgroup basic-write:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_storedw_loop:
        Subgroup basic-render:
                pass       -> DMESG-WARN (skl-i5k-2) UNSTABLE
Test kms_addfb_basic:
        Subgroup too-wide:
                pass       -> DMESG-WARN (skl-i7k-2)
Test kms_flip:
        Subgroup basic-flip-vs-modeset:
                dmesg-warn -> PASS       (hsw-brixbox) UNSTABLE
        Subgroup basic-flip-vs-wf_vblank:
                dmesg-warn -> PASS       (skl-i5k-2) UNSTABLE
                dmesg-warn -> PASS       (hsw-gt2) UNSTABLE
                dmesg-warn -> PASS       (bdw-ultra) UNSTABLE
                dmesg-warn -> PASS       (skl-i7k-2) UNSTABLE
                dmesg-warn -> PASS       (ivb-t430s) UNSTABLE
                dmesg-warn -> PASS       (byt-nuc) UNSTABLE
                dmesg-warn -> PASS       (snb-x220t) UNSTABLE
                dmesg-warn -> PASS       (snb-dellxps) UNSTABLE
                dmesg-warn -> PASS       (hsw-brixbox) UNSTABLE
        Subgroup basic-plain-flip:
                dmesg-warn -> PASS       (ivb-t430s)
Test kms_pipe_crc_basic:
        Subgroup read-crc-pipe-a:
                dmesg-warn -> PASS       (snb-x220t) UNSTABLE
        Subgroup read-crc-pipe-b:
                dmesg-warn -> PASS       (skl-i5k-2) UNSTABLE
                dmesg-warn -> PASS       (snb-dellxps) UNSTABLE
        Subgroup read-crc-pipe-b-frame-sequence:
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup read-crc-pipe-c-frame-sequence:
                dmesg-warn -> PASS       (bsw-nuc-2) UNSTABLE
Test kms_psr_sink_crc:
        Subgroup psr_basic:
                dmesg-warn -> PASS       (bdw-ultra)
Test pm_rpm:
        Subgroup basic-rte:
                pass       -> DMESG-WARN (byt-nuc) UNSTABLE

bdw-ultra        total:132  pass:126  dwarn:0   dfail:0   fail:0   skip:6  
bsw-nuc-2        total:135  pass:115  dwarn:0   dfail:0   fail:0   skip:20 
byt-nuc          total:135  pass:121  dwarn:1   dfail:0   fail:0   skip:13 
hsw-brixbox      total:135  pass:128  dwarn:0   dfail:0   fail:0   skip:7  
hsw-gt2          total:135  pass:131  dwarn:0   dfail:0   fail:0   skip:4  
ilk-hp8440p      total:135  pass:100  dwarn:0   dfail:0   fail:0   skip:35 
ivb-t430s        total:135  pass:129  dwarn:0   dfail:0   fail:0   skip:6  
skl-i5k-2        total:135  pass:125  dwarn:2   dfail:0   fail:0   skip:8  
skl-i7k-2        total:135  pass:120  dwarn:6   dfail:1   fail:0   skip:8  
snb-dellxps      total:135  pass:123  dwarn:0   dfail:0   fail:0   skip:12 
snb-x220t        total:135  pass:123  dwarn:0   dfail:0   fail:1   skip:11 

Results at /archive/results/CI_IGT_test/Patchwork_1090/

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

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

* ✗ failure: Fi.CI.BAT
  2015-12-21 13:10 [PATCH 00/15] drm/i915/bios: mipi sequence block v3, etc Jani Nikula
@ 2016-01-05 16:01 ` Patchwork
  2016-01-11 13:30 ` Patchwork
  2016-01-11 14:01 ` Patchwork
  2 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-05 16:01 UTC (permalink / raw)
  To: Jani Nikula; +Cc: intel-gfx

== Summary ==

HEAD is now at 865e245 drm-intel-nightly: 2016y-01m-05d-15h-23m-53s UTC integration manifest
Applying: drm/i915/bios: add proper documentation for the Video BIOS Table (VBT)
Using index info to reconstruct a base tree...
M	Documentation/DocBook/gpu.tmpl
M	drivers/gpu/drm/i915/intel_bios.c
M	drivers/gpu/drm/i915/intel_bios.h
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_bios.h
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_bios.h
Auto-merging drivers/gpu/drm/i915/intel_bios.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_bios.c
Patch failed at 0001 drm/i915/bios: add proper documentation for the Video BIOS Table (VBT)

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

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

* ✗ failure: Fi.CI.BAT
  2015-12-18 20:00 [PATCH v2 0/5] Add GuC ADS (Addition Data Structure) yu.dai
@ 2016-01-05 12:30 ` Patchwork
  2016-01-06  9:01 ` Patchwork
  1 sibling, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-05 12:30 UTC (permalink / raw)
  To: Dave Gordon; +Cc: intel-gfx

== Summary ==

HEAD is now at c837c0f drm-intel-nightly: 2016y-01m-05d-10h-35m-52s UTC integration manifest
Applying: drm/i915: add kerneldoc for intel_lr_context_size()
Applying: drm/i915/guc: Add GuC ADS (Addition Data Structure) - allocation
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0002 drm/i915/guc: Add GuC ADS (Addition Data Structure) - allocation

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

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

* ✗ failure: Fi.CI.BAT
  2016-01-04 10:13 [PATCH] drm/i915: Force clean compilation with -Werror Chris Wilson
@ 2016-01-04 11:01 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-04 11:01 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Summary ==

HEAD is now at c1e9dc2 drm-intel-nightly: 2016y-01m-04d-09h-35m-16s UTC integration manifest
Applying: drm/i915: Force clean compilation with -Werror
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 drm/i915: Force clean compilation with -Werror

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

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

* ✗ failure: Fi.CI.BAT
  2016-01-04 10:10 [PATCH 1/3] drm: Balance error path for GEM handle allocation Chris Wilson
@ 2016-01-04 10:49 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2016-01-04 10:49 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Summary ==

Built on c1e9dc2dcb577438a6350c7f1cb36ba8ad0e1dfd drm-intel-nightly: 2016y-01m-04d-09h-35m-16s UTC integration manifest

Test gem_basic:
        Subgroup create-close:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_cpu_reloc:
        Subgroup basic:
                pass       -> DMESG-FAIL (skl-i7k-2)
Test gem_ctx_param_basic:
        Subgroup basic:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup invalid-param-set:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup non-root-set-no-zeromap:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup root-set-no-zeromap-disabled:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_mmap:
        Subgroup basic:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_mmap_gtt:
        Subgroup basic-read:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup basic-write:
                pass       -> DMESG-WARN (skl-i7k-2)
Test kms_addfb_basic:
        Subgroup addfb25-modifier-no-flag:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup addfb25-x-tiled-mismatch:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup bad-pitch-1024:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup bad-pitch-63:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup bad-pitch-999:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup clobberred-modifier:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup too-high:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup too-wide:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup unused-offsets:
                pass       -> DMESG-WARN (skl-i7k-2)
Test kms_flip:
        Subgroup basic-plain-flip:
                pass       -> DMESG-FAIL (skl-i7k-2)
Test kms_pipe_crc_basic:
        Subgroup read-crc-pipe-a-frame-sequence:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup read-crc-pipe-b:
                dmesg-warn -> PASS       (snb-dellxps)
        Subgroup read-crc-pipe-b-frame-sequence:
                pass       -> DMESG-FAIL (skl-i7k-2)
Test kms_setmode:
        Subgroup basic-clone-single-crtc:
                pass       -> DMESG-WARN (snb-dellxps)
Test prime_self_import:
        Subgroup basic-with_two_bos:
                pass       -> DMESG-WARN (skl-i7k-2)

bdw-nuci7        total:132  pass:122  dwarn:1   dfail:0   fail:0   skip:9  
bdw-ultra        total:132  pass:124  dwarn:2   dfail:0   fail:0   skip:6  
bsw-nuc-2        total:135  pass:114  dwarn:1   dfail:0   fail:0   skip:20 
byt-nuc          total:135  pass:120  dwarn:2   dfail:0   fail:0   skip:13 
hsw-brixbox      total:135  pass:126  dwarn:2   dfail:0   fail:0   skip:7  
hsw-gt2          total:135  pass:130  dwarn:1   dfail:0   fail:0   skip:4  
hsw-xps12        total:132  pass:125  dwarn:3   dfail:0   fail:0   skip:4  
ilk-hp8440p      total:135  pass:99   dwarn:1   dfail:0   fail:0   skip:35 
ivb-t430s        total:135  pass:127  dwarn:2   dfail:0   fail:0   skip:6  
skl-i5k-2        total:135  pass:124  dwarn:3   dfail:0   fail:0   skip:8  
skl-i7k-2        total:135  pass:101  dwarn:22  dfail:3   fail:0   skip:8  
snb-dellxps      total:135  pass:121  dwarn:2   dfail:0   fail:0   skip:12 
snb-x220t        total:135  pass:121  dwarn:2   dfail:0   fail:1   skip:11 

Results at /archive/results/CI_IGT_test/Patchwork_1063/

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

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

* ✗ failure: Fi.CI.BAT
  2015-12-31 12:45 [PATCH] drm/i915: Add RPM references in the *_get_hw_state functions Gabriel Feceoru
@ 2015-12-31 13:20 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2015-12-31 13:20 UTC (permalink / raw)
  To: Feceoru, Gabriel; +Cc: intel-gfx

== Summary ==

Built on 79686f613b3955a4ed09cee936e7f70ec4e61b67 drm-intel-nightly: 2015y-12m-30d-11h-59m-54s UTC integration manifest

Test gem_basic:
        Subgroup create-close:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_cpu_reloc:
        Subgroup basic:
                pass       -> DMESG-FAIL (skl-i7k-2)
Test gem_ctx_param_basic:
        Subgroup basic:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup invalid-param-set:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup non-root-set-no-zeromap:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup root-set-no-zeromap-disabled:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_mmap:
        Subgroup basic:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_mmap_gtt:
        Subgroup basic-read:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup basic-write:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_storedw_loop:
        Subgroup basic-render:
                dmesg-warn -> PASS       (skl-i5k-2)
                dmesg-warn -> PASS       (skl-i7k-2)
Test kms_addfb_basic:
        Subgroup addfb25-modifier-no-flag:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup addfb25-x-tiled-mismatch:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup bad-pitch-1024:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup bad-pitch-63:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup bad-pitch-999:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup clobberred-modifier:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup too-high:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup too-wide:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup unused-offsets:
                pass       -> DMESG-WARN (skl-i7k-2)
Test kms_flip:
        Subgroup basic-flip-vs-dpms:
                pass       -> DMESG-WARN (skl-i5k-2)
                pass       -> DMESG-WARN (skl-i7k-2)
                dmesg-warn -> PASS       (ilk-hp8440p)
        Subgroup basic-flip-vs-modeset:
                dmesg-warn -> PASS       (bsw-nuc-2)
                dmesg-warn -> PASS       (hsw-brixbox)
                dmesg-warn -> PASS       (bdw-nuci7)
                dmesg-warn -> PASS       (ilk-hp8440p)
        Subgroup basic-plain-flip:
                pass       -> DMESG-WARN (skl-i5k-2)
                pass       -> DMESG-WARN (snb-x220t)
                pass       -> DMESG-WARN (bdw-ultra)
                pass       -> DMESG-FAIL (skl-i7k-2)
Test kms_force_connector_basic:
        Subgroup force-connector-state:
                pass       -> SKIP       (snb-x220t)
Test kms_pipe_crc_basic:
        Subgroup hang-read-crc-pipe-a:
                pass       -> DMESG-WARN (skl-i5k-2)
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup hang-read-crc-pipe-b:
                pass       -> DMESG-WARN (skl-i5k-2)
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup hang-read-crc-pipe-c:
                pass       -> DMESG-WARN (skl-i5k-2)
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup read-crc-pipe-a:
                pass       -> DMESG-WARN (skl-i5k-2)
                dmesg-warn -> PASS       (snb-x220t)
                pass       -> DMESG-WARN (skl-i7k-2)
                dmesg-warn -> PASS       (byt-nuc)
        Subgroup read-crc-pipe-a-frame-sequence:
                pass       -> DMESG-WARN (skl-i5k-2)
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup read-crc-pipe-b:
                pass       -> DMESG-WARN (skl-i5k-2)
                pass       -> DMESG-WARN (snb-dellxps)
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup read-crc-pipe-b-frame-sequence:
                pass       -> DMESG-WARN (skl-i5k-2)
                pass       -> DMESG-FAIL (skl-i7k-2)
        Subgroup read-crc-pipe-c:
                pass       -> DMESG-WARN (skl-i5k-2)
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup read-crc-pipe-c-frame-sequence:
                pass       -> DMESG-WARN (skl-i5k-2)
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup suspend-read-crc-pipe-a:
                pass       -> DMESG-WARN (skl-i5k-2)
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup suspend-read-crc-pipe-c:
                pass       -> DMESG-WARN (skl-i5k-2)
                pass       -> DMESG-WARN (skl-i7k-2)
Test kms_psr_sink_crc:
        Subgroup psr_basic:
                dmesg-warn -> PASS       (bdw-ultra)
Test kms_setmode:
        Subgroup basic-clone-single-crtc:
                dmesg-warn -> PASS       (snb-dellxps)
Test pm_rpm:
        Subgroup basic-pci-d3-state:
                pass       -> DMESG-WARN (skl-i5k-2)
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup basic-rte:
                pass       -> DMESG-WARN (skl-i5k-2)
                pass       -> DMESG-WARN (skl-i7k-2)
Test prime_self_import:
        Subgroup basic-with_two_bos:
                pass       -> DMESG-WARN (skl-i7k-2)

bdw-nuci7        total:132  pass:122  dwarn:1   dfail:0   fail:0   skip:9  
bdw-ultra        total:132  pass:124  dwarn:2   dfail:0   fail:0   skip:6  
bsw-nuc-2        total:135  pass:114  dwarn:1   dfail:0   fail:0   skip:20 
byt-nuc          total:135  pass:120  dwarn:2   dfail:0   fail:0   skip:13 
hsw-brixbox      total:135  pass:127  dwarn:1   dfail:0   fail:0   skip:7  
hsw-gt2          total:135  pass:130  dwarn:1   dfail:0   fail:0   skip:4  
hsw-xps12        total:132  pass:125  dwarn:3   dfail:0   fail:0   skip:4  
ilk-hp8440p      total:135  pass:100  dwarn:0   dfail:0   fail:0   skip:35 
ivb-t430s        total:135  pass:127  dwarn:2   dfail:0   fail:0   skip:6  
skl-i5k-2        total:135  pass:108  dwarn:19  dfail:0   fail:0   skip:8  
skl-i7k-2        total:135  pass:89   dwarn:34  dfail:3   fail:0   skip:8  
snb-dellxps      total:135  pass:121  dwarn:2   dfail:0   fail:0   skip:12 
snb-x220t        total:135  pass:120  dwarn:2   dfail:0   fail:1   skip:12 

Results at /archive/results/CI_IGT_test/Patchwork_981/

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

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

* ✗ failure: Fi.CI.BAT
  2015-12-30 22:56 [PATCH] drm/i915/bxt: Fix eDP panel power save/restore Matt Roper
@ 2015-12-31  7:43 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2015-12-31  7:43 UTC (permalink / raw)
  To: Matt Roper; +Cc: intel-gfx

== Summary ==

Built on 79686f613b3955a4ed09cee936e7f70ec4e61b67 drm-intel-nightly: 2015y-12m-30d-11h-59m-54s UTC integration manifest

Test gem_ctx_param_basic:
        Subgroup basic:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup invalid-param-set:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_mmap_gtt:
        Subgroup basic-write:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_storedw_loop:
        Subgroup basic-render:
                dmesg-warn -> PASS       (skl-i5k-2)
Test kms_addfb_basic:
        Subgroup too-wide:
                pass       -> DMESG-WARN (skl-i7k-2)
Test kms_flip:
        Subgroup basic-flip-vs-dpms:
                dmesg-warn -> PASS       (ilk-hp8440p)
        Subgroup basic-flip-vs-modeset:
                dmesg-warn -> PASS       (bsw-nuc-2)
                dmesg-warn -> PASS       (hsw-xps12)
                dmesg-warn -> PASS       (hsw-brixbox)
                dmesg-warn -> PASS       (bdw-nuci7)
                dmesg-warn -> PASS       (ilk-hp8440p)
Test kms_pipe_crc_basic:
        Subgroup read-crc-pipe-a:
                dmesg-warn -> PASS       (snb-x220t)
                dmesg-warn -> PASS       (byt-nuc)
        Subgroup read-crc-pipe-b:
                pass       -> DMESG-WARN (snb-dellxps)
        Subgroup read-crc-pipe-b-frame-sequence:
                pass       -> DMESG-FAIL (skl-i7k-2)
Test kms_setmode:
        Subgroup basic-clone-single-crtc:
                dmesg-warn -> PASS       (snb-dellxps)
Test pm_rpm:
        Subgroup basic-rte:
                dmesg-warn -> PASS       (byt-nuc)

bdw-nuci7        total:132  pass:122  dwarn:1   dfail:0   fail:0   skip:9  
bdw-ultra        total:132  pass:124  dwarn:2   dfail:0   fail:0   skip:6  
bsw-nuc-2        total:135  pass:114  dwarn:1   dfail:0   fail:0   skip:20 
byt-nuc          total:135  pass:121  dwarn:1   dfail:0   fail:0   skip:13 
hsw-brixbox      total:135  pass:127  dwarn:1   dfail:0   fail:0   skip:7  
hsw-gt2          total:135  pass:130  dwarn:1   dfail:0   fail:0   skip:4  
hsw-xps12        total:132  pass:126  dwarn:2   dfail:0   fail:0   skip:4  
ilk-hp8440p      total:135  pass:100  dwarn:0   dfail:0   fail:0   skip:35 
ivb-t430s        total:135  pass:127  dwarn:2   dfail:0   fail:0   skip:6  
skl-i5k-2        total:135  pass:124  dwarn:3   dfail:0   fail:0   skip:8  
skl-i7k-2        total:135  pass:119  dwarn:7   dfail:1   fail:0   skip:8  
snb-dellxps      total:135  pass:121  dwarn:2   dfail:0   fail:0   skip:12 
snb-x220t        total:135  pass:122  dwarn:1   dfail:0   fail:1   skip:11 

Results at /archive/results/CI_IGT_test/Patchwork_970/

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

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

* ✗ failure: Fi.CI.BAT
  2015-12-04 11:33 [PATCH] drm/i915: Avoid writing relocs with addresses in non-canonical form Michał Winiarski
@ 2015-12-29 16:20 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2015-12-29 16:20 UTC (permalink / raw)
  To: Michał Winiarski; +Cc: intel-gfx

== Summary ==

Built on ec0382c73cb1adc972bebdd94afad3f0ea117114 drm-intel-nightly: 2015y-12m-23d-22h-28m-25s UTC integration manifest

Test gem_ctx_param_basic:
        Subgroup root-set:
                skip       -> PASS       (ilk-hp8440p)
Test gem_storedw_loop:
        Subgroup basic-render:
                dmesg-warn -> PASS       (skl-i5k-2)
                dmesg-warn -> PASS       (bdw-nuci7)
Test kms_flip:
        Subgroup basic-flip-vs-dpms:
                dmesg-warn -> PASS       (ilk-hp8440p)
        Subgroup basic-flip-vs-modeset:
                dmesg-warn -> PASS       (skl-i5k-2)
                pass       -> DMESG-WARN (hsw-xps12)
                pass       -> DMESG-WARN (hsw-brixbox)
                pass       -> DMESG-WARN (bdw-nuci7)
        Subgroup basic-plain-flip:
                pass       -> DMESG-WARN (snb-x220t)
                pass       -> DMESG-WARN (snb-dellxps)
Test kms_pipe_crc_basic:
        Subgroup read-crc-pipe-a:
                dmesg-warn -> PASS       (snb-x220t)
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup read-crc-pipe-b:
                pass       -> DMESG-WARN (skl-i5k-2)
        Subgroup read-crc-pipe-b-frame-sequence:
                pass       -> DMESG-WARN (byt-nuc)
Test kms_setmode:
        Subgroup basic-clone-single-crtc:
                dmesg-warn -> PASS       (snb-dellxps)
Test pm_rpm:
        Subgroup basic-rte:
                dmesg-warn -> PASS       (hsw-xps12)
                pass       -> DMESG-WARN (byt-nuc)

bdw-nuci7        total:132  pass:121  dwarn:2   dfail:0   fail:0   skip:9  
bdw-ultra        total:132  pass:124  dwarn:2   dfail:0   fail:0   skip:6  
bsw-nuc-2        total:135  pass:113  dwarn:2   dfail:0   fail:0   skip:20 
byt-nuc          total:135  pass:119  dwarn:3   dfail:0   fail:0   skip:13 
hsw-brixbox      total:135  pass:126  dwarn:2   dfail:0   fail:0   skip:7  
hsw-xps12        total:132  pass:125  dwarn:3   dfail:0   fail:0   skip:4  
ilk-hp8440p      total:135  pass:101  dwarn:0   dfail:0   fail:0   skip:34 
ivb-t430s        total:135  pass:127  dwarn:2   dfail:0   fail:0   skip:6  
skl-i5k-2        total:135  pass:124  dwarn:3   dfail:0   fail:0   skip:8  
skl-i7k-2        total:135  pass:123  dwarn:4   dfail:0   fail:0   skip:8  
snb-dellxps      total:135  pass:121  dwarn:2   dfail:0   fail:0   skip:12 
snb-x220t        total:135  pass:121  dwarn:2   dfail:0   fail:1   skip:11 

HANGED hsw-gt2 in igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c

Results at /archive/results/CI_IGT_test/Patchwork_945/

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

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

* ✗ failure: Fi.CI.BAT
  2015-12-23  8:11 [PATCH] drm/i915: increase the tries for HDMI hotplug live status checking Gary Wang
@ 2015-12-23  8:49 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2015-12-23  8:49 UTC (permalink / raw)
  To: Gary Wang; +Cc: intel-gfx

== Summary ==

Built on 7e671e69deffb88d60687dacffe6e34a5d046500 drm-intel-nightly: 2015y-12m-22d-13h-28m-34s UTC integration manifest

Test gem_storedw_loop:
        Subgroup basic-render:
                pass       -> DMESG-WARN (skl-i5k-2)
Test kms_flip:
        Subgroup basic-flip-vs-dpms:
                dmesg-warn -> PASS       (ilk-hp8440p)
        Subgroup basic-flip-vs-modeset:
                dmesg-warn -> PASS       (bsw-nuc-2)
                dmesg-warn -> PASS       (hsw-xps12)
                pass       -> DMESG-WARN (hsw-brixbox)
                dmesg-warn -> PASS       (ilk-hp8440p)
                dmesg-warn -> PASS       (byt-nuc)
        Subgroup basic-flip-vs-wf_vblank:
                dmesg-warn -> PASS       (snb-x220t)
        Subgroup basic-plain-flip:
                pass       -> DMESG-WARN (hsw-xps12)
                pass       -> DMESG-WARN (bdw-nuci7)
Test kms_pipe_crc_basic:
        Subgroup hang-read-crc-pipe-a:
                pass       -> DMESG-WARN (snb-x220t)
        Subgroup read-crc-pipe-a:
                pass       -> DMESG-WARN (snb-x220t)
        Subgroup read-crc-pipe-a-frame-sequence:
                dmesg-warn -> PASS       (byt-nuc)
        Subgroup read-crc-pipe-b:
                dmesg-warn -> PASS       (skl-i5k-2)
        Subgroup read-crc-pipe-c:
                pass       -> DMESG-WARN (skl-i5k-2)
Test kms_psr_sink_crc:
        Subgroup psr_basic:
                dmesg-warn -> PASS       (bdw-ultra)
Test pm_rpm:
        Subgroup basic-pci-d3-state:
                pass       -> DMESG-WARN (bdw-ultra)

bdw-nuci7        total:132  pass:121  dwarn:2   dfail:0   fail:0   skip:9  
bdw-ultra        total:132  pass:124  dwarn:2   dfail:0   fail:0   skip:6  
bsw-nuc-2        total:135  pass:114  dwarn:1   dfail:0   fail:0   skip:20 
byt-nuc          total:135  pass:120  dwarn:2   dfail:0   fail:0   skip:13 
hsw-brixbox      total:135  pass:126  dwarn:2   dfail:0   fail:0   skip:7  
hsw-xps12        total:132  pass:125  dwarn:3   dfail:0   fail:0   skip:4  
ilk-hp8440p      total:135  pass:100  dwarn:0   dfail:0   fail:0   skip:35 
ivb-t430s        total:135  pass:127  dwarn:2   dfail:0   fail:0   skip:6  
skl-i5k-2        total:135  pass:123  dwarn:4   dfail:0   fail:0   skip:8  
skl-i7k-2        total:135  pass:124  dwarn:3   dfail:0   fail:0   skip:8  
snb-dellxps      total:135  pass:121  dwarn:2   dfail:0   fail:0   skip:12 
snb-x220t        total:135  pass:121  dwarn:2   dfail:0   fail:1   skip:11 

HANGED hsw-gt2 in igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c

Results at /archive/results/CI_IGT_test/Patchwork_801/

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

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

* ✗ failure: Fi.CI.BAT
  2015-12-21 18:53 [PATCH] drm, i915: Fix pointer size cast Borislav Petkov
@ 2015-12-22  7:30 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2015-12-22  7:30 UTC (permalink / raw)
  To: Borislav Petkov; +Cc: intel-gfx

== Summary ==

HEAD is now at 78deeec drm-intel-nightly: 2015y-12m-21d-16h-03m-57s UTC integration manifest
Applying: drm, i915: Fix pointer size cast
Using index info to reconstruct a base tree...
M	drivers/gpu/drm/i915/intel_display.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_display.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_display.c
Patch failed at 0001 drm, i915: Fix pointer size cast

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

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

* ✗ failure: Fi.CI.BAT
  2015-12-21 16:04 improve handling of the driver's internal default context Dave Gordon
@ 2015-12-22  7:20 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2015-12-22  7:20 UTC (permalink / raw)
  To: Dave Gordon; +Cc: intel-gfx

== Summary ==

Built on 78deeec98b10627fe2050ce8ebfa2ea2d5b9e6c7 drm-intel-nightly: 2015y-12m-21d-16h-03m-57s UTC integration manifest

Test gem_mmap_gtt:
        Subgroup basic-small-bo:
                dmesg-warn -> PASS       (bdw-nuci7)
Test gem_storedw_loop:
        Subgroup basic-render:
                pass       -> DMESG-WARN (skl-i5k-2)
                pass       -> DMESG-WARN (bdw-nuci7)
Test kms_flip:
        Subgroup basic-flip-vs-modeset:
                pass       -> DMESG-WARN (skl-i5k-2)
                pass       -> DMESG-WARN (hsw-xps12)
                dmesg-warn -> PASS       (hsw-brixbox)
                skip       -> DMESG-WARN (bdw-nuci7)
        Subgroup basic-plain-flip:
                skip       -> PASS       (bdw-nuci7)
Test kms_pipe_crc_basic:
        Subgroup read-crc-pipe-a:
                pass       -> DMESG-WARN (snb-x220t)
                skip       -> PASS       (bdw-nuci7)
                dmesg-warn -> PASS       (byt-nuc)
        Subgroup read-crc-pipe-a-frame-sequence:
                pass       -> FAIL       (snb-x220t)
                skip       -> PASS       (bdw-nuci7)
                pass       -> DMESG-WARN (ilk-hp8440p)
        Subgroup read-crc-pipe-b:
                dmesg-warn -> PASS       (skl-i5k-2)
                dmesg-warn -> PASS       (hsw-xps12)
                pass       -> DMESG-WARN (snb-dellxps)
                skip       -> PASS       (bdw-nuci7)
        Subgroup read-crc-pipe-b-frame-sequence:
                skip       -> PASS       (bdw-nuci7)
        Subgroup read-crc-pipe-c:
                skip       -> PASS       (bdw-nuci7)
Test kms_setmode:
        Subgroup basic-clone-single-crtc:
                dmesg-warn -> PASS       (snb-dellxps)
Test pm_rpm:
        Subgroup basic-pci-d3-state:
                skip       -> PASS       (bdw-nuci7)
                pass       -> DMESG-WARN (bdw-ultra)
        Subgroup basic-rte:
                skip       -> PASS       (bdw-nuci7)
                dmesg-warn -> PASS       (bdw-ultra)

bdw-nuci7        total:132  pass:120  dwarn:3   dfail:0   fail:0   skip:9  
bdw-ultra        total:132  pass:124  dwarn:2   dfail:0   fail:0   skip:6  
bsw-nuc-2        total:135  pass:114  dwarn:1   dfail:0   fail:0   skip:20 
byt-nuc          total:135  pass:120  dwarn:2   dfail:0   fail:0   skip:13 
hsw-brixbox      total:135  pass:127  dwarn:1   dfail:0   fail:0   skip:7  
hsw-xps12        total:132  pass:125  dwarn:3   dfail:0   fail:0   skip:4  
ilk-hp8440p      total:135  pass:99   dwarn:1   dfail:0   fail:0   skip:35 
ivb-t430s        total:135  pass:127  dwarn:2   dfail:0   fail:0   skip:6  
skl-i5k-2        total:135  pass:121  dwarn:6   dfail:0   fail:0   skip:8  
skl-i7k-2        total:135  pass:122  dwarn:5   dfail:0   fail:0   skip:8  
snb-dellxps      total:135  pass:121  dwarn:2   dfail:0   fail:0   skip:12 
snb-x220t        total:135  pass:120  dwarn:2   dfail:0   fail:2   skip:11 

HANGED hsw-gt2 in igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b

Results at /archive/results/CI_IGT_test/Patchwork_783/

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

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

* ✗ failure: Fi.CI.BAT
  2015-12-21 15:33 [RFC v2] drm/i915/bdw+: Do not emit user interrupts when not needed Tvrtko Ursulin
@ 2015-12-21 17:30 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2015-12-21 17:30 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: intel-gfx

== Summary ==

HEAD is now at 78deeec drm-intel-nightly: 2015y-12m-21d-16h-03m-57s UTC integration manifest
Applying: drm/i915/bdw+: Do not emit user interrupts when not needed
Using index info to reconstruct a base tree...
M	drivers/gpu/drm/i915/i915_drv.h
M	drivers/gpu/drm/i915/intel_lrc.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_lrc.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_lrc.c
Auto-merging drivers/gpu/drm/i915/i915_drv.h
Patch failed at 0001 drm/i915/bdw+: Do not emit user interrupts when not needed

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

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

* Re: ✗ failure:  Fi.CI.BAT
  2015-12-18 15:01 ` ✗ failure: Fi.CI.BAT Patchwork
@ 2015-12-21 13:44   ` Daniel Vetter
  0 siblings, 0 replies; 118+ messages in thread
From: Daniel Vetter @ 2015-12-21 13:44 UTC (permalink / raw)
  To: Patchwork; +Cc: intel-gfx

On Fri, Dec 18, 2015 at 03:01:16PM -0000, Patchwork wrote:
> == Summary ==
> 
> HEAD is now at da33ddb drm-intel-nightly: 2015y-12m-18d-13h-53m-06s UTC integration manifest
> Applying: drm/i915: Extend LRC pinning to cover GPU context writeback
> Repository lacks necessary blobs to fall back on 3-way merge.
> Cannot fall back to three-way merge.
> Patch failed at 0001 drm/i915: Extend LRC pinning to cover GPU context writeback

Dependent patches should be submitted as an entire series.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* ✗ failure: Fi.CI.BAT
  2015-12-18 19:55 [PATCH] drm/i915: edp resume/On time optimization abhay.kumar
@ 2015-12-19  7:30 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2015-12-19  7:30 UTC (permalink / raw)
  To: abhay.kumar; +Cc: intel-gfx

== Summary ==

HEAD is now at 7cdc548 drm-intel-nightly: 2015y-12m-18d-19h-26m-21s UTC integration manifest
Applying: drm/i915: edp resume/On time optimization.
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 drm/i915: edp resume/On time optimization.

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

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

* ✗ failure: Fi.CI.BAT
  2015-12-18 17:24 [PATCH] drm/i915: Workaround CHV pipe C cursor fail ville.syrjala
@ 2015-12-18 17:49 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2015-12-18 17:49 UTC (permalink / raw)
  To: ville.syrjala; +Cc: intel-gfx

== Summary ==

Built on deb496ede4fc5e7affe15640a113ea9b5f1189e0 drm-intel-nightly: 2015y-12m-18d-16h-12m-24s UTC integration manifest

Test gem_storedw_loop:
        Subgroup basic-render:
                dmesg-warn -> PASS       (skl-i5k-2)
Test kms_flip:
        Subgroup basic-flip-vs-modeset:
                pass       -> DMESG-WARN (ilk-hp8440p)
                pass       -> DMESG-WARN (byt-nuc)
Test kms_pipe_crc_basic:
        Subgroup read-crc-pipe-a:
                pass       -> DMESG-WARN (snb-x220t)
        Subgroup read-crc-pipe-a-frame-sequence:
                pass       -> FAIL       (snb-x220t)
        Subgroup read-crc-pipe-c:
                dmesg-warn -> PASS       (bdw-ultra)
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup suspend-read-crc-pipe-a:
                dmesg-warn -> PASS       (snb-x220t)
Test kms_setmode:
        Subgroup basic-clone-single-crtc:
                dmesg-warn -> PASS       (snb-dellxps)
Test pm_rpm:
        Subgroup basic-pci-d3-state:
                pass       -> DMESG-WARN (bdw-ultra)

bdw-ultra        total:132  pass:124  dwarn:2   dfail:0   fail:0   skip:6  
bsw-nuc-2        total:135  pass:115  dwarn:0   dfail:0   fail:0   skip:20 
byt-nuc          total:135  pass:120  dwarn:2   dfail:0   fail:0   skip:13 
hsw-brixbox      total:135  pass:126  dwarn:2   dfail:0   fail:0   skip:7  
hsw-gt2          total:135  pass:130  dwarn:1   dfail:0   fail:0   skip:4  
ilk-hp8440p      total:135  pass:99   dwarn:1   dfail:0   fail:0   skip:35 
ivb-t430s        total:135  pass:127  dwarn:2   dfail:0   fail:0   skip:6  
skl-i5k-2        total:135  pass:122  dwarn:5   dfail:0   fail:0   skip:8  
skl-i7k-2        total:135  pass:121  dwarn:6   dfail:0   fail:0   skip:8  
snb-dellxps      total:135  pass:122  dwarn:1   dfail:0   fail:0   skip:12 
snb-x220t        total:135  pass:120  dwarn:2   dfail:0   fail:2   skip:11 

Results at /archive/results/CI_IGT_test/Patchwork_723/

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

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

* ✗ failure: Fi.CI.BAT
  2015-12-18 15:17 [PATCH] Allow userspace to set NULL blob on properties Lionel Landwerlin
@ 2015-12-18 15:30 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2015-12-18 15:30 UTC (permalink / raw)
  To: Lionel Landwerlin; +Cc: intel-gfx

== Summary ==

HEAD is now at da33ddb drm-intel-nightly: 2015y-12m-18d-13h-53m-06s UTC integration manifest
Applying: drm/atomic: allow setting a blob to NULL using id = 0
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 drm/atomic: allow setting a blob to NULL using id = 0

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

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

* ✗ failure: Fi.CI.BAT
  2015-12-18 14:41 [PATCH v9] drm/i915: Extend LRC pinning to cover GPU context writeback Nick Hoath
@ 2015-12-18 15:01 ` Patchwork
  2015-12-21 13:44   ` Daniel Vetter
  0 siblings, 1 reply; 118+ messages in thread
From: Patchwork @ 2015-12-18 15:01 UTC (permalink / raw)
  To: Nick Hoath; +Cc: intel-gfx

== Summary ==

HEAD is now at da33ddb drm-intel-nightly: 2015y-12m-18d-13h-53m-06s UTC integration manifest
Applying: drm/i915: Extend LRC pinning to cover GPU context writeback
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 drm/i915: Extend LRC pinning to cover GPU context writeback

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

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

* ✗ failure: Fi.CI.BAT
  2015-12-18 11:59 [RFC] drm/i915/bdw+: Do not emit user interrupts when not needed Tvrtko Ursulin
@ 2015-12-18 12:30 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2015-12-18 12:30 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: intel-gfx

== Summary ==

HEAD is now at 3c71db8 drm-intel-nightly: 2015y-12m-18d-09h-42m-49s UTC integration manifest
Applying: drm/i915/bdw+: Do not emit user interrupts when not needed
Using index info to reconstruct a base tree...
M	drivers/gpu/drm/i915/intel_lrc.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_lrc.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_lrc.c
Patch failed at 0001 drm/i915/bdw+: Do not emit user interrupts when not needed

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

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

* ✗ failure: Fi.CI.BAT
  2015-12-18 10:53 [PATCH] drm/i915/bdw+: Replace list_del+list_add_tail with list_move_tail Tvrtko Ursulin
@ 2015-12-18 11:49 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2015-12-18 11:49 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: intel-gfx

== Summary ==

Built on 3c71db89fc37b6061ce6b070ce73f89155da5f20 drm-intel-nightly: 2015y-12m-18d-09h-42m-49s UTC integration manifest

Test igt@kms_flip@basic-flip-vs-wf_vblank on ivb-t430s pass -> dmesg-warn
Test igt@kms_flip@basic-flip-vs-wf_vblank on byt-nuc dmesg-warn -> pass
Test igt@kms_pipe_crc_basic@read-crc-pipe-c-frame-sequence on bsw-nuc-2 pass -> dmesg-warn
Test igt@kms_pipe_crc_basic@hang-read-crc-pipe-a on ivb-t430s dmesg-warn -> pass
Test igt@gem_mmap@basic on byt-nuc dmesg-warn -> pass
Test igt@pm_rpm@basic-rte on byt-nuc dmesg-warn -> pass (UNSTABLE)
Test igt@gem_mmap_gtt@basic-write on bsw-nuc-2 dmesg-warn -> pass
Test igt@kms_pipe_crc_basic@read-crc-pipe-a on byt-nuc dmesg-warn -> pass
Test igt@kms_pipe_crc_basic@read-crc-pipe-c on skl-i5k-2 dmesg-warn -> pass
Test igt@kms_flip@basic-flip-vs-modeset on hsw-brixbox dmesg-warn -> pass
Test igt@kms_flip@basic-flip-vs-modeset on skl-i5k-2 pass -> dmesg-warn
Test igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence on snb-x220t pass -> fail

bsw-nuc-2        total:135  pass:114  dwarn:1   dfail:0   fail:0   skip:20 
byt-nuc          total:135  pass:122  dwarn:0   dfail:0   fail:0   skip:13 
hsw-brixbox      total:135  pass:127  dwarn:1   dfail:0   fail:0   skip:7  
hsw-gt2          total:135  pass:130  dwarn:1   dfail:0   fail:0   skip:4  
ilk-hp8440p      total:135  pass:100  dwarn:0   dfail:0   fail:2   skip:33 
ivb-t430s        total:135  pass:128  dwarn:1   dfail:1   fail:1   skip:4  
skl-i5k-2        total:135  pass:122  dwarn:5   dfail:0   fail:0   skip:8  
skl-i7k-2        total:135  pass:123  dwarn:4   dfail:0   fail:0   skip:8  
snb-dellxps      total:135  pass:121  dwarn:2   dfail:0   fail:0   skip:12 
snb-x220t        total:135  pass:120  dwarn:2   dfail:0   fail:2   skip:11 

Results at /archive/results/CI_IGT_test/Patchwork_714/

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

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

* ✗ failure: Fi.CI.BAT
  2015-12-18 10:14 [PATCH] drm/i915/vlv: Modifying RC6 Promotion timer for Media workloads Namrta Salonie
@ 2015-12-18 10:30 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2015-12-18 10:30 UTC (permalink / raw)
  To: Namrta Salonie; +Cc: intel-gfx

== Summary ==

HEAD is now at 3c71db8 drm-intel-nightly: 2015y-12m-18d-09h-42m-49s UTC integration manifest
Applying: drm/i915/vlv: Modifying RC6 Promotion timer for Media workloads.
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 drm/i915/vlv: Modifying RC6 Promotion timer for Media workloads.

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

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

* ✗ failure: Fi.CI.BAT
  2015-12-18  6:27 [PATCH] drm/i915: edp resume/On time optimization abhay.kumar
@ 2015-12-18  9:01 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2015-12-18  9:01 UTC (permalink / raw)
  To: abhay.kumar; +Cc: intel-gfx

== Summary ==

HEAD is now at ac2305b drm-intel-nightly: 2015y-12m-17d-16h-19m-23s UTC integration manifest
Applying: drm/i915: edp resume/On time optimization.
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 drm/i915: edp resume/On time optimization.

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

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

* ✗ failure: Fi.CI.BAT
  2015-12-18  1:16 [PATCH] drm/i915: HWSTAM is not a thing on SKL+ Ben Widawsky
@ 2015-12-18  8:30 ` Patchwork
  0 siblings, 0 replies; 118+ messages in thread
From: Patchwork @ 2015-12-18  8:30 UTC (permalink / raw)
  To: Ben Widawsky; +Cc: intel-gfx

== Summary ==

HEAD is now at ac2305b drm-intel-nightly: 2015y-12m-17d-16h-19m-23s UTC integration manifest
Applying: drm/i915: HWSTAM is not a thing on SKL+
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 drm/i915: HWSTAM is not a thing on SKL+

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

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

end of thread, other threads:[~2016-01-19 22:02 UTC | newest]

Thread overview: 118+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-14  6:16 [PATCH v14 0/11] Support for creating/using Stolen memory backed objects ankitprasad.r.sharma
2016-01-14  6:16 ` [PATCH 01/11] drm/i915: Add support for mapping an object page by page ankitprasad.r.sharma
2016-01-14 10:32   ` Tvrtko Ursulin
2016-01-14 13:34     ` Chris Wilson
2016-01-15  9:53       ` Tvrtko Ursulin
2016-01-15 11:44         ` Chris Wilson
2016-01-15 15:15           ` Tvrtko Ursulin
2016-01-14  6:16 ` [PATCH 02/11] drm/i915: Introduce i915_gem_object_get_dma_address() ankitprasad.r.sharma
2016-01-14  6:16 ` [PATCH 03/11] drm/i915: Use insert_page for pwrite_fast ankitprasad.r.sharma
2016-01-14  9:46   ` Chris Wilson
2016-01-14  6:16 ` [PATCH 04/11] drm/i915: Clearing buffer objects via CPU/GTT ankitprasad.r.sharma
2016-01-14 10:06   ` Chris Wilson
2016-01-14  6:16 ` [PATCH 05/11] drm/i915: Support for creating Stolen memory backed objects ankitprasad.r.sharma
2016-01-14 10:24   ` Chris Wilson
2016-01-14 10:46     ` Tvrtko Ursulin
2016-01-14 11:14       ` Chris Wilson
2016-01-14 11:27         ` Tvrtko Ursulin
2016-01-14 11:57           ` Chris Wilson
2016-01-14  6:16 ` [PATCH 06/11] drm/i915: Propagating correct error codes to the userspace ankitprasad.r.sharma
2016-01-14 10:25   ` Chris Wilson
2016-01-14  6:16 ` [PATCH 07/11] drm/i915: Add support for stealing purgable stolen pages ankitprasad.r.sharma
2016-01-14  6:16 ` [PATCH 08/11] drm/i915: Support for pread/pwrite from/to non shmem backed objects ankitprasad.r.sharma
2016-01-14 10:51   ` Chris Wilson
2016-01-14  6:16 ` [PATCH 09/11] drm/i915: Migrate stolen objects before hibernation ankitprasad.r.sharma
2016-01-14 10:53   ` Chris Wilson
2016-01-14  6:16 ` [PATCH 10/11] acpi: Export acpi_bus_type ankitprasad.r.sharma
2016-01-14  6:16   ` ankitprasad.r.sharma
2016-01-15 14:51   ` Rafael J. Wysocki
2016-01-18  9:01     ` Ankitprasad Sharma
2016-01-18  9:01       ` Ankitprasad Sharma
2016-01-18 14:57       ` Rafael J. Wysocki
2016-01-18 18:26         ` Lukas Wunner
2016-01-19  8:15           ` Ankitprasad Sharma
2016-01-18 22:28         ` Rafael J. Wysocki
2016-01-18 22:39           ` Lukas Wunner
2016-01-18 22:46             ` Rafael J. Wysocki
2016-01-18 23:00               ` Lukas Wunner
2016-01-18 23:00                 ` Lukas Wunner
2016-01-18 23:59                 ` Rafael J. Wysocki
2016-01-19 16:31                   ` Lukas Wunner
2016-01-19 22:03                     ` Rafael J. Wysocki
2016-01-14  6:16 ` [PATCH 11/11] drm/i915: Disable use of stolen area by User when Intel RST is present ankitprasad.r.sharma
2016-01-14  6:16   ` ankitprasad.r.sharma
2016-01-14 11:20 ` ✗ failure: Fi.CI.BAT Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2016-01-14 15:56 [PATCH v5 1/1] drm/i915/bxt: Check BIOS RC6 setup before enabling RC6 Sagar Arun Kamble
2016-01-14 16:30 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-14 15:12 [PATCH] drm/i915/bios: Fix the sequence size calculations for MIPI seq v3 Jani Nikula
2016-01-14 16:20 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-14 15:02 [PATCH] drm/i915: Decouple execbuf uAPI from internal implementation Tvrtko Ursulin
2016-01-14 15:49 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-14 13:22 [PATCH 0/8] drm/i915: Some more fb offsets[] prep stuff ville.syrjala
2016-01-14 14:49 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-14 15:00   ` Ville Syrjälä
2016-01-15 12:03     ` Chris Wilson
2016-01-14 12:53 [PATCH 1/2] drm/i915: Start WM computation from scratch on ILK-BDW ville.syrjala
2016-01-14 14:20 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-14 14:29   ` Ville Syrjälä
2016-01-19 13:58     ` Daniel Vetter
2016-01-19 14:09       ` Ville Syrjälä
2016-01-19 16:43         ` Daniel Vetter
2016-01-14 10:49 [PATCH] drm/i915: Clear pending reset requests during suspend Arun Siluvery
2016-01-14 12:20 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-13 17:28 [PATCH 00/20] TDR/watchdog support for gen8 Arun Siluvery
2016-01-14  8:30 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-13 16:19 [PATCH v10] drm/i915: Extend LRC pinning to cover GPU context writeback Nick Hoath
2016-01-14  7:20 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-14 11:31   ` Nick Hoath
2016-01-19  9:08     ` Daniel Vetter
2016-01-13 14:35 [PATCH] drm/i915/dp: fall back to 18 bpp when sink capability is unknown Jani Nikula
2016-01-13 15:13 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-13 16:17   ` Daniel Vetter
2016-01-13 18:03     ` Chris Wilson
2016-01-13 12:52 [PATCH] drm/i915: Fix for reserved space WARN_ON when ring begin fails John.C.Harrison
2016-01-13 13:49 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-12 15:28 [PATCH 1/1] drm/i915: Reorder shadow registers on gen8 for faster lookup Mika Kuoppala
2016-01-12 16:20 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-11 21:40 [PATCH 00/22] drm_event cleanup, round 2 Daniel Vetter
2016-01-12  8:30 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-11 12:27 [PATCH v2 0/9] Kill off intel_crtc->atomic! Maarten Lankhorst
2016-01-11 12:49 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-11 14:30 ` Patchwork
2016-01-08 21:40 [PATCH] drm/i915: Reject invalid-pad for context-destroy ioctl Chris Wilson
2016-01-11 11:07 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-08 20:36 [PATCH 00/21] drm_event cleanup Daniel Vetter
2016-01-11 11:20 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-12 16:24   ` Daniel Vetter
2016-01-08 16:58 [PATCH 1/2] drm/i915: Store edram capabilities instead of fixed size Mika Kuoppala
2016-01-11 10:27 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-08 13:51 [PATCH 1/2] drm/i915: Enable mmio_debug for vlv/chv Mika Kuoppala
2016-01-11  9:59 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-11 12:50   ` Mika Kuoppala
2016-01-12 16:22     ` Daniel Vetter
2016-01-13  9:16       ` Mika Kuoppala
2016-01-13  9:20       ` Mika Kuoppala
2016-01-13  9:39         ` Daniel Vetter
2016-01-13  9:39           ` Daniel Vetter
2016-01-08 11:29 [PATCH v2 00/13] Misc cleanups and locking fixes Tvrtko Ursulin
2016-01-11  9:44 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-07 10:54 [PATCH 0/7] Explicitly pass crtc_state and plane_state to plane update functions Maarten Lankhorst
2016-01-11  8:53 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-07  9:10 [PATCH] drm/i915: Init power domains early in driver load Daniel Vetter
2016-01-11  9:12 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-06 20:53 [PATCH] drm/i915/guc: Fix a memory leak where guc->execbuf_client is not freed yu.dai
2016-01-13  8:49 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-06 11:09 [PATCH 1/3] drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off) Chris Wilson
2016-01-06 13:20 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-06  2:26 [PATCH 1/2] drm/i915: fix get digital port issue in intel_audio libin.yang
2016-01-06 12:49 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-05 19:18 [PATCH] drm/i915: Cleaning up DDI translation tables Rodrigo Vivi
2016-01-06 11:30 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-05 19:10 [PATCH] drm/i915/guc: Enable GuC submission, where supported yu.dai
2016-01-06 10:20 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-07 10:27   ` Dave Gordon
2016-01-07 13:06     ` Jani Nikula
2016-01-07 14:36       ` Daniel Vetter
2016-01-07 14:51         ` Jani Nikula
2016-01-07 15:37         ` Dave Gordon
2016-01-05 16:54 [PATCH] drm/i915: Tune down rpm wakelock debug checks Daniel Vetter
2016-01-06  7:49 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-04 10:13 [PATCH] drm/i915: Force clean compilation with -Werror Chris Wilson
2016-01-04 11:01 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-04 10:10 [PATCH 1/3] drm: Balance error path for GEM handle allocation Chris Wilson
2016-01-04 10:49 ` ✗ failure: Fi.CI.BAT Patchwork
2015-12-31 12:45 [PATCH] drm/i915: Add RPM references in the *_get_hw_state functions Gabriel Feceoru
2015-12-31 13:20 ` ✗ failure: Fi.CI.BAT Patchwork
2015-12-30 22:56 [PATCH] drm/i915/bxt: Fix eDP panel power save/restore Matt Roper
2015-12-31  7:43 ` ✗ failure: Fi.CI.BAT Patchwork
2015-12-23  8:11 [PATCH] drm/i915: increase the tries for HDMI hotplug live status checking Gary Wang
2015-12-23  8:49 ` ✗ failure: Fi.CI.BAT Patchwork
2015-12-21 18:53 [PATCH] drm, i915: Fix pointer size cast Borislav Petkov
2015-12-22  7:30 ` ✗ failure: Fi.CI.BAT Patchwork
2015-12-21 16:04 improve handling of the driver's internal default context Dave Gordon
2015-12-22  7:20 ` ✗ failure: Fi.CI.BAT Patchwork
2015-12-21 15:33 [RFC v2] drm/i915/bdw+: Do not emit user interrupts when not needed Tvrtko Ursulin
2015-12-21 17:30 ` ✗ failure: Fi.CI.BAT Patchwork
2015-12-21 13:10 [PATCH 00/15] drm/i915/bios: mipi sequence block v3, etc Jani Nikula
2016-01-05 16:01 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-11 13:30 ` Patchwork
2016-01-11 14:01 ` Patchwork
2015-12-18 20:00 [PATCH v2 0/5] Add GuC ADS (Addition Data Structure) yu.dai
2016-01-05 12:30 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-06  9:01 ` Patchwork
2015-12-18 19:55 [PATCH] drm/i915: edp resume/On time optimization abhay.kumar
2015-12-19  7:30 ` ✗ failure: Fi.CI.BAT Patchwork
2015-12-18 17:24 [PATCH] drm/i915: Workaround CHV pipe C cursor fail ville.syrjala
2015-12-18 17:49 ` ✗ failure: Fi.CI.BAT Patchwork
2015-12-18 15:17 [PATCH] Allow userspace to set NULL blob on properties Lionel Landwerlin
2015-12-18 15:30 ` ✗ failure: Fi.CI.BAT Patchwork
2015-12-18 14:41 [PATCH v9] drm/i915: Extend LRC pinning to cover GPU context writeback Nick Hoath
2015-12-18 15:01 ` ✗ failure: Fi.CI.BAT Patchwork
2015-12-21 13:44   ` Daniel Vetter
2015-12-18 11:59 [RFC] drm/i915/bdw+: Do not emit user interrupts when not needed Tvrtko Ursulin
2015-12-18 12:30 ` ✗ failure: Fi.CI.BAT Patchwork
2015-12-18 10:53 [PATCH] drm/i915/bdw+: Replace list_del+list_add_tail with list_move_tail Tvrtko Ursulin
2015-12-18 11:49 ` ✗ failure: Fi.CI.BAT Patchwork
2015-12-18 10:14 [PATCH] drm/i915/vlv: Modifying RC6 Promotion timer for Media workloads Namrta Salonie
2015-12-18 10:30 ` ✗ failure: Fi.CI.BAT Patchwork
2015-12-18  6:27 [PATCH] drm/i915: edp resume/On time optimization abhay.kumar
2015-12-18  9:01 ` ✗ failure: Fi.CI.BAT Patchwork
2015-12-18  1:16 [PATCH] drm/i915: HWSTAM is not a thing on SKL+ Ben Widawsky
2015-12-18  8:30 ` ✗ failure: Fi.CI.BAT Patchwork
2015-12-14 16:23 [PATCH 00/10] drm/i915: Fixes from my attempt at running igt on gen2 ville.syrjala
2016-01-12  7:49 ` ✗ failure: Fi.CI.BAT Patchwork
2015-12-04 11:33 [PATCH] drm/i915: Avoid writing relocs with addresses in non-canonical form Michał Winiarski
2015-12-29 16:20 ` ✗ failure: Fi.CI.BAT 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.