date:20190227

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Remove second level open-coded rcu work

2019-02-27 Thread Tvrtko Ursulin



On 27/02/2019 23:09, Chris Wilson wrote:

We currently use a worker queued from an rcu callback to determine when
a how grace period has elapsed while we remained idle. We use this idle
delay to infer that we will be idle for a while and this is a suitable
point at which we can trim our global memory caches.

Since we wrote that, this mechanism now exists as rcu_work, and having
converted the idle shrinkers over to using that, we can remove our own
variant.


By the look of it gt.epoch can be completely ripped out.

Regards,

Tvrtko


Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_gem.c | 91 +
  1 file changed, 12 insertions(+), 79 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8ded7e1756c9..8cf3429594d5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -101,7 +101,7 @@ static void i915_gem_info_remove_obj(struct 
drm_i915_private *dev_priv,
spin_unlock(_priv->mm.object_stat_lock);
  }
  
-static u32 __i915_gem_park(struct drm_i915_private *i915)

+static void __i915_gem_park(struct drm_i915_private *i915)
  {
intel_wakeref_t wakeref;
  
@@ -112,7 +112,7 @@ static u32 __i915_gem_park(struct drm_i915_private *i915)

GEM_BUG_ON(!list_empty(>gt.active_rings));
  
  	if (!i915->gt.awake)

-   return I915_EPOCH_INVALID;
+   return;
  
  	GEM_BUG_ON(i915->gt.epoch == I915_EPOCH_INVALID);
  
@@ -143,7 +143,15 @@ static u32 __i915_gem_park(struct drm_i915_private *i915)
  
  	intel_display_power_put(i915, POWER_DOMAIN_GT_IRQ, wakeref);
  
-	return i915->gt.epoch;

+   /*
+* When we are idle, it is an opportune time to reap our caches.
+* However, we have many objects that utilise RCU and the ordered
+* i915->wq that this work is executing on. To try and flush any
+* pending frees now we are idle, we first wait for an RCU grace
+* period, and then queue a task (that will run last on the wq) to
+* shrink and re-optimize the caches.
+*/
+   i915_globals_park();
  }
  
  void i915_gem_park(struct drm_i915_private *i915)

@@ -2877,62 +2885,6 @@ i915_gem_retire_work_handler(struct work_struct *work)
   round_jiffies_up_relative(HZ));
  }
  
-static void shrink_caches(struct drm_i915_private *i915)

-{
-   /*
-* kmem_cache_shrink() discards empty slabs and reorders partially
-* filled slabs to prioritise allocating from the mostly full slabs,
-* with the aim of reducing fragmentation.
-*/
-   i915_globals_park();
-}
-
-struct sleep_rcu_work {
-   union {
-   struct rcu_head rcu;
-   struct work_struct work;
-   };
-   struct drm_i915_private *i915;
-   unsigned int epoch;
-};
-
-static inline bool
-same_epoch(struct drm_i915_private *i915, unsigned int epoch)
-{
-   /*
-* There is a small chance that the epoch wrapped since we started
-* sleeping. If we assume that epoch is at least a u32, then it will
-* take at least 2^32 * 100ms for it to wrap, or about 326 years.
-*/
-   return epoch == READ_ONCE(i915->gt.epoch);
-}
-
-static void __sleep_work(struct work_struct *work)
-{
-   struct sleep_rcu_work *s = container_of(work, typeof(*s), work);
-   struct drm_i915_private *i915 = s->i915;
-   unsigned int epoch = s->epoch;
-
-   kfree(s);
-   if (same_epoch(i915, epoch))
-   shrink_caches(i915);
-}
-
-static void __sleep_rcu(struct rcu_head *rcu)
-{
-   struct sleep_rcu_work *s = container_of(rcu, typeof(*s), rcu);
-   struct drm_i915_private *i915 = s->i915;
-
-   destroy_rcu_head(>rcu);
-
-   if (same_epoch(i915, s->epoch)) {
-   INIT_WORK(>work, __sleep_work);
-   queue_work(i915->wq, >work);
-   } else {
-   kfree(s);
-   }
-}
-
  static inline bool
  new_requests_since_last_retire(const struct drm_i915_private *i915)
  {
@@ -2961,7 +2913,6 @@ i915_gem_idle_work_handler(struct work_struct *work)
  {
struct drm_i915_private *dev_priv =
container_of(work, typeof(*dev_priv), gt.idle_work.work);
-   unsigned int epoch = I915_EPOCH_INVALID;
bool rearm_hangcheck;
  
  	if (!READ_ONCE(dev_priv->gt.awake))

@@ -3016,7 +2967,7 @@ i915_gem_idle_work_handler(struct work_struct *work)
if (new_requests_since_last_retire(dev_priv))
goto out_unlock;
  
-	epoch = __i915_gem_park(dev_priv);

+   __i915_gem_park(dev_priv);
  
  	assert_kernel_context_is_current(dev_priv);
  
@@ -3029,24 +2980,6 @@ i915_gem_idle_work_handler(struct work_struct *work)

GEM_BUG_ON(!dev_priv->gt.awake);
i915_queue_hangcheck(dev_priv);
}
-
-   /*
-* When we are idle, it is an opportune time to reap our caches.
-* However, we have many objects that

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Make object/vma allocation caches global

2019-02-27 Thread Tvrtko Ursulin



On 27/02/2019 23:09, Chris Wilson wrote:

As our allocations are not device specific, we can move our slab caches
to a global scope.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/gvt/dmabuf.c |  2 +-
  drivers/gpu/drm/i915/i915_drv.h   |  6 ---
  drivers/gpu/drm/i915/i915_gem.c   | 47 ++-
  drivers/gpu/drm/i915/i915_gem_context.c   | 35 +-
  drivers/gpu/drm/i915/i915_gem_context.h   |  8 
  drivers/gpu/drm/i915/i915_gem_dmabuf.c|  2 +-
  drivers/gpu/drm/i915/i915_gem_execbuffer.c|  4 +-
  drivers/gpu/drm/i915/i915_gem_gtt.c   |  2 +-
  drivers/gpu/drm/i915/i915_gem_internal.c  |  2 +-
  drivers/gpu/drm/i915/i915_gem_object.c| 34 ++
  drivers/gpu/drm/i915/i915_gem_object.h|  8 +++-
  drivers/gpu/drm/i915/i915_gem_stolen.c|  2 +-
  drivers/gpu/drm/i915/i915_gem_userptr.c   |  2 +-
  drivers/gpu/drm/i915/i915_globals.c   | 29 +++-
  drivers/gpu/drm/i915/i915_vma.c   | 43 ++---
  drivers/gpu/drm/i915/i915_vma.h   |  7 +++
  .../gpu/drm/i915/selftests/huge_gem_object.c  |  2 +-
  drivers/gpu/drm/i915/selftests/huge_pages.c   |  4 +-
  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |  2 +-
  .../gpu/drm/i915/selftests/mock_gem_device.c  | 15 --
  20 files changed, 170 insertions(+), 86 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c 
b/drivers/gpu/drm/i915/gvt/dmabuf.c
index 3e7e2b80c857..f27edf17b4ab 100644
--- a/drivers/gpu/drm/i915/gvt/dmabuf.c
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
@@ -153,7 +153,7 @@ static struct drm_i915_gem_object *vgpu_create_gem(struct 
drm_device *dev,
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_i915_gem_object *obj;
  
-	obj = i915_gem_object_alloc(dev_priv);

+   obj = i915_gem_object_alloc();
if (obj == NULL)
return NULL;
  
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h

index f16016b330b3..35516089a3ff 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1470,10 +1470,6 @@ struct intel_cdclk_state {
  struct drm_i915_private {
struct drm_device drm;
  
-	struct kmem_cache *objects;

-   struct kmem_cache *vmas;
-   struct kmem_cache *luts;
-
const struct intel_device_info __info; /* Use INTEL_INFO() to access. */
struct intel_runtime_info __runtime; /* Use RUNTIME_INFO() to access. */
struct intel_driver_caps caps;
@@ -2802,8 +2798,6 @@ void i915_gem_load_init_fences(struct drm_i915_private 
*dev_priv);
  int i915_gem_freeze(struct drm_i915_private *dev_priv);
  int i915_gem_freeze_late(struct drm_i915_private *dev_priv);
  
-void *i915_gem_object_alloc(struct drm_i915_private *dev_priv);

-void i915_gem_object_free(struct drm_i915_gem_object *obj);
  void i915_gem_object_init(struct drm_i915_gem_object *obj,
 const struct drm_i915_gem_object_ops *ops);
  struct drm_i915_gem_object *
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 713ed6fbdcc8..8ded7e1756c9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -624,17 +624,6 @@ i915_gem_phys_pwrite(struct drm_i915_gem_object *obj,
return 0;
  }
  
-void *i915_gem_object_alloc(struct drm_i915_private *dev_priv)

-{
-   return kmem_cache_zalloc(dev_priv->objects, GFP_KERNEL);
-}
-
-void i915_gem_object_free(struct drm_i915_gem_object *obj)
-{
-   struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
-   kmem_cache_free(dev_priv->objects, obj);
-}
-
  static int
  i915_gem_create(struct drm_file *file,
struct drm_i915_private *dev_priv,
@@ -2895,10 +2884,6 @@ static void shrink_caches(struct drm_i915_private *i915)
 * filled slabs to prioritise allocating from the mostly full slabs,
 * with the aim of reducing fragmentation.
 */
-   kmem_cache_shrink(i915->luts);
-   kmem_cache_shrink(i915->vmas);
-   kmem_cache_shrink(i915->objects);
-
i915_globals_park();
  }
  
@@ -3094,7 +3079,7 @@ void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file)

list_del(>obj_link);
list_del(>ctx_link);
  
-		kmem_cache_free(i915->luts, lut);

+   i915_lut_handle_free(lut);
__i915_gem_object_release_unless_active(obj);
}
  
@@ -4199,7 +4184,7 @@ i915_gem_object_create(struct drm_i915_private *dev_priv, u64 size)

if (overflows_type(size, obj->base.size))
return ERR_PTR(-E2BIG);
  
-	obj = i915_gem_object_alloc(dev_priv);

+   obj = i915_gem_object_alloc();
if (obj == NULL)
return ERR_PTR(-ENOMEM);
  
@@ -5223,19 +5208,7 @@ static void i915_gem_init__mm(struct drm_i915_private *i915)
  
  int i915_gem_init_early(struct drm_i915_private *dev_priv)

  {
-

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Make request allocation caches global

2019-02-27 Thread Tvrtko Ursulin



On 27/02/2019 23:09, Chris Wilson wrote:

As kmem_caches share the same properties (size, allocation/free behaviour)
for all potential devices, we can use global caches. While this
potential has worse fragmentation behaviour (one can argue that
different devices would have different activity lifetimes, but you can
also argue that activity is temporal across the system) it is the
default behaviour of the system at large to amalgamate matching caches.

The benefit for us is much reduced pointer dancing along the frequent
allocation paths.

v2: Defer shrinking until after a global grace period for futureproofing
multiple consumers of the slab caches, similar to the current strategy
for avoiding shrinking too early.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/Makefile |   1 +
  drivers/gpu/drm/i915/i915_active.c|   7 +-
  drivers/gpu/drm/i915/i915_active.h|   1 +
  drivers/gpu/drm/i915/i915_drv.h   |   3 -
  drivers/gpu/drm/i915/i915_gem.c   |  34 +-
  drivers/gpu/drm/i915/i915_globals.c   | 113 ++
  drivers/gpu/drm/i915/i915_globals.h   |  15 +++
  drivers/gpu/drm/i915/i915_pci.c   |   8 +-
  drivers/gpu/drm/i915/i915_request.c   |  53 ++--
  drivers/gpu/drm/i915/i915_request.h   |  10 ++
  drivers/gpu/drm/i915/i915_scheduler.c |  66 +++---
  drivers/gpu/drm/i915/i915_scheduler.h |  34 +-
  drivers/gpu/drm/i915/intel_guc_submission.c   |   3 +-
  drivers/gpu/drm/i915/intel_lrc.c  |   6 +-
  drivers/gpu/drm/i915/intel_ringbuffer.h   |  17 ---
  drivers/gpu/drm/i915/selftests/mock_engine.c  |  45 ---
  .../gpu/drm/i915/selftests/mock_gem_device.c  |  26 
  drivers/gpu/drm/i915/selftests/mock_request.c |  12 +-
  drivers/gpu/drm/i915/selftests/mock_request.h |   7 --
  19 files changed, 312 insertions(+), 149 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/i915_globals.c
  create mode 100644 drivers/gpu/drm/i915/i915_globals.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 1787e1299b1b..a1d834068765 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -77,6 +77,7 @@ i915-y += \
  i915_gem_tiling.o \
  i915_gem_userptr.o \
  i915_gemfs.o \
+ i915_globals.o \
  i915_query.o \
  i915_request.o \
  i915_scheduler.o \
diff --git a/drivers/gpu/drm/i915/i915_active.c 
b/drivers/gpu/drm/i915/i915_active.c
index db7bb5bd5add..d9f6471ac16c 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -294,7 +294,12 @@ int __init i915_global_active_init(void)
return 0;
  }
  
-void __exit i915_global_active_exit(void)

+void i915_global_active_shrink(void)
+{
+   kmem_cache_shrink(global.slab_cache);
+}
+
+void i915_global_active_exit(void)
  {
kmem_cache_destroy(global.slab_cache);
  }
diff --git a/drivers/gpu/drm/i915/i915_active.h 
b/drivers/gpu/drm/i915/i915_active.h
index 12b5c1d287d1..5fbd9102384b 100644
--- a/drivers/gpu/drm/i915/i915_active.h
+++ b/drivers/gpu/drm/i915/i915_active.h
@@ -420,6 +420,7 @@ static inline void i915_active_fini(struct i915_active 
*ref) { }
  #endif
  
  int i915_global_active_init(void);

+void i915_global_active_shrink(void);
  void i915_global_active_exit(void);
  
  #endif /* _I915_ACTIVE_H_ */

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cc09caf3870e..f16016b330b3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1473,9 +1473,6 @@ struct drm_i915_private {
struct kmem_cache *objects;
struct kmem_cache *vmas;
struct kmem_cache *luts;
-   struct kmem_cache *requests;
-   struct kmem_cache *dependencies;
-   struct kmem_cache *priorities;
  
  	const struct intel_device_info __info; /* Use INTEL_INFO() to access. */

struct intel_runtime_info __runtime; /* Use RUNTIME_INFO() to access. */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2b261524cfa4..713ed6fbdcc8 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -42,6 +42,7 @@
  #include "i915_drv.h"
  #include "i915_gem_clflush.h"
  #include "i915_gemfs.h"
+#include "i915_globals.h"
  #include "i915_reset.h"
  #include "i915_trace.h"
  #include "i915_vgpu.h"
@@ -187,6 +188,8 @@ void i915_gem_unpark(struct drm_i915_private *i915)
if (unlikely(++i915->gt.epoch == 0)) /* keep 0 as invalid */
i915->gt.epoch = 1;
  
+	i915_globals_unpark();

+
intel_enable_gt_powersave(i915);
i915_update_gfx_val(i915);
if (INTEL_GEN(i915) >= 6)
@@ -2892,12 +2895,11 @@ static void shrink_caches(struct drm_i915_private *i915)
 * filled slabs to prioritise allocating from the mostly full slabs,
 * with the aim of reducing fragmentation.

Re: [Intel-gfx] [PATCH 07/11] drm/i915: Compute the global scheduler caps

2019-02-27 Thread Tvrtko Ursulin



On 26/02/2019 10:24, Chris Wilson wrote:

Do a pass over all the engines upon starting to determine the global
scheduler capability flags (those that are agreed upon by all).

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_gem.c |  2 ++
  drivers/gpu/drm/i915/intel_engine_cs.c  | 39 +
  drivers/gpu/drm/i915/intel_lrc.c|  6 
  drivers/gpu/drm/i915/intel_ringbuffer.h |  2 ++
  4 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 713ed6fbdcc8..f6fe10fce0ec 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4700,6 +4700,8 @@ static int __i915_gem_restart_engines(void *data)
}
}
  
+	intel_engines_set_scheduler_caps(i915);

+
return 0;
  }
  
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c

index b7b626195eda..ef49b1b0537b 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -608,6 +608,45 @@ int intel_engine_setup_common(struct intel_engine_cs 
*engine)
return err;
  }
  
+void intel_engines_set_scheduler_caps(struct drm_i915_private *i915)

+{
+   static const struct {
+   u8 engine;
+   u8 sched;
+   } map[] = {
+#define MAP(x, y) { ilog2(I915_ENGINE_HAS_##x), ilog2(I915_SCHEDULER_CAP_##y) }
+   MAP(PREEMPTION, PREEMPTION),
+#undef MAP
+   };
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+   u32 enabled, disabled;
+
+   enabled = 0;
+   disabled = 0;
+   for_each_engine(engine, i915, id) { /* all engines must agree! */
+   int i;
+
+   if (engine->schedule)
+   enabled |= (I915_SCHEDULER_CAP_ENABLED |
+   I915_SCHEDULER_CAP_PRIORITY);
+   else
+   disabled |= (I915_SCHEDULER_CAP_ENABLED |
+I915_SCHEDULER_CAP_PRIORITY);
+
+   for (i = 0; i < ARRAY_SIZE(map); i++) {
+   if (engine->flags & BIT(map[i].engine))
+   enabled |= BIT(map[i].sched);
+   else
+   disabled |= BIT(map[i].sched);
+   }
+   }
+
+   i915->caps.scheduler = enabled & ~disabled;
+   if (!(i915->caps.scheduler & I915_SCHEDULER_CAP_ENABLED))
+   i915->caps.scheduler = 0;
+}
+
  static void __intel_context_unpin(struct i915_gem_context *ctx,
  struct intel_engine_cs *engine)
  {
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 29b2a2f34edb..f57cfe2fc078 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2327,12 +2327,6 @@ void intel_execlists_set_default_submission(struct 
intel_engine_cs *engine)
engine->flags |= I915_ENGINE_SUPPORTS_STATS;
if (engine->i915->preempt_context)
engine->flags |= I915_ENGINE_HAS_PREEMPTION;
-
-   engine->i915->caps.scheduler =
-   I915_SCHEDULER_CAP_ENABLED |
-   I915_SCHEDULER_CAP_PRIORITY;
-   if (intel_engine_has_preemption(engine))
-   engine->i915->caps.scheduler |= I915_SCHEDULER_CAP_PREEMPTION;
  }
  
  static void

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 5284f243931a..b8ec7e40a59b 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -576,6 +576,8 @@ intel_engine_has_preemption(const struct intel_engine_cs 
*engine)
return engine->flags & I915_ENGINE_HAS_PREEMPTION;
  }
  
+void intel_engines_set_scheduler_caps(struct drm_i915_private *i915);

+
  static inline bool __execlists_need_preempt(int prio, int last)
  {
/*



Reviewed-by: Tvrtko Ursulin 

Regards,

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

Re: [Intel-gfx] [PATCH 05/11] drm/i915: Introduce i915_timeline.mutex

2019-02-27 Thread Tvrtko Ursulin



On 26/02/2019 10:23, Chris Wilson wrote:

A simple mutex used for guarding the flow of requests in and out of the
timeline. In the short-term, it will be used only to guard the addition
of requests into the timeline, taken on alloc and released on commit so
that only one caller can construct a request into the timeline
(important as the seqno and ring pointers must be serialised). This will
be used by observers to ensure that the seqno/hwsp is stable. Later,
when we have reduced retiring to only operate on a single timeline at a
time, we can then use the mutex as the sole guard required for retiring.


At which point does this gets used? In media scalability patches or later?

Regards,

Tvrtko



Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_request.c| 6 +-
  drivers/gpu/drm/i915/i915_timeline.c   | 1 +
  drivers/gpu/drm/i915/i915_timeline.h   | 2 ++
  drivers/gpu/drm/i915/selftests/i915_request.c  | 4 +---
  drivers/gpu/drm/i915/selftests/mock_timeline.c | 1 +
  5 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index c65f6c990fdd..719d1a5ab082 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -563,6 +563,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct 
i915_gem_context *ctx)
return ERR_CAST(ce);
  
  	reserve_gt(i915);

+   mutex_lock(>ring->timeline->mutex);
  
  	/* Move our oldest request to the slab-cache (if not in use!) */

rq = list_first_entry(>ring->request_list, typeof(*rq), ring_link);
@@ -688,6 +689,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct 
i915_gem_context *ctx)
  
  	kmem_cache_free(global.slab_requests, rq);

  err_unreserve:
+   mutex_unlock(>ring->timeline->mutex);
unreserve_gt(i915);
intel_context_unpin(ce);
return ERR_PTR(ret);
@@ -880,7 +882,7 @@ void i915_request_add(struct i915_request *request)
GEM_TRACE("%s fence %llx:%lld\n",
  engine->name, request->fence.context, request->fence.seqno);
  
-	lockdep_assert_held(>i915->drm.struct_mutex);

+   lockdep_assert_held(>timeline->mutex);
trace_i915_request_add(request);
  
  	/*

@@ -991,6 +993,8 @@ void i915_request_add(struct i915_request *request)
 */
if (prev && i915_request_completed(prev))
i915_request_retire_upto(prev);
+
+   mutex_unlock(>timeline->mutex);
  }
  
  static unsigned long local_clock_us(unsigned int *cpu)

