[Intel-gfx] [PATCH 03/22] drm/i915: Skip shrinking already freed pages

2019-06-17 Thread Chris Wilson
Previously, we want to shrink the pages of freed objects before they
were RCU collected. However, by removing the struct_mutex serialisation
around the active reference, we need to acquire an extra reference
around the wait. Unfortunately this means that we have to skip objects
that are waiting RCU collection.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c   | 47 +---
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c |  5 +++
 2 files changed, 6 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index a4047a585c8b..bb5b6e63a2cc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -148,33 +148,6 @@ void i915_gem_close_object(struct drm_gem_object *gem, 
struct drm_file *file)
}
 }
 
-static bool discard_backing_storage(struct drm_i915_gem_object *obj)
-{
-   /*
-* If we are the last user of the backing storage (be it shmemfs
-* pages or stolen etc), we know that the pages are going to be
-* immediately released. In this case, we can then skip copying
-* back the contents from the GPU.
-*/
-   if (!i915_gem_object_is_shrinkable(obj))
-   return false;
-
-   if (obj->mm.madv != I915_MADV_WILLNEED)
-   return false;
-
-   if (!obj->base.filp)
-   return true;
-
-   /* At first glance, this looks racy, but then again so would be
-* userspace racing mmap against close. However, the first external
-* reference to the filp can only be obtained through the
-* i915_gem_mmap_ioctl() which safeguards us against the user
-* acquiring such a reference whilst we are in the middle of
-* freeing the object.
-*/
-   return file_count(obj->base.filp) == 1;
-}
-
 static void __i915_gem_free_objects(struct drm_i915_private *i915,
struct llist_node *freed)
 {
@@ -224,8 +197,7 @@ static void __i915_gem_free_objects(struct drm_i915_private 
*i915,
if (obj->ops->release)
obj->ops->release(obj);
 
-   if (WARN_ON(i915_gem_object_has_pinned_pages(obj)))
-   atomic_set(&obj->mm.pages_pin_count, 0);
+   atomic_set(&obj->mm.pages_pin_count, 0);
__i915_gem_object_put_pages(obj, I915_MM_NORMAL);
GEM_BUG_ON(i915_gem_object_has_pages(obj));
 
@@ -323,23 +295,6 @@ void i915_gem_free_object(struct drm_gem_object *gem_obj)
 {
struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
 
-   if (obj->mm.quirked)
-   __i915_gem_object_unpin_pages(obj);
-
-   if (discard_backing_storage(obj)) {
-   struct drm_i915_private *i915 = to_i915(obj->base.dev);
-
-   obj->mm.madv = I915_MADV_DONTNEED;
-
-   if (i915_gem_object_has_pages(obj)) {
-   unsigned long flags;
-
-   spin_lock_irqsave(&i915->mm.obj_lock, flags);
-   list_move_tail(&obj->mm.link, &i915->mm.purge_list);
-   spin_unlock_irqrestore(&i915->mm.obj_lock, flags);
-   }
-   }
-
/*
 * Before we free the object, make sure any pure RCU-only
 * read-side critical sections are complete, e.g.
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index c851c4029597..3a926a8755c6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -241,6 +241,9 @@ i915_gem_shrink(struct drm_i915_private *i915,
if (!can_release_pages(obj))
continue;
 
+   if (!kref_get_unless_zero(&obj->base.refcount))
+   continue;
+
spin_unlock_irqrestore(&i915->mm.obj_lock, flags);
 
if (unsafe_drop_pages(obj)) {
@@ -253,7 +256,9 @@ i915_gem_shrink(struct drm_i915_private *i915,
}
mutex_unlock(&obj->mm.lock);
}
+
scanned += obj->base.size >> PAGE_SHIFT;
+   i915_gem_object_put(obj);
 
spin_lock_irqsave(&i915->mm.obj_lock, flags);
}
-- 
2.20.1

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

[Intel-gfx] [PATCH 18/22] drm/i915: Forgo last_fence active request tracking

2019-06-17 Thread Chris Wilson
We were using the last_fence to track the last request that used this
vma that might be interpreted by a fence register and forced ourselves
to wait for this request before modifying any fence register that
overlapped our vma. Due to requirement that we need to track any XY_BLT
command, linear or tiled, this in effect meant that we have to track the
vma for its active lifespan anyway, so we can forgo the explicit
last_fence tracking and just use the whole vma->active.

Another solution would be to pipeline the register updates, and would
help resolve some long running stalls for gen3 (but only gen 2 and 3!)

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c   |  4 +---
 drivers/gpu/drm/i915/i915_gem_fence_reg.c |  6 ++
 drivers/gpu/drm/i915/i915_gem_gtt.c   |  1 -
 drivers/gpu/drm/i915/i915_vma.c   | 13 -
 drivers/gpu/drm/i915/i915_vma.h   |  1 -
 5 files changed, 3 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index d7af7c66df91..f9d36faf476a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -209,9 +209,7 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object 
*obj)
}
}
if (vma->fence)
-   seq_printf(m, " , fence: %d%s",
-  vma->fence->id,
-  i915_active_request_isset(&vma->last_fence) 
? "*" : "");
+   seq_printf(m, " , fence: %d", vma->fence->id);
seq_puts(m, ")");
 
spin_lock(&obj->vma.lock);
diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c 
b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
index 0bf53ac1c835..754eceaf0b23 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
@@ -230,16 +230,14 @@ static int fence_update(struct i915_fence_reg *fence,
 i915_gem_object_get_tiling(vma->obj)))
return -EINVAL;
 
-   ret = i915_active_request_retire(&vma->last_fence,
-&vma->obj->base.dev->struct_mutex);
+   ret = i915_active_wait(&vma->active);
if (ret)
return ret;
}
 
old = xchg(&fence->vma, NULL);
if (old) {
-   ret = i915_active_request_retire(&old->last_fence,
-&old->obj->base.dev->struct_mutex);
+   ret = i915_active_wait(&old->active);
if (ret) {
fence->vma = old;
return ret;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 17c732d3d523..94edf46b5229 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2074,7 +2074,6 @@ static struct i915_vma *pd_vma_create(struct gen6_ppgtt 
*ppgtt, int size)
return ERR_PTR(-ENOMEM);
 
i915_active_init(i915, &vma->active, NULL, NULL);
-   INIT_ACTIVE_REQUEST(&vma->last_fence);
 
vma->vm = &ggtt->vm;
vma->ops = &pd_vma_ops;
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 08582d1908d2..3d2266cc21f8 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -118,7 +118,6 @@ vma_create(struct drm_i915_gem_object *obj,
 
i915_active_init(vm->i915, &vma->active,
 __i915_vma_active, __i915_vma_retire);
-   INIT_ACTIVE_REQUEST(&vma->last_fence);
 
INIT_LIST_HEAD(&vma->closed_link);
 
@@ -793,8 +792,6 @@ static void __i915_vma_destroy(struct i915_vma *vma)
GEM_BUG_ON(vma->node.allocated);
GEM_BUG_ON(vma->fence);
 
-   GEM_BUG_ON(i915_active_request_isset(&vma->last_fence));
-
mutex_lock(&vma->vm->mutex);
list_del(&vma->vm_link);
mutex_unlock(&vma->vm->mutex);
@@ -930,9 +927,6 @@ int i915_vma_move_to_active(struct i915_vma *vma,
obj->read_domains |= I915_GEM_GPU_DOMAINS;
obj->mm.dirty = true;
 
-   if (flags & EXEC_OBJECT_NEEDS_FENCE)
-   __i915_active_request_set(&vma->last_fence, rq);
-
export_fence(vma, rq, flags);
 
GEM_BUG_ON(!i915_vma_is_active(vma));
@@ -965,14 +959,7 @@ int i915_vma_unbind(struct i915_vma *vma)
 * before we are finished).
 */
__i915_vma_pin(vma);
-
ret = i915_active_wait(&vma->active);
-   if (ret)
-   goto unpin;
-
-   ret = i915_active_request_retire(&vma->last_fence,
- &vma->vm->i915->drm.struct_mutex);
-unpin:
__i915_vma_unpin(vma);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/i915_vma.

[Intel-gfx] [PATCH 09/22] drm/i915: Make the semaphore saturation mask global

2019-06-17 Thread Chris Wilson
The idea behind keeping the saturation mask local to a context backfired
spectacularly. The premise with the local mask was that we would be more
proactive in attempting to use semaphores after each time the context
idled, and that all new contexts would attempt to use semaphores
ignoring the current state of the system. This turns out to be horribly
optimistic. If the system state is still oversaturated and the existing
workloads have all stopped using semaphores, the new workloads would
attempt to use semaphores and be deprioritised behind real work. The
new contexts would not switch off using semaphores until their initial
batch of low priority work had completed. Given sufficient backload load
of equal user priority, this would completely starve the new work of any
GPU time.

To compensate, remove the local tracking in favour of keeping it as
global state on the engine -- once the system is saturated and
semaphores are disabled, everyone stops attempting to use semaphores
until the system is idle again. One of the reason for preferring local
context tracking was that it worked with virtual engines, so for
switching to global state we could either do a complete check of all the
virtual siblings or simply disable semaphores for those requests. This
takes the simpler approach of disabling semaphores on virtual engines.

The downside is that the decision that the engine is saturated is a
local measure -- we are only checking whether or not this context was
scheduled in a timely fashion, it may be legitimately delayed due to user
priorities. We still have the same dilemma though, that we do not want
to employ the semaphore poll unless it will be used.

Fixes: ca6e56f654e7 ("drm/i915: Disable semaphore busywaits on saturated 
systems")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Dmitry Rogozhkin 
Cc: Dmitry Ermilov 
---
 drivers/gpu/drm/i915/gt/intel_context.c   | 2 --
 drivers/gpu/drm/i915/gt/intel_context_types.h | 2 --
 drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 ++
 drivers/gpu/drm/i915/gt/intel_engine_types.h  | 2 ++
 drivers/gpu/drm/i915/gt/intel_lrc.c   | 2 +-
 drivers/gpu/drm/i915/i915_request.c   | 4 ++--
 6 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 42f45744d859..2c454f227c2e 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -142,7 +142,6 @@ intel_context_init(struct intel_context *ce,
ce->engine = engine;
ce->ops = engine->cops;
ce->sseu = engine->sseu;
-   ce->saturated = 0;
 
INIT_LIST_HEAD(&ce->signal_link);
INIT_LIST_HEAD(&ce->signals);
@@ -223,7 +222,6 @@ void intel_context_enter_engine(struct intel_context *ce)
 
 void intel_context_exit_engine(struct intel_context *ce)
 {
-   ce->saturated = 0;
intel_engine_pm_put(ce->engine);
 }
 
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index b565c3ff4378..4c0e211c715d 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -58,8 +58,6 @@ struct intel_context {
atomic_t pin_count;
struct mutex pin_mutex; /* guards pinning and associated on-gpuing */
 
-   intel_engine_mask_t saturated; /* submitting semaphores too late? */
-
/**
 * active: Active tracker for the rq activity (inc. external) on this
 * intel_context object.
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c 
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index d14e352b0b17..2ce00d3dc42a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -100,6 +100,8 @@ static int __engine_park(struct intel_wakeref *wf)
struct intel_engine_cs *engine =
container_of(wf, typeof(*engine), wakeref);
 
+   engine->saturated = 0;
+
/*
 * If one and only one request is completed between pm events,
 * we know that we are inside the kernel context and it is
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 11a25f060fed..1cbe10a0fec7 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -258,6 +258,8 @@ struct intel_engine_cs {
struct intel_context *kernel_context; /* pinned */
struct intel_context *preempt_context; /* pinned; optional */
 
+   intel_engine_mask_t saturated; /* submitting semaphores too late? */
+
unsigned long serial;
 
unsigned long wakeref_serial;
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 0563fe8398c5..bbbdc63906c6 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -3198,7 +3198,6 @@ static void virtual_context_exit(struct intel_conte

[Intel-gfx] [PATCH 14/22] drm/i915: Throw away the active object retirement complexity

2019-06-17 Thread Chris Wilson
Remove the accumulated optimisations that we have for i915_vma_retire
and reduce it to the bare essential of tracking the active object
reference. This allows us to only use atomic operations, and so will be
able to avoid the struct_mutex requirement.

The principal loss here is the shrinker MRU bumping, so now if we have
to shrink, we will do so in much more random order and more likely to
try and shrink recently used objects. That is a nuisance, but shrinking
active objects is a second step we try to avoid and will always be a
system-wide performance issue.

The other loss is here is in the automatic pruning of the
reservation_object when idling. This is not as large an issue as upon
reservation_object introduction as now adding new fences into the object
replaces already signaled fences, keeping the array compact. But we do
lose the auto-expiration of stale fences and unused arrays. That may be
a noticeable problem for which we need to re-implement autopruning.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c|  1 -
 drivers/gpu/drm/i915/gem/i915_gem_object.h|  6 ---
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |  1 -
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c  |  5 +-
 .../drm/i915/gem/selftests/i915_gem_mman.c|  9 
 drivers/gpu/drm/i915/gt/intel_lrc.c   |  4 +-
 drivers/gpu/drm/i915/gt/intel_ringbuffer.c|  1 -
 drivers/gpu/drm/i915/gt/selftest_hangcheck.c  | 32 +--
 drivers/gpu/drm/i915/i915_debugfs.c   |  8 +--
 drivers/gpu/drm/i915/i915_gem_batch_pool.c| 42 ++-
 drivers/gpu/drm/i915/i915_vma.c   | 54 ---
 11 files changed, 47 insertions(+), 116 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index bb5b6e63a2cc..252e752da211 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -162,7 +162,6 @@ static void __i915_gem_free_objects(struct drm_i915_private 
*i915,
 
mutex_lock(&i915->drm.struct_mutex);
 
-   GEM_BUG_ON(i915_gem_object_is_active(obj));
list_for_each_entry_safe(vma, vn, &obj->vma.list, obj_link) {
GEM_BUG_ON(i915_vma_is_active(vma));
vma->flags &= ~I915_VMA_PIN_MASK;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 7cb1871d7128..454bfb498001 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -158,12 +158,6 @@ i915_gem_object_needs_async_cancel(const struct 
drm_i915_gem_object *obj)
return obj->ops->flags & I915_GEM_OBJECT_ASYNC_CANCEL;
 }
 
-static inline bool
-i915_gem_object_is_active(const struct drm_i915_gem_object *obj)
-{
-   return READ_ONCE(obj->active_count);
-}
-
 static inline bool
 i915_gem_object_is_framebuffer(const struct drm_i915_gem_object *obj)
 {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 5b05698619ce..c299fed2c6b1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -156,7 +156,6 @@ struct drm_i915_gem_object {
 
/** Count of VMA actually bound by this object */
atomic_t bind_count;
-   unsigned int active_count;
/** Count of how many global VMA are currently pinned for use by HW */
unsigned int pin_global;
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index 3a926a8755c6..f4677f70cce7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -230,8 +230,9 @@ i915_gem_shrink(struct drm_i915_private *i915,
continue;
 
if (!(shrink & I915_SHRINK_ACTIVE) &&
-   (i915_gem_object_is_active(obj) ||
-i915_gem_object_is_framebuffer(obj)))
+   (i915_gem_object_is_framebuffer(obj) ||
+reservation_object_test_signaled_rcu(obj->resv,
+ true)))
continue;
 
if (!(shrink & I915_SHRINK_BOUND) &&
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index 5c81f4b4813a..2053194a8b70 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -474,15 +474,6 @@ static int igt_mmap_offset_exhaustion(void *arg)
pr_err("[loop %d] Failed to busy the object\n", loop);
goto err_obj;
}
-
-   /* NB we rely on the _active_ reference to access obj now */
-   GEM_BUG_O

[Intel-gfx] [PATCH 10/22] dma-fence: Propagate errors to dma-fence-array container

2019-06-17 Thread Chris Wilson
When one of the array of fences is signaled, propagate its errors to the
parent fence-array (keeping the first error to be raised).

v2: Opencode cmpxchg_local to avoid compiler freakout.

Signed-off-by: Chris Wilson 
Cc: Sumit Semwal 
Cc: Gustavo Padovan 
---
 drivers/dma-buf/dma-fence-array.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/dma-buf/dma-fence-array.c 
b/drivers/dma-buf/dma-fence-array.c
index 12c6f64c0bc2..d90675bb4fcc 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -13,6 +13,12 @@
 #include 
 #include 
 
+static void fence_set_error_once(struct dma_fence *fence, int error)
+{
+   if (!fence->error && error)
+   dma_fence_set_error(fence, error);
+}
+
 static const char *dma_fence_array_get_driver_name(struct dma_fence *fence)
 {
return "dma_fence_array";
@@ -38,6 +44,13 @@ static void dma_fence_array_cb_func(struct dma_fence *f,
container_of(cb, struct dma_fence_array_cb, cb);
struct dma_fence_array *array = array_cb->array;
 
+   /*
+* Propagate the first error reported by any of our fences, but only
+* before we ourselves are signaled.
+*/
+   if (atomic_read(&array->num_pending) > 0)
+   fence_set_error_once(&array->base, f->error);
+
if (atomic_dec_and_test(&array->num_pending))
irq_work_queue(&array->work);
else
@@ -63,6 +76,8 @@ static bool dma_fence_array_enable_signaling(struct dma_fence 
*fence)
dma_fence_get(&array->base);
if (dma_fence_add_callback(array->fences[i], &cb[i].cb,
   dma_fence_array_cb_func)) {
+   fence_set_error_once(&array->base,
+array->fences[i]->error);
dma_fence_put(&array->base);
if (atomic_dec_and_test(&array->num_pending))
return false;
-- 
2.20.1

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

[Intel-gfx] [PATCH 15/22] drm/i915: Provide an i915_active.acquire callback

2019-06-17 Thread Chris Wilson
If we introduce a callback for i915_active that is only called the first
time we use the i915_active and is symmetrically paired with the
i915_active.retire callback, we can replace the open-coded and
non-atomic implementations -- which will be very fragile (i.e. broken)
upon removing the struct_mutex serialisation.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c  |   8 +-
 drivers/gpu/drm/i915/gt/intel_context.c  |  82 ---
 drivers/gpu/drm/i915/gt/intel_context.h  |  14 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c  |   6 +-
 drivers/gpu/drm/i915/gt/intel_ringbuffer.c   |   2 +-
 drivers/gpu/drm/i915/gt/mock_engine.c|   2 +-
 drivers/gpu/drm/i915/i915_active.c   | 217 ++-
 drivers/gpu/drm/i915/i915_active.h   |  25 ++-
 drivers/gpu/drm/i915/i915_active_types.h |  10 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c  |   2 +-
 drivers/gpu/drm/i915/i915_timeline.c |  16 +-
 drivers/gpu/drm/i915/i915_vma.c  |  22 +-
 drivers/gpu/drm/i915/selftests/i915_active.c |  12 +-
 13 files changed, 225 insertions(+), 193 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 1ce122f4ed25..9262a1d4f763 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -923,8 +923,12 @@ static int context_barrier_task(struct i915_gem_context 
*ctx,
if (!cb)
return -ENOMEM;
 
-   i915_active_init(i915, &cb->base, cb_retire);
-   i915_active_acquire(&cb->base);
+   i915_active_init(i915, &cb->base, NULL, cb_retire);
+   err = i915_active_acquire(&cb->base);
+   if (err) {
+   kfree(cb);
+   return err;
+   }
 
for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it) {
struct i915_request *rq;
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 2c454f227c2e..b19aa823a51a 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -95,11 +95,14 @@ void intel_context_unpin(struct intel_context *ce)
intel_context_put(ce);
 }
 
-static int __context_pin_state(struct i915_vma *vma, unsigned long flags)
+static int __context_pin_state(struct i915_vma *vma)
 {
+   u64 flags;
int err;
 
-   err = i915_vma_pin(vma, 0, 0, flags | PIN_GLOBAL);
+   flags = PIN_HIGH | PIN_GLOBAL;
+   flags |= i915_vm_to_ggtt(vma->vm)->pin_bias | PIN_OFFSET_BIAS;
+   err = i915_vma_pin(vma, 0, 0, flags);
if (err)
return err;
 
@@ -119,7 +122,7 @@ static void __context_unpin_state(struct i915_vma *vma)
__i915_vma_unpin(vma);
 }
 
-static void intel_context_retire(struct i915_active *active)
+static void __intel_context_retire(struct i915_active *active)
 {
struct intel_context *ce = container_of(active, typeof(*ce), active);
 
@@ -129,65 +132,58 @@ static void intel_context_retire(struct i915_active 
*active)
intel_context_put(ce);
 }
 
-void
-intel_context_init(struct intel_context *ce,
-  struct i915_gem_context *ctx,
-  struct intel_engine_cs *engine)
-{
-   GEM_BUG_ON(!engine->cops);
-
-   kref_init(&ce->ref);
-
-   ce->gem_context = ctx;
-   ce->engine = engine;
-   ce->ops = engine->cops;
-   ce->sseu = engine->sseu;
-
-   INIT_LIST_HEAD(&ce->signal_link);
-   INIT_LIST_HEAD(&ce->signals);
-
-   mutex_init(&ce->pin_mutex);
-
-   i915_active_init(ctx->i915, &ce->active, intel_context_retire);
-}
-
-int intel_context_active_acquire(struct intel_context *ce, unsigned long flags)
+static int __intel_context_active(struct i915_active *active)
 {
+   struct intel_context *ce = container_of(active, typeof(*ce), active);
int err;
 
-   if (!i915_active_acquire(&ce->active))
-   return 0;
-
intel_context_get(ce);
 
if (!ce->state)
return 0;
 
-   err = __context_pin_state(ce->state, flags);
-   if (err) {
-   i915_active_cancel(&ce->active);
-   intel_context_put(ce);
-   return err;
-   }
+   err = __context_pin_state(ce->state);
+   if (err)
+   goto err_put;
 
/* Preallocate tracking nodes */
if (!i915_gem_context_is_kernel(ce->gem_context)) {
err = i915_active_acquire_preallocate_barrier(&ce->active,
  ce->engine);
-   if (err) {
-   i915_active_release(&ce->active);
-   return err;
-   }
+   if (err)
+   goto err_unpin;
}
 
return 0;
+
+err_unpin:
+   __context_unpin_state(ce->state);
+err_put:
+   intel_context_put(ce);
+   return err;
 }
 
-void intel_co

[Intel-gfx] [PATCH 12/22] dma-fence: Refactor signaling for manual invocation

2019-06-17 Thread Chris Wilson
Move the duplicated code within dma-fence.c into the header for wider
reuse. In the process apply a small micro-optimisation to only prune the
fence->cb_list once rather than use list_del on every entry.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/dma-buf/Makefile|  10 +-
 drivers/dma-buf/dma-fence-trace.c   |  28 +++
 drivers/dma-buf/dma-fence.c |  33 +--
 drivers/gpu/drm/i915/gt/intel_breadcrumbs.c |  32 +--
 include/linux/dma-fence-impl.h  |  84 +++
 include/linux/dma-fence-types.h | 252 
 include/linux/dma-fence.h   | 222 +
 7 files changed, 381 insertions(+), 280 deletions(-)
 create mode 100644 drivers/dma-buf/dma-fence-trace.c
 create mode 100644 include/linux/dma-fence-impl.h
 create mode 100644 include/linux/dma-fence-types.h

diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index e8c7310cb800..65c43778e571 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -1,6 +1,12 @@
 # SPDX-License-Identifier: GPL-2.0-only
-obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \
-reservation.o seqno-fence.o
+obj-y := \
+   dma-buf.o \
+   dma-fence.o \
+   dma-fence-array.o \
+   dma-fence-chain.o \
+   dma-fence-trace.o \
+   reservation.o \
+   seqno-fence.o
 obj-$(CONFIG_SYNC_FILE)+= sync_file.o
 obj-$(CONFIG_SW_SYNC)  += sw_sync.o sync_debug.o
 obj-$(CONFIG_UDMABUF)  += udmabuf.o
diff --git a/drivers/dma-buf/dma-fence-trace.c 
b/drivers/dma-buf/dma-fence-trace.c
new file mode 100644
index ..eb6f282be4c0
--- /dev/null
+++ b/drivers/dma-buf/dma-fence-trace.c
@@ -0,0 +1,28 @@
+/*
+ * Fence mechanism for dma-buf and to allow for asynchronous dma access
+ *
+ * Copyright (C) 2012 Canonical Ltd
+ * Copyright (C) 2012 Texas Instruments
+ *
+ * Authors:
+ * Rob Clark 
+ * Maarten Lankhorst 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include 
+
+#define CREATE_TRACE_POINTS
+#include 
+
+EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit);
+EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal);
+EXPORT_TRACEPOINT_SYMBOL(dma_fence_signaled);
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 59ac96ec7ba8..027a6a894abd 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -14,15 +14,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
-#define CREATE_TRACE_POINTS
-#include 
-
-EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit);
-EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal);
-EXPORT_TRACEPOINT_SYMBOL(dma_fence_signaled);
-
 static DEFINE_SPINLOCK(dma_fence_stub_lock);
 static struct dma_fence dma_fence_stub;
 
@@ -128,7 +122,6 @@ EXPORT_SYMBOL(dma_fence_context_alloc);
  */
 int dma_fence_signal_locked(struct dma_fence *fence)
 {
-   struct dma_fence_cb *cur, *tmp;
int ret = 0;
 
lockdep_assert_held(fence->lock);
@@ -136,7 +129,7 @@ int dma_fence_signal_locked(struct dma_fence *fence)
if (WARN_ON(!fence))
return -EINVAL;
 
-   if (test_and_set_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
+   if (!__dma_fence_signal(fence)) {
ret = -EINVAL;
 
/*
@@ -144,15 +137,10 @@ int dma_fence_signal_locked(struct dma_fence *fence)
 * still run through all callbacks
 */
} else {
-   fence->timestamp = ktime_get();
-   set_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags);
-   trace_dma_fence_signaled(fence);
+   __dma_fence_signal__timestamp(fence, ktime_get());
}
 
-   list_for_each_entry_safe(cur, tmp, &fence->cb_list, node) {
-   list_del_init(&cur->node);
-   cur->func(fence, cur);
-   }
+   __dma_fence_signal__notify(fence);
return ret;
 }
 EXPORT_SYMBOL(dma_fence_signal_locked);
@@ -177,21 +165,14 @@ int dma_fence_signal(struct dma_fence *fence)
if (!fence)
return -EINVAL;
 
-   if (test_and_set_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
+   if (!__dma_fence_signal(fence))
return -EINVAL;
 
-   fence->timestamp = ktime_get();
-   set_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags);
-   trace_dma_fence_signaled(fence);
+   __dma_fence_signal__timestamp(fence, ktime_get());
 
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &fence->flags)) {
-   struct dma_fence_cb *cur, *tmp;
-
spin_lock

[Intel-gfx] [PATCH 08/22] drm/i915/execlists: Force preemption

2019-06-17 Thread Chris Wilson
If the preempted context takes too long to relinquish control, e.g. it
is stuck inside a shader with arbitration disabled, evict that context
with an engine reset. This ensures that preemptions are reasonably
responsive, providing a tighter QoS for the more important context at
the cost of flagging unresponsive contexts more frequently (i.e. instead
of using an ~10s hangcheck, we now evict at ~10ms).  The challenge of
lies in picking a timeout that can be reasonably serviced by HW for
typical workloads, balancing the existing clients against the needs for
responsiveness.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/Kconfig.profile | 12 ++
 drivers/gpu/drm/i915/gt/intel_lrc.c  | 56 ++--
 2 files changed, 65 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig.profile 
b/drivers/gpu/drm/i915/Kconfig.profile
index 48df8889a88a..8273d3baafe4 100644
--- a/drivers/gpu/drm/i915/Kconfig.profile
+++ b/drivers/gpu/drm/i915/Kconfig.profile
@@ -25,3 +25,15 @@ config DRM_I915_SPIN_REQUEST
  May be 0 to disable the initial spin. In practice, we estimate
  the cost of enabling the interrupt (if currently disabled) to be
  a few microseconds.
+
+config DRM_I915_PREEMPT_TIMEOUT
+   int "Preempt timeout (ms)"
+   default 10 # milliseconds
+   help
+ How long to wait (in milliseconds) for a preemption event to occur
+ when submitting a new context via execlists. If the current context
+ does not hit an arbitration point and yield to HW before the timer
+ expires, the HW will be reset to allow the more important context
+ to execute.
+
+ May be 0 to disable the timeout.
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index cea08d665ef5..0563fe8398c5 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -887,6 +887,15 @@ enable_timeslice(struct intel_engine_cs *engine)
return last && need_timeslice(engine, last);
 }
 
+static unsigned long preempt_expires(void)
+{
+   unsigned long timeout =
+   msecs_to_jiffies_timeout(CONFIG_DRM_I915_PREEMPT_TIMEOUT);
+
+   barrier();
+   return jiffies + timeout;
+}
+
 static void execlists_dequeue(struct intel_engine_cs *engine)
 {
struct intel_engine_execlists * const execlists = &engine->execlists;
@@ -1218,6 +1227,9 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
*port = execlists_schedule_in(last, port - execlists->pending);
memset(port + 1, 0, (last_port - port) * sizeof(*port));
execlists_submit_ports(engine);
+
+   if (CONFIG_DRM_I915_PREEMPT_TIMEOUT)
+   mod_timer(&execlists->timer, preempt_expires());
}
 }
 
@@ -1373,13 +1385,48 @@ static void process_csb(struct intel_engine_cs *engine)
invalidate_csb_entries(&buf[0], &buf[num_entries - 1]);
 }
 
-static void __execlists_submission_tasklet(struct intel_engine_cs *const 
engine)
+static bool __execlists_submission_tasklet(struct intel_engine_cs *const 
engine)
 {
lockdep_assert_held(&engine->active.lock);
 
process_csb(engine);
-   if (!engine->execlists.pending[0])
+   if (!engine->execlists.pending[0]) {
execlists_dequeue(engine);
+   return true;
+   }
+
+   return false;
+}
+
+static void preempt_reset(struct intel_engine_cs *engine)
+{
+   const unsigned int bit = I915_RESET_ENGINE + engine->id;
+   unsigned long *lock = &engine->i915->gpu_error.flags;
+
+   if (test_and_set_bit(bit, lock))
+   return;
+
+   tasklet_disable_nosync(&engine->execlists.tasklet);
+   spin_unlock(&engine->active.lock);
+
+   i915_reset_engine(engine, "preemption time out");
+
+   spin_lock(&engine->active.lock);
+   tasklet_enable(&engine->execlists.tasklet);
+
+   clear_bit(bit, lock);
+   wake_up_bit(lock, bit);
+}
+
+static bool preempt_timeout(struct intel_engine_cs *const engine)
+{
+   if (!CONFIG_DRM_I915_PREEMPT_TIMEOUT)
+   return false;
+
+   if (!intel_engine_has_preemption(engine))
+   return false;
+
+   return !timer_pending(&engine->execlists.timer);
 }
 
 /*
@@ -1392,7 +1439,10 @@ static void execlists_submission_tasklet(unsigned long 
data)
unsigned long flags;
 
spin_lock_irqsave(&engine->active.lock, flags);
-   __execlists_submission_tasklet(engine);
+
+   if (!__execlists_submission_tasklet(engine) && preempt_timeout(engine))
+   preempt_reset(engine);
+
spin_unlock_irqrestore(&engine->active.lock, flags);
 }
 
-- 
2.20.1

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

[Intel-gfx] [PATCH 11/22] dma-fence: Report the composite sync_file status

2019-06-17 Thread Chris Wilson
Same as for the individual fences, we want to report the actual status
of the fence when queried.

Reported-by: Petri Latvala 
Signed-off-by: Chris Wilson 
Cc: Sumit Semwal 
Cc: Gustavo Padovan 
Cc: Petri Latvala 
---
 drivers/dma-buf/sync_file.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index ee4d1a96d779..25c5c071645b 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -419,7 +419,7 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
 * info->num_fences.
 */
if (!info.num_fences) {
-   info.status = dma_fence_is_signaled(sync_file->fence);
+   info.status = dma_fence_get_status(sync_file->fence);
goto no_fences;
} else {
info.status = 1;
-- 
2.20.1

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

[Intel-gfx] [PATCH 22/22] drm/i915: Move idle barrier cleanup into engine-pm

2019-06-17 Thread Chris Wilson
Now that we now longer need to guarantee that the active callback is
under the struct_mutex, we can lift it out of the i915_gem_park() and
into the engine parking itself.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/i915_gem_pm.c| 19 ---
 drivers/gpu/drm/i915/gt/intel_engine_pm.c | 15 +++
 2 files changed, 15 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index c9433cde4b9a..364cd8bea44a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -10,29 +10,10 @@
 #include "i915_drv.h"
 #include "i915_globals.h"
 
-static void call_idle_barriers(struct intel_engine_cs *engine)
-{
-   struct llist_node *node, *next;
-
-   llist_for_each_safe(node, next, llist_del_all(&engine->barrier_tasks)) {
-   struct dma_fence_cb *cb =
-   container_of((struct list_head *)node,
-typeof(*cb), node);
-
-   cb->func(NULL, cb);
-   }
-}
-
 static void i915_gem_park(struct drm_i915_private *i915)
 {
-   struct intel_engine_cs *engine;
-   enum intel_engine_id id;
-
lockdep_assert_held(&i915->drm.struct_mutex);
 
-   for_each_engine(engine, i915, id)
-   call_idle_barriers(engine); /* cleanup after wedging */
-
i915_timelines_park(i915);
i915_vma_parked(i915);
 
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c 
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index d5d3aac5c268..5488c3e557de 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -96,6 +96,19 @@ static bool switch_to_kernel_context(struct intel_engine_cs 
*engine)
return false;
 }
 
+static void call_idle_barriers(struct intel_engine_cs *engine)
+{
+   struct llist_node *node, *next;
+
+   llist_for_each_safe(node, next, llist_del_all(&engine->barrier_tasks)) {
+   struct dma_fence_cb *cb =
+   container_of((struct list_head *)node,
+typeof(*cb), node);
+
+   cb->func(NULL, cb);
+   }
+}
+
 static int __engine_park(struct intel_wakeref *wf)
 {
struct intel_engine_cs *engine =
@@ -115,6 +128,8 @@ static int __engine_park(struct intel_wakeref *wf)
 
GEM_TRACE("%s\n", engine->name);
 
+   call_idle_barriers(engine); /* cleanup after wedging */
+
intel_engine_disarm_breadcrumbs(engine);
intel_engine_pool_park(&engine->pool);
 
-- 
2.20.1

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

[Intel-gfx] [PATCH 13/22] dma-fence: Always execute signal callbacks

2019-06-17 Thread Chris Wilson
Allow for some users to surreptiously insert lazy signal callbacks that
do not depend on enabling the signaling mechanism around every fence.
This means that we may have a cb_list even if the signaling bit is not
enabled, so always notify the callbacks.

The cost is that dma_fence_signal() must always acquire the spinlock to
ensure that the cb_list is flushed.

Signed-off-by: Chris Wilson 
---
 drivers/dma-buf/dma-fence.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 027a6a894abd..ab4a456bba04 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -170,11 +170,9 @@ int dma_fence_signal(struct dma_fence *fence)
 
__dma_fence_signal__timestamp(fence, ktime_get());
 
-   if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &fence->flags)) {
-   spin_lock_irqsave(fence->lock, flags);
-   __dma_fence_signal__notify(fence);
-   spin_unlock_irqrestore(fence->lock, flags);
-   }
+   spin_lock_irqsave(fence->lock, flags);
+   __dma_fence_signal__notify(fence);
+   spin_unlock_irqrestore(fence->lock, flags);
return 0;
 }
 EXPORT_SYMBOL(dma_fence_signal);
-- 
2.20.1

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

[Intel-gfx] [PATCH 04/22] drm/i915: Stop passing I915_WAIT_LOCKED to i915_request_wait()

2019-06-17 Thread Chris Wilson
Since commit eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on
struct_mutex"), the I915_WAIT_LOCKED flags passed to i915_request_wait()
has been defunct. Now go ahead and remove it from all callers.

References: eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on 
struct_mutex")
Signed-off-by: Chris Wilson 
---
 .../drm/i915/gem/selftests/i915_gem_context.c | 14 +++--
 drivers/gpu/drm/i915/gt/intel_ringbuffer.c|  2 +-
 drivers/gpu/drm/i915/gt/intel_workarounds.c   |  2 +-
 drivers/gpu/drm/i915/gt/selftest_hangcheck.c  |  9 ++
 drivers/gpu/drm/i915/gt/selftest_lrc.c| 24 ++-
 .../gpu/drm/i915/gt/selftest_workarounds.c|  6 ++--
 drivers/gpu/drm/i915/i915_active.h|  2 +-
 drivers/gpu/drm/i915/i915_request.c   |  4 ---
 drivers/gpu/drm/i915/i915_trace.h |  3 +-
 drivers/gpu/drm/i915/selftests/i915_request.c | 30 +++
 .../gpu/drm/i915/selftests/i915_timeline.c|  6 ++--
 11 files changed, 36 insertions(+), 66 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index 03ac5003abf1..eaa2b16574c7 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -83,9 +83,7 @@ static int live_nop_switch(void *arg)
}
i915_request_add(rq);
}
-   if (i915_request_wait(rq,
- I915_WAIT_LOCKED,
- HZ / 5) < 0) {
+   if (i915_request_wait(rq, 0, HZ / 5) < 0) {
pr_err("Failed to populated %d contexts\n", nctx);
i915_gem_set_wedged(i915);
err = -EIO;
@@ -128,9 +126,7 @@ static int live_nop_switch(void *arg)
 
i915_request_add(rq);
}
-   if (i915_request_wait(rq,
- I915_WAIT_LOCKED,
- HZ / 5) < 0) {
+   if (i915_request_wait(rq, 0, HZ / 5) < 0) {
pr_err("Switching between %ld contexts timed 
out\n",
   prime);
i915_gem_set_wedged(i915);
@@ -893,7 +889,7 @@ __read_slice_count(struct drm_i915_private *i915,
if (spin)
igt_spinner_end(spin);
 
-   ret = i915_request_wait(rq, I915_WAIT_LOCKED, MAX_SCHEDULE_TIMEOUT);
+   ret = i915_request_wait(rq, 0, MAX_SCHEDULE_TIMEOUT);
i915_request_put(rq);
if (ret < 0)
return ret;
@@ -980,9 +976,7 @@ __sseu_finish(struct drm_i915_private *i915,
igt_spinner_end(spin);
 
if ((flags & TEST_IDLE) && ret == 0) {
-   ret = i915_gem_wait_for_idle(i915,
-I915_WAIT_LOCKED,
-MAX_SCHEDULE_TIMEOUT);
+   ret = i915_gem_wait_for_idle(i915, 0, MAX_SCHEDULE_TIMEOUT);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/i915/gt/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
index 019bf039f616..f82190987206 100644
--- a/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
@@ -1815,7 +1815,7 @@ static noinline int wait_for_space(struct intel_ring 
*ring, unsigned int bytes)
return -ENOSPC;
 
timeout = i915_request_wait(target,
-   I915_WAIT_INTERRUPTIBLE | I915_WAIT_LOCKED,
+   I915_WAIT_INTERRUPTIBLE,
MAX_SCHEDULE_TIMEOUT);
if (timeout < 0)
return timeout;
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 165b0a45e009..9624d9e776e3 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1384,7 +1384,7 @@ static int engine_wa_list_verify(struct intel_context *ce,
goto err_vma;
 
i915_request_add(rq);
-   if (i915_request_wait(rq, I915_WAIT_LOCKED, HZ / 5) < 0) {
+   if (i915_request_wait(rq, 0, HZ / 5) < 0) {
err = -ETIME;
goto err_vma;
}
diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c 
b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
index b0b2998e56b8..1ee4c923044f 100644
--- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
@@ -339,8 +339,7 @@ static int igt_hang_sanitycheck(void *arg)
 
timeout = 0;
igt_wedge_on_timeout(&w, i915, HZ / 10 /* 100ms timeout*/)
-   timeout = i915_request_wait(rq,
-   

[Intel-gfx] [PATCH 01/22] drm/i915: Restore -Wunused-but-set-variable

2019-06-17 Thread Chris Wilson
We appear to be clear of this warning, so time to re-enable the gcc error
checking.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index c0a7b2994077..f4971900087a 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -17,7 +17,6 @@ subdir-ccflags-y += $(call cc-disable-warning, 
unused-parameter)
 subdir-ccflags-y += $(call cc-disable-warning, type-limits)
 subdir-ccflags-y += $(call cc-disable-warning, missing-field-initializers)
 subdir-ccflags-y += $(call cc-disable-warning, implicit-fallthrough)
-subdir-ccflags-y += $(call cc-disable-warning, unused-but-set-variable)
 # clang warnings
 subdir-ccflags-y += $(call cc-disable-warning, sign-compare)
 subdir-ccflags-y += $(call cc-disable-warning, sometimes-uninitialized)
-- 
2.20.1

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

[Intel-gfx] [PATCH 19/22] drm/i915: Extract intel_frontbuffer active tracking

2019-06-17 Thread Chris Wilson
Move the active tracking for the frontbuffer operations out of the
i915_gem_object and into its own first class (refcounted) object. In the
process of detangling, we switch from low level request tracking to the
easier i915_active -- with the plan that this avoids any potential
atomic callbacks as the frontbuffer tracking wishes to sleep as it
flushes.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/i915_gem_clflush.c   |   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_domain.c|  14 +-
 drivers/gpu/drm/i915/gem/i915_gem_mman.c  |   4 -
 drivers/gpu/drm/i915/gem/i915_gem_object.c|  28 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.h|   2 +-
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |   8 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |   5 -
 drivers/gpu/drm/i915/i915_drv.h   |   4 -
 drivers/gpu/drm/i915/i915_gem.c   |  47 +---
 drivers/gpu/drm/i915/i915_vma.c   |   6 +-
 drivers/gpu/drm/i915/intel_display.c  |  67 +++--
 drivers/gpu/drm/i915/intel_drv.h  |   1 +
 drivers/gpu/drm/i915/intel_fbdev.c|  22 +-
 drivers/gpu/drm/i915/intel_frontbuffer.c  | 255 +-
 drivers/gpu/drm/i915/intel_frontbuffer.h  |  70 +++--
 drivers/gpu/drm/i915/intel_overlay.c  |   8 +-
 16 files changed, 300 insertions(+), 243 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c 
b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
index 537aa2337cc8..54b447539430 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
@@ -47,7 +47,7 @@ static void __i915_do_clflush(struct drm_i915_gem_object *obj)
 {
GEM_BUG_ON(!i915_gem_object_has_pages(obj));
drm_clflush_sg(obj->mm.pages);
-   intel_fb_obj_flush(obj, ORIGIN_CPU);
+   intel_frontbuffer_flush(obj->frontbuffer, ORIGIN_CPU);
 }
 
 static void i915_clflush_work(struct work_struct *work)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index bd180ef46aeb..7e6ed767348c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -550,13 +550,6 @@ i915_gem_object_set_to_cpu_domain(struct 
drm_i915_gem_object *obj, bool write)
return 0;
 }
 
-static inline enum fb_op_origin
-fb_write_origin(struct drm_i915_gem_object *obj, unsigned int domain)
-{
-   return (domain == I915_GEM_DOMAIN_GTT ?
-   obj->frontbuffer_ggtt_origin : ORIGIN_CPU);
-}
-
 /**
  * Called when user space prepares to use an object with the CPU, either
  * through the mmap ioctl's mapping or a GTT mapping.
@@ -660,9 +653,8 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void 
*data,
 
i915_gem_object_unlock(obj);
 
-   if (write_domain != 0)
-   intel_fb_obj_invalidate(obj,
-   fb_write_origin(obj, write_domain));
+   if (write_domain)
+   intel_frontbuffer_invalidate(obj->frontbuffer, ORIGIN_CPU);
 
 out_unpin:
i915_gem_object_unpin_pages(obj);
@@ -782,7 +774,7 @@ int i915_gem_object_prepare_write(struct 
drm_i915_gem_object *obj,
}
 
 out:
-   intel_fb_obj_invalidate(obj, ORIGIN_CPU);
+   intel_frontbuffer_invalidate(obj->frontbuffer, ORIGIN_CPU);
obj->mm.dirty = true;
/* return with the pages pinned */
return 0;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 391621ee3cbb..bcc53c2b4f69 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -99,9 +99,6 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
up_write(&mm->mmap_sem);
if (IS_ERR_VALUE(addr))
goto err;
-
-   /* This may race, but that's ok, it only gets set */
-   WRITE_ONCE(obj->frontbuffer_ggtt_origin, ORIGIN_CPU);
}
i915_gem_object_put(obj);
 
@@ -281,7 +278,6 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
 * Userspace is now writing through an untracked VMA, abandon
 * all hope that the hardware is able to track future writes.
 */
-   obj->frontbuffer_ggtt_origin = ORIGIN_CPU;
 
vma = i915_gem_object_ggtt_pin(obj, &view, 0, 0, flags);
if (IS_ERR(vma) && !view.type) {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 252e752da211..91c3998351d9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -44,16 +44,6 @@ void i915_gem_object_free(struct drm_i915_gem_object *obj)
return kmem_cache_free(global.slab_objects, obj);
 }
 
-static void
-frontbuffer_retire(struct i915_active_request *active,
-  struct i915_request *request)
-{
-   struct drm_i915_gem_object *obj =
-

[Intel-gfx] [PATCH 21/22] drm/i915: Replace struct_mutex for batch pool serialisation

2019-06-17 Thread Chris Wilson
Switch to tracking activity via i915_active on individual nodes, only
keeping a list of retired objects in the cache, and reaping the cache
when the engine itself idles.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/Makefile |   2 +-
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  58 ---
 drivers/gpu/drm/i915/gem/i915_gem_object.c|   1 -
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |   1 -
 drivers/gpu/drm/i915/gem/i915_gem_pm.c|   4 +-
 drivers/gpu/drm/i915/gt/intel_engine.h|   1 -
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |  11 +-
 drivers/gpu/drm/i915/gt/intel_engine_pm.c |   2 +
 drivers/gpu/drm/i915/gt/intel_engine_pool.c   | 163 ++
 drivers/gpu/drm/i915/gt/intel_engine_pool.h   |  33 
 .../gpu/drm/i915/gt/intel_engine_pool_types.h |  29 
 drivers/gpu/drm/i915/gt/intel_engine_types.h  |   4 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |  68 
 drivers/gpu/drm/i915/i915_gem_batch_pool.c| 132 --
 drivers/gpu/drm/i915/i915_gem_batch_pool.h|  26 ---
 15 files changed, 271 insertions(+), 264 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_pool.c
 create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_pool.h
 create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_pool_types.h
 delete mode 100644 drivers/gpu/drm/i915/i915_gem_batch_pool.c
 delete mode 100644 drivers/gpu/drm/i915/i915_gem_batch_pool.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index f4971900087a..dc6c22b40efe 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -70,6 +70,7 @@ obj-y += gt/
 gt-y += \
gt/intel_breadcrumbs.o \
gt/intel_context.o \
+   gt/intel_engine_pool.o \
gt/intel_engine_cs.o \
gt/intel_engine_pm.o \
gt/intel_gt_pm.o \
@@ -114,7 +115,6 @@ i915-y += \
  $(gem-y) \
  i915_active.o \
  i915_cmd_parser.o \
- i915_gem_batch_pool.o \
  i915_gem_evict.o \
  i915_gem_fence_reg.o \
  i915_gem_gtt.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index eeb4c6cdb01d..b09be26c4340 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -14,6 +14,7 @@
 
 #include "gem/i915_gem_ioctls.h"
 #include "gt/intel_context.h"
+#include "gt/intel_engine_pool.h"
 #include "gt/intel_gt_pm.h"
 
 #include "i915_gem_ioctls.h"
@@ -1200,25 +1201,26 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
 unsigned int len)
 {
struct reloc_cache *cache = &eb->reloc_cache;
-   struct drm_i915_gem_object *obj;
+   struct intel_engine_pool_node *pool;
struct i915_request *rq;
struct i915_vma *batch;
u32 *cmd;
int err;
 
-   obj = i915_gem_batch_pool_get(&eb->engine->batch_pool, PAGE_SIZE);
-   if (IS_ERR(obj))
-   return PTR_ERR(obj);
+   pool = intel_engine_pool_get(&eb->engine->pool, PAGE_SIZE);
+   if (IS_ERR(pool))
+   return PTR_ERR(pool);
 
-   cmd = i915_gem_object_pin_map(obj,
+   cmd = i915_gem_object_pin_map(pool->obj,
  cache->has_llc ?
  I915_MAP_FORCE_WB :
  I915_MAP_FORCE_WC);
-   i915_gem_object_unpin_pages(obj);
-   if (IS_ERR(cmd))
-   return PTR_ERR(cmd);
+   if (IS_ERR(cmd)) {
+   err = PTR_ERR(cmd);
+   goto out_pool;
+   }
 
-   batch = i915_vma_instance(obj, vma->vm, NULL);
+   batch = i915_vma_instance(pool->obj, vma->vm, NULL);
if (IS_ERR(batch)) {
err = PTR_ERR(batch);
goto err_unmap;
@@ -1234,6 +1236,10 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
goto err_unpin;
}
 
+   err = intel_engine_pool_mark_active(pool, rq);
+   if (err)
+   goto err_request;
+
err = reloc_move_to_gpu(rq, vma);
if (err)
goto err_request;
@@ -1259,7 +1265,7 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
cache->rq_size = 0;
 
/* Return with batch mapping (cmd) still pinned */
-   return 0;
+   goto out_pool;
 
 skip_request:
i915_request_skip(rq, err);
@@ -1268,7 +1274,9 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
 err_unpin:
i915_vma_unpin(batch);
 err_unmap:
-   i915_gem_object_unpin_map(obj);
+   i915_gem_object_unpin_map(pool->obj);
+out_pool:
+   intel_engine_pool_put(pool);
return err;
 }
 
@@ -2012,18 +2020,17 @@ static int i915_reset_gen7_sol_offsets(struct 
i915_request *rq)
 
 static struct i915_vma *eb_parse(struct i915_execbuffer *eb, bool is_master)
 {
-   struct drm_i915_gem_object *shadow_batch_obj;
+   struct 

[Intel-gfx] [PATCH 20/22] drm/i915: Coordinate i915_active with its own mutex

2019-06-17 Thread Chris Wilson
Forgo the struct_mutex serialisation for i915_active, and interpose its
own mutex handling for active/retire.

This is a multi-layered sleight-of-hand. First, we had to ensure that no
active/retire callbacks accidentally inverted the mutex ordering rules,
nor assumed that they were themselves serialised by struct_mutex. More
challenging though, is the rule over updating elements of the active
rbtree. Instead of the whole i915_active now being serialised by
struct_mutex, allocations/rotations of the tree are serialised by the
i915_active.mutex and individual nodes are serialised by the caller
using the i915_timeline.mutex (we need to use nested spinlocks to
interact with the dma_fence callback lists).

The pain point here is that instead of a single mutex around execbuf, we
now have to take a mutex for active tracker (one for each vma, context,
etc) and a couple of spinlocks for each fence update. The improvement in
fine grained locking allowing for multiple concurrent clients
(eventually!) should be worth it in typical loads.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   |  12 +-
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|   2 +-
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |   2 +
 drivers/gpu/drm/i915/gem/i915_gem_pm.c|   9 +-
 drivers/gpu/drm/i915/gt/intel_context.c   |   2 +-
 drivers/gpu/drm/i915/gt/intel_reset.c |  10 +-
 drivers/gpu/drm/i915/gt/selftest_lrc.c|  10 +-
 drivers/gpu/drm/i915/gvt/scheduler.c  |   3 -
 drivers/gpu/drm/i915/i915_active.c| 149 +
 drivers/gpu/drm/i915/i915_active.h| 305 --
 drivers/gpu/drm/i915/i915_active_types.h  |  17 +-
 drivers/gpu/drm/i915/i915_gem.c   |  42 ++-
 drivers/gpu/drm/i915/i915_gem_gtt.c   |   2 +-
 drivers/gpu/drm/i915/i915_request.c   |  49 +--
 drivers/gpu/drm/i915/i915_request.h   |   1 -
 drivers/gpu/drm/i915/i915_timeline.c  |   9 +-
 drivers/gpu/drm/i915/i915_timeline_types.h|   2 +-
 drivers/gpu/drm/i915/i915_vma.c   |  36 +--
 drivers/gpu/drm/i915/intel_frontbuffer.c  |   2 +-
 drivers/gpu/drm/i915/intel_overlay.c  |   6 +-
 drivers/gpu/drm/i915/selftests/i915_active.c  |  22 +-
 .../gpu/drm/i915/selftests/mock_timeline.c|   2 +-
 22 files changed, 225 insertions(+), 469 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c85468d517ef..0cd0b2a830b9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -911,20 +911,18 @@ static int context_barrier_task(struct i915_gem_context 
*ctx,
void (*task)(void *data),
void *data)
 {
-   struct drm_i915_private *i915 = ctx->i915;
struct context_barrier_task *cb;
struct i915_gem_engines_iter it;
struct intel_context *ce;
int err = 0;
 
-   lockdep_assert_held(&i915->drm.struct_mutex);
GEM_BUG_ON(!task);
 
cb = kmalloc(sizeof(*cb), GFP_KERNEL);
if (!cb)
return -ENOMEM;
 
-   i915_active_init(i915, &cb->base, NULL, cb_retire);
+   i915_active_init(&cb->base, NULL, cb_retire);
err = i915_active_acquire(&cb->base);
if (err) {
kfree(cb);
@@ -956,7 +954,9 @@ static int context_barrier_task(struct i915_gem_context 
*ctx,
if (emit)
err = emit(rq, data);
if (err == 0)
-   err = i915_active_ref(&cb->base, rq->fence.context, rq);
+   err = i915_active_ref(&cb->base,
+ rq->fence.context,
+ &rq->fence);
 
i915_request_add(rq);
if (err)
@@ -1193,7 +1193,7 @@ gen8_modify_rpcs(struct intel_context *ce, struct 
intel_sseu sseu)
return PTR_ERR(rq);
 
/* Queue this switch after all other activity by this context. */
-   ret = i915_active_request_set(&ce->ring->timeline->last_request, rq);
+   ret = i915_active_fence_set(&ce->ring->timeline->last_request, rq);
if (ret)
goto out_add;
 
@@ -1205,7 +1205,7 @@ gen8_modify_rpcs(struct intel_context *ce, struct 
intel_sseu sseu)
 * words transfer the pinned ce object to tracked active request.
 */
GEM_BUG_ON(i915_active_is_idle(&ce->active));
-   ret = i915_active_ref(&ce->active, rq->fence.context, rq);
+   ret = i915_active_ref(&ce->active, rq->fence.context, &rq->fence);
if (ret)
goto out_add;
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 528eea44dccf..eeb4c6cdb01d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -131

[Intel-gfx] [PATCH 05/22] drm/i915: Flush the execution-callbacks on retiring

2019-06-17 Thread Chris Wilson
In the unlikely case the request completes while we regard it as not even
executing on the GPU (see the next patch!), we have to flush any pending
execution callbacks at retirement and ensure that we do not add any
more.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_request.c | 93 +++--
 1 file changed, 49 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index d7fd77e8a789..51b068a57193 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -119,6 +119,50 @@ const struct dma_fence_ops i915_fence_ops = {
.release = i915_fence_release,
 };
 
+static void irq_execute_cb(struct irq_work *wrk)
+{
+   struct execute_cb *cb = container_of(wrk, typeof(*cb), work);
+
+   i915_sw_fence_complete(cb->fence);
+   kmem_cache_free(global.slab_execute_cbs, cb);
+}
+
+static void irq_execute_cb_hook(struct irq_work *wrk)
+{
+   struct execute_cb *cb = container_of(wrk, typeof(*cb), work);
+
+   cb->hook(container_of(cb->fence, struct i915_request, submit),
+&cb->signal->fence);
+   i915_request_put(cb->signal);
+
+   irq_execute_cb(wrk);
+}
+
+static void __notify_execute_cb(struct i915_request *rq)
+{
+   struct execute_cb *cb;
+
+   lockdep_assert_held(&rq->lock);
+
+   if (list_empty(&rq->execute_cb))
+   return;
+
+   list_for_each_entry(cb, &rq->execute_cb, link)
+   irq_work_queue(&cb->work);
+
+   /*
+* XXX Rollback on __i915_request_unsubmit()
+*
+* In the future, perhaps when we have an active time-slicing scheduler,
+* it will be interesting to unsubmit parallel execution and remove
+* busywaits from the GPU until their master is restarted. This is
+* quite hairy, we have to carefully rollback the fence and do a
+* preempt-to-idle cycle on the target engine, all the while the
+* master execute_cb may refire.
+*/
+   INIT_LIST_HEAD(&rq->execute_cb);
+}
+
 static inline void
 i915_request_remove_from_client(struct i915_request *request)
 {
@@ -246,6 +290,11 @@ static bool i915_request_retire(struct i915_request *rq)
GEM_BUG_ON(!atomic_read(&rq->i915->gt_pm.rps.num_waiters));
atomic_dec(&rq->i915->gt_pm.rps.num_waiters);
}
+   if (!test_bit(I915_FENCE_FLAG_ACTIVE, &rq->fence.flags)) {
+   set_bit(I915_FENCE_FLAG_ACTIVE, &rq->fence.flags);
+   __notify_execute_cb(rq);
+   }
+   GEM_BUG_ON(!list_empty(&rq->execute_cb));
spin_unlock(&rq->lock);
 
local_irq_enable();
@@ -285,50 +334,6 @@ void i915_request_retire_upto(struct i915_request *rq)
} while (i915_request_retire(tmp) && tmp != rq);
 }
 
-static void irq_execute_cb(struct irq_work *wrk)
-{
-   struct execute_cb *cb = container_of(wrk, typeof(*cb), work);
-
-   i915_sw_fence_complete(cb->fence);
-   kmem_cache_free(global.slab_execute_cbs, cb);
-}
-
-static void irq_execute_cb_hook(struct irq_work *wrk)
-{
-   struct execute_cb *cb = container_of(wrk, typeof(*cb), work);
-
-   cb->hook(container_of(cb->fence, struct i915_request, submit),
-&cb->signal->fence);
-   i915_request_put(cb->signal);
-
-   irq_execute_cb(wrk);
-}
-
-static void __notify_execute_cb(struct i915_request *rq)
-{
-   struct execute_cb *cb;
-
-   lockdep_assert_held(&rq->lock);
-
-   if (list_empty(&rq->execute_cb))
-   return;
-
-   list_for_each_entry(cb, &rq->execute_cb, link)
-   irq_work_queue(&cb->work);
-
-   /*
-* XXX Rollback on __i915_request_unsubmit()
-*
-* In the future, perhaps when we have an active time-slicing scheduler,
-* it will be interesting to unsubmit parallel execution and remove
-* busywaits from the GPU until their master is restarted. This is
-* quite hairy, we have to carefully rollback the fence and do a
-* preempt-to-idle cycle on the target engine, all the while the
-* master execute_cb may refire.
-*/
-   INIT_LIST_HEAD(&rq->execute_cb);
-}
-
 static int
 __i915_request_await_execution(struct i915_request *rq,
   struct i915_request *signal,
-- 
2.20.1

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

Re: [Intel-gfx] [PATCH] i915: gvt: no need to check return value of debugfs_create functions

2019-06-17 Thread Zhenyu Wang
On 2019.06.13 15:34:19 +0200, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value.  The function can work or not, but the code logic should
> never do something different based on this.

Looks fine to me. We'd follow this idiom.

Reviewed-by: Zhenyu Wang 

> 
> Because there is no need to check these functions, a number of local
> functions can be made to return void to simplify things as nothing can
> fail.
> 
> Cc: Zhenyu Wang 
> Cc: Zhi Wang 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: intel-gvt-...@lists.freedesktop.org
> Cc: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Greg Kroah-Hartman 
> ---
>  drivers/gpu/drm/i915/gvt/debugfs.c | 47 ++
>  drivers/gpu/drm/i915/gvt/gvt.c |  4 +--
>  drivers/gpu/drm/i915/gvt/gvt.h |  4 +--
>  drivers/gpu/drm/i915/gvt/kvmgt.c   |  3 --
>  drivers/gpu/drm/i915/gvt/vgpu.c|  4 +--
>  5 files changed, 13 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/debugfs.c 
> b/drivers/gpu/drm/i915/gvt/debugfs.c
> index 8a9606f91e68..fdd9058ab8f2 100644
> --- a/drivers/gpu/drm/i915/gvt/debugfs.c
> +++ b/drivers/gpu/drm/i915/gvt/debugfs.c
> @@ -189,36 +189,19 @@ DEFINE_SIMPLE_ATTRIBUTE(vgpu_scan_nonprivbb_fops,
>  /**
>   * intel_gvt_debugfs_add_vgpu - register debugfs entries for a vGPU
>   * @vgpu: a vGPU
> - *
> - * Returns:
> - * Zero on success, negative error code if failed.
>   */
> -int intel_gvt_debugfs_add_vgpu(struct intel_vgpu *vgpu)
> +void intel_gvt_debugfs_add_vgpu(struct intel_vgpu *vgpu)
>  {
> - struct dentry *ent;
>   char name[16] = "";
>  
>   snprintf(name, 16, "vgpu%d", vgpu->id);
>   vgpu->debugfs = debugfs_create_dir(name, vgpu->gvt->debugfs_root);
> - if (!vgpu->debugfs)
> - return -ENOMEM;
> -
> - ent = debugfs_create_bool("active", 0444, vgpu->debugfs,
> -   &vgpu->active);
> - if (!ent)
> - return -ENOMEM;
> -
> - ent = debugfs_create_file("mmio_diff", 0444, vgpu->debugfs,
> -   vgpu, &vgpu_mmio_diff_fops);
> - if (!ent)
> - return -ENOMEM;
>  
> - ent = debugfs_create_file("scan_nonprivbb", 0644, vgpu->debugfs,
> -  vgpu, &vgpu_scan_nonprivbb_fops);
> - if (!ent)
> - return -ENOMEM;
> -
> - return 0;
> + debugfs_create_bool("active", 0444, vgpu->debugfs, &vgpu->active);
> + debugfs_create_file("mmio_diff", 0444, vgpu->debugfs, vgpu,
> + &vgpu_mmio_diff_fops);
> + debugfs_create_file("scan_nonprivbb", 0644, vgpu->debugfs, vgpu,
> + &vgpu_scan_nonprivbb_fops);
>  }
>  
>  /**
> @@ -234,27 +217,15 @@ void intel_gvt_debugfs_remove_vgpu(struct intel_vgpu 
> *vgpu)
>  /**
>   * intel_gvt_debugfs_init - register gvt debugfs root entry
>   * @gvt: GVT device
> - *
> - * Returns:
> - * zero on success, negative if failed.
>   */
> -int intel_gvt_debugfs_init(struct intel_gvt *gvt)
> +void intel_gvt_debugfs_init(struct intel_gvt *gvt)
>  {
>   struct drm_minor *minor = gvt->dev_priv->drm.primary;
> - struct dentry *ent;
>  
>   gvt->debugfs_root = debugfs_create_dir("gvt", minor->debugfs_root);
> - if (!gvt->debugfs_root) {
> - gvt_err("Cannot create debugfs dir\n");
> - return -ENOMEM;
> - }
>  
> - ent = debugfs_create_ulong("num_tracked_mmio", 0444, gvt->debugfs_root,
> -&gvt->mmio.num_tracked_mmio);
> - if (!ent)
> - return -ENOMEM;
> -
> - return 0;
> + debugfs_create_ulong("num_tracked_mmio", 0444, gvt->debugfs_root,
> +  &gvt->mmio.num_tracked_mmio);
>  }
>  
>  /**
> diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
> index 43f4242062dd..8f37eefa0a02 100644
> --- a/drivers/gpu/drm/i915/gvt/gvt.c
> +++ b/drivers/gpu/drm/i915/gvt/gvt.c
> @@ -375,9 +375,7 @@ int intel_gvt_init_device(struct drm_i915_private 
> *dev_priv)
>   }
>   gvt->idle_vgpu = vgpu;
>  
> - ret = intel_gvt_debugfs_init(gvt);
> - if (ret)
> - gvt_err("debugfs registration failed, go on.\n");
> + intel_gvt_debugfs_init(gvt);
>  
>   gvt_dbg_core("gvt device initialization is done\n");
>   dev_priv->gvt = gvt;
> diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
> index f5a328b5290a..b73c7e63b2d5 100644
> --- a/drivers/gpu/drm/i915/gvt/gvt.h
> +++ b/drivers/gpu/drm/i915/gvt/gvt.h
> @@ -682,9 +682,9 @@ static inline void intel_gvt_mmio_set_in_ctx(
>   gvt->mmio.mmio_attribute[offset >> 2] |= F_IN_CTX;
>  }
>  
> -int intel_gvt_debugfs_add_vgpu(struct intel_vgpu *vgpu);
> +void intel_gvt_debugfs_add_vgpu(struct intel_vgpu *vgpu);
>  void intel_gvt_debugfs_remove_vgpu(struct intel_vgpu *vgpu);
> -int intel_gvt_de

Re: [Intel-gfx] [PATCH v3 4/7] lib/hexdump.c: Replace ascii bool in hex_dump_to_buffer with flags

2019-06-17 Thread Jani Nikula
On Mon, 17 Jun 2019, "Alastair D'Silva"  wrote:
> From: Alastair D'Silva 
>
> In order to support additional features in hex_dump_to_buffer, replace
> the ascii bool parameter with flags.
>
> Signed-off-by: Alastair D'Silva 
> ---
>  drivers/gpu/drm/i915/intel_engine_cs.c|  2 +-
>  drivers/isdn/hardware/mISDN/mISDNisar.c   |  6 --
>  drivers/mailbox/mailbox-test.c|  2 +-
>  drivers/net/ethernet/amd/xgbe/xgbe-drv.c  |  2 +-
>  drivers/net/ethernet/synopsys/dwc-xlgmac-common.c |  2 +-
>  drivers/net/wireless/ath/ath10k/debug.c   |  3 ++-
>  drivers/net/wireless/intel/iwlegacy/3945-mac.c|  2 +-
>  drivers/platform/chrome/wilco_ec/debugfs.c|  2 +-
>  drivers/scsi/scsi_logging.c   |  8 +++-
>  drivers/staging/fbtft/fbtft-core.c|  2 +-
>  fs/seq_file.c |  3 ++-
>  include/linux/printk.h|  8 
>  lib/hexdump.c | 15 ---
>  lib/test_hexdump.c|  5 +++--
>  14 files changed, 33 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index eea9bec04f1b..5df5fffdb848 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -1340,7 +1340,7 @@ static void hexdump(struct drm_printer *m, const void 
> *buf, size_t len)
>   WARN_ON_ONCE(hex_dump_to_buffer(buf + pos, len - pos,
>   rowsize, sizeof(u32),
>   line, sizeof(line),
> - false) >= sizeof(line));
> + 0) >= sizeof(line));
>   drm_printf(m, "[%04zx] %s\n", pos, line);
>  
>   prev = buf + pos;

On i915,

Acked-by: Jani Nikula 


-- 
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 17/22] drm/i915/overlay: Switch to using i915_active tracking

2019-06-17 Thread Chris Wilson
Remove the raw i915_active_request tracking in favour of the higher
level i915_active tracking for the sole purpose of making the lockless
transition easier in later patches.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_active.h   |  19 
 drivers/gpu/drm/i915/intel_overlay.c | 130 +--
 2 files changed, 64 insertions(+), 85 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_active.h 
b/drivers/gpu/drm/i915/i915_active.h
index 134166d31251..911a8338007a 100644
--- a/drivers/gpu/drm/i915/i915_active.h
+++ b/drivers/gpu/drm/i915/i915_active.h
@@ -89,25 +89,6 @@ int __must_check
 i915_active_request_set(struct i915_active_request *active,
struct i915_request *rq);
 
-/**
- * i915_active_request_set_retire_fn - updates the retirement callback
- * @active - the active tracker
- * @fn - the routine called when the request is retired
- * @mutex - struct_mutex used to guard retirements
- *
- * i915_active_request_set_retire_fn() updates the function pointer that
- * is called when the final request associated with the @active tracker
- * is retired.
- */
-static inline void
-i915_active_request_set_retire_fn(struct i915_active_request *active,
- i915_active_retire_fn fn,
- struct mutex *mutex)
-{
-   lockdep_assert_held(mutex);
-   active->retire = fn ?: i915_active_retire_noop;
-}
-
 /**
  * i915_active_request_raw - return the active request
  * @active - the active tracker
diff --git a/drivers/gpu/drm/i915/intel_overlay.c 
b/drivers/gpu/drm/i915/intel_overlay.c
index 21339b7f6a3e..c7d2d980df8c 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -190,7 +190,8 @@ struct intel_overlay {
struct overlay_registers __iomem *regs;
u32 flip_addr;
/* flip handling */
-   struct i915_active_request last_flip;
+   struct i915_active last_flip;
+   void (*flip_complete)(struct intel_overlay *ovl);
 };
 
 static void i830_overlay_clock_gating(struct drm_i915_private *dev_priv,
@@ -216,32 +217,26 @@ static void i830_overlay_clock_gating(struct 
drm_i915_private *dev_priv,
  PCI_DEVFN(0, 0), I830_CLOCK_GATE, val);
 }
 
-static void intel_overlay_submit_request(struct intel_overlay *overlay,
-struct i915_request *rq,
-i915_active_retire_fn retire)
+static struct i915_request *
+alloc_request(struct intel_overlay *overlay, void (*fn)(struct intel_overlay 
*))
 {
-   GEM_BUG_ON(i915_active_request_peek(&overlay->last_flip,
-   &overlay->i915->drm.struct_mutex));
-   i915_active_request_set_retire_fn(&overlay->last_flip, retire,
- &overlay->i915->drm.struct_mutex);
-   __i915_active_request_set(&overlay->last_flip, rq);
-   i915_request_add(rq);
-}
+   struct intel_engine_cs *engine = overlay->i915->engine[RCS0];
+   struct i915_request *rq;
+   int err;
 
-static int intel_overlay_do_wait_request(struct intel_overlay *overlay,
-struct i915_request *rq,
-i915_active_retire_fn retire)
-{
-   intel_overlay_submit_request(overlay, rq, retire);
-   return i915_active_request_retire(&overlay->last_flip,
- &overlay->i915->drm.struct_mutex);
-}
+   overlay->flip_complete = fn;
 
-static struct i915_request *alloc_request(struct intel_overlay *overlay)
-{
-   struct intel_engine_cs *engine = overlay->i915->engine[RCS0];
+   rq = i915_request_create(engine->kernel_context);
+   if (IS_ERR(rq))
+   return rq;
+
+   err = i915_active_ref(&overlay->last_flip, rq->fence.context, rq);
+   if (err) {
+   i915_request_add(rq);
+   return ERR_PTR(err);
+   }
 
-   return i915_request_create(engine->kernel_context);
+   return rq;
 }
 
 /* overlay needs to be disable in OCMD reg */
@@ -253,7 +248,7 @@ static int intel_overlay_on(struct intel_overlay *overlay)
 
WARN_ON(overlay->active);
 
-   rq = alloc_request(overlay);
+   rq = alloc_request(overlay, NULL);
if (IS_ERR(rq))
return PTR_ERR(rq);
 
@@ -274,7 +269,9 @@ static int intel_overlay_on(struct intel_overlay *overlay)
*cs++ = MI_NOOP;
intel_ring_advance(rq, cs);
 
-   return intel_overlay_do_wait_request(overlay, rq, NULL);
+   i915_request_add(rq);
+
+   return i915_active_wait(&overlay->last_flip);
 }
 
 static void intel_overlay_flip_prepare(struct intel_overlay *overlay,
@@ -318,7 +315,7 @@ static int intel_overlay_continue(struct intel_overlay 
*overlay,
if (tmp & (1 << 17))
DRM_DEBUG("overlay underrun, DOVSTA: %x\n", tmp);
 
-   rq = alloc_request(overlay);
+  

[Intel-gfx] [PATCH 07/22] drm/i915/execlists: Minimalistic timeslicing

2019-06-17 Thread Chris Wilson
If we have multiple contexts of equal priority pending execution,
activate a timer to demote the currently executing context in favour of
the next in the queue when that timeslice expires. This enforces
fairness between contexts (so long as they allow preemption -- forced
preemption, in the future, will kick those who do not obey) and allows
us to avoid userspace blocking forward progress with e.g. unbounded
MI_SEMAPHORE_WAIT.

For the starting point here, we use the jiffie as our timeslice so that
we should be reasonably efficient wrt frequent CPU wakeups.

Testcase: igt/gem_exec_scheduler/semaphore-resolve
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/intel_engine_types.h |   6 +
 drivers/gpu/drm/i915/gt/intel_lrc.c  | 111 +
 drivers/gpu/drm/i915/gt/selftest_lrc.c   | 223 +++
 drivers/gpu/drm/i915/i915_scheduler.c|   1 +
 drivers/gpu/drm/i915/i915_scheduler_types.h  |   1 +
 5 files changed, 342 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index dd0082df42cc..11a25f060fed 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "i915_gem.h"
@@ -137,6 +138,11 @@ struct intel_engine_execlists {
 */
struct tasklet_struct tasklet;
 
+   /**
+* @timer: kick the current context if its timeslice expires
+*/
+   struct timer_list timer;
+
/**
 * @default_priolist: priority list for I915_PRIORITY_NORMAL
 */
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 65c91b7db59d..cea08d665ef5 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -255,6 +255,7 @@ static int effective_prio(const struct i915_request *rq)
prio |= I915_PRIORITY_NOSEMAPHORE;
 
/* Restrict mere WAIT boosts from triggering preemption */
+   BUILD_BUG_ON(__NO_PREEMPTION & ~I915_PRIORITY_MASK); /* only internal */
return prio | __NO_PREEMPTION;
 }
 
@@ -811,6 +812,81 @@ last_active(const struct intel_engine_execlists *execlists)
return *last;
 }
 
+static void
+defer_request(struct i915_request * const rq, struct list_head * const pl)
+{
+   struct i915_dependency *p;
+
+   /*
+* We want to move the interrupted request to the back of
+* the round-robin list (i.e. its priority level), but
+* in doing so, we must then move all requests that were in
+* flight and were waiting for the interrupted request to
+* be run after it again.
+*/
+   list_move_tail(&rq->sched.link, pl);
+
+   list_for_each_entry(p, &rq->sched.waiters_list, wait_link) {
+   struct i915_request *w =
+   container_of(p->waiter, typeof(*w), sched);
+
+   /* Leave semaphores spinning on the other engines */
+   if (w->engine != rq->engine)
+   continue;
+
+   /* No waiter should start before the active request completed */
+   GEM_BUG_ON(i915_request_started(w));
+
+   GEM_BUG_ON(rq_prio(w) > rq_prio(rq));
+   if (rq_prio(w) < rq_prio(rq))
+   continue;
+
+   if (list_empty(&w->sched.link))
+   continue; /* Not yet submitted; unready */
+
+   /*
+* This should be very shallow as it is limited by the
+* number of requests that can fit in a ring (<64) and
+* the number of contexts that can be in flight on this
+* engine.
+*/
+   defer_request(w, pl);
+   }
+}
+
+static void defer_active(struct intel_engine_cs *engine)
+{
+   struct i915_request *rq;
+
+   rq = __unwind_incomplete_requests(engine);
+   if (!rq)
+   return;
+
+   defer_request(rq, i915_sched_lookup_priolist(engine, rq_prio(rq)));
+}
+
+static bool
+need_timeslice(struct intel_engine_cs *engine, const struct i915_request *rq)
+{
+   int hint;
+
+   if (list_is_last(&rq->sched.link, &engine->active.requests))
+   return false;
+
+   hint = max(rq_prio(list_next_entry(rq, sched.link)),
+  engine->execlists.queue_priority_hint);
+
+   return hint >= rq_prio(rq);
+}
+
+static bool
+enable_timeslice(struct intel_engine_cs *engine)
+{
+   struct i915_request *last = last_active(&engine->execlists);
+
+   return last && need_timeslice(engine, last);
+}
+
 static void execlists_dequeue(struct intel_engine_cs *engine)
 {
struct intel_engine_execlists * const execlists = &engine->execlists;
@@ -904,6 +980,27 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
 */
last->hw_context->lrc_desc |=

[Intel-gfx] [PATCH 16/22] drm/i915: Push the i915_active.retire into a worker

2019-06-17 Thread Chris Wilson
As we need to use a mutex to serialisation i915_active activation
(because we want to allow the callback to sleep), we need to push the
i915_active.retire into a worker callback in case we get need to retire
from an atomic context.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c |  1 +
 drivers/gpu/drm/i915/gt/intel_context.c |  1 +
 drivers/gpu/drm/i915/i915_active.c  | 72 -
 drivers/gpu/drm/i915/i915_active_types.h| 12 
 drivers/gpu/drm/i915/i915_timeline.c|  1 +
 drivers/gpu/drm/i915/i915_vma.c |  3 +-
 6 files changed, 74 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 9262a1d4f763..c85468d517ef 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -891,6 +891,7 @@ struct context_barrier_task {
void *data;
 };
 
+__i915_active_call
 static void cb_retire(struct i915_active *base)
 {
struct context_barrier_task *cb = container_of(base, typeof(*cb), base);
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index b19aa823a51a..abeb6bf0155a 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -122,6 +122,7 @@ static void __context_unpin_state(struct i915_vma *vma)
__i915_vma_unpin(vma);
 }
 
+__i915_active_call
 static void __intel_context_retire(struct i915_active *active)
 {
struct intel_context *ce = container_of(active, typeof(*ce), active);
diff --git a/drivers/gpu/drm/i915/i915_active.c 
b/drivers/gpu/drm/i915/i915_active.c
index 6a9f8d37f415..20b0e19aafff 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -30,18 +30,14 @@ struct active_node {
 };
 
 static void
-active_retire(struct i915_active *ref)
+__active_retire(struct i915_active *ref)
 {
struct active_node *it, *n;
struct rb_root root;
bool retire = false;
 
-   GEM_BUG_ON(!atomic_read(&ref->count));
-   if (atomic_add_unless(&ref->count, -1, 1))
-   return;
-
-   /* One active may be flushed from inside the acquire of another */
-   mutex_lock_nested(&ref->mutex, SINGLE_DEPTH_NESTING);
+   lockdep_assert_held(&ref->mutex);
+   GEM_BUG_ON(i915_active_is_idle(ref));
 
/* return the unused nodes to our slabcache -- flushing the allocator */
if (atomic_dec_and_test(&ref->count)) {
@@ -63,6 +59,36 @@ active_retire(struct i915_active *ref)
}
 }
 
+static void
+active_work(struct work_struct *wrk)
+{
+   struct i915_active *ref = container_of(wrk, typeof(*ref), work);
+
+   GEM_BUG_ON(!atomic_read(&ref->count));
+   if (atomic_add_unless(&ref->count, -1, 1))
+   return;
+
+   mutex_lock(&ref->mutex);
+   __active_retire(ref);
+}
+
+static void
+active_retire(struct i915_active *ref)
+{
+   GEM_BUG_ON(!atomic_read(&ref->count));
+   if (atomic_add_unless(&ref->count, -1, 1))
+   return;
+
+   /* If we are inside interrupt context (fence signaling), defer */
+   if (ref->flags & I915_ACTIVE_RETIRE_SLEEPS ||
+   !mutex_trylock(&ref->mutex)) {
+   queue_work(system_unbound_wq, &ref->work);
+   return;
+   }
+
+   __active_retire(ref);
+}
+
 static void
 node_retire(struct i915_active_request *base, struct i915_request *rq)
 {
@@ -132,14 +158,22 @@ void __i915_active_init(struct drm_i915_private *i915,
void (*retire)(struct i915_active *ref),
struct lock_class_key *key)
 {
+   unsigned long bits;
+
ref->i915 = i915;
+
+   ref->flags = 0;
ref->active = active;
-   ref->retire = retire;
+   ref->retire = ptr_unpack_bits(retire, &bits, 2);
+   if (bits & I915_ACTIVE_MAY_SLEEP)
+   ref->flags |= I915_ACTIVE_RETIRE_SLEEPS;
+
ref->tree = RB_ROOT;
ref->cache = NULL;
init_llist_head(&ref->barriers);
atomic_set(&ref->count, 0);
__mutex_init(&ref->mutex, "i915_active", key);
+   INIT_WORK(&ref->work, active_work);
 }
 
 int i915_active_ref(struct i915_active *ref,
@@ -208,8 +242,10 @@ int i915_active_wait(struct i915_active *ref)
if (err)
return err;
 
-   if (!atomic_add_unless(&ref->count, 1, 0))
-   goto unlock;
+   if (!atomic_add_unless(&ref->count, 1, 0)) {
+   mutex_unlock(&ref->mutex);
+   return 0;
+   }
 
rbtree_postorder_for_each_entry_safe(it, n, &ref->tree, node) {
err = i915_active_request_retire(&it->base, BKL(ref));
@@ -217,10 +253,15 @@ int i915_active_wait(struct i915_active *ref)
break;
}
 
-   active_retire(ref);
-unlock:
-   mutex_unlock(&ref->mutex);
-   return err;
+   __active_ret

[Intel-gfx] [PATCH 02/22] drm/i915/gtt: Serialise both updates to PDE and our shadow

2019-06-17 Thread Chris Wilson
Currently, we perform a locked update of the shadow entry when
allocating a page directory entry such that if two clients are
concurrently allocating neighbouring ranges we only insert one new entry
for the pair of them. However, we also need to serialise both clients
wrt to the actual entry in the HW table, or else we may allow one client
or even a third client to proceed ahead of the HW write. My handwave
before was that under the _pathological_ condition we would see the
scratch entry instead of the expected entry, causing a temporary
glitch. That starvation condition will eventually show up in practice, so
fix it.

The reason for the previous cheat was to avoid having to free the extra
allocation while under the spinlock. Now, we keep the extra entry
allocated until the end instead.

Fixes: 1d1b5490b91c ("drm/i915/gtt: Replace struct_mutex serialisation for 
allocation")
Signed-off-by: Chris Wilson 
Cc: Matthew Auld 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 126 +++-
 1 file changed, 69 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 278de04a96aa..7cc20cafbe1e 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1386,82 +1386,88 @@ static int gen8_ppgtt_alloc_pd(struct 
i915_address_space *vm,
   struct i915_page_directory *pd,
   u64 start, u64 length)
 {
+   struct i915_page_table *alloc = NULL;
struct i915_page_table *pt;
u64 from = start;
unsigned int pde;
+   int ret = 0;
 
spin_lock(&pd->lock);
gen8_for_each_pde(pt, pd, start, length, pde) {
const int count = gen8_pte_count(start, length);
 
if (pt == vm->scratch_pt) {
-   struct i915_page_table *old;
-
spin_unlock(&pd->lock);
 
-   pt = alloc_pt(vm);
-   if (IS_ERR(pt))
+   pt = fetch_and_zero(&alloc);
+   if (!pt)
+   pt = alloc_pt(vm);
+   if (IS_ERR(pt)) {
+   ret = PTR_ERR(pt);
goto unwind;
+   }
 
if (count < GEN8_PTES || intel_vgpu_active(vm->i915))
gen8_initialize_pt(vm, pt);
 
-   old = cmpxchg(&pd->page_table[pde], vm->scratch_pt, pt);
-   if (old == vm->scratch_pt) {
+   spin_lock(&pd->lock);
+   if (pd->page_table[pde] == vm->scratch_pt) {
gen8_ppgtt_set_pde(vm, pd, pt, pde);
+   pd->page_table[pde] = pt;
atomic_inc(&pd->used_pdes);
} else {
-   free_pt(vm, pt);
-   pt = old;
+   alloc = pt;
+   pt = pd->page_table[pde];
}
-
-   spin_lock(&pd->lock);
}
 
atomic_add(count, &pt->used_ptes);
}
spin_unlock(&pd->lock);
-
-   return 0;
+   goto out;
 
 unwind:
gen8_ppgtt_clear_pd(vm, pd, from, start - from);
-   return -ENOMEM;
+out:
+   if (alloc)
+   free_pt(vm, alloc);
+   return ret;
 }
 
 static int gen8_ppgtt_alloc_pdp(struct i915_address_space *vm,
struct i915_page_directory_pointer *pdp,
u64 start, u64 length)
 {
+   struct i915_page_directory *alloc = NULL;
struct i915_page_directory *pd;
u64 from = start;
unsigned int pdpe;
-   int ret;
+   int ret = 0;
 
spin_lock(&pdp->lock);
gen8_for_each_pdpe(pd, pdp, start, length, pdpe) {
if (pd == vm->scratch_pd) {
-   struct i915_page_directory *old;
-
spin_unlock(&pdp->lock);
 
-   pd = alloc_pd(vm);
-   if (IS_ERR(pd))
+   pd = fetch_and_zero(&alloc);
+   if (!pd)
+   pd = alloc_pd(vm);
+   if (IS_ERR(pd)) {
+   ret = PTR_ERR(pd);
goto unwind;
+   }
 
gen8_initialize_pd(vm, pd);
 
-   old = cmpxchg(&pdp->page_directory[pdpe],
- vm->scratch_pd, pd);
-   if (old == vm->scratch_pd) {
+   spin_lock(&pdp->lock);
+   if (pdp->page_directory[pdpe] == vm->scratch_pd) {
gen8_ppgtt_set_pdpe(vm, pdp, pd, pdpe);
+ 

[Intel-gfx] [PATCH 06/22] drm/i915/execlists: Preempt-to-busy

2019-06-17 Thread Chris Wilson
When using a global seqno, we required a precise stop-the-workd event to
handle preemption and unwind the global seqno counter. To accomplish
this, we would preempt to a special out-of-band context and wait for the
machine to report that it was idle. Given an idle machine, we could very
precisely see which requests had completed and which we needed to feed
back into the run queue.

However, now that we have scrapped the global seqno, we no longer need
to precisely unwind the global counter and only track requests by their
per-context seqno. This allows us to loosely unwind inflight requests
while scheduling a preemption, with the enormous caveat that the
requests we put back on the run queue are still _inflight_ (until the
preemption request is complete). This makes request tracking much more
messy, as at any point then we can see a completed request that we
believe is not currently scheduled for execution. We also have to be
careful not to rewind RING_TAIL past RING_HEAD on preempting to the
running context, and for this we use a semaphore to prevent completion
of the request before continuing.

To accomplish this feat, we change how we track requests scheduled to
the HW. Instead of appending our requests onto a single list as we
submit, we track each submission to ELSP as its own block. Then upon
receiving the CS preemption event, we promote the pending block to the
inflight block (discarding what was previously being tracked). As normal
CS completion events arrive, we then remove stale entries from the
inflight tracker.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   |   2 +-
 drivers/gpu/drm/i915/gt/intel_context_types.h |   5 +
 drivers/gpu/drm/i915/gt/intel_engine.h|  61 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |  61 +-
 drivers/gpu/drm/i915/gt/intel_engine_types.h  |  52 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c   | 671 --
 drivers/gpu/drm/i915/i915_gpu_error.c |  19 +-
 drivers/gpu/drm/i915/i915_request.c   |   6 +
 drivers/gpu/drm/i915/i915_request.h   |   1 +
 drivers/gpu/drm/i915/i915_scheduler.c |   3 +-
 drivers/gpu/drm/i915/i915_utils.h |  12 +
 drivers/gpu/drm/i915/intel_guc_submission.c   | 175 ++---
 drivers/gpu/drm/i915/selftests/i915_request.c |   8 +-
 13 files changed, 465 insertions(+), 611 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 6200060aef05..1ce122f4ed25 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -646,7 +646,7 @@ static void init_contexts(struct drm_i915_private *i915)
 
 static bool needs_preempt_context(struct drm_i915_private *i915)
 {
-   return HAS_EXECLISTS(i915);
+   return USES_GUC_SUBMISSION(i915);
 }
 
 int i915_gem_contexts_init(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index e95be4be9612..b565c3ff4378 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -13,6 +13,7 @@
 #include 
 
 #include "i915_active_types.h"
+#include "i915_utils.h"
 #include "intel_engine_types.h"
 #include "intel_sseu.h"
 
@@ -38,6 +39,10 @@ struct intel_context {
struct i915_gem_context *gem_context;
struct intel_engine_cs *engine;
struct intel_engine_cs *inflight;
+#define intel_context_inflight(ce) ptr_mask_bits((ce)->inflight, 2)
+#define intel_context_inflight_count(ce)  ptr_unmask_bits((ce)->inflight, 2)
+#define intel_context_inflight_inc(ce) ptr_count_inc(&(ce)->inflight)
+#define intel_context_inflight_dec(ce) ptr_count_dec(&(ce)->inflight)
 
struct list_head signal_link;
struct list_head signals;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h 
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 2f1c6871ee95..9bb6ff76680e 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -125,71 +125,26 @@ hangcheck_action_to_str(const enum 
intel_engine_hangcheck_action a)
 
 void intel_engines_set_scheduler_caps(struct drm_i915_private *i915);
 
-static inline void
-execlists_set_active(struct intel_engine_execlists *execlists,
-unsigned int bit)
-{
-   __set_bit(bit, (unsigned long *)&execlists->active);
-}
-
-static inline bool
-execlists_set_active_once(struct intel_engine_execlists *execlists,
- unsigned int bit)
-{
-   return !__test_and_set_bit(bit, (unsigned long *)&execlists->active);
-}
-
-static inline void
-execlists_clear_active(struct intel_engine_execlists *execlists,
-  unsigned int bit)
-{
-   __clear_bit(bit, (unsigned long *)&execlists->active);
-}
-
-static inline void
-execlists_clear_all_active(struct intel_engine_execlists *execlists)
+static inline unsigned int
+execlists_num_ports(const st

Re: [Intel-gfx] [PATCH 01/22] drm/i915: Restore -Wunused-but-set-variable

2019-06-17 Thread Chris Wilson
Quoting Chris Wilson (2019-06-17 08:18:51)
> We appear to be clear of this warning, so time to re-enable the gcc error
> checking.

Scratch that, it is only showing up under W=1. Hmm.

I forget it is to cover the voluminous atomic macros.
-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 [01/22] drm/i915: Restore -Wunused-but-set-variable

2019-06-17 Thread Patchwork
== Series Details ==

Series: series starting with [01/22] drm/i915: Restore -Wunused-but-set-variable
URL   : https://patchwork.freedesktop.org/series/62184/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
f9d84faad457 drm/i915: Restore -Wunused-but-set-variable
9a9b7608d0bb drm/i915/gtt: Serialise both updates to PDE and our shadow
5084e77a82e6 drm/i915: Skip shrinking already freed pages
90ca29dca482 drm/i915: Stop passing I915_WAIT_LOCKED to i915_request_wait()
-:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#11: 
References: eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on 
struct_mutex")

-:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit eb8d0f5af4ec ("drm/i915: Remove 
GPU reset dependence on struct_mutex")'
#11: 
References: eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on 
struct_mutex")

total: 1 errors, 1 warnings, 0 checks, 328 lines checked
f8ec22798621 drm/i915: Flush the execution-callbacks on retiring
68499f942c04 drm/i915/execlists: Preempt-to-busy
-:1494: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p_ptr' - possible 
side-effects?
#1494: FILE: drivers/gpu/drm/i915/i915_utils.h:134:
+#define ptr_count_dec(p_ptr) do {  \
+   typeof(p_ptr) __p = (p_ptr);\
+   unsigned long __v = (unsigned long)(*__p);  \
+   *__p = (typeof(*p_ptr))(--__v); \
+} while (0)

-:1500: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p_ptr' - possible 
side-effects?
#1500: FILE: drivers/gpu/drm/i915/i915_utils.h:140:
+#define ptr_count_inc(p_ptr) do {  \
+   typeof(p_ptr) __p = (p_ptr);\
+   unsigned long __v = (unsigned long)(*__p);  \
+   *__p = (typeof(*p_ptr))(++__v); \
+} while (0)

-:1783: WARNING:LINE_SPACING: Missing a blank line after declarations
#1783: FILE: drivers/gpu/drm/i915/intel_guc_submission.c:820:
+   int rem = ARRAY_SIZE(execlists->inflight) - idx;
+   memmove(execlists->inflight, port, rem * sizeof(*port));

total: 0 errors, 1 warnings, 2 checks, 1682 lines checked
0e05621dacc3 drm/i915/execlists: Minimalistic timeslicing
-:345: WARNING:LONG_LINE: line over 100 characters
#345: FILE: drivers/gpu/drm/i915/gt/selftest_lrc.c:211:
+ 2 * RUNTIME_INFO(outer->i915)->num_engines * 
(count + 2) * (count + 3)) < 0) {

total: 0 errors, 1 warnings, 0 checks, 426 lines checked
dcf969ca734d drm/i915/execlists: Force preemption
411a6ede312e drm/i915: Make the semaphore saturation mask global
9492cff546bc dma-fence: Propagate errors to dma-fence-array container
22dc1810a223 dma-fence: Report the composite sync_file status
a9fdb112a5db dma-fence: Refactor signaling for manual invocation
-:33: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#33: 
new file mode 100644

-:38: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#38: FILE: drivers/dma-buf/dma-fence-trace.c:1:
+/*

-:293: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#293: FILE: include/linux/dma-fence-types.h:1:
+/*

-:368: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#368: FILE: include/linux/dma-fence-types.h:76:
+   spinlock_t *lock;

total: 0 errors, 3 warnings, 1 checks, 728 lines checked
f76e40a91686 dma-fence: Always execute signal callbacks
fedfd3888d5c drm/i915: Throw away the active object retirement complexity
5b4a2eca4f49 drm/i915: Provide an i915_active.acquire callback
-:684: CHECK:UNCOMMENTED_DEFINITION: struct mutex definition without comment
#684: FILE: drivers/gpu/drm/i915/i915_active_types.h:36:
+   struct mutex mutex;

total: 0 errors, 0 warnings, 1 checks, 730 lines checked
04f835537ecd drm/i915: Push the i915_active.retire into a worker
c703a4145665 drm/i915/overlay: Switch to using i915_active tracking
0dd26f77aba5 drm/i915: Forgo last_fence active request tracking
70d8c211e754 drm/i915: Extract intel_frontbuffer active tracking
14f5d2753d66 drm/i915: Coordinate i915_active with its own mutex
437346375b8c drm/i915: Replace struct_mutex for batch pool serialisation
-:304: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#304: 
new file mode 100644

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

-:310: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use 
line 1 instead
#310: FILE: drivers/gpu/drm/i915/gt/intel_engine_pool.c:2:
+ * SPDX-License-Identifier: MIT

-:478: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
t

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/22] drm/i915: Restore -Wunused-but-set-variable

2019-06-17 Thread Patchwork
== Series Details ==

Series: series starting with [01/22] drm/i915: Restore -Wunused-but-set-variable
URL   : https://patchwork.freedesktop.org/series/62184/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Restore -Wunused-but-set-variable
-
+./arch/x86/include/asm/pgtable_64.h:61:9: warning: cast from non-scalar
+./arch/x86/include/asm/pgtable_64.h:61:9: warning: cast to non-scalar
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2074:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2075:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2076:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2077:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2078:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2079:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gem/i915_gem_domain.c:446:34: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/gem/i915_gem_domain.c:446:34: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1515:25: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/gem/i915_gem_internal.c:52:39: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/gem/i915_gem_internal.c:54:37: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/gem/i915_gem_internal.c:54:37: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/gem/i915_gem_internal.c:82:29: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/gem/i915_gem_internal.c:82:29: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/gem/i915_gem_mman.c:190:17: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/gem/i915_gem_mman.c:190:17: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/gem/i915_gem_mman.c:190:17: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/gem/i915_gem_mman.c:190:17: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/gem/i915_gem_mman.c:306:32: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/gem/i915_gem_mman.c:306:32: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/gem/i915_gem_shmem.c:541:36: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:327:25: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/gem/i915_gem_wait.c:194:16: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/gem/selftests/huge_pages.c:203:36: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/gem/selftests/huge_pages.c:203:36: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/gt/intel_reset.c:1380:5: warning: context imbalance in 
'i915_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/intel_sseu.c:99:25: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/gvt/mmio.c:281:23: warning: memcpy with byte count of 
279040
+drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/i915_cmd_parser.c:1106:35: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/i915_cmd_parser.c:1106:35: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/i915_debugfs.c:3829:41: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/i915_debugfs.c:3829:41: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/i915_debugfs.c:3883:49: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/i915_debugfs.c:3883:49: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/i915_debugfs.c:3939:49: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/i915_debugfs.c:3939:49: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/i915_drv.c:1225:36: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/i915_drv.c:12

[Intel-gfx] [PATCH] drm/i915/icl: Add missing device ID

2019-06-17 Thread Mika Kahola
We are missing PCI device ID for SKU ICLLP U GT 1.5F (0x8A54) as per BSPec.

BSpec: 19092

Signed-off-by: Mika Kahola 
---
 include/drm/i915_pciids.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 6d60ea68c171..6c342ac470c8 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -568,7 +568,8 @@
INTEL_VGA_DEVICE(0x8A56, info), \
INTEL_VGA_DEVICE(0x8A71, info), \
INTEL_VGA_DEVICE(0x8A70, info), \
-   INTEL_VGA_DEVICE(0x8A53, info)
+   INTEL_VGA_DEVICE(0x8A53, info), \
+   INTEL_VGA_DEVICE(0x8A54, info)
 
 #define INTEL_ICL_11_IDS(info) \
INTEL_ICL_PORT_F_IDS(info), \
-- 
2.17.1

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

Re: [Intel-gfx] use exact allocation for dma coherent memory

2019-06-17 Thread Dan Carpenter
I once wrote a Smatch check based on a commit message that said we can't
pass dma_alloc_coherent() pointers to virt_to_phys().  But then I never
felt like I understood the rules enough to actually report the warnings
as bugs.

drivers/platform/x86/dcdbas.c:108 smi_data_buf_realloc() error: 'buf' came from 
dma_alloc_coherent() so we can't do virt_to_phys()
drivers/net/caif/caif_virtio.c:414 cfv_create_genpool() error: 
'cfv->alloc_addr' came from dma_alloc_coherent() so we can't do virt_to_phys()
drivers/infiniband/hw/cxgb4/qp.c:135 alloc_host_sq() error: 'sq->queue' came 
from dma_alloc_coherent() so we can't do virt_to_phys()
drivers/infiniband/hw/cxgb4/qp.c:272 create_qp() error: 'wq->rq.queue' came 
from dma_alloc_coherent() so we can't do virt_to_phys()
drivers/infiniband/hw/cxgb4/qp.c:2628 alloc_srq_queue() error: 'wq->queue' came 
from dma_alloc_coherent() so we can't do virt_to_phys()
drivers/infiniband/hw/ocrdma/ocrdma_verbs.c:494 ocrdma_alloc_ucontext() error: 
'ctx->ah_tbl.va' came from dma_alloc_coherent() so we can't do virt_to_phys()

drivers/infiniband/hw/cxgb4/qp.c
   129  static int alloc_host_sq(struct c4iw_rdev *rdev, struct t4_sq *sq)
   130  {
   131  sq->queue = dma_alloc_coherent(&(rdev->lldi.pdev->dev), 
sq->memsize,
   132 &(sq->dma_addr), GFP_KERNEL);
   133  if (!sq->queue)
   134  return -ENOMEM;
   135  sq->phys_addr = virt_to_phys(sq->queue);
   136  dma_unmap_addr_set(sq, mapping, sq->dma_addr);
   137  return 0;
   138  }

Is this a bug?

regards,
dan carpenter

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

Re: [Intel-gfx] [PATCH 40/59] drm/vram-helper: Drop drm_gem_prime_export/import

2019-06-17 Thread Gerd Hoffmann
  Hi,

> Aside: Would be really nice to switch the others over to
> drm_gem_object_funcs.

While most callbacks are pretty straight forward (just hook the same
callbacks into the drm_gem_object_funcs. struct) the mmap bits are a
bit more obscure.

First, there seem to be two ways to mmap a gem buffer:

  (1) drm_driver->fops->mmap, and
  (2) drm_driver->gem_prime_mmap.

drm_gem_object_funcs has just a single vm_ops ...

Also it is not obvious how one would convert something which basically
calls ttm_bo_mmap() in drm_driver->fops->mmap to the new interface.

thanks,
  Gerd

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

Re: [Intel-gfx] [RFC 01/31] drm/i915: Convert intel_vgt_(de)balloon to uncore

2019-06-17 Thread Tvrtko Ursulin


On 14/06/2019 18:43, Chris Wilson wrote:

Quoting Michal Wajdeczko (2019-06-14 18:18:54)

On Fri, 14 Jun 2019 17:17:01 +0200, Tvrtko Ursulin
 wrote:


From: Tvrtko Ursulin 

More removal of implicit dev_priv from using old mmio accessors.

Furthermore these calls really operate on ggtt so it logically makes
sense
if they take it as parameter.


Hmm, I'm not sure that we going in right direction here, as these
functions mostly operate on bl_info that today is separate to ggtt.


That was my first thought too, except they are operating inside of ggtt
init/fini.


And it does actually modify ggtt: intel_vgt_balloon -> vgt_balloon_space 
-> i915_gem_gtt_reserve.


So to me it sounded passable to make them take ggtt as input parameter. 
It is not detrimental if they (the functions) one day decide to wrap 
both bl_info and ggtt into a new object.


Sounds passable or objection is hard?

Regards,

Tvrtko


Maybe better option would be to move pure ggtt related functions
vgt_balloon_space/vgt_deballoon_space to i915_gem_ggtt.c|h (after
rename) and allow vgpu functions to keep i915 as parameter ?


Presumably, vgpu would migrate to taking its own object as well. Still
undecided how best to handle ggtt init plugins. My ideal would be that
vgpu init was dynamic and be tuned to work with an existing ggtt, and
never rely on static partitioning.
-Chris


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

Re: [Intel-gfx] use exact allocation for dma coherent memory

2019-06-17 Thread Christoph Hellwig
> drivers/infiniband/hw/cxgb4/qp.c
>129  static int alloc_host_sq(struct c4iw_rdev *rdev, struct t4_sq *sq)
>130  {
>131  sq->queue = dma_alloc_coherent(&(rdev->lldi.pdev->dev), 
> sq->memsize,
>132 &(sq->dma_addr), GFP_KERNEL);
>133  if (!sq->queue)
>134  return -ENOMEM;
>135  sq->phys_addr = virt_to_phys(sq->queue);
>136  dma_unmap_addr_set(sq, mapping, sq->dma_addr);
>137  return 0;
>138  }
> 
> Is this a bug?

Yes.  This will blow up badly on many platforms, as sq->queue
might be vmapped, ioremapped, come from a pool without page backing.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Nuke atomic set/get prop plane stubs

2019-06-17 Thread Maarten Lankhorst
Op 11-06-2019 om 19:05 schreef Ville Syrjälä:
> On Tue, Jun 11, 2019 at 03:28:20PM +0200, Maarten Lankhorst wrote:
>> They have been unused since rotation was added to drm core in 2015,
>> time to get rid of them.
>>
>> Signed-off-by: Maarten Lankhorst 
> Reviewed-by: Ville Syrjälä 
>
>> ---
>>  drivers/gpu/drm/i915/intel_atomic_plane.c | 45 ---
>>  drivers/gpu/drm/i915/intel_atomic_plane.h |  8 
>>  drivers/gpu/drm/i915/intel_display.c  |  6 ---
>>  drivers/gpu/drm/i915/intel_sprite.c   |  8 
>>  4 files changed, 67 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
>> b/drivers/gpu/drm/i915/intel_atomic_plane.c
>> index 58ea1b672a1a..30bd4e76fff9 100644
>> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
>> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
>> @@ -353,48 +353,3 @@ const struct drm_plane_helper_funcs 
>> intel_plane_helper_funcs = {
>>  .cleanup_fb = intel_cleanup_plane_fb,
>>  .atomic_check = intel_plane_atomic_check,
>>  };
>> -
>> -/**
>> - * intel_plane_atomic_get_property - fetch plane property value
>> - * @plane: plane to fetch property for
>> - * @state: state containing the property value
>> - * @property: property to look up
>> - * @val: pointer to write property value into
>> - *
>> - * The DRM core does not store shadow copies of properties for
>> - * atomic-capable drivers.  This entrypoint is used to fetch
>> - * the current value of a driver-specific plane property.
>> - */
>> -int
>> -intel_plane_atomic_get_property(struct drm_plane *plane,
>> -const struct drm_plane_state *state,
>> -struct drm_property *property,
>> -u64 *val)
>> -{
>> -DRM_DEBUG_KMS("Unknown property [PROP:%d:%s]\n",
>> -  property->base.id, property->name);
>> -return -EINVAL;
>> -}
>> -
>> -/**
>> - * intel_plane_atomic_set_property - set plane property value
>> - * @plane: plane to set property for
>> - * @state: state to update property value in
>> - * @property: property to set
>> - * @val: value to set property to
>> - *
>> - * Writes the specified property value for a plane into the provided atomic
>> - * state object.
>> - *
>> - * Returns 0 on success, -EINVAL on unrecognized properties
>> - */
>> -int
>> -intel_plane_atomic_set_property(struct drm_plane *plane,
>> -struct drm_plane_state *state,
>> -struct drm_property *property,
>> -u64 val)
>> -{
>> -DRM_DEBUG_KMS("Unknown property [PROP:%d:%s]\n",
>> -  property->base.id, property->name);
>> -return -EINVAL;
>> -}
>> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.h 
>> b/drivers/gpu/drm/i915/intel_atomic_plane.h
>> index 24320041498d..1437a8797e10 100644
>> --- a/drivers/gpu/drm/i915/intel_atomic_plane.h
>> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.h
>> @@ -42,14 +42,6 @@ int intel_plane_atomic_check_with_state(const struct 
>> intel_crtc_state *old_crtc_
>>  struct intel_crtc_state *crtc_state,
>>  const struct intel_plane_state 
>> *old_plane_state,
>>  struct intel_plane_state *intel_state);
>> -int intel_plane_atomic_get_property(struct drm_plane *plane,
>> -const struct drm_plane_state *state,
>> -struct drm_property *property,
>> -u64 *val);
>> -int intel_plane_atomic_set_property(struct drm_plane *plane,
>> -struct drm_plane_state *state,
>> -struct drm_property *property,
>> -u64 val);
>>  int intel_plane_atomic_calc_changes(const struct intel_crtc_state 
>> *old_crtc_state,
>>  struct drm_crtc_state *crtc_state,
>>  const struct intel_plane_state 
>> *old_plane_state,
>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 62fa573f90e8..5d497627ffd0 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -14458,8 +14458,6 @@ static const struct drm_plane_funcs i965_plane_funcs 
>> = {
>>  .update_plane = drm_atomic_helper_update_plane,
>>  .disable_plane = drm_atomic_helper_disable_plane,
>>  .destroy = intel_plane_destroy,
>> -.atomic_get_property = intel_plane_atomic_get_property,
>> -.atomic_set_property = intel_plane_atomic_set_property,
>>  .atomic_duplicate_state = intel_plane_duplicate_state,
>>  .atomic_destroy_state = intel_plane_destroy_state,
>>  .format_mod_supported = i965_plane_format_mod_supported,
>> @@ -14469,8 +14467,6 @@ static const struct drm_plane_funcs i8xx_plane_funcs 
>> = {
>>  .update_plane = drm_atomic_helper_update_plane,
>>  

[Intel-gfx] [PATCH] drm/i915: Keep engine alive as we retire the context

2019-06-17 Thread Chris Wilson
Though we pin the context first before taking the pm wakeref, during
retire we need to unpin before dropping the pm wakeref (breaking the
"natural" onion). During the unpin, we may need to attach a cleanup
operation on to the engine wakeref, ergo we want to keep the engine
awake until after the unpin.

Fixes: ce476c80b8bf ("drm/i915: Keep contexts pinned until after the next 
kernel context switch")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_request.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 9819483d1b5d..8d952bc03d5c 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -250,8 +250,9 @@ static bool i915_request_retire(struct i915_request *rq)
 
local_irq_enable();
 
-   intel_context_exit(rq->hw_context);
+   /* Onion reversed to keep engine alive until after unpinning */
intel_context_unpin(rq->hw_context);
+   intel_context_exit(rq->hw_context);
 
i915_request_remove_from_client(rq);
list_del(&rq->link);
-- 
2.20.1

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

Re: [Intel-gfx] [PATCH 59/59] drm/doc: Document kapi doc expectations

2019-06-17 Thread Jani Nikula
On Fri, 14 Jun 2019, Daniel Vetter  wrote:
> We've had this already for anything new. With my drm_prime.c cleanup I
> also think documentations for everything already existing is complete,
> and we can bake this in as a requirements subsystem wide.
>
> Signed-off-by: Daniel Vetter 
> Cc: Laurent Pinchart 
> Cc: Jani Nikula 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Sean Paul 

Acked-by: Jani Nikula 

> ---
>  Documentation/gpu/introduction.rst | 13 +
>  Documentation/gpu/todo.rst | 13 -
>  2 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/gpu/introduction.rst 
> b/Documentation/gpu/introduction.rst
> index fccbe375244d..a94ad6ad1f54 100644
> --- a/Documentation/gpu/introduction.rst
> +++ b/Documentation/gpu/introduction.rst
> @@ -51,6 +51,19 @@ and "FIXME" where the interface could be cleaned up.
>  
>  Also read the :ref:`guidelines for the kernel documentation at large 
> `.
>  
> +Documentation Requirements for kAPI
> +---
> +
> +All kernel APIs exported to other modules must be documented, including their
> +datastructures and at least a short introductory section explaining the 
> overall
> +concepts. Documentation should be put into the code itself as kerneldoc 
> comments
> +as much as reasonable. Do not blindly document everything, but document only
> +what's relevant for driver authors: Internal functions of drm.ko and 
> definitely
> +static functions should not have formal kerneldoc comments. Use normal C
> +comments if you feel like a comment is warranted. Similar for data 
> structures,
> +annotate anything entirely private with ``/* private: */`` comments as per 
> the
> +documentation guide.
> +
>  Getting Started
>  ===
>  
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 026e55c517e1..25878dd048fd 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -299,19 +299,6 @@ In the end no .c file should need to include ``drmP.h`` 
> anymore.
>  
>  Contact: Daniel Vetter
>  
> -Add missing kerneldoc for exported functions
> -
> -
> -The DRM reference documentation is still lacking kerneldoc in a few areas. 
> The
> -task would be to clean up interfaces like moving functions around between
> -files to better group them and improving the interfaces like dropping return
> -values for functions that never fail. Then write kerneldoc for all exported
> -functions and an overview section and integrate it all into the drm book.
> -
> -See https://dri.freedesktop.org/docs/drm/ for what's there already.
> -
> -Contact: Daniel Vetter
> -
>  Make panic handling work
>  

-- 
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: move modesetting core code under display/

2019-06-17 Thread Jani Nikula
On Thu, 13 Jun 2019, Maarten Lankhorst  
wrote:
> Op 13-06-2019 om 10:44 schreef Jani Nikula:
>> Now that we have a new subdirectory for display code, continue by moving
>> modesetting core code.
>>
>> display/intel_frontbuffer.h sticks out like a sore thumb, otherwise this
>> is, again, a surprisingly clean operation.
>>
>> v2:
>> - don't move intel_sideband.[ch] (Ville)
>> - use tabs for Makefile file lists and sort them
>>
>> Cc: Chris Wilson 
>> Cc: Joonas Lahtinen 
>> Cc: Rodrigo Vivi 
>> Cc: Ville Syrjälä 
>> Reviewed-by: Chris Wilson 
>> Acked-by: Rodrigo Vivi 
>> Signed-off-by: Jani Nikula 
>
> For whole series:
>
> Acked-by: Maarten Lankhorst 

Pushed the series to dinq; thanks for the reviews and acks. We now have
display tucked away under a separate subdir.

BR,
Jani.

>
>> ---
>>  drivers/gpu/drm/i915/Makefile | 66 ++-
>>  drivers/gpu/drm/i915/Makefile.header-test | 24 ---
>>  .../gpu/drm/i915/display/Makefile.header-test |  2 +-
>>  .../gpu/drm/i915/{ => display}/intel_acpi.c   |  0
>>  .../gpu/drm/i915/{ => display}/intel_acpi.h   |  0
>>  .../gpu/drm/i915/{ => display}/intel_atomic.c |  0
>>  .../gpu/drm/i915/{ => display}/intel_atomic.h |  0
>>  .../i915/{ => display}/intel_atomic_plane.c   |  0
>>  .../i915/{ => display}/intel_atomic_plane.h   |  0
>>  .../gpu/drm/i915/{ => display}/intel_audio.c  |  0
>>  .../gpu/drm/i915/{ => display}/intel_audio.h  |  0
>>  .../gpu/drm/i915/{ => display}/intel_bios.c   |  0
>>  .../gpu/drm/i915/{ => display}/intel_bios.h   |  0
>>  drivers/gpu/drm/i915/{ => display}/intel_bw.c |  0
>>  drivers/gpu/drm/i915/{ => display}/intel_bw.h |  0
>>  .../gpu/drm/i915/{ => display}/intel_cdclk.c  |  0
>>  .../gpu/drm/i915/{ => display}/intel_cdclk.h  |  0
>>  .../gpu/drm/i915/{ => display}/intel_color.c  |  0
>>  .../gpu/drm/i915/{ => display}/intel_color.h  |  0
>>  .../drm/i915/{ => display}/intel_combo_phy.c  |  0
>>  .../drm/i915/{ => display}/intel_combo_phy.h  |  0
>>  .../drm/i915/{ => display}/intel_connector.c  |  0
>>  .../drm/i915/{ => display}/intel_connector.h  |  0
>>  .../drm/i915/{ => display}/intel_display.c|  0
>>  .../drm/i915/{ => display}/intel_display.h|  0
>>  .../i915/{ => display}/intel_display_power.c  |  0
>>  .../i915/{ => display}/intel_display_power.h  |  0
>>  .../drm/i915/{ => display}/intel_dpio_phy.c   |  0
>>  .../drm/i915/{ => display}/intel_dpio_phy.h   |  0
>>  .../drm/i915/{ => display}/intel_dpll_mgr.c   |  0
>>  .../drm/i915/{ => display}/intel_dpll_mgr.h   |  0
>>  .../gpu/drm/i915/{ => display}/intel_fbc.c|  0
>>  .../gpu/drm/i915/{ => display}/intel_fbc.h|  0
>>  .../gpu/drm/i915/{ => display}/intel_fbdev.c  |  0
>>  .../gpu/drm/i915/{ => display}/intel_fbdev.h  |  0
>>  .../i915/{ => display}/intel_fifo_underrun.c  |  0
>>  .../i915/{ => display}/intel_fifo_underrun.h  |  0
>>  .../i915/{ => display}/intel_frontbuffer.c|  0
>>  .../i915/{ => display}/intel_frontbuffer.h|  0
>>  .../gpu/drm/i915/{ => display}/intel_hdcp.c   |  0
>>  .../gpu/drm/i915/{ => display}/intel_hdcp.h   |  0
>>  .../drm/i915/{ => display}/intel_hotplug.c|  0
>>  .../drm/i915/{ => display}/intel_hotplug.h|  0
>>  .../drm/i915/{ => display}/intel_lpe_audio.c  |  0
>>  .../drm/i915/{ => display}/intel_lpe_audio.h  |  0
>>  .../drm/i915/{ => display}/intel_opregion.c   |  0
>>  .../drm/i915/{ => display}/intel_opregion.h   |  0
>>  .../drm/i915/{ => display}/intel_overlay.c|  0
>>  .../drm/i915/{ => display}/intel_overlay.h|  0
>>  .../drm/i915/{ => display}/intel_pipe_crc.c   |  0
>>  .../drm/i915/{ => display}/intel_pipe_crc.h   |  0
>>  .../gpu/drm/i915/{ => display}/intel_psr.c|  0
>>  .../gpu/drm/i915/{ => display}/intel_psr.h|  0
>>  .../gpu/drm/i915/{ => display}/intel_quirks.c |  0
>>  .../gpu/drm/i915/{ => display}/intel_quirks.h |  0
>>  .../gpu/drm/i915/{ => display}/intel_sprite.c |  0
>>  .../gpu/drm/i915/{ => display}/intel_sprite.h |  0
>>  .../drm/i915/{ => display}/intel_vbt_defs.h   |  0
>>  drivers/gpu/drm/i915/gem/i915_gem_clflush.c   |  3 +-
>>  drivers/gpu/drm/i915/gem/i915_gem_domain.c|  3 +-
>>  .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  3 +-
>>  drivers/gpu/drm/i915/gem/i915_gem_object.c|  3 +-
>>  drivers/gpu/drm/i915/gt/intel_reset.c |  3 +-
>>  drivers/gpu/drm/i915/gvt/opregion.c   |  2 +-
>>  drivers/gpu/drm/i915/i915_debugfs.c   |  6 +-
>>  drivers/gpu/drm/i915/i915_drv.c   | 18 ++---
>>  drivers/gpu/drm/i915/i915_drv.h   | 13 ++--
>>  drivers/gpu/drm/i915/i915_gem.c   |  5 +-
>>  drivers/gpu/drm/i915/i915_gem_gtt.c   |  3 +-
>>  drivers/gpu/drm/i915/i915_gpu_error.c |  5 +-
>>  drivers/gpu/drm/i915/i915_irq.c   |  9 +--
>>  drivers/gpu/drm/i915/i915_pci.c   |  3 +-
>>  drivers/gpu/drm/i915/i915_suspend.c   |  2 +-
>>  drivers/gpu/drm/i915/i915_vma.c   | 10 +--
>>  drivers/gpu/drm/i915/intel_device_info.

Re: [Intel-gfx] [PATCH] drm/i915: Keep engine alive as we retire the context

2019-06-17 Thread Chris Wilson
Quoting Chris Wilson (2019-06-17 09:40:44)
> Though we pin the context first before taking the pm wakeref, during
> retire we need to unpin before dropping the pm wakeref (breaking the
> "natural" onion). During the unpin, we may need to attach a cleanup
> operation on to the engine wakeref, ergo we want to keep the engine
> awake until after the unpin.
> 
> Fixes: ce476c80b8bf ("drm/i915: Keep contexts pinned until after the next 
> kernel context switch")
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_request.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_request.c 
> b/drivers/gpu/drm/i915/i915_request.c
> index 9819483d1b5d..8d952bc03d5c 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -250,8 +250,9 @@ static bool i915_request_retire(struct i915_request *rq)
>  
> local_irq_enable();
>  
> -   intel_context_exit(rq->hw_context);
> +   /* Onion reversed to keep engine alive until after unpinning */
> intel_context_unpin(rq->hw_context);
> +   intel_context_exit(rq->hw_context);

The alternative is to keep the onion unwind here and to add the engine
wakerefs into the barriers. Hmm.

That seems like it should be more foolproof, perhaps?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915: Keep engine alive as we retire the context

2019-06-17 Thread Chris Wilson
Though we pin the context first before taking the pm wakeref, during
retire we need to unpin before dropping the pm wakeref (breaking the
"natural" onion). During the unpin, we may need to attach a cleanup
operation on to the engine wakeref, ergo we want to keep the engine
awake until after the unpin.

v2: Push the engine wakeref into the barrier so we keep the onion unwind
ordering in the request itself

Fixes: ce476c80b8bf ("drm/i915: Keep contexts pinned until after the next 
kernel context switch")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_active.c | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_active.c 
b/drivers/gpu/drm/i915/i915_active.c
index 2d019ac6db20..a803ad42075d 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -4,6 +4,8 @@
  * Copyright © 2019 Intel Corporation
  */
 
+#include "gt/intel_engine_pm.h"
+
 #include "i915_drv.h"
 #include "i915_active.h"
 #include "i915_globals.h"
@@ -268,8 +270,9 @@ int i915_active_acquire_preallocate_barrier(struct 
i915_active *ref,
struct intel_engine_cs *engine)
 {
struct drm_i915_private *i915 = engine->i915;
+   struct llist_node *pos, *next;
unsigned long tmp;
-   int err = 0;
+   int err;
 
GEM_BUG_ON(!engine->mask);
for_each_engine_masked(engine, i915, engine->mask, tmp) {
@@ -278,8 +281,9 @@ int i915_active_acquire_preallocate_barrier(struct 
i915_active *ref,
 
node = kmem_cache_alloc(global.slab_cache, GFP_KERNEL);
if (unlikely(!node)) {
+   intel_engine_pm_put(engine);
err = -ENOMEM;
-   break;
+   goto unwind;
}
 
i915_active_request_init(&node->base,
@@ -288,10 +292,24 @@ int i915_active_acquire_preallocate_barrier(struct 
i915_active *ref,
node->ref = ref;
ref->count++;
 
+   intel_engine_pm_get(engine);
llist_add((struct llist_node *)&node->base.link,
  &ref->barriers);
}
 
+   return 0;
+
+unwind:
+   llist_for_each_safe(pos, next, llist_del_all(&ref->barriers)) {
+   struct active_node *node;
+
+   node = container_of((struct list_head *)pos,
+   typeof(*node), base.link);
+   engine = (void *)rcu_access_pointer(node->base.request);
+
+   intel_engine_pm_put(engine);
+   kfree(node);
+   }
return err;
 }
 
@@ -328,6 +346,7 @@ void i915_active_acquire_barrier(struct i915_active *ref)
 
llist_add((struct llist_node *)&node->base.link,
  &engine->barrier_tasks);
+   intel_engine_pm_put(engine);
}
i915_active_release(ref);
 }
-- 
2.20.1

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

Re: [Intel-gfx] [PATCH 09/59] drm/prime: Align gem_prime_export with obj_funcs.export

2019-06-17 Thread Koenig, Christian
Am 14.06.19 um 22:35 schrieb Daniel Vetter:
> The idea is that gem_prime_export is deprecated in favor of
> obj_funcs.export. That's much easier to do if both have matching
> function signatures.
>
> Signed-off-by: Daniel Vetter 
> Cc: Russell King 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Zhenyu Wang 
> Cc: Zhi Wang 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: Tomi Valkeinen 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: "David (ChunMing) Zhou" 
> Cc: Thierry Reding 
> Cc: Jonathan Hunter 
> Cc: Dave Airlie 
> Cc: Eric Anholt 
> Cc: "Michel Dänzer" 
> Cc: Chris Wilson 
> Cc: Huang Rui 
> Cc: Felix Kuehling 
> Cc: Hawking Zhang 
> Cc: Feifei Xu 
> Cc: Jim Qu 
> Cc: Evan Quan 
> Cc: Matthew Auld 
> Cc: Mika Kuoppala 
> Cc: Thomas Zimmermann 
> Cc: Kate Stewart 
> Cc: Sumit Semwal 
> Cc: Jilayne Lovejoy 
> Cc: Thomas Gleixner 
> Cc: Mikulas Patocka 
> Cc: Greg Kroah-Hartman 
> Cc: Junwei Zhang 
> Cc: intel-gvt-...@lists.freedesktop.org
> Cc: intel-gfx@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> Cc: linux-te...@vger.kernel.org

Acked-by: Christian König 

> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c  | 7 +++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h  | 3 +--
>   drivers/gpu/drm/armada/armada_gem.c  | 5 ++---
>   drivers/gpu/drm/armada/armada_gem.h  | 3 +--
>   drivers/gpu/drm/drm_prime.c  | 9 -
>   drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c   | 5 ++---
>   drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 8 
>   drivers/gpu/drm/i915/gvt/dmabuf.c| 2 +-
>   drivers/gpu/drm/i915/i915_drv.h  | 3 +--
>   drivers/gpu/drm/omapdrm/omap_gem.h   | 3 +--
>   drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c| 5 ++---
>   drivers/gpu/drm/radeon/radeon_drv.c  | 3 +--
>   drivers/gpu/drm/radeon/radeon_prime.c| 5 ++---
>   drivers/gpu/drm/tegra/gem.c  | 7 +++
>   drivers/gpu/drm/tegra/gem.h  | 3 +--
>   drivers/gpu/drm/udl/udl_dmabuf.c | 5 ++---
>   drivers/gpu/drm/udl/udl_drv.h| 3 +--
>   drivers/gpu/drm/vc4/vc4_bo.c | 5 ++---
>   drivers/gpu/drm/vc4/vc4_drv.h| 3 +--
>   drivers/gpu/drm/vgem/vgem_fence.c| 2 +-
>   include/drm/drm_drv.h| 4 ++--
>   include/drm/drm_prime.h  | 3 +--
>   22 files changed, 39 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> index 489041df1f45..4809d4a5d72a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> @@ -345,8 +345,7 @@ const struct dma_buf_ops amdgpu_dmabuf_ops = {
>* Returns:
>* Shared DMA buffer representing the GEM BO from the given device.
>*/
> -struct dma_buf *amdgpu_gem_prime_export(struct drm_device *dev,
> - struct drm_gem_object *gobj,
> +struct dma_buf *amdgpu_gem_prime_export(struct drm_gem_object *gobj,
>   int flags)
>   {
>   struct amdgpu_bo *bo = gem_to_amdgpu_bo(gobj);
> @@ -356,9 +355,9 @@ struct dma_buf *amdgpu_gem_prime_export(struct drm_device 
> *dev,
>   bo->flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID)
>   return ERR_PTR(-EPERM);
>   
> - buf = drm_gem_prime_export(dev, gobj, flags);
> + buf = drm_gem_prime_export(gobj, flags);
>   if (!IS_ERR(buf)) {
> - buf->file->f_mapping = dev->anon_inode->i_mapping;
> + buf->file->f_mapping = gobj->dev->anon_inode->i_mapping;
>   buf->ops = &amdgpu_dmabuf_ops;
>   }
>   
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
> index c7056cbe8685..7f73a4f94204 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
> @@ -30,8 +30,7 @@ struct drm_gem_object *
>   amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
>struct dma_buf_attachment *attach,
>struct sg_table *sg);
> -struct dma_buf *amdgpu_gem_prime_export(struct drm_device *dev,
> - struct drm_gem_object *gobj,
> +struct dma_buf *amdgpu_gem_prime_export(struct drm_gem_object *gobj,
>   int flags);
>   struct drm_gem_object *amdgpu_gem_prime_import(struct drm_device *dev,
>   struct dma_buf *dma_buf);
> diff --git a/drivers/gpu/drm/armada/armada_gem.c 
> b/drivers/gpu/drm/armada/armada_gem.c
> index 642d0e70d0f8..7e7fcc3f1f7f 100644
> --- 

Re: [Intel-gfx] [PATCH v2] drm/i915: Keep engine alive as we retire the context

2019-06-17 Thread Chris Wilson
Quoting Chris Wilson (2019-06-17 10:32:27)
> Though we pin the context first before taking the pm wakeref, during
> retire we need to unpin before dropping the pm wakeref (breaking the
> "natural" onion). During the unpin, we may need to attach a cleanup
> operation on to the engine wakeref, ergo we want to keep the engine
> awake until after the unpin.
> 
> v2: Push the engine wakeref into the barrier so we keep the onion unwind
> ordering in the request itself
> 
> Fixes: ce476c80b8bf ("drm/i915: Keep contexts pinned until after the next 
> kernel context switch")
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_active.c | 23 +--
>  1 file changed, 21 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_active.c 
> b/drivers/gpu/drm/i915/i915_active.c
> index 2d019ac6db20..a803ad42075d 100644
> --- a/drivers/gpu/drm/i915/i915_active.c
> +++ b/drivers/gpu/drm/i915/i915_active.c
> @@ -4,6 +4,8 @@
>   * Copyright © 2019 Intel Corporation
>   */
>  
> +#include "gt/intel_engine_pm.h"
> +
>  #include "i915_drv.h"
>  #include "i915_active.h"
>  #include "i915_globals.h"
> @@ -268,8 +270,9 @@ int i915_active_acquire_preallocate_barrier(struct 
> i915_active *ref,
> struct intel_engine_cs *engine)
>  {
> struct drm_i915_private *i915 = engine->i915;
> +   struct llist_node *pos, *next;
> unsigned long tmp;
> -   int err = 0;
> +   int err;
>  
> GEM_BUG_ON(!engine->mask);
> for_each_engine_masked(engine, i915, engine->mask, tmp) {
> @@ -278,8 +281,9 @@ int i915_active_acquire_preallocate_barrier(struct 
> i915_active *ref,
>  
> node = kmem_cache_alloc(global.slab_cache, GFP_KERNEL);
> if (unlikely(!node)) {
> +   intel_engine_pm_put(engine);

Oh no, didn't remove after reordering.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3] drm/i915: Keep engine alive as we retire the context

2019-06-17 Thread Chris Wilson
Though we pin the context first before taking the pm wakeref, during
retire we need to unpin before dropping the pm wakeref (breaking the
"natural" onion). During the unpin, we may need to attach a cleanup
operation on to the engine wakeref, ergo we want to keep the engine
awake until after the unpin.

v2: Push the engine wakeref into the barrier so we keep the onion unwind
ordering in the request itself

Fixes: ce476c80b8bf ("drm/i915: Keep contexts pinned until after the next 
kernel context switch")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_active.c | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_active.c 
b/drivers/gpu/drm/i915/i915_active.c
index 2d019ac6db20..41ed2798687d 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -4,6 +4,8 @@
  * Copyright © 2019 Intel Corporation
  */
 
+#include "gt/intel_engine_pm.h"
+
 #include "i915_drv.h"
 #include "i915_active.h"
 #include "i915_globals.h"
@@ -268,8 +270,9 @@ int i915_active_acquire_preallocate_barrier(struct 
i915_active *ref,
struct intel_engine_cs *engine)
 {
struct drm_i915_private *i915 = engine->i915;
+   struct llist_node *pos, *next;
unsigned long tmp;
-   int err = 0;
+   int err;
 
GEM_BUG_ON(!engine->mask);
for_each_engine_masked(engine, i915, engine->mask, tmp) {
@@ -279,7 +282,7 @@ int i915_active_acquire_preallocate_barrier(struct 
i915_active *ref,
node = kmem_cache_alloc(global.slab_cache, GFP_KERNEL);
if (unlikely(!node)) {
err = -ENOMEM;
-   break;
+   goto unwind;
}
 
i915_active_request_init(&node->base,
@@ -288,10 +291,24 @@ int i915_active_acquire_preallocate_barrier(struct 
i915_active *ref,
node->ref = ref;
ref->count++;
 
+   intel_engine_pm_get(engine);
llist_add((struct llist_node *)&node->base.link,
  &ref->barriers);
}
 
+   return 0;
+
+unwind:
+   llist_for_each_safe(pos, next, llist_del_all(&ref->barriers)) {
+   struct active_node *node;
+
+   node = container_of((struct list_head *)pos,
+   typeof(*node), base.link);
+   engine = (void *)rcu_access_pointer(node->base.request);
+
+   intel_engine_pm_put(engine);
+   kfree(node);
+   }
return err;
 }
 
@@ -328,6 +345,7 @@ void i915_active_acquire_barrier(struct i915_active *ref)
 
llist_add((struct llist_node *)&node->base.link,
  &engine->barrier_tasks);
+   intel_engine_pm_put(engine);
}
i915_active_release(ref);
 }
-- 
2.20.1

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

[Intel-gfx] [PATCH 03/11] drm/i915: make i915_globals.h self-contained

2019-06-17 Thread Jani Nikula
Add the minimal includes/declarations to make the header self-contained,
and ensure it stays that way.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/Makefile.header-test | 1 +
 drivers/gpu/drm/i915/i915_globals.h   | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/Makefile.header-test 
b/drivers/gpu/drm/i915/Makefile.header-test
index 00a437db434d..4f7a349dcfc5 100644
--- a/drivers/gpu/drm/i915/Makefile.header-test
+++ b/drivers/gpu/drm/i915/Makefile.header-test
@@ -8,6 +8,7 @@ header_test := \
i915_drv.h \
i915_fixed.h \
i915_gem_gtt.h \
+   i915_globals.h \
i915_irq.h \
i915_params.h \
i915_priolist_types.h \
diff --git a/drivers/gpu/drm/i915/i915_globals.h 
b/drivers/gpu/drm/i915/i915_globals.h
index 04c1ce107fc0..2d199f411a4a 100644
--- a/drivers/gpu/drm/i915/i915_globals.h
+++ b/drivers/gpu/drm/i915/i915_globals.h
@@ -7,6 +7,8 @@
 #ifndef _I915_GLOBALS_H_
 #define _I915_GLOBALS_H_
 
+#include 
+
 typedef void (*i915_global_func_t)(void);
 
 struct i915_global {
-- 
2.20.1

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

[Intel-gfx] [PATCH 01/11] drm/i915: make i915_fixed.h self-contained

2019-06-17 Thread Jani Nikula
Add the minimal includes/declarations to make the header self-contained,
and ensure it stays that way.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/Makefile.header-test | 1 +
 drivers/gpu/drm/i915/i915_fixed.h | 5 +
 2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/Makefile.header-test 
b/drivers/gpu/drm/i915/Makefile.header-test
index e6ba66f787f9..f6ec3e72ae38 100644
--- a/drivers/gpu/drm/i915/Makefile.header-test
+++ b/drivers/gpu/drm/i915/Makefile.header-test
@@ -6,6 +6,7 @@ header_test := \
i915_active_types.h \
i915_debugfs.h \
i915_drv.h \
+   i915_fixed.h \
i915_irq.h \
i915_params.h \
i915_priolist_types.h \
diff --git a/drivers/gpu/drm/i915/i915_fixed.h 
b/drivers/gpu/drm/i915/i915_fixed.h
index 6621595fe74c..a327094de2bd 100644
--- a/drivers/gpu/drm/i915/i915_fixed.h
+++ b/drivers/gpu/drm/i915/i915_fixed.h
@@ -6,6 +6,11 @@
 #ifndef _I915_FIXED_H_
 #define _I915_FIXED_H_
 
+#include 
+#include 
+#include 
+#include 
+
 typedef struct {
u32 val;
 } uint_fixed_16_16_t;
-- 
2.20.1

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

[Intel-gfx] drm/i915: last bits to make headers self-contained

2019-06-17 Thread Jani Nikula
After this, all headers except display/intel_vbt_defs.h (which is also
copy-pasted to userspace) and i915_oa_*.h (which are generated files)
are self-contained.

BR,
Jani.


___
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 Enable Multi-segmented-gamma for ICL (rev4)

2019-06-17 Thread Shankar, Uma


>On 13/06/2019 10:39, Shankar, Uma wrote:
>>
>>
>>> -Original Message-
>>> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
>>> Behalf Of Patchwork
>>> Sent: Thursday, June 13, 2019 12:36 PM
>>> To: Sharma, Shashank 
>>> Cc: intel-gfx@lists.freedesktop.org
>>> Subject: [Intel-gfx] ✗ Fi.CI.IGT: failure for Enable
>>> Multi-segmented-gamma for ICL
>>> (rev4)
>>>
>>> == Series Details ==
>>>
>>> Series: Enable Multi-segmented-gamma for ICL (rev4)
>>> URL   : https://patchwork.freedesktop.org/series/60126/
>>> State : failure
>>>
>>> == Summary ==
>>>
>>> CI Bug Log - changes from CI_DRM_6242_full -> Patchwork_13248_full
>>> 
>>>
>>> Summary
>>> ---
>>>
>>>  **FAILURE**
>>>
>>>  Serious unknown changes coming with Patchwork_13248_full absolutely
>>> need to be  verified manually.
>>>
>>>  If you think the reported changes have nothing to do with the
>>> changes  introduced in Patchwork_13248_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_13248_full:
>>>
>>> ### IGT changes ###
>>>
>>>  Possible regressions 
>>>
>>>  * igt@kms_color@pipe-b-ctm-0-25:
>>>- shard-iclb: [PASS][1] -> [FAIL][2] +4 similar issues
>>>   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6242/shard-
>>> iclb3/igt@kms_co...@pipe-b-ctm-0-25.html
>>>   [2]:
>>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13248/shard-
>>> iclb2/igt@kms_co...@pipe-b-ctm-0-25.html
>>>
>>
>> Hi Martin,
>> These are the failures which we get when we enabled multi segment
>> gamma due to the crc limitations (already in discussion with hardware
>> design and validation team). As discussed, can we mark these as known issues 
>> and
>merge the multi segment gamma series.
>>
>> We will be tracking the hardware CRC issues separately and will work
>> with hardware design teams to debug that.
>
>Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110920
>Acked-by: Martin Peres 

Thanks Martin.

We are working with simulation (Fulsim) team to analyse the crc behaviour in 
hardware.
Will update the Bugzilla once we have more information/findings on this.

Regards,
Uma Shankar

>Martin
>
>>
>> Thanks & Regards,
>> Uma Shankar
>>
>>> Known issues
>>> 
>>>
>>>  Here are the changes found in Patchwork_13248_full that come from known
>issues:
>>>
>>> ### IGT changes ###
>>>
>>>  Issues hit 
>>>
>>>  * igt@gem_exec_schedule@preemptive-hang-bsd2:
>>>- shard-kbl:  [PASS][3] -> [INCOMPLETE][4] ([fdo#103665])
>>>   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6242/shard-
>>> kbl7/igt@gem_exec_sched...@preemptive-hang-bsd2.html
>>>   [4]:
>>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13248/shard-
>>> kbl3/igt@gem_exec_sched...@preemptive-hang-bsd2.html
>>>
>>>  * igt@gem_tiled_swapping@non-threaded:
>>>- shard-iclb: [PASS][5] -> [FAIL][6] ([fdo#108686])
>>>   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6242/shard-
>>> iclb2/igt@gem_tiled_swapp...@non-threaded.html
>>>   [6]:
>>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13248/shard-
>>> iclb7/igt@gem_tiled_swapp...@non-threaded.html
>>>- shard-glk:  [PASS][7] -> [DMESG-WARN][8] ([fdo#108686])
>>>   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6242/shard-
>>> glk7/igt@gem_tiled_swapp...@non-threaded.html
>>>   [8]:
>>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13248/shard-
>>> glk9/igt@gem_tiled_swapp...@non-threaded.html
>>>
>>>  * igt@i915_pm_rpm@i2c:
>>>- shard-skl:  [PASS][9] -> [SKIP][10] ([fdo#109271]) +2 similar 
>>> issues
>>>   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6242/shard-
>>> skl5/igt@i915_pm_...@i2c.html
>>>   [10]:
>>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13248/shard-
>>> skl6/igt@i915_pm_...@i2c.html
>>>
>>>  * igt@kms_color@pipe-c-degamma:
>>>- shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#104782]) +2 similar 
>>> issues
>>>   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6242/shard-
>>> iclb2/igt@kms_co...@pipe-c-degamma.html
>>>   [12]:
>>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13248/shard-
>>> iclb7/igt@kms_co...@pipe-c-degamma.html
>>>
>>>  * igt@kms_cursor_crc@pipe-a-cursor-128x128-onscreen:
>>>- shard-snb:  [PASS][13] -> [SKIP][14] ([fdo#109271]) +1 similar 
>>> issue
>>>   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6242/shard-
>>> snb7/igt@kms_cursor_...@pipe-a-cursor-128x128-onscreen.html
>>>   [14]:
>>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13248/shard-
>>> snb4/igt@kms_cursor_...@pipe-a-cursor-128x128-onscreen.html
>>>
>>>  * igt@kms_fbcon_fbt@fbc-suspend:
>>>- shard-skl:  [PASS][15] -> [INCOMPLETE][16] ([fdo#104108])
>>>   [15]: https://i

[Intel-gfx] [PATCH 11/11] drm/i915: use wildcard to ensure all headers stay self-contained

2019-06-17 Thread Jani Nikula
Skip the generated i915_oa_*.h files.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/Makefile.header-test | 29 +--
 1 file changed, 1 insertion(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/Makefile.header-test 
b/drivers/gpu/drm/i915/Makefile.header-test
index 919d3a848b0b..f6641eca0d2d 100644
--- a/drivers/gpu/drm/i915/Makefile.header-test
+++ b/drivers/gpu/drm/i915/Makefile.header-test
@@ -2,34 +2,7 @@
 # Copyright © 2019 Intel Corporation
 
 # Test the headers are compilable as standalone units
-header_test := \
-   i915_active_types.h \
-   i915_debugfs.h \
-   i915_drv.h \
-   i915_fixed.h \
-   i915_gem_gtt.h \
-   i915_globals.h \
-   i915_irq.h \
-   i915_params.h \
-   i915_priolist_types.h \
-   i915_pvinfo.h \
-   i915_reg.h \
-   i915_scheduler_types.h \
-   i915_timeline_types.h \
-   i915_utils.h \
-   i915_vgpu.h \
-   intel_csr.h \
-   intel_drv.h \
-   intel_guc_ct.h \
-   intel_guc_fwif.h \
-   intel_guc_reg.h \
-   intel_gvt.h \
-   intel_pm.h \
-   intel_runtime_pm.h \
-   intel_sideband.h \
-   intel_uc_fw.h \
-   intel_uncore.h \
-   intel_wakeref.h
+header_test := $(notdir $(filter-out $(src)/i915_oa_%.h,$(wildcard 
$(src)/*.h)))
 
 quiet_cmd_header_test = HDRTEST $@
   cmd_header_test = echo "\#include \"$( $@
-- 
2.20.1

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

[Intel-gfx] [PATCH 02/11] drm/i915: make i915_gem_gtt.h self-contained

2019-06-17 Thread Jani Nikula
Add the minimal includes/declarations to make the header self-contained,
and ensure it stays that way.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/Makefile.header-test | 1 +
 drivers/gpu/drm/i915/i915_gem_gtt.h   | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/Makefile.header-test 
b/drivers/gpu/drm/i915/Makefile.header-test
index f6ec3e72ae38..00a437db434d 100644
--- a/drivers/gpu/drm/i915/Makefile.header-test
+++ b/drivers/gpu/drm/i915/Makefile.header-test
@@ -7,6 +7,7 @@ header_test := \
i915_debugfs.h \
i915_drv.h \
i915_fixed.h \
+   i915_gem_gtt.h \
i915_irq.h \
i915_params.h \
i915_priolist_types.h \
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 63fa357c69de..108d4c7293d7 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -38,6 +38,8 @@
 #include 
 #include 
 
+#include 
+
 #include "gt/intel_reset.h"
 #include "i915_gem_fence_reg.h"
 #include "i915_request.h"
-- 
2.20.1

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

[Intel-gfx] [PATCH 04/11] drm/i915: make i915_pvinfo.h self-contained

2019-06-17 Thread Jani Nikula
Add the minimal includes/declarations to make the header self-contained,
and ensure it stays that way.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/Makefile.header-test | 1 +
 drivers/gpu/drm/i915/i915_pvinfo.h| 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/Makefile.header-test 
b/drivers/gpu/drm/i915/Makefile.header-test
index 4f7a349dcfc5..c0d1663e5b61 100644
--- a/drivers/gpu/drm/i915/Makefile.header-test
+++ b/drivers/gpu/drm/i915/Makefile.header-test
@@ -12,6 +12,7 @@ header_test := \
i915_irq.h \
i915_params.h \
i915_priolist_types.h \
+   i915_pvinfo.h \
i915_reg.h \
i915_scheduler_types.h \
i915_timeline_types.h \
diff --git a/drivers/gpu/drm/i915/i915_pvinfo.h 
b/drivers/gpu/drm/i915/i915_pvinfo.h
index 969e514916ab..2b29065da6d1 100644
--- a/drivers/gpu/drm/i915/i915_pvinfo.h
+++ b/drivers/gpu/drm/i915/i915_pvinfo.h
@@ -24,6 +24,8 @@
 #ifndef _I915_PVINFO_H_
 #define _I915_PVINFO_H_
 
+#include 
+
 /* The MMIO offset of the shared info between guest and host emulator */
 #define VGT_PVINFO_PAGE0x78000
 #define VGT_PVINFO_SIZE0x1000
-- 
2.20.1

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

[Intel-gfx] [PATCH 10/11] drm/i915: make intel_uc_fw.h self-contained

2019-06-17 Thread Jani Nikula
Add the minimal includes/declarations to make the header self-contained,
and ensure it stays that way.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/Makefile.header-test | 1 +
 drivers/gpu/drm/i915/intel_uc_fw.h| 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/Makefile.header-test 
b/drivers/gpu/drm/i915/Makefile.header-test
index 5ae2cae27e85..919d3a848b0b 100644
--- a/drivers/gpu/drm/i915/Makefile.header-test
+++ b/drivers/gpu/drm/i915/Makefile.header-test
@@ -27,6 +27,7 @@ header_test := \
intel_pm.h \
intel_runtime_pm.h \
intel_sideband.h \
+   intel_uc_fw.h \
intel_uncore.h \
intel_wakeref.h
 
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.h 
b/drivers/gpu/drm/i915/intel_uc_fw.h
index ff98f8661d72..24e66469153c 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/intel_uc_fw.h
@@ -25,6 +25,8 @@
 #ifndef _INTEL_UC_FW_H_
 #define _INTEL_UC_FW_H_
 
+#include 
+
 struct drm_printer;
 struct drm_i915_private;
 
-- 
2.20.1

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

[Intel-gfx] [PATCH 08/11] drm/i915: make intel_guc_reg.h self-contained

2019-06-17 Thread Jani Nikula
Add the minimal includes/declarations to make the header self-contained,
and ensure it stays that way.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/Makefile.header-test | 1 +
 drivers/gpu/drm/i915/intel_guc_reg.h  | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/Makefile.header-test 
b/drivers/gpu/drm/i915/Makefile.header-test
index b140afeb617e..085fba8e71f2 100644
--- a/drivers/gpu/drm/i915/Makefile.header-test
+++ b/drivers/gpu/drm/i915/Makefile.header-test
@@ -22,6 +22,7 @@ header_test := \
intel_drv.h \
intel_guc_ct.h \
intel_guc_fwif.h \
+   intel_guc_reg.h \
intel_pm.h \
intel_runtime_pm.h \
intel_sideband.h \
diff --git a/drivers/gpu/drm/i915/intel_guc_reg.h 
b/drivers/gpu/drm/i915/intel_guc_reg.h
index a214f8b71929..02f4b1d61a98 100644
--- a/drivers/gpu/drm/i915/intel_guc_reg.h
+++ b/drivers/gpu/drm/i915/intel_guc_reg.h
@@ -24,6 +24,9 @@
 #ifndef _INTEL_GUC_REG_H_
 #define _INTEL_GUC_REG_H_
 
+#include 
+#include 
+
 /* Definitions of GuC H/W registers, bits, etc */
 
 #define GUC_STATUS _MMIO(0xc000)
-- 
2.20.1

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

[Intel-gfx] [PATCH 05/11] drm/i915: make i915_vgpu.h self-contained

2019-06-17 Thread Jani Nikula
Add the minimal includes/declarations to make the header self-contained,
and ensure it stays that way.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/Makefile.header-test | 1 +
 drivers/gpu/drm/i915/i915_vgpu.h  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/Makefile.header-test 
b/drivers/gpu/drm/i915/Makefile.header-test
index c0d1663e5b61..0961b661df09 100644
--- a/drivers/gpu/drm/i915/Makefile.header-test
+++ b/drivers/gpu/drm/i915/Makefile.header-test
@@ -17,6 +17,7 @@ header_test := \
i915_scheduler_types.h \
i915_timeline_types.h \
i915_utils.h \
+   i915_vgpu.h \
intel_csr.h \
intel_drv.h \
intel_pm.h \
diff --git a/drivers/gpu/drm/i915/i915_vgpu.h b/drivers/gpu/drm/i915/i915_vgpu.h
index ebe1b7bced98..0ad3c491c5d9 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.h
+++ b/drivers/gpu/drm/i915/i915_vgpu.h
@@ -24,6 +24,7 @@
 #ifndef _I915_VGPU_H_
 #define _I915_VGPU_H_
 
+#include "i915_drv.h"
 #include "i915_pvinfo.h"
 
 void i915_check_vgpu(struct drm_i915_private *dev_priv);
-- 
2.20.1

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

[Intel-gfx] [PATCH 06/11] drm/i915: make intel_guc_ct.h self-contained

2019-06-17 Thread Jani Nikula
Add the minimal includes/declarations to make the header self-contained,
and ensure it stays that way.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/Makefile.header-test | 1 +
 drivers/gpu/drm/i915/intel_guc_ct.h   | 6 --
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/Makefile.header-test 
b/drivers/gpu/drm/i915/Makefile.header-test
index 0961b661df09..315f0b7d0406 100644
--- a/drivers/gpu/drm/i915/Makefile.header-test
+++ b/drivers/gpu/drm/i915/Makefile.header-test
@@ -20,6 +20,7 @@ header_test := \
i915_vgpu.h \
intel_csr.h \
intel_drv.h \
+   intel_guc_ct.h \
intel_pm.h \
intel_runtime_pm.h \
intel_sideband.h \
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.h 
b/drivers/gpu/drm/i915/intel_guc_ct.h
index 41ba593a4df7..d7b8c1223964 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.h
+++ b/drivers/gpu/drm/i915/intel_guc_ct.h
@@ -24,11 +24,13 @@
 #ifndef _INTEL_GUC_CT_H_
 #define _INTEL_GUC_CT_H_
 
-struct intel_guc;
-struct i915_vma;
+#include 
+#include 
 
 #include "intel_guc_fwif.h"
 
+struct i915_vma;
+
 /**
  * DOC: Command Transport (CT).
  *
-- 
2.20.1

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

[Intel-gfx] [PATCH 09/11] drm/i915: make intel_gvt.h self-contained

2019-06-17 Thread Jani Nikula
Add the minimal includes/declarations to make the header self-contained,
and ensure it stays that way.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/Makefile.header-test | 1 +
 drivers/gpu/drm/i915/intel_gvt.h  | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/Makefile.header-test 
b/drivers/gpu/drm/i915/Makefile.header-test
index 085fba8e71f2..5ae2cae27e85 100644
--- a/drivers/gpu/drm/i915/Makefile.header-test
+++ b/drivers/gpu/drm/i915/Makefile.header-test
@@ -23,6 +23,7 @@ header_test := \
intel_guc_ct.h \
intel_guc_fwif.h \
intel_guc_reg.h \
+   intel_gvt.h \
intel_pm.h \
intel_runtime_pm.h \
intel_sideband.h \
diff --git a/drivers/gpu/drm/i915/intel_gvt.h b/drivers/gpu/drm/i915/intel_gvt.h
index 61b246470282..85ce37eb7cd6 100644
--- a/drivers/gpu/drm/i915/intel_gvt.h
+++ b/drivers/gpu/drm/i915/intel_gvt.h
@@ -24,7 +24,7 @@
 #ifndef _INTEL_GVT_H_
 #define _INTEL_GVT_H_
 
-struct intel_gvt;
+struct drm_i915_private;
 
 #ifdef CONFIG_DRM_I915_GVT
 int intel_gvt_init(struct drm_i915_private *dev_priv);
-- 
2.20.1

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

[Intel-gfx] [PATCH 07/11] drm/i915: make intel_guc_fwif.h self-contained

2019-06-17 Thread Jani Nikula
Add the minimal includes/declarations to make the header self-contained,
and ensure it stays that way.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/Makefile.header-test | 1 +
 drivers/gpu/drm/i915/intel_guc_fwif.h | 4 
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/Makefile.header-test 
b/drivers/gpu/drm/i915/Makefile.header-test
index 315f0b7d0406..b140afeb617e 100644
--- a/drivers/gpu/drm/i915/Makefile.header-test
+++ b/drivers/gpu/drm/i915/Makefile.header-test
@@ -21,6 +21,7 @@ header_test := \
intel_csr.h \
intel_drv.h \
intel_guc_ct.h \
+   intel_guc_fwif.h \
intel_pm.h \
intel_runtime_pm.h \
intel_sideband.h \
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index f55f3bc8524d..92bd7ffb5b10 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -23,6 +23,10 @@
 #ifndef _INTEL_GUC_FWIF_H
 #define _INTEL_GUC_FWIF_H
 
+#include 
+#include 
+#include 
+
 #define GUC_CLIENT_PRIORITY_KMD_HIGH   0
 #define GUC_CLIENT_PRIORITY_HIGH   1
 #define GUC_CLIENT_PRIORITY_KMD_NORMAL 2
-- 
2.20.1

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

Re: [Intel-gfx] [PATCH 09/59] drm/prime: Align gem_prime_export with obj_funcs.export

2019-06-17 Thread Thierry Reding
On Fri, Jun 14, 2019 at 10:35:25PM +0200, Daniel Vetter wrote:
> The idea is that gem_prime_export is deprecated in favor of
> obj_funcs.export. That's much easier to do if both have matching
> function signatures.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Russell King 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Zhenyu Wang 
> Cc: Zhi Wang 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: Tomi Valkeinen 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: "David (ChunMing) Zhou" 
> Cc: Thierry Reding 
> Cc: Jonathan Hunter 
> Cc: Dave Airlie 
> Cc: Eric Anholt 
> Cc: "Michel Dänzer" 
> Cc: Chris Wilson 
> Cc: Huang Rui 
> Cc: Felix Kuehling 
> Cc: Hawking Zhang 
> Cc: Feifei Xu 
> Cc: Jim Qu 
> Cc: Evan Quan 
> Cc: Matthew Auld 
> Cc: Mika Kuoppala 
> Cc: Thomas Zimmermann 
> Cc: Kate Stewart 
> Cc: Sumit Semwal 
> Cc: Jilayne Lovejoy 
> Cc: Thomas Gleixner 
> Cc: Mikulas Patocka 
> Cc: Greg Kroah-Hartman 
> Cc: Junwei Zhang 
> Cc: intel-gvt-...@lists.freedesktop.org
> Cc: intel-gfx@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> Cc: linux-te...@vger.kernel.org
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c  | 7 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h  | 3 +--
>  drivers/gpu/drm/armada/armada_gem.c  | 5 ++---
>  drivers/gpu/drm/armada/armada_gem.h  | 3 +--
>  drivers/gpu/drm/drm_prime.c  | 9 -
>  drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c   | 5 ++---
>  drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 8 
>  drivers/gpu/drm/i915/gvt/dmabuf.c| 2 +-
>  drivers/gpu/drm/i915/i915_drv.h  | 3 +--
>  drivers/gpu/drm/omapdrm/omap_gem.h   | 3 +--
>  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c| 5 ++---
>  drivers/gpu/drm/radeon/radeon_drv.c  | 3 +--
>  drivers/gpu/drm/radeon/radeon_prime.c| 5 ++---
>  drivers/gpu/drm/tegra/gem.c  | 7 +++
>  drivers/gpu/drm/tegra/gem.h  | 3 +--
>  drivers/gpu/drm/udl/udl_dmabuf.c | 5 ++---
>  drivers/gpu/drm/udl/udl_drv.h| 3 +--
>  drivers/gpu/drm/vc4/vc4_bo.c | 5 ++---
>  drivers/gpu/drm/vc4/vc4_drv.h| 3 +--
>  drivers/gpu/drm/vgem/vgem_fence.c| 2 +-
>  include/drm/drm_drv.h| 4 ++--
>  include/drm/drm_prime.h  | 3 +--
>  22 files changed, 39 insertions(+), 57 deletions(-)

Acked-by: Thierry Reding 


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

[Intel-gfx] [PATCH] drm/i915/guc: Reduce verbosity on log overflows

2019-06-17 Thread Chris Wilson
If the user is clearing the log buffer too slowly, we overflow. As this
is an expected condition, and the driver tries to handle it, reduce the
error message down to a notice.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110817
Signed-off-by: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_guc_log.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index bf1446629703..e3b83ecb90b5 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -208,7 +208,9 @@ static bool guc_check_log_buf_overflow(struct intel_guc_log 
*log,
/* buffer_full_cnt is a 4 bit counter */
log->stats[type].sampled_overflow += 16;
}
-   DRM_ERROR_RATELIMITED("GuC log buffer overflow\n");
+
+   dev_notice_ratelimited(guc_to_i915(log_to_guc(log))->drm.dev,
+  "GuC log buffer overflow\n");
}
 
return overflow;
-- 
2.20.1

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

[Intel-gfx] ✓ Fi.CI.IGT: success for prime doc polish and ... a few cleanups

2019-06-17 Thread Patchwork
== Series Details ==

Series: prime doc polish and ... a few cleanups
URL   : https://patchwork.freedesktop.org/series/62135/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6277_full -> Patchwork_13296_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_tiled_swapping@non-threaded:
- shard-iclb: [PASS][1] -> [FAIL][2] ([fdo#108686])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb7/igt@gem_tiled_swapp...@non-threaded.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13296/shard-iclb1/igt@gem_tiled_swapp...@non-threaded.html

  * igt@gem_userptr_blits@map-fixed-invalidate-busy-gup:
- shard-skl:  [PASS][3] -> [DMESG-WARN][4] ([fdo#110913 ]) +2 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-skl3/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13296/shard-skl4/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html

  * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy:
- shard-kbl:  [PASS][5] -> [DMESG-WARN][6] ([fdo#110913 ])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-kbl7/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13296/shard-kbl6/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html
- shard-apl:  [PASS][7] -> [DMESG-WARN][8] ([fdo#110913 ]) +1 
similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-apl6/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13296/shard-apl2/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html

  * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup:
- shard-snb:  [PASS][9] -> [DMESG-WARN][10] ([fdo#110913 ])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-snb5/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13296/shard-snb2/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
- shard-kbl:  [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +1 
similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-kbl3/igt@kms_f...@flip-vs-suspend-interruptible.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13296/shard-kbl4/igt@kms_f...@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-stridechange:
- shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103167]) +6 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb1/igt@kms_frontbuffer_track...@fbc-stridechange.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13296/shard-iclb7/igt@kms_frontbuffer_track...@fbc-stridechange.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-apl:  [PASS][15] -> [DMESG-WARN][16] ([fdo#108566]) +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-apl3/igt@kms_frontbuffer_track...@fbc-suspend.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13296/shard-apl3/igt@kms_frontbuffer_track...@fbc-suspend.html

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-kbl:  [PASS][17] -> [FAIL][18] ([fdo#108145])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-kbl4/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13296/shard-kbl4/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html

  * igt@kms_plane_lowres@pipe-a-tiling-x:
- shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103166]) +1 similar 
issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb3/igt@kms_plane_low...@pipe-a-tiling-x.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13296/shard-iclb8/igt@kms_plane_low...@pipe-a-tiling-x.html

  * igt@kms_psr@psr2_no_drrs:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +2 similar 
issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb2/igt@kms_psr@psr2_no_drrs.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13296/shard-iclb3/igt@kms_psr@psr2_no_drrs.html

  * igt@kms_setmode@basic:
- shard-kbl:  [PASS][23] -> [FAIL][24] ([fdo#99912])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-kbl1/igt@kms_setm...@basic.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13296/shard-kbl2/igt@kms_setm...@basic.html

  
 Possible fixes 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/ehl: Add missing VECS engine

2019-06-17 Thread Patchwork
== Series Details ==

Series: drm/i915/ehl: Add missing VECS engine
URL   : https://patchwork.freedesktop.org/series/62143/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6277_full -> Patchwork_13297_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110854])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb4/igt@gem_exec_balan...@smoke.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-iclb8/igt@gem_exec_balan...@smoke.html

  * 
igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrash-inactive:
- shard-snb:  [PASS][3] -> [INCOMPLETE][4] ([fdo#105411])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-snb5/igt@gem_persistent_rel...@forked-interruptible-faulting-reloc-thrash-inactive.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-snb4/igt@gem_persistent_rel...@forked-interruptible-faulting-reloc-thrash-inactive.html

  * igt@gem_persistent_relocs@forked-interruptible-thrashing:
- shard-snb:  [PASS][5] -> [DMESG-WARN][6] ([fdo#110789] / 
[fdo#110913 ])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-snb6/igt@gem_persistent_rel...@forked-interruptible-thrashing.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-snb5/igt@gem_persistent_rel...@forked-interruptible-thrashing.html

  * igt@gem_ringfill@basic-default-hang:
- shard-glk:  [PASS][7] -> [DMESG-WARN][8] ([fdo#110913 ])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-glk4/igt@gem_ringf...@basic-default-hang.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-glk7/igt@gem_ringf...@basic-default-hang.html

  * igt@gem_tiled_swapping@non-threaded:
- shard-iclb: [PASS][9] -> [INCOMPLETE][10] ([fdo#107713] / 
[fdo#108686])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb7/igt@gem_tiled_swapp...@non-threaded.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-iclb2/igt@gem_tiled_swapp...@non-threaded.html
- shard-glk:  [PASS][11] -> [DMESG-WARN][12] ([fdo#108686])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-glk8/igt@gem_tiled_swapp...@non-threaded.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-glk2/igt@gem_tiled_swapp...@non-threaded.html

  * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy:
- shard-kbl:  [PASS][13] -> [DMESG-WARN][14] ([fdo#110913 ])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-kbl7/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-kbl2/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html

  * igt@i915_suspend@debugfs-reader:
- shard-apl:  [PASS][15] -> [DMESG-WARN][16] ([fdo#108566])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-apl5/igt@i915_susp...@debugfs-reader.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-apl1/igt@i915_susp...@debugfs-reader.html

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-glk:  [PASS][17] -> [FAIL][18] ([fdo#104873])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-glk4/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-glk9/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html

  * igt@kms_frontbuffer_tracking@fbc-stridechange:
- shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +4 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb1/igt@kms_frontbuffer_track...@fbc-stridechange.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-iclb8/igt@kms_frontbuffer_track...@fbc-stridechange.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- shard-kbl:  [PASS][21] -> [DMESG-WARN][22] ([fdo#108566]) +4 
similar issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-kbl6/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-kbl2/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  * igt@kms_plane_lowres@pipe-a-tiling-x:
- shard-iclb: [PASS][23] -> [FAIL][24] ([fdo#103166]) +1 similar 
issue
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb3/igt@kms_plane_low...@pipe-a-tiling-x.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-iclb6/igt@kms_plane_low...@pipe-a-til

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/3] drm/i915: Keep contexts pinned until after the next kernel context switch (rev2)

2019-06-17 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/3] drm/i915: Keep contexts pinned until 
after the next kernel context switch (rev2)
URL   : https://patchwork.freedesktop.org/series/62124/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6277_full -> Patchwork_13295_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_eio@in-flight-1us:
- shard-glk:  [PASS][1] -> [DMESG-WARN][2] ([fdo#110913 ])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-glk4/igt@gem_...@in-flight-1us.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13295/shard-glk6/igt@gem_...@in-flight-1us.html

  * igt@gem_eio@wait-wedge-1us:
- shard-apl:  [PASS][3] -> [DMESG-WARN][4] ([fdo#110913 ]) +1 
similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-apl7/igt@gem_...@wait-wedge-1us.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13295/shard-apl2/igt@gem_...@wait-wedge-1us.html

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#110854])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb4/igt@gem_exec_balan...@smoke.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13295/shard-iclb8/igt@gem_exec_balan...@smoke.html

  * igt@gem_tiled_swapping@non-threaded:
- shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([fdo#107713] / 
[fdo#108686])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb7/igt@gem_tiled_swapp...@non-threaded.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13295/shard-iclb6/igt@gem_tiled_swapp...@non-threaded.html

  * igt@gem_userptr_blits@map-fixed-invalidate-busy-gup:
- shard-skl:  [PASS][9] -> [DMESG-WARN][10] ([fdo#110913 ])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-skl3/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13295/shard-skl8/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html

  * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy:
- shard-kbl:  [PASS][11] -> [DMESG-WARN][12] ([fdo#110913 ])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-kbl7/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13295/shard-kbl4/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html

  * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup:
- shard-iclb: [PASS][13] -> [DMESG-WARN][14] ([fdo#110913 ])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb6/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13295/shard-iclb3/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html
- shard-snb:  [PASS][15] -> [DMESG-WARN][16] ([fdo#110913 ])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-snb5/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13295/shard-snb5/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html

  * igt@i915_pm_rc6_residency@rc6-accuracy:
- shard-kbl:  [PASS][17] -> [SKIP][18] ([fdo#109271])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-kbl2/igt@i915_pm_rc6_reside...@rc6-accuracy.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13295/shard-kbl2/igt@i915_pm_rc6_reside...@rc6-accuracy.html

  * igt@i915_suspend@debugfs-reader:
- shard-skl:  [PASS][19] -> [INCOMPLETE][20] ([fdo#104108])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-skl10/igt@i915_susp...@debugfs-reader.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13295/shard-skl9/igt@i915_susp...@debugfs-reader.html

  * igt@i915_suspend@fence-restore-tiled2untiled:
- shard-kbl:  [PASS][21] -> [DMESG-WARN][22] ([fdo#108566])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-kbl1/igt@i915_susp...@fence-restore-tiled2untiled.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13295/shard-kbl7/igt@i915_susp...@fence-restore-tiled2untiled.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-apl:  [PASS][23] -> [DMESG-WARN][24] ([fdo#108566]) +1 
similar issue
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-apl8/igt@kms_cursor_...@pipe-c-cursor-suspend.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13295/shard-apl6/igt@kms_cursor_...@pipe-c-cursor-suspend.html

  * igt@kms_flip@2x-flip-vs-expired-vblank:
- shard-glk:  [PASS][2

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/ehl: Allow combo PHY A to drive a third external display

2019-06-17 Thread Patchwork
== Series Details ==

Series: drm/i915/ehl: Allow combo PHY A to drive a third external display
URL   : https://patchwork.freedesktop.org/series/62131/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6277_full -> Patchwork_13293_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_eio@in-flight-1us:
- shard-glk:  [PASS][1] -> [DMESG-WARN][2] ([fdo#110913 ])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-glk4/igt@gem_...@in-flight-1us.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13293/shard-glk9/igt@gem_...@in-flight-1us.html

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110854])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb4/igt@gem_exec_balan...@smoke.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13293/shard-iclb7/igt@gem_exec_balan...@smoke.html

  * igt@gem_persistent_relocs@forked-interruptible-thrashing:
- shard-snb:  [PASS][5] -> [DMESG-WARN][6] ([fdo#110789] / 
[fdo#110913 ])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-snb6/igt@gem_persistent_rel...@forked-interruptible-thrashing.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13293/shard-snb7/igt@gem_persistent_rel...@forked-interruptible-thrashing.html

  * igt@gem_userptr_blits@map-fixed-invalidate-busy-gup:
- shard-apl:  [PASS][7] -> [DMESG-WARN][8] ([fdo#110913 ])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-apl7/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13293/shard-apl2/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html
- shard-skl:  [PASS][9] -> [DMESG-WARN][10] ([fdo#110913 ]) +2 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-skl3/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13293/shard-skl6/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html

  * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy:
- shard-kbl:  [PASS][11] -> [DMESG-WARN][12] ([fdo#110913 ]) +1 
similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-kbl7/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13293/shard-kbl7/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html

  * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup:
- shard-iclb: [PASS][13] -> [DMESG-WARN][14] ([fdo#110913 ])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb6/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13293/shard-iclb2/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html
- shard-snb:  [PASS][15] -> [DMESG-WARN][16] ([fdo#110913 ])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-snb5/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13293/shard-snb2/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html

  * igt@i915_suspend@sysfs-reader:
- shard-apl:  [PASS][17] -> [DMESG-WARN][18] ([fdo#108566]) +2 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-apl7/igt@i915_susp...@sysfs-reader.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13293/shard-apl1/igt@i915_susp...@sysfs-reader.html

  * igt@kms_flip@flip-vs-suspend:
- shard-kbl:  [PASS][19] -> [DMESG-WARN][20] ([fdo#108566])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-kbl7/igt@kms_f...@flip-vs-suspend.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13293/shard-kbl7/igt@kms_f...@flip-vs-suspend.html

  * igt@kms_flip@modeset-vs-vblank-race-interruptible:
- shard-glk:  [PASS][21] -> [FAIL][22] ([fdo#103060])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-glk5/igt@kms_f...@modeset-vs-vblank-race-interruptible.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13293/shard-glk8/igt@kms_f...@modeset-vs-vblank-race-interruptible.html

  * igt@kms_flip@plain-flip-ts-check-interruptible:
- shard-glk:  [PASS][23] -> [FAIL][24] ([fdo#100368])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-glk5/igt@kms_f...@plain-flip-ts-check-interruptible.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13293/shard-glk8/igt@kms_f...@plain-flip-ts-check-interruptible.html

  * igt@kms_frontbuffer_tracking@fb

[Intel-gfx] [PATCH] Documentation/i915: fix file references after display/ subdir renames

2019-06-17 Thread Jani Nikula
Fix the plethora of Sphinx build errors after moving the display files
under a subdirectory.

Fixes: 379bc100232a ("drm/i915: move modesetting output/encoder code under 
display/")
Fixes: df0566a641f9 ("drm/i915: move modesetting core code under display/")
Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Cc: Ville Syrjälä 
Cc: Maarten Lankhorst 
Signed-off-by: Jani Nikula 
---
 Documentation/gpu/i915.rst | 66 +++---
 1 file changed, 33 insertions(+), 33 deletions(-)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 300220c4b498..c38ef0dda605 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -82,13 +82,13 @@ change.
 Frontbuffer Tracking
 
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_frontbuffer.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_frontbuffer.c
:doc: frontbuffer tracking
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_frontbuffer.h
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_frontbuffer.h
:internal:
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_frontbuffer.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_frontbuffer.c
:internal:
 
 .. kernel-doc:: drivers/gpu/drm/i915/i915_gem.c
@@ -97,10 +97,10 @@ Frontbuffer Tracking
 Display FIFO Underrun Reporting
 ---
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_fifo_underrun.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fifo_underrun.c
:doc: fifo underrun handling
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_fifo_underrun.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fifo_underrun.c
:internal:
 
 Plane Configuration
@@ -115,10 +115,10 @@ panel self refresh.
 Atomic Plane Helpers
 
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_atomic_plane.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_atomic_plane.c
:doc: atomic plane helpers
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_atomic_plane.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_atomic_plane.c
:internal:
 
 Output Probing
@@ -132,19 +132,19 @@ probing, so those sections fully apply.
 Hotplug
 ---
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_hotplug.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_hotplug.c
:doc: Hotplug
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_hotplug.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_hotplug.c
:internal:
 
 High Definition Audio
 -
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_audio.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_audio.c
:doc: High Definition Audio over HDMI and Display Port
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_audio.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_audio.c
:internal:
 
 .. kernel-doc:: include/drm/i915_component.h
@@ -153,58 +153,58 @@ High Definition Audio
 Intel HDMI LPE Audio Support
 
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_lpe_audio.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_lpe_audio.c
:doc: LPE Audio integration for HDMI or DP playback
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_lpe_audio.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_lpe_audio.c
:internal:
 
 Panel Self Refresh PSR (PSR/SRD)
 
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_psr.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_psr.c
:doc: Panel Self Refresh (PSR/SRD)
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_psr.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_psr.c
:internal:
 
 Frame Buffer Compression (FBC)
 --
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_fbc.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fbc.c
:doc: Frame Buffer Compression (FBC)
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_fbc.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fbc.c
:internal:
 
 Display Refresh Rate Switching (DRRS)
 -
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_dp.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dp.c
:doc: Display Refresh Rate Switching (DRRS)
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_dp.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dp.c
:functions: intel_dp_set_drrs_state
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_dp.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dp.c
:functions: intel_edp_drrs_enable
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_dp.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dp.c
:functions: intel_edp_drrs_disable
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_dp.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dp.c
:functions: intel_edp_drrs_invalidate
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_dp.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dp.c
:functions: intel_edp_drrs_flush
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_dp.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [01/10] drm/i915/gtt: No need to zero the table for page dirs

2019-06-17 Thread Patchwork
== Series Details ==

Series: series starting with [01/10] drm/i915/gtt: No need to zero the table 
for page dirs
URL   : https://patchwork.freedesktop.org/series/62122/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6277_full -> Patchwork_13289_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_eio@in-flight-internal-10ms:
- shard-skl:  [PASS][1] -> [DMESG-WARN][2] ([fdo#110913 ]) +2 
similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-skl10/igt@gem_...@in-flight-internal-10ms.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13289/shard-skl10/igt@gem_...@in-flight-internal-10ms.html

  * igt@gem_eio@in-flight-internal-1us:
- shard-apl:  [PASS][3] -> [DMESG-WARN][4] ([fdo#110913 ]) +1 
similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-apl1/igt@gem_...@in-flight-internal-1us.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13289/shard-apl4/igt@gem_...@in-flight-internal-1us.html

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#110854])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb4/igt@gem_exec_balan...@smoke.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13289/shard-iclb7/igt@gem_exec_balan...@smoke.html

  * igt@gem_persistent_relocs@forked-thrashing:
- shard-kbl:  [PASS][7] -> [DMESG-WARN][8] ([fdo#110913 ]) +2 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-kbl3/igt@gem_persistent_rel...@forked-thrashing.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13289/shard-kbl6/igt@gem_persistent_rel...@forked-thrashing.html

  * igt@gem_tiled_swapping@non-threaded:
- shard-iclb: [PASS][9] -> [FAIL][10] ([fdo#108686])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb7/igt@gem_tiled_swapp...@non-threaded.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13289/shard-iclb4/igt@gem_tiled_swapp...@non-threaded.html

  * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy:
- shard-glk:  [PASS][11] -> [DMESG-WARN][12] ([fdo#110913 ])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-glk3/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13289/shard-glk7/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html

  * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup:
- shard-iclb: [PASS][13] -> [DMESG-WARN][14] ([fdo#110913 ])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb6/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13289/shard-iclb7/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html
- shard-snb:  [PASS][15] -> [DMESG-WARN][16] ([fdo#110913 ])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-snb5/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13289/shard-snb7/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html

  * igt@gem_userptr_blits@sync-unmap-cycles:
- shard-hsw:  [PASS][17] -> [DMESG-WARN][18] ([fdo#110913 ])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-hsw7/igt@gem_userptr_bl...@sync-unmap-cycles.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13289/shard-hsw7/igt@gem_userptr_bl...@sync-unmap-cycles.html

  * igt@i915_pm_rpm@modeset-lpsp-stress-no-wait:
- shard-iclb: [PASS][19] -> [INCOMPLETE][20] ([fdo#107713] / 
[fdo#108840])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb2/igt@i915_pm_...@modeset-lpsp-stress-no-wait.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13289/shard-iclb2/igt@i915_pm_...@modeset-lpsp-stress-no-wait.html

  * igt@i915_suspend@fence-restore-tiled2untiled:
- shard-apl:  [PASS][21] -> [DMESG-WARN][22] ([fdo#108566]) +2 
similar issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-apl3/igt@i915_susp...@fence-restore-tiled2untiled.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13289/shard-apl3/igt@i915_susp...@fence-restore-tiled2untiled.html
- shard-skl:  [PASS][23] -> [INCOMPLETE][24] ([fdo#104108])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-skl6/igt@i915_susp...@fence-restore-tiled2untiled.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13289/shard-skl8/igt@i915_susp...@fence-restore-tiled2untiled.html

  * igt@kms_flip@2x-flip-vs-expired-

Re: [Intel-gfx] [PATCH 02/22] drm/i915/gtt: Serialise both updates to PDE and our shadow

2019-06-17 Thread Matthew Auld

On 17/06/2019 08:18, Chris Wilson wrote:

Currently, we perform a locked update of the shadow entry when
allocating a page directory entry such that if two clients are
concurrently allocating neighbouring ranges we only insert one new entry
for the pair of them. However, we also need to serialise both clients
wrt to the actual entry in the HW table, or else we may allow one client
or even a third client to proceed ahead of the HW write. My handwave
before was that under the _pathological_ condition we would see the
scratch entry instead of the expected entry, causing a temporary
glitch. That starvation condition will eventually show up in practice, so
fix it.

The reason for the previous cheat was to avoid having to free the extra
allocation while under the spinlock. Now, we keep the extra entry
allocated until the end instead.

Fixes: 1d1b5490b91c ("drm/i915/gtt: Replace struct_mutex serialisation for 
allocation")
Signed-off-by: Chris Wilson 
Cc: Matthew Auld 
Cc: Mika Kuoppala 
---


[snip]

  
  static int gen8_preallocate_top_level_pdp(struct i915_ppgtt *ppgtt)

@@ -1819,11 +1831,13 @@ static int gen6_alloc_va_range(struct 
i915_address_space *vm,
   u64 start, u64 length)
  {
struct gen6_ppgtt *ppgtt = to_gen6_ppgtt(i915_vm_to_ppgtt(vm));
+   struct i915_page_table *alloc = NULL;
struct i915_page_table *pt;
intel_wakeref_t wakeref;
u64 from = start;
unsigned int pde;
bool flush = false;
+   int ret;


ret = 0;

  
  	wakeref = intel_runtime_pm_get(&vm->i915->runtime_pm);
  
@@ -1832,19 +1846,18 @@ static int gen6_alloc_va_range(struct i915_address_space *vm,

const unsigned int count = gen6_pte_count(start, length);
  
  		if (pt == vm->scratch_pt) {

-   struct i915_page_table *old;
-
spin_unlock(&ppgtt->base.pd.lock);
  
-			pt = alloc_pt(vm);

+   pt = alloc;


We have to reset this, no?


+   if (!pt)
+   pt = alloc_pt(vm);
if (IS_ERR(pt))
goto unwind_out;


ret = PTR_ERR();

  
  			gen6_initialize_pt(vm, pt);
  
-			old = cmpxchg(&ppgtt->base.pd.page_table[pde],

- vm->scratch_pt, pt);
-   if (old == vm->scratch_pt) {
+   spin_lock(&ppgtt->base.pd.lock);
+   if (ppgtt->base.pd.page_table[pde] == vm->scratch_pt) {
ppgtt->base.pd.page_table[pde] = pt;
if (i915_vma_is_bound(ppgtt->vma,
  I915_VMA_GLOBAL_BIND)) {
@@ -1852,11 +1865,9 @@ static int gen6_alloc_va_range(struct i915_address_space 
*vm,
flush = true;
}
} else {
-   free_pt(vm, pt);
-   pt = old;
+   alloc = pt;
+   pt = ppgtt->base.pd.page_table[pde];
}
-
-   spin_lock(&ppgtt->base.pd.lock);
}
  
  		atomic_add(count, &pt->used_ptes);

@@ -1868,14 +1879,15 @@ static int gen6_alloc_va_range(struct 
i915_address_space *vm,
gen6_ggtt_invalidate(vm->i915);
}
  
-	intel_runtime_pm_put(&vm->i915->runtime_pm, wakeref);

-
-   return 0;
+   goto out;
  
  unwind_out:

-   intel_runtime_pm_put(&vm->i915->runtime_pm, wakeref);
gen6_ppgtt_clear_range(vm, from, start - from);
-   return -ENOMEM;
+out:
+   if (alloc)
+   free_pt(vm, alloc);
+   intel_runtime_pm_put(&vm->i915->runtime_pm, wakeref);
+   return ret;
  }
  
  static int gen6_ppgtt_init_scratch(struct gen6_ppgtt *ppgtt)



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

Re: [Intel-gfx] [PATCH 02/22] drm/i915/gtt: Serialise both updates to PDE and our shadow

2019-06-17 Thread Chris Wilson
Quoting Matthew Auld (2019-06-17 11:36:36)
> On 17/06/2019 08:18, Chris Wilson wrote:
> > Currently, we perform a locked update of the shadow entry when
> > allocating a page directory entry such that if two clients are
> > concurrently allocating neighbouring ranges we only insert one new entry
> > for the pair of them. However, we also need to serialise both clients
> > wrt to the actual entry in the HW table, or else we may allow one client
> > or even a third client to proceed ahead of the HW write. My handwave
> > before was that under the _pathological_ condition we would see the
> > scratch entry instead of the expected entry, causing a temporary
> > glitch. That starvation condition will eventually show up in practice, so
> > fix it.
> > 
> > The reason for the previous cheat was to avoid having to free the extra
> > allocation while under the spinlock. Now, we keep the extra entry
> > allocated until the end instead.
> > 
> > Fixes: 1d1b5490b91c ("drm/i915/gtt: Replace struct_mutex serialisation for 
> > allocation")
> > Signed-off-by: Chris Wilson 
> > Cc: Matthew Auld 
> > Cc: Mika Kuoppala 
> > ---
> 
> [snip]
> 
> >   
> >   static int gen8_preallocate_top_level_pdp(struct i915_ppgtt *ppgtt)
> > @@ -1819,11 +1831,13 @@ static int gen6_alloc_va_range(struct 
> > i915_address_space *vm,
> >  u64 start, u64 length)
> >   {
> >   struct gen6_ppgtt *ppgtt = to_gen6_ppgtt(i915_vm_to_ppgtt(vm));
> > + struct i915_page_table *alloc = NULL;
> >   struct i915_page_table *pt;
> >   intel_wakeref_t wakeref;
> >   u64 from = start;
> >   unsigned int pde;
> >   bool flush = false;
> > + int ret;
> 
> ret = 0;

Yeah, originally this kept to the separate exit paths, forgot to fix
after merging.

> >   wakeref = intel_runtime_pm_get(&vm->i915->runtime_pm);
> >   
> > @@ -1832,19 +1846,18 @@ static int gen6_alloc_va_range(struct 
> > i915_address_space *vm,
> >   const unsigned int count = gen6_pte_count(start, length);
> >   
> >   if (pt == vm->scratch_pt) {
> > - struct i915_page_table *old;
> > -
> >   spin_unlock(&ppgtt->base.pd.lock);
> >   
> > - pt = alloc_pt(vm);
> > + pt = alloc;
> 
> We have to reset this, no?

Yes, obviously missed after fixing the pattern for gen6.

> > + if (!pt)
> > + pt = alloc_pt(vm);
> >   if (IS_ERR(pt))
> >   goto unwind_out;
> 
> ret = PTR_ERR();

Sigh.
Thanks,
-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 tainting i915_gem_park() with wakeref.lock

2019-06-17 Thread Patchwork
== Series Details ==

Series: drm/i915: Avoid tainting i915_gem_park() with wakeref.lock
URL   : https://patchwork.freedesktop.org/series/62145/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6278_full -> Patchwork_13298_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_13298_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_13298_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_13298_full:

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_await@wide-contexts:
- shard-skl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6278/shard-skl3/igt@gem_exec_aw...@wide-contexts.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13298/shard-skl9/igt@gem_exec_aw...@wide-contexts.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_eio@wait-1us:
- shard-glk:  [PASS][3] -> [DMESG-WARN][4] ([fdo#110913 ]) +1 
similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6278/shard-glk8/igt@gem_...@wait-1us.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13298/shard-glk2/igt@gem_...@wait-1us.html

  * igt@gem_unfence_active_buffers:
- shard-apl:  [PASS][5] -> [DMESG-WARN][6] ([fdo#110913 ]) +1 
similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6278/shard-apl5/igt@gem_unfence_active_buffers.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13298/shard-apl2/igt@gem_unfence_active_buffers.html

  * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup:
- shard-kbl:  [PASS][7] -> [DMESG-WARN][8] ([fdo#110913 ]) +1 
similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6278/shard-kbl2/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13298/shard-kbl2/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html

  * igt@gem_workarounds@suspend-resume-context:
- shard-apl:  [PASS][9] -> [DMESG-WARN][10] ([fdo#108566])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6278/shard-apl2/igt@gem_workarou...@suspend-resume-context.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13298/shard-apl3/igt@gem_workarou...@suspend-resume-context.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-glk:  [PASS][11] -> [FAIL][12] ([fdo#105363])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6278/shard-glk2/igt@kms_f...@flip-vs-expired-vblank-interruptible.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13298/shard-glk9/igt@kms_f...@flip-vs-expired-vblank-interruptible.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
- shard-kbl:  [PASS][13] -> [DMESG-WARN][14] ([fdo#108566])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6278/shard-kbl1/igt@kms_f...@flip-vs-suspend-interruptible.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13298/shard-kbl1/igt@kms_f...@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt:
- shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +5 similar 
issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6278/shard-iclb4/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-blt.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13298/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-blt.html

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl:  [PASS][17] -> [FAIL][18] ([fdo#108145])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6278/shard-skl5/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13298/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html

  * igt@kms_plane_lowres@pipe-a-tiling-x:
- shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103166])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6278/shard-iclb8/igt@kms_plane_low...@pipe-a-tiling-x.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13298/shard-iclb8/igt@kms_plane_low...@pipe-a-tiling-x.html

  * igt@kms_psr2_su@frontbuffer:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109642])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6278/shard-iclb2/igt@kms_psr2...@frontbuffer.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132

[Intel-gfx] [PATCH i-g-t] i915/gem_ctx_shared: Check for a large enough hole in the GTT

2019-06-17 Thread Chris Wilson
In the exec-shared-gtt test, we cheekily try to reference an object we
placed in the GTT in an earlier execbuf (and avoid declaring it in the
later call). For a global GTT, where there may be existing objects, we
have to find a hole large enough to fit both and avoid and implicit
guard pages.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110876
Signed-off-by: Chris Wilson 
---
 tests/i915/gem_ctx_shared.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/tests/i915/gem_ctx_shared.c b/tests/i915/gem_ctx_shared.c
index ed43e8903..4b1020b96 100644
--- a/tests/i915/gem_ctx_shared.c
+++ b/tests/i915/gem_ctx_shared.c
@@ -184,6 +184,7 @@ static void exhaust_shared_gtt(int i915, unsigned int flags)
 static void exec_shared_gtt(int i915, unsigned int ring)
 {
const int gen = intel_gen(intel_get_drm_devid(i915));
+   const uint32_t bbe = MI_BATCH_BUFFER_END;
struct drm_i915_gem_exec_object2 obj = {};
struct drm_i915_gem_execbuffer2 execbuf = {
.buffers_ptr = to_user_pointer(&obj),
@@ -197,11 +198,19 @@ static void exec_shared_gtt(int i915, unsigned int ring)
gem_require_ring(i915, ring);
igt_require(gem_can_store_dword(i915, ring));
 
+   /* Find a hole big enough for both objects later */
+   scratch = gem_create(i915, 16384);
+   gem_write(i915, scratch, 0, &bbe, sizeof(bbe));
+   obj.handle = scratch;
+   gem_execbuf(i915, &execbuf);
+   gem_close(i915, scratch);
+   obj.flags |= EXEC_OBJECT_PINNED; /* reuse this address */
+
scratch = gem_create(i915, 4096);
s = gem_mmap__cpu(i915, scratch, 0, 4096, PROT_WRITE);
 
gem_set_domain(i915, scratch, I915_GEM_DOMAIN_CPU, I915_GEM_DOMAIN_CPU);
-   *s = MI_BATCH_BUFFER_END;
+   *s = bbe;
 
/* Load object into place in the GTT */
obj.handle = scratch;
@@ -224,11 +233,10 @@ static void exec_shared_gtt(int i915, unsigned int ring)
batch[++i] = obj.offset;
}
batch[++i] = 0xc0ffee;
-   batch[++i] = MI_BATCH_BUFFER_END;
+   batch[++i] = bbe;
gem_write(i915, obj.handle, 0, batch, sizeof(batch));
 
-   obj.offset += 4096; /* make sure we don't cause an eviction! */
-   obj.flags |= EXEC_OBJECT_PINNED;
+   obj.offset += 8192; /* make sure we don't cause an eviction! */
execbuf.rsvd1 = gem_context_clone(i915, 0, I915_CONTEXT_CLONE_VM, 0);
if (gen > 3 && gen < 6)
execbuf.flags |= I915_EXEC_SECURE;
-- 
2.20.1

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

[Intel-gfx] [PATCH v2] drm/i915/gtt: Serialise both updates to PDE and our shadow

2019-06-17 Thread Chris Wilson
Currently, we perform a locked update of the shadow entry when
allocating a page directory entry such that if two clients are
concurrently allocating neighbouring ranges we only insert one new entry
for the pair of them. However, we also need to serialise both clients
wrt to the actual entry in the HW table, or else we may allow one client
or even a third client to proceed ahead of the HW write. My handwave
before was that under the _pathological_ condition we would see the
scratch entry instead of the expected entry, causing a temporary
glitch. That starvation condition will eventually show up in practice, so
fix it.

The reason for the previous cheat was to avoid having to free the extra
allocation while under the spinlock. Now, we keep the extra entry
allocated until the end instead.

v2: Fix error paths for gen6

Fixes: 1d1b5490b91c ("drm/i915/gtt: Replace struct_mutex serialisation for 
allocation")
Signed-off-by: Chris Wilson 
Cc: Matthew Auld 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 130 +++-
 1 file changed, 72 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 0392a4c4bb9b..0987748d327b 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1387,82 +1387,88 @@ static int gen8_ppgtt_alloc_pd(struct 
i915_address_space *vm,
   struct i915_page_directory *pd,
   u64 start, u64 length)
 {
+   struct i915_page_table *alloc = NULL;
struct i915_page_table *pt;
u64 from = start;
unsigned int pde;
+   int ret = 0;
 
spin_lock(&pd->lock);
gen8_for_each_pde(pt, pd, start, length, pde) {
const int count = gen8_pte_count(start, length);
 
if (pt == vm->scratch_pt) {
-   struct i915_page_table *old;
-
spin_unlock(&pd->lock);
 
-   pt = alloc_pt(vm);
-   if (IS_ERR(pt))
+   pt = fetch_and_zero(&alloc);
+   if (!pt)
+   pt = alloc_pt(vm);
+   if (IS_ERR(pt)) {
+   ret = PTR_ERR(pt);
goto unwind;
+   }
 
if (count < GEN8_PTES || intel_vgpu_active(vm->i915))
gen8_initialize_pt(vm, pt);
 
-   old = cmpxchg(&pd->page_table[pde], vm->scratch_pt, pt);
-   if (old == vm->scratch_pt) {
+   spin_lock(&pd->lock);
+   if (pd->page_table[pde] == vm->scratch_pt) {
gen8_ppgtt_set_pde(vm, pd, pt, pde);
+   pd->page_table[pde] = pt;
atomic_inc(&pd->used_pdes);
} else {
-   free_pt(vm, pt);
-   pt = old;
+   alloc = pt;
+   pt = pd->page_table[pde];
}
-
-   spin_lock(&pd->lock);
}
 
atomic_add(count, &pt->used_ptes);
}
spin_unlock(&pd->lock);
-
-   return 0;
+   goto out;
 
 unwind:
gen8_ppgtt_clear_pd(vm, pd, from, start - from);
-   return -ENOMEM;
+out:
+   if (alloc)
+   free_pt(vm, alloc);
+   return ret;
 }
 
 static int gen8_ppgtt_alloc_pdp(struct i915_address_space *vm,
struct i915_page_directory_pointer *pdp,
u64 start, u64 length)
 {
+   struct i915_page_directory *alloc = NULL;
struct i915_page_directory *pd;
u64 from = start;
unsigned int pdpe;
-   int ret;
+   int ret = 0;
 
spin_lock(&pdp->lock);
gen8_for_each_pdpe(pd, pdp, start, length, pdpe) {
if (pd == vm->scratch_pd) {
-   struct i915_page_directory *old;
-
spin_unlock(&pdp->lock);
 
-   pd = alloc_pd(vm);
-   if (IS_ERR(pd))
+   pd = fetch_and_zero(&alloc);
+   if (!pd)
+   pd = alloc_pd(vm);
+   if (IS_ERR(pd)) {
+   ret = PTR_ERR(pd);
goto unwind;
+   }
 
gen8_initialize_pd(vm, pd);
 
-   old = cmpxchg(&pdp->page_directory[pdpe],
- vm->scratch_pd, pd);
-   if (old == vm->scratch_pd) {
+   spin_lock(&pdp->lock);
+   if (pdp->page_directory[pdpe] == vm->scratch_pd) {
gen8_ppgtt_set_pdpe(vm, 

Re: [Intel-gfx] [PATCH v2] drm/i915/gtt: Serialise both updates to PDE and our shadow

2019-06-17 Thread Matthew Auld

On 17/06/2019 12:20, Chris Wilson wrote:

Currently, we perform a locked update of the shadow entry when
allocating a page directory entry such that if two clients are
concurrently allocating neighbouring ranges we only insert one new entry
for the pair of them. However, we also need to serialise both clients
wrt to the actual entry in the HW table, or else we may allow one client
or even a third client to proceed ahead of the HW write. My handwave
before was that under the _pathological_ condition we would see the
scratch entry instead of the expected entry, causing a temporary
glitch. That starvation condition will eventually show up in practice, so
fix it.

The reason for the previous cheat was to avoid having to free the extra
allocation while under the spinlock. Now, we keep the extra entry
allocated until the end instead.

v2: Fix error paths for gen6

Fixes: 1d1b5490b91c ("drm/i915/gtt: Replace struct_mutex serialisation for 
allocation")
Signed-off-by: Chris Wilson 
Cc: Matthew Auld 
Cc: Mika Kuoppala 

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

[Intel-gfx] [PATCH 2/6] drm/ttm: remove the backing store if no placement is given

2019-06-17 Thread Christian König
Pipeline removal of the BOs backing store when no placement is given
during validation.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c7de667d482a..682a1a035b35 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1240,6 +1240,18 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
uint32_t new_flags;
 
reservation_object_assert_held(bo->resv);
+
+   /*
+* Remove the backing store if no placement is given.
+*/
+   if (!placement->num_placement && !placement->num_busy_placement) {
+   ret = ttm_bo_pipeline_gutting(bo);
+   if (ret)
+   return ret;
+
+   return ttm_tt_create(bo, false);
+   }
+
/*
 * Check whether we need to move buffer.
 */
-- 
2.17.1

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

[Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10

2019-06-17 Thread Christian König
On the exporter side we add optional explicit pinning callbacks. If those
callbacks are implemented the framework no longer caches sg tables and the
map/unmap callbacks are always called with the lock of the reservation object
held.

On the importer side we add an optional invalidate callback. This callback is
used by the exporter to inform the importers that their mappings should be
destroyed as soon as possible.

This allows the exporter to provide the mappings without the need to pin
the backing store.

v2: don't try to invalidate mappings when the callback is NULL,
lock the reservation obj while using the attachments,
add helper to set the callback
v3: move flag for invalidation support into the DMA-buf,
use new attach_info structure to set the callback
v4: use importer_priv field instead of mangling exporter priv.
v5: drop invalidation_supported flag
v6: squash together with pin/unpin changes
v7: pin/unpin takes an attachment now
v8: nuke dma_buf_attachment_(map|unmap)_locked,
everything is now handled backward compatible
v9: always cache when export/importer don't agree on dynamic handling
v10: minimal style cleanup

Signed-off-by: Christian König 
---
 drivers/dma-buf/dma-buf.c | 188 --
 include/linux/dma-buf.h   | 109 --
 2 files changed, 283 insertions(+), 14 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index a2d34c6b80a5..f756870ba509 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -409,6 +409,9 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
return ERR_PTR(-EINVAL);
}
 
+   if (WARN_ON(exp_info->ops->cache_sgt_mapping && exp_info->ops->pin))
+   return ERR_PTR(-EINVAL);
+
if (!try_module_get(exp_info->owner))
return ERR_PTR(-ENOENT);
 
@@ -530,10 +533,12 @@ void dma_buf_put(struct dma_buf *dmabuf)
 EXPORT_SYMBOL_GPL(dma_buf_put);
 
 /**
- * dma_buf_attach - Add the device to dma_buf's attachments list; optionally,
+ * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list; 
optionally,
  * calls attach() of dma_buf_ops to allow device-specific attach functionality
- * @dmabuf:[in]buffer to attach device to.
- * @dev:   [in]device to be attached.
+ * @dmabuf:[in]buffer to attach device to.
+ * @dev:   [in]device to be attached.
+ * @importer_ops   [in]importer operations for the attachment
+ * @importer_priv  [in]importer private pointer for the attachment
  *
  * Returns struct dma_buf_attachment pointer for this attachment. Attachments
  * must be cleaned up by calling dma_buf_detach().
@@ -547,8 +552,10 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
  * accessible to @dev, and cannot be moved to a more suitable place. This is
  * indicated with the error code -EBUSY.
  */
-struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
- struct device *dev)
+struct dma_buf_attachment *
+dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
+  const struct dma_buf_attach_ops *importer_ops,
+  void *importer_priv)
 {
struct dma_buf_attachment *attach;
int ret;
@@ -562,6 +569,8 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
*dmabuf,
 
attach->dev = dev;
attach->dmabuf = dmabuf;
+   attach->importer_ops = importer_ops;
+   attach->importer_priv = importer_priv;
 
mutex_lock(&dmabuf->lock);
 
@@ -570,16 +579,72 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
*dmabuf,
if (ret)
goto err_attach;
}
+   reservation_object_lock(dmabuf->resv, NULL);
list_add(&attach->node, &dmabuf->attachments);
+   reservation_object_unlock(dmabuf->resv);
 
mutex_unlock(&dmabuf->lock);
 
+   /* When either the importer or the exporter can't handle dynamic
+* mappings we cache the mapping here to avoid issues with the
+* reservation object lock.
+*/
+   if (dma_buf_attachment_is_dynamic(attach) !=
+   dma_buf_is_dynamic(dmabuf)) {
+   struct sg_table *sgt;
+
+   if (dma_buf_is_dynamic(attach->dmabuf)) {
+   reservation_object_lock(attach->dmabuf->resv, NULL);
+   ret = dma_buf_pin(attach);
+   if (ret)
+   goto err_unlock;
+   }
+
+   sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
+   if (!sgt)
+   sgt = ERR_PTR(-ENOMEM);
+   if (IS_ERR(sgt)) {
+   ret = PTR_ERR(sgt);
+   goto err_unpin;
+   }
+   if (dma_buf_is_dynamic(attach->dmabuf))
+   reservation_object_unlock(attach->dmabuf->re

[Intel-gfx] [PATCH 3/6] drm/ttm: use the parent resv for ghost objects v2

2019-06-17 Thread Christian König
This way we can even pipeline imported BO evictions.

v2: Limit this to only cases when the parent object uses a separate
reservation object as well. This fixes another OOM problem.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo_util.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 895d77d799e4..95f47d685921 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -517,9 +517,11 @@ static int ttm_buffer_object_transfer(struct 
ttm_buffer_object *bo,
kref_init(&fbo->base.kref);
fbo->base.destroy = &ttm_transfered_destroy;
fbo->base.acc_size = 0;
-   fbo->base.resv = &fbo->base.ttm_resv;
-   reservation_object_init(fbo->base.resv);
-   ret = reservation_object_trylock(fbo->base.resv);
+   if (bo->resv == &bo->ttm_resv)
+   fbo->base.resv = &fbo->base.ttm_resv;
+
+   reservation_object_init(&fbo->base.ttm_resv);
+   ret = reservation_object_trylock(&fbo->base.ttm_resv);
WARN_ON(!ret);
 
*new_obj = &fbo->base;
@@ -716,7 +718,7 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
if (ret)
return ret;
 
-   reservation_object_add_excl_fence(ghost_obj->resv, fence);
+   reservation_object_add_excl_fence(&ghost_obj->ttm_resv, fence);
 
/**
 * If we're not moving to fixed memory, the TTM object
@@ -729,7 +731,7 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
else
bo->ttm = NULL;
 
-   ttm_bo_unreserve(ghost_obj);
+   reservation_object_unlock(&ghost_obj->ttm_resv);
ttm_bo_put(ghost_obj);
}
 
@@ -772,7 +774,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
if (ret)
return ret;
 
-   reservation_object_add_excl_fence(ghost_obj->resv, fence);
+   reservation_object_add_excl_fence(&ghost_obj->ttm_resv, fence);
 
/**
 * If we're not moving to fixed memory, the TTM object
@@ -785,7 +787,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
else
bo->ttm = NULL;
 
-   ttm_bo_unreserve(ghost_obj);
+   reservation_object_unlock(&ghost_obj->ttm_resv);
ttm_bo_put(ghost_obj);
 
} else if (from->flags & TTM_MEMTYPE_FLAG_FIXED) {
@@ -841,7 +843,7 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
if (ret)
return ret;
 
-   ret = reservation_object_copy_fences(ghost->resv, bo->resv);
+   ret = reservation_object_copy_fences(&ghost->ttm_resv, bo->resv);
/* Last resort, wait for the BO to be idle when we are OOM */
if (ret)
ttm_bo_wait(bo, false, false);
@@ -850,7 +852,7 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
bo->mem.mem_type = TTM_PL_SYSTEM;
bo->ttm = NULL;
 
-   ttm_bo_unreserve(ghost);
+   reservation_object_unlock(&ghost->ttm_resv);
ttm_bo_put(ghost);
 
return 0;
-- 
2.17.1

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

[Intel-gfx] [PATCH 5/6] drm/amdgpu: add independent DMA-buf export v6

2019-06-17 Thread Christian König
The caching of SGT's is actually quite harmful and should probably removed
altogether when all drivers are audited.

Start by providing a separate DMA-buf export implementation in amdgpu.
This is also a prerequisite of unpinned DMA-buf handling.

v2: fix unintended recursion, remove debugging leftovers
v3: split out from unpinned DMA-buf work
v4: rebase on top of new no_sgt_cache flag
v5: fix some warnings by including amdgpu_dma_buf.h
v6: fix locking for non amdgpu exports

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 210 +---
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h |   1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |   1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  |   5 +
 4 files changed, 139 insertions(+), 78 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 4711cf1b5bd2..30984773ae79 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -36,26 +36,11 @@
 #include "amdgpu.h"
 #include "amdgpu_display.h"
 #include "amdgpu_gem.h"
+#include "amdgpu_dma_buf.h"
 #include 
 #include 
 #include 
 
-/**
- * amdgpu_gem_prime_get_sg_table - &drm_driver.gem_prime_get_sg_table
- * implementation
- * @obj: GEM buffer object (BO)
- *
- * Returns:
- * A scatter/gather table for the pinned pages of the BO's memory.
- */
-struct sg_table *amdgpu_gem_prime_get_sg_table(struct drm_gem_object *obj)
-{
-   struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
-   int npages = bo->tbo.num_pages;
-
-   return drm_prime_pages_to_sg(bo->tbo.ttm->pages, npages);
-}
-
 /**
  * amdgpu_gem_prime_vmap - &dma_buf_ops.vmap implementation
  * @obj: GEM BO
@@ -181,92 +166,163 @@ __reservation_object_make_exclusive(struct 
reservation_object *obj)
 }
 
 /**
- * amdgpu_dma_buf_map_attach - &dma_buf_ops.attach implementation
- * @dma_buf: Shared DMA buffer
+ * amdgpu_dma_buf_attach - &dma_buf_ops.attach implementation
+ *
+ * @dmabuf: DMA-buf where we attach to
+ * @attach: attachment to add
+ *
+ * Add the attachment as user to the exported DMA-buf.
+ */
+static int amdgpu_dma_buf_attach(struct dma_buf *dmabuf,
+struct dma_buf_attachment *attach)
+{
+   struct drm_gem_object *obj = dmabuf->priv;
+   struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+   struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+   int r;
+
+   if (attach->dev->driver == adev->dev->driver)
+   return 0;
+
+   r = amdgpu_bo_reserve(bo, false);
+   if (unlikely(r != 0))
+   return r;
+
+   /*
+* We only create shared fences for internal use, but importers
+* of the dmabuf rely on exclusive fences for implicitly
+* tracking write hazards. As any of the current fences may
+* correspond to a write, we need to convert all existing
+* fences on the reservation object into a single exclusive
+* fence.
+*/
+   r = __reservation_object_make_exclusive(bo->tbo.resv);
+   if (r)
+   return r;
+
+   bo->prime_shared_count++;
+   amdgpu_bo_unreserve(bo);
+   return 0;
+}
+
+/**
+ * amdgpu_dma_buf_detach - &dma_buf_ops.detach implementation
+ *
+ * @dmabuf: DMA-buf where we remove the attachment from
+ * @attach: the attachment to remove
+ *
+ * Called when an attachment is removed from the DMA-buf.
+ */
+static void amdgpu_dma_buf_detach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attach)
+{
+   struct drm_gem_object *obj = dmabuf->priv;
+   struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+   struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+
+   if (attach->dev->driver != adev->dev->driver && bo->prime_shared_count)
+   bo->prime_shared_count--;
+}
+
+/**
+ * amdgpu_dma_buf_pin - &dma_buf_ops.pin implementation
+ *
+ * @attach: attachment to pin down
+ *
+ * Pin the BO which is backing the DMA-buf so that it can't move any more.
+ */
+static int amdgpu_dma_buf_pin(struct dma_buf_attachment *attach)
+{
+   struct drm_gem_object *obj = attach->dmabuf->priv;
+   struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+
+   /* pin buffer into GTT */
+   return amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT);
+}
+
+/**
+ * amdgpu_dma_buf_unpin - &dma_buf_ops.unpin implementation
+ *
+ * @attach: attachment to unpin
+ *
+ * Unpin a previously pinned BO to make it movable again.
+ */
+static void amdgpu_dma_buf_unpin(struct dma_buf_attachment *attach)
+{
+   struct drm_gem_object *obj = attach->dmabuf->priv;
+   struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+
+   amdgpu_bo_unpin(bo);
+}
+
+/**
+ * amdgpu_dma_buf_map_dma_buf - &dma_buf_ops.map_dma_buf implementation
  * @attach: DMA-buf attachment
+ * @dir: DMA direction
  *
  * Makes sure that the shared DMA buffer can be accessed by the target device.
  * For now, simply pi

[Intel-gfx] [PATCH 4/6] drm/amdgpu: use allowed_domains for exported DMA-bufs

2019-06-17 Thread Christian König
Avoid that we ping/pong the buffers when we stop to pin DMA-buf
exports by using the allowed domains for exported buffers.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 3e2da24cd17a..a59780654335 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -26,6 +26,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -412,7 +413,9 @@ static int amdgpu_cs_bo_validate(struct amdgpu_cs_parser *p,
/* Don't move this buffer if we have depleted our allowance
 * to move it. Don't move anything if the threshold is zero.
 */
-   if (p->bytes_moved < p->bytes_moved_threshold) {
+   if (p->bytes_moved < p->bytes_moved_threshold &&
+   (!bo->gem_base.dma_buf ||
+   list_empty(&bo->gem_base.dma_buf->attachments))) {
if (!amdgpu_gmc_vram_full_visible(&adev->gmc) &&
(bo->flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED)) {
/* And don't move a CPU_ACCESS_REQUIRED BO to limited
-- 
2.17.1

___
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/ehl: Add power wells support for Elkhart Lake

2019-06-17 Thread Patchwork
== Series Details ==

Series: drm/i915/ehl: Add power wells support for Elkhart Lake
URL   : https://patchwork.freedesktop.org/series/62156/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6279_full -> Patchwork_13300_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_eio@in-flight-internal-10ms:
- shard-apl:  [PASS][1] -> [DMESG-WARN][2] ([fdo#110913 ])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6279/shard-apl4/igt@gem_...@in-flight-internal-10ms.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13300/shard-apl2/igt@gem_...@in-flight-internal-10ms.html

  * igt@gem_persistent_relocs@forked-thrash-inactive:
- shard-glk:  [PASS][3] -> [INCOMPLETE][4] ([fdo#103359] / 
[k.org#198133])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6279/shard-glk8/igt@gem_persistent_rel...@forked-thrash-inactive.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13300/shard-glk9/igt@gem_persistent_rel...@forked-thrash-inactive.html

  * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy:
- shard-kbl:  [PASS][5] -> [DMESG-WARN][6] ([fdo#110913 ])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6279/shard-kbl2/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13300/shard-kbl1/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html
- shard-glk:  [PASS][7] -> [DMESG-WARN][8] ([fdo#110913 ])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6279/shard-glk5/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13300/shard-glk3/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html

  * igt@i915_pm_backlight@fade_with_suspend:
- shard-skl:  [PASS][9] -> [INCOMPLETE][10] ([fdo#104108])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6279/shard-skl3/igt@i915_pm_backlight@fade_with_suspend.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13300/shard-skl6/igt@i915_pm_backlight@fade_with_suspend.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-apl:  [PASS][11] -> [DMESG-WARN][12] ([fdo#108566])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6279/shard-apl8/igt@kms_cursor_...@pipe-c-cursor-suspend.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13300/shard-apl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html

  * igt@kms_flip@plain-flip-fb-recreate-interruptible:
- shard-skl:  [PASS][13] -> [FAIL][14] ([fdo#100368])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6279/shard-skl9/igt@kms_f...@plain-flip-fb-recreate-interruptible.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13300/shard-skl6/igt@kms_f...@plain-flip-fb-recreate-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt:
- shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +5 similar 
issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6279/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13300/shard-iclb4/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
- shard-iclb: [PASS][17] -> [INCOMPLETE][18] ([fdo#107713] / 
[fdo#110042])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6279/shard-iclb7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13300/shard-iclb3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-kbl:  [PASS][19] -> [DMESG-WARN][20] ([fdo#108566]) +2 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6279/shard-kbl3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13300/shard-kbl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
- shard-skl:  [PASS][21] -> [FAIL][22] ([fdo#108145])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6279/shard-skl3/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13300/shard-skl6/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html

  * igt@kms_plane_lowres@pipe-a-tiling-x:
- shard-iclb: [PASS][23] -> [FAIL][24] ([fdo#103166])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM

[Intel-gfx] [PATCH 6/6] drm/amdgpu: add independent DMA-buf import v6

2019-06-17 Thread Christian König
Instead of relying on the DRM functions just implement our own import
functions. This prepares support for taking care of unpinned DMA-buf.

v2: enable for all exporters, not just amdgpu, fix invalidation
handling, lock reservation object while setting callback
v3: change to new dma_buf attach interface
v4: split out from unpinned DMA-buf work
v5: rebased and cleanup on new DMA-buf interface
v6: squash with invalidation callback change,
stop using _(map|unmap)_locked

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 65 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h |  4 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  |  6 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 32 --
 5 files changed, 83 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 30984773ae79..1a81eb1ed9a7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -426,31 +426,28 @@ struct dma_buf *amdgpu_gem_prime_export(struct drm_device 
*dev,
 }
 
 /**
- * amdgpu_gem_prime_import_sg_table - &drm_driver.gem_prime_import_sg_table
- * implementation
+ * amdgpu_dma_buf_create_obj - create BO for DMA-buf import
+ *
  * @dev: DRM device
- * @attach: DMA-buf attachment
- * @sg: Scatter/gather table
+ * @dma_buf: DMA-buf
  *
- * Imports shared DMA buffer memory exported by another device.
+ * Creates an empty SG BO for DMA-buf import.
  *
  * Returns:
  * A new GEM BO of the given DRM device, representing the memory
  * described by the given DMA-buf attachment and scatter/gather table.
  */
-struct drm_gem_object *
-amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
-struct dma_buf_attachment *attach,
-struct sg_table *sg)
+static struct drm_gem_object *
+amdgpu_dma_buf_create_obj(struct drm_device *dev, struct dma_buf *dma_buf)
 {
-   struct reservation_object *resv = attach->dmabuf->resv;
+   struct reservation_object *resv = dma_buf->resv;
struct amdgpu_device *adev = dev->dev_private;
struct amdgpu_bo *bo;
struct amdgpu_bo_param bp;
int ret;
 
memset(&bp, 0, sizeof(bp));
-   bp.size = attach->dmabuf->size;
+   bp.size = dma_buf->size;
bp.byte_align = PAGE_SIZE;
bp.domain = AMDGPU_GEM_DOMAIN_CPU;
bp.flags = 0;
@@ -461,11 +458,9 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
if (ret)
goto error;
 
-   bo->tbo.sg = sg;
-   bo->tbo.ttm->sg = sg;
bo->allowed_domains = AMDGPU_GEM_DOMAIN_GTT;
bo->preferred_domains = AMDGPU_GEM_DOMAIN_GTT;
-   if (attach->dmabuf->ops != &amdgpu_dmabuf_ops)
+   if (dma_buf->ops != &amdgpu_dmabuf_ops)
bo->prime_shared_count = 1;
 
ww_mutex_unlock(&resv->lock);
@@ -476,6 +471,32 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
return ERR_PTR(ret);
 }
 
+/**
+ * amdgpu_gem_prime_invalidate_mappings - &attach.invalidate implementation
+ *
+ * @attach: the DMA-buf attachment
+ *
+ * Invalidate the DMA-buf attachment, making sure that the we re-create the
+ * mapping before the next use.
+ */
+static void
+amdgpu_gem_prime_invalidate_mappings(struct dma_buf_attachment *attach)
+{
+   struct ttm_operation_ctx ctx = { false, false };
+   struct drm_gem_object *obj = attach->importer_priv;
+   struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+   struct ttm_placement placement = {};
+   int r;
+
+   r = ttm_bo_validate(&bo->tbo, &placement, &ctx);
+   if (r)
+   DRM_ERROR("Failed to invalidate DMA-buf import (%d))\n", r);
+}
+
+static const struct dma_buf_attach_ops amdgpu_dma_buf_attach_ops = {
+   .invalidate = amdgpu_gem_prime_invalidate_mappings
+};
+
 /**
  * amdgpu_gem_prime_import - &drm_driver.gem_prime_import implementation
  * @dev: DRM device
@@ -490,6 +511,7 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
 struct drm_gem_object *amdgpu_gem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf)
 {
+   struct dma_buf_attachment *attach;
struct drm_gem_object *obj;
 
if (dma_buf->ops == &amdgpu_dmabuf_ops) {
@@ -504,5 +526,18 @@ struct drm_gem_object *amdgpu_gem_prime_import(struct 
drm_device *dev,
}
}
 
-   return drm_gem_prime_import(dev, dma_buf);
+   obj = amdgpu_dma_buf_create_obj(dev, dma_buf);
+   if (IS_ERR(obj))
+   return obj;
+
+   attach = dma_buf_dynamic_attach(dma_buf, dev->dev,
+   &amdgpu_dma_buf_attach_ops, obj);
+   if (IS_ERR(attach)) {
+   drm_gem_object_put(obj);
+   return ERR_CAST(attach);
+   }
+
+   get_dma_buf(dma_buf);
+   

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/ehl: Introduce Mule Creek Canyon PCH (rev3)

2019-06-17 Thread Patchwork
== Series Details ==

Series: drm/i915/ehl: Introduce Mule Creek Canyon PCH (rev3)
URL   : https://patchwork.freedesktop.org/series/61137/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6279_full -> Patchwork_13299_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_13299_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_13299_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_13299_full:

### IGT changes ###

 Possible regressions 

  * igt@runner@aborted:
- shard-kbl:  NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13299/shard-kbl1/igt@run...@aborted.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_persistent_relocs@forked-faulting-reloc-thrashing:
- shard-apl:  [PASS][2] -> [DMESG-WARN][3] ([fdo#110913 ]) +1 
similar issue
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6279/shard-apl2/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13299/shard-apl3/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html
- shard-glk:  [PASS][4] -> [DMESG-WARN][5] ([fdo#110913 ])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6279/shard-glk5/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13299/shard-glk4/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html

  * igt@gem_persistent_relocs@forked-interruptible-thrashing:
- shard-snb:  [PASS][6] -> [DMESG-WARN][7] ([fdo#110789] / 
[fdo#110913 ])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6279/shard-snb6/igt@gem_persistent_rel...@forked-interruptible-thrashing.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13299/shard-snb6/igt@gem_persistent_rel...@forked-interruptible-thrashing.html

  * igt@gem_userptr_blits@map-fixed-invalidate-busy-gup:
- shard-snb:  [PASS][8] -> [DMESG-WARN][9] ([fdo#110913 ])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6279/shard-snb1/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13299/shard-snb4/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html

  * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy:
- shard-kbl:  [PASS][10] -> [DMESG-WARN][11] ([fdo#110913 ])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6279/shard-kbl2/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13299/shard-kbl2/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html

  * igt@i915_selftest@live_hangcheck:
- shard-kbl:  [PASS][12] -> [INCOMPLETE][13] ([fdo#103665] / 
[fdo#108744])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6279/shard-kbl1/igt@i915_selftest@live_hangcheck.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13299/shard-kbl1/igt@i915_selftest@live_hangcheck.html

  * igt@i915_suspend@debugfs-reader:
- shard-apl:  [PASS][14] -> [DMESG-WARN][15] ([fdo#108566]) +1 
similar issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6279/shard-apl4/igt@i915_susp...@debugfs-reader.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13299/shard-apl2/igt@i915_susp...@debugfs-reader.html

  * igt@i915_suspend@fence-restore-untiled:
- shard-kbl:  [PASS][16] -> [DMESG-WARN][17] ([fdo#108566]) +1 
similar issue
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6279/shard-kbl3/igt@i915_susp...@fence-restore-untiled.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13299/shard-kbl2/igt@i915_susp...@fence-restore-untiled.html

  * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
- shard-glk:  [PASS][18] -> [FAIL][19] ([fdo#105363])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6279/shard-glk6/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13299/shard-glk9/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html

  * igt@kms_flip@flip-vs-suspend:
- shard-skl:  [PASS][20] -> [INCOMPLETE][21] ([fdo#109507])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6279/shard-skl6/igt@kms_f...@flip-vs-suspend.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13299/shard-skl6/igt@kms_f...@flip-vs-suspend.html
- shard-glk:   

[Intel-gfx] [PATCH v3 4/7] lib/hexdump.c: Replace ascii bool in hex_dump_to_buffer with flags

2019-06-17 Thread Alastair D'Silva
From: Alastair D'Silva 

In order to support additional features in hex_dump_to_buffer, replace
the ascii bool parameter with flags.

Signed-off-by: Alastair D'Silva 
---
 drivers/gpu/drm/i915/intel_engine_cs.c|  2 +-
 drivers/isdn/hardware/mISDN/mISDNisar.c   |  6 --
 drivers/mailbox/mailbox-test.c|  2 +-
 drivers/net/ethernet/amd/xgbe/xgbe-drv.c  |  2 +-
 drivers/net/ethernet/synopsys/dwc-xlgmac-common.c |  2 +-
 drivers/net/wireless/ath/ath10k/debug.c   |  3 ++-
 drivers/net/wireless/intel/iwlegacy/3945-mac.c|  2 +-
 drivers/platform/chrome/wilco_ec/debugfs.c|  2 +-
 drivers/scsi/scsi_logging.c   |  8 +++-
 drivers/staging/fbtft/fbtft-core.c|  2 +-
 fs/seq_file.c |  3 ++-
 include/linux/printk.h|  8 
 lib/hexdump.c | 15 ---
 lib/test_hexdump.c|  5 +++--
 14 files changed, 33 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index eea9bec04f1b..5df5fffdb848 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1340,7 +1340,7 @@ static void hexdump(struct drm_printer *m, const void 
*buf, size_t len)
WARN_ON_ONCE(hex_dump_to_buffer(buf + pos, len - pos,
rowsize, sizeof(u32),
line, sizeof(line),
-   false) >= sizeof(line));
+   0) >= sizeof(line));
drm_printf(m, "[%04zx] %s\n", pos, line);
 
prev = buf + pos;
diff --git a/drivers/isdn/hardware/mISDN/mISDNisar.c 
b/drivers/isdn/hardware/mISDN/mISDNisar.c
index fd5c52f37802..ccc0ee9d894f 100644
--- a/drivers/isdn/hardware/mISDN/mISDNisar.c
+++ b/drivers/isdn/hardware/mISDN/mISDNisar.c
@@ -71,7 +71,8 @@ send_mbox(struct isar_hw *isar, u8 his, u8 creg, u8 len, u8 
*msg)
 
while (l < (int)len) {
hex_dump_to_buffer(msg + l, len - l, 32, 1,
-  isar->log, 256, 1);
+  isar->log, 256,
+  HEXDUMP_ASCII);
pr_debug("%s: %s %02x: %s\n", isar->name,
 __func__, l, isar->log);
l += 32;
@@ -100,7 +101,8 @@ rcv_mbox(struct isar_hw *isar, u8 *msg)
 
while (l < (int)isar->clsb) {
hex_dump_to_buffer(msg + l, isar->clsb - l, 32,
-  1, isar->log, 256, 1);
+  1, isar->log, 256,
+  HEXDUMP_ASCII);
pr_debug("%s: %s %02x: %s\n", isar->name,
 __func__, l, isar->log);
l += 32;
diff --git a/drivers/mailbox/mailbox-test.c b/drivers/mailbox/mailbox-test.c
index 4555d678fadd..23c3fbafdcb2 100644
--- a/drivers/mailbox/mailbox-test.c
+++ b/drivers/mailbox/mailbox-test.c
@@ -209,7 +209,7 @@ static ssize_t mbox_test_message_read(struct file *filp, 
char __user *userbuf,
hex_dump_to_buffer(ptr,
   MBOX_BYTES_PER_LINE,
   MBOX_BYTES_PER_LINE, 1, touser + l,
-  MBOX_HEXDUMP_LINE_LEN, true);
+  MBOX_HEXDUMP_LINE_LEN, HEXDUMP_ASCII);
 
ptr += MBOX_BYTES_PER_LINE;
l += MBOX_HEXDUMP_LINE_LEN;
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c 
b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
index 3dd0cecddba8..1e26410cf6c2 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
@@ -2992,7 +2992,7 @@ void xgbe_print_pkt(struct net_device *netdev, struct 
sk_buff *skb, bool tx_rx)
unsigned int len = min(skb->len - i, 32U);
 
hex_dump_to_buffer(&skb->data[i], len, 32, 1,
-  buffer, sizeof(buffer), false);
+  buffer, sizeof(buffer), 0);
netdev_dbg(netdev, "  %#06x: %s\n", i, buffer);
}
 
diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c 
b/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
index eb1c6b03c329..b80adfa1f890 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
@@ -349,7 +349,7 @@ void xlgmac_print_pkt(struct net_device *netdev,
unsigned int len = min(skb->len - i

[Intel-gfx] [PATCH v3 0/7] Hexdump Enhancements

2019-06-17 Thread Alastair D'Silva
From: Alastair D'Silva 

Apologies for the large CC list, it's a heads up for those responsible
for subsystems where a prototype change in generic code causes a change
in those subsystems.

This series enhances hexdump.

These improve the readability of the dumped data in certain situations
(eg. wide terminals are available, many lines of empty bytes exist, etc).

The default behaviour of hexdump is unchanged, however, the prototype
for hex_dump_to_buffer() has changed, and print_hex_dump() has been
renamed to print_hex_dump_ext(), with a wrapper replacing it for
compatibility with existing code, which would have been too invasive to
change.

Hexdump selftests have be run & confirmed passed.

Changelog:
V3:
 - Fix inline documention
 - use BIT macros
 - use u32 rather than u64 for flags
V2:
 - Fix failing selftests
 - Fix precedence bug in 'Replace ascii bool in hex_dump_to_buffer...'
 - Remove hardcoded new lengths & instead relax the checks in
   hex_dump_to_buffer, allocating the buffer from the heap instead of the
   stack.
 - Replace the skipping of lines of 0x00/0xff with skipping lines of
   repeated characters, announcing what has been skipped.
 - Add spaces as an optional N-group separator
 - Allow byte ordering to be maintained when HEXDUMP_RETAIN_BYTE_ORDERING
   is set.
 - Updated selftests to cover 'Relax rowsize checks' &
   'Optionally retain byte ordering'

Alastair D'Silva (7):
  lib/hexdump.c: Fix selftests
  lib/hexdump.c: Relax rowsize checks in hex_dump_to_buffer
  lib/hexdump.c: Optionally suppress lines of repeated bytes
  lib/hexdump.c: Replace ascii bool in hex_dump_to_buffer with flags
  lib/hexdump.c: Allow multiple groups to be separated by lines '|'
  lib/hexdump.c: Allow multiple groups to be separated by spaces
  lib/hexdump.c: Optionally retain byte ordering

 drivers/gpu/drm/i915/intel_engine_cs.c|   2 +-
 drivers/isdn/hardware/mISDN/mISDNisar.c   |   6 +-
 drivers/mailbox/mailbox-test.c|   2 +-
 drivers/net/ethernet/amd/xgbe/xgbe-drv.c  |   2 +-
 .../net/ethernet/synopsys/dwc-xlgmac-common.c |   2 +-
 drivers/net/wireless/ath/ath10k/debug.c   |   3 +-
 .../net/wireless/intel/iwlegacy/3945-mac.c|   2 +-
 drivers/platform/chrome/wilco_ec/debugfs.c|   2 +-
 drivers/scsi/scsi_logging.c   |   8 +-
 drivers/staging/fbtft/fbtft-core.c|   2 +-
 fs/seq_file.c |   3 +-
 include/linux/printk.h|  34 ++-
 lib/hexdump.c | 260 +++---
 lib/test_hexdump.c| 146 +++---
 14 files changed, 372 insertions(+), 102 deletions(-)

-- 
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/7] lib/hexdump.c: Optionally suppress lines of repeated bytes

2019-06-17 Thread Alastair D'Silva
From: Alastair D'Silva 

Some buffers may only be partially filled with useful data, while the rest
is padded (typically with 0x00 or 0xff).

This patch introduces a flag to allow the supression of lines of repeated
bytes, which are replaced with '** Skipped %u bytes of value 0x%x **'

An inline wrapper function is provided for backwards compatibility with
existing code, which maintains the original behaviour.

Signed-off-by: Alastair D'Silva 
---
 include/linux/printk.h | 25 +---
 lib/hexdump.c  | 91 --
 2 files changed, 99 insertions(+), 17 deletions(-)

diff --git a/include/linux/printk.h b/include/linux/printk.h
index cefd374c47b1..d7754799cfe0 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -481,13 +481,18 @@ enum {
DUMP_PREFIX_ADDRESS,
DUMP_PREFIX_OFFSET
 };
+
 extern int hex_dump_to_buffer(const void *buf, size_t len, int rowsize,
  int groupsize, char *linebuf, size_t linebuflen,
  bool ascii);
+
+#define HEXDUMP_ASCII  BIT(0)
+#define HEXDUMP_SUPPRESS_REPEATED  BIT(1)
+
 #ifdef CONFIG_PRINTK
-extern void print_hex_dump(const char *level, const char *prefix_str,
+extern void print_hex_dump_ext(const char *level, const char *prefix_str,
   int prefix_type, int rowsize, int groupsize,
-  const void *buf, size_t len, bool ascii);
+  const void *buf, size_t len, u32 flags);
 #if defined(CONFIG_DYNAMIC_DEBUG)
 #define print_hex_dump_bytes(prefix_str, prefix_type, buf, len)\
dynamic_hex_dump(prefix_str, prefix_type, 16, 1, buf, len, true)
@@ -496,18 +501,28 @@ extern void print_hex_dump_bytes(const char *prefix_str, 
int prefix_type,
 const void *buf, size_t len);
 #endif /* defined(CONFIG_DYNAMIC_DEBUG) */
 #else
-static inline void print_hex_dump(const char *level, const char *prefix_str,
+static inline void print_hex_dump_ext(const char *level, const char 
*prefix_str,
  int prefix_type, int rowsize, int groupsize,
- const void *buf, size_t len, bool ascii)
+ const void *buf, size_t len, u32 flags)
 {
 }
 static inline void print_hex_dump_bytes(const char *prefix_str, int 
prefix_type,
const void *buf, size_t len)
 {
 }
-
 #endif
 
+static __always_inline void print_hex_dump(const char *level,
+  const char *prefix_str,
+  int prefix_type, int rowsize,
+  int groupsize, const void *buf,
+  size_t len, bool ascii)
+{
+   print_hex_dump_ext(level, prefix_str, prefix_type, rowsize, groupsize,
+   buf, len, ascii ? HEXDUMP_ASCII : 0);
+}
+
+
 #if defined(CONFIG_DYNAMIC_DEBUG)
 #define print_hex_dump_debug(prefix_str, prefix_type, rowsize, \
 groupsize, buf, len, ascii)\
diff --git a/lib/hexdump.c b/lib/hexdump.c
index 3943507bc0e9..b781f84e 100644
--- a/lib/hexdump.c
+++ b/lib/hexdump.c
@@ -212,8 +212,44 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
 EXPORT_SYMBOL(hex_dump_to_buffer);
 
 #ifdef CONFIG_PRINTK
+
+/**
+ * buf_is_all - Check if a buffer contains only a single byte value
+ * @buf: pointer to the buffer
+ * @len: the size of the buffer in bytes
+ * @val: outputs the value if if the bytes are identical
+ */
+static bool buf_is_all(const u8 *buf, size_t len, u8 *val_out)
+{
+   size_t i;
+   u8 val;
+
+   if (len <= 1)
+   return false;
+
+   val = buf[0];
+
+   for (i = 1; i < len; i++) {
+   if (buf[i] != val)
+   return false;
+   }
+
+   *val_out = val;
+   return true;
+}
+
+static void announce_skipped(const char *level, const char *prefix_str,
+  u8 val, size_t count)
+{
+   if (count == 0)
+   return;
+
+   printk("%s%s ** Skipped %lu bytes of value 0x%x **\n",
+  level, prefix_str, count, val);
+}
+
 /**
- * print_hex_dump - print a text hex dump to syslog for a binary blob of data
+ * print_hex_dump_ext - dump a binary blob of data to syslog in hexadecimal
  * @level: kernel log level (e.g. KERN_DEBUG)
  * @prefix_str: string to prefix each line with;
  *  caller supplies trailing spaces for alignment if desired
@@ -224,6 +260,10 @@ EXPORT_SYMBOL(hex_dump_to_buffer);
  * @buf: data blob to dump
  * @len: number of bytes in the @buf
  * @ascii: include ASCII after the hex output
+ * @flags: A bitwise OR of the following flags:
+ * HEXDUMP_ASCII:  include ASCII after the hex output
+ * HEXDUMP_SUPPRESS_REPEATED:  suppress repeated lines of identical
+

[Intel-gfx] [PATCH v3 2/7] lib/hexdump.c: Relax rowsize checks in hex_dump_to_buffer

2019-06-17 Thread Alastair D'Silva
From: Alastair D'Silva 

This patch removes the hardcoded row limits and allows for
other lengths. These lengths must still be a multiple of
groupsize.

This allows structs that are not 16/32 bytes to display on
a single line.

This patch also expands the self-tests to test row sizes
up to 64 bytes (though they can now be arbitrarily long).

Signed-off-by: Alastair D'Silva 
---
 lib/hexdump.c  | 48 --
 lib/test_hexdump.c | 52 ++
 2 files changed, 75 insertions(+), 25 deletions(-)

diff --git a/lib/hexdump.c b/lib/hexdump.c
index 81b70ed37209..3943507bc0e9 100644
--- a/lib/hexdump.c
+++ b/lib/hexdump.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 const char hex_asc[] = "0123456789abcdef";
@@ -80,14 +81,15 @@ EXPORT_SYMBOL(bin2hex);
  * hex_dump_to_buffer - convert a blob of data to "hex ASCII" in memory
  * @buf: data blob to dump
  * @len: number of bytes in the @buf
- * @rowsize: number of bytes to print per line; must be 16 or 32
+ * @rowsize: number of bytes to print per line; must be a multiple of groupsize
  * @groupsize: number of bytes to print at a time (1, 2, 4, 8; default = 1)
  * @linebuf: where to put the converted data
  * @linebuflen: total size of @linebuf, including space for terminating NUL
  * @ascii: include ASCII after the hex output
  *
- * hex_dump_to_buffer() works on one "line" of output at a time, i.e.,
- * 16 or 32 bytes of input data converted to hex + ASCII output.
+ * hex_dump_to_buffer() works on one "line" of output at a time, converting
+ *  bytes of input to hexadecimal (and optionally printable ASCII)
+ * until  bytes have been emitted.
  *
  * Given a buffer of u8 data, hex_dump_to_buffer() converts the input data
  * to a hex + ASCII dump at the supplied memory location.
@@ -116,16 +118,17 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
int ascii_column;
int ret;
 
-   if (rowsize != 16 && rowsize != 32)
-   rowsize = 16;
-
-   if (len > rowsize)  /* limit to one line at a time */
-   len = rowsize;
if (!is_power_of_2(groupsize) || groupsize > 8)
groupsize = 1;
if ((len % groupsize) != 0) /* no mixed size output */
groupsize = 1;
 
+   if (rowsize % groupsize)
+   rowsize -= rowsize % groupsize;
+
+   if (len > rowsize)  /* limit to one line at a time */
+   len = rowsize;
+
ngroups = len / groupsize;
ascii_column = rowsize * 2 + rowsize / groupsize + 1;
 
@@ -216,7 +219,7 @@ EXPORT_SYMBOL(hex_dump_to_buffer);
  *  caller supplies trailing spaces for alignment if desired
  * @prefix_type: controls whether prefix of an offset, address, or none
  *  is printed (%DUMP_PREFIX_OFFSET, %DUMP_PREFIX_ADDRESS, %DUMP_PREFIX_NONE)
- * @rowsize: number of bytes to print per line; must be 16 or 32
+ * @rowsize: number of bytes to print per line; must be a multiple of groupsize
  * @groupsize: number of bytes to print at a time (1, 2, 4, 8; default = 1)
  * @buf: data blob to dump
  * @len: number of bytes in the @buf
@@ -226,10 +229,9 @@ EXPORT_SYMBOL(hex_dump_to_buffer);
  * to the kernel log at the specified kernel log level, with an optional
  * leading prefix.
  *
- * print_hex_dump() works on one "line" of output at a time, i.e.,
- * 16 or 32 bytes of input data converted to hex + ASCII output.
  * print_hex_dump() iterates over the entire input @buf, breaking it into
- * "line size" chunks to format and print.
+ * lines of rowsize/groupsize groups of input data converted to hex +
+ * (optionally) ASCII output.
  *
  * E.g.:
  *   print_hex_dump(KERN_DEBUG, "raw data: ", DUMP_PREFIX_ADDRESS,
@@ -246,17 +248,29 @@ void print_hex_dump(const char *level, const char 
*prefix_str, int prefix_type,
 {
const u8 *ptr = buf;
int i, linelen, remaining = len;
-   unsigned char linebuf[32 * 3 + 2 + 32 + 1];
+   unsigned char *linebuf;
+   unsigned int linebuf_len;
 
-   if (rowsize != 16 && rowsize != 32)
-   rowsize = 16;
+   if (rowsize % groupsize)
+   rowsize -= rowsize % groupsize;
+
+   /* Worst case line length:
+* 2 hex chars + space per byte in, 2 spaces, 1 char per byte in, NULL
+*/
+   linebuf_len = rowsize * 3 + 2 + rowsize + 1;
+   linebuf = kzalloc(linebuf_len, GFP_KERNEL);
+   if (!linebuf) {
+   printk("%s%shexdump: Could not alloc %u bytes for buffer\n",
+   level, prefix_str, linebuf_len);
+   return;
+   }
 
for (i = 0; i < len; i += rowsize) {
linelen = min(remaining, rowsize);
remaining -= rowsize;
 
hex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize,
-  linebuf, sizeof(linebuf), ascii);
+

[Intel-gfx] [PATCH v3 1/7] lib/hexdump.c: Fix selftests

2019-06-17 Thread Alastair D'Silva
From: Alastair D'Silva 

The overflow tests did not account for the situation where no
overflow occurs and len < rowsize.

This patch renames the cryptic variables and accounts for the
above case.

The selftests now pass.

Signed-off-by: Alastair D'Silva 
---
 lib/test_hexdump.c | 47 ++
 1 file changed, 27 insertions(+), 20 deletions(-)

diff --git a/lib/test_hexdump.c b/lib/test_hexdump.c
index 5144899d3c6b..d78ddd62ffd0 100644
--- a/lib/test_hexdump.c
+++ b/lib/test_hexdump.c
@@ -163,45 +163,52 @@ static void __init test_hexdump_overflow(size_t buflen, 
size_t len,
 {
char test[TEST_HEXDUMP_BUF_SIZE];
char buf[TEST_HEXDUMP_BUF_SIZE];
-   int rs = rowsize, gs = groupsize;
-   int ae, he, e, f, r;
-   bool a;
+   int ascii_len, hex_len, expected_len, fill_point, ngroups, rc;
+   bool match;
 
total_tests++;
 
memset(buf, FILL_CHAR, sizeof(buf));
 
-   r = hex_dump_to_buffer(data_b, len, rs, gs, buf, buflen, ascii);
+   rc = hex_dump_to_buffer(data_b, len, rowsize, groupsize, buf, buflen, 
ascii);
 
/*
 * Caller must provide the data length multiple of groupsize. The
 * calculations below are made with that assumption in mind.
 */
-   ae = rs * 2 /* hex */ + rs / gs /* spaces */ + 1 /* space */ + len /* 
ascii */;
-   he = (gs * 2 /* hex */ + 1 /* space */) * len / gs - 1 /* no trailing 
space */;
+   ngroups = rowsize / groupsize;
+   hex_len = (groupsize * 2 /* hex */ + 1 /* spaces */) * ngroups
+ - 1 /* no trailing space */;
+   ascii_len = hex_len + 2 /* space */ + len /* ascii */;
+
+   if (len < rowsize) {
+   ngroups = len / groupsize;
+   hex_len = (groupsize * 2 /* hex */ + 1 /* spaces */) * ngroups
+ - 1 /* no trailing space */;
+   }
 
-   if (ascii)
-   e = ae;
-   else
-   e = he;
+   expected_len = (ascii) ? ascii_len : hex_len;
 
-   f = min_t(int, e + 1, buflen);
+   fill_point = min_t(int, expected_len + 1, buflen);
if (buflen) {
-   test_hexdump_prepare_test(len, rs, gs, test, sizeof(test), 
ascii);
-   test[f - 1] = '\0';
+   test_hexdump_prepare_test(len, rowsize, groupsize, test,
+ sizeof(test), ascii);
+   test[fill_point - 1] = '\0';
}
-   memset(test + f, FILL_CHAR, sizeof(test) - f);
+   memset(test + fill_point, FILL_CHAR, sizeof(test) - fill_point);
 
-   a = r == e && !memcmp(test, buf, TEST_HEXDUMP_BUF_SIZE);
+   match = rc == expected_len && !memcmp(test, buf, TEST_HEXDUMP_BUF_SIZE);
 
buf[sizeof(buf) - 1] = '\0';
 
-   if (!a) {
-   pr_err("Len: %zu buflen: %zu strlen: %zu\n",
-   len, buflen, strnlen(buf, sizeof(buf)));
-   pr_err("Result: %d '%s'\n", r, buf);
-   pr_err("Expect: %d '%s'\n", e, test);
+   if (!match) {
+   pr_err("rowsize: %u groupsize: %u ascii: %d Len: %zu buflen: 
%zu strlen: %zu\n",
+   rowsize, groupsize, ascii, len, buflen,
+   strnlen(buf, sizeof(buf)));
+   pr_err("Result: %d '%-.*s'\n", rc, (int)buflen, buf);
+   pr_err("Expect: %d '%-.*s'\n", expected_len, (int)buflen, test);
failed_tests++;
+
}
 }
 
-- 
2.21.0

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

[Intel-gfx] [PATCH v3 7/7] lib/hexdump.c: Optionally retain byte ordering

2019-06-17 Thread Alastair D'Silva
From: Alastair D'Silva 

The behaviour of hexdump groups is to print the data out as if
it was a native-endian number.

This patch tweaks the documentation to make this clear, and also
adds the HEXDUMP_RETAIN_BYTE_ORDER flag to allow groups of
multiple bytes to be printed without affecting the ordering
of the printed bytes.

Signed-off-by: Alastair D'Silva 
---
 include/linux/printk.h |  1 +
 lib/hexdump.c  | 30 +
 lib/test_hexdump.c | 60 +-
 3 files changed, 68 insertions(+), 23 deletions(-)

diff --git a/include/linux/printk.h b/include/linux/printk.h
index 04416e788802..ffc94bedd737 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -490,6 +490,7 @@ enum {
 #define HEXDUMP_2_GRP_SPACES   BIT(5)
 #define HEXDUMP_4_GRP_SPACES   BIT(6)
 #define HEXDUMP_8_GRP_SPACES   BIT(7)
+#define HEXDUMP_RETAIN_BYTE_ORDER  BIT(8)
 
 extern int hex_dump_to_buffer(const void *buf, size_t len, int rowsize,
  int groupsize, char *linebuf, size_t linebuflen,
diff --git a/lib/hexdump.c b/lib/hexdump.c
index dc85ef0dbb0a..ce14abc7701f 100644
--- a/lib/hexdump.c
+++ b/lib/hexdump.c
@@ -127,7 +127,8 @@ static void separator_parameters(u64 flags, int groupsize, 
int *sep_chars,
  * @buf: data blob to dump
  * @len: number of bytes in the @buf
  * @rowsize: number of bytes to print per line; must be a multiple of groupsize
- * @groupsize: number of bytes to print at a time (1, 2, 4, 8; default = 1)
+ * @groupsize: number of bytes to convert to a native endian number and print:
+ *1, 2, 4, 8; default = 1
  * @linebuf: where to put the converted data
  * @linebuflen: total size of @linebuf, including space for terminating NUL
  * @flags: A bitwise OR of the following flags:
@@ -138,6 +139,9 @@ static void separator_parameters(u64 flags, int groupsize, 
int *sep_chars,
  * HEXDUMP_2_GRP_SPACES:   insert a ' ' after every 2 groups
  * HEXDUMP_4_GRP_SPACES:   insert a ' ' after every 4 groups
  * HEXDUMP_8_GRP_SPACES:   insert a ' ' after every 8 groups
+ * HEXDUMP_RETAIN_BYTE_ORDER:  Retain the byte ordering of groups
+ * instead of treating each group as a
+ * native-endian number
  *
  * hex_dump_to_buffer() works on one "line" of output at a time, converting
  *  bytes of input to hexadecimal (and optionally printable ASCII)
@@ -171,6 +175,7 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
int ret;
int sep_chars = 0;
char sep = 0;
+   bool big_endian = (flags & HEXDUMP_RETAIN_BYTE_ORDER) ? 1 : 0;
 
if (!is_power_of_2(groupsize) || groupsize > 8)
groupsize = 1;
@@ -202,10 +207,13 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
const u64 *ptr8 = buf;
 
for (j = 0; j < ngroups; j++) {
+   u64 val = big_endian ?
+   be64_to_cpu(get_unaligned(ptr8 + j)) :
+   get_unaligned(ptr8 + j);
ret = snprintf(linebuf + lx, linebuflen - lx,
   "%s%16.16llx",
   j ? group_separator(j, flags) : "",
-  get_unaligned(ptr8 + j));
+  val);
if (ret >= linebuflen - lx)
goto overflow1;
lx += ret;
@@ -214,10 +222,14 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
const u32 *ptr4 = buf;
 
for (j = 0; j < ngroups; j++) {
+   u32 val = big_endian ?
+   be32_to_cpu(get_unaligned(ptr4 + j)) :
+   get_unaligned(ptr4 + j);
+
ret = snprintf(linebuf + lx, linebuflen - lx,
   "%s%8.8x",
   j ? group_separator(j, flags) : "",
-  get_unaligned(ptr4 + j));
+  val);
if (ret >= linebuflen - lx)
goto overflow1;
lx += ret;
@@ -226,10 +238,14 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
const u16 *ptr2 = buf;
 
for (j = 0; j < ngroups; j++) {
+   u16 val = big_endian ?
+   be16_to_cpu(get_unaligned(ptr2 + j)) :
+   get_unaligned(ptr2 + j);
+
ret = snprintf(linebuf + lx, linebuflen - lx,
   "%s%4.4x",
   

[Intel-gfx] [PATCH v3 5/7] lib/hexdump.c: Allow multiple groups to be separated by lines '|'

2019-06-17 Thread Alastair D'Silva
From: Alastair D'Silva 

With the wider display format, it can become hard to identify how many
bytes into the line you are looking at.

The patch adds new flags to hex_dump_to_buffer() and print_hex_dump() to
print vertical lines to separate every N groups of bytes.

eg.
buf:: 454d414e 43415053|4e495f45 00584544  NAMESPAC|E_INDEX.
buf:0010:  0002|   |

Signed-off-by: Alastair D'Silva 
---
 include/linux/printk.h |  3 +++
 lib/hexdump.c  | 59 --
 2 files changed, 54 insertions(+), 8 deletions(-)

diff --git a/include/linux/printk.h b/include/linux/printk.h
index 97dd29a2bd77..c6b748f66a82 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -484,6 +484,9 @@ enum {
 
 #define HEXDUMP_ASCII  BIT(0)
 #define HEXDUMP_SUPPRESS_REPEATED  BIT(1)
+#define HEXDUMP_2_GRP_LINESBIT(2)
+#define HEXDUMP_4_GRP_LINESBIT(3)
+#define HEXDUMP_8_GRP_LINESBIT(4)
 
 extern int hex_dump_to_buffer(const void *buf, size_t len, int rowsize,
  int groupsize, char *linebuf, size_t linebuflen,
diff --git a/lib/hexdump.c b/lib/hexdump.c
index 08c6084d7daa..4da7d24826fb 100644
--- a/lib/hexdump.c
+++ b/lib/hexdump.c
@@ -77,6 +77,23 @@ char *bin2hex(char *dst, const void *src, size_t count)
 }
 EXPORT_SYMBOL(bin2hex);
 
+static const char *group_separator(int group, u64 flags)
+{
+   if (group == 0)
+   return " ";
+
+   if ((flags & HEXDUMP_8_GRP_LINES) && !((group) % 8))
+   return "|";
+
+   if ((flags & HEXDUMP_4_GRP_LINES) && !((group) % 4))
+   return "|";
+
+   if ((flags & HEXDUMP_2_GRP_LINES) && !((group) % 2))
+   return "|";
+
+   return " ";
+}
+
 /**
  * hex_dump_to_buffer - convert a blob of data to "hex ASCII" in memory
  * @buf: data blob to dump
@@ -87,6 +104,9 @@ EXPORT_SYMBOL(bin2hex);
  * @linebuflen: total size of @linebuf, including space for terminating NUL
  * @flags: A bitwise OR of the following flags:
  * HEXDUMP_ASCII:  include ASCII after the hex output
+ * HEXDUMP_2_GRP_LINES:insert a '|' after every 2 groups
+ * HEXDUMP_4_GRP_LINES:insert a '|' after every 4 groups
+ * HEXDUMP_8_GRP_LINES:insert a '|' after every 8 groups
  *
  * hex_dump_to_buffer() works on one "line" of output at a time, converting
  *  bytes of input to hexadecimal (and optionally printable ASCII)
@@ -118,6 +138,7 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
int j, lx = 0;
int ascii_column;
int ret;
+   int line_chars = 0;
 
if (!is_power_of_2(groupsize) || groupsize > 8)
groupsize = 1;
@@ -144,7 +165,8 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
 
for (j = 0; j < ngroups; j++) {
ret = snprintf(linebuf + lx, linebuflen - lx,
-  "%s%16.16llx", j ? " " : "",
+  "%s%16.16llx",
+  j ? group_separator(j, flags) : "",
   get_unaligned(ptr8 + j));
if (ret >= linebuflen - lx)
goto overflow1;
@@ -155,7 +177,8 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
 
for (j = 0; j < ngroups; j++) {
ret = snprintf(linebuf + lx, linebuflen - lx,
-  "%s%8.8x", j ? " " : "",
+  "%s%8.8x",
+  j ? group_separator(j, flags) : "",
   get_unaligned(ptr4 + j));
if (ret >= linebuflen - lx)
goto overflow1;
@@ -166,7 +189,8 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
 
for (j = 0; j < ngroups; j++) {
ret = snprintf(linebuf + lx, linebuflen - lx,
-  "%s%4.4x", j ? " " : "",
+  "%s%4.4x",
+  j ? group_separator(j, flags) : "",
   get_unaligned(ptr2 + j));
if (ret >= linebuflen - lx)
goto overflow1;
@@ -196,11 +220,26 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
goto overflow2;
linebuf[lx++] = ' ';
}
+
+   if (flags & HEXDUMP_2_GRP_LINES)
+   line_chars = groupsize * 2;
+   if (flags & HEXDUMP_4_GRP_LINES)
+   line_chars = groupsize * 4;
+   if (flags & HEXDUMP_8_GRP_LINES)
+   line_chars = group

[Intel-gfx] [PATCH v3 6/7] lib/hexdump.c: Allow multiple groups to be separated by spaces

2019-06-17 Thread Alastair D'Silva
From: Alastair D'Silva 

Similar to the previous patch, this patch separates groups by 2 spaces for
the hex fields, and 1 space for the ASCII field.

eg.
buf:: 454d414e 43415053  4e495f45 00584544  NAMESPAC E_INDEX.
buf:0010:  0002      

Signed-off-by: Alastair D'Silva 
---
 include/linux/printk.h |  3 ++
 lib/hexdump.c  | 65 +++---
 2 files changed, 52 insertions(+), 16 deletions(-)

diff --git a/include/linux/printk.h b/include/linux/printk.h
index c6b748f66a82..04416e788802 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -487,6 +487,9 @@ enum {
 #define HEXDUMP_2_GRP_LINESBIT(2)
 #define HEXDUMP_4_GRP_LINESBIT(3)
 #define HEXDUMP_8_GRP_LINESBIT(4)
+#define HEXDUMP_2_GRP_SPACES   BIT(5)
+#define HEXDUMP_4_GRP_SPACES   BIT(6)
+#define HEXDUMP_8_GRP_SPACES   BIT(7)
 
 extern int hex_dump_to_buffer(const void *buf, size_t len, int rowsize,
  int groupsize, char *linebuf, size_t linebuflen,
diff --git a/lib/hexdump.c b/lib/hexdump.c
index 4da7d24826fb..dc85ef0dbb0a 100644
--- a/lib/hexdump.c
+++ b/lib/hexdump.c
@@ -91,9 +91,37 @@ static const char *group_separator(int group, u64 flags)
if ((flags & HEXDUMP_2_GRP_LINES) && !((group) % 2))
return "|";
 
+   if ((flags & HEXDUMP_8_GRP_SPACES) && !((group) % 8))
+   return "  ";
+
+   if ((flags & HEXDUMP_4_GRP_SPACES) && !((group) % 4))
+   return "  ";
+
+   if ((flags & HEXDUMP_2_GRP_SPACES) && !((group) % 2))
+   return "  ";
+
return " ";
 }
 
+static void separator_parameters(u64 flags, int groupsize, int *sep_chars,
+char *sep)
+{
+   if (flags & (HEXDUMP_2_GRP_LINES | HEXDUMP_2_GRP_SPACES))
+   *sep_chars = groupsize * 2;
+   if (flags & (HEXDUMP_4_GRP_LINES | HEXDUMP_4_GRP_SPACES))
+   *sep_chars = groupsize * 4;
+   if (flags & (HEXDUMP_8_GRP_LINES | HEXDUMP_8_GRP_SPACES))
+   *sep_chars = groupsize * 8;
+
+   if (flags & (HEXDUMP_2_GRP_LINES | HEXDUMP_4_GRP_LINES |
+  HEXDUMP_8_GRP_LINES))
+   *sep = '|';
+
+   if (flags & (HEXDUMP_2_GRP_SPACES | HEXDUMP_4_GRP_SPACES |
+  HEXDUMP_8_GRP_SPACES))
+   *sep = ' ';
+}
+
 /**
  * hex_dump_to_buffer - convert a blob of data to "hex ASCII" in memory
  * @buf: data blob to dump
@@ -107,6 +135,9 @@ static const char *group_separator(int group, u64 flags)
  * HEXDUMP_2_GRP_LINES:insert a '|' after every 2 groups
  * HEXDUMP_4_GRP_LINES:insert a '|' after every 4 groups
  * HEXDUMP_8_GRP_LINES:insert a '|' after every 8 groups
+ * HEXDUMP_2_GRP_SPACES:   insert a ' ' after every 2 groups
+ * HEXDUMP_4_GRP_SPACES:   insert a ' ' after every 4 groups
+ * HEXDUMP_8_GRP_SPACES:   insert a ' ' after every 8 groups
  *
  * hex_dump_to_buffer() works on one "line" of output at a time, converting
  *  bytes of input to hexadecimal (and optionally printable ASCII)
@@ -138,7 +169,8 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
int j, lx = 0;
int ascii_column;
int ret;
-   int line_chars = 0;
+   int sep_chars = 0;
+   char sep = 0;
 
if (!is_power_of_2(groupsize) || groupsize > 8)
groupsize = 1;
@@ -152,8 +184,14 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
len = rowsize;
 
ngroups = len / groupsize;
+
ascii_column = rowsize * 2 + rowsize / groupsize + 1;
 
+   // space separators use 2 spaces in the hex output
+   separator_parameters(flags, groupsize, &sep_chars, &sep);
+   if (sep == ' ')
+   ascii_column += rowsize / sep_chars;
+
if (!linebuflen)
goto overflow1;
 
@@ -221,24 +259,17 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
linebuf[lx++] = ' ';
}
 
-   if (flags & HEXDUMP_2_GRP_LINES)
-   line_chars = groupsize * 2;
-   if (flags & HEXDUMP_4_GRP_LINES)
-   line_chars = groupsize * 4;
-   if (flags & HEXDUMP_8_GRP_LINES)
-   line_chars = groupsize * 8;
-
for (j = 0; j < len; j++) {
if (linebuflen < lx + 2)
goto overflow2;
ch = ptr[j];
linebuf[lx++] = (isascii(ch) && isprint(ch)) ? ch : '.';
 
-   if (line_chars && ((j + 1) < len) &&
-   ((j + 1) % line_chars == 0)) {
+   if (sep_chars && ((j + 1) < len) &&
+   ((j + 1) % sep_chars == 0)) {
if (linebuflen < lx +

Re: [Intel-gfx] [PATCH v3 3/7] lib/hexdump.c: Optionally suppress lines of repeated bytes

2019-06-17 Thread Alastair D'Silva
On Mon, 2019-06-17 at 12:04 +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva 
> 
> Some buffers may only be partially filled with useful data, while the
> rest
> is padded (typically with 0x00 or 0xff).
> 
> This patch introduces a flag to allow the supression of lines of
> repeated
> bytes, which are replaced with '** Skipped %u bytes of value 0x%x **'
> 
> An inline wrapper function is provided for backwards compatibility
> with
> existing code, which maintains the original behaviour.
> 
> Signed-off-by: Alastair D'Silva 
> ---
>  include/linux/printk.h | 25 +---
>  lib/hexdump.c  | 91 --
> 
>  2 files changed, 99 insertions(+), 17 deletions(-)
> 
> diff --git a/include/linux/printk.h b/include/linux/printk.h
> index cefd374c47b1..d7754799cfe0 100644
> --- a/include/linux/printk.h
> +++ b/include/linux/printk.h
> @@ -481,13 +481,18 @@ enum {
>   DUMP_PREFIX_ADDRESS,
>   DUMP_PREFIX_OFFSET
>  };
> +
>  extern int hex_dump_to_buffer(const void *buf, size_t len, int
> rowsize,
> int groupsize, char *linebuf, size_t
> linebuflen,
> bool ascii);
> +
> +#define HEXDUMP_ASCIIBIT(0)
> +#define HEXDUMP_SUPPRESS_REPEATEDBIT(1)
> +

This is missing the include of linux/bits.h, I'll fix this in the next
version.

-- 
Alastair D'Silva   mob: 0423 762 819
skype: alastair_dsilva
Twitter: @EvilDeece
blog: http://alastair.d-silva.org


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

[Intel-gfx] [PATCH] drm/i915: Use the correct style for SPDX License Identifier

2019-06-17 Thread Nishad Kamdar
This patch corrects the SPDX License Identifier style
in header files related to DRM Drivers for Intel 915 Graphics.
For C header files Documentation/process/license-rules.rst
mandates C-like comments (opposed to C source files where
C++ style should be used)

Changes made by using a script provided by Joe Perches here:
https://lkml.org/lkml/2019/2/7/46
and some manual changes.

Suggested-by: Joe Perches 
Signed-off-by: Nishad Kamdar 
---
 drivers/gpu/drm/i915/gem/i915_gem_clflush.h  | 3 +--
 drivers/gpu/drm/i915/gem/i915_gem_context.h  | 3 +--
 drivers/gpu/drm/i915/gem/i915_gem_context_types.h| 3 +--
 drivers/gpu/drm/i915/gem/i915_gem_ioctls.h   | 3 +--
 drivers/gpu/drm/i915/gem/i915_gem_object.h   | 3 +--
 drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 3 +--
 drivers/gpu/drm/i915/gem/i915_gem_pm.h   | 3 +--
 drivers/gpu/drm/i915/gem/i915_gemfs.h| 3 +--
 drivers/gpu/drm/i915/gem/selftests/huge_gem_object.h | 3 +--
 drivers/gpu/drm/i915/gem/selftests/igt_gem_utils.h   | 3 +--
 drivers/gpu/drm/i915/gem/selftests/mock_context.h| 3 +--
 drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.h | 3 +--
 drivers/gpu/drm/i915/gem/selftests/mock_gem_object.h | 3 +--
 drivers/gpu/drm/i915/gt/intel_context.h  | 3 +--
 drivers/gpu/drm/i915/gt/intel_context_types.h| 3 +--
 drivers/gpu/drm/i915/gt/intel_engine_pm.h| 3 +--
 drivers/gpu/drm/i915/gt/intel_engine_types.h | 3 +--
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 3 +--
 drivers/gpu/drm/i915/gt/intel_gt_pm.h| 3 +--
 drivers/gpu/drm/i915/gt/intel_lrc_reg.h  | 3 +--
 drivers/gpu/drm/i915/gt/intel_reset.h| 3 +--
 drivers/gpu/drm/i915/gt/intel_sseu.h | 3 +--
 drivers/gpu/drm/i915/gt/intel_workarounds.h  | 3 +--
 drivers/gpu/drm/i915/gt/intel_workarounds_types.h| 3 +--
 drivers/gpu/drm/i915/i915_active.h   | 3 +--
 drivers/gpu/drm/i915/i915_active_types.h | 3 +--
 drivers/gpu/drm/i915/i915_gem_batch_pool.h   | 3 +--
 drivers/gpu/drm/i915/i915_globals.h  | 3 +--
 drivers/gpu/drm/i915/i915_gpu_error.h| 3 +--
 drivers/gpu/drm/i915/i915_oa_bdw.h   | 3 +--
 drivers/gpu/drm/i915/i915_oa_bxt.h   | 3 +--
 drivers/gpu/drm/i915/i915_oa_cflgt2.h| 3 +--
 drivers/gpu/drm/i915/i915_oa_cflgt3.h| 3 +--
 drivers/gpu/drm/i915/i915_oa_chv.h   | 3 +--
 drivers/gpu/drm/i915/i915_oa_cnl.h   | 3 +--
 drivers/gpu/drm/i915/i915_oa_glk.h   | 3 +--
 drivers/gpu/drm/i915/i915_oa_hsw.h   | 3 +--
 drivers/gpu/drm/i915/i915_oa_icl.h   | 3 +--
 drivers/gpu/drm/i915/i915_oa_kblgt2.h| 3 +--
 drivers/gpu/drm/i915/i915_oa_kblgt3.h| 3 +--
 drivers/gpu/drm/i915/i915_oa_sklgt2.h| 3 +--
 drivers/gpu/drm/i915/i915_oa_sklgt3.h| 3 +--
 drivers/gpu/drm/i915/i915_oa_sklgt4.h| 3 +--
 drivers/gpu/drm/i915/i915_pmu.h  | 3 +--
 drivers/gpu/drm/i915/i915_priolist_types.h   | 3 +--
 drivers/gpu/drm/i915/i915_query.h| 3 +--
 drivers/gpu/drm/i915/i915_scatterlist.h  | 3 +--
 drivers/gpu/drm/i915/i915_scheduler.h| 3 +--
 drivers/gpu/drm/i915/i915_scheduler_types.h  | 3 +--
 drivers/gpu/drm/i915/i915_sw_fence.h | 3 +--
 drivers/gpu/drm/i915/i915_timeline_types.h   | 3 +--
 drivers/gpu/drm/i915/i915_user_extensions.h  | 3 +--
 drivers/gpu/drm/i915/intel_huc_fw.h  | 3 +--
 drivers/gpu/drm/i915/intel_wakeref.h | 3 +--
 drivers/gpu/drm/i915/intel_wopcm.h   | 3 +--
 drivers/gpu/drm/i915/selftests/igt_flush_test.h  | 3 +--
 drivers/gpu/drm/i915/selftests/igt_live_test.h   | 3 +--
 drivers/gpu/drm/i915/selftests/igt_reset.h   | 3 +--
 drivers/gpu/drm/i915/selftests/igt_spinner.h | 3 +--
 drivers/gpu/drm/i915/selftests/igt_wedge_me.h| 3 +--
 drivers/gpu/drm/i915/selftests/mock_timeline.h   | 3 +--
 61 files changed, 61 insertions(+), 122 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.h 
b/drivers/gpu/drm/i915/gem/i915_gem_clflush.h
index e6c382973129..9d7ee1579900 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.h
@@ -1,6 +1,5 @@
+/* SPDX-License-Identifier: MIT */
 /*
- * SPDX-License-Identifier: MIT
- *
  * Copyright © 2016 Intel Corporation
  */
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h 
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index 630392c77e48..26a965805e7a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -1,6 +1,5 @@
+/* SPDX-License-Identifier: MIT */
 /*
- * SPDX-License-Identifier: MIT
- *

Re: [Intel-gfx] drm/i915: last bits to make headers self-contained

2019-06-17 Thread Chris Wilson
Quoting Jani Nikula (2019-06-17 10:50:57)
> After this, all headers except display/intel_vbt_defs.h (which is also
> copy-pasted to userspace) and i915_oa_*.h (which are generated files)
> are self-contained.

All looked fine,
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 drm/i915: Restore -Wunused-but-set-variable

2019-06-17 Thread Patchwork
== Series Details ==

Series: drm/i915: Restore -Wunused-but-set-variable
URL   : https://patchwork.freedesktop.org/series/62161/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6281 -> Patchwork_13301


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13301/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850:   [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6281/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13301/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html

  * igt@prime_busy@basic-wait-after-default:
- fi-icl-u3:  [PASS][3] -> [DMESG-WARN][4] ([fdo#107724])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6281/fi-icl-u3/igt@prime_b...@basic-wait-after-default.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13301/fi-icl-u3/igt@prime_b...@basic-wait-after-default.html

  
 Possible fixes 

  * igt@gem_busy@busy-all:
- fi-icl-guc: [INCOMPLETE][5] ([fdo#107713]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6281/fi-icl-guc/igt@gem_b...@busy-all.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13301/fi-icl-guc/igt@gem_b...@busy-all.html

  * igt@gem_close_race@basic-process:
- fi-icl-u3:  [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6281/fi-icl-u3/igt@gem_close_r...@basic-process.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13301/fi-icl-u3/igt@gem_close_r...@basic-process.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy:   [DMESG-WARN][9] ([fdo#102614]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6281/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13301/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html

  
  [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724


Participating hosts (52 -> 46)
--

  Additional (1): fi-pnv-d510 
  Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks 
fi-bsw-cyan fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_6281 -> Patchwork_13301

  CI_DRM_6281: 39e3d39be374d48ba73b61ec34f19a0afd5ac6f4 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5057: 3b91c82b90d45c1a30569410c1142b541956740a @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13301: 331f7ccf619ae30bcbdeb657e9ab794a43d271a0 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

331f7ccf619a drm/i915: Restore -Wunused-but-set-variable

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/ehl: Add power wells support for Elkhart Lake

2019-06-17 Thread Imre Deak
Hi,

On Fri, Jun 14, 2019 at 07:06:49PM -0700, Vivek Kasireddy wrote:
> The number of power wells and the relevant sequences are common between
> ICL and EHL since they both are Gen 11. The only significant differences
> are that EHL does not have DDI E and DDI D and type C/TBT ports.

EHL could just reuse icl_power_wells[]. No power wells be used on EHL
that don't exist on it (since we'll not register port E/D or use the
ports in TBT/DP-alt mode).

--Imre

> 
> Cc: Clint Taylor 
> Cc: José Roberto de Souza 
> Cc: Matt Roper 
> Cc: Imre Deak 
> Signed-off-by: Vivek Kasireddy 
> ---
>  drivers/gpu/drm/i915/intel_display_power.c | 210 -
>  1 file changed, 209 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display_power.c 
> b/drivers/gpu/drm/i915/intel_display_power.c
> index c672c8080a93..e3ed77b843d2 100644
> --- a/drivers/gpu/drm/i915/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/intel_display_power.c
> @@ -2397,6 +2397,66 @@ void intel_display_power_put(struct drm_i915_private 
> *dev_priv,
>  #define ICL_AUX_TBT4_IO_POWER_DOMAINS (  \
>   BIT_ULL(POWER_DOMAIN_AUX_TBT4))
>  
> +#define EHL_PW_4_POWER_DOMAINS ( \
> + BIT_ULL(POWER_DOMAIN_PIPE_C) |  \
> + BIT_ULL(POWER_DOMAIN_PIPE_C_PANEL_FITTER) | \
> + BIT_ULL(POWER_DOMAIN_INIT))
> + /* VDSC/joining */
> +#define EHL_PW_3_POWER_DOMAINS ( \
> + EHL_PW_4_POWER_DOMAINS |\
> + BIT_ULL(POWER_DOMAIN_PIPE_B) |  \
> + BIT_ULL(POWER_DOMAIN_TRANSCODER_A) |\
> + BIT_ULL(POWER_DOMAIN_TRANSCODER_B) |\
> + BIT_ULL(POWER_DOMAIN_TRANSCODER_C) |\
> + BIT_ULL(POWER_DOMAIN_PIPE_B_PANEL_FITTER) | \
> + BIT_ULL(POWER_DOMAIN_PORT_DDI_B_LANES) |\
> + BIT_ULL(POWER_DOMAIN_PORT_DDI_B_IO) |   \
> + BIT_ULL(POWER_DOMAIN_PORT_DDI_C_LANES) |\
> + BIT_ULL(POWER_DOMAIN_PORT_DDI_C_IO) |   \
> + BIT_ULL(POWER_DOMAIN_PORT_DDI_D_LANES) |\
> + BIT_ULL(POWER_DOMAIN_PORT_DDI_D_IO) |   \
> + BIT_ULL(POWER_DOMAIN_AUX_B) |   \
> + BIT_ULL(POWER_DOMAIN_AUX_C) |   \
> + BIT_ULL(POWER_DOMAIN_AUX_D) |   \
> + BIT_ULL(POWER_DOMAIN_VGA) | \
> + BIT_ULL(POWER_DOMAIN_AUDIO) |   \
> + BIT_ULL(POWER_DOMAIN_INIT))
> + /*
> +  * - transcoder WD
> +  * - KVMR (HW control)
> +  */
> +#define EHL_PW_2_POWER_DOMAINS ( \
> + EHL_PW_3_POWER_DOMAINS |\
> + BIT_ULL(POWER_DOMAIN_TRANSCODER_EDP_VDSC) | \
> + BIT_ULL(POWER_DOMAIN_INIT))
> + /*
> +  * - KVMR (HW control)
> +  */
> +#define EHL_DISPLAY_DC_OFF_POWER_DOMAINS (   \
> + EHL_PW_2_POWER_DOMAINS |\
> + BIT_ULL(POWER_DOMAIN_MODESET) | \
> + BIT_ULL(POWER_DOMAIN_AUX_A) |   \
> + BIT_ULL(POWER_DOMAIN_INIT))
> +
> +#define EHL_DDI_IO_A_POWER_DOMAINS ( \
> + BIT_ULL(POWER_DOMAIN_PORT_DDI_A_IO))
> +#define EHL_DDI_IO_B_POWER_DOMAINS ( \
> + BIT_ULL(POWER_DOMAIN_PORT_DDI_B_IO))
> +#define EHL_DDI_IO_C_POWER_DOMAINS ( \
> + BIT_ULL(POWER_DOMAIN_PORT_DDI_C_IO))
> +#define EHL_DDI_IO_D_POWER_DOMAINS ( \
> + BIT_ULL(POWER_DOMAIN_PORT_DDI_D_IO))
> +
> +#define EHL_AUX_A_IO_POWER_DOMAINS ( \
> + BIT_ULL(POWER_DOMAIN_AUX_IO_A) |\
> + BIT_ULL(POWER_DOMAIN_AUX_A))
> +#define EHL_AUX_B_IO_POWER_DOMAINS ( \
> + BIT_ULL(POWER_DOMAIN_AUX_B))
> +#define EHL_AUX_C_IO_POWER_DOMAINS ( \
> + BIT_ULL(POWER_DOMAIN_AUX_C))
> +#define EHL_AUX_D_IO_POWER_DOMAINS ( \
> + BIT_ULL(POWER_DOMAIN_AUX_D))
> +
>  static const struct i915_power_well_ops i9xx_always_on_power_well_ops = {
>   .sync_hw = i9xx_power_well_sync_hw_noop,
>   .enable = i9xx_always_on_power_well_noop,
> @@ -3354,6 +3414,152 @@ static const struct i915_power_well_desc 
> icl_power_wells[] = {
>   },
>  };
>  
> +static const struct i915_power_well_desc ehl_power_wells[] = {
> + {
> + .name = "always-on",
> + .always_on = true,
> + .domains = POWER_DOMAIN_MASK,
> + .ops = &i9xx_always_on_power_well_ops,
> + .id = DISP_PW_ID_NONE,
> + },
> + {
> + .name = "power well 1",
> + /* Handled by the DMC firmware */
> + .always_on = true,
> + .domains = 0,
> + .ops = &hsw_power_well_ops,
> + .id = SKL_DISP_PW_1,
> + {
> + .hsw.regs = &hsw_power_well_regs,
> + .hsw.idx = ICL_PW_CTL_IDX_PW_1,
> + .hsw.has_fuses = true,
> + 

Re: [Intel-gfx] [PATCH] drm/i915: Check visibility in icl_build_plane_wm

2019-06-17 Thread Ville Syrjälä
On Fri, Jun 14, 2019 at 12:39:41PM +0200, Maarten Lankhorst wrote:
> When a planar YUV plane is configured, but the crtc is
> marked inactive, we can end up with a linked plane without
> visibility.

How is that possible? I don't think we should be adding the slave plane
if the master is not visible.

> Handle this by checking for visibility early,
> instead of doing a WARN.
> 
> <4> [201.742919] [ cut here ]
> <4> [201.742920] WARN_ON(!intel_wm_plane_visible(crtc_state, plane_state))
> <4> [201.742947] WARNING: CPU: 7 PID: 1268 at 
> drivers/gpu/drm/i915/intel_pm.c:5068 skl_compute_wm+0x2be/0x10a0 [i915]
> <4> [201.742948] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek 
> snd_hda_codec_generic i915 x86_pkg_temp_thermal snd_hda_intel coretemp 
> snd_hda_codec mei_hdcp snd_hwdep snd_hda_core crct10dif_pclmul cdc_ether 
> usbnet crc32_pclmul mii snd_pcm ghash_clmulni_intel mei_me mei prime_numbers
> <4> [201.742958] CPU: 7 PID: 1268 Comm: kms_chamelium Tainted: G U
> 5.2.0-rc3-CI-CI_DRM_6216+ #1
> <4> [201.742960] Hardware name: Intel Corporation Ice Lake Client 
> Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS 
> ICLSFWR1.R00.3183.A00.1905020411 05/02/2019
> <4> [201.742978] RIP: 0010:skl_compute_wm+0x2be/0x10a0 [i915]
> <4> [201.742980] Code: 24 10 8b 92 fc 02 00 00 0f 85 ba 04 00 00 48 c7 c6 e0 
> 38 2e a0 48 c7 c7 93 99 31 a0 89 54 24 20 48 89 44 24 08 e8 82 a2 f5 e0 <0f> 
> 0b 8b 54 24 20 48 8b 44 24 08 48 8b 40 48 80 78 12 00 0f 85 76
> <4> [201.742981] RSP: 0018:c964f9a8 EFLAGS: 00010282
> <4> [201.742983] RAX:  RBX:  RCX: 
> 0007
> <4> [201.742984] RDX: 175c RSI: 8884934d48e0 RDI: 
> 8212df49
> <4> [201.742985] RBP: 888493408558 R08: b56dab44 R09: 
> 
> <4> [201.742986] R10: 88848be0 R11:  R12: 
> 88849afd89f8
> <4> [201.742987] R13: 88847eaf67e8 R14: 88848c344a88 R15: 
> 88848be0
> <4> [201.742988] FS:  7f4d9b60b700() GS:88849ff8() 
> knlGS:
> <4> [201.742989] CS:  0010 DS:  ES:  CR0: 80050033
> <4> [201.742991] CR2: 7f4d9b609ff8 CR3: 00048c326006 CR4: 
> 00760ee0
> <4> [201.742992] PKRU: 5554
> <4> [201.742993] Call Trace:
> <4> [201.743021]  ? intel_atomic_check+0x7b2/0x1440 [i915]
> <4> [201.743026]  ? __mutex_unlock_slowpath+0x46/0x2b0
> <4> [201.743052]  intel_atomic_check+0x7ca/0x1440 [i915]
> <4> [201.743060]  drm_atomic_check_only+0x55a/0x7f0
> <4> [201.743064]  drm_atomic_commit+0xe/0x50
> <4> [201.743067]  drm_atomic_connector_commit_dpms+0xe0/0xf0
> <4> [201.743069]  set_property_atomic+0xba/0x140
> <4> [201.743075]  drm_mode_obj_set_property_ioctl+0x111/0x1d0
> <4> [201.743077]  ? drm_dev_exit+0x8/0x40
> <4> [201.743080]  ? drm_connector_set_obj_prop+0x70/0x70
> <4> [201.743082]  drm_connector_property_set_ioctl+0x39/0x60
> <4> [201.743084]  drm_ioctl_kernel+0x83/0xf0
> <4> [201.743087]  drm_ioctl+0x2f3/0x3b0
> <4> [201.743090]  ? drm_connector_set_obj_prop+0x70/0x70
> <4> [201.743096]  ? lock_acquire+0xa6/0x1c0
> <4> [201.743100]  do_vfs_ioctl+0xa0/0x6e0
> <4> [201.743103]  ? __fget+0x10f/0x200
> <4> [201.743105]  ksys_ioctl+0x35/0x60
> <4> [201.743108]  __x64_sys_ioctl+0x11/0x20
> <4> [201.743110]  do_syscall_64+0x55/0x1c0
> <4> [201.743112]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> <4> [201.743114] RIP: 0033:0x7f4da6c8d5d7
> <4> [201.743115] Code: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 
> c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 
> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 f7 d8 64 89 01 48
> <4> [201.743116] RSP: 002b:7f4d9b60aba8 EFLAGS: 0246 ORIG_RAX: 
> 0010
> <4> [201.743118] RAX: ffda RBX: 7f4d94001ac0 RCX: 
> 7f4da6c8d5d7
> <4> [201.743119] RDX: 7f4d9b60abe0 RSI: c01064ab RDI: 
> 0005
> <4> [201.743120] RBP: 7f4d9b60abe0 R08: 7f4d940015c0 R09: 
> 7f4d940015f0
> <4> [201.743121] R10: 0055 R11: 0246 R12: 
> c01064ab
> <4> [201.743122] R13: 0005 R14: 0005 R15: 
> 7f4da7a2c0c7
> <4> [201.743156] irq event stamp: 362
> <4> [201.743162] hardirqs last  enabled at (361): [] 
> vprintk_emit+0xcc/0x340
> <4> [201.743168] hardirqs last disabled at (362): [] 
> trace_hardirqs_off_thunk+0x1a/0x1c
> <4> [201.743174] softirqs last  enabled at (0): [] 
> copy_process.part.6+0x4e8/0x1dc0
> <4> [201.743178] softirqs last disabled at (0): [<>] 0x0
> <4> [201.743243] WARNING: CPU: 7 PID: 1268 at 
> drivers/gpu/drm/i915/intel_pm.c:5068 skl_compute_wm+0x2be/0x10a0 [i915]
> <4> [201.743246] ---[ end trace 33e6703087376efa ]---
> 
> Signed-off-by: Maarten Lankhorst 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110895
> Testcase: kms_chamelium@hdmi-cmp-nv12
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 8 
>  1 fi

Re: [Intel-gfx] [RESEND FOR CI] i915: no need to check return value of debugfs_create functions

2019-06-17 Thread Jani Nikula
On Thu, 13 Jun 2019, Jani Nikula  wrote:
> From: Greg Kroah-Hartman 
>
> When calling debugfs functions, there is no need to ever check the
> return value.  The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Greg Kroah-Hartman 
> Signed-off-by: Jani Nikula 

And pushed to drm-intel-next-queued, thanks for the patch.

BR,
Jani.

> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 20 +++-
>  1 file changed, 7 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 323863504111..41386c86ea65 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4442,23 +4442,17 @@ static const struct i915_debugfs_files {
>  int i915_debugfs_register(struct drm_i915_private *dev_priv)
>  {
>   struct drm_minor *minor = dev_priv->drm.primary;
> - struct dentry *ent;
>   int i;
>  
> - ent = debugfs_create_file("i915_forcewake_user", S_IRUSR,
> -   minor->debugfs_root, to_i915(minor->dev),
> -   &i915_forcewake_fops);
> - if (!ent)
> - return -ENOMEM;
> + debugfs_create_file("i915_forcewake_user", S_IRUSR, minor->debugfs_root,
> + to_i915(minor->dev), &i915_forcewake_fops);
>  
>   for (i = 0; i < ARRAY_SIZE(i915_debugfs_files); i++) {
> - ent = debugfs_create_file(i915_debugfs_files[i].name,
> -   S_IRUGO | S_IWUSR,
> -   minor->debugfs_root,
> -   to_i915(minor->dev),
> -   i915_debugfs_files[i].fops);
> - if (!ent)
> - return -ENOMEM;
> + debugfs_create_file(i915_debugfs_files[i].name,
> + S_IRUGO | S_IWUSR,
> + minor->debugfs_root,
> + to_i915(minor->dev),
> + i915_debugfs_files[i].fops);
>   }
>  
>   return drm_debugfs_create_files(i915_debugfs_list,

-- 
Jani Nikula, Intel Open Source Graphics Center
___
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 [01/22] drm/i915: Restore -Wunused-but-set-variable

2019-06-17 Thread Patchwork
== Series Details ==

Series: series starting with [01/22] drm/i915: Restore -Wunused-but-set-variable
URL   : https://patchwork.freedesktop.org/series/62184/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6282 -> Patchwork_13302


Summary
---

  **FAILURE**

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

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13302/

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_close_race@basic-process:
- fi-hsw-peppy:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6282/fi-hsw-peppy/igt@gem_close_r...@basic-process.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13302/fi-hsw-peppy/igt@gem_close_r...@basic-process.html
- fi-ivb-3770:[PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6282/fi-ivb-3770/igt@gem_close_r...@basic-process.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13302/fi-ivb-3770/igt@gem_close_r...@basic-process.html
- fi-hsw-4770:[PASS][5] -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6282/fi-hsw-4770/igt@gem_close_r...@basic-process.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13302/fi-hsw-4770/igt@gem_close_r...@basic-process.html
- fi-hsw-4770r:   [PASS][7] -> [INCOMPLETE][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6282/fi-hsw-4770r/igt@gem_close_r...@basic-process.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13302/fi-hsw-4770r/igt@gem_close_r...@basic-process.html

  * igt@i915_module_load@reload:
- fi-kbl-8809g:   [PASS][9] -> [DMESG-WARN][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6282/fi-kbl-8809g/igt@i915_module_l...@reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13302/fi-kbl-8809g/igt@i915_module_l...@reload.html
- fi-blb-e6850:   [PASS][11] -> [DMESG-WARN][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6282/fi-blb-e6850/igt@i915_module_l...@reload.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13302/fi-blb-e6850/igt@i915_module_l...@reload.html
- fi-kbl-r:   [PASS][13] -> [DMESG-WARN][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6282/fi-kbl-r/igt@i915_module_l...@reload.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13302/fi-kbl-r/igt@i915_module_l...@reload.html
- fi-apl-guc: [PASS][15] -> [DMESG-WARN][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6282/fi-apl-guc/igt@i915_module_l...@reload.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13302/fi-apl-guc/igt@i915_module_l...@reload.html
- fi-icl-dsi: NOTRUN -> [DMESG-WARN][17]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13302/fi-icl-dsi/igt@i915_module_l...@reload.html
- fi-whl-u:   [PASS][18] -> [DMESG-WARN][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6282/fi-whl-u/igt@i915_module_l...@reload.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13302/fi-whl-u/igt@i915_module_l...@reload.html
- fi-pnv-d510:[PASS][20] -> [DMESG-WARN][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6282/fi-pnv-d510/igt@i915_module_l...@reload.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13302/fi-pnv-d510/igt@i915_module_l...@reload.html
- fi-skl-6600u:   [PASS][22] -> [DMESG-WARN][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6282/fi-skl-6600u/igt@i915_module_l...@reload.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13302/fi-skl-6600u/igt@i915_module_l...@reload.html
- fi-skl-iommu:   [PASS][24] -> [DMESG-WARN][25]
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6282/fi-skl-iommu/igt@i915_module_l...@reload.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13302/fi-skl-iommu/igt@i915_module_l...@reload.html
- fi-elk-e7500:   [PASS][26] -> [DMESG-WARN][27]
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6282/fi-elk-e7500/igt@i915_module_l...@reload.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13302/fi-elk-e7500/igt@i915_module_l...@reload.html
- fi-skl-6700k2:  [PASS][28] -> [DMESG-WARN][29]
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6282/fi-skl-6700k2/igt@i915_module_l...@reload.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_1

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/22] drm/i915: Restore -Wunused-but-set-variable

2019-06-17 Thread Chris Wilson
Quoting Patchwork (2019-06-17 14:05:05)
>  Possible regressions 
> 
>   * igt@gem_close_race@basic-process:
> - fi-hsw-peppy:   [PASS][1] -> [INCOMPLETE][2]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6282/fi-hsw-peppy/igt@gem_close_r...@basic-process.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13302/fi-hsw-peppy/igt@gem_close_r...@basic-process.html

Hmm, wasn't expecting an issue with the engine wakeref vs the batch
pool.

>   * igt@i915_module_load@reload:
> - fi-kbl-8809g:   [PASS][9] -> [DMESG-WARN][10]
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6282/fi-kbl-8809g/igt@i915_module_l...@reload.html
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13302/fi-kbl-8809g/igt@i915_module_l...@reload.html

Leaked the intel_framebuffer object.
-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 drm/i915/icl: Add missing device ID

2019-06-17 Thread Patchwork
== Series Details ==

Series: drm/i915/icl: Add missing device ID
URL   : https://patchwork.freedesktop.org/series/62187/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6284 -> Patchwork_13303


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13303/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_exec@basic:
- fi-icl-y:   [PASS][1] -> [INCOMPLETE][2] ([fdo#107713])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6284/fi-icl-y/igt@gem_ctx_e...@basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13303/fi-icl-y/igt@gem_ctx_e...@basic.html

  * igt@gem_exec_basic@basic-all:
- fi-icl-u2:  [PASS][3] -> [INCOMPLETE][4] ([fdo#107713])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6284/fi-icl-u2/igt@gem_exec_ba...@basic-all.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13303/fi-icl-u2/igt@gem_exec_ba...@basic-all.html

  * igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: [PASS][5] -> [DMESG-WARN][6] ([fdo#106387]) +1 
similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6284/fi-ilk-650/igt@prime_v...@basic-fence-flip.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13303/fi-ilk-650/igt@prime_v...@basic-fence-flip.html

  
 Possible fixes 

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [FAIL][7] ([fdo#109485]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6284/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13303/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  
  [fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485


Participating hosts (44 -> 38)
--

  Additional (2): fi-icl-dsi fi-pnv-d510 
  Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks 
fi-bsw-cyan fi-kbl-8809g fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_6284 -> Patchwork_13303

  CI_DRM_6284: f992a9cb038edbdd5ff20a1ed3410e8b95879bcf @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5057: 3b91c82b90d45c1a30569410c1142b541956740a @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13303: 5bb41e6ad0ec333636d93785cf5736c6f43a042e @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

5bb41e6ad0ec drm/i915/icl: Add missing device ID

== Logs ==

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

Re: [Intel-gfx] [PATCH 14/22] drm/i915: Throw away the active object retirement complexity

2019-06-17 Thread Matthew Auld

On 17/06/2019 08:19, Chris Wilson wrote:

Remove the accumulated optimisations that we have for i915_vma_retire
and reduce it to the bare essential of tracking the active object
reference. This allows us to only use atomic operations, and so will be
able to avoid the struct_mutex requirement.

The principal loss here is the shrinker MRU bumping, so now if we have
to shrink, we will do so in much more random order and more likely to
try and shrink recently used objects. That is a nuisance, but shrinking
active objects is a second step we try to avoid and will always be a
system-wide performance issue.

The other loss is here is in the automatic pruning of the
reservation_object when idling. This is not as large an issue as upon
reservation_object introduction as now adding new fences into the object
replaces already signaled fences, keeping the array compact. But we do
lose the auto-expiration of stale fences and unused arrays. That may be
a noticeable problem for which we need to re-implement autopruning.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/gem/i915_gem_object.c|  1 -
  drivers/gpu/drm/i915/gem/i915_gem_object.h|  6 ---
  .../gpu/drm/i915/gem/i915_gem_object_types.h  |  1 -
  drivers/gpu/drm/i915/gem/i915_gem_shrinker.c  |  5 +-
  .../drm/i915/gem/selftests/i915_gem_mman.c|  9 
  drivers/gpu/drm/i915/gt/intel_lrc.c   |  4 +-
  drivers/gpu/drm/i915/gt/intel_ringbuffer.c|  1 -
  drivers/gpu/drm/i915/gt/selftest_hangcheck.c  | 32 +--
  drivers/gpu/drm/i915/i915_debugfs.c   |  8 +--
  drivers/gpu/drm/i915/i915_gem_batch_pool.c| 42 ++-
  drivers/gpu/drm/i915/i915_vma.c   | 54 ---
  11 files changed, 47 insertions(+), 116 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index bb5b6e63a2cc..252e752da211 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -162,7 +162,6 @@ static void __i915_gem_free_objects(struct drm_i915_private 
*i915,
  
  		mutex_lock(&i915->drm.struct_mutex);
  
-		GEM_BUG_ON(i915_gem_object_is_active(obj));

list_for_each_entry_safe(vma, vn, &obj->vma.list, obj_link) {
GEM_BUG_ON(i915_vma_is_active(vma));
vma->flags &= ~I915_VMA_PIN_MASK;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 7cb1871d7128..454bfb498001 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -158,12 +158,6 @@ i915_gem_object_needs_async_cancel(const struct 
drm_i915_gem_object *obj)
return obj->ops->flags & I915_GEM_OBJECT_ASYNC_CANCEL;
  }
  
-static inline bool

-i915_gem_object_is_active(const struct drm_i915_gem_object *obj)
-{
-   return READ_ONCE(obj->active_count);
-}
-
  static inline bool
  i915_gem_object_is_framebuffer(const struct drm_i915_gem_object *obj)
  {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 5b05698619ce..c299fed2c6b1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -156,7 +156,6 @@ struct drm_i915_gem_object {
  
  	/** Count of VMA actually bound by this object */

atomic_t bind_count;
-   unsigned int active_count;
/** Count of how many global VMA are currently pinned for use by HW */
unsigned int pin_global;
  
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c

index 3a926a8755c6..f4677f70cce7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -230,8 +230,9 @@ i915_gem_shrink(struct drm_i915_private *i915,
continue;
  
  			if (!(shrink & I915_SHRINK_ACTIVE) &&

-   (i915_gem_object_is_active(obj) ||
-i915_gem_object_is_framebuffer(obj)))
+   (i915_gem_object_is_framebuffer(obj) ||
+reservation_object_test_signaled_rcu(obj->resv,
+ true)))


Wait, isn't it the other way around, so 
!reservation_object_test_signaled_rcu() ?



continue;
  
  			if (!(shrink & I915_SHRINK_BOUND) &&

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index 5c81f4b4813a..2053194a8b70 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -474,15 +474,6 @@ static int igt_mmap_offset_exhaustion(void *arg)
pr_err("[loop %d] Failed to busy the object\n", loop);
goto err_obj;
}
-
-  

Re: [Intel-gfx] [PATCH 07/59] drm/arm/komeda: Remove DRIVER_HAVE_IRQ

2019-06-17 Thread Daniel Vetter
On Mon, Jun 17, 2019 at 06:26:08AM +, james qian wang (Arm Technology 
China) wrote:
> On Fri, Jun 14, 2019 at 10:35:23PM +0200, Daniel Vetter wrote:
> > Read the docs, komeda is not an old enough driver for this :-)
> > 
> > Signed-off-by: Daniel Vetter 
> > Cc: "James (Qian) Wang" 
> > Cc: Liviu Dudau 
> > ---
> >  drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c 
> > b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > index 0c6396dc323f..b9d699cc7bbf 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > @@ -55,8 +55,7 @@ static irqreturn_t komeda_kms_irq_handler(int irq, void 
> > *data)
> >  }
> >  
> >  static struct drm_driver komeda_kms_driver = {
> > -   .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
> > -  DRIVER_HAVE_IRQ,
> > +   .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> > .lastclose  = drm_fb_helper_lastclose,
> > .irq_handler= komeda_kms_irq_handler,
> 
> Hi Daniel:
> 
> Thank you for the patch.
> 
> And Ayan also sent two patches for this topic. like:
> 
> For drop drm_irq_install:
> https://patchwork.freedesktop.org/series/61763/
> For manually set drm->irq_enabled:
> https://patchwork.freedesktop.org/series/61776/
> 
> For clear, seems we'd better squash all these three patches into one
> single patch.

Not sure how these other patches are related to mine directly. This here
just removes a flag which does nothing, because komeda is not a legacy
driver. And ack for merging right away would be nice.

Thanks, Daniel

> 
> Hi Ayan:
> Could you help the squash all these patches to a single one.
> 
> Thanks
> James
> 
> > .gem_free_object_unlocked   = drm_gem_cma_free_object,
> > -- 
> > 2.20.1

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

Re: [Intel-gfx] [PATCH 14/22] drm/i915: Throw away the active object retirement complexity

2019-06-17 Thread Chris Wilson
Quoting Matthew Auld (2019-06-17 14:43:34)
> On 17/06/2019 08:19, Chris Wilson wrote:
> > Remove the accumulated optimisations that we have for i915_vma_retire
> > and reduce it to the bare essential of tracking the active object
> > reference. This allows us to only use atomic operations, and so will be
> > able to avoid the struct_mutex requirement.
> > 
> > The principal loss here is the shrinker MRU bumping, so now if we have
> > to shrink, we will do so in much more random order and more likely to
> > try and shrink recently used objects. That is a nuisance, but shrinking
> > active objects is a second step we try to avoid and will always be a
> > system-wide performance issue.
> > 
> > The other loss is here is in the automatic pruning of the
> > reservation_object when idling. This is not as large an issue as upon
> > reservation_object introduction as now adding new fences into the object
> > replaces already signaled fences, keeping the array compact. But we do
> > lose the auto-expiration of stale fences and unused arrays. That may be
> > a noticeable problem for which we need to re-implement autopruning.
> > 
> > Signed-off-by: Chris Wilson 
> > ---
> >   drivers/gpu/drm/i915/gem/i915_gem_object.c|  1 -
> >   drivers/gpu/drm/i915/gem/i915_gem_object.h|  6 ---
> >   .../gpu/drm/i915/gem/i915_gem_object_types.h  |  1 -
> >   drivers/gpu/drm/i915/gem/i915_gem_shrinker.c  |  5 +-
> >   .../drm/i915/gem/selftests/i915_gem_mman.c|  9 
> >   drivers/gpu/drm/i915/gt/intel_lrc.c   |  4 +-
> >   drivers/gpu/drm/i915/gt/intel_ringbuffer.c|  1 -
> >   drivers/gpu/drm/i915/gt/selftest_hangcheck.c  | 32 +--
> >   drivers/gpu/drm/i915/i915_debugfs.c   |  8 +--
> >   drivers/gpu/drm/i915/i915_gem_batch_pool.c| 42 ++-
> >   drivers/gpu/drm/i915/i915_vma.c   | 54 ---
> >   11 files changed, 47 insertions(+), 116 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > index bb5b6e63a2cc..252e752da211 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > @@ -162,7 +162,6 @@ static void __i915_gem_free_objects(struct 
> > drm_i915_private *i915,
> >   
> >   mutex_lock(&i915->drm.struct_mutex);
> >   
> > - GEM_BUG_ON(i915_gem_object_is_active(obj));
> >   list_for_each_entry_safe(vma, vn, &obj->vma.list, obj_link) {
> >   GEM_BUG_ON(i915_vma_is_active(vma));
> >   vma->flags &= ~I915_VMA_PIN_MASK;
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
> > b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > index 7cb1871d7128..454bfb498001 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > @@ -158,12 +158,6 @@ i915_gem_object_needs_async_cancel(const struct 
> > drm_i915_gem_object *obj)
> >   return obj->ops->flags & I915_GEM_OBJECT_ASYNC_CANCEL;
> >   }
> >   
> > -static inline bool
> > -i915_gem_object_is_active(const struct drm_i915_gem_object *obj)
> > -{
> > - return READ_ONCE(obj->active_count);
> > -}
> > -
> >   static inline bool
> >   i915_gem_object_is_framebuffer(const struct drm_i915_gem_object *obj)
> >   {
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
> > b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > index 5b05698619ce..c299fed2c6b1 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > @@ -156,7 +156,6 @@ struct drm_i915_gem_object {
> >   
> >   /** Count of VMA actually bound by this object */
> >   atomic_t bind_count;
> > - unsigned int active_count;
> >   /** Count of how many global VMA are currently pinned for use by HW */
> >   unsigned int pin_global;
> >   
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> > index 3a926a8755c6..f4677f70cce7 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> > @@ -230,8 +230,9 @@ i915_gem_shrink(struct drm_i915_private *i915,
> >   continue;
> >   
> >   if (!(shrink & I915_SHRINK_ACTIVE) &&
> > - (i915_gem_object_is_active(obj) ||
> > -  i915_gem_object_is_framebuffer(obj)))
> > + (i915_gem_object_is_framebuffer(obj) ||
> > +  reservation_object_test_signaled_rcu(obj->resv,
> > +   true)))
> 
> Wait, isn't it the other way around, so 
> !reservation_object_test_signaled_rcu() ?

If you insist ;)

> 
> >   continue;
> >   
> >   if (!(shrink & I915_SHRINK_BOUND) &&
> > diff --git a/d

Re: [Intel-gfx] [PATCH v2] drm/i915/gtt: Serialise both updates to PDE and our shadow

2019-06-17 Thread Mika Kuoppala
Chris Wilson  writes:

> Currently, we perform a locked update of the shadow entry when
> allocating a page directory entry such that if two clients are
> concurrently allocating neighbouring ranges we only insert one new entry
> for the pair of them. However, we also need to serialise both clients
> wrt to the actual entry in the HW table, or else we may allow one client
> or even a third client to proceed ahead of the HW write. My handwave
> before was that under the _pathological_ condition we would see the
> scratch entry instead of the expected entry, causing a temporary
> glitch. That starvation condition will eventually show up in practice, so
> fix it.
>
> The reason for the previous cheat was to avoid having to free the extra
> allocation while under the spinlock. Now, we keep the extra entry
> allocated until the end instead.
>
> v2: Fix error paths for gen6
>
> Fixes: 1d1b5490b91c ("drm/i915/gtt: Replace struct_mutex serialisation for 
> allocation")
> Signed-off-by: Chris Wilson 
> Cc: Matthew Auld 
> Cc: Mika Kuoppala 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c | 130 +++-
>  1 file changed, 72 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 0392a4c4bb9b..0987748d327b 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -1387,82 +1387,88 @@ static int gen8_ppgtt_alloc_pd(struct 
> i915_address_space *vm,
>  struct i915_page_directory *pd,
>  u64 start, u64 length)
>  {
> + struct i915_page_table *alloc = NULL;
>   struct i915_page_table *pt;
>   u64 from = start;
>   unsigned int pde;
> + int ret = 0;
>  
>   spin_lock(&pd->lock);
>   gen8_for_each_pde(pt, pd, start, length, pde) {
>   const int count = gen8_pte_count(start, length);
>  
>   if (pt == vm->scratch_pt) {
> - struct i915_page_table *old;
> -
>   spin_unlock(&pd->lock);
>  
> - pt = alloc_pt(vm);
> - if (IS_ERR(pt))
> + pt = fetch_and_zero(&alloc);
> + if (!pt)
> + pt = alloc_pt(vm);
> + if (IS_ERR(pt)) {
> + ret = PTR_ERR(pt);
>   goto unwind;
> + }
>  
>   if (count < GEN8_PTES || intel_vgpu_active(vm->i915))
>   gen8_initialize_pt(vm, pt);
>  
> - old = cmpxchg(&pd->page_table[pde], vm->scratch_pt, pt);
> - if (old == vm->scratch_pt) {
> + spin_lock(&pd->lock);
> + if (pd->page_table[pde] == vm->scratch_pt) {
>   gen8_ppgtt_set_pde(vm, pd, pt, pde);
> + pd->page_table[pde] = pt;
>   atomic_inc(&pd->used_pdes);
>   } else {
> - free_pt(vm, pt);
> - pt = old;
> + alloc = pt;
> + pt = pd->page_table[pde];
>   }
> -
> - spin_lock(&pd->lock);
>   }
>  
>   atomic_add(count, &pt->used_ptes);
>   }
>   spin_unlock(&pd->lock);
> -
> - return 0;
> + goto out;
>  
>  unwind:
>   gen8_ppgtt_clear_pd(vm, pd, from, start - from);
> - return -ENOMEM;
> +out:
> + if (alloc)
> + free_pt(vm, alloc);
> + return ret;
>  }
>  
>  static int gen8_ppgtt_alloc_pdp(struct i915_address_space *vm,
>   struct i915_page_directory_pointer *pdp,
>   u64 start, u64 length)
>  {
> + struct i915_page_directory *alloc = NULL;
>   struct i915_page_directory *pd;
>   u64 from = start;
>   unsigned int pdpe;
> - int ret;
> + int ret = 0;
>  
>   spin_lock(&pdp->lock);
>   gen8_for_each_pdpe(pd, pdp, start, length, pdpe) {
>   if (pd == vm->scratch_pd) {
> - struct i915_page_directory *old;
> -
>   spin_unlock(&pdp->lock);
>  
> - pd = alloc_pd(vm);
> - if (IS_ERR(pd))
> + pd = fetch_and_zero(&alloc);
> + if (!pd)
> + pd = alloc_pd(vm);
> + if (IS_ERR(pd)) {
> + ret = PTR_ERR(pd);
>   goto unwind;
> + }
>  
>   gen8_initialize_pd(vm, pd);
>  
> - old = cmpxchg(&pdp->page_directory[pdpe],
> -   vm->scratch_pd, pd);
> - if (old == vm->scratch_pd) {
> +

Re: [Intel-gfx] [PATCH 40/59] drm/vram-helper: Drop drm_gem_prime_export/import

2019-06-17 Thread Daniel Vetter
On Mon, Jun 17, 2019 at 10:24:38AM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > Aside: Would be really nice to switch the others over to
> > drm_gem_object_funcs.
> 
> While most callbacks are pretty straight forward (just hook the same
> callbacks into the drm_gem_object_funcs. struct) the mmap bits are a
> bit more obscure.
> 
> First, there seem to be two ways to mmap a gem buffer:
> 
>   (1) drm_driver->fops->mmap, and
>   (2) drm_driver->gem_prime_mmap.
> 
> drm_gem_object_funcs has just a single vm_ops ...
> 
> Also it is not obvious how one would convert something which basically
> calls ttm_bo_mmap() in drm_driver->fops->mmap to the new interface.

Yeah the mmap side is still a mess, but my series here was getting a bit
too long already. There's a bunch of problems here:

drm_driver->gem_prime_mmap could be nuked and instead we use
drm_gem_prime_mmap everywhere. Especially the various versions in helpers
really don't add much.

The trouble is that removing the hook outright isn't quite right, because
it also signals "is mmap allowed on this dma-buf". I'm kinda tempted to
just make that a hard requirement, and force people who can't support mmap
on the dma-buf (or who need begin/end_cpu_access hooks) to supply their
own set of dma_buf_ops.

Second one is drm_driver->fops->mmap. That one we need to keep, but this
isn't mmap on a buffer, but mmap on the entire drm_device. The one which
should be replaced by drm_gem_object_funcs.vm_ops is
drm_driver->gem_vm_ops.

Hope that explains a bit better what's going on here. Step one here for
mmap is definitely to roll out drm_gem_prime_mmap as far as possible, so
it's easier to understand where the exceptions are.

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

Re: [Intel-gfx] [PATCH 01/59] drm/todo: Improve drm_gem_object funcs todo

2019-06-17 Thread Daniel Vetter
On Fri, Jun 14, 2019 at 03:53:31PM -0700, Eric Anholt wrote:
> Daniel Vetter  writes:
> 
> > We're kinda going in the wrong direction. Spotted while typing better
> > gem/prime docs.
> >
> > Cc: Thomas Zimmermann 
> > Cc: Gerd Hoffmann 
> > Cc: Rob Herring 
> > Cc: Noralf Trønnes 
> > Signed-off-by: Daniel Vetter 
> 
> That's a big series, but a great cleanup.  I took a look at a lot of it.
> Patch 1-2, 4-10, 41-47, 49-50, and all the gem_prime_import/export drop
> patches are:
> 
> Reviewed-by: Eric Anholt 

Thanks a lot for all your review.

> I don't currently have a plan for reading the shuffle in patch 3.

Yeah patch 3 is not cool, I need to split out the shuffle from the doc
rework. Should have done that for v1, but got a bit lazy before the w/e
:-)

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

  1   2   3   >