diff --git a/drivers/gpu/drm/i915/i915_timeline.c 
b/drivers/gpu/drm/i915/i915_timeline.c
index b2202d2e58a2..87a80558da28 100644
--- a/drivers/gpu/drm/i915/i915_timeline.c
+++ b/drivers/gpu/drm/i915/i915_timeline.c
@@ -162,6 +162,7 @@ int i915_timeline_init(struct drm_i915_private *i915,
timeline->fence_context = dma_fence_context_alloc(1);
  
  	spin_lock_init(>lock);

+   mutex_init(>mutex);
  
  	INIT_ACTIVE_REQUEST(>barrier);

INIT_ACTIVE_REQUEST(>last_request);
diff --git a/drivers/gpu/drm/i915/i915_timeline.h 
b/drivers/gpu/drm/i915/i915_timeline.h
index 7bec7d2e45bf..36c3849f7108 100644
--- a/drivers/gpu/drm/i915/i915_timeline.h
+++ b/drivers/gpu/drm/i915/i915_timeline.h
@@ -44,6 +44,8 @@ struct i915_timeline {
  #define TIMELINE_CLIENT 0 /* default subclass */
  #define TIMELINE_ENGINE 1
  
+	struct mutex mutex; /* protects the flow of requests */

+
unsigned int pin_count;
const u32 *hwsp_seqno;
struct i915_vma *hwsp_ggtt;
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c 
b/drivers/gpu/drm/i915/selftests/i915_request.c
index 7da52e3d67af..7e1b65b8eb19 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -141,14 +141,12 @@ static int igt_fence_wait(void *arg)
err = -ENOMEM;
goto out_locked;
}
-   mutex_unlock(>drm.struct_mutex); /* safe as we are single user */
  
  	if (dma_fence_wait_timeout(>fence, false, T) != -ETIME) {

pr_err("fence wait success before submit (expected 
timeout)!\n");
-   goto out_device;
+   goto out_locked;
}
  
-	mutex_lock(>drm.struct_mutex);

i915_request_add(request);
mutex_unlock(>drm.struct_mutex);
  
diff --git a/drivers/gpu/drm/i915/selftests/mock_timeline.c b/drivers/gpu/drm/i915/selftests/mock_timeline.c

index d2de9ece2118..416d85233263 100644
--- a/drivers/gpu/drm/i915/selftests/mock_timeline.c
+++ b/drivers/gpu/drm/i915/selftests/mock_timeline.c
@@ -14,6 +14,7 @@ void mock_timeline_init(struct i915_timeline *timeline, u64 
context)
timeline->fence_context = context;
  
  	spin_lock_init(>lock);

+   mutex_init(>mutex);
  
  	INIT_ACTIVE_REQUEST(>barrier);

INIT_ACTIVE_REQUEST(>last_request);


___
Intel-gfx mailing list

Re: [Intel-gfx] [PATCH 11/11] drm/i915: Use __ffs() in for_each_priolist for more compact code

2019-02-27 Thread Tvrtko Ursulin



On 26/02/2019 10:24, Chris Wilson wrote:

Gcc has a slight preference if we use __ffs() to subtract one from the
index once rather than each use:

__execlists_submission_tasklet  28672847 -20

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_scheduler.h | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_scheduler.h 
b/drivers/gpu/drm/i915/i915_scheduler.h
index 24c2c027fd2c..068a6750540f 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.h
+++ b/drivers/gpu/drm/i915/i915_scheduler.h
@@ -100,9 +100,11 @@ struct i915_priolist {
list_for_each_entry(it, &(plist)->requests[idx], sched.link)
  
  #define priolist_for_each_request_consume(it, n, plist, idx) \

-   for (; (idx = ffs((plist)->used)); (plist)->used &= ~BIT(idx - 1)) \
+   for (; \
+(plist)->used ? (idx = __ffs((plist)->used)), 1 : 0; \
+(plist)->used &= ~BIT(idx)) \
list_for_each_entry_safe(it, n, \
-&(plist)->requests[idx - 1], \
+&(plist)->requests[idx], \
 sched.link)
  
  void i915_sched_node_init(struct i915_sched_node *node);




Reviewed-by: Tvrtko Ursulin 

Regards,

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v3,1/6] drm/i915/psr: Remove PSR2 FIXME

2019-02-27 Thread Patchwork

== Series Details ==

Series: series starting with [v3,1/6] drm/i915/psr: Remove PSR2 FIXME
URL   : https://patchwork.freedesktop.org/series/57324/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_5668_full -> Patchwork_12324_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_12324_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_12324_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_12324_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_color@pipe-b-ctm-0-75:
- shard-apl:  PASS -> FAIL +9

  * igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-legacy:
- shard-apl:  PASS -> DMESG-FAIL +17

  * igt@kms_flip@2x-flip-vs-suspend-interruptible:
- shard-hsw:  PASS -> DMESG-WARN

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-pgflip-blt:
- shard-kbl:  PASS -> DMESG-FAIL +12

  * igt@kms_pipe_crc_basic@read-crc-pipe-c:
- shard-kbl:  PASS -> FAIL +7

  
 Warnings 

  * igt@kms_cursor_crc@cursor-64x64-sliding:
- shard-apl:  FAIL [fdo#103232] -> DMESG-FAIL

  * igt@kms_plane_alpha_blend@pipe-a-alpha-basic:
- shard-apl:  FAIL [fdo#108145] -> DMESG-FAIL
- shard-kbl:  FAIL [fdo#108145] / [fdo#108590] -> DMESG-FAIL

  
Known issues


  Here are the changes found in Patchwork_12324_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@vcs0-clean:
- shard-iclb: NOTRUN -> SKIP [fdo#109281]

  * igt@gem_exec_big:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] +37

  * igt@gem_exec_parallel@bsd1:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] +94

  * igt@gem_exec_params@no-blt:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] +30

  * igt@gem_mocs_settings@mocs-rc6-vebox:
- shard-iclb: NOTRUN -> SKIP [fdo#109287]

  * igt@gem_mocs_settings@mocs-settings-bsd2:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] / [fdo#109287]

  * igt@gem_pwrite@huge-cpu-forwards:
- shard-iclb: NOTRUN -> SKIP [fdo#109290] +1

  * igt@gen3_render_mixed_blits:
- shard-iclb: NOTRUN -> SKIP [fdo#109289] +1

  * igt@i915_hangman@error-state-capture-bsd2:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] +6

  * igt@i915_pm_lpsp@non-edp:
- shard-iclb: NOTRUN -> SKIP [fdo#109301]

  * igt@i915_pm_rpm@dpms-lpsp:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +4

  * igt@i915_pm_rpm@system-suspend-execbuf:
- shard-skl:  PASS -> INCOMPLETE [fdo#104108] / [fdo#107807]

  * igt@kms_available_modes_crc@available_mode_test_crc:
- shard-skl:  NOTRUN -> FAIL [fdo#106641]

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
- shard-apl:  NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-modeset-hang-oldfb-render-f:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +6

  * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
- shard-kbl:  PASS -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-f:
- shard-hsw:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1

  * igt@kms_ccs@pipe-b-crc-sprite-planes-basic:
- shard-apl:  PASS -> FAIL [fdo#106510]

  * igt@kms_chamelium@vga-frame-dump:
- shard-iclb: NOTRUN -> SKIP [fdo#109284] +1

  * igt@kms_cursor_crc@cursor-256x256-sliding:
- shard-iclb: NOTRUN -> FAIL [fdo#103232] +1

  * igt@kms_cursor_crc@cursor-512x170-random:
- shard-iclb: NOTRUN -> SKIP [fdo#109279] +1

  * igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-skl:  PASS -> INCOMPLETE [fdo#104108] / [fdo#107773]

  * igt@kms_flip@2x-flip-vs-panning-vs-hang-interruptible:
- shard-iclb: NOTRUN -> SKIP [fdo#109274] +1

  * igt@kms_flip@flip-vs-expired-vblank:
- shard-skl:  PASS -> FAIL [fdo#105363]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render:
- shard-iclb: NOTRUN -> FAIL [fdo#103167] +1

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-render:
- shard-kbl:  PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +1

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
- shard-apl:  PASS -> FAIL [fdo#103167]

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-wc:
- shard-glk:  PASS -> FAIL [fdo#103167] +6

  * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite:
- shard-iclb: PASS -> FAIL [fdo#103167] +20

  *

Re: [Intel-gfx] [PATCH v3 3/3] drm/i915: use REG_FIELD_PREP() to define register bitfield values

2019-02-27 Thread kbuild test robot

Hi Jani,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20190227]
[cannot apply to v5.0-rc8]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Jani-Nikula/drm-i915-introduce-macros-to-define-register-contents/20190228-093058
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/i915/intel_display.c:1165:22: sparse: error: Expected 
>> constant expression in case statement
   drivers/gpu/drm/i915/intel_display.c:1168:22: sparse: error: Expected 
constant expression in case statement
   drivers/gpu/drm/i915/intel_display.c:1171:22: sparse: error: Expected 
constant expression in case statement
   drivers/gpu/drm/i915/intel_display.c:1174:22: sparse: error: Expected 
constant expression in case statement

vim +1165 drivers/gpu/drm/i915/intel_display.c

040484af Jesse Barnes   2011-01-03  1147  
4f8036a2 Tvrtko Ursulin 2016-10-13  1148  void assert_panel_unlocked(struct 
drm_i915_private *dev_priv, enum pipe pipe)
ea0760cf Jesse Barnes   2011-01-04  1149  {
f0f59a00 Ville Syrjälä  2015-11-18  1150i915_reg_t pp_reg;
ea0760cf Jesse Barnes   2011-01-04  1151u32 val;
10ed55e4 Ville Syrjälä  2018-05-23  1152enum pipe panel_pipe = 
INVALID_PIPE;
0de3b485 Thomas Jarosch 2011-08-25  1153bool locked = true;
ea0760cf Jesse Barnes   2011-01-04  1154  
4f8036a2 Tvrtko Ursulin 2016-10-13  1155if (WARN_ON(HAS_DDI(dev_priv)))
bedd4dba Jani Nikula2014-08-22  1156return;
bedd4dba Jani Nikula2014-08-22  1157  
4f8036a2 Tvrtko Ursulin 2016-10-13  1158if (HAS_PCH_SPLIT(dev_priv)) {
bedd4dba Jani Nikula2014-08-22  1159u32 port_sel;
bedd4dba Jani Nikula2014-08-22  1160  
44cb734c Imre Deak  2016-08-10  1161pp_reg = PP_CONTROL(0);
44cb734c Imre Deak  2016-08-10  1162port_sel = 
I915_READ(PP_ON_DELAYS(0)) & PANEL_PORT_SELECT_MASK;
bedd4dba Jani Nikula2014-08-22  1163  
4c23dea4 Ville Syrjälä  2018-05-18  1164switch (port_sel) {
4c23dea4 Ville Syrjälä  2018-05-18 @1165case 
PANEL_PORT_SELECT_LVDS:
a44628b9 Ville Syrjälä  2018-05-14  1166
intel_lvds_port_enabled(dev_priv, PCH_LVDS, _pipe);
4c23dea4 Ville Syrjälä  2018-05-18  1167break;
4c23dea4 Ville Syrjälä  2018-05-18  1168case 
PANEL_PORT_SELECT_DPA:
4c23dea4 Ville Syrjälä  2018-05-18  1169
intel_dp_port_enabled(dev_priv, DP_A, PORT_A, _pipe);
4c23dea4 Ville Syrjälä  2018-05-18  1170break;
4c23dea4 Ville Syrjälä  2018-05-18  1171case 
PANEL_PORT_SELECT_DPC:
4c23dea4 Ville Syrjälä  2018-05-18  1172
intel_dp_port_enabled(dev_priv, PCH_DP_C, PORT_C, _pipe);
4c23dea4 Ville Syrjälä  2018-05-18  1173break;
4c23dea4 Ville Syrjälä  2018-05-18  1174case 
PANEL_PORT_SELECT_DPD:
4c23dea4 Ville Syrjälä  2018-05-18  1175
intel_dp_port_enabled(dev_priv, PCH_DP_D, PORT_D, _pipe);
4c23dea4 Ville Syrjälä  2018-05-18  1176break;
4c23dea4 Ville Syrjälä  2018-05-18  1177default:
4c23dea4 Ville Syrjälä  2018-05-18  1178
MISSING_CASE(port_sel);
4c23dea4 Ville Syrjälä  2018-05-18  1179break;
4c23dea4 Ville Syrjälä  2018-05-18  1180}
4f8036a2 Tvrtko Ursulin 2016-10-13  1181} else if 
(IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
bedd4dba Jani Nikula2014-08-22  1182/* presumably write 
lock depends on pipe, not port select */
44cb734c Imre Deak  2016-08-10  1183pp_reg = 
PP_CONTROL(pipe);
bedd4dba Jani Nikula2014-08-22  1184panel_pipe = pipe;
ea0760cf Jesse Barnes   2011-01-04  1185} else {
f0d2b758 Ville Syrjälä  2018-05-18  1186u32 port_sel;
f0d2b758 Ville Syrjälä  2018-05-18  1187  
44cb734c Imre Deak  2016-08-10  1188pp_reg = PP_CONTROL(0);
f0d2b758 Ville Syrjälä  2018-05-18  1189port_sel = 
I915_READ(PP_ON_DELAYS(0)) & PANEL_PORT_SELECT_MASK;
f0d2b758 Ville Syrjälä  2018-05-18  1190  
f0d2b758 Ville Syrjälä  2018-05-18  1191WARN_ON(port_sel != 
PANEL_PORT_SELECT_LVDS);
a44628b9 Ville Syrjälä  2018-05-14  1192
intel_lvds_port_enabled(dev_priv, LVDS, _pipe);
ea0760cf Jesse Barnes   2011-01-04  1193}
ea0760cf Jesse Barnes   2011-01-04  1194  
ea0760cf Jesse Barnes   2011-01-04  1195val = I915_READ(pp_reg);
ea0760cf Jesse

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915: Make request allocation caches global

2019-02-27 Thread Patchwork

== Series Details ==

Series: series starting with [1/3] drm/i915: Make request allocation caches 
global
URL   : https://patchwork.freedesktop.org/series/57319/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_5668_full -> Patchwork_12323_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_12323_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_12323_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_12323_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_flip@2x-flip-vs-suspend-interruptible:
- shard-hsw:  PASS -> DMESG-WARN

  
Known issues


  Here are the changes found in Patchwork_12323_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@vcs0-clean:
- shard-iclb: NOTRUN -> SKIP [fdo#109281]

  * igt@gem_exec_big:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] +37

  * igt@gem_mocs_settings@mocs-rc6-vebox:
- shard-iclb: NOTRUN -> SKIP [fdo#109287]

  * igt@gem_mocs_settings@mocs-settings-bsd2:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] / [fdo#109287]

  * igt@gem_pwrite@huge-cpu-forwards:
- shard-iclb: NOTRUN -> SKIP [fdo#109290] +1

  * igt@gen3_render_mixed_blits:
- shard-iclb: NOTRUN -> SKIP [fdo#109289] +1

  * igt@i915_hangman@error-state-capture-bsd2:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] +6

  * igt@i915_pm_lpsp@non-edp:
- shard-iclb: NOTRUN -> SKIP [fdo#109301]

  * igt@i915_pm_rpm@basic-pci-d3-state:
- shard-iclb: PASS -> INCOMPLETE [fdo#108840]

  * igt@i915_pm_rpm@gem-mmap-gtt:
- shard-kbl:  PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +24

  * igt@i915_pm_rpm@reg-read-ioctl:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +1

  * igt@i915_selftest@live_contexts:
- shard-iclb: NOTRUN -> DMESG-FAIL [fdo#108569]

  * igt@kms_available_modes_crc@available_mode_test_crc:
- shard-skl:  NOTRUN -> FAIL [fdo#106641]

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
- shard-apl:  NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-modeset-hang-oldfb-render-f:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +8

  * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
- shard-kbl:  PASS -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-f:
- shard-hsw:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1

  * igt@kms_chamelium@vga-frame-dump:
- shard-iclb: NOTRUN -> SKIP [fdo#109284] +1

  * igt@kms_color@pipe-a-degamma:
- shard-apl:  PASS -> FAIL [fdo#104782] / [fdo#108145]

  * igt@kms_cursor_crc@cursor-256x256-sliding:
- shard-iclb: NOTRUN -> FAIL [fdo#103232] +1

  * igt@kms_cursor_crc@cursor-512x170-random:
- shard-iclb: NOTRUN -> SKIP [fdo#109279] +1

  * igt@kms_cursor_crc@cursor-64x21-sliding:
- shard-apl:  PASS -> FAIL [fdo#103232] +2

  * igt@kms_cursor_crc@cursor-alpha-opaque:
- shard-apl:  PASS -> FAIL [fdo#109350]

  * igt@kms_flip@2x-flip-vs-panning-vs-hang-interruptible:
- shard-iclb: NOTRUN -> SKIP [fdo#109274] +1

  * igt@kms_flip@2x-modeset-vs-vblank-race:
- shard-glk:  PASS -> FAIL [fdo#103060]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt:
- shard-apl:  PASS -> FAIL [fdo#103167]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt:
- shard-glk:  PASS -> FAIL [fdo#103167] +1

  * igt@kms_frontbuffer_tracking@fbc-1p-rte:
- shard-apl:  PASS -> FAIL [fdo#103167] / [fdo#105682]

  * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-blt:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] +116

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-blt:
- shard-hsw:  NOTRUN -> SKIP [fdo#109271] +27
- shard-iclb: PASS -> FAIL [fdo#103167] +3

  * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-spr-indfb-draw-mmap-gtt:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] +10

  * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping:
- shard-skl:  NOTRUN -> DMESG-WARN [fdo#106885] +1

  * igt@kms_plane@plane-position-covered-pipe-c-planes:
- shard-glk:  PASS -> FAIL [fdo#103166]

  * igt@kms_plane_alpha_blend@pipe-b-alpha-7efc:
- shard-skl:  NOTRUN -> FAIL [fdo#107815] / [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-b-alpha-basic:
- shard-apl:  NOTRUN -> FAIL

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/6] drm/i915/psr: Remove PSR2 FIXME

2019-02-27 Thread Patchwork

== Series Details ==

Series: series starting with [v3,1/6] drm/i915/psr: Remove PSR2 FIXME
URL   : https://patchwork.freedesktop.org/series/57324/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5668 -> Patchwork_12324


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/57324/revisions/1/

Known issues


  Here are the changes found in Patchwork_12324 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_basic@basic-bsd2:
- fi-kbl-7500u:   NOTRUN -> SKIP [fdo#109271] +9

  * igt@gem_exec_suspend@basic-s3:
- fi-hsw-peppy:   PASS -> DMESG-WARN [fdo#102614] +1

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-7560u:   PASS -> INCOMPLETE [fdo#107139]

  * igt@i915_selftest@live_execlists:
- fi-apl-guc: NOTRUN -> INCOMPLETE [fdo#103927] / [fdo#109720]

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   NOTRUN -> DMESG-WARN [fdo#103841]

  * igt@kms_psr@cursor_plane_move:
- fi-whl-u:   PASS -> FAIL [fdo#107383] +3

  * igt@kms_psr@primary_page_flip:
- fi-apl-guc: NOTRUN -> SKIP [fdo#109271] +40

  * igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: PASS -> FAIL [fdo#104008]

  * igt@runner@aborted:
- fi-kbl-7500u:   NOTRUN -> FAIL [fdo#103841]

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-apl-guc: DMESG-WARN -> PASS

  
  [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
  [fdo#103841]: https://bugs.freedesktop.org/show_bug.cgi?id=103841
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
  [fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139
  [fdo#107383]: https://bugs.freedesktop.org/show_bug.cgi?id=107383
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720


Participating hosts (42 -> 35)
--

  Additional (1): fi-kbl-7500u 
  Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-byt-squawks 
fi-bsw-cyan fi-kbl-guc fi-icl-u3 fi-icl-y 


Build changes
-

* Linux: CI_DRM_5668 -> Patchwork_12324

  CI_DRM_5668: f31df5b814fb600861b577e2bc2cdb75c8c3e323 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4861: 017d8461ae509b2d8ef5f585de8ad908081d28a0 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12324: c77872de172eace9bb835d4a42c3484188affbca @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

c77872de172e drm/i915: Enable PSR2 by default
eb31e5391b9a drm/i915: Disable PSR2 while getting pipe CRC
3ef971bb424a drm/i915/crc: Make IPS workaround generic
8d51e309df10 drm/i915: Compute and commit color features in fastsets
afd41f2adbcf drm/i915/psr: Only lookup for enabled CRTCs when forcing a fastset
3131977023c5 drm/i915/psr: Remove PSR2 FIXME

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12324/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 4/6] drm/i915/crc: Make IPS workaround generic

2019-02-27 Thread José Roberto de Souza

Other features like PSR2 also needs to be disabled while getting CRC
so lets rename ips_force_disable to crc_enabled, drop all this checks
for pipe A and HSW and BDW and make it generic and
hsw_compute_ips_config() will take care of all the checks removed
from here.

Cc: Dhinakaran Pandiyan 
Cc: Ville Syrjälä 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_display.c  | 10 +--
 drivers/gpu/drm/i915/intel_drv.h  |  3 +-
 drivers/gpu/drm/i915/intel_pipe_crc.c | 42 +--
 3 files changed, 24 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 816e8f124b3b..328967c642b3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6751,7 +6751,13 @@ static bool hsw_compute_ips_config(struct 
intel_crtc_state *crtc_state)
if (!hsw_crtc_state_ips_capable(crtc_state))
return false;
 
-   if (crtc_state->ips_force_disable)
+   /*
+* When IPS gets enabled, the pipe CRC changes. Since IPS gets
+* enabled and disabled dynamically based on package C states,
+* user space can't make reliable use of the CRCs, so let's just
+* completely disable it.
+*/
+   if (crtc_state->crc_enabled)
return false;
 
/* IPS should be fine as long as at least one plane is enabled. */
@@ -11684,7 +11690,7 @@ clear_intel_crtc_state(struct intel_crtc_state 
*crtc_state)
saved_state->shared_dpll = crtc_state->shared_dpll;
saved_state->dpll_hw_state = crtc_state->dpll_hw_state;
saved_state->pch_pfit.force_thru = crtc_state->pch_pfit.force_thru;
-   saved_state->ips_force_disable = crtc_state->ips_force_disable;
+   saved_state->crc_enabled = crtc_state->crc_enabled;
if (IS_G4X(dev_priv) ||
IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
saved_state->wm = crtc_state->wm;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 5412373e2f98..2be64529e4a2 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -999,7 +999,8 @@ struct intel_crtc_state {
struct intel_link_m_n fdi_m_n;
 
bool ips_enabled;
-   bool ips_force_disable;
+
+   bool crc_enabled;
 
bool enable_fbc;
 
diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c 
b/drivers/gpu/drm/i915/intel_pipe_crc.c
index 53d4ec68d3c4..f6d0b2aaffe2 100644
--- a/drivers/gpu/drm/i915/intel_pipe_crc.c
+++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
@@ -280,11 +280,12 @@ static int ilk_pipe_crc_ctl_reg(enum 
intel_pipe_crc_source *source,
return 0;
 }
 
-static void hsw_pipe_A_crc_wa(struct drm_i915_private *dev_priv,
- bool enable)
+static void
+intel_crtc_crc_prepare(struct drm_i915_private *dev_priv, struct drm_crtc 
*crtc,
+  bool enable)
 {
struct drm_device *dev = _priv->drm;
-   struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, PIPE_A);
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_crtc_state *pipe_config;
struct drm_atomic_state *state;
struct drm_modeset_acquire_ctx ctx;
@@ -301,23 +302,15 @@ static void hsw_pipe_A_crc_wa(struct drm_i915_private 
*dev_priv,
state->acquire_ctx = 
 
 retry:
-   pipe_config = intel_atomic_get_crtc_state(state, crtc);
+   pipe_config = intel_atomic_get_crtc_state(state, intel_crtc);
if (IS_ERR(pipe_config)) {
ret = PTR_ERR(pipe_config);
goto put_state;
}
 
-   if (HAS_IPS(dev_priv)) {
-   /*
-* When IPS gets enabled, the pipe CRC changes. Since IPS gets
-* enabled and disabled dynamically based on package C states,
-* user space can't make reliable use of the CRCs, so let's just
-* completely disable it.
-*/
-   pipe_config->ips_force_disable = enable;
-   }
+   pipe_config->crc_enabled = enable;
 
-   if (IS_HASWELL(dev_priv)) {
+   if (IS_HASWELL(dev_priv) && intel_crtc->pipe == PIPE_A) {
pipe_config->pch_pfit.force_thru = enable;
if (pipe_config->cpu_transcoder == TRANSCODER_EDP &&
pipe_config->pch_pfit.enabled != enable)
@@ -343,8 +336,7 @@ static void hsw_pipe_A_crc_wa(struct drm_i915_private 
*dev_priv,
 static int ivb_pipe_crc_ctl_reg(struct drm_i915_private *dev_priv,
enum pipe pipe,
enum intel_pipe_crc_source *source,
-   u32 *val,
-   bool set_wa)
+   u32 *val)
 {
if (*source == INTEL_PIPE_CRC_SOURCE_AUTO)
*source = INTEL_PIPE_CRC_SOURCE_PIPE;
@@ -357,10 +349,6 @@ static int ivb_pipe_crc_ctl_reg(struct

[Intel-gfx] [PATCH v3 1/6] drm/i915/psr: Remove PSR2 FIXME

2019-02-27 Thread José Roberto de Souza

Now we are checking sink capabilities when probing PSR DPCD register
and then dynamically checking in if new state is compatible with PSR
in, so this FIXME can be dropped.

Reviewed-by: Dhinakaran Pandiyan 
Cc: Dhinakaran Pandiyan 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_psr.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 75c1a5deebf5..8bed73914876 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -532,11 +532,6 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
int crtc_vdisplay = crtc_state->base.adjusted_mode.crtc_vdisplay;
int psr_max_h = 0, psr_max_v = 0;
 
-   /*
-* FIXME psr2_support is messed up. It's both computed
-* dynamically during PSR enable, and extracted from sink
-* caps during eDP detection.
-*/
if (!dev_priv->psr.sink_psr2_support)
return false;
 
-- 
2.21.0

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

[Intel-gfx] [PATCH v3 5/6] drm/i915: Disable PSR2 while getting pipe CRC

2019-02-27 Thread José Roberto de Souza

When PSR2 is active aka after the number of frames programmed in
PSR2_CTL 'Frames Before SU Entry' hardware stops to generate CRC
interruptions causing IGT tests to fail due timeout.

Oddly that don't happen when PSR1 active, so here it switches from
PSR2 to PSR1 while user is requesting pipe CRC.

Force setting mode_changed as true is necessary to atomic checks
functions compute new PSR state, that is why it was added to
intel_crtc_crc_prepare().

v3: Reusing intel_crtc_crc_prepare() and crc_enabled

v2: Changed commit description to describe that PSR2 inhibit CRC
calculations.

Cc: Dhinakaran Pandiyan 
Cc: Ville Syrjälä 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_pipe_crc.c | 1 +
 drivers/gpu/drm/i915/intel_psr.c  | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c 
b/drivers/gpu/drm/i915/intel_pipe_crc.c
index f6d0b2aaffe2..e7ac24c33650 100644
--- a/drivers/gpu/drm/i915/intel_pipe_crc.c
+++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
@@ -308,6 +308,7 @@ intel_crtc_crc_prepare(struct drm_i915_private *dev_priv, 
struct drm_crtc *crtc,
goto put_state;
}
 
+   pipe_config->base.mode_changed = pipe_config->crc_enabled != enable;
pipe_config->crc_enabled = enable;
 
if (IS_HASWELL(dev_priv) && intel_crtc->pipe == PIPE_A) {
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 6175b1d2e0c8..f7730b8b2ec0 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -572,6 +572,9 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
return false;
}
 
+   if (crtc_state->crc_enabled)
+   return false;
+
return true;
 }
 
-- 
2.21.0

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

[Intel-gfx] [PATCH v3 6/6] drm/i915: Enable PSR2 by default

2019-02-27 Thread José Roberto de Souza

The support for PSR2 was polished, IGT tests for PSR2 was added and
it was tested performing regular user workloads like browsing,
editing documents and compiling Linux, so it is time to enable it by
default and enjoy even more power-savings.

Cc: Rodrigo Vivi 
Cc: Dhinakaran Pandiyan 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_psr.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index f7730b8b2ec0..f168f92912eb 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -80,9 +80,6 @@ static bool intel_psr2_enabled(struct drm_i915_private 
*dev_priv,
case I915_PSR_DEBUG_DISABLE:
case I915_PSR_DEBUG_FORCE_PSR1:
return false;
-   case I915_PSR_DEBUG_DEFAULT:
-   if (i915_modparams.enable_psr <= 0)
-   return false;
default:
return crtc_state->has_psr2;
}
-- 
2.21.0

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

[Intel-gfx] [PATCH v3 3/6] drm/i915: Compute and commit color features in fastsets

2019-02-27 Thread José Roberto de Souza

In any commit, intel_modeset_pipe_config() will initialilly clear
and then recalculate most of the pipe states but it leave intel
specific color features states in reset state.

If after intel_pipe_config_compare() is detected that a fastset is
possible it will mark update_pipe as true and unsed mode_changed,
causing the color features state to be kept in reset state and then
latter being committed to hardware disabling the color features.

This issue can be reproduced by any code patch that duplicates the
actual(with color features already enabled) state and only mark
mode_changed as true.

Cc: Ville Syrjälä 
Cc: Maarten Lankhorst 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_display.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7c5e84ef5171..816e8f124b3b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11232,7 +11232,8 @@ static int intel_crtc_atomic_check(struct drm_crtc 
*crtc,
return ret;
}
 
-   if (mode_changed || crtc_state->color_mgmt_changed) {
+   if (mode_changed || pipe_config->update_pipe ||
+   crtc_state->color_mgmt_changed) {
ret = intel_color_check(pipe_config);
if (ret)
return ret;
-- 
2.21.0

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

[Intel-gfx] [PATCH v3 2/6] drm/i915/psr: Only lookup for enabled CRTCs when forcing a fastset

2019-02-27 Thread José Roberto de Souza

Forcing a specific CRTC to the eDP connector was causing the
intel_psr_fastset_force() to mark mode_chaged in the wrong and
disabled CRTC causing no update in the PSR state.

Looks like our internal state track do not clear output_types and
has_psr in the disabled CRTCs, not sure if this is the expected
behavior or not but in the mean time this fix the issue.

Cc: Maarten Lankhorst 
Cc: Dhinakaran Pandiyan 
Reviewed-by: Dhinakaran Pandiyan 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_psr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 8bed73914876..6175b1d2e0c8 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -981,7 +981,8 @@ static int intel_psr_fastset_force(struct drm_i915_private 
*dev_priv)
 
intel_crtc_state = to_intel_crtc_state(crtc_state);
 
-   if (intel_crtc_has_type(intel_crtc_state, INTEL_OUTPUT_EDP) &&
+   if (crtc_state->active &&
+   intel_crtc_has_type(intel_crtc_state, INTEL_OUTPUT_EDP) &&
intel_crtc_state->has_psr) {
/* Mark mode as changed to trigger a pipe->update() */
crtc_state->mode_changed = true;
-- 
2.21.0

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Make request allocation caches global

2019-02-27 Thread Patchwork

== Series Details ==

Series: series starting with [1/3] drm/i915: Make request allocation caches 
global
URL   : https://patchwork.freedesktop.org/series/57319/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5668 -> Patchwork_12323


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/57319/revisions/1/

Known issues


  Here are the changes found in Patchwork_12323 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_basic@basic-bsd2:
- fi-kbl-7500u:   NOTRUN -> SKIP [fdo#109271] +9

  * igt@i915_selftest@live_execlists:
- fi-apl-guc: NOTRUN -> INCOMPLETE [fdo#103927] / [fdo#109720]

  * igt@i915_selftest@live_hangcheck:
- fi-icl-u3:  PASS -> INCOMPLETE [fdo#108569]

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   NOTRUN -> DMESG-WARN [fdo#103841]

  * igt@kms_psr@primary_page_flip:
- fi-apl-guc: NOTRUN -> SKIP [fdo#109271] +40

  * igt@runner@aborted:
- fi-kbl-7500u:   NOTRUN -> FAIL [fdo#103841]

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-apl-guc: DMESG-WARN -> PASS

  
  [fdo#103841]: https://bugs.freedesktop.org/show_bug.cgi?id=103841
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720


Participating hosts (42 -> 37)
--

  Additional (1): fi-kbl-7500u 
  Missing(6): fi-kbl-7567u fi-ilk-m540 fi-hsw-4200u fi-byt-squawks 
fi-bsw-cyan fi-icl-y 


Build changes
-

* Linux: CI_DRM_5668 -> Patchwork_12323

  CI_DRM_5668: f31df5b814fb600861b577e2bc2cdb75c8c3e323 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4861: 017d8461ae509b2d8ef5f585de8ad908081d28a0 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12323: dc80371b25d677c5518b69a50b91f26b64482ce1 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

dc80371b25d6 drm/i915: Remove second level open-coded rcu work
8e4c2b2cab40 drm/i915: Make object/vma allocation caches global
158b026641f1 drm/i915: Make request allocation caches global

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12323/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Fix atomic state leak when resetting HDMI link

2019-02-27 Thread Souza, Jose

On Thu, 2019-02-28 at 00:19 +, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [1/2] drm/i915: Fix atomic state leak
> when resetting HDMI link
> URL   : https://patchwork.freedesktop.org/series/57318/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_5668 -> Patchwork_12322
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_12322 absolutely need
> to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the
> changes
>   introduced in Patchwork_12322, please notify your bug team to allow
> them
>   to document this new failure mode, which will reduce false
> positives in CI.
> 
>   External URL: 
> https://patchwork.freedesktop.org/api/1.0/series/57318/revisions/1/
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in
> Patchwork_12322:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@i915_selftest@live_objects:
> - fi-apl-guc: NOTRUN -> DMESG-WARN

Not related at all.

> 
>   
> Known issues
> 
> 
>   Here are the changes found in Patchwork_12322 that come from known
> issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@amdgpu/amd_basic@userptr:
> - fi-kbl-8809g:   PASS -> DMESG-WARN [fdo#108965]
> 
>   * igt@gem_exec_basic@basic-bsd2:
> - fi-kbl-7500u:   NOTRUN -> SKIP [fdo#109271] +9
> 
>   * igt@i915_selftest@live_hangcheck:
> - fi-icl-u3:  PASS -> INCOMPLETE [fdo#108569]
> 
>   * igt@i915_selftest@live_requests:
> - fi-snb-2600:PASS -> INCOMPLETE [fdo#105411]
> 
>   * igt@kms_chamelium@dp-crc-fast:
> - fi-kbl-7500u:   NOTRUN -> DMESG-WARN [fdo#103841]
> 
>   * igt@kms_psr@primary_page_flip:
> - fi-apl-guc: NOTRUN -> SKIP [fdo#109271] +40
> 
>   * igt@runner@aborted:
> - fi-kbl-7500u:   NOTRUN -> FAIL [fdo#103841]
> 
>   
>  Possible fixes 
> 
>   * igt@gem_exec_suspend@basic-s3:
> - fi-apl-guc: DMESG-WARN -> PASS
> - {fi-icl-y}: FAIL [fdo#103375] -> PASS
> 
>   * igt@gem_exec_suspend@basic-s4-devices:
> - {fi-icl-y}: FAIL -> PASS
> 
>   * igt@gem_mmap_gtt@basic-small-copy:
> - {fi-icl-y}: TIMEOUT -> PASS
> 
>   * igt@kms_busy@basic-flip-b:
> - {fi-icl-y}: FAIL [fdo#103182] -> PASS
> 
>   
>   {name}: This element is suppressed. This means it is ignored when
> computing
>   the status of the difference (SUCCESS, WARNING, or
> FAILURE).
> 
>   [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
>   [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
>   [fdo#103841]: https://bugs.freedesktop.org/show_bug.cgi?id=103841
>   [fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
>   [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
>   [fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
>   [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
> 
> 
> Participating hosts (42 -> 39)
> --
> 
>   Additional (1): fi-kbl-7500u 
>   Missing(4): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-
> 4200u 
> 
> 
> Build changes
> -
> 
> * Linux: CI_DRM_5668 -> Patchwork_12322
> 
>   CI_DRM_5668: f31df5b814fb600861b577e2bc2cdb75c8c3e323 @
> git://anongit.freedesktop.org/gfx-ci/linux
>   IGT_4861: 017d8461ae509b2d8ef5f585de8ad908081d28a0 @
> git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
>   Patchwork_12322: 8c1a39496e922ad945fb891f7c5ecb36c2ff238f @
> git://anongit.freedesktop.org/gfx-ci/linux
> 
> 
> == Linux commits ==
> 
> 8c1a39496e92 drm/i915: Don't manually add connectors and planes state
> ae104db6497b drm/i915: Fix atomic state leak when resetting HDMI link
> 
> == Logs ==
> 
> For more details see: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12322/
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/icl: Probe again type-c connectors that failed

2019-02-27 Thread Souza, Jose

On Tue, 2019-02-26 at 16:08 +0200, Imre Deak wrote:
> On Fri, Feb 22, 2019 at 01:08:34PM -0800, José Roberto de Souza
> wrote:
> > Unpowered type-c dongles can take some time to boot and be
> > responsible, causing the probe to fail and sink never be detected
> > without further actions from userspace.
> > 
> > It was not a issue for older platforms because there was a hardware
> > bridge between DDI/DP ports and type-c controller adding a implicit
> > delay that hid this issue but ICL have type-c controllers
> > integrated
> > to the SOC bring this issue to users.
> > 
> > So here if the probe failed when coming from a IRQ it returns
> > INTEL_HOTPLUG_RETRY that will schedule another run of
> > i915_hotplug_work_func() after 1 second what is time enough for
> > those type-c dongles to boot.
> > 
> > Cc: Ville Syrjälä 
> > Cc: Imre Deak 
> > Cc: Jani Nikula 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c | 13 +
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 1676a87f18cb..96bbcf5c9787 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -4056,6 +4056,8 @@ intel_ddi_hotplug(struct intel_encoder
> > *encoder,
> >   struct intel_connector *connector,
> >   bool irq_received)
> >  {
> > +   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > +   struct intel_digital_port *dig_port = enc_to_dig_port(
> > >base);
> > struct drm_modeset_acquire_ctx ctx;
> > enum intel_hotplug_state state;
> > int ret;
> > @@ -4082,6 +4084,17 @@ intel_ddi_hotplug(struct intel_encoder
> > *encoder,
> > drm_modeset_acquire_fini();
> > WARN(ret, "Acquiring modeset locks failed with %i\n", ret);
> >  
> > +   /*
> > +* Unpowered type-c dongles can take some time to boot and be
> > +* responsible, so here giving some type to those dongles to 

s/type/time
So I don't loose it when doing the next version.

> > power up
> > +* and then retrying the probe.
> > +*/
> > +   if (state == INTEL_HOTPLUG_NOCHANGE &&
> > +   connector->base.status != connector_status_connected &&
> > +   irq_received && intel_port_is_tc(dev_priv, encoder->port)
> > &&
> > +   !dig_port->tc_legacy_port && !dig_port->dp.is_mst)
> 
> Based on the investigation by Jani et al, we have the similar problem
> with
> HDMI, only during disconnect. So I think we could generalize by
> retrying
> any time there is no change (except for MST where the driver always
> keeps
> the connector in a disconnected state), regardless of the type of the
> sink, since a no-change is suspect in any case: why would the sink
> signal
> (with a long pulse) if there is no change?

The only case that I can think of is the cases were sink do a short
pulse but we don't handle it in the short pulse handler and schedule a
long pulse handler but it should not cause any drawback retry everytime
there is no change in the state and irq_received is set.

What comment could we add about the HDMI here? Something like this
would be fine?

"HDMI sinks are reported as connected by hardware right after unpluging
it, so here also giving some time for hardware to process the unplug so
driver can read it and do the unplug sequence and notify userspace
about the absence of the HDMI sink"

> 
> For HDMI we'd also need to handle this in intel_hdmi.c.

It happens in older gens that don't have DDI? Otherwise just the update
above should take care of DP and HDMI DDI ports.

> 
> Then Ville suggested to add a Chamelium test for this to IGT, could
> you
> Jose look into that as well? Both the connect and disconnect races
> could
> be tested, both on HDMI and DP, by generating the HPD early/late wrt.
> to
> AUX/DDC starting/stopping to return valid data. I don't know if
> Chamelium can do this, you'd have to find that out first.

I will try put my hands in a Chamelium board otherwise I will play with
trybot to add this tests.

> 
> --Imre
> 
> > +   state = INTEL_HOTPLUG_RETRY;
> > +
> > return state;
> >  }
> >  
> > -- 
> > 2.20.1
> > 


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915: Make request allocation caches global

2019-02-27 Thread Patchwork

== Series Details ==

Series: series starting with [1/3] drm/i915: Make request allocation caches 
global
URL   : https://patchwork.freedesktop.org/series/57319/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Make request allocation caches global
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3581:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3578:16: warning: expression 
using sizeof(void)

Commit: drm/i915: Make object/vma allocation caches global
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3578:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3572:16: warning: expression 
using sizeof(void)
+./include/uapi/linux/perf_event.h:147:56: warning: cast truncates bits from 
constant value (8000 becomes 0)

Commit: drm/i915: Remove second level open-coded rcu work
Okay!

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915: Make request allocation caches global

2019-02-27 Thread Patchwork

== Series Details ==

Series: series starting with [1/3] drm/i915: Make request allocation caches 
global
URL   : https://patchwork.freedesktop.org/series/57319/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
158b026641f1 drm/i915: Make request allocation caches global
-:162: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#162: 
new file mode 100644

-:167: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#167: FILE: drivers/gpu/drm/i915/i915_globals.c:1:
+/*

-:286: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#286: FILE: drivers/gpu/drm/i915/i915_globals.h:1:
+/*

-:627: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'plist' - possible 
side-effects?
#627: FILE: drivers/gpu/drm/i915/i915_scheduler.h:93:
+#define priolist_for_each_request(it, plist, idx) \
+   for (idx = 0; idx < ARRAY_SIZE((plist)->requests); idx++) \
+   list_for_each_entry(it, &(plist)->requests[idx], sched.link)

-:627: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'idx' - possible 
side-effects?
#627: FILE: drivers/gpu/drm/i915/i915_scheduler.h:93:
+#define priolist_for_each_request(it, plist, idx) \
+   for (idx = 0; idx < ARRAY_SIZE((plist)->requests); idx++) \
+   list_for_each_entry(it, &(plist)->requests[idx], sched.link)

-:631: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'plist' - possible 
side-effects?
#631: FILE: drivers/gpu/drm/i915/i915_scheduler.h:97:
+#define priolist_for_each_request_consume(it, n, plist, idx) \
+   for (; (idx = ffs((plist)->used)); (plist)->used &= ~BIT(idx - 1)) \
+   list_for_each_entry_safe(it, n, \
+&(plist)->requests[idx - 1], \
+sched.link)

-:631: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'idx' - possible 
side-effects?
#631: FILE: drivers/gpu/drm/i915/i915_scheduler.h:97:
+#define priolist_for_each_request_consume(it, n, plist, idx) \
+   for (; (idx = ffs((plist)->used)); (plist)->used &= ~BIT(idx - 1)) \
+   list_for_each_entry_safe(it, n, \
+&(plist)->requests[idx - 1], \
+sched.link)

total: 0 errors, 3 warnings, 4 checks, 800 lines checked
8e4c2b2cab40 drm/i915: Make object/vma allocation caches global
dc80371b25d6 drm/i915: Remove second level open-coded rcu work

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Fix atomic state leak when resetting HDMI link

2019-02-27 Thread Patchwork

== Series Details ==

Series: series starting with [1/2] drm/i915: Fix atomic state leak when 
resetting HDMI link
URL   : https://patchwork.freedesktop.org/series/57318/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_5668 -> Patchwork_12322


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_12322 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_12322, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/57318/revisions/1/

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_12322:

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live_objects:
- fi-apl-guc: NOTRUN -> DMESG-WARN

  
Known issues


  Here are the changes found in Patchwork_12322 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g:   PASS -> DMESG-WARN [fdo#108965]

  * igt@gem_exec_basic@basic-bsd2:
- fi-kbl-7500u:   NOTRUN -> SKIP [fdo#109271] +9

  * igt@i915_selftest@live_hangcheck:
- fi-icl-u3:  PASS -> INCOMPLETE [fdo#108569]

  * igt@i915_selftest@live_requests:
- fi-snb-2600:PASS -> INCOMPLETE [fdo#105411]

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   NOTRUN -> DMESG-WARN [fdo#103841]

  * igt@kms_psr@primary_page_flip:
- fi-apl-guc: NOTRUN -> SKIP [fdo#109271] +40

  * igt@runner@aborted:
- fi-kbl-7500u:   NOTRUN -> FAIL [fdo#103841]

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-apl-guc: DMESG-WARN -> PASS
- {fi-icl-y}: FAIL [fdo#103375] -> PASS

  * igt@gem_exec_suspend@basic-s4-devices:
- {fi-icl-y}: FAIL -> PASS

  * igt@gem_mmap_gtt@basic-small-copy:
- {fi-icl-y}: TIMEOUT -> PASS

  * igt@kms_busy@basic-flip-b:
- {fi-icl-y}: FAIL [fdo#103182] -> PASS

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
  [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
  [fdo#103841]: https://bugs.freedesktop.org/show_bug.cgi?id=103841
  [fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271


Participating hosts (42 -> 39)
--

  Additional (1): fi-kbl-7500u 
  Missing(4): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u 


Build changes
-

* Linux: CI_DRM_5668 -> Patchwork_12322

  CI_DRM_5668: f31df5b814fb600861b577e2bc2cdb75c8c3e323 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4861: 017d8461ae509b2d8ef5f585de8ad908081d28a0 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12322: 8c1a39496e922ad945fb891f7c5ecb36c2ff238f @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

8c1a39496e92 drm/i915: Don't manually add connectors and planes state
ae104db6497b drm/i915: Fix atomic state leak when resetting HDMI link

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12322/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 3/3] drm/i915: use REG_FIELD_PREP() to define register bitfield values

2019-02-27 Thread Michal Wajdeczko

On Wed, 27 Feb 2019 18:02:38 +0100, Jani Nikula   
wrote:



@@ -108,9 +108,9 @@
  *  #define FOO(pipe)   _MMIO_PIPE(pipe, _FOO_A, _FOO_B)
  *  #define   FOO_ENABLEREG_BIT(31)
  *  #define   FOO_MODE_MASK REG_GENMASK(19, 16)
- *  #define   FOO_MODE_BAR  (0 << 16)
- *  #define   FOO_MODE_BAZ  (1 << 16)
- *  #define   FOO_MODE_QUX_SNB  (2 << 16)
+ *  #define   FOO_MODE_BAR  REG_FIELD_PREP(FOO_MODE_MASK, 0)
+ *  #define   FOO_MODE_BAZ  REG_FIELD_PREP(FOO_MODE_MASK, 1)
+ *  #define   FOO_MODE_QUX_SNB  REG_FIELD_PREP(FOO_MODE_MASK, 2)


hmm, shouldn't we define these values as:

#define   FOO_MODE_BAR  (0)
#define   FOO_MODE_BAZ  (1)
#define   FOO_MODE_QUX_SNB  (2)

to allow using them natively with REG_FIELD_GET/PREPARE() ?
maybe we should also consider dropping _MASK suffix?

MMIO_WRITE(...,
   REG_FIELD_PREPARE(FOO_ENABLE, true) |
   REG_FIELD_PREPARE(FOO_MODE, FOO_MODE_BAR))

mode = REG_FIELD_GET(FOO_MODE, MMIO_READ(...));
enabled = REG_FIELD_GET(FOO_ENABLE, MMIO_READ(...));

Thanks,
Michal

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

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] Revert "drm/i915: Avoid waking the engines just to check if they are idle" (rev2)

2019-02-27 Thread Patchwork

== Series Details ==

Series: series starting with [1/2] Revert "drm/i915: Avoid waking the engines 
just to check if they are idle" (rev2)
URL   : https://patchwork.freedesktop.org/series/57311/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5666_full -> Patchwork_12321_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_12321_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_bad_reloc@negative-reloc-bsd2:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] +7

  * igt@gem_bad_reloc@negative-reloc-lut-blt:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] +34

  * igt@gem_exec_params@no-vebox:
- shard-iclb: NOTRUN -> SKIP [fdo#109283]

  * igt@gem_pwrite@huge-gtt-forwards:
- shard-iclb: NOTRUN -> SKIP [fdo#109290]

  * igt@i915_pm_rpm@system-suspend:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +4

  * igt@i915_pm_rpm@system-suspend-execbuf:
- shard-iclb: PASS -> INCOMPLETE [fdo#107713] / [fdo#108840]

  * igt@i915_pm_rpm@universal-planes-dpms:
- shard-skl:  PASS -> INCOMPLETE [fdo#107807]

  * igt@i915_query@query-topology-known-pci-ids:
- shard-iclb: NOTRUN -> SKIP [fdo#109303]

  * igt@kms_busy@extended-modeset-hang-newfb-render-b:
- shard-skl:  PASS -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-hsw:  PASS -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-modeset-hang-oldfb-render-d:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +5

  * igt@kms_busy@extended-modeset-hang-oldfb-render-e:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +4

  * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956]
- shard-apl:  PASS -> DMESG-WARN [fdo#107956]

  * igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-glk:  PASS -> FAIL [fdo#108145]
- shard-iclb: NOTRUN -> FAIL [fdo#107725] +1

  * igt@kms_ccs@pipe-c-missing-ccs-buffer:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] +29

  * igt@kms_chamelium@hdmi-edid-read:
- shard-iclb: NOTRUN -> SKIP [fdo#109284] +1

  * igt@kms_color@pipe-a-degamma:
- shard-apl:  PASS -> FAIL [fdo#104782] / [fdo#108145]

  * igt@kms_concurrent@pipe-f:
- shard-iclb: NOTRUN -> SKIP [fdo#109278] +1

  * igt@kms_cursor_crc@cursor-128x128-dpms:
- shard-iclb: NOTRUN -> FAIL [fdo#103232]

  * igt@kms_cursor_crc@cursor-128x128-random:
- shard-apl:  PASS -> FAIL [fdo#103232] +1

  * igt@kms_cursor_crc@cursor-256x85-sliding:
- shard-apl:  NOTRUN -> FAIL [fdo#103232] +1

  * igt@kms_cursor_legacy@cursora-vs-flipb-legacy:
- shard-iclb: NOTRUN -> SKIP [fdo#109274] +1

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-skl:  PASS -> FAIL [fdo#102670]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
- shard-iclb: NOTRUN -> FAIL [fdo#103167]
- shard-glk:  PASS -> FAIL [fdo#103167] +3

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-pri-shrfb-draw-mmap-gtt:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] +8

  * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-wc:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] +59

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-move:
- shard-iclb: PASS -> FAIL [fdo#103167] +3

  * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-cur-indfb-move:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] +68

  * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping:
- shard-glk:  PASS -> FAIL [fdo#108948]

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-skl:  PASS -> INCOMPLETE [fdo#104108]

  * igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-skl:  NOTRUN -> FAIL [fdo#108145] +2

  * igt@kms_plane_alpha_blend@pipe-c-alpha-7efc:
- shard-kbl:  NOTRUN -> FAIL [fdo#108145] / [fdo#108590]

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
- shard-kbl:  NOTRUN -> FAIL [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1

  * igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-apl:  PASS -> FAIL [fdo#103166] +1

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
- shard-iclb: PASS -> FAIL [fdo#103166] +2

  * igt@kms_plane_multiple@atomic-pipe-c-tiling-x:
- shard-glk:  PASS -> FAIL [fdo#103166]

  * igt@kms_psr@psr2_primary_mmap_cpu:
- shard-iclb: NOTRUN -> SKIP [fdo#109441] +1

  *

[Intel-gfx] [PATCH 1/3] drm/i915: Make request allocation caches global

2019-02-27 Thread Chris Wilson

As kmem_caches share the same properties (size, allocation/free behaviour)
for all potential devices, we can use global caches. While this
potential has worse fragmentation behaviour (one can argue that
different devices would have different activity lifetimes, but you can
also argue that activity is temporal across the system) it is the
default behaviour of the system at large to amalgamate matching caches.

The benefit for us is much reduced pointer dancing along the frequent
allocation paths.

v2: Defer shrinking until after a global grace period for futureproofing
multiple consumers of the slab caches, similar to the current strategy
for avoiding shrinking too early.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/i915_active.c|   7 +-
 drivers/gpu/drm/i915/i915_active.h|   1 +
 drivers/gpu/drm/i915/i915_drv.h   |   3 -
 drivers/gpu/drm/i915/i915_gem.c   |  34 +-
 drivers/gpu/drm/i915/i915_globals.c   | 113 ++
 drivers/gpu/drm/i915/i915_globals.h   |  15 +++
 drivers/gpu/drm/i915/i915_pci.c   |   8 +-
 drivers/gpu/drm/i915/i915_request.c   |  53 ++--
 drivers/gpu/drm/i915/i915_request.h   |  10 ++
 drivers/gpu/drm/i915/i915_scheduler.c |  66 +++---
 drivers/gpu/drm/i915/i915_scheduler.h |  34 +-
 drivers/gpu/drm/i915/intel_guc_submission.c   |   3 +-
 drivers/gpu/drm/i915/intel_lrc.c  |   6 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h   |  17 ---
 drivers/gpu/drm/i915/selftests/mock_engine.c  |  45 ---
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  26 
 drivers/gpu/drm/i915/selftests/mock_request.c |  12 +-
 drivers/gpu/drm/i915/selftests/mock_request.h |   7 --
 19 files changed, 312 insertions(+), 149 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_globals.c
 create mode 100644 drivers/gpu/drm/i915/i915_globals.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 1787e1299b1b..a1d834068765 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -77,6 +77,7 @@ i915-y += \
  i915_gem_tiling.o \
  i915_gem_userptr.o \
  i915_gemfs.o \
+ i915_globals.o \
  i915_query.o \
  i915_request.o \
  i915_scheduler.o \
diff --git a/drivers/gpu/drm/i915/i915_active.c 
b/drivers/gpu/drm/i915/i915_active.c
index db7bb5bd5add..d9f6471ac16c 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -294,7 +294,12 @@ int __init i915_global_active_init(void)
return 0;
 }
 
-void __exit i915_global_active_exit(void)
+void i915_global_active_shrink(void)
+{
+   kmem_cache_shrink(global.slab_cache);
+}
+
+void i915_global_active_exit(void)
 {
kmem_cache_destroy(global.slab_cache);
 }
diff --git a/drivers/gpu/drm/i915/i915_active.h 
b/drivers/gpu/drm/i915/i915_active.h
index 12b5c1d287d1..5fbd9102384b 100644
--- a/drivers/gpu/drm/i915/i915_active.h
+++ b/drivers/gpu/drm/i915/i915_active.h
@@ -420,6 +420,7 @@ static inline void i915_active_fini(struct i915_active 
*ref) { }
 #endif
 
 int i915_global_active_init(void);
+void i915_global_active_shrink(void);
 void i915_global_active_exit(void);
 
 #endif /* _I915_ACTIVE_H_ */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cc09caf3870e..f16016b330b3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1473,9 +1473,6 @@ struct drm_i915_private {
struct kmem_cache *objects;
struct kmem_cache *vmas;
struct kmem_cache *luts;
-   struct kmem_cache *requests;
-   struct kmem_cache *dependencies;
-   struct kmem_cache *priorities;
 
const struct intel_device_info __info; /* Use INTEL_INFO() to access. */
struct intel_runtime_info __runtime; /* Use RUNTIME_INFO() to access. */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2b261524cfa4..713ed6fbdcc8 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -42,6 +42,7 @@
 #include "i915_drv.h"
 #include "i915_gem_clflush.h"
 #include "i915_gemfs.h"
+#include "i915_globals.h"
 #include "i915_reset.h"
 #include "i915_trace.h"
 #include "i915_vgpu.h"
@@ -187,6 +188,8 @@ void i915_gem_unpark(struct drm_i915_private *i915)
if (unlikely(++i915->gt.epoch == 0)) /* keep 0 as invalid */
i915->gt.epoch = 1;
 
+   i915_globals_unpark();
+
intel_enable_gt_powersave(i915);
i915_update_gfx_val(i915);
if (INTEL_GEN(i915) >= 6)
@@ -2892,12 +2895,11 @@ static void shrink_caches(struct drm_i915_private *i915)
 * filled slabs to prioritise allocating from the mostly full slabs,
 * with the aim of reducing fragmentation.
 */
-   kmem_cache_shrink(i915->priorities);
-

[Intel-gfx] [PATCH 2/3] drm/i915: Make object/vma allocation caches global

2019-02-27 Thread Chris Wilson

As our allocations are not device specific, we can move our slab caches
to a global scope.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gvt/dmabuf.c |  2 +-
 drivers/gpu/drm/i915/i915_drv.h   |  6 ---
 drivers/gpu/drm/i915/i915_gem.c   | 47 ++-
 drivers/gpu/drm/i915/i915_gem_context.c   | 35 +-
 drivers/gpu/drm/i915/i915_gem_context.h   |  8 
 drivers/gpu/drm/i915/i915_gem_dmabuf.c|  2 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c|  4 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c   |  2 +-
 drivers/gpu/drm/i915/i915_gem_internal.c  |  2 +-
 drivers/gpu/drm/i915/i915_gem_object.c| 34 ++
 drivers/gpu/drm/i915/i915_gem_object.h|  8 +++-
 drivers/gpu/drm/i915/i915_gem_stolen.c|  2 +-
 drivers/gpu/drm/i915/i915_gem_userptr.c   |  2 +-
 drivers/gpu/drm/i915/i915_globals.c   | 29 +++-
 drivers/gpu/drm/i915/i915_vma.c   | 43 ++---
 drivers/gpu/drm/i915/i915_vma.h   |  7 +++
 .../gpu/drm/i915/selftests/huge_gem_object.c  |  2 +-
 drivers/gpu/drm/i915/selftests/huge_pages.c   |  4 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |  2 +-
 .../gpu/drm/i915/selftests/mock_gem_device.c  | 15 --
 20 files changed, 170 insertions(+), 86 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c 
b/drivers/gpu/drm/i915/gvt/dmabuf.c
index 3e7e2b80c857..f27edf17b4ab 100644
--- a/drivers/gpu/drm/i915/gvt/dmabuf.c
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
@@ -153,7 +153,7 @@ static struct drm_i915_gem_object *vgpu_create_gem(struct 
drm_device *dev,
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_i915_gem_object *obj;
 
-   obj = i915_gem_object_alloc(dev_priv);
+   obj = i915_gem_object_alloc();
if (obj == NULL)
return NULL;
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f16016b330b3..35516089a3ff 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1470,10 +1470,6 @@ struct intel_cdclk_state {
 struct drm_i915_private {
struct drm_device drm;
 
-   struct kmem_cache *objects;
-   struct kmem_cache *vmas;
-   struct kmem_cache *luts;
-
const struct intel_device_info __info; /* Use INTEL_INFO() to access. */
struct intel_runtime_info __runtime; /* Use RUNTIME_INFO() to access. */
struct intel_driver_caps caps;
@@ -2802,8 +2798,6 @@ void i915_gem_load_init_fences(struct drm_i915_private 
*dev_priv);
 int i915_gem_freeze(struct drm_i915_private *dev_priv);
 int i915_gem_freeze_late(struct drm_i915_private *dev_priv);
 
-void *i915_gem_object_alloc(struct drm_i915_private *dev_priv);
-void i915_gem_object_free(struct drm_i915_gem_object *obj);
 void i915_gem_object_init(struct drm_i915_gem_object *obj,
 const struct drm_i915_gem_object_ops *ops);
 struct drm_i915_gem_object *
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 713ed6fbdcc8..8ded7e1756c9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -624,17 +624,6 @@ i915_gem_phys_pwrite(struct drm_i915_gem_object *obj,
return 0;
 }
 
-void *i915_gem_object_alloc(struct drm_i915_private *dev_priv)
-{
-   return kmem_cache_zalloc(dev_priv->objects, GFP_KERNEL);
-}
-
-void i915_gem_object_free(struct drm_i915_gem_object *obj)
-{
-   struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
-   kmem_cache_free(dev_priv->objects, obj);
-}
-
 static int
 i915_gem_create(struct drm_file *file,
struct drm_i915_private *dev_priv,
@@ -2895,10 +2884,6 @@ static void shrink_caches(struct drm_i915_private *i915)
 * filled slabs to prioritise allocating from the mostly full slabs,
 * with the aim of reducing fragmentation.
 */
-   kmem_cache_shrink(i915->luts);
-   kmem_cache_shrink(i915->vmas);
-   kmem_cache_shrink(i915->objects);
-
i915_globals_park();
 }
 
@@ -3094,7 +3079,7 @@ void i915_gem_close_object(struct drm_gem_object *gem, 
struct drm_file *file)
list_del(>obj_link);
list_del(>ctx_link);
 
-   kmem_cache_free(i915->luts, lut);
+   i915_lut_handle_free(lut);
__i915_gem_object_release_unless_active(obj);
}
 
@@ -4199,7 +4184,7 @@ i915_gem_object_create(struct drm_i915_private *dev_priv, 
u64 size)
if (overflows_type(size, obj->base.size))
return ERR_PTR(-E2BIG);
 
-   obj = i915_gem_object_alloc(dev_priv);
+   obj = i915_gem_object_alloc();
if (obj == NULL)
return ERR_PTR(-ENOMEM);
 
@@ -5223,19 +5208,7 @@ static void i915_gem_init__mm(struct drm_i915_private 
*i915)
 
 int i915_gem_init_early(struct drm_i915_private *dev_priv)
 {
-   int err = -ENOMEM;
-
-   dev_priv->objects =

[Intel-gfx] [PATCH 3/3] drm/i915: Remove second level open-coded rcu work

2019-02-27 Thread Chris Wilson

We currently use a worker queued from an rcu callback to determine when
a how grace period has elapsed while we remained idle. We use this idle
delay to infer that we will be idle for a while and this is a suitable
point at which we can trim our global memory caches.

Since we wrote that, this mechanism now exists as rcu_work, and having
converted the idle shrinkers over to using that, we can remove our own
variant.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 91 +
 1 file changed, 12 insertions(+), 79 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8ded7e1756c9..8cf3429594d5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -101,7 +101,7 @@ static void i915_gem_info_remove_obj(struct 
drm_i915_private *dev_priv,
spin_unlock(_priv->mm.object_stat_lock);
 }
 
-static u32 __i915_gem_park(struct drm_i915_private *i915)
+static void __i915_gem_park(struct drm_i915_private *i915)
 {
intel_wakeref_t wakeref;
 
@@ -112,7 +112,7 @@ static u32 __i915_gem_park(struct drm_i915_private *i915)
GEM_BUG_ON(!list_empty(>gt.active_rings));
 
if (!i915->gt.awake)
-   return I915_EPOCH_INVALID;
+   return;
 
GEM_BUG_ON(i915->gt.epoch == I915_EPOCH_INVALID);
 
@@ -143,7 +143,15 @@ static u32 __i915_gem_park(struct drm_i915_private *i915)
 
intel_display_power_put(i915, POWER_DOMAIN_GT_IRQ, wakeref);
 
-   return i915->gt.epoch;
+   /*
+* When we are idle, it is an opportune time to reap our caches.
+* However, we have many objects that utilise RCU and the ordered
+* i915->wq that this work is executing on. To try and flush any
+* pending frees now we are idle, we first wait for an RCU grace
+* period, and then queue a task (that will run last on the wq) to
+* shrink and re-optimize the caches.
+*/
+   i915_globals_park();
 }
 
 void i915_gem_park(struct drm_i915_private *i915)
@@ -2877,62 +2885,6 @@ i915_gem_retire_work_handler(struct work_struct *work)
   round_jiffies_up_relative(HZ));
 }
 
-static void shrink_caches(struct drm_i915_private *i915)
-{
-   /*
-* kmem_cache_shrink() discards empty slabs and reorders partially
-* filled slabs to prioritise allocating from the mostly full slabs,
-* with the aim of reducing fragmentation.
-*/
-   i915_globals_park();
-}
-
-struct sleep_rcu_work {
-   union {
-   struct rcu_head rcu;
-   struct work_struct work;
-   };
-   struct drm_i915_private *i915;
-   unsigned int epoch;
-};
-
-static inline bool
-same_epoch(struct drm_i915_private *i915, unsigned int epoch)
-{
-   /*
-* There is a small chance that the epoch wrapped since we started
-* sleeping. If we assume that epoch is at least a u32, then it will
-* take at least 2^32 * 100ms for it to wrap, or about 326 years.
-*/
-   return epoch == READ_ONCE(i915->gt.epoch);
-}
-
-static void __sleep_work(struct work_struct *work)
-{
-   struct sleep_rcu_work *s = container_of(work, typeof(*s), work);
-   struct drm_i915_private *i915 = s->i915;
-   unsigned int epoch = s->epoch;
-
-   kfree(s);
-   if (same_epoch(i915, epoch))
-   shrink_caches(i915);
-}
-
-static void __sleep_rcu(struct rcu_head *rcu)
-{
-   struct sleep_rcu_work *s = container_of(rcu, typeof(*s), rcu);
-   struct drm_i915_private *i915 = s->i915;
-
-   destroy_rcu_head(>rcu);
-
-   if (same_epoch(i915, s->epoch)) {
-   INIT_WORK(>work, __sleep_work);
-   queue_work(i915->wq, >work);
-   } else {
-   kfree(s);
-   }
-}
-
 static inline bool
 new_requests_since_last_retire(const struct drm_i915_private *i915)
 {
@@ -2961,7 +2913,6 @@ i915_gem_idle_work_handler(struct work_struct *work)
 {
struct drm_i915_private *dev_priv =
container_of(work, typeof(*dev_priv), gt.idle_work.work);
-   unsigned int epoch = I915_EPOCH_INVALID;
bool rearm_hangcheck;
 
if (!READ_ONCE(dev_priv->gt.awake))
@@ -3016,7 +2967,7 @@ i915_gem_idle_work_handler(struct work_struct *work)
if (new_requests_since_last_retire(dev_priv))
goto out_unlock;
 
-   epoch = __i915_gem_park(dev_priv);
+   __i915_gem_park(dev_priv);
 
assert_kernel_context_is_current(dev_priv);
 
@@ -3029,24 +2980,6 @@ i915_gem_idle_work_handler(struct work_struct *work)
GEM_BUG_ON(!dev_priv->gt.awake);
i915_queue_hangcheck(dev_priv);
}
-
-   /*
-* When we are idle, it is an opportune time to reap our caches.
-* However, we have many objects that utilise RCU and the ordered
-* i915->wq that this work is executing on. To try and flush any
-* pending

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: introduce REG_BIT() and REG_GENMASK() to define register contents

2019-02-27 Thread Michal Wajdeczko

On Wed, 27 Feb 2019 18:02:36 +0100, Jani Nikula   
wrote:



@@ -116,6 +116,34 @@
  *  #define GEN8_BAR_MMIO(0xb888)
  */
+/**
+ * REG_BIT() - Prepare a u32 bit value
+ * @__n: 0-based bit number
+ *
+ * Local wrapper for BIT() to force u32, with compile time checks.
+ *
+ * @return: Value with bit @__n set.
+ */
+#define REG_BIT(__n)   \
+   ((u32)(BIT(__n) +   \
+  BUILD_BUG_ON_ZERO(__builtin_constant_p(__n) &&   \
+((__n) < 0 || (__n) > 31


Maybe to simplify the code we can define this macro using macro below:

#define REG_BIT(__n) REG_GENMASK(__n, __n)


+
+/**
+ * REG_GENMASK() - Prepare a continuous u32 bitmask
+ * @__high: 0-based high bit
+ * @__low: 0-based low bit
+ *
+ * Local wrapper for GENMASK() to force u32, with compile time checks.
+ *
+ * @return: Continuous bitmask from @__high to @__low, inclusive.
+ */
+#define REG_GENMASK(__high, __low) \
+   ((u32)(GENMASK(__high, __low) + \
+  BUILD_BUG_ON_ZERO(__builtin_constant_p(__high) &&\
+__builtin_constant_p(__low) && \
+((__low) < 0 || (__high) > 31 || (__low) > 
(__high)
+


nit: Since we are defining new set of macros, do we really have to follow
naming of the underlying macros? maybe we can can have clear new names:

REG_BIT(n)
REG_BITS(hi,low)

Thanks,
Michal

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

[Intel-gfx] [PATCH 1/2] drm/i915: Fix atomic state leak when resetting HDMI link

2019-02-27 Thread José Roberto de Souza

Atomic state needs to be put even if the commit was successful.

Fixes: dba14b27dd3c ("drm/i915: Reinitialize sink scrambling/TMDS clock ratio 
on HPD")
Cc: Ville Syrjälä 
Cc: Lyude Paul 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_ddi.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index d918be927fc2..34dd5823398a 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3984,12 +3984,7 @@ static int modeset_pipe(struct drm_crtc *crtc,
goto out;
 
ret = drm_atomic_commit(state);
-   if (ret)
-   goto out;
-
-   return 0;
-
- out:
+out:
drm_atomic_state_put(state);
 
return ret;
-- 
2.21.0

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

[Intel-gfx] [PATCH 2/2] drm/i915: Don't manually add connectors and planes state

2019-02-27 Thread José Roberto de Souza

drm_atomic_commit() call chain already takes care of adding
connectors and planes, so lets no add then manually if not changing
their states.

Cc: Ville Syrjälä 
Cc: Lyude Paul 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_ddi.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 34dd5823398a..c22ddde2dfc1 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3975,14 +3975,6 @@ static int modeset_pipe(struct drm_crtc *crtc,
 
crtc_state->mode_changed = true;
 
-   ret = drm_atomic_add_affected_connectors(state, crtc);
-   if (ret)
-   goto out;
-
-   ret = drm_atomic_add_affected_planes(state, crtc);
-   if (ret)
-   goto out;
-
ret = drm_atomic_commit(state);
 out:
drm_atomic_state_put(state);
-- 
2.21.0

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915/icl: Default to Thread Group preemption for compute workloads

2019-02-27 Thread Anuj Phogat

Tested both the patches with drm-tip kernel. Fixes multiple gpu hangs
in vulkan cts and piglit. I will do more thorough testing with updated
version of these patches based on review.



On Wed, Feb 27, 2019 at 7:52 AM Michał Winiarski
 wrote:
>
> We assumed that the default preemption granularity is fine for ICL.
> Unfortunately, it turns out that some drivers don't support mid-thread
> preemption for compute workloads.
> If a workload that doesn't support mid-thread preemption gets mid-thread
> preempted, we're going to observe a GPU hang.
> While I'm here, let's also update the "workaround" naming.
>
> Signed-off-by: Michał Winiarski 
> Cc: Anuj Phogat 
> Cc: Joonas Lahtinen 
> Cc: Matt Roper 
> Cc: Rafael Antognolli 
> ---
>  drivers/gpu/drm/i915/intel_workarounds.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c 
> b/drivers/gpu/drm/i915/intel_workarounds.c
> index 743cf5b00155..a19e1c0052a7 100644
> --- a/drivers/gpu/drm/i915/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> @@ -555,6 +555,11 @@ static void icl_ctx_workarounds_init(struct 
> intel_engine_cs *engine)
>GEN10_CACHE_MODE_SS,
>0, /* write-only, so skip validation */
>
> _MASKED_BIT_ENABLE(FLOAT_BLEND_OPTIMIZATION_ENABLE));
> +
> +   /* WaDisableGPGPUMidThreadPreemption:icl */
> +   WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1,
> +   GEN9_PREEMPT_GPGPU_LEVEL_MASK,
> +   GEN9_PREEMPT_GPGPU_THREAD_GROUP_LEVEL);
>  }
>
>  void intel_engine_init_ctx_wa(struct intel_engine_cs *engine)
> @@ -1170,8 +1175,8 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, 
> struct i915_wa_list *wal)
> GEN7_DISABLE_SAMPLER_PREFETCH);
> }
>
> -   if (IS_GEN(i915, 9) || IS_CANNONLAKE(i915)) {
> -   /* 
> WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,cnl */
> +   if (IS_GEN_RANGE(i915, 9, 11)) {
> +   /* 
> FtrPerCtxtPreemptionGranularityControl:skl,bxt,kbl,cfl,cnl,icl */
> wa_masked_en(wal,
>  GEN7_FF_SLICE_CS_CHICKEN1,
>  GEN9_FFSC_PERCTX_PREEMPT_CTRL);
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] Revert "drm/i915: Avoid waking the engines just to check if they are idle" (rev2)

2019-02-27 Thread Patchwork

== Series Details ==

Series: series starting with [1/2] Revert "drm/i915: Avoid waking the engines 
just to check if they are idle" (rev2)
URL   : https://patchwork.freedesktop.org/series/57311/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5666 -> Patchwork_12321


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/57311/revisions/2/

Known issues


  Here are the changes found in Patchwork_12321 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850:   PASS -> INCOMPLETE [fdo#107718]

  * igt@i915_selftest@live_contexts:
- fi-icl-u2:  NOTRUN -> DMESG-FAIL [fdo#108569]

  * igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]

  
 Possible fixes 

  * igt@i915_selftest@live_requests:
- fi-icl-u2:  INCOMPLETE [fdo#109644] -> PASS

  * igt@prime_vgem@basic-fence-flip:
- fi-gdg-551: FAIL [fdo#103182] -> PASS

  
  [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#109644]: https://bugs.freedesktop.org/show_bug.cgi?id=109644


Participating hosts (44 -> 35)
--

  Missing(9): fi-hsw-4770r fi-ilk-m540 fi-hsw-4200u fi-byt-squawks 
fi-bsw-cyan fi-snb-2520m fi-ctg-p8600 fi-pnv-d510 fi-icl-y 


Build changes
-

* Linux: CI_DRM_5666 -> Patchwork_12321

  CI_DRM_5666: 358ab8acaabef3cef2a7ce9e5dd7c4196a0c30fc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4860: b79007f9c575a538a63ce9301a890ed9e1a45f35 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12321: 576b1db10eddf8a19e936787f5fc22e83aecd631 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

576b1db10edd drm/i915: Report engines are idle if already parked
35705bcdfb67 Revert "drm/i915: Avoid waking the engines just to check if they 
are idle"

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12321/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Wake up next in drm_read() chain if we are forced to putback the event

2019-02-27 Thread Chris Wilson

Quoting Chris Wilson (2019-02-27 10:17:15)
> Quoting Daniel Vetter (2017-08-07 10:28:58)
> > On Fri, Aug 04, 2017 at 09:23:28AM +0100, Chris Wilson wrote:
> > > After an event is sent, we try to copy it into the user buffer of the
> > > first waiter in drm_read() and if the user buffer doesn't have enough
> > > room we put it back onto the list. However, we didn't wake up any
> > > subsequent waiter, so that event may sit on the list until either a new
> > > vblank event is sent or a new waiter appears. Rare, but in the worst
> > > case may lead to a stuck process.
> > > 
> > > Signed-off-by: Chris Wilson 
> > > Cc: Daniel Vetter 
> > 
> > New subtestcase in igt@drm_read?
> 
> Caught it!
> Testcase: igt/drm_read/short-buffer-wakeup

And pushed with Ville's irc r-b.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] Revert "drm/i915: Avoid waking the engines just to check if they are idle" (rev2)

2019-02-27 Thread Patchwork

== Series Details ==

Series: series starting with [1/2] Revert "drm/i915: Avoid waking the engines 
just to check if they are idle" (rev2)
URL   : https://patchwork.freedesktop.org/series/57311/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
35705bcdfb67 Revert "drm/i915: Avoid waking the engines just to check if they 
are idle"
576b1db10edd drm/i915: Report engines are idle if already parked
-:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#11: 
References: 0b702dca2658 ("drm/i915: Avoid waking the engines just to check if 
they are idle")

-:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 0b702dca2658 ("drm/i915: Avoid 
waking the engines just to check if they are idle")'
#11: 
References: 0b702dca2658 ("drm/i915: Avoid waking the engines just to check if 
they are idle")

total: 1 errors, 1 warnings, 0 checks, 24 lines checked

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] Revert "drm/i915: Avoid waking the engines just to check if they are idle"

2019-02-27 Thread Patchwork

== Series Details ==

Series: series starting with [1/2] Revert "drm/i915: Avoid waking the engines 
just to check if they are idle"
URL   : https://patchwork.freedesktop.org/series/57311/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5666 -> Patchwork_12320


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/57311/revisions/1/

Known issues


  Here are the changes found in Patchwork_12320 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_contexts:
- fi-icl-u2:  NOTRUN -> DMESG-FAIL [fdo#108569]

  * igt@kms_busy@basic-flip-a:
- fi-gdg-551: PASS -> FAIL [fdo#103182]

  * igt@kms_psr@primary_mmap_gtt:
- fi-blb-e6850:   NOTRUN -> SKIP [fdo#109271] +27

  
 Possible fixes 

  * igt@i915_selftest@live_requests:
- fi-icl-u2:  INCOMPLETE [fdo#109644] -> PASS

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850:   INCOMPLETE [fdo#107718] -> PASS

  * igt@prime_vgem@basic-fence-flip:
- fi-gdg-551: FAIL [fdo#103182] -> PASS

  
  [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109644]: https://bugs.freedesktop.org/show_bug.cgi?id=109644


Participating hosts (44 -> 38)
--

  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 fi-icl-u3 


Build changes
-

* Linux: CI_DRM_5666 -> Patchwork_12320

  CI_DRM_5666: 358ab8acaabef3cef2a7ce9e5dd7c4196a0c30fc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4860: b79007f9c575a538a63ce9301a890ed9e1a45f35 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12320: 644e77c6b75e2528e3f6ce75266f1afd7a1175ff @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

644e77c6b75e drm/i915: Report engines are idle if already parked
74f5ddaa45e2 Revert "drm/i915: Avoid waking the engines just to check if they 
are idle"

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12320/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Report engines are idle if already parked

2019-02-27 Thread Chris Wilson

If we have parked, then we must have passed an idleness test and still
be idle. We chose not to use this shortcut in the past so that we could
use the idleness test at any time and inspect HW. However, some HW like
Sandybridge, doesn't like being woken up frivolously, so avoid doing so.

References: 0b702dca2658 ("drm/i915: Avoid waking the engines just to check if 
they are idle")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index b7b626195eda..96a38f411bc7 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1033,7 +1033,7 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
return ring_is_idle(engine);
 }
 
-bool intel_engines_are_idle(struct drm_i915_private *dev_priv)
+bool intel_engines_are_idle(struct drm_i915_private *i915)
 {
struct intel_engine_cs *engine;
enum intel_engine_id id;
@@ -1042,10 +1042,14 @@ bool intel_engines_are_idle(struct drm_i915_private 
*dev_priv)
 * If the driver is wedged, HW state may be very inconsistent and
 * report that it is still busy, even though we have stopped using it.
 */
-   if (i915_reset_failed(dev_priv))
+   if (i915_reset_failed(i915))
return true;
 
-   for_each_engine(engine, dev_priv, id) {
+   /* Already parked (and passed an idleness test); must still be idle */
+   if (!READ_ONCE(i915->gt.awake))
+   return true;
+
+   for_each_engine(engine, i915, id) {
if (!intel_engine_is_idle(engine))
return false;
}
-- 
2.20.1

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] Revert "drm/i915: Avoid waking the engines just to check if they are idle"

2019-02-27 Thread Patchwork

== Series Details ==

Series: series starting with [1/2] Revert "drm/i915: Avoid waking the engines 
just to check if they are idle"
URL   : https://patchwork.freedesktop.org/series/57311/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
74f5ddaa45e2 Revert "drm/i915: Avoid waking the engines just to check if they 
are idle"
644e77c6b75e drm/i915: Report engines are idle if already parked
-:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#11: 
References: 0b702dca2658 ("drm/i915: Avoid waking the engines just to check if 
they are idle")

-:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 0b702dca2658 ("drm/i915: Avoid 
waking the engines just to check if they are idle")'
#11: 
References: 0b702dca2658 ("drm/i915: Avoid waking the engines just to check if 
they are idle")

total: 1 errors, 1 warnings, 0 checks, 10 lines checked

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

Re: [Intel-gfx] [PATCH i-g-t] lib: Incrementally mlock()

2019-02-27 Thread Chris Wilson

Quoting Caz Yokoyama (2019-02-27 17:34:57)
> inline.
> 
> v2 patches fixes
> - address calculation bug
> - not killed
> However, the test does not runs faster.

Fair enough, I expected some improvement from the incremental and
avoiding the second mlock + populate of a large region, but if it's not
significant, then let's just make oomkiller faster ;)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: introduce REG_BIT() and REG_GENMASK() to define register contents

2019-02-27 Thread Ville Syrjälä

On Wed, Feb 27, 2019 at 08:50:31PM +, Chris Wilson wrote:
> Quoting Jani Nikula (2019-02-27 17:02:36)

> >  #define  PP_REFERENCE_DIVIDER_SHIFT8
> > -#define  PANEL_POWER_CYCLE_DELAY_MASK  0x1f
> > +#define  PANEL_POWER_CYCLE_DELAY_MASK  REG_GENMASK(4, 0)
> 
> Ok.
> 
> I'll get used to the hi,lo convention eventually.

The nice thing is that it matches the spec.

The hard part is running out of fingers for wide bitfields :P

-- 
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 3/3] drm/i915: use REG_FIELD_PREP() to define register bitfield values

2019-02-27 Thread Ville Syrjälä

On Wed, Feb 27, 2019 at 07:02:38PM +0200, Jani Nikula wrote:
> Slightly verbose, but does away with hand rolled shifts. Ties the field
> values with the mask defining the field.
> 
> Unfortunately we have to make a local copy of FIELD_PREP() to evaluate
> to a integer constant expression. But with this, we can ensure the mask
> is non-zero, power of 2, fits u32, and the value fits the mask (when the
> value is a constant expression).

I might like a debug knob to make that into a runtime check for
non-const expressions. But that can be considered later.

-- 
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 3/3] drm/i915: use REG_FIELD_PREP() to define register bitfield values

2019-02-27 Thread Chris Wilson

Quoting Jani Nikula (2019-02-27 17:02:38)
> Slightly verbose, but does away with hand rolled shifts. Ties the field
> values with the mask defining the field.
> 
> Unfortunately we have to make a local copy of FIELD_PREP() to evaluate
> to a integer constant expression. But with this, we can ensure the mask
> is non-zero, power of 2, fits u32, and the value fits the mask (when the
> value is a constant expression).
> 
> Convert power sequencer registers as an example.
> 
> v3:
> - rename the macro to REG_FIELD_PREP to avoid underscore prefix and to
>   be in line with kernel macros (Chris)
> - rename power of 2 check macro (Chris)
> 
> v2:
>  - add build-time checks with BUILD_BUG_ON_ZERO()
>  - rename to just _FIELD() due to regmap.h REG_FIELD() clash
> 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Michal Wajdeczko 
> Cc: Mika Kuoppala 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 69 +++--
>  1 file changed, 39 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 1bd75770483a..70b7c5f0777b 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -62,11 +62,11 @@
>   * significant to least significant bit. Indent the register content macros
>   * using two extra spaces between ``#define`` and the macro name.
>   *
> - * Define bit fields using ``REG_GENMASK(h, l)``. Define bit field contents 
> so
> - * that they are already shifted in place, and can be directly OR'd. For
> - * convenience, function-like macros may be used to define bit fields, but do
> - * note that the macros may be needed to read as well as write the register
> - * contents.
> + * Define bit fields using ``REG_GENMASK(h, l)``. Define bit field contents
> + * using ``REG_FIELD_PREP(mask, value)``. This will define the values already
> + * shifted in place, so they can be directly OR'd together. For convenience,
> + * function-like macros may be used to define bit fields, but do note that 
> the
> + * macros may be needed to read as well as write the register contents.
>   *
>   * Define bits using ``REG_BIT(N)``. Do **not** add ``_BIT`` suffix to the 
> name.
>   *
> @@ -108,9 +108,9 @@
>   *  #define FOO(pipe)   _MMIO_PIPE(pipe, _FOO_A, _FOO_B)
>   *  #define   FOO_ENABLEREG_BIT(31)
>   *  #define   FOO_MODE_MASK REG_GENMASK(19, 16)
> - *  #define   FOO_MODE_BAR  (0 << 16)
> - *  #define   FOO_MODE_BAZ  (1 << 16)
> - *  #define   FOO_MODE_QUX_SNB  (2 << 16)
> + *  #define   FOO_MODE_BAR  REG_FIELD_PREP(FOO_MODE_MASK, 0)
> + *  #define   FOO_MODE_BAZ  REG_FIELD_PREP(FOO_MODE_MASK, 1)
> + *  #define   FOO_MODE_QUX_SNB  REG_FIELD_PREP(FOO_MODE_MASK, 2)
>   *
>   *  #define BAR _MMIO(0xb000)
>   *  #define GEN8_BAR_MMIO(0xb888)
> @@ -144,17 +144,27 @@
>  __builtin_constant_p(__low) && \
>  ((__low) < 0 || (__high) > 31 || (__low) > 
> (__high)
>  
> +/*
> + * Local integer constant expression version of is_power_of_2().
> + */
> +#define IS_POWER_OF_2(__x) ((__x) && (((__x) & ((__x) - 1)) == 
> 0))

There's definitely something to be said about linux/build_bug.h not providing
this.

>  /**
>   * REG_FIELD_PREP() - Prepare a u32 bitfield value
>   * @__mask: shifted mask defining the field's length and position
>   * @__val: value to put in the field
>  
> - * Local wrapper for FIELD_PREP() to force u32 and for consistency with
> - * REG_FIELD_GET(), REG_BIT() and REG_GENMASK().
> + * Local copy of FIELD_PREP() to generate an integer constant expression, 
> force
> + * u32 and for consistency with REG_FIELD_GET(), REG_BIT() and REG_GENMASK().
>   *
>   * @return: @__val masked and shifted into the field defined by @__mask.
>   */
> -#define REG_FIELD_PREP(__mask, __val)  ((u32)FIELD_PREP(__mask, __val))
> +#define REG_FIELD_PREP(__mask, __val)
>   \
> +   ((u32)typeof(__mask))(__val) << __bf_shf(__mask)) & (__mask)) +   
>   \
> +  BUILD_BUG_ON_ZERO(!__builtin_constant_p(__mask)) + 
>   \
> +  BUILD_BUG_ON_ZERO((__mask) == 0 || (__mask) > U32_MAX) +   
>   \
> +  BUILD_BUG_ON_ZERO(!IS_POWER_OF_2((__mask) + (1ULL << 
> __bf_shf(__mask + \

Take 0xff0 and add 0x10 to make 0x100!

So each field must be a conjoint set of bits.

> +  
> BUILD_BUG_ON_ZERO(__builtin_choose_expr(__builtin_constant_p(__val), 
> (~((__mask) >> __bf_shf(__mask)) & (__val)), 0

If val is constant, check that val is within the range of mask;
otherwise skip the test rather than do it at runtime.

Hmm. I'd like a debug option to always check. That'll probably take just
a bit more ifdeffry, but if it catches just one bug, worth it?

>   * REG_FIELD_GET() -

[Intel-gfx] [PATCH 1/2] Revert "drm/i915: Avoid waking the engines just to check if they are idle"

2019-02-27 Thread Chris Wilson

This reverts commit 0b702dca26580e3bbfbbaf22dfc29280b6263414.

CI reports that this is not as reliable as it first appears, with
failures starting to sporadically occur in selftests.

Fixes: 0b702dca2658 ("drm/i915: Avoid waking the engines just to check if they 
are idle")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 4f244019560d..b7b626195eda 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -968,7 +968,6 @@ static bool ring_is_idle(struct intel_engine_cs *engine)
 {
struct drm_i915_private *dev_priv = engine->i915;
intel_wakeref_t wakeref;
-   unsigned long flags;
bool idle = true;
 
if (I915_SELFTEST_ONLY(!engine->mmio_base))
@@ -979,19 +978,15 @@ static bool ring_is_idle(struct intel_engine_cs *engine)
if (!wakeref)
return true;
 
-   spin_lock_irqsave(_priv->uncore.lock, flags);
+   /* First check that no commands are left in the ring */
+   if ((I915_READ_HEAD(engine) & HEAD_ADDR) !=
+   (I915_READ_TAIL(engine) & TAIL_ADDR))
+   idle = false;
 
-   /*
-* Check that no commands are left in the ring.
-*
-* If the engine is not awake, both reads return 0 as we do so without
-* forcewake.
-*/
-   if ((I915_READ_FW(RING_HEAD(engine->mmio_base)) & HEAD_ADDR) !=
-   (I915_READ_FW(RING_TAIL(engine->mmio_base)) & TAIL_ADDR))
+   /* No bit for gen2, so assume the CS parser is idle */
+   if (INTEL_GEN(dev_priv) > 2 && !(I915_READ_MODE(engine) & MODE_IDLE))
idle = false;
 
-   spin_unlock_irqrestore(_priv->uncore.lock, flags);
intel_runtime_pm_put(dev_priv, wakeref);
 
return idle;
-- 
2.20.1

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

Re: [Intel-gfx] [PATCH 1/2] drm/edid: If no preferred mode is found assume the first mode is preferred

2019-02-27 Thread Ville Syrjälä

On Wed, Feb 27, 2019 at 03:23:01PM -0500, Adam Jackson wrote:
> On Wed, 2019-02-27 at 19:14 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Some monitors apparently forget to mark any mode as preferred in the
> > EDID. In this particular case we have a very generic looking ID
> > "PNP Model 0 Serial Number 4" / "LVDS 800x600" so a specific quirk
> > doesn't seem particularly wise. Also the quirk we have
> > (EDID_QUIRK_FIRST_DETAILED_PREFERRED) is actually defunct so we'd
> > have to fix it first.
> >
> > As a generic fallback let's just mark the first probed mode (which
> > should be the first detailed mode, assuming there are any) as
> > preferred.
> 
> What problem is this trying to fix? Userspace (and drm for that matter)
> is typically going to pick the first mode in the list anyway if there's
> none marked as preferred. Not having any preferred modes was pretty
> common on CRTs IIRC.

Ah sorry, I forgot to mention the original symptoms. The problem is
that with no preferred mode i915 decided to get the fixed mode for
the panel from the VBT instead. That one turned out to be 1024x768
which made the 800x600 panel somewhat unhappy.

So instead of putting this logic into the EDID parser I guess we
could just put it into the i915 fixed mode code. But then I suppose
we should also fix EDID_QUIRK_FIRST_DETAILED_PREFERRED (assuming it
exists for a good reason).

> 
> The other major case I've seen of a monitor with no preferred mode are
> the early dual-link DVI displays without internal scalers (Apple
> Cinema, Dell 3007WFP, etc). You end up with 1280x800 first in the list
> since 2560x1600 doesn't fit in a single DVI link. It might be nice if
> such monitors decided their preferred mode based on the link
> capabilities; if you know it's a dual-link capable port, you'd probably
> prefer 2560x1600.
> 
> Does it make more sense to run the "infer a preferred mode" logic after
> we've done mode validation for the output?

For this particular case that wouldn't help since then we'd end up
picking the 800x600 75Hz EST mode. Well, I'm not sure whether the
panel would like that or not. The VBIOS at least selects the 800x600
60Hz EST mode for whatever reason.

-- 
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 2/3] drm/i915: deprecate _SHIFT in favor of _MASK passed to accessors

2019-02-27 Thread Chris Wilson

Quoting Jani Nikula (2019-02-27 17:02:37)
> bitfield.h defines FIELD_GET() and FIELD_PREP() macros to access
> bitfields using the mask alone, with no need for separate shift. Indeed,
> the shift is redundant.
> 
> We define REG_FIELD_GET() and REG_FIELD_PREP() wrappers for the above,
> in part to force u32 and for consistency with REG_BIT() and
> REG_GENMASK(), but also as we'll need to redefine REG_FIELD_PREP() in
> follow-up work to make it produce integer constant expressions.
> 
> For the most part, REG_FIELD_GET() is shorter than masking followed by
> shift, and arguably has more clarity.
> 
> REG_FIELD_PREP() can get more verbose than simply shifting in place, but
> it does provide masking to ensure we don't overflow the mask, something
> we usually don't bother with currently.
> 
> Convert power sequencer registers as an example.
> 
> v2:
> - Add the REG_FIELD_GET() and REG_FIELD_PREP() wrappers to use them
>   consistently from the start.
> 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Michal Wajdeczko 
> Cc: Mika Kuoppala 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/i915_reg.h   | 45 ---
>  drivers/gpu/drm/i915/intel_dp.c   | 40 +++
>  drivers/gpu/drm/i915/intel_lvds.c | 40 +--
>  3 files changed, 64 insertions(+), 61 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index e847a18067bc..1bd75770483a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -25,6 +25,7 @@
>  #ifndef _I915_REG_H_
>  #define _I915_REG_H_
>  
> +#include 
>  #include 
>  
>  /**
> @@ -61,11 +62,11 @@
>   * significant to least significant bit. Indent the register content macros
>   * using two extra spaces between ``#define`` and the macro name.
>   *
> - * For bit fields, define a ``_MASK`` and a ``_SHIFT`` macro. Use
> - * ``REG_GENMASK()`` to define _MASK. Define bit field contents so that they 
> are
> - * already shifted in place, and can be directly OR'd. For convenience,
> - * function-like macros may be used to define bit fields, but do note that 
> the
> - * macros may be needed to read as well as write the register contents.
> + * Define bit fields using ``REG_GENMASK(h, l)``. Define bit field contents 
> so
> + * that they are already shifted in place, and can be directly OR'd. For
> + * convenience, function-like macros may be used to define bit fields, but do
> + * note that the macros may be needed to read as well as write the register
> + * contents.
>   *
>   * Define bits using ``REG_BIT(N)``. Do **not** add ``_BIT`` suffix to the 
> name.
>   *
> @@ -107,7 +108,6 @@
>   *  #define FOO(pipe)   _MMIO_PIPE(pipe, _FOO_A, _FOO_B)
>   *  #define   FOO_ENABLEREG_BIT(31)
>   *  #define   FOO_MODE_MASK REG_GENMASK(19, 16)
> - *  #define   FOO_MODE_SHIFT16
>   *  #define   FOO_MODE_BAR  (0 << 16)
>   *  #define   FOO_MODE_BAZ  (1 << 16)
>   *  #define   FOO_MODE_QUX_SNB  (2 << 16)
> @@ -144,6 +144,30 @@
>  __builtin_constant_p(__low) && \
>  ((__low) < 0 || (__high) > 31 || (__low) > 
> (__high)
>  
> +/**
> + * REG_FIELD_PREP() - Prepare a u32 bitfield value
> + * @__mask: shifted mask defining the field's length and position
> + * @__val: value to put in the field
> +
> + * Local wrapper for FIELD_PREP() to force u32 and for consistency with
> + * REG_FIELD_GET(), REG_BIT() and REG_GENMASK().
> + *
> + * @return: @__val masked and shifted into the field defined by @__mask.
> + */
> +#define REG_FIELD_PREP(__mask, __val)  ((u32)FIELD_PREP(__mask, __val))
> +
> +/**
> + * REG_FIELD_GET() - Extract a u32 bitfield value
> + * @__mask: shifted mask defining the field's length and position
> + * @__val: value to extract the bitfield value from
> + *
> + * Local wrapper for FIELD_GET() to force u32 and for consistency with
> + * REG_FIELD_PREP(), REG_BIT() and REG_GENMASK().
> + *
> + * @return: Masked and shifted value of the field defined by @__mask in 
> @__val.
> + */
> +#define REG_FIELD_GET(__mask, __val)   ((u32)FIELD_GET(__mask, __val))

I think I prefer the REG_FIELD variants already. Let's see how they work
in practice.

>  typedef struct {
> u32 reg;
>  } i915_reg_t;
> @@ -4726,7 +4750,6 @@ enum {
>  #define ICP_PP_CONTROL(x)  _MMIO(((x) == 1) ? _PP_CONTROL_1 : \
>   _PP_CONTROL_2)
>  #define  POWER_CYCLE_DELAY_MASKREG_GENMASK(8, 4)
> -#define  POWER_CYCLE_DELAY_SHIFT   4
>  #define  VDD_OVERRIDE_FORCEREG_BIT(3)
>  #define  BACKLIGHT_ENABLE  REG_BIT(2)
>  #define  PWR_DOWN_ON_RESET REG_BIT(1)
> @@ -4743,7 +4766,6 @@ enum {
>  #define   PP_SEQUENCE_NONE (0 << 28)
>  #define   PP_SEQUENCE_POWER_UP (1 << 28)
>  #define

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: introduce REG_BIT() and REG_GENMASK() to define register contents

2019-02-27 Thread Chris Wilson

Quoting Jani Nikula (2019-02-27 17:02:36)
> Introduce REG_BIT(n) to define register bits and REG_GENMASK(h, l) to
> define register bitfield masks.
> 
> We define the above as wrappers to BIT() and GENMASK() respectively to
> force u32 type to go with our register size, and to add compile time
> checks on the bit numbers.
> 
> The intention is that these are easier to get right and review against
> the spec than hand rolled masks.
> 
> Convert power sequencer registers as an example.
> 
> v3:
> - rename macros to REG_BIT() and REG_GENMASK() to avoid underscore
>   prefix and to be in line with kernel macros (Chris)
> - add compile time checks (Mika)
> 
> v2:
> - rename macros to just _BIT() and _MASK() to reduce verbosity
> 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Michal Wajdeczko 
> Cc: Mika Kuoppala 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 94 +
>  1 file changed, 61 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index c9b482bc6433..e847a18067bc 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -25,6 +25,8 @@
>  #ifndef _I915_REG_H_
>  #define _I915_REG_H_
>  
> +#include 
> +
>  /**
>   * DOC: The i915 register macro definition style guide
>   *
> @@ -59,15 +61,13 @@
>   * significant to least significant bit. Indent the register content macros
>   * using two extra spaces between ``#define`` and the macro name.
>   *
> - * For bit fields, define a ``_MASK`` and a ``_SHIFT`` macro. Define bit 
> field
> - * contents so that they are already shifted in place, and can be directly
> - * OR'd. For convenience, function-like macros may be used to define bit 
> fields,
> - * but do note that the macros may be needed to read as well as write the
> - * register contents.
> + * For bit fields, define a ``_MASK`` and a ``_SHIFT`` macro. Use
> + * ``REG_GENMASK()`` to define _MASK. Define bit field contents so that they 
> are
> + * already shifted in place, and can be directly OR'd. For convenience,
> + * function-like macros may be used to define bit fields, but do note that 
> the
> + * macros may be needed to read as well as write the register contents.
>   *
> - * Define bits using ``(1 << N)`` instead of ``BIT(N)``. We may change this 
> in
> - * the future, but this is the prevailing style. Do **not** add ``_BIT`` 
> suffix
> - * to the name.
> + * Define bits using ``REG_BIT(N)``. Do **not** add ``_BIT`` suffix to the 
> name.
>   *
>   * Group the register and its contents together without blank lines, separate
>   * from other registers and their contents with one blank line.
> @@ -105,8 +105,8 @@
>   *  #define _FOO_A  0xf000
>   *  #define _FOO_B  0xf001
>   *  #define FOO(pipe)   _MMIO_PIPE(pipe, _FOO_A, _FOO_B)
> - *  #define   FOO_ENABLE(1 << 31)
> - *  #define   FOO_MODE_MASK (0xf << 16)
> + *  #define   FOO_ENABLEREG_BIT(31)
> + *  #define   FOO_MODE_MASK REG_GENMASK(19, 16)
>   *  #define   FOO_MODE_SHIFT16
>   *  #define   FOO_MODE_BAR  (0 << 16)
>   *  #define   FOO_MODE_BAZ  (1 << 16)
> @@ -116,6 +116,34 @@
>   *  #define GEN8_BAR_MMIO(0xb888)
>   */
>  
> +/**
> + * REG_BIT() - Prepare a u32 bit value
> + * @__n: 0-based bit number
> + *
> + * Local wrapper for BIT() to force u32, with compile time checks.
> + *
> + * @return: Value with bit @__n set.
> + */
> +#define REG_BIT(__n)   \
> +   ((u32)(BIT(__n) +   \
> +  BUILD_BUG_ON_ZERO(__builtin_constant_p(__n) &&   \
> +((__n) < 0 || (__n) > 31
> +
> +/**
> + * REG_GENMASK() - Prepare a continuous u32 bitmask
> + * @__high: 0-based high bit
> + * @__low: 0-based low bit
> + *
> + * Local wrapper for GENMASK() to force u32, with compile time checks.
> + *
> + * @return: Continuous bitmask from @__high to @__low, inclusive.
> + */
> +#define REG_GENMASK(__high, __low) \
> +   ((u32)(GENMASK(__high, __low) + \
> +  BUILD_BUG_ON_ZERO(__builtin_constant_p(__high) &&\
> +__builtin_constant_p(__low) && \
> +((__low) < 0 || (__high) > 31 || (__low) > 
> (__high)
> +
>  typedef struct {
> u32 reg;
>  } i915_reg_t;
> @@ -4691,18 +4719,18 @@ enum {
>  
>  #define _PP_STATUS 0x61200
>  #define PP_STATUS(pps_idx) _MMIO_PPS(pps_idx, _PP_STATUS)
> -#define   PP_ON(1 << 31)
> +#define   PP_ONREG_BIT(31)

Ok.

>  
>  #define _PP_CONTROL_1  0xc7204
>  #define _PP_CONTROL_2

[Intel-gfx] [PATCH 2/2] drm/i915: Report engines are idle if already parked

2019-02-27 Thread Chris Wilson

If we have parked, then we must have passed an idleness test and still
be idle. We chose not to use this shortcut in the past so that we could
use the idleness test at any time and inspect HW, however some HW like
Sandybridge doesn't like being woken up frivolously so avoid doing so.

References: 0b702dca2658 ("drm/i915: Avoid waking the engines just to check if 
they are idle")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index b7b626195eda..7160162ae128 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1045,6 +1045,10 @@ bool intel_engines_are_idle(struct drm_i915_private 
*dev_priv)
if (i915_reset_failed(dev_priv))
return true;
 
+   /* Already parked (and passed an idleness test); must still be idle */
+   if (!READ_ONCE(dev_priv->gt.awake))
+   return true;
+
for_each_engine(engine, dev_priv, id) {
if (!intel_engine_is_idle(engine))
return false;
-- 
2.20.1

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

Re: [Intel-gfx] [PATCH 1/2] drm/edid: If no preferred mode is found assume the first mode is preferred

2019-02-27 Thread Adam Jackson

On Wed, 2019-02-27 at 19:14 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Some monitors apparently forget to mark any mode as preferred in the
> EDID. In this particular case we have a very generic looking ID
> "PNP Model 0 Serial Number 4" / "LVDS 800x600" so a specific quirk
> doesn't seem particularly wise. Also the quirk we have
> (EDID_QUIRK_FIRST_DETAILED_PREFERRED) is actually defunct so we'd
> have to fix it first.
>
> As a generic fallback let's just mark the first probed mode (which
> should be the first detailed mode, assuming there are any) as
> preferred.

What problem is this trying to fix? Userspace (and drm for that matter)
is typically going to pick the first mode in the list anyway if there's
none marked as preferred. Not having any preferred modes was pretty
common on CRTs IIRC.

The other major case I've seen of a monitor with no preferred mode are
the early dual-link DVI displays without internal scalers (Apple
Cinema, Dell 3007WFP, etc). You end up with 1280x800 first in the list
since 2560x1600 doesn't fit in a single DVI link. It might be nice if
such monitors decided their preferred mode based on the link
capabilities; if you know it's a dual-link capable port, you'd probably
prefer 2560x1600.

Does it make more sense to run the "infer a preferred mode" logic after
we've done mode validation for the output?

- ajax

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: introduce macros to define register contents (rev3)

2019-02-27 Thread Patchwork

== Series Details ==

Series: drm/i915: introduce macros to define register contents (rev3)
URL   : https://patchwork.freedesktop.org/series/50513/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5666_full -> Patchwork_12317_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_12317_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_bad_reloc@negative-reloc-bsd2:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] +7

  * igt@gem_exec_params@no-vebox:
- shard-iclb: NOTRUN -> SKIP [fdo#109283]

  * igt@gem_exec_suspend@basic-s3:
- shard-skl:  PASS -> INCOMPLETE [fdo#104108] / [fdo#107773]

  * igt@gem_pwrite@huge-gtt-forwards:
- shard-iclb: NOTRUN -> SKIP [fdo#109290]

  * igt@gem_unref_active_buffers:
- shard-apl:  PASS -> INCOMPLETE [fdo#103927]

  * igt@i915_pm_rpm@cursor-dpms:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +4

  * igt@i915_pm_rpm@modeset-lpsp-stress:
- shard-iclb: PASS -> INCOMPLETE [fdo#108840]

  * igt@i915_query@query-topology-known-pci-ids:
- shard-iclb: NOTRUN -> SKIP [fdo#109303]

  * igt@kms_busy@extended-modeset-hang-newfb-render-b:
- shard-skl:  PASS -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-hsw:  PASS -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-modeset-hang-oldfb-render-d:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +5

  * igt@kms_busy@extended-modeset-hang-oldfb-render-e:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +4

  * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956]
- shard-apl:  PASS -> DMESG-WARN [fdo#107956]

  * igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-iclb: NOTRUN -> FAIL [fdo#107725] +1

  * igt@kms_ccs@pipe-c-missing-ccs-buffer:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] +21

  * igt@kms_chamelium@hdmi-edid-read:
- shard-iclb: NOTRUN -> SKIP [fdo#109284] +1

  * igt@kms_color@pipe-b-degamma:
- shard-apl:  PASS -> FAIL [fdo#104782]

  * igt@kms_concurrent@pipe-f:
- shard-iclb: NOTRUN -> SKIP [fdo#109278] +1

  * igt@kms_cursor_crc@cursor-128x128-dpms:
- shard-iclb: NOTRUN -> FAIL [fdo#103232]

  * igt@kms_cursor_crc@cursor-256x85-sliding:
- shard-apl:  NOTRUN -> FAIL [fdo#103232] +1

  * igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-skl:  PASS -> FAIL [fdo#103191] / [fdo#103232]

  * igt@kms_cursor_legacy@cursora-vs-flipb-legacy:
- shard-iclb: NOTRUN -> SKIP [fdo#109274] +1

  * igt@kms_fbcon_fbt@fbc:
- shard-iclb: PASS -> DMESG-WARN [fdo#109593]

  * igt@kms_fbcon_fbt@fbc-suspend:
- shard-iclb: PASS -> INCOMPLETE [fdo#107713]

  * igt@kms_flip@2x-plain-flip-ts-check-interruptible:
- shard-glk:  PASS -> FAIL [fdo#100368]

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl:  PASS -> FAIL [fdo#105363]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
- shard-glk:  PASS -> FAIL [fdo#103167] +1

  * igt@kms_frontbuffer_tracking@fbc-badstride:
- shard-skl:  PASS -> FAIL [fdo#105682] +1

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-wc:
- shard-iclb: PASS -> FAIL [fdo#103167] +3

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-pri-shrfb-draw-mmap-gtt:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] +8

  * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-wc:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] +59

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-shrfb-pgflip-blt:
- shard-skl:  PASS -> FAIL [fdo#103167] +1

  * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-cur-indfb-move:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] +68

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-skl:  PASS -> FAIL [fdo#103166] +1

  * igt@kms_plane@plane-position-covered-pipe-b-planes:
- shard-iclb: PASS -> FAIL [fdo#103166] +1

  * igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-skl:  NOTRUN -> FAIL [fdo#108145] +2

  * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl:  PASS -> FAIL [fdo#107815] / [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-c-alpha-7efc:
- shard-kbl:  NOTRUN -> FAIL [fdo#108145] / [fdo#108590]

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
- shard-kbl:  NOTRUN -> FAIL [fdo#108145]

  * igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-apl:  PASS -> FAIL [fdo#103166]

  * igt@kms_psr@psr2_primary_mmap_cpu:

Re: [Intel-gfx] [PATCH] drm: prefix header search paths with $(srctree)/

2019-02-27 Thread Sam Ravnborg

Hi Masahiro.

On Thu, Jan 31, 2019 at 12:56:39PM +0900, Masahiro Yamada wrote:
> Currently, the Kbuild core manipulates header search paths in a crazy
> way [1].
> 
> To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> the search paths in the srctree. Some Makefiles are already written in
> that way, but not all. The goal of this work is to make the notation
> consistent, and finally get rid of the gross hacks.
> 
> Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
> ("kbuild: do not drop -I without parameter").
> 
> [1]: https://patchwork.kernel.org/patch/9632347/
> 
> Signed-off-by: Masahiro Yamada 

Patch looks good:
Reviewed-by: Sam Ravnborg 

> ---
> 
> I put all gpu/drm changes into a single patch because
> they are trivial conversion.
>
> Please let me know if I need to split this into per-driver patches.
Agree that it is good to have those related chnges together in one patch.

I still need to look into getting commit-rights.
Daniel - can you take this to drm-misc?

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add a security blanket to ring_is_idle()

2019-02-27 Thread Patchwork

== Series Details ==

Series: drm/i915: Add a security blanket to ring_is_idle()
URL   : https://patchwork.freedesktop.org/series/57308/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_5666 -> Patchwork_12319


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_12319 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_12319, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/57308/revisions/1/

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_12319:

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live_gem:
- fi-snb-2520m:   PASS -> DMESG-WARN

  * igt@runner@aborted:
- fi-snb-2520m:   NOTRUN -> FAIL

  
Known issues


  Here are the changes found in Patchwork_12319 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_contexts:
- fi-icl-u2:  NOTRUN -> DMESG-FAIL [fdo#108569]

  * igt@kms_busy@basic-flip-a:
- fi-gdg-551: PASS -> FAIL [fdo#103182] +1

  * igt@kms_psr@primary_mmap_gtt:
- fi-blb-e6850:   NOTRUN -> SKIP [fdo#109271] +27

  
 Possible fixes 

  * igt@i915_selftest@live_execlists:
- fi-apl-guc: INCOMPLETE [fdo#103927] / [fdo#109720] -> PASS

  * igt@i915_selftest@live_requests:
- fi-icl-u2:  INCOMPLETE [fdo#109644] -> PASS

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850:   INCOMPLETE [fdo#107718] -> PASS

  
  [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109644]: https://bugs.freedesktop.org/show_bug.cgi?id=109644
  [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720


Participating hosts (44 -> 38)
--

  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 fi-icl-y 


Build changes
-

* Linux: CI_DRM_5666 -> Patchwork_12319

  CI_DRM_5666: 358ab8acaabef3cef2a7ce9e5dd7c4196a0c30fc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4860: b79007f9c575a538a63ce9301a890ed9e1a45f35 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12319: c883bdeac3f6b0191212ec871420edcaf8621679 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

c883bdeac3f6 drm/i915: Add a security blanket to ring_is_idle()

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12319/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/icl: Default to Thread Group preemption for compute workloads

2019-02-27 Thread Patchwork

== Series Details ==

Series: series starting with [1/2] drm/i915/icl: Default to Thread Group 
preemption for compute workloads
URL   : https://patchwork.freedesktop.org/series/57300/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_5666_full -> Patchwork_12315_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_12315_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_12315_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_12315_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_universal_plane@disable-primary-vs-flip-pipe-c:
- shard-apl:  PASS -> DMESG-WARN

  
Known issues


  Here are the changes found in Patchwork_12315_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_bad_reloc@negative-reloc-bsd2:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] +7

  * igt@gem_exec_params@no-vebox:
- shard-iclb: NOTRUN -> SKIP [fdo#109283]

  * igt@gem_pwrite@huge-gtt-forwards:
- shard-iclb: NOTRUN -> SKIP [fdo#109290]

  * igt@gem_softpin@noreloc-s3:
- shard-skl:  PASS -> INCOMPLETE [fdo#104108] / [fdo#107773]

  * igt@i915_pm_rpm@dpms-lpsp:
- shard-iclb: PASS -> INCOMPLETE [fdo#108840]

  * igt@i915_pm_rpm@dpms-non-lpsp:
- shard-skl:  NOTRUN -> INCOMPLETE [fdo#107807]

  * igt@i915_pm_rpm@gem-idle:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +5

  * igt@i915_pm_rpm@system-suspend-execbuf:
- shard-iclb: PASS -> INCOMPLETE [fdo#107713] / [fdo#108840]

  * igt@i915_query@query-topology-known-pci-ids:
- shard-iclb: NOTRUN -> SKIP [fdo#109303]

  * igt@kms_busy@extended-modeset-hang-newfb-render-b:
- shard-skl:  PASS -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-hsw:  PASS -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-modeset-hang-oldfb-render-d:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +4

  * igt@kms_busy@extended-modeset-hang-oldfb-render-e:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +4

  * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956]
- shard-apl:  PASS -> DMESG-WARN [fdo#107956]

  * igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-glk:  PASS -> FAIL [fdo#108145]
- shard-iclb: NOTRUN -> FAIL [fdo#107725] +1

  * igt@kms_ccs@pipe-c-missing-ccs-buffer:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] +21

  * igt@kms_chamelium@hdmi-edid-read:
- shard-iclb: NOTRUN -> SKIP [fdo#109284] +1

  * igt@kms_color@pipe-c-legacy-gamma:
- shard-apl:  PASS -> FAIL [fdo#104782] +1

  * igt@kms_concurrent@pipe-f:
- shard-iclb: NOTRUN -> SKIP [fdo#109278] +1

  * igt@kms_cursor_crc@cursor-128x128-dpms:
- shard-iclb: NOTRUN -> FAIL [fdo#103232]

  * igt@kms_cursor_crc@cursor-128x128-random:
- shard-apl:  PASS -> FAIL [fdo#103232] +1

  * igt@kms_cursor_crc@cursor-256x85-sliding:
- shard-apl:  NOTRUN -> FAIL [fdo#103232] +1

  * igt@kms_cursor_legacy@cursora-vs-flipb-legacy:
- shard-iclb: NOTRUN -> SKIP [fdo#109274] +1

  * igt@kms_draw_crc@draw-method-xrgb-mmap-wc-ytiled:
- shard-skl:  PASS -> FAIL [fdo#103184]

  * igt@kms_flip@dpms-vs-vblank-race:
- shard-glk:  PASS -> FAIL [fdo#103060]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-apl:  PASS -> FAIL [fdo#103167]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
- shard-glk:  PASS -> FAIL [fdo#103167] +1

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-shrfb-fliptrack:
- shard-iclb: PASS -> FAIL [fdo#103167] +2

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-pri-shrfb-draw-mmap-gtt:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] +8

  * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-wc:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] +59

  * igt@kms_invalid_dotclock:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] +53

  * igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-skl:  NOTRUN -> FAIL [fdo#108145] +1

  * igt@kms_plane_alpha_blend@pipe-c-alpha-7efc:
- shard-kbl:  NOTRUN -> FAIL [fdo#108145] / [fdo#108590]

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
- shard-kbl:  NOTRUN -> FAIL [fdo#108145]

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-none:

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/edid: If no preferred mode is found assume the first mode is preferred

2019-02-27 Thread Patchwork

== Series Details ==

Series: series starting with [1/2] drm/edid: If no preferred mode is found 
assume the first mode is preferred
URL   : https://patchwork.freedesktop.org/series/57306/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_5666 -> Patchwork_12318


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_12318 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_12318, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/57306/revisions/1/

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_12318:

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live_hugepages:
- fi-apl-guc: PASS -> DMESG-WARN

  * igt@i915_selftest@live_requests:
- fi-bxt-j4205:   PASS -> DMESG-WARN

  * igt@i915_selftest@live_timelines:
- fi-ivb-3770:PASS -> DMESG-WARN

  * igt@runner@aborted:
- fi-bxt-j4205:   NOTRUN -> FAIL
- fi-ivb-3770:NOTRUN -> FAIL

  
Known issues


  Here are the changes found in Patchwork_12318 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_contexts:
- fi-icl-u2:  NOTRUN -> DMESG-FAIL [fdo#108569]

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- fi-kbl-7560u:   PASS -> FAIL [fdo#103375]

  * igt@kms_psr@primary_mmap_gtt:
- fi-blb-e6850:   NOTRUN -> SKIP [fdo#109271] +27

  * igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: PASS -> FAIL [fdo#104008]

  
 Possible fixes 

  * igt@i915_selftest@live_requests:
- fi-icl-u2:  INCOMPLETE [fdo#109644] -> PASS

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850:   INCOMPLETE [fdo#107718] -> PASS

  * igt@prime_vgem@basic-fence-flip:
- fi-gdg-551: FAIL [fdo#103182] -> PASS

  
  [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
  [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
  [fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109644]: https://bugs.freedesktop.org/show_bug.cgi?id=109644


Participating hosts (44 -> 38)
--

  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 fi-icl-y 


Build changes
-

* Linux: CI_DRM_5666 -> Patchwork_12318

  CI_DRM_5666: 358ab8acaabef3cef2a7ce9e5dd7c4196a0c30fc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4860: b79007f9c575a538a63ce9301a890ed9e1a45f35 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12318: 5c9fa35c3ea45ef953f82bb03e1882a2f8670f68 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

5c9fa35c3ea4 drm/edid: Remove defunct EDID_QUIRK_FIRST_DETAILED_PREFERRED
0aebfe5ba886 drm/edid: If no preferred mode is found assume the first mode is 
preferred

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12318/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: introduce macros to define register contents (rev3)

2019-02-27 Thread Patchwork

== Series Details ==

Series: drm/i915: introduce macros to define register contents (rev3)
URL   : https://patchwork.freedesktop.org/series/50513/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5666 -> Patchwork_12317


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/50513/revisions/3/

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_12317:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_selftest@live_gtt:
- {fi-icl-y}: PASS -> INCOMPLETE

  
Known issues


  Here are the changes found in Patchwork_12317 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_contexts:
- fi-icl-u2:  NOTRUN -> DMESG-FAIL [fdo#108569]

  * igt@kms_busy@basic-flip-a:
- fi-kbl-7567u:   PASS -> SKIP [fdo#109271] / [fdo#109278] +2

  * igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]

  * igt@kms_psr@primary_mmap_gtt:
- fi-blb-e6850:   NOTRUN -> SKIP [fdo#109271] +27

  
 Possible fixes 

  * igt@i915_selftest@live_requests:
- fi-icl-u2:  INCOMPLETE [fdo#109644] -> PASS

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850:   INCOMPLETE [fdo#107718] -> PASS

  * igt@prime_vgem@basic-fence-flip:
- fi-gdg-551: FAIL [fdo#103182] -> PASS

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109644]: https://bugs.freedesktop.org/show_bug.cgi?id=109644


Participating hosts (44 -> 38)
--

  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 fi-pnv-d510 


Build changes
-

* Linux: CI_DRM_5666 -> Patchwork_12317

  CI_DRM_5666: 358ab8acaabef3cef2a7ce9e5dd7c4196a0c30fc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4860: b79007f9c575a538a63ce9301a890ed9e1a45f35 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12317: 81637c300f08431f584763347f3e167fe89dfc44 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

81637c300f08 drm/i915: use REG_FIELD_PREP() to define register bitfield values
1e626607f4fd drm/i915: deprecate _SHIFT in favor of _MASK passed to accessors
918ed22b15ea drm/i915: introduce REG_BIT() and REG_GENMASK() to define register 
contents

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12317/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm/i915/icl: decouple dpll ids from type

2019-02-27 Thread Ville Syrjälä

On Tue, Feb 26, 2019 at 11:02:58AM -0800, Lucas De Marchi wrote:
> On Tue, Feb 26, 2019 at 04:48:23PM +0200, Ville Syrjälä wrote:
> >> >This seems a rather roundabout way of doing things when we already have
> >> >the vfuncs.
> >> >
> >> >How about just:
> >> >
> >> >mg_pll_enable()
> >> >{
> >> >  icl_pll_enable(MG_REG);
> >> >}
> >> >
> >> >combo_pll_enable()
> >> >{
> >> >  icl_pll_enable(COMBO_REG);
> >> >}
> >> >
> >> >or something along those lines.
> >>
> >> humn... I thought about this approach as an intermediate step to the
> >> full blown "add another vfunc struct and pass that instead".  Platforms
> >> are free to use this for small differences that don't justify going that
> >> route.
> >>
> >> In your approach you go the route of "always use vfunc and add
> >> additional arguments to the common function".
> >> Compared to the approach here, it's not subjective on what to do in
> >> similar cases, but has its downsides as well.
> >>
> >> 1) The function can't be inlined so there's and extra hop when calling
> >> the vfunc
> >
> >We already have the vfunc. And even if we didn't, an extra vfunc in
> >modesetting code is probably in the noise.
> 
> I'm talking about the extra function you added here. The vfunc will call
> this, which then calls the real common function.
> 
> >> 2) if the callee is inlined we basically duplicate .text, but I doubt
> >> any compiler would do that
> >
> >Either it inlines or not. Why should we care in this particular case?
> 
> In this case I'm referring to icl_pll_enable() being inlined inside
> mg_pll_enable() and combo_pll_enable().
> 
> But let's leave alone the inlines and extra function calls and talk
> about the organization below.
> 
> >> 3) reg as the argument is probably not a good choice as it may change
> >> in the next platform - so we would need to add a "type" nonetheless
> >
> >Not sure what you mean. If the reg changes you pass in a different reg.
> >If other things differ significantly you write a new function.
> 
> because here the function can share more when I consider the *type* of
> the pll, not if it's reg 0x10, 0x30 or 0x40.
> 
> >>
> >> Since flags is already there
> >> and under-utilized I don't see much
> >> advantage on the vfunc-only approach. I'm not strongly opposed though:
> >> IMO both are better than the current state.
> >
> >If the existing mechanism is sufficient to the task then we should
> >generally use it rather than adding yet another mechanism. This
> >keeps the code more uniform and thus easier for everyone to
> >understand.
> 
> 
> both of them already exist - flags is already there. If I handle the
> *types* differently with your approach I would basically have:
> 
> enum pll_type {
> A,
> B,
> C,
> }
> 
> pll_enable()
> {
> ...
> 
> if (type == A)
> else if (type == B)
> else

This thing shouldn't have any ifs in it if this is done right.

The more ifs you have the harder it is to follow the code.
Ideally we'd have none.

> 
> ...
> }
> 
> a_pll_enable()
> {
> return pll_enable(A);
> }
> 
> b_pll_enable()
> {
> return pll_enable(B);
> }
> 
> c_pll_enable()
> {
> return pll_enable(C);
> }
> 
> static const struct funcs a_funcs = {
> .enable = a_pll_enable(),
> };
> static const struct funcs b_funcs = {
> .eanble = b_pll_enable(),
> };
> static const struct funcs c_funcs = {
> .enable = c_pll_enable(),
> };
> 
> static const struct plls[] = {
> { a_funcs, ... },
> { b_funcs, ... },
> { c_funcs, ... },
> };
> 
> 
> This approach has its value when the implementations are completely
> different - e.g. the mg vs combo approach in patch 1. When the
> implementation is very similar, what I'm proposing is to be able to do:
> 
> enum pll_type {
> A,
> B,
> C,
> }
> 
> pll_enable()
> {
> ...
> 
> if (type == A)
> else if (type == B)
> else
> 
> ...
> }
> 
> static const struct funcs funcs = {
> .enable = pll_enable(),
> };
>  
> static const struct plls[] = {
> { funcs, A, ... }
> { funcs, B, ... }
> { funcs, C, ... }
> }
> 
> We have less boilerplate code and the information is in the table rather
> than spread across multiple functions. Don't get me wrong, the other
> approach has its place and is even used in patch 1 because the impl
> is totally different.
> 
> In the ICL case, the type in the table is used to tweak the behavior for
> MG vs TBT, because they reuse most of the same calls. Combo vs MG is
> handled in patch 1, not here.
> 
> Lucas De Marchi

-- 
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915/icl: move MG pll hw_state readout

2019-02-27 Thread Ville Syrjälä

On Tue, Feb 26, 2019 at 11:15:44AM -0800, Lucas De Marchi wrote:
> On Tue, Feb 26, 2019 at 04:21:01PM +0200, Ville Syrjälä wrote:
> >On Mon, Feb 25, 2019 at 04:03:05PM -0800, Lucas De Marchi wrote:
> >> On Mon, Feb 25, 2019 at 10:42:12PM +0200, Ville Syrjälä wrote:
> >> >On Fri, Feb 22, 2019 at 03:23:22PM -0800, Lucas De Marchi wrote:
> >> >> Let the MG plls have their own hooks since it shares very little with
> >> >> other PLL types. It's also better so the platform info contains the info
> >> >> if the PLL is for MG PHY rather than relying on the PLL ids.
> >> >>
> >> >> Signed-off-by: Lucas De Marchi 
> >> >
> >> >There's quite a bit more cleanup to be done in this area. As a start
> >> >https://patchwork.freedesktop.org/series/56354/ ;)
> >>
> >> I started reviewing that and even gave my r-b in some patches - first
> >> patches cause several conflicts with in-flight patches though. Not sure
> >> how beneficial they are.
> >
> >The current code is quite messy, and thus hard to follow.
> >It should be cleaned up before we pile even more stuff on top.
> >People had already cargo culted all the crud from the older
> >implementations to the later ones.
> >
> >We can't let the dirt accumulate indefinitely because eventually
> >the point comes where the thing either collapses under its own weight
> >or someone just decides to not even look at the previous code and
> >does the new thing totally differently. And that approach does not
> >scale because then everyone has to keep in mind N different ways
> >of doing the exact same thing. And also all the learnings from the
> >old code are forgotten and we probably get more bugs as a result.
> 
> I agree with all of that. I'm talking about those particular changes and
> the timing with the pending work going upstream, not generically.

There is always pending work somewhere. We can't stop for that. Also
if there's more of this stuff about to be submitted upstream we 
should clean it up before it lands.

> 
> >> IMO last 3 patches could be standalone
> >> (particularly the one that is a bug fix, and doesn't depend on the
> >> previous ones)
> >
> >Nothing prevents the patches from being reviewed/merged out of order.
> 
> CI running on them and they taking more time to be merged waiting for
> the other patches to be reviewed.

The first part is already sorted by CI checking the whole thing.

The second part should be easy to fix.

> 
> Lucas De Marchi
> 
> >
> >>
> >> >This patch looks good to me. It'll conflict with my series though, but
> >> >no biggie.
> >> >Reviewed-by: Ville Syrjälä 
> >>
> >> thanks
> >> Lucas De Marchi
> >>
> >> >
> >> >> ---
> >> >>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 122 --
> >> >>  1 file changed, 74 insertions(+), 48 deletions(-)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> >> >> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> >> >> index 0a42d11c4c33..e4ec73d415d9 100644
> >> >> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> >> >> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> >> >> @@ -2966,6 +2966,68 @@ static i915_reg_t icl_pll_id_to_enable_reg(enum 
> >> >> intel_dpll_id id)
> >> >> return MG_PLL_ENABLE(icl_pll_id_to_tc_port(id));
> >> >>  }
> >> >>
> >> >> +static bool mg_pll_get_hw_state(struct drm_i915_private *dev_priv,
> >> >> +   struct intel_shared_dpll *pll,
> >> >> +   struct intel_dpll_hw_state *hw_state)
> >> >> +{
> >> >> +   const enum intel_dpll_id id = pll->info->id;
> >> >> +   enum tc_port tc_port = icl_pll_id_to_tc_port(id);
> >> >> +   intel_wakeref_t wakeref;
> >> >> +   bool ret = false;
> >> >> +   u32 val;
> >> >> +
> >> >> +   wakeref = intel_display_power_get_if_enabled(dev_priv,
> >> >> +POWER_DOMAIN_PLLS);
> >> >> +   if (!wakeref)
> >> >> +   return false;
> >> >> +
> >> >> +   val = I915_READ(MG_PLL_ENABLE(tc_port));
> >> >> +   if (!(val & PLL_ENABLE))
> >> >> +   goto out;
> >> >> +
> >> >> +   hw_state->mg_refclkin_ctl = I915_READ(MG_REFCLKIN_CTL(tc_port));
> >> >> +   hw_state->mg_refclkin_ctl &= MG_REFCLKIN_CTL_OD_2_MUX_MASK;
> >> >> +
> >> >> +   hw_state->mg_clktop2_coreclkctl1 =
> >> >> +   I915_READ(MG_CLKTOP2_CORECLKCTL1(tc_port));
> >> >> +   hw_state->mg_clktop2_coreclkctl1 &=
> >> >> +   MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO_MASK;
> >> >> +
> >> >> +   hw_state->mg_clktop2_hsclkctl =
> >> >> +   I915_READ(MG_CLKTOP2_HSCLKCTL(tc_port));
> >> >> +   hw_state->mg_clktop2_hsclkctl &=
> >> >> +   MG_CLKTOP2_HSCLKCTL_TLINEDRV_CLKSEL_MASK |
> >> >> +   MG_CLKTOP2_HSCLKCTL_CORE_INPUTSEL_MASK |
> >> >> +   MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO_MASK |
> >> >> +   MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_MASK;
> >> >> +
> >> >> +   hw_state->mg_pll_div0 = I915_READ(MG_PLL_DIV0(tc_port));
> >>

[Intel-gfx] [PATCH] drm/i915: Add a security blanket to ring_is_idle()

2019-02-27 Thread Chris Wilson

So CI is reporting a few flips on Skylake for intel_engines_are_idle(),
so apply a double check that the ring is valid before inspecting the
registers. However, we keep the forcewake omission in play to avoid the
Sandybridge failure.

Fixes: 0b702dca2658 ("drm/i915: Avoid waking the engines just to check if they 
are idle")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 4f244019560d..e3614e483f40 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -987,7 +987,8 @@ static bool ring_is_idle(struct intel_engine_cs *engine)
 * If the engine is not awake, both reads return 0 as we do so without
 * forcewake.
 */
-   if ((I915_READ_FW(RING_HEAD(engine->mmio_base)) & HEAD_ADDR) !=
+   if (I915_READ_FW(RING_CTL(engine->mmio_base)) & RING_VALID &&
+   (I915_READ_FW(RING_HEAD(engine->mmio_base)) & HEAD_ADDR) !=
(I915_READ_FW(RING_TAIL(engine->mmio_base)) & TAIL_ADDR))
idle = false;
 
-- 
2.20.1

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Use intel_engine_stop_cs when stopping ringbuffer

2019-02-27 Thread Chris Wilson

Quoting Patchwork (2019-02-27 17:41:59)
>  Possible regressions 
> 
>   * igt@i915_selftest@live_active:
> - fi-apl-guc: PASS -> DMESG-WARN

Second flip due to "drm/i915: Avoid waking the engines just to check if
they are idle", both skl.

Suggests that its passing earlier was fluke.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: introduce macros to define register contents (rev3)

2019-02-27 Thread Patchwork

== Series Details ==

Series: drm/i915: introduce macros to define register contents (rev3)
URL   : https://patchwork.freedesktop.org/series/50513/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: introduce REG_BIT() and REG_GENMASK() to define register 
contents
Okay!

Commit: drm/i915: deprecate _SHIFT in favor of _MASK passed to accessors
Okay!

Commit: drm/i915: use REG_FIELD_PREP() to define register bitfield values
+drivers/gpu/drm/i915/intel_display.c:1165:22: error: Expected constant 
expression in case statement
+drivers/gpu/drm/i915/intel_display.c:1168:22: error: Expected constant 
expression in case statement
+drivers/gpu/drm/i915/intel_display.c:1171:22: error: Expected constant 
expression in case statement
+drivers/gpu/drm/i915/intel_display.c:1174:22: error: Expected constant 
expression in case statement
-drivers/gpu/drm/i915/intel_display.c:2404:13: warning: call with no type!
-./include/linux/reservation.h:220:20: warning: dereference of noderef 
expression
-./include/linux/reservation.h:220:20: warning: dereference of noderef 
expression
-./include/linux/reservation.h:220:20: warning: dereference of noderef 
expression
-./include/linux/reservation.h:220:45: warning: dereference of noderef 
expression
-./include/linux/reservation.h:220:45: warning: dereference of noderef 
expression
-./include/linux/reservation.h:220:45: warning: dereference of noderef 
expression

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: introduce macros to define register contents (rev3)

2019-02-27 Thread Patchwork

== Series Details ==

Series: drm/i915: introduce macros to define register contents (rev3)
URL   : https://patchwork.freedesktop.org/series/50513/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
918ed22b15ea drm/i915: introduce REG_BIT() and REG_GENMASK() to define register 
contents
-:91: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__n' - possible side-effects?
#91: FILE: drivers/gpu/drm/i915/i915_reg.h:127:
+#define REG_BIT(__n)   \
+   ((u32)(BIT(__n) +   \
+  BUILD_BUG_ON_ZERO(__builtin_constant_p(__n) &&   \
+((__n) < 0 || (__n) > 31

-:105: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__high' - possible 
side-effects?
#105: FILE: drivers/gpu/drm/i915/i915_reg.h:141:
+#define REG_GENMASK(__high, __low) \
+   ((u32)(GENMASK(__high, __low) + \
+  BUILD_BUG_ON_ZERO(__builtin_constant_p(__high) &&\
+__builtin_constant_p(__low) && \
+((__low) < 0 || (__high) > 31 || (__low) > 
(__high)

-:105: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__low' - possible 
side-effects?
#105: FILE: drivers/gpu/drm/i915/i915_reg.h:141:
+#define REG_GENMASK(__high, __low) \
+   ((u32)(GENMASK(__high, __low) + \
+  BUILD_BUG_ON_ZERO(__builtin_constant_p(__high) &&\
+__builtin_constant_p(__low) && \
+((__low) < 0 || (__high) > 31 || (__low) > 
(__high)

total: 0 errors, 0 warnings, 3 checks, 169 lines checked
1e626607f4fd drm/i915: deprecate _SHIFT in favor of _MASK passed to accessors
81637c300f08 drm/i915: use REG_FIELD_PREP() to define register bitfield values
-:73: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__x' - possible side-effects?
#73: FILE: drivers/gpu/drm/i915/i915_reg.h:150:
+#define IS_POWER_OF_2(__x) ((__x) && (((__x) & ((__x) - 1)) == 0))

-:88: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__mask' - possible 
side-effects?
#88: FILE: drivers/gpu/drm/i915/i915_reg.h:162:
+#define REG_FIELD_PREP(__mask, __val)  
\
+   ((u32)typeof(__mask))(__val) << __bf_shf(__mask)) & (__mask)) + 
\
+  BUILD_BUG_ON_ZERO(!__builtin_constant_p(__mask)) +   
\
+  BUILD_BUG_ON_ZERO((__mask) == 0 || (__mask) > U32_MAX) + 
\
+  BUILD_BUG_ON_ZERO(!IS_POWER_OF_2((__mask) + (1ULL << 
__bf_shf(__mask + \
+  
BUILD_BUG_ON_ZERO(__builtin_choose_expr(__builtin_constant_p(__val), 
(~((__mask) >> __bf_shf(__mask)) & (__val)), 0

-:88: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__val' - possible 
side-effects?
#88: FILE: drivers/gpu/drm/i915/i915_reg.h:162:
+#define REG_FIELD_PREP(__mask, __val)  
\
+   ((u32)typeof(__mask))(__val) << __bf_shf(__mask)) & (__mask)) + 
\
+  BUILD_BUG_ON_ZERO(!__builtin_constant_p(__mask)) +   
\
+  BUILD_BUG_ON_ZERO((__mask) == 0 || (__mask) > U32_MAX) + 
\
+  BUILD_BUG_ON_ZERO(!IS_POWER_OF_2((__mask) + (1ULL << 
__bf_shf(__mask + \
+  
BUILD_BUG_ON_ZERO(__builtin_choose_expr(__builtin_constant_p(__val), 
(~((__mask) >> __bf_shf(__mask)) & (__val)), 0

-:93: WARNING:LONG_LINE: line over 100 characters
#93: FILE: drivers/gpu/drm/i915/i915_reg.h:167:
+  
BUILD_BUG_ON_ZERO(__builtin_choose_expr(__builtin_constant_p(__val), 
(~((__mask) >> __bf_shf(__mask)) & (__val)), 0

total: 0 errors, 1 warnings, 3 checks, 114 lines checked

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Use intel_engine_stop_cs when stopping ringbuffer

2019-02-27 Thread Patchwork

== Series Details ==

Series: series starting with [1/3] drm/i915: Use intel_engine_stop_cs when 
stopping ringbuffer
URL   : https://patchwork.freedesktop.org/series/57304/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_5666 -> Patchwork_12316


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_12316 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_12316, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/57304/revisions/1/

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_12316:

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live_active:
- fi-apl-guc: PASS -> DMESG-WARN

  
Known issues


  Here are the changes found in Patchwork_12316 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900:   PASS -> SKIP [fdo#109271]

  * igt@i915_pm_rpm@basic-rte:
- fi-byt-j1900:   PASS -> FAIL [fdo#108800]

  * igt@i915_selftest@live_contexts:
- fi-icl-u2:  NOTRUN -> DMESG-FAIL [fdo#108569]

  * igt@kms_busy@basic-flip-a:
- fi-kbl-7567u:   PASS -> SKIP [fdo#109271] / [fdo#109278] +2

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u:   PASS -> WARN [fdo#109380]

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u:   PASS -> SKIP [fdo#109271] +33

  * igt@kms_psr@primary_mmap_gtt:
- fi-blb-e6850:   NOTRUN -> SKIP [fdo#109271] +27

  
 Possible fixes 

  * igt@i915_selftest@live_requests:
- fi-icl-u2:  INCOMPLETE [fdo#109644] -> PASS

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850:   INCOMPLETE [fdo#107718] -> PASS

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
  [fdo#109644]: https://bugs.freedesktop.org/show_bug.cgi?id=109644


Participating hosts (44 -> 36)
--

  Missing(8): fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy fi-byt-squawks 
fi-bsw-cyan fi-ctg-p8600 fi-gdg-551 fi-ivb-3770 


Build changes
-

* Linux: CI_DRM_5666 -> Patchwork_12316

  CI_DRM_5666: 358ab8acaabef3cef2a7ce9e5dd7c4196a0c30fc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4860: b79007f9c575a538a63ce9301a890ed9e1a45f35 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12316: a3a61404858ebb091d4618c68a60513cfdedfc95 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

a3a61404858e drm/i915: Disable PSMI idle messaging when stopping ring
c29ce4adfdc3 drm/i915: Introduce intel_engine_stop_ringbuffer
8195837078fd drm/i915: Use intel_engine_stop_cs when stopping ringbuffer

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12316/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] lib: Incrementally mlock()

2019-02-27 Thread Caz Yokoyama

inline.

v2 patches fixes
- address calculation bug
- not killed
However, the test does not runs faster.
-caz

On Wed, 2019-02-27 at 16:29 +, Chris Wilson wrote:
> As we already have the previous portion of the mmap mlocked, we only
> need to mlock() the fresh portion for testing available memory.
> 
> v2: Fixup the uint64_t pointer arithmetric and only use a single mmap
> to
> avoid subsequent mlock fail (for reasons unknown, but bet on mm/).
> 
> Signed-off-by: Chris Wilson 
> Cc: Caz Yokoyama 
> ---
>  lib/igt_aux.h |  2 +-
>  lib/intel_os.c| 40 +--
> 
>  tests/eviction_common.c   | 17 +
>  tests/i915/i915_suspend.c | 17 +++--
>  4 files changed, 35 insertions(+), 41 deletions(-)
> 
> diff --git a/lib/igt_aux.h b/lib/igt_aux.h
> index fb02c026a..09b6246bf 100644
> --- a/lib/igt_aux.h
> +++ b/lib/igt_aux.h
> @@ -194,7 +194,7 @@ void intel_purge_vm_caches(int fd);
>  uint64_t intel_get_avail_ram_mb(void);
>  uint64_t intel_get_total_ram_mb(void);
>  uint64_t intel_get_total_swap_mb(void);
> -size_t intel_get_total_pinnable_mem(void);
> +void *intel_get_total_pinnable_mem(size_t *pinned);
>  
>  int __intel_check_memory(uint64_t count, uint64_t size, unsigned
> mode,
>uint64_t *out_required, uint64_t *out_total);
> diff --git a/lib/intel_os.c b/lib/intel_os.c
> index e1e31e230..dd93bea1a 100644
> --- a/lib/intel_os.c
> +++ b/lib/intel_os.c
> @@ -227,11 +227,9 @@ intel_get_total_swap_mb(void)
>   *
>   * Returns: Amount of memory that can be safely pinned, in bytes.
>   */
> -size_t
> -intel_get_total_pinnable_mem(void)
> +void *intel_get_total_pinnable_mem(size_t *total)
>  {
>   uint64_t *can_mlock, pin, avail;
> - size_t ret;
>  
>   pin = (intel_get_total_ram_mb() + 1) << 20;
>   avail = (intel_get_avail_ram_mb() + 1) << 20;
> @@ -245,34 +243,40 @@ intel_get_total_pinnable_mem(void)
>*/
>   *can_mlock = (avail >> 1) + (avail >> 2);
>   if (mlock(can_mlock, *can_mlock)) {
> - *can_mlock = 0;
> - goto out;
> + munmap(can_mlock, pin);
> + return MAP_FAILED;
>   }
>  
>   for (uint64_t inc = 1024 << 20; inc >= 4 << 10; inc >>= 2) {
> - igt_debug("Testing mlock %'"PRIu64" B (%'"PRIu64"
> MiB)\n",
> -   *can_mlock, *can_mlock >> 20);
> + uint64_t locked = *can_mlock;
> +
> + igt_debug("Testing mlock %'"PRIu64"B (%'"PRIu64"MiB) +
> %'"PRIu64"B\n",
> +   locked, locked >> 20, inc);
>  
>   igt_fork(child, 1) {
> - for (uint64_t bytes = *can_mlock;
> -  bytes <= pin;
> -  bytes += inc) {
> - if (mlock(can_mlock, bytes))
> + uint64_t bytes = *can_mlock;
> +
> + while (bytes <= pin) {
> + if (mlock((void *)can_mlock + bytes,
> inc))
>   break;
>  
> - *can_mlock = bytes;
> + *can_mlock = bytes += inc;
>   __sync_synchronize();
>   }
>   }
>   __igt_waitchildren();
> - igt_assert(!mlock(can_mlock, *can_mlock));
> - }
>  
> -out:
> - ret = *can_mlock;
> - munmap(can_mlock, pin);
> + if (*can_mlock > locked + inc) { /* Weird bit of mm/
> lore */
> + *can_mlock -= inc;
> 
Are you able to explain this? Is this for when child is killed during
updating *can_mlock?

If the condition is not met, parent does not mlock. Is this OK?

> + igt_debug("Claiming mlock %'"PRIu64"B
> (%'"PRIu64"MiB)\n",
> +   *can_mlock, *can_mlock >> 20);
> + igt_assert(!mlock((void *)can_mlock + locked,
> 
> +   *can_mlock - locked));
> + }
> + }
>  
> - return ret;
> + *total = pin;
> 
*total = *can_mlock?

Also you don't unmap. I mean map and unmap are not paired in the same
function. Not elegant. But c'est la vie.
-caz

> + return can_mlock;
>  }
>  
>  static uint64_t vfs_file_max(void)
> diff --git a/tests/eviction_common.c b/tests/eviction_common.c
> index 321772ba7..a3b9e4167 100644
> --- a/tests/eviction_common.c
> +++ b/tests/eviction_common.c
> @@ -133,23 +133,24 @@ static void mlocked_evictions(int fd, struct
> igt_eviction_test_ops *ops,
> uint64_t surface_size,
> uint64_t surface_count)
>  {
> + uint64_t sz, pin, total;
>   void *mem;
> - uint64_t sz, pin_total;
>  
>   intel_require_memory(surface_count, surface_size, CHECK_RAM);
>  
> - sz = surface_size*surface_count;
> - pin_total = intel_get_total_pinnable_mem();
> - igt_require(pin_total > sz);
> -
> -

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Disable PSMI idle messaging when stopping ring

2019-02-27 Thread Chris Wilson

Quoting Mika Kuoppala (2019-02-27 16:58:50)
> Hardware cannot be in a middle of idle flow messaging
> when we pull the plug from ringbuffer. Disable idle
> messaging before we do so to avoid potential deadlock
> on engine initialization and reset.
> 
> v2: INVALID_MMIO_REG, unconditional enable (Chris)
> 
> Cc: Chris Wilson 
> Signed-off-by: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/intel_engine_cs.c | 56 +-
>  1 file changed, 55 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index a8e47cfa6e35..fe7fca392b63 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -725,7 +725,7 @@ int intel_engine_init_common(struct intel_engine_cs 
> *engine)
>  
>  /**
>   * intel_engines_cleanup_common - cleans up the engine state created by
> - *the common initiailizers.
> + *the common initializers.
>   * @engine: Engine to cleanup.
>   *
>   * This cleans up everything created by the common helpers.
> @@ -826,6 +826,55 @@ void intel_engine_cancel_stop_cs(struct intel_engine_cs 
> *engine)
>   _MASKED_BIT_DISABLE(STOP_RING));
>  }
>  
> +static i915_reg_t get_idle_poll_reg(const struct intel_engine_cs *engine)
> +{
> +   if (engine->id != RCS)
> +   return INVALID_MMIO_REG;
> +
> +   if (IS_GEN(engine->i915, 9))
> +   return GEN9_RCS_FE_FSM2;
> +
> +   if (IS_GEN(engine->i915, 8))
> +   return GEN6_RCS_PWR_FSM;
> +
> +   return INVALID_MMIO_REG;
> +}
> +
> +static void disable_idle_messaging(struct intel_engine_cs *engine)
> +{
> +   struct drm_i915_private *dev_priv = engine->i915;
> +   i915_reg_t poll_reg;
> +
> +   poll_reg = get_idle_poll_reg(engine);
> +   if (!i915_mmio_reg_valid(poll_reg))
> +   return;
> +
> +   GEM_DEBUG_WARN_ON(I915_READ_FW(GEN6_RC_SLEEP_PSMI_CONTROL) &
> + GEN6_PSMI_SLEEP_MSG_DISABLE);
> +
> +   I915_WRITE_FW(GEN6_RC_SLEEP_PSMI_CONTROL,
> + _MASKED_BIT_ENABLE(GEN6_PSMI_SLEEP_MSG_DISABLE));
> +

Needs some reference at least. Or a synposis of what exactly we are
waiting for in a comment.

> +   if (__intel_wait_for_register_fw(dev_priv, poll_reg,
> +0x7f, 0x30,
> +5000, 0,
> +NULL))
> +   DRM_DEBUG_DRIVER("psmi idle msg poll timeout\n");
> +}
> +
> +static void enable_idle_messaging(struct intel_engine_cs *engine)
> +{
> +   struct drm_i915_private *dev_priv = engine->i915;
> +   i915_reg_t poll_reg;
> +
> +   poll_reg = get_idle_poll_reg(engine);
> +   if (!i915_mmio_reg_valid(poll_reg))
> +   return;
> +
> +   I915_WRITE_FW(GEN6_RC_SLEEP_PSMI_CONTROL,
> + _MASKED_BIT_DISABLE(GEN6_PSMI_SLEEP_MSG_DISABLE));
> +}
> +
>  int intel_engine_stop_ringbuffer(struct intel_engine_cs *engine)
>  {
> struct drm_i915_private *dev_priv = engine->i915;
> @@ -841,9 +890,14 @@ int intel_engine_stop_ringbuffer(struct intel_engine_cs 
> *engine)
> I915_WRITE_FW(RING_TAIL(base), 0);
> POSTING_READ_FW(RING_TAIL(base));
>  
> +   /* Idle messaging needs to be off during ring disable */
> +   disable_idle_messaging(engine);
> +
> /* The ring must be empty before it is disabled */
> I915_WRITE_FW(RING_CTL(base), 0);
>  
> +   enable_idle_messaging(engine);
> +
> /* Check acts as a post */
> if (I915_READ_FW(RING_HEAD(base))) {
> GEM_TRACE("%s: ring head [%x] not parked\n",

Given the history SLEEP_MSG_DISABLE around RING_CTL is not surprising.

Acked-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use intel_engine_stop_cs when stopping ringbuffer

2019-02-27 Thread Chris Wilson

Quoting Mika Kuoppala (2019-02-27 17:03:38)
> Mika Kuoppala  writes:
> 
> > We have an exported function for stopping the engine before
> > disabling a ringbuffer. Take it into use.
> >
> > Cc: Chris Wilson 
> > Signed-off-by: Mika Kuoppala 
> > ---
> >  drivers/gpu/drm/i915/intel_engine_cs.c  |  3 +++
> >  drivers/gpu/drm/i915/intel_ringbuffer.c | 31 +++--
> >  2 files changed, 16 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> > b/drivers/gpu/drm/i915/intel_engine_cs.c
> > index 4f244019560d..3feb0f74c239 100644
> > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> > @@ -817,6 +817,9 @@ void intel_engine_cancel_stop_cs(struct intel_engine_cs 
> > *engine)
> >  {
> >   struct drm_i915_private *dev_priv = engine->i915;
> >  
> > + if (INTEL_GEN(dev_priv) < 3)
> > + return;
> > +
> >   GEM_TRACE("%s\n", engine->name);
> >  
> >   I915_WRITE_FW(RING_MI_MODE(engine->mmio_base),
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index 1b96b0960adc..5363dad1208d 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -607,23 +607,19 @@ static void ring_setup_status_page(struct 
> > intel_engine_cs *engine)
> >  static bool stop_ring(struct intel_engine_cs *engine)
> >  {
> >   struct drm_i915_private *dev_priv = engine->i915;
> > + int ret;
> >  
> > - if (INTEL_GEN(dev_priv) > 2) {
> > - I915_WRITE_MODE(engine, _MASKED_BIT_ENABLE(STOP_RING));
> > - if (intel_wait_for_register(dev_priv,
> > - RING_MI_MODE(engine->mmio_base),
> > - MODE_IDLE,
> > - MODE_IDLE,
> > - 1000)) {
> > - DRM_ERROR("%s : timed out trying to stop ring\n",
> > -   engine->name);
> > - /* Sometimes we observe that the idle flag is not
> > -  * set even though the ring is empty. So double
> > -  * check before giving up.
> > -  */
> > - if (I915_READ_HEAD(engine) != I915_READ_TAIL(engine))
> > - return false;
> > - }
> > + ret = intel_engine_stop_cs(engine);
> > + if (ret == -ENODEV)
> > + ret = 0;
> > +
> > + if (ret) {
> > + /* Sometimes we observe that the idle flag is not
> > +  * set even though the ring is empty. So double
> > +  * check before giving up.
> > +  */
> > + if (I915_READ_HEAD(engine) != I915_READ_TAIL(engine))
> 
> Hmm these could have been also converted to the _FW variants.

Sneak it in.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/edid: If no preferred mode is found assume the first mode is preferred

2019-02-27 Thread Ville Syrjala

From: Ville Syrjälä 

Some monitors apparently forget to mark any mode as preferred in the
EDID. In this particular case we have a very generic looking ID
"PNP Model 0 Serial Number 4" / "LVDS 800x600" so a specific quirk
doesn't seem particularly wise. Also the quirk we have
(EDID_QUIRK_FIRST_DETAILED_PREFERRED) is actually defunct so we'd
have to fix it first.

As a generic fallback let's just mark the first probed mode (which
should be the first detailed mode, assuming there are any) as
preferred.

On this particular machine the VBIOS seems to pick the 800x600
60Hz EST mode, which has the opposite sync polarities to the
800x600 60Hz detailed timings. But since it works I guess we
can ignore that slight discrepancy.

Cc: Adam Jackson 
Cc: Roberto Viola 
Tested-by: Roberto Viola 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109780
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_edid.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5f142530532a..6c6a93647686 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1828,7 +1828,7 @@ static void edid_fixup_preferred(struct drm_connector 
*connector,
list_for_each_entry_safe(cur_mode, t, >probed_modes, head) {
cur_mode->type &= ~DRM_MODE_TYPE_PREFERRED;
 
-   if (cur_mode == preferred_mode)
+   if (cur_mode == preferred_mode || target_refresh == 0)
continue;
 
/* Largest mode is preferred */
@@ -1850,6 +1850,18 @@ static void edid_fixup_preferred(struct drm_connector 
*connector,
preferred_mode->type |= DRM_MODE_TYPE_PREFERRED;
 }
 
+static bool preferred_mode_exists(struct drm_connector *connector)
+{
+   struct drm_display_mode *mode;
+
+   list_for_each_entry(mode, >probed_modes, head) {
+   if (mode->type & DRM_MODE_TYPE_PREFERRED)
+   return true;
+   }
+
+   return false;
+}
+
 static bool
 mode_is_rb(const struct drm_display_mode *mode)
 {
@@ -4733,7 +4745,8 @@ int drm_add_edid_modes(struct drm_connector *connector, 
struct edid *edid)
if (edid->features & DRM_EDID_FEATURE_DEFAULT_GTF)
num_modes += add_inferred_modes(connector, edid);
 
-   if (quirks & (EDID_QUIRK_PREFER_LARGE_60 | EDID_QUIRK_PREFER_LARGE_75))
+   if (quirks & (EDID_QUIRK_PREFER_LARGE_60 | EDID_QUIRK_PREFER_LARGE_75) 
||
+   !preferred_mode_exists(connector))
edid_fixup_preferred(connector, quirks);
 
if (quirks & EDID_QUIRK_FORCE_6BPC)
-- 
2.19.2

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

[Intel-gfx] [PATCH 2/2] drm/edid: Remove defunct EDID_QUIRK_FIRST_DETAILED_PREFERRED

2019-02-27 Thread Ville Syrjala

From: Ville Syrjälä 

Looks like EDID_QUIRK_FIRST_DETAILED_PREFERRED never did anything.
Its counterpart in f86EdidModes.c is properly hooked up but somehow
that functionality was lost when it was copied into the kernel.

Assuming that another preferred mode didn't sneak in somehow
(is that even possible?) this should now be fully covered by the
generic fallback that marks the first probed mode as preferred.
So let's just remove the quirk.

I tried to double check the known cases:
* Proview AY765C
  https://bugs.freedesktop.org/show_bug.cgi?id=15160 seems OK
* Unknown Acer
  https://bugzilla.redhat.com/show_bug.cgi?id=284231 (got the
  reference from xf86EdidModes.c), no access
* Philips 107p5 CRT
  "Reported on xorg@ with pastebin", didn't find the mail(s)
* Peacock Ergovision 19 (only in xf86EdidModes.c)
  https://bugzilla.redhat.com/show_bug.cgi?id=492359 seems OK

Cc: Adam Jackson 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_edid.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 6c6a93647686..59829e596910 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -68,8 +68,6 @@
  * maximum size and use that.
  */
 #define EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE   (1 << 4)
-/* Monitor forgot to set the first detailed is preferred bit. */
-#define EDID_QUIRK_FIRST_DETAILED_PREFERRED(1 << 5)
 /* use +hsync +vsync for detailed mode */
 #define EDID_QUIRK_DETAILED_SYNC_PP(1 << 6)
 /* Force reduced-blanking timings for detailed modes */
@@ -107,8 +105,6 @@ static const struct edid_quirk {
{ "ACR", 44358, EDID_QUIRK_PREFER_LARGE_60 },
/* Acer F51 */
{ "API", 0x7602, EDID_QUIRK_PREFER_LARGE_60 },
-   /* Unknown Acer */
-   { "ACR", 2423, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
 
/* AEO model 0 reports 8 bpc, but is a 6 bpc panel */
{ "AEO", 0, EDID_QUIRK_FORCE_6BPC },
@@ -145,12 +141,6 @@ static const struct edid_quirk {
{ "LPL", 0, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
{ "LPL", 0x2a00, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
 
-   /* Philips 107p5 CRT */
-   { "PHL", 57364, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
-
-   /* Proview AY765C */
-   { "PTS", 765, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
-
/* Samsung SyncMaster 205BW.  Note: irony */
{ "SAM", 541, EDID_QUIRK_DETAILED_SYNC_PP },
/* Samsung SyncMaster 22[5-6]BW */
-- 
2.19.2

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Introduce intel_engine_stop_ringbuffer

2019-02-27 Thread Chris Wilson

Quoting Mika Kuoppala (2019-02-27 16:58:49)
> We use identical sequence of stopping ringbuffer on reset
> handing and on ring initialization. Make a function
> to handle both cases.
> 
> Cc: Chris Wilson 
> Signed-off-by: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_reset.c   | 18 +---
>  drivers/gpu/drm/i915/intel_engine_cs.c  | 28 +
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 10 ++---
>  drivers/gpu/drm/i915/intel_ringbuffer.h |  2 ++
>  4 files changed, 33 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reset.c 
> b/drivers/gpu/drm/i915/i915_reset.c
> index 55d6123dbba4..4191398b5125 100644
> --- a/drivers/gpu/drm/i915/i915_reset.c
> +++ b/drivers/gpu/drm/i915/i915_reset.c
> @@ -113,28 +113,12 @@ void i915_reset_request(struct i915_request *rq, bool 
> guilty)
>  
>  static void gen3_stop_engine(struct intel_engine_cs *engine)
>  {
> -   struct drm_i915_private *dev_priv = engine->i915;
> -   const u32 base = engine->mmio_base;
> -
> GEM_TRACE("%s\n", engine->name);
>  
> if (intel_engine_stop_cs(engine))
> GEM_TRACE("%s: timed out on STOP_RING\n", engine->name);
>  
> -   I915_WRITE_FW(RING_HEAD(base), I915_READ_FW(RING_TAIL(base)));
> -   POSTING_READ_FW(RING_HEAD(base)); /* paranoia */
> -
> -   I915_WRITE_FW(RING_HEAD(base), 0);
> -   I915_WRITE_FW(RING_TAIL(base), 0);
> -   POSTING_READ_FW(RING_TAIL(base));
> -
> -   /* The ring must be empty before it is disabled */
> -   I915_WRITE_FW(RING_CTL(base), 0);
> -
> -   /* Check acts as a post */
> -   if (I915_READ_FW(RING_HEAD(base)))
> -   GEM_TRACE("%s: ring head [%x] not parked\n",
> - engine->name, I915_READ_FW(RING_HEAD(base)));
> +   intel_engine_stop_ringbuffer(engine);
>  }
>  
>  static void i915_stop_engines(struct drm_i915_private *i915,
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 3feb0f74c239..a8e47cfa6e35 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -826,6 +826,34 @@ void intel_engine_cancel_stop_cs(struct intel_engine_cs 
> *engine)
>   _MASKED_BIT_DISABLE(STOP_RING));
>  }
>  
> +int intel_engine_stop_ringbuffer(struct intel_engine_cs *engine)

I think intel_engine_stop_ring() works better, since it is the set of
RING registers we are controlling and are not concerned here with the
backing buffer.

> +{
> +   struct drm_i915_private *dev_priv = engine->i915;
> +   const u32 base = engine->mmio_base;
> +
> +   assert_forcewakes_active(dev_priv, FORCEWAKE_ALL);
> +   GEM_TRACE("%s\n", engine->name);
> +
> +   I915_WRITE_FW(RING_HEAD(base), I915_READ_FW(RING_TAIL(base)));
> +   POSTING_READ_FW(RING_HEAD(base)); /* paranoia */
> +
> +   I915_WRITE_FW(RING_HEAD(base), 0);
> +   I915_WRITE_FW(RING_TAIL(base), 0);
> +   POSTING_READ_FW(RING_TAIL(base));
> +
> +   /* The ring must be empty before it is disabled */
> +   I915_WRITE_FW(RING_CTL(base), 0);
> +
> +   /* Check acts as a post */
> +   if (I915_READ_FW(RING_HEAD(base))) {
> +   GEM_TRACE("%s: ring head [%x] not parked\n",
> + engine->name, I915_READ_FW(RING_HEAD(base)));
> +   return -EIO;
> +   }
> +
> +   return 0;
> +}
> +
>  const char *i915_cache_level_str(struct drm_i915_private *i915, int type)
>  {
> switch (type) {
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 5363dad1208d..8936a9051760 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -622,15 +622,9 @@ static bool stop_ring(struct intel_engine_cs *engine)
> return false;
> }
>  
> -   I915_WRITE_HEAD(engine, I915_READ_TAIL(engine));
> +   ret = intel_engine_stop_ringbuffer(engine);

Maybe

if (intel_engine_stop_ring(engine))
return false;

return false;

looks tidier?

Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use intel_engine_stop_cs when stopping ringbuffer

2019-02-27 Thread Chris Wilson

Quoting Mika Kuoppala (2019-02-27 16:58:48)
> We have an exported function for stopping the engine before
> disabling a ringbuffer. Take it into use.
> 
> Cc: Chris Wilson 
> Signed-off-by: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/intel_engine_cs.c  |  3 +++
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 31 +++--
>  2 files changed, 16 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 4f244019560d..3feb0f74c239 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -817,6 +817,9 @@ void intel_engine_cancel_stop_cs(struct intel_engine_cs 
> *engine)
>  {
> struct drm_i915_private *dev_priv = engine->i915;
>  
> +   if (INTEL_GEN(dev_priv) < 3)
> +   return;
> +
> GEM_TRACE("%s\n", engine->name);
>  
> I915_WRITE_FW(RING_MI_MODE(engine->mmio_base),
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 1b96b0960adc..5363dad1208d 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -607,23 +607,19 @@ static void ring_setup_status_page(struct 
> intel_engine_cs *engine)
>  static bool stop_ring(struct intel_engine_cs *engine)
>  {
> struct drm_i915_private *dev_priv = engine->i915;
> +   int ret;
>  
> -   if (INTEL_GEN(dev_priv) > 2) {
> -   I915_WRITE_MODE(engine, _MASKED_BIT_ENABLE(STOP_RING));
> -   if (intel_wait_for_register(dev_priv,
> -   RING_MI_MODE(engine->mmio_base),
> -   MODE_IDLE,
> -   MODE_IDLE,
> -   1000)) {
> -   DRM_ERROR("%s : timed out trying to stop ring\n",
> - engine->name);
> -   /* Sometimes we observe that the idle flag is not
> -* set even though the ring is empty. So double
> -* check before giving up.
> -*/
> -   if (I915_READ_HEAD(engine) != I915_READ_TAIL(engine))
> -   return false;
> -   }
> +   ret = intel_engine_stop_cs(engine);
> +   if (ret == -ENODEV)
> +   ret = 0;
> +
> +   if (ret) {
> +   /* Sometimes we observe that the idle flag is not

As you go past, gradually switch over to
/*
 * Sometimes...
style. The joys of a slow transition to uniformity and switching styles
half way through.

> +* set even though the ring is empty. So double
> +* check before giving up.
> +*/
> +   if (I915_READ_HEAD(engine) != I915_READ_TAIL(engine))
> +   return false;
> }
>  
> I915_WRITE_HEAD(engine, I915_READ_TAIL(engine));
> @@ -718,8 +714,7 @@ static int init_ring_common(struct intel_engine_cs 
> *engine)
> goto out;
> }
>  
> -   if (INTEL_GEN(dev_priv) > 2)
> -   I915_WRITE_MODE(engine, _MASKED_BIT_DISABLE(STOP_RING));
> +   intel_engine_cancel_stop_cs(engine);
>  
> /* Now awake, let it get started */
> if (ring->tail != ring->head) {

Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/icl: Default to Thread Group preemption for compute workloads

2019-02-27 Thread Patchwork

== Series Details ==

Series: series starting with [1/2] drm/i915/icl: Default to Thread Group 
preemption for compute workloads
URL   : https://patchwork.freedesktop.org/series/57300/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5666 -> Patchwork_12315


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/57300/revisions/1/

Known issues


  Here are the changes found in Patchwork_12315 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850:   PASS -> INCOMPLETE [fdo#107718]

  * igt@i915_selftest@live_contexts:
- fi-icl-u2:  NOTRUN -> DMESG-FAIL [fdo#108569]

  * igt@i915_selftest@live_requests:
- fi-icl-u3:  PASS -> DMESG-FAIL [fdo#109644]

  
 Possible fixes 

  * igt@i915_selftest@live_requests:
- fi-icl-u2:  INCOMPLETE [fdo#109644] -> PASS

  
 Warnings 

  * igt@prime_vgem@basic-fence-flip:
- fi-gdg-551: FAIL [fdo#103182] -> DMESG-FAIL [fdo#103182]

  
  [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#109644]: https://bugs.freedesktop.org/show_bug.cgi?id=109644


Participating hosts (44 -> 39)
--

  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 


Build changes
-

* Linux: CI_DRM_5666 -> Patchwork_12315

  CI_DRM_5666: 358ab8acaabef3cef2a7ce9e5dd7c4196a0c30fc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4860: b79007f9c575a538a63ce9301a890ed9e1a45f35 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12315: 02a1ad846725b72884ede07b5f946a9c00b6b4a1 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

02a1ad846725 drm/i915/icl: Apply WaEnablePreemptionGranularityControlByUMD
4f4bb7bd5f22 drm/i915/icl: Default to Thread Group preemption for compute 
workloads

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12315/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use intel_engine_stop_cs when stopping ringbuffer

2019-02-27 Thread Mika Kuoppala

Mika Kuoppala  writes:

> We have an exported function for stopping the engine before
> disabling a ringbuffer. Take it into use.
>
> Cc: Chris Wilson 
> Signed-off-by: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/intel_engine_cs.c  |  3 +++
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 31 +++--
>  2 files changed, 16 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 4f244019560d..3feb0f74c239 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -817,6 +817,9 @@ void intel_engine_cancel_stop_cs(struct intel_engine_cs 
> *engine)
>  {
>   struct drm_i915_private *dev_priv = engine->i915;
>  
> + if (INTEL_GEN(dev_priv) < 3)
> + return;
> +
>   GEM_TRACE("%s\n", engine->name);
>  
>   I915_WRITE_FW(RING_MI_MODE(engine->mmio_base),
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 1b96b0960adc..5363dad1208d 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -607,23 +607,19 @@ static void ring_setup_status_page(struct 
> intel_engine_cs *engine)
>  static bool stop_ring(struct intel_engine_cs *engine)
>  {
>   struct drm_i915_private *dev_priv = engine->i915;
> + int ret;
>  
> - if (INTEL_GEN(dev_priv) > 2) {
> - I915_WRITE_MODE(engine, _MASKED_BIT_ENABLE(STOP_RING));
> - if (intel_wait_for_register(dev_priv,
> - RING_MI_MODE(engine->mmio_base),
> - MODE_IDLE,
> - MODE_IDLE,
> - 1000)) {
> - DRM_ERROR("%s : timed out trying to stop ring\n",
> -   engine->name);
> - /* Sometimes we observe that the idle flag is not
> -  * set even though the ring is empty. So double
> -  * check before giving up.
> -  */
> - if (I915_READ_HEAD(engine) != I915_READ_TAIL(engine))
> - return false;
> - }
> + ret = intel_engine_stop_cs(engine);
> + if (ret == -ENODEV)
> + ret = 0;
> +
> + if (ret) {
> + /* Sometimes we observe that the idle flag is not
> +  * set even though the ring is empty. So double
> +  * check before giving up.
> +  */
> + if (I915_READ_HEAD(engine) != I915_READ_TAIL(engine))

Hmm these could have been also converted to the _FW variants.
-Mika


> + return false;
>   }
>  
>   I915_WRITE_HEAD(engine, I915_READ_TAIL(engine));
> @@ -718,8 +714,7 @@ static int init_ring_common(struct intel_engine_cs 
> *engine)
>   goto out;
>   }
>  
> - if (INTEL_GEN(dev_priv) > 2)
> - I915_WRITE_MODE(engine, _MASKED_BIT_DISABLE(STOP_RING));
> + intel_engine_cancel_stop_cs(engine);
>  
>   /* Now awake, let it get started */
>   if (ring->tail != ring->head) {
> -- 
> 2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 5/7] drm/tinydrm: Drop using tinydrm_device

2019-02-27 Thread Noralf Trønnes



Den 27.02.2019 15.27, skrev Gerd Hoffmann:
> On Mon, Feb 25, 2019 at 03:42:30PM +0100, Noralf Trønnes wrote:
>> Use devm_drm_dev_init() and drop using tinydrm_device.
>>
>> v2: devm_drm_dev_register() was dropped so add driver release callbacks.
>>
>> Signed-off-by: Noralf Trønnes 
>> ---
>>  drivers/gpu/drm/tinydrm/hx8357d.c  |  40 +--
>>  drivers/gpu/drm/tinydrm/ili9225.c  |  40 +--
>>  drivers/gpu/drm/tinydrm/ili9341.c  |  40 +--
>>  drivers/gpu/drm/tinydrm/mi0283qt.c |  40 +--
>>  drivers/gpu/drm/tinydrm/mipi-dbi.c |  67 +++---
>>  drivers/gpu/drm/tinydrm/st7586.c   | 105 -
>>  drivers/gpu/drm/tinydrm/st7735r.c  |  40 +--
>>  include/drm/tinydrm/mipi-dbi.h |  26 ---
> 
> Hmm, repaper got its own patch and these are all bundled.
> Slightly confusing, but at the end of the day it doesn't matter much.
> 

They had to since they all use the mipi-dbi helper which had to be
changed. The repaper driver is the only one that didn't use that helper.

thanks,
Noralf.

> Acked-by: Gerd Hoffmann 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 0/3] drm/i915: introduce macros to define register contents

2019-02-27 Thread Jani Nikula

v3 of [1] with naming hopefully settled (fingers crossed), and some more
compile time checks, documentation and other polish added.

The naming scheme of the local wrappers/copies of bit fiddling macros is
to just use REG_ prefix for the regular kernel ones, with hopefully
minimal confusion. So we end up with:

REG_BIT()
REG_GENMASK()
REG_FIELD_PREP()
REG_FIELD_GET()

We can also use the same macros in i915_reg.h and rest of the driver,
with no mixed use for register contents. Indeed some of the regular
kernel macros lead to non-u32 types being used.


BR,
Jani.

[1] http://mid.mail-archive.com/cover.1547726792.git.jani.nikula@intel.com


Jani Nikula (3):
  drm/i915: introduce REG_BIT() and REG_GENMASK() to define register
contents
  drm/i915: deprecate _SHIFT in favor of _MASK passed to accessors
  drm/i915: use REG_FIELD_PREP() to define register bitfield values

 drivers/gpu/drm/i915/i915_reg.h   | 182 +++---
 drivers/gpu/drm/i915/intel_dp.c   |  40 +++
 drivers/gpu/drm/i915/intel_lvds.c |  40 +++
 3 files changed, 151 insertions(+), 111 deletions(-)

-- 
2.20.1

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

[Intel-gfx] [PATCH v3 2/3] drm/i915: deprecate _SHIFT in favor of _MASK passed to accessors

2019-02-27 Thread Jani Nikula

bitfield.h defines FIELD_GET() and FIELD_PREP() macros to access
bitfields using the mask alone, with no need for separate shift. Indeed,
the shift is redundant.

We define REG_FIELD_GET() and REG_FIELD_PREP() wrappers for the above,
in part to force u32 and for consistency with REG_BIT() and
REG_GENMASK(), but also as we'll need to redefine REG_FIELD_PREP() in
follow-up work to make it produce integer constant expressions.

For the most part, REG_FIELD_GET() is shorter than masking followed by
shift, and arguably has more clarity.

REG_FIELD_PREP() can get more verbose than simply shifting in place, but
it does provide masking to ensure we don't overflow the mask, something
we usually don't bother with currently.

Convert power sequencer registers as an example.

v2:
- Add the REG_FIELD_GET() and REG_FIELD_PREP() wrappers to use them
  consistently from the start.

Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
Cc: Mika Kuoppala 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_reg.h   | 45 ---
 drivers/gpu/drm/i915/intel_dp.c   | 40 +++
 drivers/gpu/drm/i915/intel_lvds.c | 40 +--
 3 files changed, 64 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e847a18067bc..1bd75770483a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -25,6 +25,7 @@
 #ifndef _I915_REG_H_
 #define _I915_REG_H_
 
+#include 
 #include 
 
 /**
@@ -61,11 +62,11 @@
  * significant to least significant bit. Indent the register content macros
  * using two extra spaces between ``#define`` and the macro name.
  *
- * For bit fields, define a ``_MASK`` and a ``_SHIFT`` macro. Use
- * ``REG_GENMASK()`` to define _MASK. Define bit field contents so that they 
are
- * already shifted in place, and can be directly OR'd. For convenience,
- * function-like macros may be used to define bit fields, but do note that the
- * macros may be needed to read as well as write the register contents.
+ * Define bit fields using ``REG_GENMASK(h, l)``. Define bit field contents so
+ * that they are already shifted in place, and can be directly OR'd. For
+ * convenience, function-like macros may be used to define bit fields, but do
+ * note that the macros may be needed to read as well as write the register
+ * contents.
  *
  * Define bits using ``REG_BIT(N)``. Do **not** add ``_BIT`` suffix to the 
name.
  *
@@ -107,7 +108,6 @@
  *  #define FOO(pipe)   _MMIO_PIPE(pipe, _FOO_A, _FOO_B)
  *  #define   FOO_ENABLEREG_BIT(31)
  *  #define   FOO_MODE_MASK REG_GENMASK(19, 16)
- *  #define   FOO_MODE_SHIFT16
  *  #define   FOO_MODE_BAR  (0 << 16)
  *  #define   FOO_MODE_BAZ  (1 << 16)
  *  #define   FOO_MODE_QUX_SNB  (2 << 16)
@@ -144,6 +144,30 @@
 __builtin_constant_p(__low) && \
 ((__low) < 0 || (__high) > 31 || (__low) > 
(__high)
 
+/**
+ * REG_FIELD_PREP() - Prepare a u32 bitfield value
+ * @__mask: shifted mask defining the field's length and position
+ * @__val: value to put in the field
+
+ * Local wrapper for FIELD_PREP() to force u32 and for consistency with
+ * REG_FIELD_GET(), REG_BIT() and REG_GENMASK().
+ *
+ * @return: @__val masked and shifted into the field defined by @__mask.
+ */
+#define REG_FIELD_PREP(__mask, __val)  ((u32)FIELD_PREP(__mask, __val))
+
+/**
+ * REG_FIELD_GET() - Extract a u32 bitfield value
+ * @__mask: shifted mask defining the field's length and position
+ * @__val: value to extract the bitfield value from
+ *
+ * Local wrapper for FIELD_GET() to force u32 and for consistency with
+ * REG_FIELD_PREP(), REG_BIT() and REG_GENMASK().
+ *
+ * @return: Masked and shifted value of the field defined by @__mask in @__val.
+ */
+#define REG_FIELD_GET(__mask, __val)   ((u32)FIELD_GET(__mask, __val))
+
 typedef struct {
u32 reg;
 } i915_reg_t;
@@ -4726,7 +4750,6 @@ enum {
 #define ICP_PP_CONTROL(x)  _MMIO(((x) == 1) ? _PP_CONTROL_1 : \
  _PP_CONTROL_2)
 #define  POWER_CYCLE_DELAY_MASKREG_GENMASK(8, 4)
-#define  POWER_CYCLE_DELAY_SHIFT   4
 #define  VDD_OVERRIDE_FORCEREG_BIT(3)
 #define  BACKLIGHT_ENABLE  REG_BIT(2)
 #define  PWR_DOWN_ON_RESET REG_BIT(1)
@@ -4743,7 +4766,6 @@ enum {
 #define   PP_SEQUENCE_NONE (0 << 28)
 #define   PP_SEQUENCE_POWER_UP (1 << 28)
 #define   PP_SEQUENCE_POWER_DOWN   (2 << 28)
-#define   PP_SEQUENCE_SHIFT28
 #define   PP_CYCLE_DELAY_ACTIVEREG_BIT(27)
 #define   PP_SEQUENCE_STATE_MASK   REG_GENMASK(3, 0)
 #define   PP_SEQUENCE_STATE_OFF_IDLE   (0x0 << 0)
@@ -4769,7 +4791,6 @@ enum {
 
 #define _PP_ON_DELAYS  0x61208
 #define PP_ON_DELAYS(pps_idx)

[Intel-gfx] [PATCH v3 3/3] drm/i915: use REG_FIELD_PREP() to define register bitfield values

2019-02-27 Thread Jani Nikula

Slightly verbose, but does away with hand rolled shifts. Ties the field
values with the mask defining the field.

Unfortunately we have to make a local copy of FIELD_PREP() to evaluate
to a integer constant expression. But with this, we can ensure the mask
is non-zero, power of 2, fits u32, and the value fits the mask (when the
value is a constant expression).

Convert power sequencer registers as an example.

v3:
- rename the macro to REG_FIELD_PREP to avoid underscore prefix and to
  be in line with kernel macros (Chris)
- rename power of 2 check macro (Chris)

v2:
 - add build-time checks with BUILD_BUG_ON_ZERO()
 - rename to just _FIELD() due to regmap.h REG_FIELD() clash

Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
Cc: Mika Kuoppala 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_reg.h | 69 +++--
 1 file changed, 39 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1bd75770483a..70b7c5f0777b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -62,11 +62,11 @@
  * significant to least significant bit. Indent the register content macros
  * using two extra spaces between ``#define`` and the macro name.
  *
- * Define bit fields using ``REG_GENMASK(h, l)``. Define bit field contents so
- * that they are already shifted in place, and can be directly OR'd. For
- * convenience, function-like macros may be used to define bit fields, but do
- * note that the macros may be needed to read as well as write the register
- * contents.
+ * Define bit fields using ``REG_GENMASK(h, l)``. Define bit field contents
+ * using ``REG_FIELD_PREP(mask, value)``. This will define the values already
+ * shifted in place, so they can be directly OR'd together. For convenience,
+ * function-like macros may be used to define bit fields, but do note that the
+ * macros may be needed to read as well as write the register contents.
  *
  * Define bits using ``REG_BIT(N)``. Do **not** add ``_BIT`` suffix to the 
name.
  *
@@ -108,9 +108,9 @@
  *  #define FOO(pipe)   _MMIO_PIPE(pipe, _FOO_A, _FOO_B)
  *  #define   FOO_ENABLEREG_BIT(31)
  *  #define   FOO_MODE_MASK REG_GENMASK(19, 16)
- *  #define   FOO_MODE_BAR  (0 << 16)
- *  #define   FOO_MODE_BAZ  (1 << 16)
- *  #define   FOO_MODE_QUX_SNB  (2 << 16)
+ *  #define   FOO_MODE_BAR  REG_FIELD_PREP(FOO_MODE_MASK, 0)
+ *  #define   FOO_MODE_BAZ  REG_FIELD_PREP(FOO_MODE_MASK, 1)
+ *  #define   FOO_MODE_QUX_SNB  REG_FIELD_PREP(FOO_MODE_MASK, 2)
  *
  *  #define BAR _MMIO(0xb000)
  *  #define GEN8_BAR_MMIO(0xb888)
@@ -144,17 +144,27 @@
 __builtin_constant_p(__low) && \
 ((__low) < 0 || (__high) > 31 || (__low) > 
(__high)
 
+/*
+ * Local integer constant expression version of is_power_of_2().
+ */
+#define IS_POWER_OF_2(__x) ((__x) && (((__x) & ((__x) - 1)) == 0))
+
 /**
  * REG_FIELD_PREP() - Prepare a u32 bitfield value
  * @__mask: shifted mask defining the field's length and position
  * @__val: value to put in the field
 
- * Local wrapper for FIELD_PREP() to force u32 and for consistency with
- * REG_FIELD_GET(), REG_BIT() and REG_GENMASK().
+ * Local copy of FIELD_PREP() to generate an integer constant expression, force
+ * u32 and for consistency with REG_FIELD_GET(), REG_BIT() and REG_GENMASK().
  *
  * @return: @__val masked and shifted into the field defined by @__mask.
  */
-#define REG_FIELD_PREP(__mask, __val)  ((u32)FIELD_PREP(__mask, __val))
+#define REG_FIELD_PREP(__mask, __val)  
\
+   ((u32)typeof(__mask))(__val) << __bf_shf(__mask)) & (__mask)) + 
\
+  BUILD_BUG_ON_ZERO(!__builtin_constant_p(__mask)) +   
\
+  BUILD_BUG_ON_ZERO((__mask) == 0 || (__mask) > U32_MAX) + 
\
+  BUILD_BUG_ON_ZERO(!IS_POWER_OF_2((__mask) + (1ULL << 
__bf_shf(__mask + \
+  
BUILD_BUG_ON_ZERO(__builtin_choose_expr(__builtin_constant_p(__val), 
(~((__mask) >> __bf_shf(__mask)) & (__val)), 0
 
 /**
  * REG_FIELD_GET() - Extract a u32 bitfield value
@@ -4763,27 +4773,26 @@ enum {
  */
 #define   PP_READY REG_BIT(30)
 #define   PP_SEQUENCE_MASK REG_GENMASK(29, 28)
-#define   PP_SEQUENCE_NONE (0 << 28)
-#define   PP_SEQUENCE_POWER_UP (1 << 28)
-#define   PP_SEQUENCE_POWER_DOWN   (2 << 28)
+#define   PP_SEQUENCE_NONE REG_FIELD_PREP(PP_SEQUENCE_MASK, 0)
+#define   PP_SEQUENCE_POWER_UP REG_FIELD_PREP(PP_SEQUENCE_MASK, 1)
+#define   PP_SEQUENCE_POWER_DOWN   REG_FIELD_PREP(PP_SEQUENCE_MASK, 2)
 #define   PP_CYCLE_DELAY_ACTIVEREG_BIT(27)
 #define   PP_SEQUENCE_STATE_MASK   REG_GENMASK(3, 0)

[Intel-gfx] [PATCH v3 1/3] drm/i915: introduce REG_BIT() and REG_GENMASK() to define register contents

2019-02-27 Thread Jani Nikula

Introduce REG_BIT(n) to define register bits and REG_GENMASK(h, l) to
define register bitfield masks.

We define the above as wrappers to BIT() and GENMASK() respectively to
force u32 type to go with our register size, and to add compile time
checks on the bit numbers.

The intention is that these are easier to get right and review against
the spec than hand rolled masks.

Convert power sequencer registers as an example.

v3:
- rename macros to REG_BIT() and REG_GENMASK() to avoid underscore
  prefix and to be in line with kernel macros (Chris)
- add compile time checks (Mika)

v2:
- rename macros to just _BIT() and _MASK() to reduce verbosity

Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
Cc: Mika Kuoppala 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_reg.h | 94 +
 1 file changed, 61 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c9b482bc6433..e847a18067bc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -25,6 +25,8 @@
 #ifndef _I915_REG_H_
 #define _I915_REG_H_
 
+#include 
+
 /**
  * DOC: The i915 register macro definition style guide
  *
@@ -59,15 +61,13 @@
  * significant to least significant bit. Indent the register content macros
  * using two extra spaces between ``#define`` and the macro name.
  *
- * For bit fields, define a ``_MASK`` and a ``_SHIFT`` macro. Define bit field
- * contents so that they are already shifted in place, and can be directly
- * OR'd. For convenience, function-like macros may be used to define bit 
fields,
- * but do note that the macros may be needed to read as well as write the
- * register contents.
+ * For bit fields, define a ``_MASK`` and a ``_SHIFT`` macro. Use
+ * ``REG_GENMASK()`` to define _MASK. Define bit field contents so that they 
are
+ * already shifted in place, and can be directly OR'd. For convenience,
+ * function-like macros may be used to define bit fields, but do note that the
+ * macros may be needed to read as well as write the register contents.
  *
- * Define bits using ``(1 << N)`` instead of ``BIT(N)``. We may change this in
- * the future, but this is the prevailing style. Do **not** add ``_BIT`` suffix
- * to the name.
+ * Define bits using ``REG_BIT(N)``. Do **not** add ``_BIT`` suffix to the 
name.
  *
  * Group the register and its contents together without blank lines, separate
  * from other registers and their contents with one blank line.
@@ -105,8 +105,8 @@
  *  #define _FOO_A  0xf000
  *  #define _FOO_B  0xf001
  *  #define FOO(pipe)   _MMIO_PIPE(pipe, _FOO_A, _FOO_B)
- *  #define   FOO_ENABLE(1 << 31)
- *  #define   FOO_MODE_MASK (0xf << 16)
+ *  #define   FOO_ENABLEREG_BIT(31)
+ *  #define   FOO_MODE_MASK REG_GENMASK(19, 16)
  *  #define   FOO_MODE_SHIFT16
  *  #define   FOO_MODE_BAR  (0 << 16)
  *  #define   FOO_MODE_BAZ  (1 << 16)
@@ -116,6 +116,34 @@
  *  #define GEN8_BAR_MMIO(0xb888)
  */
 
+/**
+ * REG_BIT() - Prepare a u32 bit value
+ * @__n: 0-based bit number
+ *
+ * Local wrapper for BIT() to force u32, with compile time checks.
+ *
+ * @return: Value with bit @__n set.
+ */
+#define REG_BIT(__n)   \
+   ((u32)(BIT(__n) +   \
+  BUILD_BUG_ON_ZERO(__builtin_constant_p(__n) &&   \
+((__n) < 0 || (__n) > 31
+
+/**
+ * REG_GENMASK() - Prepare a continuous u32 bitmask
+ * @__high: 0-based high bit
+ * @__low: 0-based low bit
+ *
+ * Local wrapper for GENMASK() to force u32, with compile time checks.
+ *
+ * @return: Continuous bitmask from @__high to @__low, inclusive.
+ */
+#define REG_GENMASK(__high, __low) \
+   ((u32)(GENMASK(__high, __low) + \
+  BUILD_BUG_ON_ZERO(__builtin_constant_p(__high) &&\
+__builtin_constant_p(__low) && \
+((__low) < 0 || (__high) > 31 || (__low) > 
(__high)
+
 typedef struct {
u32 reg;
 } i915_reg_t;
@@ -4691,18 +4719,18 @@ enum {
 
 #define _PP_STATUS 0x61200
 #define PP_STATUS(pps_idx) _MMIO_PPS(pps_idx, _PP_STATUS)
-#define   PP_ON(1 << 31)
+#define   PP_ONREG_BIT(31)
 
 #define _PP_CONTROL_1  0xc7204
 #define _PP_CONTROL_2  0xc7304
 #define ICP_PP_CONTROL(x)  _MMIO(((x) == 1) ? _PP_CONTROL_1 : \
  _PP_CONTROL_2)
-#define  POWER_CYCLE_DELAY_MASK(0x1f << 4)
+#define  POWER_CYCLE_DELAY_MASKREG_GENMASK(8, 4)
 #define

[Intel-gfx] [PATCH 2/3] drm/i915: Introduce intel_engine_stop_ringbuffer

2019-02-27 Thread Mika Kuoppala

We use identical sequence of stopping ringbuffer on reset
handing and on ring initialization. Make a function
to handle both cases.

Cc: Chris Wilson 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_reset.c   | 18 +---
 drivers/gpu/drm/i915/intel_engine_cs.c  | 28 +
 drivers/gpu/drm/i915/intel_ringbuffer.c | 10 ++---
 drivers/gpu/drm/i915/intel_ringbuffer.h |  2 ++
 4 files changed, 33 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reset.c 
b/drivers/gpu/drm/i915/i915_reset.c
index 55d6123dbba4..4191398b5125 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -113,28 +113,12 @@ void i915_reset_request(struct i915_request *rq, bool 
guilty)
 
 static void gen3_stop_engine(struct intel_engine_cs *engine)
 {
-   struct drm_i915_private *dev_priv = engine->i915;
-   const u32 base = engine->mmio_base;
-
GEM_TRACE("%s\n", engine->name);
 
if (intel_engine_stop_cs(engine))
GEM_TRACE("%s: timed out on STOP_RING\n", engine->name);
 
-   I915_WRITE_FW(RING_HEAD(base), I915_READ_FW(RING_TAIL(base)));
-   POSTING_READ_FW(RING_HEAD(base)); /* paranoia */
-
-   I915_WRITE_FW(RING_HEAD(base), 0);
-   I915_WRITE_FW(RING_TAIL(base), 0);
-   POSTING_READ_FW(RING_TAIL(base));
-
-   /* The ring must be empty before it is disabled */
-   I915_WRITE_FW(RING_CTL(base), 0);
-
-   /* Check acts as a post */
-   if (I915_READ_FW(RING_HEAD(base)))
-   GEM_TRACE("%s: ring head [%x] not parked\n",
- engine->name, I915_READ_FW(RING_HEAD(base)));
+   intel_engine_stop_ringbuffer(engine);
 }
 
 static void i915_stop_engines(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 3feb0f74c239..a8e47cfa6e35 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -826,6 +826,34 @@ void intel_engine_cancel_stop_cs(struct intel_engine_cs 
*engine)
  _MASKED_BIT_DISABLE(STOP_RING));
 }
 
+int intel_engine_stop_ringbuffer(struct intel_engine_cs *engine)
+{
+   struct drm_i915_private *dev_priv = engine->i915;
+   const u32 base = engine->mmio_base;
+
+   assert_forcewakes_active(dev_priv, FORCEWAKE_ALL);
+   GEM_TRACE("%s\n", engine->name);
+
+   I915_WRITE_FW(RING_HEAD(base), I915_READ_FW(RING_TAIL(base)));
+   POSTING_READ_FW(RING_HEAD(base)); /* paranoia */
+
+   I915_WRITE_FW(RING_HEAD(base), 0);
+   I915_WRITE_FW(RING_TAIL(base), 0);
+   POSTING_READ_FW(RING_TAIL(base));
+
+   /* The ring must be empty before it is disabled */
+   I915_WRITE_FW(RING_CTL(base), 0);
+
+   /* Check acts as a post */
+   if (I915_READ_FW(RING_HEAD(base))) {
+   GEM_TRACE("%s: ring head [%x] not parked\n",
+ engine->name, I915_READ_FW(RING_HEAD(base)));
+   return -EIO;
+   }
+
+   return 0;
+}
+
 const char *i915_cache_level_str(struct drm_i915_private *i915, int type)
 {
switch (type) {
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 5363dad1208d..8936a9051760 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -622,15 +622,9 @@ static bool stop_ring(struct intel_engine_cs *engine)
return false;
}
 
-   I915_WRITE_HEAD(engine, I915_READ_TAIL(engine));
+   ret = intel_engine_stop_ringbuffer(engine);
 
-   I915_WRITE_HEAD(engine, 0);
-   I915_WRITE_TAIL(engine, 0);
-
-   /* The ring must be empty before it is disabled */
-   I915_WRITE_CTL(engine, 0);
-
-   return (I915_READ_HEAD(engine) & HEAD_ADDR) == 0;
+   return ret == 0;
 }
 
 static int init_ring_common(struct intel_engine_cs *engine)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index de8dba7565b0..10eb0f9a1432 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -858,6 +858,8 @@ int intel_init_vebox_ring_buffer(struct intel_engine_cs 
*engine);
 int intel_engine_stop_cs(struct intel_engine_cs *engine);
 void intel_engine_cancel_stop_cs(struct intel_engine_cs *engine);
 
+int intel_engine_stop_ringbuffer(struct intel_engine_cs *engine);
+
 void intel_engine_set_hwsp_writemask(struct intel_engine_cs *engine, u32 mask);
 
 u64 intel_engine_get_active_head(const struct intel_engine_cs *engine);
-- 
2.17.1

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

[Intel-gfx] [PATCH 3/3] drm/i915: Disable PSMI idle messaging when stopping ring

2019-02-27 Thread Mika Kuoppala

Hardware cannot be in a middle of idle flow messaging
when we pull the plug from ringbuffer. Disable idle
messaging before we do so to avoid potential deadlock
on engine initialization and reset.

v2: INVALID_MMIO_REG, unconditional enable (Chris)

Cc: Chris Wilson 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 56 +-
 1 file changed, 55 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index a8e47cfa6e35..fe7fca392b63 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -725,7 +725,7 @@ int intel_engine_init_common(struct intel_engine_cs *engine)
 
 /**
  * intel_engines_cleanup_common - cleans up the engine state created by
- *the common initiailizers.
+ *the common initializers.
  * @engine: Engine to cleanup.
  *
  * This cleans up everything created by the common helpers.
@@ -826,6 +826,55 @@ void intel_engine_cancel_stop_cs(struct intel_engine_cs 
*engine)
  _MASKED_BIT_DISABLE(STOP_RING));
 }
 
+static i915_reg_t get_idle_poll_reg(const struct intel_engine_cs *engine)
+{
+   if (engine->id != RCS)
+   return INVALID_MMIO_REG;
+
+   if (IS_GEN(engine->i915, 9))
+   return GEN9_RCS_FE_FSM2;
+
+   if (IS_GEN(engine->i915, 8))
+   return GEN6_RCS_PWR_FSM;
+
+   return INVALID_MMIO_REG;
+}
+
+static void disable_idle_messaging(struct intel_engine_cs *engine)
+{
+   struct drm_i915_private *dev_priv = engine->i915;
+   i915_reg_t poll_reg;
+
+   poll_reg = get_idle_poll_reg(engine);
+   if (!i915_mmio_reg_valid(poll_reg))
+   return;
+
+   GEM_DEBUG_WARN_ON(I915_READ_FW(GEN6_RC_SLEEP_PSMI_CONTROL) &
+ GEN6_PSMI_SLEEP_MSG_DISABLE);
+
+   I915_WRITE_FW(GEN6_RC_SLEEP_PSMI_CONTROL,
+ _MASKED_BIT_ENABLE(GEN6_PSMI_SLEEP_MSG_DISABLE));
+
+   if (__intel_wait_for_register_fw(dev_priv, poll_reg,
+0x7f, 0x30,
+5000, 0,
+NULL))
+   DRM_DEBUG_DRIVER("psmi idle msg poll timeout\n");
+}
+
+static void enable_idle_messaging(struct intel_engine_cs *engine)
+{
+   struct drm_i915_private *dev_priv = engine->i915;
+   i915_reg_t poll_reg;
+
+   poll_reg = get_idle_poll_reg(engine);
+   if (!i915_mmio_reg_valid(poll_reg))
+   return;
+
+   I915_WRITE_FW(GEN6_RC_SLEEP_PSMI_CONTROL,
+ _MASKED_BIT_DISABLE(GEN6_PSMI_SLEEP_MSG_DISABLE));
+}
+
 int intel_engine_stop_ringbuffer(struct intel_engine_cs *engine)
 {
struct drm_i915_private *dev_priv = engine->i915;
@@ -841,9 +890,14 @@ int intel_engine_stop_ringbuffer(struct intel_engine_cs 
*engine)
I915_WRITE_FW(RING_TAIL(base), 0);
POSTING_READ_FW(RING_TAIL(base));
 
+   /* Idle messaging needs to be off during ring disable */
+   disable_idle_messaging(engine);
+
/* The ring must be empty before it is disabled */
I915_WRITE_FW(RING_CTL(base), 0);
 
+   enable_idle_messaging(engine);
+
/* Check acts as a post */
if (I915_READ_FW(RING_HEAD(base))) {
GEM_TRACE("%s: ring head [%x] not parked\n",
-- 
2.17.1

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

[Intel-gfx] [PATCH 1/3] drm/i915: Use intel_engine_stop_cs when stopping ringbuffer

2019-02-27 Thread Mika Kuoppala

We have an exported function for stopping the engine before
disabling a ringbuffer. Take it into use.

Cc: Chris Wilson 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_engine_cs.c  |  3 +++
 drivers/gpu/drm/i915/intel_ringbuffer.c | 31 +++--
 2 files changed, 16 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 4f244019560d..3feb0f74c239 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -817,6 +817,9 @@ void intel_engine_cancel_stop_cs(struct intel_engine_cs 
*engine)
 {
struct drm_i915_private *dev_priv = engine->i915;
 
+   if (INTEL_GEN(dev_priv) < 3)
+   return;
+
GEM_TRACE("%s\n", engine->name);
 
I915_WRITE_FW(RING_MI_MODE(engine->mmio_base),
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 1b96b0960adc..5363dad1208d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -607,23 +607,19 @@ static void ring_setup_status_page(struct intel_engine_cs 
*engine)
 static bool stop_ring(struct intel_engine_cs *engine)
 {
struct drm_i915_private *dev_priv = engine->i915;
+   int ret;
 
-   if (INTEL_GEN(dev_priv) > 2) {
-   I915_WRITE_MODE(engine, _MASKED_BIT_ENABLE(STOP_RING));
-   if (intel_wait_for_register(dev_priv,
-   RING_MI_MODE(engine->mmio_base),
-   MODE_IDLE,
-   MODE_IDLE,
-   1000)) {
-   DRM_ERROR("%s : timed out trying to stop ring\n",
- engine->name);
-   /* Sometimes we observe that the idle flag is not
-* set even though the ring is empty. So double
-* check before giving up.
-*/
-   if (I915_READ_HEAD(engine) != I915_READ_TAIL(engine))
-   return false;
-   }
+   ret = intel_engine_stop_cs(engine);
+   if (ret == -ENODEV)
+   ret = 0;
+
+   if (ret) {
+   /* Sometimes we observe that the idle flag is not
+* set even though the ring is empty. So double
+* check before giving up.
+*/
+   if (I915_READ_HEAD(engine) != I915_READ_TAIL(engine))
+   return false;
}
 
I915_WRITE_HEAD(engine, I915_READ_TAIL(engine));
@@ -718,8 +714,7 @@ static int init_ring_common(struct intel_engine_cs *engine)
goto out;
}
 
-   if (INTEL_GEN(dev_priv) > 2)
-   I915_WRITE_MODE(engine, _MASKED_BIT_DISABLE(STOP_RING));
+   intel_engine_cancel_stop_cs(engine);
 
/* Now awake, let it get started */
if (ring->tail != ring->head) {
-- 
2.17.1

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

[Intel-gfx] [PATCH i-g-t] lib: Incrementally mlock()

2019-02-27 Thread Chris Wilson

As we already have the previous portion of the mmap mlocked, we only
need to mlock() the fresh portion for testing available memory.

v2: Fixup the uint64_t pointer arithmetric and only use a single mmap to
avoid subsequent mlock fail (for reasons unknown, but bet on mm/).

Signed-off-by: Chris Wilson 
Cc: Caz Yokoyama 
---
 lib/igt_aux.h |  2 +-
 lib/intel_os.c| 40 +--
 tests/eviction_common.c   | 17 +
 tests/i915/i915_suspend.c | 17 +++--
 4 files changed, 35 insertions(+), 41 deletions(-)

diff --git a/lib/igt_aux.h b/lib/igt_aux.h
index fb02c026a..09b6246bf 100644
--- a/lib/igt_aux.h
+++ b/lib/igt_aux.h
@@ -194,7 +194,7 @@ void intel_purge_vm_caches(int fd);
 uint64_t intel_get_avail_ram_mb(void);
 uint64_t intel_get_total_ram_mb(void);
 uint64_t intel_get_total_swap_mb(void);
-size_t intel_get_total_pinnable_mem(void);
+void *intel_get_total_pinnable_mem(size_t *pinned);
 
 int __intel_check_memory(uint64_t count, uint64_t size, unsigned mode,
 uint64_t *out_required, uint64_t *out_total);
diff --git a/lib/intel_os.c b/lib/intel_os.c
index e1e31e230..dd93bea1a 100644
--- a/lib/intel_os.c
+++ b/lib/intel_os.c
@@ -227,11 +227,9 @@ intel_get_total_swap_mb(void)
  *
  * Returns: Amount of memory that can be safely pinned, in bytes.
  */
-size_t
-intel_get_total_pinnable_mem(void)
+void *intel_get_total_pinnable_mem(size_t *total)
 {
uint64_t *can_mlock, pin, avail;
-   size_t ret;
 
pin = (intel_get_total_ram_mb() + 1) << 20;
avail = (intel_get_avail_ram_mb() + 1) << 20;
@@ -245,34 +243,40 @@ intel_get_total_pinnable_mem(void)
 */
*can_mlock = (avail >> 1) + (avail >> 2);
if (mlock(can_mlock, *can_mlock)) {
-   *can_mlock = 0;
-   goto out;
+   munmap(can_mlock, pin);
+   return MAP_FAILED;
}
 
for (uint64_t inc = 1024 << 20; inc >= 4 << 10; inc >>= 2) {
-   igt_debug("Testing mlock %'"PRIu64" B (%'"PRIu64" MiB)\n",
- *can_mlock, *can_mlock >> 20);
+   uint64_t locked = *can_mlock;
+
+   igt_debug("Testing mlock %'"PRIu64"B (%'"PRIu64"MiB) + 
%'"PRIu64"B\n",
+ locked, locked >> 20, inc);
 
igt_fork(child, 1) {
-   for (uint64_t bytes = *can_mlock;
-bytes <= pin;
-bytes += inc) {
-   if (mlock(can_mlock, bytes))
+   uint64_t bytes = *can_mlock;
+
+   while (bytes <= pin) {
+   if (mlock((void *)can_mlock + bytes, inc))
break;
 
-   *can_mlock = bytes;
+   *can_mlock = bytes += inc;
__sync_synchronize();
}
}
__igt_waitchildren();
-   igt_assert(!mlock(can_mlock, *can_mlock));
-   }
 
-out:
-   ret = *can_mlock;
-   munmap(can_mlock, pin);
+   if (*can_mlock > locked + inc) { /* Weird bit of mm/ lore */
+   *can_mlock -= inc;
+   igt_debug("Claiming mlock %'"PRIu64"B 
(%'"PRIu64"MiB)\n",
+ *can_mlock, *can_mlock >> 20);
+   igt_assert(!mlock((void *)can_mlock + locked,
+ *can_mlock - locked));
+   }
+   }
 
-   return ret;
+   *total = pin;
+   return can_mlock;
 }
 
 static uint64_t vfs_file_max(void)
diff --git a/tests/eviction_common.c b/tests/eviction_common.c
index 321772ba7..a3b9e4167 100644
--- a/tests/eviction_common.c
+++ b/tests/eviction_common.c
@@ -133,23 +133,24 @@ static void mlocked_evictions(int fd, struct 
igt_eviction_test_ops *ops,
  uint64_t surface_size,
  uint64_t surface_count)
 {
+   uint64_t sz, pin, total;
void *mem;
-   uint64_t sz, pin_total;
 
intel_require_memory(surface_count, surface_size, CHECK_RAM);
 
-   sz = surface_size*surface_count;
-   pin_total = intel_get_total_pinnable_mem();
-   igt_require(pin_total > sz);
-
-   mem = mmap(NULL, pin_total, PROT_READ, MAP_SHARED | MAP_ANON, -1, 0);
+   mem = intel_get_total_pinnable_mem();
igt_assert(mem != MAP_FAILED);
+   pin = *(uint64_t *)mem;
+   igt_assert(!munlock(mem, pin));
+
+   sz = surface_size * surface_count;
+   igt_require(pin > sz);
 
igt_fork(child, 1) {
uint32_t *bo;
uint64_t n;
int ret;
-   size_t lock = pin_total - sz;
+   size_t lock = pin - sz;
 
bo = malloc(surface_count * sizeof(*bo));
igt_assert(bo);
@@ -186,7

Re: [Intel-gfx] [PATCH 2/2] drm/i915/icl: Apply WaEnablePreemptionGranularityControlByUMD

2019-02-27 Thread Chris Wilson

Quoting Michał Winiarski (2019-02-27 15:51:09)
> There are still some cases where userspace needs to change the
> preemption granularity for compute workloads. Let's whitelist the
> per-ctx granularity control register to allow it.
> 
> Signed-off-by: Michał Winiarski 
> Cc: Anuj Phogat 
> Cc: Joonas Lahtinen 
> Cc: Matt Roper 
> Cc: Rafael Antognolli 
> ---
>  drivers/gpu/drm/i915/intel_workarounds.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c 
> b/drivers/gpu/drm/i915/intel_workarounds.c
> index a19e1c0052a7..1aa167415096 100644
> --- a/drivers/gpu/drm/i915/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> @@ -1057,6 +1057,9 @@ static void icl_whitelist_build(struct i915_wa_list *w)
>  
> /* WaAllowUMDToModifySamplerMode:icl */
> whitelist_reg(w, GEN10_SAMPLER_MODE);
> +
> +   /* WaEnablePreemptionGranularityControlByUMD:icl */
> +   whitelist_reg(w, GEN8_CS_CHICKEN1);

Whilst you are here, I have a task to add a quick little test to check
to make sure that "userspace" can actually write to the whitelisted
register. Or at least review the selftest and fill in a few gaps.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/icl: Apply WaEnablePreemptionGranularityControlByUMD

2019-02-27 Thread Chris Wilson

Quoting Michał Winiarski (2019-02-27 15:51:09)
> There are still some cases where userspace needs to change the
> preemption granularity for compute workloads. Let's whitelist the
> per-ctx granularity control register to allow it.

Just wondering aloud if this should a single patch; change the default
and allow userspace to opt-in in a single switch.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/i915/icl: Default to Thread Group preemption for compute workloads

2019-02-27 Thread Michał Winiarski

We assumed that the default preemption granularity is fine for ICL.
Unfortunately, it turns out that some drivers don't support mid-thread
preemption for compute workloads.
If a workload that doesn't support mid-thread preemption gets mid-thread
preempted, we're going to observe a GPU hang.
While I'm here, let's also update the "workaround" naming.

Signed-off-by: Michał Winiarski 
Cc: Anuj Phogat 
Cc: Joonas Lahtinen 
Cc: Matt Roper 
Cc: Rafael Antognolli 
---
 drivers/gpu/drm/i915/intel_workarounds.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_workarounds.c 
b/drivers/gpu/drm/i915/intel_workarounds.c
index 743cf5b00155..a19e1c0052a7 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -555,6 +555,11 @@ static void icl_ctx_workarounds_init(struct 
intel_engine_cs *engine)
   GEN10_CACHE_MODE_SS,
   0, /* write-only, so skip validation */
   _MASKED_BIT_ENABLE(FLOAT_BLEND_OPTIMIZATION_ENABLE));
+
+   /* WaDisableGPGPUMidThreadPreemption:icl */
+   WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1,
+   GEN9_PREEMPT_GPGPU_LEVEL_MASK,
+   GEN9_PREEMPT_GPGPU_THREAD_GROUP_LEVEL);
 }
 
 void intel_engine_init_ctx_wa(struct intel_engine_cs *engine)
@@ -1170,8 +1175,8 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct 
i915_wa_list *wal)
GEN7_DISABLE_SAMPLER_PREFETCH);
}
 
-   if (IS_GEN(i915, 9) || IS_CANNONLAKE(i915)) {
-   /* 
WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,cnl */
+   if (IS_GEN_RANGE(i915, 9, 11)) {
+   /* 
FtrPerCtxtPreemptionGranularityControl:skl,bxt,kbl,cfl,cnl,icl */
wa_masked_en(wal,
 GEN7_FF_SLICE_CS_CHICKEN1,
 GEN9_FFSC_PERCTX_PREEMPT_CTRL);
-- 
2.20.1

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

[Intel-gfx] [PATCH 2/2] drm/i915/icl: Apply WaEnablePreemptionGranularityControlByUMD

2019-02-27 Thread Michał Winiarski

There are still some cases where userspace needs to change the
preemption granularity for compute workloads. Let's whitelist the
per-ctx granularity control register to allow it.

Signed-off-by: Michał Winiarski 
Cc: Anuj Phogat 
Cc: Joonas Lahtinen 
Cc: Matt Roper 
Cc: Rafael Antognolli 
---
 drivers/gpu/drm/i915/intel_workarounds.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_workarounds.c 
b/drivers/gpu/drm/i915/intel_workarounds.c
index a19e1c0052a7..1aa167415096 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -1057,6 +1057,9 @@ static void icl_whitelist_build(struct i915_wa_list *w)
 
/* WaAllowUMDToModifySamplerMode:icl */
whitelist_reg(w, GEN10_SAMPLER_MODE);
+
+   /* WaEnablePreemptionGranularityControlByUMD:icl */
+   whitelist_reg(w, GEN8_CS_CHICKEN1);
 }
 
 void intel_engine_init_whitelist(struct intel_engine_cs *engine)
-- 
2.20.1

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

Re: [Intel-gfx] [PATCH 3/3] usb: typec: altmodes/displayport: Notify drm subsys of hotplug events

2019-02-27 Thread Hans de Goede


Hi,

On 27-02-19 10:44, Heikki Krogerus wrote:

On Mon, Feb 25, 2019 at 02:20:37PM +0100, Hans de Goede wrote:

Use the new drm_kms_call_oob_hotplug_notifier_chain() function to load
drm/kms drivers know about DisplayPort over Type-C hotplug events.

Signed-off-by: Hans de Goede 


I'm OK with this. I'll wait for the v2 and see if I can test these.


The only change I've queued for v2 is adding a "depends on DRM" to
the TYPEC_DP_ALTMODE Kconfig.

And given the discussion about passing lane-info, it might be a while
before we get a v2, so if you want to give this a test run, it is
probably best to just test v1 for now (if you've time).

Note to test this on the GPD win (which you have AFAIK) you will also
need the fusb302 + pi3usb30532 patches I've send out recently, as well as:

https://github.com/jwrdegoede/linux-sunxi/commit/945c6fe0a18957357b42e04ed34bf33667003030

I've one Type-C to VGA dongle (without any other functions) where the Type-C
mode negotiation fails. This one does work on a XPS 15 so I need to borrow
some hardware from a friend so that I can capture the USB-PD signals and
see what the Alpine Ridge controller does different compared to the in kernel
stack and fix this. My other 4 dongles work fine, including this "standard" 
model:
http://media.redgamingtech.com/rgt-website/2015/03/Apple-HDMI-Usb-Type-C-dongle.jpg

Regards,

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

Re: [Intel-gfx] [PATCH 0/3] Propagate DP-over-Type-C hotplug events from Type-C subsys to drm-drivers

2019-02-27 Thread Hans de Goede


Hi,

On 27-02-19 12:16, Jani Nikula wrote:

On Wed, 27 Feb 2019, Heikki Krogerus  wrote:

One thing that this series does not consider is the DP lane count
problem. The GPU drivers (i915 in this case) does not know is four,
two or one DP lanes in use.


Also, orientation.


The orientation should simply be correct with Type-C over DP. The mux /
orientation-switch used will take care of (physically) swapping the
lanes if the connector is inserted upside-down.


I guess that is not a critical issue since there is a workaround (I
think) where the driver basically does trial and error, but ideally we
should be able to tell i915 also the pin assignment that was
negotiated with the partner device so it knows the DP lane count.


Yeah, if the information is there, we'd like to know.


So far machines actually using a setup where the kernel does the
USB-PD / Type-C negotiation rather then this being handled in firmware
in say the Alpine Ridge controller, are very rare.

AFAIK in the Alpine Ridge controller case, there is no communication
with the i915 driver, the only thing the Alpine Ridge controller does
which the everything done in the kernel approach does not, is that
it actually has a pin connected to the HDP pin of the displayport in
question.  But that just lets the i915 driver know about hotplug-events,
not how many lanes are used.

Currently I'm aware of only 2 x86 models which actually need the
hotplug event propagation from the Type-C subsystem to the i915 driver.
Do we really want to come up with a much more complex solution to
optimize for this corner case, while the much more common case
(Alpine Ridge controller) does not provide this info to the i915 driver?

To give some idea of the complexity, first of all we need some
mechanism to let the kernel know which drm_connector is connected
to which Type-C port. For the 2 models I know if which need this, this
info is not available and we would need to hardcode it in the kernel
based on e.g. DMI matching.

Then once we have this link, we need to start thinking about probe
ordering. Likely we need the typec framework to find the drm_connector,
since the typec-partner device is only created when there actually is
a DP capable "dongle" connected, making doing it the other way around
tricky. Then the typec-partner device needs to get a reference or some
such to make sure the drm_connector does not fgo away during the lifetime
of the typec-partner device.

I would really like to avoid this, so if we want to send more info to
the i915 driver, I suggest we create some event struct for this which
gets passed to the notifier, this could include a string to
describe the DP connector which the Type-C connector is connected to
when the mux is set to DP mode, e.g. "i915/DP-1" should be unique
or probably better, use the PCI device name, so: ":00:02.0/DP-1"

Then we still have a loose coupling avoiding lifetime issues, while
the receiving drm driver can check which connector the event is for
and we can then also include other info such as lane-count and orientation
in the event struct.


With the orientation


As said, the orientation *should* be corrected by the mux switch,
it is corrected by the mux switch on the hardware I know about and
actually getting it wrong breaks the display output (we had a bug there),
so I guess that getting it wrong leads to the lines being swizzled in a way
which the i915 driver does not check for ...

Regards,

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

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Avoid waking the engines just to check if they are idle

2019-02-27 Thread Chris Wilson

Quoting Patchwork (2019-02-27 15:07:07)
>  Possible fixes 
> 
>   * igt@drm_read@short-buffer-nonblock:
> - shard-snb:  INCOMPLETE [fdo#105411] -> PASS

That's the one, that's been 100% since the last IGT reorder.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Avoid waking the engines just to check if they are idle

2019-02-27 Thread Patchwork

== Series Details ==

Series: drm/i915: Avoid waking the engines just to check if they are idle
URL   : https://patchwork.freedesktop.org/series/57292/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_5665_full -> Patchwork_12314_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_12314_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_12314_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_12314_full:

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live_objects:
- shard-apl:  PASS -> DMESG-WARN

  * igt@runner@aborted:
- shard-apl:  NOTRUN -> FAIL

  
Known issues


  Here are the changes found in Patchwork_12314_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@vcs1-dirty-create:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] / [fdo#109281]

  * igt@gem_exec_schedule@out-order-vebox:
- shard-hsw:  NOTRUN -> SKIP [fdo#109271] +26

  * igt@gem_exec_store@basic-bsd2:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] +4

  * igt@gem_mocs_settings@mocs-rc6-vebox:
- shard-iclb: NOTRUN -> SKIP [fdo#109287]

  * igt@gem_pwrite@huge-cpu-fbr:
- shard-iclb: NOTRUN -> SKIP [fdo#109290]

  * igt@gem_stolen@stolen-no-mmap:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] +22

  * igt@i915_pm_rc6_residency@rc6-accuracy:
- shard-kbl:  PASS -> SKIP [fdo#109271]
- shard-snb:  PASS -> SKIP [fdo#109271] +2

  * igt@i915_pm_rpm@gem-execbuf-stress:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +5

  * igt@i915_pm_rpm@i2c:
- shard-iclb: PASS -> FAIL [fdo#104097]

  * igt@i915_pm_rps@waitboost:
- shard-iclb: NOTRUN -> FAIL [fdo#102250] / [fdo#108059]

  * igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
- shard-apl:  PASS -> FAIL [fdo#109660]

  * igt@kms_atomic_transition@4x-modeset-transitions-nonblocking-fencing:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +4

  * igt@kms_busy@basic-modeset-d:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +4

  * igt@kms_busy@basic-modeset-f:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +2

  * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c:
- shard-kbl:  NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_chamelium@hdmi-crc-bgr565:
- shard-iclb: NOTRUN -> SKIP [fdo#109284]

  * igt@kms_color@pipe-b-gamma:
- shard-iclb: NOTRUN -> FAIL [fdo#104782]

  * igt@kms_concurrent@pipe-d:
- shard-iclb: NOTRUN -> SKIP [fdo#109278] +7

  * igt@kms_cursor_crc@cursor-256x256-random:
- shard-apl:  PASS -> FAIL [fdo#103232] +2

  * igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions:
- shard-hsw:  PASS -> FAIL [fdo#103355]

  * igt@kms_fbcon_fbt@fbc:
- shard-iclb: PASS -> DMESG-WARN [fdo#109593]

  * igt@kms_flip@2x-flip-vs-fences:
- shard-iclb: NOTRUN -> SKIP [fdo#109274] +2

  * igt@kms_flip@flip-vs-expired-vblank:
- shard-skl:  PASS -> FAIL [fdo#105363]

  * igt@kms_flip@plain-flip-fb-recreate-interruptible:
- shard-skl:  PASS -> FAIL [fdo#100368]

  * igt@kms_flip@single-buffer-flip-vs-dpms-off-vs-modeset:
- shard-apl:  PASS -> INCOMPLETE [fdo#103927]

  * igt@kms_flip@wf_vblank-ts-check-interruptible:
- shard-kbl:  PASS -> DMESG-WARN [fdo#103313] / [fdo#103558] / 
[fdo#105602] +12

  * igt@kms_flip_tiling@flip-changes-tiling-yf:
- shard-skl:  PASS -> FAIL [fdo#108228] / [fdo#108303]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
- shard-apl:  PASS -> FAIL [fdo#103167]

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-fullscreen:
- shard-glk:  PASS -> FAIL [fdo#103167] +1

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-shrfb-fliptrack:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] +10

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-blt:
- shard-iclb: PASS -> FAIL [fdo#103167] +6

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-onoff:
- shard-skl:  NOTRUN -> FAIL [fdo#103167]

  * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-shrfb-msflip-blt:
- shard-glk:  NOTRUN -> SKIP [fdo#109271] +9

  * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-spr-indfb-move:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] +59

  * igt@kms_frontbuffer_tracking@psr-rgb101010-draw-mmap-wc:
- shard-kbl:

Re: [Intel-gfx] [PATCH 04/11] drm/i915: Make request allocation caches global

2019-02-27 Thread Chris Wilson

Quoting Tvrtko Ursulin (2019-02-27 14:17:25)
> 
> On 27/02/2019 10:44, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-02-27 10:29:43)
> >>
> >> On 26/02/2019 10:23, Chris Wilson wrote:
> >>> As kmem_caches share the same properties (size, allocation/free behaviour)
> >>> for all potential devices, we can use global caches. While this
> >>> potential has worse fragmentation behaviour (one can argue that
> >>> different devices would have different activity lifetimes, but you can
> >>> also argue that activity is temporal across the system) it is the
> >>> default behaviour of the system at large to amalgamate matching caches.
> >>>
> >>> The benefit for us is much reduced pointer dancing along the frequent
> >>> allocation paths.
> >>>
> >>> v2: Defer shrinking until after a global grace period for futureproofing
> >>> multiple consumers of the slab caches, similar to the current strategy
> >>> for avoiding shrinking too early.
> >>
> >> I suggested to call i915_globals_park directly from __i915_gem_park for
> >> symmetry with how i915_gem_unpark calls i915_globals_unpark.
> >> i915_globals has it's own delayed setup so I don't think it benefits
> >> from the double indirection courtesy of being called from shrink_caches.
> > 
> > I replied I left that change until a later patch after the final
> > conversions. Mostly so that we had a standalone patch to revert if the
> > rcu_work turns out badly. In this patch, it was to be the simple
> > translation over to global_shrink, except you asked for it to be truly
> > global and so we needed another layer of counters.
> 
> It's a hard sell I think. Because why even have rcu work now in this 
> case? You could make i915_globals_park just shrink if active counter 
> dropped to zero. I don't see a benefit in a temporary asymmetric solution.

I did do just that in v1
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)

2019-02-27 Thread Joonas Lahtinen

Quoting Christian König (2019-02-27 04:17:01)
> Am 27.02.19 um 00:04 schrieb Dave Airlie:
> >>> At the end of the day, I don't really care that much.  I get it, we
> >>> all have large projects with scarce resources.  I just think a few
> >>> years down the road we'll all regret it as a community.
> >> AMD and others have also spent years tuning TTM for both UMA and VRAM,
> >> but especially VRAM.  It comes across a bit daft to complain about the
> >> effort to move to TTM, but say nothing about the effort to tune GEM
> >> for optimal VRAM performance.  Effort that has already been expended
> >> that you could take advantage of.
> > I'm with Alex here, the patches you have now are just the start, I
> > realise you think they are all you'll need, but I expect once Chris
> > gets going with real VRAM hardware he'll generate reams for stuff.
> >
> > People have been tuning and making TTM run on VRAM using GPUs for
> > longer than you've been making VRAM using GPUs, there had better be
> > good and well thought out reasons for avoiding using it, and so far
> > you haven't made that argument to me all. In fact your scheduler
> > arguments works against you. If we should have abstracted i915
> > scheduler out and used it because it had more features and
> > pre-existed, then i915 should be using TTM since it's already
> > abstracted out and has more features.
> >
> > Like we've pulled other stuff out of TTM like reservation objects, I
> > don't think i915 uses those yet either when it clearly could be. Maybe
> > if we started by fixing that, moving to TTM would be less of a
> > problem.
> 
> Just to make it extra clear: At least I absolutely won't mind if we 
> decommission TTM further!
> 
> We have optimized TTM as much as we could without a fundamental design 
> change, but essentially there are a couple of problem we can't fix 
> without touching all drivers at once.
> 
> For example the layered design where TTM calls back into the driver to 
> move stuff around or allocate something from a domain really needs to go 
> away.
> 
> So my suggestion is that we filleting TTM into multiple independent 
> components which a) can be used to implement the existing TTM interface 
> and b) implement a clean and encapsulated functionality.
> 
> Those components can then be used by drivers independently of TTM to 
> implement the necessary MM.

This is exactly what I was hoping we could do, too. So I'm glad to hear
this suggestion. 

Incrementally extracting and sharing the components would lead to less
disruptions than halting the progress while doing a major rewrite of
the driver.

As I mentioned in IRC, one good step for both the scheduler and memory
management would be to actually map out the feature sets. It is clear
that we have confusion about what the feature set of the respective
components are (at least I do seem to have about TTM / DRM scheduler).

Then when we understand what it is that we actually have, it should be
easier to start discussing which are the components that could be reused.

I think one good way to take on this would be to look into sharing as
much of the test assets as possible. We have plenty of testcases
excercising the low-on-memory conditions and scheduling corner cases
that we've had to tackle. And I'm sure there are tests for the above
mentioned TTM VRAM tuning, too.

I'll look into and discuss the reservation objects Dave mentioned, and
I'm happy to hear about other suggestions.

I'd also like to hear comments about the buddy allocator suggestion. It
should help in enabling >4K page support for pretty much any driver.

Regards, Joonas

> Regards,
> Christian.
> 
> >
> > Anyways, I expect moving to TTM is a big change for i915, and probably
> > more than you are able to bite off at present, but I'm going to be
> > watching closely what stuff you add on top of this sort of thing, and
> > if it starts getting large and messier as you tune it, I'll have to
> > start reconsidering how big a NO I have to use.
> >
> > Dave.
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 7/7] drm/tinydrm: Use drm_dev_enter/exit()

2019-02-27 Thread Gerd Hoffmann

On Mon, Feb 25, 2019 at 03:42:32PM +0100, Noralf Trønnes wrote:
> This protects device resources from use after device removal.
> 
> There are 3 ways for driver-device unbinding to happen:
> - The driver module is unloaded causing the driver to be unregistered.
>   This can't happen as long as there are open file handles because a
>   reference is taken on the module.
> - The device is removed (Device Tree overlay unloading).
>   This can happen at any time.
> - The driver sysfs unbind file can be used to unbind the driver from the
>   device. This can happen any time.
> 
> v2: Since drm_atomic_helper_shutdown() has to be called after
> drm_dev_unplug() we don't want do block ->disable after unplug.
> 
> Signed-off-by: Noralf Trønnes 

Acked-by: Gerd Hoffmann 

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

Re: [Intel-gfx] [PATCH v3 5/7] drm/tinydrm: Drop using tinydrm_device

2019-02-27 Thread Gerd Hoffmann

On Mon, Feb 25, 2019 at 03:42:30PM +0100, Noralf Trønnes wrote:
> Use devm_drm_dev_init() and drop using tinydrm_device.
> 
> v2: devm_drm_dev_register() was dropped so add driver release callbacks.
> 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/tinydrm/hx8357d.c  |  40 +--
>  drivers/gpu/drm/tinydrm/ili9225.c  |  40 +--
>  drivers/gpu/drm/tinydrm/ili9341.c  |  40 +--
>  drivers/gpu/drm/tinydrm/mi0283qt.c |  40 +--
>  drivers/gpu/drm/tinydrm/mipi-dbi.c |  67 +++---
>  drivers/gpu/drm/tinydrm/st7586.c   | 105 -
>  drivers/gpu/drm/tinydrm/st7735r.c  |  40 +--
>  include/drm/tinydrm/mipi-dbi.h |  26 ---

Hmm, repaper got its own patch and these are all bundled.
Slightly confusing, but at the end of the day it doesn't matter much.

Acked-by: Gerd Hoffmann 

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

Re: [Intel-gfx] [PATCH] drm/i915: Keep timeline HWSP allocated until idle across the system

2019-02-27 Thread Tvrtko Ursulin



On 27/02/2019 11:15, Chris Wilson wrote:

In preparation for enabling HW semaphores, we need to keep in flight
timeline HWSP alive until its use across entire system has completed,
as any other timeline active on the GPU may still refer back to the
already retired timeline. We both have to delay recycling available
cachelines and unpinning old HWSP until the next idle point.

An easy option would be to simply keep all used HWSP until the system as
a whole was idle, i.e. we could release them all at once on parking.
However, on a busy system, we may never see a global idle point,
essentially meaning the resource will be leaked until we are forced to
do a GC pass. We already employ a fine-grained idle detection mechanism
for vma, which we can reuse here so that each cacheline can be freed
immediately after the last request using it is retired.

v3: Keep track of the activity of each cacheline.
v4: cacheline_free() on canceling the seqno tracking
v5: Finally with a testcase to exercise wraparound
v6: Pack cacheline into empty bits of page-aligned vaddr
v7: Use i915_utils to hide the pointer casting around bit manipulation

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin  #v5
---
  drivers/gpu/drm/i915/i915_request.c   |  31 +-
  drivers/gpu/drm/i915/i915_request.h   |  11 +
  drivers/gpu/drm/i915/i915_timeline.c  | 290 --
  drivers/gpu/drm/i915/i915_timeline.h  |  11 +-
  drivers/gpu/drm/i915/i915_utils.h |   3 +
  .../gpu/drm/i915/selftests/i915_timeline.c| 113 +++
  6 files changed, 420 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 719d1a5ab082..d354967d6ae8 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -325,11 +325,6 @@ void i915_request_retire_upto(struct i915_request *rq)
} while (tmp != rq);
  }
  
-static u32 timeline_get_seqno(struct i915_timeline *tl)

-{
-   return tl->seqno += 1 + tl->has_initial_breadcrumb;
-}
-
  static void move_to_timeline(struct i915_request *request,
 struct i915_timeline *timeline)
  {
@@ -532,8 +527,10 @@ struct i915_request *
  i915_request_alloc(struct intel_engine_cs *engine, struct i915_gem_context 
*ctx)
  {
struct drm_i915_private *i915 = engine->i915;
-   struct i915_request *rq;
struct intel_context *ce;
+   struct i915_timeline *tl;
+   struct i915_request *rq;
+   u32 seqno;
int ret;
  
  	lockdep_assert_held(>drm.struct_mutex);

@@ -610,24 +607,27 @@ i915_request_alloc(struct intel_engine_cs *engine, struct 
i915_gem_context *ctx)
}
}
  
-	rq->rcustate = get_state_synchronize_rcu();

-
INIT_LIST_HEAD(>active_list);
+
+   tl = ce->ring->timeline;
+   ret = i915_timeline_get_seqno(tl, rq, );
+   if (ret)
+   goto err_free;
+
rq->i915 = i915;
rq->engine = engine;
rq->gem_context = ctx;
rq->hw_context = ce;
rq->ring = ce->ring;
-   rq->timeline = ce->ring->timeline;
+   rq->timeline = tl;
GEM_BUG_ON(rq->timeline == >timeline);
-   rq->hwsp_seqno = rq->timeline->hwsp_seqno;
+   rq->hwsp_seqno = tl->hwsp_seqno;
+   rq->hwsp_cacheline = tl->hwsp_cacheline;
+   rq->rcustate = get_state_synchronize_rcu(); /* acts as smp_mb() */
  
  	spin_lock_init(>lock);

-   dma_fence_init(>fence,
-  _fence_ops,
-  >lock,
-  rq->timeline->fence_context,
-  timeline_get_seqno(rq->timeline));
+   dma_fence_init(>fence, _fence_ops, >lock,
+  tl->fence_context, seqno);
  
  	/* We bump the ref for the fence chain */

i915_sw_fence_init(_request_get(rq)->submit, submit_notify);
@@ -687,6 +687,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct 
i915_gem_context *ctx)
GEM_BUG_ON(!list_empty(>sched.signalers_list));
GEM_BUG_ON(!list_empty(>sched.waiters_list));
  
+err_free:

kmem_cache_free(global.slab_requests, rq);
  err_unreserve:
mutex_unlock(>ring->timeline->mutex);
diff --git a/drivers/gpu/drm/i915/i915_request.h 
b/drivers/gpu/drm/i915/i915_request.h
index be3ded6bcf56..ea1e6f0ade53 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -38,6 +38,7 @@ struct drm_file;
  struct drm_i915_gem_object;
  struct i915_request;
  struct i915_timeline;
+struct i915_timeline_cacheline;
  
  struct i915_capture_list {

struct i915_capture_list *next;
@@ -148,6 +149,16 @@ struct i915_request {
 */
const u32 *hwsp_seqno;
  
+	/*

+* If we need to access the timeline's seqno for this request in
+* another request, we need to keep a read reference to this associated
+* cacheline, so that we do not free and recycle it before the foriegn
+*

Re: [Intel-gfx] [PATCH v3 3/7] drm/drv: DOC: Add driver example code

2019-02-27 Thread Gerd Hoffmann

On Mon, Feb 25, 2019 at 03:42:28PM +0100, Noralf Trønnes wrote:
> Add driver example that shows how devm_drm_dev_init() can be used.
> 
> v2: Expand docs (Sam, Daniel)

Acked-by: Gerd Hoffmann 

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

Re: [Intel-gfx] [PATCH 04/11] drm/i915: Make request allocation caches global

2019-02-27 Thread Tvrtko Ursulin



On 27/02/2019 10:44, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2019-02-27 10:29:43)


On 26/02/2019 10:23, Chris Wilson wrote:

As kmem_caches share the same properties (size, allocation/free behaviour)
for all potential devices, we can use global caches. While this
potential has worse fragmentation behaviour (one can argue that
different devices would have different activity lifetimes, but you can
also argue that activity is temporal across the system) it is the
default behaviour of the system at large to amalgamate matching caches.

The benefit for us is much reduced pointer dancing along the frequent
allocation paths.

v2: Defer shrinking until after a global grace period for futureproofing
multiple consumers of the slab caches, similar to the current strategy
for avoiding shrinking too early.


I suggested to call i915_globals_park directly from __i915_gem_park for
symmetry with how i915_gem_unpark calls i915_globals_unpark.
i915_globals has it's own delayed setup so I don't think it benefits
from the double indirection courtesy of being called from shrink_caches.


I replied I left that change until a later patch after the final
conversions. Mostly so that we had a standalone patch to revert if the
rcu_work turns out badly. In this patch, it was to be the simple
translation over to global_shrink, except you asked for it to be truly
global and so we needed another layer of counters.


It's a hard sell I think. Because why even have rcu work now in this 
case? You could make i915_globals_park just shrink if active counter 
dropped to zero. I don't see a benefit in a temporary asymmetric solution.


Regards,

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

Re: [Intel-gfx] [PATCH v3 2/7] drm: Add devm_drm_dev_init()

2019-02-27 Thread Gerd Hoffmann

On Mon, Feb 25, 2019 at 03:42:27PM +0100, Noralf Trønnes wrote:
> This adds a resource managed (devres) version of drm_dev_init().
> 
> v2: Remove devm_drm_dev_register() since we can't touch hw in devm
> release functions and drivers want to disable hw on driver module
> unload (Daniel Vetter, Greg KH)

Acked-by: Gerd Hoffmann 

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

Re: [Intel-gfx] [PATCH v3 1/7] drm/drv: Hold ref on parent device during drm_device lifetime

2019-02-27 Thread Gerd Hoffmann

On Mon, Feb 25, 2019 at 03:42:26PM +0100, Noralf Trønnes wrote:
> This makes it safe to access drm_device->dev after the parent device has
> been removed/unplugged.
> 
> Signed-off-by: Noralf Trønnes 

Reviewed-by: Gerd Hoffmann 

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

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [01/11] drm/i915: Skip scanning for signalers if we are already inflight (rev3)

2019-02-27 Thread Patchwork

== Series Details ==

Series: series starting with [01/11] drm/i915: Skip scanning for signalers if 
we are already inflight (rev3)
URL   : https://patchwork.freedesktop.org/series/57244/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5665_full -> Patchwork_12313_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_12313_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_eio@reset-stress:
- shard-snb:  PASS -> FAIL [fdo#109661]

  * igt@gem_exec_schedule@out-order-vebox:
- shard-hsw:  NOTRUN -> SKIP [fdo#109271] +26

  * igt@i915_pm_rpm@basic-rte:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +6

  * igt@i915_pm_rpm@system-suspend-modeset:
- shard-iclb: PASS -> FAIL [fdo#103375] +3

  * igt@kms_atomic_transition@4x-modeset-transitions-nonblocking-fencing:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +7

  * igt@kms_busy@basic-modeset-d:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +4

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-skl:  NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-pageflip-hang-newfb-render-f:
- shard-iclb: NOTRUN -> SKIP [fdo#109278] +1

  * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c:
- shard-kbl:  NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_chamelium@hdmi-crc-bgr565:
- shard-iclb: NOTRUN -> SKIP [fdo#109284]

  * igt@kms_color@pipe-b-gamma:
- shard-iclb: NOTRUN -> FAIL [fdo#104782]

  * igt@kms_cursor_crc@cursor-256x256-random:
- shard-apl:  PASS -> FAIL [fdo#103232] +2

  * igt@kms_fbcon_fbt@fbc-suspend:
- shard-iclb: PASS -> INCOMPLETE [fdo#107713]

  * igt@kms_flip@2x-plain-flip-ts-check:
- shard-iclb: NOTRUN -> SKIP [fdo#109274]

  * igt@kms_flip@flip-vs-expired-vblank:
- shard-skl:  PASS -> FAIL [fdo#105363] +1

  * igt@kms_flip@modeset-vs-vblank-race-interruptible:
- shard-glk:  PASS -> FAIL [fdo#103060]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-render:
- shard-apl:  PASS -> FAIL [fdo#103167]

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-mmap-wc:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] +3

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-pwrite:
- shard-iclb: PASS -> FAIL [fdo#103167] +5

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-onoff:
- shard-skl:  NOTRUN -> FAIL [fdo#103167]

  * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-shrfb-msflip-blt:
- shard-glk:  NOTRUN -> SKIP [fdo#109271] +9

  * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-spr-indfb-move:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] +91

  * igt@kms_frontbuffer_tracking@psr-rgb101010-draw-mmap-wc:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] +38

  * igt@kms_plane@pixel-format-pipe-a-planes-source-clamping:
- shard-skl:  NOTRUN -> DMESG-WARN [fdo#106885] +1

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl:  NOTRUN -> FAIL [fdo#107815]

  * igt@kms_plane_alpha_blend@pipe-c-alpha-basic:
- shard-glk:  NOTRUN -> FAIL [fdo#108145]

  * igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-skl:  NOTRUN -> FAIL [fdo#103166] / [fdo#107815]

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
- shard-iclb: PASS -> FAIL [fdo#103166] +2

  * igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-kbl:  PASS -> FAIL [fdo#109016] +1

  * igt@kms_setmode@basic:
- shard-hsw:  PASS -> FAIL [fdo#99912]

  * igt@kms_universal_plane@cursor-fb-leak-pipe-f:
- shard-hsw:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +3

  * igt@kms_universal_plane@universal-plane-pipe-b-functional:
- shard-glk:  PASS -> FAIL [fdo#103166]

  
 Possible fixes 

  * igt@gem_busy@extended-semaphore-blt:
- shard-iclb: SKIP [fdo#109275] -> PASS +2
- shard-kbl:  SKIP [fdo#109271] -> PASS +4
- shard-glk:  SKIP [fdo#109271] -> PASS +3

  * igt@gem_busy@extended-semaphore-vebox:
- shard-apl:  SKIP [fdo#109271] -> PASS +3
- shard-skl:  SKIP [fdo#109271] -> PASS +3

  * igt@gem_exec_parallel@bsd:
- shard-glk:  INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS

  * igt@i915_pm_rpm@gem-evict-pwrite:
- shard-iclb: DMESG-WARN [fdo#107724] -> PASS +2

  * igt@i915_pm_rpm@reg-read-ioctl:
- shard-iclb: INCOMPLETE [fdo#107713] / [fdo#108840] -> PASS

  * igt@kms_busy@extended-modeset-hang-newfb-render-a:
- shard-kbl:  DMESG-WARN [fdo#107956] -> PASS

  * igt@kms_frontbuffer_tracking@fbc-1p-indfb-fliptrack:
-

Re: [Intel-gfx] [PATCH] drm/i915: Avoid waking the engines just to check if they are idle

2019-02-27 Thread Mika Kuoppala

Chris Wilson  writes:

> Exploit that reads of the ring registers return 0 from the engine when
> it is idle and we do not apply forcewake to know that if the engine is
> idle then both reads will be identical (and so we interpret the ring as
> idle).
>
> The ulterior motive is to try and reduce the number of spurious wakeups
> to avoid untimely death, such as:
>
> <3> [85.046836] [drm:fw_domains_get [i915]] *ERROR* render: timed out waiting 
> for forcewake ack request.
> <4> [85.051916] [ cut here ]
> <4> [85.051917] GT thread status wait timed out
> <4> [85.051963] WARNING: CPU: 2 PID: 2195 at 
> drivers/gpu/drm/i915/intel_uncore.c:303 
> __gen6_gt_wait_for_thread_c0+0x6e/0xa0 [i915]
> <4> [85.051964] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek 
> snd_hda_codec_generic i915 x86_pkg_temp_thermal coretemp mei_hdcp 
> crct10dif_pclmul crc32_pclmul snd_hda_intel ghash_clmulni_intel snd_hda_codec 
> broadcom bcm_phy_lib i2c_i801 snd_hwdep snd_hda_core tg3 snd_pcm ptp pps_core 
> mei_me mei prime_numbers lpc_ich
> <4> [85.051980] CPU: 2 PID: 2195 Comm: drm_read Tainted: G U
> 5.0.0-rc8-CI-CI_DRM_5662+ #1
> <4> [85.051981] Hardware name: Dell Inc. XPS 8300  /0Y2MRG, BIOS A06 
> 10/17/2011
> <4> [85.052012] RIP: 0010:__gen6_gt_wait_for_thread_c0+0x6e/0xa0 [i915]
> <4> [85.052015] Code: 8b 92 5c 80 13 00 83 e2 07 75 d5 5b 5d c3 80 3d 5b 6a 
> 1a 00 00 75 f4 48 c7 c7 38 21 31 a0 c6 05 4b 6a 1a 00 01 e8 e2 84 ea e0 <0f> 
> 0b eb dd 80 3d 3a 6a 1a 00 00 75 98 48 c7 c6 08 21 31 a0 48 c7
> <4> [85.052016] RSP: 0018:c943bd00 EFLAGS: 00010086
> <4> [85.052019] RAX:  RBX: 888217c5 RCX: 
> 
> <4> [85.052020] RDX: 0007 RSI: 820cb141 RDI: 
> 
> <4> [85.052022] RBP: 0013cd30f2fb R08:  R09: 
> 0001
> <4> [85.052024] R10: c943bce0 R11:  R12: 
> 888217c50ee0
> <4> [85.052025] R13: 0001 R14:  R15: 
> 888218076530
> <4> [85.052028] FS:  7fc79d049980() GS:888227a8() 
> knlGS:
> <4> [85.052029] CS:  0010 DS:  ES:  CR0: 80050033
> <4> [85.052031] CR2: 7f782e2940f8 CR3: 00022458e006 CR4: 
> 000606e0
> <4> [85.052033] Call Trace:
> <4> [85.052064]  gen6_read32+0x14e/0x250 [i915]
> <4> [85.052096]  intel_engine_is_idle+0x7d/0x180 [i915]
> <4> [85.052126]  intel_engines_are_idle+0x29/0x50 [i915]
> <4> [85.052153]  i915_drop_caches_set+0x21c/0x290 [i915]
> <4> [85.052160]  simple_attr_write+0xb0/0xd0
> <4> [85.052165]  full_proxy_write+0x51/0x80
> <4> [85.052170]  __vfs_write+0x31/0x190
> <4> [85.052176]  ? rcu_read_lock_sched_held+0x6f/0x80
> <4> [85.052178]  ? rcu_sync_lockdep_assert+0x29/0x50
> <4> [85.052181]  ? __sb_start_write+0x152/0x1f0
> <4> [85.052183]  ? __sb_start_write+0x163/0x1f0
> <4> [85.052187]  vfs_write+0xbd/0x1b0
> <4> [85.052191]  ksys_write+0x50/0xc0
> <4> [85.052196]  do_syscall_64+0x55/0x190
> <4> [85.052200]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> <4> [85.052202] RIP: 0033:0x7fc79c9d3281
> <4> [85.052204] Code: c3 0f 1f 84 00 00 00 00 00 48 8b 05 59 8d 20 00 c3 0f 
> 1f 84 00 00 00 00 00 8b 05 8a d1 20 00 85 c0 75 16 b8 01 00 00 00 0f 05 <48> 
> 3d 00 f0 ff ff 77 57 f3 c3 0f 1f 44 00 00 41 54 55 49 89 d4 53
> <4> [85.052206] RSP: 002b:7fffa4a0a7f8 EFLAGS: 0246 ORIG_RAX: 
> 0001
> <4> [85.052208] RAX: ffda RBX: 0001 RCX: 
> 7fc79c9d3281
> <4> [85.052210] RDX: 0005 RSI: 7fffa4a0a880 RDI: 
> 0008
> <4> [85.052212] RBP: 7fffa4a0a820 R08:  R09: 
> 
> <4> [85.052213] R10:  R11: 0246 R12: 
> 7fc79c9bc718
> <4> [85.052215] R13: 0003 R14: 7fc79c9c1628 R15: 
> 7fc79c9bdd80
> <4> [85.052223] irq event stamp: 71630
> <4> [85.052226] hardirqs last  enabled at (71629): [] 
> _raw_spin_unlock_irqrestore+0x4c/0x60
> <4> [85.052228] hardirqs last disabled at (71630): [] 
> _raw_spin_lock_irqsave+0xd/0x50
> <4> [85.052231] softirqs last  enabled at (70444): [] 
> __do_softirq+0x33a/0x4b9
> <4> [85.052234] softirqs last disabled at (70433): [] 
> irq_exit+0xd1/0xe0
> <4> [85.052264] WARNING: CPU: 2 PID: 2195 at 
> drivers/gpu/drm/i915/intel_uncore.c:303 
> __gen6_gt_wait_for_thread_c0+0x6e/0xa0 [i915]
>
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/intel_engine_cs.c | 17 +++--
>  1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index b7b626195eda..4f244019560d 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -968,6 +968,7 @@ static bool ring_is_idle(struct intel_engine_cs *engine)
>  {
>   struct drm_i915_private *dev_priv = engine->i915;
>   intel_wakeref_t

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Avoid waking the engines just to check if they are idle

2019-02-27 Thread Patchwork

== Series Details ==

Series: drm/i915: Avoid waking the engines just to check if they are idle
URL   : https://patchwork.freedesktop.org/series/57292/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5665 -> Patchwork_12314


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/57292/revisions/1/

Known issues


  Here are the changes found in Patchwork_12314 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_workarounds@basic-read:
- fi-snb-2600:NOTRUN -> SKIP [fdo#109271] +57

  * igt@i915_module_load@reload:
- fi-blb-e6850:   PASS -> INCOMPLETE [fdo#107718]

  * igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]

  * igt@kms_busy@basic-flip-c:
- fi-snb-2600:NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  
  [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278


Participating hosts (41 -> 37)
--

  Additional (1): fi-snb-2600 
  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 


Build changes
-

* Linux: CI_DRM_5665 -> Patchwork_12314

  CI_DRM_5665: 63fb470a53f50de6cda4195ad7a2d7da249daec9 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4859: 1d8f3320cbc06fa73ad1487453a63993f17b9d57 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12314: 125ec713a4f5018948bde0a4974941bc381e98ad @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

125ec713a4f5 drm/i915: Avoid waking the engines just to check if they are idle

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12314/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)

2019-02-27 Thread Christian König


Am 27.02.19 um 00:04 schrieb Dave Airlie:

At the end of the day, I don't really care that much.  I get it, we
all have large projects with scarce resources.  I just think a few
years down the road we'll all regret it as a community.

AMD and others have also spent years tuning TTM for both UMA and VRAM,
but especially VRAM.  It comes across a bit daft to complain about the
effort to move to TTM, but say nothing about the effort to tune GEM
for optimal VRAM performance.  Effort that has already been expended
that you could take advantage of.

I'm with Alex here, the patches you have now are just the start, I
realise you think they are all you'll need, but I expect once Chris
gets going with real VRAM hardware he'll generate reams for stuff.

People have been tuning and making TTM run on VRAM using GPUs for
longer than you've been making VRAM using GPUs, there had better be
good and well thought out reasons for avoiding using it, and so far
you haven't made that argument to me all. In fact your scheduler
arguments works against you. If we should have abstracted i915
scheduler out and used it because it had more features and
pre-existed, then i915 should be using TTM since it's already
abstracted out and has more features.

Like we've pulled other stuff out of TTM like reservation objects, I
don't think i915 uses those yet either when it clearly could be. Maybe
if we started by fixing that, moving to TTM would be less of a
problem.


Just to make it extra clear: At least I absolutely won't mind if we 
decommission TTM further!


We have optimized TTM as much as we could without a fundamental design 
change, but essentially there are a couple of problem we can't fix 
without touching all drivers at once.


For example the layered design where TTM calls back into the driver to 
move stuff around or allocate something from a domain really needs to go 
away.


So my suggestion is that we filleting TTM into multiple independent 
components which a) can be used to implement the existing TTM interface 
and b) implement a clean and encapsulated functionality.


Those components can then be used by drivers independently of TTM to 
implement the necessary MM.


Regards,
Christian.



Anyways, I expect moving to TTM is a big change for i915, and probably
more than you are able to bite off at present, but I'm going to be
watching closely what stuff you add on top of this sort of thing, and
if it starts getting large and messier as you tune it, I'll have to
start reconsidering how big a NO I have to use.

Dave.
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/11] drm/i915: Skip scanning for signalers if we are already inflight (rev3)

2019-02-27 Thread Patchwork

== Series Details ==

Series: series starting with [01/11] drm/i915: Skip scanning for signalers if 
we are already inflight (rev3)
URL   : https://patchwork.freedesktop.org/series/57244/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5665 -> Patchwork_12313


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/57244/revisions/3/

Known issues


  Here are the changes found in Patchwork_12313 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850:   PASS -> INCOMPLETE [fdo#107718]

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
  [fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#109527]: https://bugs.freedesktop.org/show_bug.cgi?id=109527
  [fdo#109528]: https://bugs.freedesktop.org/show_bug.cgi?id=109528
  [fdo#109530]: https://bugs.freedesktop.org/show_bug.cgi?id=109530
  [fdo#109567]: https://bugs.freedesktop.org/show_bug.cgi?id=109567


Participating hosts (41 -> 37)
--

  Additional (1): fi-icl-y 
  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 


Build changes
-

* Linux: CI_DRM_5665 -> Patchwork_12313

  CI_DRM_5665: 63fb470a53f50de6cda4195ad7a2d7da249daec9 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4859: 1d8f3320cbc06fa73ad1487453a63993f17b9d57 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12313: cf099e9f7bbf4bfe77b4311996cf8edfb3ef14ff @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

cf099e9f7bbf drm/i915: Use __ffs() in for_each_priolist for more compact code
85cae32da616 drm/i915/execlists: Skip direct submission if only lite-restore
4466ab4a1898 drm/i915: Prioritise non-busywait semaphore workloads
06906ce0e44f drm/i915: Use HW semaphores for inter-engine synchronisation on 
gen8+
91d567c1020d drm/i915: Compute the global scheduler caps
d6145821b7b8 drm/i915: Keep timeline HWSP allocated until idle across the system
6c4e3e58cfad drm/i915: Introduce i915_timeline.mutex
1b4cf06284a2 drm/i915: Make request allocation caches global
8294f8314187 drm/i915/execlists: Suppress redundant preemption
12e479dbed40 drm/i915/execlists: Suppress mere WAIT preemption

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12313/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

1 2 >

1 - 100 of 118 matches

Mail list logo