[Intel-gfx] [PATCH v7 4/4] drm/dp: Track MST link bandwidth

[Dhinakaran Pandiyan]

From: "Pandiyan, Dhinakaran" 

Use the added helpers to track MST link bandwidth for atomic modesets.
Link bw is acquired in the ->atomic_check() phase when CRTCs are being
enabled with drm_atomic_find_vcpi_slots() instead of drm_find_vcpi_slots().
Similarly, link bw is released during ->atomic_check() with the connector
helper callback ->atomic_release() when CRTCs are disabled.

v5: Implement connector->atomic_check() in place of atomic_release()
v4: Return an int from intel_dp_mst_atomic_release() (Maarten)
v3:
 Handled the case where ->atomic_release() is called more than once
 during an atomic_check() for the same state.
v2:
 Squashed atomic_release() implementation and caller (Daniel)
 Fixed logic for connector-crtc switching case (Daniel)
 Fixed logic for suspend-resume case.

Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Archit Taneja 
Cc: Chris Wilson 
Cc: Harry Wentland 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp_mst.c | 57 +
 1 file changed, 51 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 5af22a7..20c557c 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -39,9 +39,9 @@ static bool intel_dp_mst_compute_config(struct intel_encoder 
*encoder,
struct intel_dp *intel_dp = _dig_port->dp;
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
-   struct drm_atomic_state *state;
+   struct drm_atomic_state *state = pipe_config->base.state;
int bpp;
-   int lane_count, slots;
+   int lane_count, slots = 0;
const struct drm_display_mode *adjusted_mode = 
_config->base.adjusted_mode;
int mst_pbn;
 
@@ -63,24 +63,68 @@ static bool intel_dp_mst_compute_config(struct 
intel_encoder *encoder,
pipe_config->pipe_bpp = bpp;
pipe_config->port_clock = intel_dp_max_link_rate(intel_dp);
 
-   state = pipe_config->base.state;
-
if (drm_dp_mst_port_has_audio(_dp->mst_mgr, connector->port))
pipe_config->has_audio = true;
-   mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
 
+   mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
pipe_config->pbn = mst_pbn;
-   slots = drm_dp_find_vcpi_slots(_dp->mst_mgr, mst_pbn);
 
intel_link_compute_m_n(bpp, lane_count,
   adjusted_mode->crtc_clock,
   pipe_config->port_clock,
   _config->dp_m_n);
 
+   if (pipe_config->base.active) {
+   slots = drm_dp_atomic_find_vcpi_slots(state, _dp->mst_mgr,
+ connector->port, mst_pbn);
+   if (slots < 0) {
+   DRM_DEBUG_KMS("failed finding vcpi slots:%d\n", slots);
+   return false;
+   }
+   }
pipe_config->dp_m_n.tu = slots;
 
return true;
+}
 
+static inline bool release_resources(struct drm_crtc_state *crtc_state)
+{
+   return (crtc_state->connectors_changed ||
+   crtc_state->mode_changed ||
+   (crtc_state->active_changed && !crtc_state->active));
+}
+
+static int intel_dp_mst_atomic_check(struct drm_connector *connector,
+   struct drm_connector_state *new_conn_state)
+{
+   struct drm_atomic_state *state = new_conn_state->state;
+   struct drm_connector_state *old_conn_state;
+   struct drm_crtc *old_crtc;
+   struct drm_crtc_state *crtc_state;
+   int slots, ret = 0;
+
+   old_conn_state = drm_atomic_get_old_connector_state(state, connector);
+   old_crtc = old_conn_state->crtc;
+   if (!old_crtc)
+   return 0;
+
+   crtc_state = drm_atomic_get_new_crtc_state(state, old_crtc);
+   slots = to_intel_crtc_state(crtc_state)->dp_m_n.tu;
+
+   if (release_resources(crtc_state) && slots > 0) {
+   struct drm_dp_mst_topology_mgr *mgr;
+   struct drm_encoder *old_encoder;
+
+   old_encoder = old_conn_state->best_encoder;
+   mgr = _to_mst(old_encoder)->primary->dp.mst_mgr;
+
+   ret = drm_dp_atomic_release_vcpi_slots(state, mgr, slots);
+   if (ret)
+   DRM_DEBUG_KMS("failed releasing %d vcpi slots:%d\n", 
slots, ret);
+   else
+   to_intel_crtc_state(crtc_state)->dp_m_n.tu = 0;
+   }
+   return ret;
 }
 
 static void intel_mst_disable_dp(struct intel_encoder *encoder,
@@ -378,6 +422,7 @@ static const struct drm_connector_helper_funcs 
intel_dp_mst_connector_helper_fun
.mode_valid = intel_dp_mst_mode_valid,

[Intel-gfx] [PATCH v7 1/4] drm: Add driver-private objects to atomic state

[Dhinakaran Pandiyan]

From: "Pandiyan, Dhinakaran" 

It is necessary to track states for objects other than connector, crtc
and plane for atomic modesets. But adding objects like DP MST link
bandwidth to drm_atomic_state would mean that a non-core object will be
modified by the core helper functions for swapping and clearing
it's state. So, lets add void * objects and helper functions that operate
on void * types to keep these objects and states private to the core.
Drivers can then implement specific functions to swap and clear states.
The other advantage having just void * for these objects in
drm_atomic_state is that objects of different types can be managed in the
same state array.

v6: More kernel-doc to keep 0-day happy
v5: Remove more NULL checks (Maarten)
v4: Avoid redundant NULL checks when private_objs array is empty (Maarten)
v3: Macro alignment (Chris)
v2: Added docs and new iterator to filter private objects (Daniel)

Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Archit Taneja 
Cc: Chris Wilson 
Cc: Harry Wentland 

Acked-by: Harry Wentland 
Suggested-by: Daniel Vetter 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_atomic.c|  65 +++
 drivers/gpu/drm/drm_atomic_helper.c |   5 ++
 include/drm/drm_atomic.h| 101 
 3 files changed, 171 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 30229ab..8e5f3eb 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -57,6 +57,7 @@ void drm_atomic_state_default_release(struct drm_atomic_state 
*state)
kfree(state->connectors);
kfree(state->crtcs);
kfree(state->planes);
+   kfree(state->private_objs);
 }
 EXPORT_SYMBOL(drm_atomic_state_default_release);
 
@@ -184,6 +185,17 @@ void drm_atomic_state_default_clear(struct 
drm_atomic_state *state)
state->planes[i].ptr = NULL;
state->planes[i].state = NULL;
}
+
+   for (i = 0; i < state->num_private_objs; i++) {
+   void *obj_state = state->private_objs[i].obj_state;
+
+   state->private_objs[i].funcs->destroy_state(obj_state);
+   state->private_objs[i].obj = NULL;
+   state->private_objs[i].obj_state = NULL;
+   state->private_objs[i].funcs = NULL;
+   }
+   state->num_private_objs = 0;
+
 }
 EXPORT_SYMBOL(drm_atomic_state_default_clear);
 
@@ -978,6 +990,59 @@ static void drm_atomic_plane_print_state(struct 
drm_printer *p,
 }
 
 /**
+ * drm_atomic_get_private_obj_state - get private object state
+ * @state: global atomic state
+ * @obj: private object to get the state for
+ * @funcs: pointer to the struct of function pointers that identify the object
+ * type
+ *
+ * This function returns the private object state for the given private object,
+ * allocating the state if needed. It does not grab any locks as the caller is
+ * expected to care of any required locking.
+ *
+ * RETURNS:
+ *
+ * Either the allocated state or the error code encoded into a pointer.
+ */
+void *
+drm_atomic_get_private_obj_state(struct drm_atomic_state *state, void *obj,
+ const struct drm_private_state_funcs *funcs)
+{
+   int index, num_objs, i;
+   size_t size;
+   struct __drm_private_objs_state *arr;
+
+   for (i = 0; i < state->num_private_objs; i++)
+   if (obj == state->private_objs[i].obj &&
+   state->private_objs[i].obj_state)
+   return state->private_objs[i].obj_state;
+
+   num_objs = state->num_private_objs + 1;
+   size = sizeof(*state->private_objs) * num_objs;
+   arr = krealloc(state->private_objs, size, GFP_KERNEL);
+   if (!arr)
+   return ERR_PTR(-ENOMEM);
+
+   state->private_objs = arr;
+   index = state->num_private_objs;
+   memset(>private_objs[index], 0, sizeof(*state->private_objs));
+
+   state->private_objs[index].obj_state = funcs->duplicate_state(state, 
obj);
+   if (!state->private_objs[index].obj_state)
+   return ERR_PTR(-ENOMEM);
+
+   state->private_objs[index].obj = obj;
+   state->private_objs[index].funcs = funcs;
+   state->num_private_objs = num_objs;
+
+   DRM_DEBUG_ATOMIC("Added new private object state %p to %p\n",
+state->private_objs[index].obj_state, state);
+
+   return state->private_objs[index].obj_state;
+}
+EXPORT_SYMBOL(drm_atomic_get_private_obj_state);
+
+/**
  * drm_atomic_get_connector_state - get connector state
  * @state: global atomic state object
  * @connector: connector to get state object for
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 

[Intel-gfx] [PATCH v7 3/4] drm/dp: Add DP MST helpers to atomically find and release vcpi slots

[Dhinakaran Pandiyan]

From: "Pandiyan, Dhinakaran" 

drm_dp_atomic_find_vcpi_slots() should be called from ->atomic_check() to
check there are sufficient vcpi slots for a mode and to add that to the
state. This should be followed by a call to drm_dp_mst_allocate_vcpi()
in ->atomic_commit() to initialize a struct vcpi for the port.

drm_dp_atomic_release_vcpi_slots() should be called from
->atomic_check() to release a port's vcpi slot allocation from the
state.

Drivers that do not make use of this atomic helper are expected to call
drm_dp_find_vcpi_slots() instead before calling
drm_dp_mst_allocate_vcpi().

v3: drm_dp_atomic_release_vcpi_slots() now needs to know how many slots
to release as we may not have a valid reference to port.
v2:
Added checks for verifying the port reference is valid
Moved get_mst_topology_state() into the helpers (Daniel)
Changed find_vcpi_slots() to not depend on current allocation

Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Archit Taneja 
Cc: Chris Wilson 
Cc: Harry Wentland 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 75 +++
 include/drm/drm_dp_mst_helper.h   |  6 +++
 2 files changed, 81 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 0ad0baa..d1cbb9c 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2498,6 +2498,81 @@ static int drm_dp_init_vcpi(struct 
drm_dp_mst_topology_mgr *mgr,
 }
 
 /**
+ * drm_dp_atomic_find_vcpi_slots() - Find and add vcpi slots to the state
+ * @state: global atomic state
+ * @mgr: MST topology manager for the port
+ * @port: port to find vcpi slots for
+ * @pbn: bandwidth required for the mode in PBN
+ *
+ * RETURNS:
+ * Total slots in the atomic state assigned for this port or error
+ */
+int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state *state,
+ struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_port *port, int pbn)
+{
+   struct drm_dp_mst_topology_state *topology_state;
+   int req_slots;
+
+   topology_state = drm_atomic_get_mst_topology_state(state, mgr);
+   if (topology_state == NULL)
+   return -ENOMEM;
+
+   port = drm_dp_get_validated_port_ref(mgr, port);
+   if (port == NULL)
+   return -EINVAL;
+   req_slots = DIV_ROUND_UP(pbn, mgr->pbn_div);
+   DRM_DEBUG_KMS("vcpi slots req=%d, avail=%d\n",
+   req_slots, topology_state->avail_slots);
+
+   if (req_slots > topology_state->avail_slots) {
+   drm_dp_put_port(port);
+   return -ENOSPC;
+   }
+
+   topology_state->avail_slots -= req_slots;
+   DRM_DEBUG_KMS("vcpi slots avail=%d", topology_state->avail_slots);
+
+   drm_dp_put_port(port);
+   return req_slots;
+}
+EXPORT_SYMBOL(drm_dp_atomic_find_vcpi_slots);
+
+/**
+ * drm_dp_atomic_release_vcpi_slots() - Release allocated vcpi slots
+ * @state: global atomic state
+ * @mgr: MST topology manager for the port
+ * @slots: number of vcpi slots to release
+ *
+ * RETURNS:
+ * 0 if @slots were added back to _dp_mst_topology_state->avail_slots or
+ * negative error code
+ */
+int drm_dp_atomic_release_vcpi_slots(struct drm_atomic_state *state,
+struct drm_dp_mst_topology_mgr *mgr,
+int slots)
+{
+   struct drm_dp_mst_topology_state *topology_state;
+
+   topology_state = drm_atomic_get_mst_topology_state(state, mgr);
+   if (topology_state == NULL)
+   return -ENOMEM;
+
+   /* We cannot rely on port->vcpi.num_slots to update
+* topology_state->avail_slots as the port may not exist if the parent
+* branch device was unplugged. This should be fixed by tracking
+* per-port slot allocation in drm_dp_mst_topology_state instead of
+* depending on the caller to tell us how many slots to release.
+*/
+   topology_state->avail_slots += slots;
+   DRM_DEBUG_KMS("vcpi slots released=%d, avail=%d\n",
+   slots, topology_state->avail_slots);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_dp_atomic_release_vcpi_slots);
+
+/**
  * drm_dp_mst_allocate_vcpi() - Allocate a virtual channel
  * @mgr: manager for this port
  * @port: port to allocate a virtual channel for.
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 0b371df..177ab6f 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -615,5 +615,11 @@ void drm_dp_mst_topology_mgr_suspend(struct 
drm_dp_mst_topology_mgr *mgr);
 int drm_dp_mst_topology_mgr_resume(struct drm_dp_mst_topology_mgr *mgr);
 struct 

[Intel-gfx] [PATCH v7 0/4] Adding driver-private objects to atomic state

[Dhinakaran Pandiyan]

Changes in this version:
Used connector->atomic_check() to release vcpi slots instead of the
atomic_release() callback.

This series introduces void * type driver-private objects in core and adds
helper functions that operate on these private objects. Drivers need to
implement object-specific functions to swap and clear object states. The
advantage of having void * for these objects in the core is objects of different
types can be managed in the same atomic state array. The series implements
DP-MST link bw tracking using the driver-private object infrastructure.

Pandiyan, Dhinakaran (4):
  drm: Add driver-private objects to atomic state
  drm/dp: Introduce MST topology state to track available link bandwidth
  drm/dp: Add DP MST helpers to atomically find and release vcpi slots
  drm/dp: Track MST link bandwidth

 drivers/gpu/drm/drm_atomic.c  |  65 +++
 drivers/gpu/drm/drm_atomic_helper.c   |   5 ++
 drivers/gpu/drm/drm_dp_mst_topology.c | 150 ++
 drivers/gpu/drm/i915/intel_dp_mst.c   |  57 +++--
 include/drm/drm_atomic.h  | 101 +++
 include/drm/drm_dp_mst_helper.h   |  26 ++
 6 files changed, 398 insertions(+), 6 deletions(-)

-- 
2.7.4

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

[Intel-gfx] [PATCH v7 2/4] drm/dp: Introduce MST topology state to track available link bandwidth

[Dhinakaran Pandiyan]

From: "Pandiyan, Dhinakaran" 

Link bandwidth is shared between multiple display streams in DP MST
configurations. The DP MST topology manager structure maintains the
shared link bandwidth for a primary link directly connected to the GPU. For
atomic modesetting drivers, checking if there is sufficient link bandwidth
for a mode needs to be done during the atomic_check phase to avoid failed
modesets. Let's encapsulate the available link bw information in a
private state structure so that bw can be allocated and released atomically
for each of the ports sharing the primary link.

v3: WARN_ON() if connection_mutex is not held (Archit)
v2: Included kernel doc, moved state initialization and switched to
kmemdup() for allocation (Daniel)

Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Archit Taneja 
Cc: Chris Wilson 
Cc: Harry Wentland 
Reviewed-by: Maarten Lankhorst 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 75 +++
 include/drm/drm_dp_mst_helper.h   | 20 ++
 2 files changed, 95 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index d3fc7e4..0ad0baa 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2936,6 +2936,69 @@ static void drm_dp_destroy_connector_work(struct 
work_struct *work)
(*mgr->cbs->hotplug)(mgr);
 }
 
+void *drm_dp_mst_duplicate_state(struct drm_atomic_state *state, void *obj)
+{
+   struct drm_dp_mst_topology_mgr *mgr = obj;
+   struct drm_dp_mst_topology_state *new_mst_state;
+
+   if (WARN_ON(!mgr->state))
+   return NULL;
+
+   new_mst_state = kmemdup(mgr->state, sizeof(*new_mst_state), GFP_KERNEL);
+   if (new_mst_state)
+   new_mst_state->state = state;
+   return new_mst_state;
+}
+
+void drm_dp_mst_swap_state(void *obj, void **obj_state_ptr)
+{
+   struct drm_dp_mst_topology_mgr *mgr = obj;
+   struct drm_dp_mst_topology_state **topology_state_ptr;
+
+   topology_state_ptr = (struct drm_dp_mst_topology_state **)obj_state_ptr;
+
+   mgr->state->state = (*topology_state_ptr)->state;
+   swap(*topology_state_ptr, mgr->state);
+   mgr->state->state = NULL;
+}
+
+void drm_dp_mst_destroy_state(void *obj_state)
+{
+   kfree(obj_state);
+}
+
+static const struct drm_private_state_funcs mst_state_funcs = {
+   .duplicate_state = drm_dp_mst_duplicate_state,
+   .swap_state = drm_dp_mst_swap_state,
+   .destroy_state = drm_dp_mst_destroy_state,
+};
+
+/**
+ * drm_atomic_get_mst_topology_state: get MST topology state
+ *
+ * @state: global atomic state
+ * @mgr: MST topology manager, also the private object in this case
+ *
+ * This function wraps drm_atomic_get_priv_obj_state() passing in the MST 
atomic
+ * state vtable so that the private object state returned is that of a MST
+ * topology object. Also, drm_atomic_get_private_obj_state() expects the caller
+ * to care of the locking, so warn if don't hold the connection_mutex.
+ *
+ * RETURNS:
+ *
+ * The MST topology state or error pointer.
+ */
+struct drm_dp_mst_topology_state *drm_atomic_get_mst_topology_state(struct 
drm_atomic_state *state,
+   struct 
drm_dp_mst_topology_mgr *mgr)
+{
+   struct drm_device *dev = mgr->dev;
+
+   WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
+   return drm_atomic_get_private_obj_state(state, mgr,
+   _state_funcs);
+}
+EXPORT_SYMBOL(drm_atomic_get_mst_topology_state);
+
 /**
  * drm_dp_mst_topology_mgr_init - initialise a topology manager
  * @mgr: manager struct to initialise
@@ -2980,6 +3043,15 @@ int drm_dp_mst_topology_mgr_init(struct 
drm_dp_mst_topology_mgr *mgr,
if (test_calc_pbn_mode() < 0)
DRM_ERROR("MST PBN self-test failed\n");
 
+   mgr->state = kzalloc(sizeof(*mgr->state), GFP_KERNEL);
+   if (mgr->state == NULL)
+   return -ENOMEM;
+   mgr->state->mgr = mgr;
+
+   /* max. time slots - one slot for MTP header */
+   mgr->state->avail_slots = 63;
+   mgr->funcs = _state_funcs;
+
return 0;
 }
 EXPORT_SYMBOL(drm_dp_mst_topology_mgr_init);
@@ -3000,6 +3072,9 @@ void drm_dp_mst_topology_mgr_destroy(struct 
drm_dp_mst_topology_mgr *mgr)
mutex_unlock(>payload_lock);
mgr->dev = NULL;
mgr->aux = NULL;
+   kfree(mgr->state);
+   mgr->state = NULL;
+   mgr->funcs = NULL;
 }
 EXPORT_SYMBOL(drm_dp_mst_topology_mgr_destroy);
 
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 5b02476..0b371df 100644
--- 

Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree

[Logan Gunthorpe]

Thanks Stephen. Looks good to me.

Logan

On 20/04/17 08:10 PM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/tee/tee_shm.c:87:2: error: unknown field 'kmap_atomic' specified in 
> initializer
>   .kmap_atomic = tee_shm_op_kmap_atomic,
>   ^
> drivers/tee/tee_shm.c:87:17: error: initialization from incompatible pointer 
> type [-Werror=incompatible-pointer-types]
>   .kmap_atomic = tee_shm_op_kmap_atomic,
>  ^
> drivers/tee/tee_shm.c:87:17: note: (near initialization for 
> 'tee_shm_dma_buf_ops.begin_cpu_access')
> drivers/tee/tee_shm.c:88:2: error: unknown field 'kmap' specified in 
> initializer
>   .kmap = tee_shm_op_kmap,
>   ^
> drivers/tee/tee_shm.c:88:10: error: initialization from incompatible pointer 
> type [-Werror=incompatible-pointer-types]
>   .kmap = tee_shm_op_kmap,
>   ^
> drivers/tee/tee_shm.c:88:10: note: (near initialization for 
> 'tee_shm_dma_buf_ops.end_cpu_access')
> 
> Caused by commit
> 
>   f9b67f0014cb ("dma-buf: Rename dma-ops to prevent conflict with 
> kunmap_atomic macro")
> 
> interacting with commit
> 
>   967c9cca2cc5 ("tee: generic TEE subsystem")
> 
> from the arm-soc tree.
> 
> I applied the following merge fix patch for today:
> 
> From: Stephen Rothwell 
> Date: Fri, 21 Apr 2017 12:06:32 +1000
> Subject: [PATCH] tee: merge fix for dma-ops field name changes
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/tee/tee_shm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
> index 0be1e3e93bee..4e14c9c9cb1c 100644
> --- a/drivers/tee/tee_shm.c
> +++ b/drivers/tee/tee_shm.c
> @@ -84,8 +84,8 @@ static struct dma_buf_ops tee_shm_dma_buf_ops = {
>   .map_dma_buf = tee_shm_op_map_dma_buf,
>   .unmap_dma_buf = tee_shm_op_unmap_dma_buf,
>   .release = tee_shm_op_release,
> - .kmap_atomic = tee_shm_op_kmap_atomic,
> - .kmap = tee_shm_op_kmap,
> + .map_atomic = tee_shm_op_kmap_atomic,
> + .map = tee_shm_op_kmap,
>   .mmap = tee_shm_op_mmap,
>  };
>  
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] linux-next: build failure after merge of the drm-misc tree

[Stephen Rothwell]

Hi all,

After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/tee/tee_shm.c:87:2: error: unknown field 'kmap_atomic' specified in 
initializer
  .kmap_atomic = tee_shm_op_kmap_atomic,
  ^
drivers/tee/tee_shm.c:87:17: error: initialization from incompatible pointer 
type [-Werror=incompatible-pointer-types]
  .kmap_atomic = tee_shm_op_kmap_atomic,
 ^
drivers/tee/tee_shm.c:87:17: note: (near initialization for 
'tee_shm_dma_buf_ops.begin_cpu_access')
drivers/tee/tee_shm.c:88:2: error: unknown field 'kmap' specified in initializer
  .kmap = tee_shm_op_kmap,
  ^
drivers/tee/tee_shm.c:88:10: error: initialization from incompatible pointer 
type [-Werror=incompatible-pointer-types]
  .kmap = tee_shm_op_kmap,
  ^
drivers/tee/tee_shm.c:88:10: note: (near initialization for 
'tee_shm_dma_buf_ops.end_cpu_access')

Caused by commit

  f9b67f0014cb ("dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic 
macro")

interacting with commit

  967c9cca2cc5 ("tee: generic TEE subsystem")

from the arm-soc tree.

I applied the following merge fix patch for today:

From: Stephen Rothwell 
Date: Fri, 21 Apr 2017 12:06:32 +1000
Subject: [PATCH] tee: merge fix for dma-ops field name changes

Signed-off-by: Stephen Rothwell 
---
 drivers/tee/tee_shm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
index 0be1e3e93bee..4e14c9c9cb1c 100644
--- a/drivers/tee/tee_shm.c
+++ b/drivers/tee/tee_shm.c
@@ -84,8 +84,8 @@ static struct dma_buf_ops tee_shm_dma_buf_ops = {
.map_dma_buf = tee_shm_op_map_dma_buf,
.unmap_dma_buf = tee_shm_op_unmap_dma_buf,
.release = tee_shm_op_release,
-   .kmap_atomic = tee_shm_op_kmap_atomic,
-   .kmap = tee_shm_op_kmap,
+   .map_atomic = tee_shm_op_kmap_atomic,
+   .map = tee_shm_op_kmap,
.mmap = tee_shm_op_mmap,
 };
 
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell
___
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: Don't try detecting sinks on ports already in use

[Patchwork]

== Series Details ==

Series: drm: i915: Don't try detecting sinks on ports already in use
URL   : https://patchwork.freedesktop.org/series/23299/
State : success

== Summary ==

Series 23299v1 drm: i915: Don't try detecting sinks on ports already in use
https://patchwork.freedesktop.org/api/1.0/series/23299/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
fail   -> PASS   (fi-skl-6700k) fdo#100367
Test pm_rpm:
Subgroup basic-rte:
incomplete -> PASS   (fi-bsw-n3050) fdo#100718

fdo#100367 https://bugs.freedesktop.org/show_bug.cgi?id=100367
fdo#100718 https://bugs.freedesktop.org/show_bug.cgi?id=100718

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:422s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:430s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:567s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:509s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:554s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:470s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:470s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:409s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:404s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:421s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:482s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:471s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:460s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:569s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:453s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:574s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:465s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:481s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:428s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:521s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:400s

9bb844000d9412c2758b861ce7aee1e9546fccb9 drm-tip: 2017y-04m-20d-14h-46m-59s UTC 
integration manifest
5e41558 drm: i915: Don't try detecting sinks on ports already in use

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4526/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH RFC] drm: i915: Don't try detecting sinks on ports already in use

[Gabriel Krisman Bertazi]

On systems where more than one connector is attached to the same port,
the HPD pin is also shared, and attaching one connector will trigger a
hotplug on every other connector on that port.  But, according to the
documentation, connectors sharing the port cannot be enabled
simultaneously, such that we can abort the detection process early if
another connector was detected succesfully.

This has the good side effect of preventing DP timeouts whenever
something else is connected to the shared port, like below:

[drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7143003f
[drm:drm_dp_dpcd_access] Too many retries, giving up. First error: -110

Since this reduces the overhead of the i915_hotplug_work_func, it may
address the following vblank misses detected by the CI:

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

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/i915/intel_display.c | 26 ++
 drivers/gpu/drm/i915/intel_dp.c  |  3 +++
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_hdmi.c|  3 +++
 4 files changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 85b9e2f521a0..618b5138c0c7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11270,6 +11270,32 @@ static bool check_digital_port_conflicts(struct 
drm_atomic_state *state)
return true;
 }
 
+bool intel_shared_digital_port_in_use(struct drm_connector *conn)
+{
+   struct drm_connector *peer;
+   struct drm_connector_list_iter iter;
+   struct intel_encoder *enc = to_intel_connector(conn)->encoder;
+   int ret = false;
+
+   drm_connector_list_iter_begin(conn->dev, );
+   drm_for_each_connector_iter(peer, ) {
+   struct intel_encoder *peer_enc;
+
+   if (peer == conn ||
+   peer->status != connector_status_connected)
+   continue;
+
+   peer_enc = to_intel_connector(peer)->encoder;
+   if (peer_enc->port == enc->port) {
+   ret = true;
+   break;
+   }
+   }
+   drm_connector_list_iter_end();
+
+   return ret;
+}
+
 static void
 clear_intel_crtc_state(struct intel_crtc_state *crtc_state)
 {
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 08834f74d396..0823c588575f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4628,6 +4628,9 @@ intel_dp_long_pulse(struct intel_connector 
*intel_connector)
 

WARN_ON(!drm_modeset_is_locked(>dev->mode_config.connection_mutex));
 
+   if (intel_shared_digital_port_in_use(connector))
+   return connector_status_disconnected;
+
intel_display_power_get(to_i915(dev), intel_dp->aux_power_domain);
 
/* Can't disconnect eDP, but you can close the lid... */
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 54f3ff840812..fd5f2517bede 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1411,6 +1411,7 @@ int vlv_force_pll_on(struct drm_i915_private *dev_priv, 
enum pipe pipe,
 const struct dpll *dpll);
 void vlv_force_pll_off(struct drm_i915_private *dev_priv, enum pipe pipe);
 int lpt_get_iclkip(struct drm_i915_private *dev_priv);
+bool intel_shared_digital_port_in_use(struct drm_connector *conn);
 
 /* modesetting asserts */
 void assert_panel_unlocked(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 6efc3cb8c471..ed4015ae7d24 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1527,6 +1527,9 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
  connector->base.id, connector->name);
 
+   if (intel_shared_digital_port_in_use(connector))
+   return connector_status_disconnected;;
+
intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
 
intel_hdmi_unset_edid(connector);
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH v6 05/20] drm/i915/tdr: Add support for per engine reset recovery

[Michel Thierry]

On 19/04/17 03:49, Chris Wilson wrote:

On Tue, Apr 18, 2017 at 01:23:20PM -0700, Michel Thierry wrote:

From: Arun Siluvery 

This change implements support for per-engine reset as an initial, less
intrusive hang recovery option to be attempted before falling back to the
legacy full GPU reset recovery mode if necessary. This is only supported
from Gen8 onwards.

Hangchecker determines which engines are hung and invokes error handler to
recover from it. Error handler schedules recovery for each of those engines
that are hung. The recovery procedure is as follows,
 - identifies the request that caused the hang and it is dropped
 - force engine to idle: this is done by issuing a reset request
 - reset and re-init engine
 - restart submissions to the engine

If engine reset fails then we fall back to heavy weight full gpu reset
which resets all engines and reinitiazes complete state of HW and SW.

v2: Rebase.
v3: s/*engine_reset*/*reset_engine*/; freeze engine and irqs before
calling i915_gem_reset_engine (Chris).
v4: Rebase, modify i915_gem_reset_prepare to use a ring mask and
reuse the function for reset_engine.
v5: intel_reset_engine_start/cancel instead of request/unrequest_reset.
v6: Clean up reset_engine function to not require mutex, i.e. no need to call
revoke/restore_fences and _retire_requests (Chris).

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Tomas Elf 
Signed-off-by: Arun Siluvery 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_drv.c | 76 --
 drivers/gpu/drm/i915/i915_drv.h | 12 +++-
 drivers/gpu/drm/i915/i915_gem.c | 97 +++--
 drivers/gpu/drm/i915/i915_gem_request.c |  2 +-
 drivers/gpu/drm/i915/intel_uncore.c | 20 +++
 5 files changed, 158 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e03d0643dbd6..634893cd93b3 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1810,7 +1810,7 @@ void i915_reset(struct drm_i915_private *dev_priv)

pr_notice("drm/i915: Resetting chip after gpu hang\n");
disable_irq(dev_priv->drm.irq);
-   ret = i915_gem_reset_prepare(dev_priv);
+   ret = i915_gem_reset_prepare(dev_priv, ALL_ENGINES);
if (ret) {
DRM_ERROR("GPU recovery failed\n");
intel_gpu_reset(dev_priv, ALL_ENGINES);
@@ -1852,7 +1852,7 @@ void i915_reset(struct drm_i915_private *dev_priv)
i915_queue_hangcheck(dev_priv);

 finish:
-   i915_gem_reset_finish(dev_priv);
+   i915_gem_reset_finish(dev_priv, ALL_ENGINES);
enable_irq(dev_priv->drm.irq);

 wakeup:
@@ -1871,11 +1871,79 @@ void i915_reset(struct drm_i915_private *dev_priv)
  *
  * Reset a specific GPU engine. Useful if a hang is detected.
  * Returns zero on successful reset or otherwise an error code.
+ *
+ * Procedure is:
+ *  - identifies the request that caused the hang and it is dropped
+ *  - force engine to idle: this is done by issuing a reset request
+ *  - reset engine
+ *  - restart submissions to the engine
  */
 int i915_reset_engine(struct intel_engine_cs *engine)
 {
-   /* FIXME: replace me with engine reset sequence */
-   return -ENODEV;
+   int ret;
+   struct drm_i915_private *dev_priv = engine->i915;
+   struct i915_gpu_error *error = _priv->gpu_error;
+
+   GEM_BUG_ON(!test_bit(I915_RESET_BACKOFF, >flags));
+
+   DRM_DEBUG_DRIVER("resetting %s\n", engine->name);
+
+   /*
+* We need to first idle the engine by issuing a reset request,
+* then perform soft reset and re-initialize hw state, for all of
+* this GT power need to be awake so ensure it does throughout the
+* process
+*/
+   intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);


Hmm, what path did we take to get here without taking rpm? I thought I
had fixed the last offender.



Too many rebases... As you say, this is no longer needed after 
1604a86d08053 "drm/i915: Extend rpm wakelock during i915_handle_error()"



+   disable_irq(dev_priv->drm.irq);


I am 99% certain that we don't need to disable_irq() now for per-engine
reset... I'd keep it in the global reset as simple paranoia.



100% correct.


+   ret = i915_gem_reset_prepare_engine(engine);
+   if (ret) {
+   DRM_ERROR("Previous reset failed - promote to full reset\n");
+   goto error;
+   }
+
+   /*
+* the request that caused the hang is stuck on elsp, identify the
+* active request and drop it, adjust head to skip the offending
+* request to resume executing remaining requests in the queue.
+*/


Hmm. Interesting. This relies on i915_gem_retire_requests() (i.e.
struct_mutex) to skip replaying innocent 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix pipe/transcoder enum mismatches

[Patchwork]

== Series Details ==

Series: drm/i915: Fix pipe/transcoder enum mismatches
URL   : https://patchwork.freedesktop.org/series/23296/
State : success

== Summary ==

Series 23296v1 drm/i915: Fix pipe/transcoder enum mismatches
https://patchwork.freedesktop.org/api/1.0/series/23296/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
fail   -> PASS   (fi-skl-6700k) fdo#100367
Test pm_rpm:
Subgroup basic-rte:
incomplete -> PASS   (fi-bsw-n3050) fdo#100718

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#100367 https://bugs.freedesktop.org/show_bug.cgi?id=100367
fdo#100718 https://bugs.freedesktop.org/show_bug.cgi?id=100718

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:436s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:425s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:581s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:507s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:545s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:487s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:494s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:408s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:405s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:429s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:498s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:479s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:460s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:571s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:449s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:574s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:461s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:486s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:430s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:534s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:403s

9bb844000d9412c2758b861ce7aee1e9546fccb9 drm-tip: 2017y-04m-20d-14h-46m-59s UTC 
integration manifest
0c17701 drm/i915: Fix pipe/transcoder enum mismatches

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4525/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

[Matthias Kaehlcke]

In several instances the driver passes an 'enum pipe' value to a
function expecting an 'enum transcoder' and viceversa. Since PIPE_x and
TRANSCODER_x have the same values this doesn't cause functional
problems. Still it is incorrect and causes clang to generate warnings
like this:

drivers/gpu/drm/i915/intel_display.c:1844:34: warning: implicit
  conversion from enumeration type 'enum transcoder' to different
  enumeration type 'enum pipe' [-Wenum-conversion]
assert_fdi_rx_enabled(dev_priv, TRANSCODER_A);

Change the code to pass values of the type expected by the callee.

Signed-off-by: Matthias Kaehlcke 
---
 drivers/gpu/drm/i915/intel_display.c | 4 ++--
 drivers/gpu/drm/i915/intel_dp.c  | 6 --
 drivers/gpu/drm/i915/intel_hdmi.c| 6 --
 drivers/gpu/drm/i915/intel_sdvo.c| 6 --
 4 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ed1f4f272b4f..23484f042fae 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1841,7 +1841,7 @@ static void lpt_enable_pch_transcoder(struct 
drm_i915_private *dev_priv,
 
/* FDI must be feeding us bits for PCH ports */
assert_fdi_tx_enabled(dev_priv, (enum pipe) cpu_transcoder);
-   assert_fdi_rx_enabled(dev_priv, TRANSCODER_A);
+   assert_fdi_rx_enabled(dev_priv, PIPE_A);
 
/* Workaround: set timing override bit. */
val = I915_READ(TRANS_CHICKEN2(PIPE_A));
@@ -4607,7 +4607,7 @@ static void lpt_pch_enable(struct drm_crtc *crtc)
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
 
-   assert_pch_transcoder_disabled(dev_priv, TRANSCODER_A);
+   assert_pch_transcoder_disabled(dev_priv, PIPE_A);
 
lpt_program_iclkip(crtc);
 
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d1670b8afbf5..454c2d3dfdd6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3568,7 +3568,8 @@ intel_dp_link_down(struct intel_dp *intel_dp)
 * doing the workaround. Sweep them under the rug.
 */
intel_set_cpu_fifo_underrun_reporting(dev_priv, PIPE_A, false);
-   intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, false);
+   intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
+ false);
 
/* always enable with pattern 1 (as per spec) */
DP &= ~(DP_PIPEB_SELECT | DP_LINK_TRAIN_MASK);
@@ -3582,7 +3583,8 @@ intel_dp_link_down(struct intel_dp *intel_dp)
 
intel_wait_for_vblank_if_active(dev_priv, PIPE_A);
intel_set_cpu_fifo_underrun_reporting(dev_priv, PIPE_A, true);
-   intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, true);
+   intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
+ true);
}
 
msleep(intel_dp->panel_power_down_delay);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 24b2fa5b6282..48b1f5d37204 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1153,7 +1153,8 @@ static void intel_disable_hdmi(struct intel_encoder 
*encoder,
 * doing the workaround. Sweep them under the rug.
 */
intel_set_cpu_fifo_underrun_reporting(dev_priv, PIPE_A, false);
-   intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, false);
+   intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
+ false);
 
temp &= ~SDVO_PIPE_B_SELECT;
temp |= SDVO_ENABLE;
@@ -1172,7 +1173,8 @@ static void intel_disable_hdmi(struct intel_encoder 
*encoder,
 
intel_wait_for_vblank_if_active(dev_priv, PIPE_A);
intel_set_cpu_fifo_underrun_reporting(dev_priv, PIPE_A, true);
-   intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, true);
+   intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
+ true);
}
 
intel_hdmi->set_infoframes(>base, false, old_crtc_state, 
old_conn_state);
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
b/drivers/gpu/drm/i915/intel_sdvo.c
index 2ad13903a054..0568a9950f7f 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1462,7 +1462,8 @@ static void intel_disable_sdvo(struct intel_encoder 
*encoder,
 * doing the workaround. Sweep them under the rug.
 */
intel_set_cpu_fifo_underrun_reporting(dev_priv, PIPE_A, false);
-   

Re: [Intel-gfx] [PULL] drm-misc-next-fixes

[Daniel Vetter]

On Thu, Apr 20, 2017 at 10:11 PM, Sean Paul  wrote:
> Hi Dave,
> A few fixes for you to pick up. The driver changes are trivial, and the
> maintainer change was necessitated by the sti fix. The headliner here is the
> dma_buf_ops rename, since it touches so many drivers. Everything looks sane 
> and
> builds with that change, so it shouldn't cause problems.
>
>
> drm-misc-next-fixes-2017-04-20:
>
> Core changes:
> - Maintain sti via drm-misc (Vincent)
> - Rename dma_buf_ops->kmap_* to avoid naming collision (Logan)

This one touches v4l and ion and is acked by the corresponding
maintainers (but Sumit forgot to record that when applying the patch,
and Sean didn't highlight it in the summary).

Sean, should we augment the template that cross-subsystem stuff
(outside of what's on-topic for drm-misc) needs to be highlighted
specifically in the pull summary?

Off for vacation for real now.

Cheers, Daniel

>
> Driver changes:
> - Fix UHD displays on stih407 (Vincent)
> - Fix uninitialized var return in atmel-hlcdc (Dan)
>
> Take care, Sean
>
>
> The following changes since commit 8cb68c83ab99a474ae847602f0c514d0fe17cc82:
>
>   drm: Fix get_property logic fumble (2017-04-12 18:11:32 +0200)
>
> are available in the git repository at:
>
>   git://anongit.freedesktop.org/git/drm-misc 
> tags/drm-misc-next-fixes-2017-04-20
>
> for you to fetch changes up to f9b67f0014cba18f1aabb6fa9272335a043eb6fd:
>
>   dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro 
> (2017-04-20 13:47:46 +0530)
>
> 
> drm-misc-next-fixes-2017-04-20
>
> Core changes:
> - Maintain sti via drm-misc (Vincent)
> - Rename dma_buf_ops->kmap_* to avoid naming collision (Logan)
>
> Driver changes:
> - Fix UHD displays on stih407 (Vincent)
> - Fix uninitialized var return in atmel-hlcdc (Dan)
>
> 
> Dan Carpenter (1):
>   drm: atmel-hlcdc: Uninitialized return in atmel_hlcdc_create_outputs()
>
> Logan Gunthorpe (1):
>   dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro
>
> Vincent Abriou (2):
>   MAINTAINERS: add drm/sti driver into drm-misc
>   drm/sti: fix GDP size to support up to UHD resolution
>
>  MAINTAINERS  |  2 +-
>  drivers/dma-buf/dma-buf.c| 16 
>  drivers/gpu/drm/armada/armada_gem.c  |  8 
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c |  5 ++---
>  drivers/gpu/drm/drm_prime.c  |  8 
>  drivers/gpu/drm/i915/i915_gem_dmabuf.c   |  8 
>  drivers/gpu/drm/i915/selftests/mock_dmabuf.c |  8 
>  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c|  8 
>  drivers/gpu/drm/sti/sti_gdp.c| 12 +++-
>  drivers/gpu/drm/tegra/gem.c  |  8 
>  drivers/gpu/drm/udl/udl_dmabuf.c |  8 
>  drivers/gpu/drm/vmwgfx/vmwgfx_prime.c|  8 
>  drivers/media/v4l2-core/videobuf2-dma-contig.c   |  4 ++--
>  drivers/media/v4l2-core/videobuf2-dma-sg.c   |  4 ++--
>  drivers/media/v4l2-core/videobuf2-vmalloc.c  |  4 ++--
>  drivers/staging/android/ion/ion.c|  8 
>  include/linux/dma-buf.h  | 22 +++---
>  17 files changed, 71 insertions(+), 70 deletions(-)
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] drm-misc-next-fixes

[Sean Paul]

Hi Dave,
A few fixes for you to pick up. The driver changes are trivial, and the
maintainer change was necessitated by the sti fix. The headliner here is the
dma_buf_ops rename, since it touches so many drivers. Everything looks sane and
builds with that change, so it shouldn't cause problems.


drm-misc-next-fixes-2017-04-20:

Core changes:
- Maintain sti via drm-misc (Vincent)
- Rename dma_buf_ops->kmap_* to avoid naming collision (Logan)

Driver changes:
- Fix UHD displays on stih407 (Vincent)
- Fix uninitialized var return in atmel-hlcdc (Dan)

Take care, Sean


The following changes since commit 8cb68c83ab99a474ae847602f0c514d0fe17cc82:

  drm: Fix get_property logic fumble (2017-04-12 18:11:32 +0200)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-fixes-2017-04-20

for you to fetch changes up to f9b67f0014cba18f1aabb6fa9272335a043eb6fd:

  dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro 
(2017-04-20 13:47:46 +0530)


drm-misc-next-fixes-2017-04-20

Core changes:
- Maintain sti via drm-misc (Vincent)
- Rename dma_buf_ops->kmap_* to avoid naming collision (Logan)

Driver changes:
- Fix UHD displays on stih407 (Vincent)
- Fix uninitialized var return in atmel-hlcdc (Dan)


Dan Carpenter (1):
  drm: atmel-hlcdc: Uninitialized return in atmel_hlcdc_create_outputs()

Logan Gunthorpe (1):
  dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

Vincent Abriou (2):
  MAINTAINERS: add drm/sti driver into drm-misc
  drm/sti: fix GDP size to support up to UHD resolution

 MAINTAINERS  |  2 +-
 drivers/dma-buf/dma-buf.c| 16 
 drivers/gpu/drm/armada/armada_gem.c  |  8 
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c |  5 ++---
 drivers/gpu/drm/drm_prime.c  |  8 
 drivers/gpu/drm/i915/i915_gem_dmabuf.c   |  8 
 drivers/gpu/drm/i915/selftests/mock_dmabuf.c |  8 
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c|  8 
 drivers/gpu/drm/sti/sti_gdp.c| 12 +++-
 drivers/gpu/drm/tegra/gem.c  |  8 
 drivers/gpu/drm/udl/udl_dmabuf.c |  8 
 drivers/gpu/drm/vmwgfx/vmwgfx_prime.c|  8 
 drivers/media/v4l2-core/videobuf2-dma-contig.c   |  4 ++--
 drivers/media/v4l2-core/videobuf2-dma-sg.c   |  4 ++--
 drivers/media/v4l2-core/videobuf2-vmalloc.c  |  4 ++--
 drivers/staging/android/ion/ion.c|  8 
 include/linux/dma-buf.h  | 22 +++---
 17 files changed, 71 insertions(+), 70 deletions(-)

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] freedesktop bug id: 100548, bisected to sched/clock commit

[Peter Zijlstra]

On Thu, Apr 20, 2017 at 07:19:50PM +0200, Peter Zijlstra wrote:

> Just for my sanity, could you confirm "tsc=unstable" (which requires the
> patch) actually works for you?


Also, could you get me the dmesg of a 'broken' boot?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 13/20] drm/i915/guc: Provide register list to be saved/restored during engine reset

[Michel Thierry]

On 20/04/17 09:39, Daniele Ceraolo Spurio wrote:



On 20/04/17 04:33, Joonas Lahtinen wrote:

On ke, 2017-04-19 at 11:35 -0700, Michel Thierry wrote:

From: Arun Siluvery 

GuC expects a list of registers from the driver which are saved/restored
during engine reset. The type of value to be saved is controlled by
flags. We provide a minimal set of registers that we want GuC to save
and
restore. This is not an issue in case of engine reset as driver
initializes
most of them following an engine reset, but in case of media reset (aka
watchdog reset) which is completely internal to GuC (including
resubmission
of hung workload), it is necessary to provide this list, otherwise
GuC won't
be able to schedule further workloads after a reset. This is the minimal
set of registers identified for things to work as expected but if we see
any new issues, this register list can be expanded.

In order to not loose any existing workarounds, we have to let GuC know
the registers and its values. These will be reapplied after the reset.
Note that we can't just read the current value because most of these
registers are masked (so we have a workaround for a workaround for a
workaround).

v2: REGSET_MASKED is too difficult for GuC, use
REGSET_SAVE_DEFAULT_VALUE
and current value from RING_MODE reg instead; no need to preserve
head/tail either, be extra paranoid and save whitelisted registers
(Daniele).

v3: Workarounds added only once during _init_workarounds also have to
been restored, or we risk loosing them after internal GuC reset
(Daniele).

Cc: Daniele Ceraolo Spurio 
Signed-off-by: Arun Siluvery 
Signed-off-by: Jeff McGee 
Signed-off-by: Michel Thierry 





@@ -732,15 +755,16 @@ static int gen9_init_workarounds(struct
intel_engine_cs *engine)

 int ret;


 /* WaConextSwitchWithConcurrentTLBInvalidate:skl,bxt,kbl,glk */
-I915_WRITE(GEN9_CSFE_CHICKEN1_RCS,
_MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE));
+I915_GUC_REG_WRITE(GEN9_CSFE_CHICKEN1_RCS,
+
_MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE));


To make grepping easier, how about?

I915_WRITE(GUC_REG(GEN9_CSFE_CHICKEN1_RCS),
   ...);

Regards, Joonas



GUC_REG makes it sound like it is somehow related to GuC, while it
isn't, we just want GuC to restore its value. What about GUC_REG_RESTORE?



Honestly, I dont care about names, pick one and I add it.
Just a reminder, we not only need the reg offset, we want to save the 
value too.


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

Re: [Intel-gfx] freedesktop bug id: 100548, bisected to sched/clock commit

[Peter Zijlstra]

On Tue, Apr 18, 2017 at 05:53:56PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 18, 2017 at 02:10:07PM +, Lofstedt, Marta wrote:
> > Sorry Peter, I still see regression on the Core2 machine, with your patch.
> > 
> 
> Blergh, ok. I'll see if I can dig out an actual Core2 machine somewhere.
> I should have enough parts about.

Argh!

My Core2 seems to work as expected _without_ this patch (time is
continuous at the stable->unstable switch), but is broken (time jumps
backwards by almost .2s) with this patch -- because by the time ACPI
Processor marks TSC as busted, we haven't ran the clocksource watchdog
yet.


Just for my sanity, could you confirm "tsc=unstable" (which requires the
patch) actually works for you?

I'll go prod at things now that I have an actual Core2 running; although
sadly I don't see an obvious problem without this patch.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 18/20] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout

[Michel Thierry]

On 20/04/17 01:52, Chris Wilson wrote:

On Wed, Apr 19, 2017 at 06:09:00PM -0700, Michel Thierry wrote:

This patch is missing:

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index c1013af0b910..a8bdea43a217 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1135,7 +1135,7 @@ int i915_gem_context_getparam_ioctl(struct
drm_device *dev, void *data,
return PTR_ERR(ctx);
}

-   args->size = 0;
+   args->size = (args->param != I915_CONTEXT_PARAM_WATCHDOG) ? 0 :
args->size;
switch (args->param) {
case I915_CONTEXT_PARAM_BAN_PERIOD:
ret = -EINVAL;

Or there will be no way to get the current thresholds (chunk was
missed due to some TRTT code nearby). I'll be sure to include it in
the next version.


No. It is always preset to 0. The PARAM should set it to the actual
struct size (it would write) and *not* the user's size.
-Chris



Ok, then I'll change the shortcut in get_watchdog, because as it is you 
can query the size, but not the thresholds.


int i915_gem_context_get_watchdog()
{
...
if (args->size == 0)
goto out;
...
out:
args->size = sizeof(threshold_in_us);

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

Re: [Intel-gfx] [PATCH v6 13/20] drm/i915/guc: Provide register list to be saved/restored during engine reset

[Daniele Ceraolo Spurio]

On 20/04/17 04:33, Joonas Lahtinen wrote:

On ke, 2017-04-19 at 11:35 -0700, Michel Thierry wrote:

From: Arun Siluvery 

GuC expects a list of registers from the driver which are saved/restored
during engine reset. The type of value to be saved is controlled by
flags. We provide a minimal set of registers that we want GuC to save and
restore. This is not an issue in case of engine reset as driver initializes
most of them following an engine reset, but in case of media reset (aka
watchdog reset) which is completely internal to GuC (including resubmission
of hung workload), it is necessary to provide this list, otherwise GuC won't
be able to schedule further workloads after a reset. This is the minimal
set of registers identified for things to work as expected but if we see
any new issues, this register list can be expanded.

In order to not loose any existing workarounds, we have to let GuC know
the registers and its values. These will be reapplied after the reset.
Note that we can't just read the current value because most of these
registers are masked (so we have a workaround for a workaround for a
workaround).

v2: REGSET_MASKED is too difficult for GuC, use REGSET_SAVE_DEFAULT_VALUE
and current value from RING_MODE reg instead; no need to preserve
head/tail either, be extra paranoid and save whitelisted registers (Daniele).

v3: Workarounds added only once during _init_workarounds also have to
been restored, or we risk loosing them after internal GuC reset
(Daniele).

Cc: Daniele Ceraolo Spurio 
Signed-off-by: Arun Siluvery 
Signed-off-by: Jeff McGee 
Signed-off-by: Michel Thierry 





@@ -732,15 +755,16 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*engine)

int ret;


/* WaConextSwitchWithConcurrentTLBInvalidate:skl,bxt,kbl,glk */
-   I915_WRITE(GEN9_CSFE_CHICKEN1_RCS, 
_MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE));
+   I915_GUC_REG_WRITE(GEN9_CSFE_CHICKEN1_RCS,
+  
_MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE));


To make grepping easier, how about?

I915_WRITE(GUC_REG(GEN9_CSFE_CHICKEN1_RCS),
   ...);

Regards, Joonas



GUC_REG makes it sound like it is somehow related to GuC, while it 
isn't, we just want GuC to restore its value. What about GUC_REG_RESTORE?


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

Re: [Intel-gfx] [PATCH i-g-t v4] benchmarks/gem_wsim: Command submission workload simulator

[Chris Wilson]

On Thu, Apr 20, 2017 at 01:29:11PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> +static void
> +run_workload(unsigned int id, struct workload *wrk, unsigned int repeat,
> +  enum intel_engine_id (*balance)(struct workload *wrk,
> +  struct w_step *w),
> +  unsigned int flags)
> +{
> + struct timespec t_start, t_end;
> + struct w_step *w;
> + double t;
> + int i, j;
> +
> + clock_gettime(CLOCK_MONOTONIC, _start);
> +
> + srand(t_start.tv_nsec);

Let's supply the seed with the workload specification. And use a
portable prng so we can be sure we can reproduce results from one system
to the next.
-Chris

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

Re: [Intel-gfx] [PATCH i-g-t v4] benchmarks/gem_wsim: Command submission workload simulator

[Chris Wilson]

On Thu, Apr 20, 2017 at 03:34:56PM +0100, Tvrtko Ursulin wrote:
> 
> On 20/04/2017 15:23, Chris Wilson wrote:
> >On Thu, Apr 20, 2017 at 01:29:11PM +0100, Tvrtko Ursulin wrote:
> >>+static void
> >>+alloc_step_batch(struct workload *wrk, struct w_step *w, struct w_step_eb 
> >>*b,
> >>+enum intel_engine_id engine, unsigned int flags)
> >>+{
> >>+   unsigned int bb_i, j = 0;
> >>+
> >>+   b->obj[j].handle = gem_create(fd, 4096);
> >>+   b->obj[j].flags = EXEC_OBJECT_WRITE;
> >>+   j++;
> >>+
> >>+   if (flags & SEQNO) {
> >>+   b->obj[j].handle = wrk->status_page_handle;
> >>+   j++;
> >>+   }
> >>+
> >>+   bb_i = j++;
> >>+   b->bb_sz = get_bb_sz(w->duration.max);
> >>+   b->bb_handle = b->obj[bb_i].handle = gem_create(fd, b->bb_sz);
> >>+   terminate_bb(w, b, engine, flags);
> >>+
> >>+   igt_assert(w->dependency <= 0);
> >>+   if (w->dependency) {
> >>+   int dep_idx = w->idx + w->dependency;
> >>+
> >>+   igt_assert(dep_idx >= 0 && dep_idx < wrk->nr_steps);
> >>+   igt_assert(wrk->steps[dep_idx].type == BATCH);
> >>+
> >>+   b->obj[j].handle = b->obj[bb_i].handle;
> >>+   bb_i = j;
> >>+   b->obj[j - 1].handle = wrk->steps[dep_idx].b[0].obj[0].handle;
> >>+   j++;
> >>+
> >>+   if (wrk->steps[dep_idx].b[1].obj[0].handle) {
> >>+   b->obj[j].handle = b->obj[bb_i].handle;
> >>+   bb_i = j;
> >>+   b->obj[j - 1].handle =
> >>+   wrk->steps[dep_idx].b[1].obj[0].handle;
> >>+   j++;
> >>+   }
> >>+   }
> >>+
> >>+   if (flags & SEQNO) {
> >>+   b->reloc.presumed_offset = -1;
> >
> >So as I understand it, you are caching the execbuf/obj/reloc for the
> >workload and then may reissue later with different seqno on different
> >rings? In which case we have a problem as the kernel will write back the >
> >
> >updated offsets to b->reloc.presumed_offset and b->obj[].offset and in
> >future passes they will match and the seqno write will go into the wrong
> >slot (if it swaps rings).
> >
> >You either want to reset presumed_offset=-1 each time, or better for all
> >concerned write the correct address alongside the seqno (which also
> >enables NORELOC).
> >
> >Delta incoming.
> 
> Only the seqno changes, but each engine has its own eb/obj/reloc. So
> I think there is no problem. Or is there still?

bb_handle is per engine as well. Ugh. No, that seems like you are
self-consistent, you just need to remove the -1 and your code is NORELOC
correct.

I wouldn't go so far as having entirely separate batches for each engine
though :)
-Chris

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

Re: [Intel-gfx] [PATCH i-g-t v4] benchmarks/gem_wsim: Command submission workload simulator

[Tvrtko Ursulin]

On 20/04/2017 15:52, Chris Wilson wrote:

On Thu, Apr 20, 2017 at 01:29:11PM +0100, Tvrtko Ursulin wrote:

+   wrk->nr_bb[engine]++;
+
+   if (engine == VCS && balance) {
+   engine = balance(wrk, w);
+   wrk->nr_bb[engine]++;
+   b = >b[engine - VCS1];
+
+   if (flags & SEQNO)
+   update_bb_seqno(b, engine,
+   ++wrk->seqno[engine]);
+   }
+
+   if (w->duration.min != w->duration.max) {
+   unsigned int d = get_duration(>duration);
+   unsigned long offset;
+
+   offset = ALIGN(b->bb_sz - get_bb_sz(d),
+  2 * sizeof(uint32_t));
+   b->eb.batch_start_offset = offset;
+   }
+
+   gem_execbuf(fd, >eb);


Likely double counting wrk->nr_bb. I suggest placing it next to the
gem_execbuf().


Just convenience in balancing mode so that nr(VCS) = nr(VCS1) + 
nr(VCS2). Also from a different angle, if the sum does not hold, that 
means workload had auto-balancing and explicit VCS1/2 batches. It's only 
used to print out the stats at the end of the run.


Regards,

Tvrtko

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

Re: [Intel-gfx] [PATCH 13/27] drm/i915/execlists: Pack the count into the low bits of the port.request

[Tvrtko Ursulin]

On 19/04/2017 10:41, Chris Wilson wrote:

add/remove: 1/1 grow/shrink: 5/4 up/down: 391/-578 (-187)
function old new   delta
execlists_submit_ports   262 471+209
port_assign.isra   - 136+136
capture 63446359 +15
reset_common_ring438 452 +14
execlists_submit_request 228 238 +10
gen8_init_common_ring334 341  +7
intel_engine_is_idle 106 105  -1
i915_engine_info23142290 -24
__i915_gem_set_wedged_BKL485 411 -74
intel_lrc_irq_handler   17891604-185
execlists_update_context 294   --294

The most important change there is the improve to the
intel_lrc_irq_handler and excclist_submit_ports (net improvement since
execlists_update_context is now inlined).

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  32 ---
 drivers/gpu/drm/i915/i915_gem.c|   6 +-
 drivers/gpu/drm/i915/i915_gpu_error.c  |  13 ++-
 drivers/gpu/drm/i915/i915_guc_submission.c |  18 ++--
 drivers/gpu/drm/i915/intel_engine_cs.c |   2 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 133 -
 drivers/gpu/drm/i915/intel_ringbuffer.h|   8 +-
 7 files changed, 120 insertions(+), 92 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 870c470177b5..0b5d7142d8d9 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3315,6 +3315,7 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
if (i915.enable_execlists) {
u32 ptr, read, write;
struct rb_node *rb;
+   unsigned int idx;

seq_printf(m, "\tExeclist status: 0x%08x %08x\n",
   I915_READ(RING_EXECLIST_STATUS_LO(engine)),
@@ -3332,8 +,7 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
if (read > write)
write += GEN8_CSB_ENTRIES;
while (read < write) {
-   unsigned int idx = ++read % GEN8_CSB_ENTRIES;
-
+   idx = ++read % GEN8_CSB_ENTRIES;
seq_printf(m, "\tExeclist CSB[%d]: 0x%08x, context: 
%d\n",
   idx,
   
I915_READ(RING_CONTEXT_STATUS_BUF_LO(engine, idx)),
@@ -3341,21 +3341,19 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
}

rcu_read_lock();
-   rq = READ_ONCE(engine->execlist_port[0].request);
-   if (rq) {
-   seq_printf(m, "\t\tELSP[0] count=%d, ",
-  engine->execlist_port[0].count);
-   print_request(m, rq, "rq: ");
-   } else {
-   seq_printf(m, "\t\tELSP[0] idle\n");
-   }
-   rq = READ_ONCE(engine->execlist_port[1].request);
-   if (rq) {
-   seq_printf(m, "\t\tELSP[1] count=%d, ",
-  engine->execlist_port[1].count);
-   print_request(m, rq, "rq: ");
-   } else {
-   seq_printf(m, "\t\tELSP[1] idle\n");
+   for (idx = 0; idx < ARRAY_SIZE(engine->execlist_port); 
idx++) {
+   unsigned int count;
+
+   rq = port_unpack(>execlist_port[idx],
+);
+   if (rq) {
+   seq_printf(m, "\t\tELSP[%d] count=%d, ",
+  idx, count);
+   print_request(m, rq, "rq: ");
+   } else {
+   seq_printf(m, "\t\tELSP[%d] idle\n",
+  idx);
+   }
}
rcu_read_unlock();

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2bc72314cdd1..f6df402a5247 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3039,12 +3039,14 @@ static void engine_set_wedged(struct intel_engine_cs 

Re: [Intel-gfx] [PATCH i-g-t v4] benchmarks/gem_wsim: Command submission workload simulator

[Chris Wilson]

On Thu, Apr 20, 2017 at 01:29:11PM +0100, Tvrtko Ursulin wrote:
> + wrk->nr_bb[engine]++;
> +
> + if (engine == VCS && balance) {
> + engine = balance(wrk, w);
> + wrk->nr_bb[engine]++;
> + b = >b[engine - VCS1];
> +
> + if (flags & SEQNO)
> + update_bb_seqno(b, engine,
> + ++wrk->seqno[engine]);
> + }
> +
> + if (w->duration.min != w->duration.max) {
> + unsigned int d = get_duration(>duration);
> + unsigned long offset;
> +
> + offset = ALIGN(b->bb_sz - get_bb_sz(d),
> +2 * sizeof(uint32_t));
> + b->eb.batch_start_offset = offset;
> + }
> +
> + gem_execbuf(fd, >eb);

Likely double counting wrk->nr_bb. I suggest placing it next to the
gem_execbuf().
-Chris

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

Re: [Intel-gfx] [PATCH v4] drm: Add DPCD definitions for DP 1.4 DSC feature

[Jani Nikula]

On Tue, 04 Apr 2017, Manasi Navare  wrote:
> From: "Navare, Manasi D" 
>
> Display stream compression is supported on DP 1.4 DP
> devices. This patch adds the corersponding DPCD
> register definitions for DSC.
>
> v4:
> * Add DSC Enable DPCD register def (Ander)
> v3:
> * Add some SHIFTS and MASKS for uniformity (Jani Nikula)
> v2:
> * Rebased on drm-tip
>
> Signed-off-by: Manasi Navare 
> Cc: Jani Nikula 
> Cc: Paulo Zanoni 
> Cc: dri-de...@lists.freedesktop.org

Pushed to drm-misc-next, thanks for the patch.

BR,
Jani.


> ---
>  include/drm/drm_dp_helper.h | 107 
> 
>  1 file changed, 107 insertions(+)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index c0bd0d7..f6258ed 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -179,6 +179,111 @@
>  
>  #define DP_GUID  0x030   /* 1.2 */
>  
> +#define DP_DSC_SUPPORT  0x060   /* DP 1.4 */
> +# define DP_DSC_DECOMPRESSION_IS_SUPPORTED  (1 << 0)
> +
> +#define DP_DSC_REV  0x061
> +# define DP_DSC_MAJOR_MASK  (0xf << 0)
> +# define DP_DSC_MINOR_MASK  (0xf << 4)
> +# define DP_DSC_MAJOR_SHIFT 0
> +# define DP_DSC_MINOR_SHIFT 4
> +
> +#define DP_DSC_RC_BUF_BLK_SIZE  0x062
> +# define DP_DSC_RC_BUF_BLK_SIZE_1   0x0
> +# define DP_DSC_RC_BUF_BLK_SIZE_4   0x1
> +# define DP_DSC_RC_BUF_BLK_SIZE_16  0x2
> +# define DP_DSC_RC_BUF_BLK_SIZE_64  0x3
> +
> +#define DP_DSC_RC_BUF_SIZE  0x063
> +
> +#define DP_DSC_SLICE_CAP_1  0x064
> +# define DP_DSC_1_PER_DP_DSC_SINK   (1 << 0)
> +# define DP_DSC_2_PER_DP_DSC_SINK   (1 << 1)
> +# define DP_DSC_4_PER_DP_DSC_SINK   (1 << 3)
> +# define DP_DSC_6_PER_DP_DSC_SINK   (1 << 4)
> +# define DP_DSC_8_PER_DP_DSC_SINK   (1 << 5)
> +# define DP_DSC_10_PER_DP_DSC_SINK  (1 << 6)
> +# define DP_DSC_12_PER_DP_DSC_SINK  (1 << 7)
> +
> +#define DP_DSC_LINE_BUF_BIT_DEPTH   0x065
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_MASK (0xf << 0)
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_90x0
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_10   0x1
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_11   0x2
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_12   0x3
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_13   0x4
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_14   0x5
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_15   0x6
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_16   0x7
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_80x8
> +
> +#define DP_DSC_BLK_PREDICTION_SUPPORT   0x066
> +# define DP_DSC_BLK_PREDICTION_IS_SUPPORTED (1 << 0)
> +
> +#define DP_DSC_MAX_BITS_PER_PIXEL_LOW   0x067   /* eDP 1.4 */
> +
> +#define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068   /* eDP 1.4 */
> +
> +#define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069
> +# define DP_DSC_RGB (1 << 0)
> +# define DP_DSC_YCbCr444(1 << 1)
> +# define DP_DSC_YCbCr422_Simple (1 << 2)
> +# define DP_DSC_YCbCr422_Native (1 << 3)
> +# define DP_DSC_YCbCr420_Native (1 << 4)
> +
> +#define DP_DSC_DEC_COLOR_DEPTH_CAP  0x06A
> +# define DP_DSC_8_BPC   (1 << 1)
> +# define DP_DSC_10_BPC  (1 << 2)
> +# define DP_DSC_12_BPC  (1 << 3)
> +
> +#define DP_DSC_PEAK_THROUGHPUT  0x06B
> +# define DP_DSC_THROUGHPUT_MODE_0_MASK  (0xf << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_SHIFT 0
> +# define DP_DSC_THROUGHPUT_MODE_0_340   (1 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_400   (2 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_450   (3 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_500   (4 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_550   (5 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_600   (6 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_650   (7 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_700   (8 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_750   (9 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_800   (10 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_850   (11 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_900   (12 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_950   (13 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_1000  (14 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_1_MASK  (0xf << 4)
> +# define DP_DSC_THROUGHPUT_MODE_1_SHIFT 4
> +# define DP_DSC_THROUGHPUT_MODE_1_340   (1 << 4)
> +# define DP_DSC_THROUGHPUT_MODE_1_400   (2 << 4)
> +# define DP_DSC_THROUGHPUT_MODE_1_450   (3 << 4)
> +# define DP_DSC_THROUGHPUT_MODE_1_500   (4 << 4)
> +# define DP_DSC_THROUGHPUT_MODE_1_550   (5 << 4)
> +# define 

Re: [Intel-gfx] [PATCH i-g-t v4] benchmarks/gem_wsim: Command submission workload simulator

[Tvrtko Ursulin]

On 20/04/2017 15:33, Chris Wilson wrote:

On Thu, Apr 20, 2017 at 03:23:27PM +0100, Chris Wilson wrote:

You either want to reset presumed_offset=-1 each time, or better for all
concerned write the correct address alongside the seqno (which also
enables NORELOC).

Delta incoming.


See attached.

Next concern is that I have full rings which implies that we are not
waiting on each batch before resubmitting with a new seqno?

If I throw a assert(!busy(batch_bo)) before the *b->mapped_seqno am I
going to be upset?


Yes you would. :) I had a sync (as a move to cpu domain) before seqno 
update in the last version but it disappeared as I was fixing the whole 
area of seqno tracking. So the balancing results in the patch are bogus 
since the seqno can jump to latest ahead of the time...


Regards,

Tvrtko

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

Re: [Intel-gfx] [PATCH i-g-t v4] benchmarks/gem_wsim: Command submission workload simulator

[Tvrtko Ursulin]

On 20/04/2017 15:23, Chris Wilson wrote:

On Thu, Apr 20, 2017 at 01:29:11PM +0100, Tvrtko Ursulin wrote:

+static void
+alloc_step_batch(struct workload *wrk, struct w_step *w, struct w_step_eb *b,
+enum intel_engine_id engine, unsigned int flags)
+{
+   unsigned int bb_i, j = 0;
+
+   b->obj[j].handle = gem_create(fd, 4096);
+   b->obj[j].flags = EXEC_OBJECT_WRITE;
+   j++;
+
+   if (flags & SEQNO) {
+   b->obj[j].handle = wrk->status_page_handle;
+   j++;
+   }
+
+   bb_i = j++;
+   b->bb_sz = get_bb_sz(w->duration.max);
+   b->bb_handle = b->obj[bb_i].handle = gem_create(fd, b->bb_sz);
+   terminate_bb(w, b, engine, flags);
+
+   igt_assert(w->dependency <= 0);
+   if (w->dependency) {
+   int dep_idx = w->idx + w->dependency;
+
+   igt_assert(dep_idx >= 0 && dep_idx < wrk->nr_steps);
+   igt_assert(wrk->steps[dep_idx].type == BATCH);
+
+   b->obj[j].handle = b->obj[bb_i].handle;
+   bb_i = j;
+   b->obj[j - 1].handle = wrk->steps[dep_idx].b[0].obj[0].handle;
+   j++;
+
+   if (wrk->steps[dep_idx].b[1].obj[0].handle) {
+   b->obj[j].handle = b->obj[bb_i].handle;
+   bb_i = j;
+   b->obj[j - 1].handle =
+   wrk->steps[dep_idx].b[1].obj[0].handle;
+   j++;
+   }
+   }
+
+   if (flags & SEQNO) {
+   b->reloc.presumed_offset = -1;


So as I understand it, you are caching the execbuf/obj/reloc for the
workload and then may reissue later with different seqno on different
rings? In which case we have a problem as the kernel will write back the >

>

updated offsets to b->reloc.presumed_offset and b->obj[].offset and in
future passes they will match and the seqno write will go into the wrong
slot (if it swaps rings).

You either want to reset presumed_offset=-1 each time, or better for all
concerned write the correct address alongside the seqno (which also
enables NORELOC).

Delta incoming.


Only the seqno changes, but each engine has its own eb/obj/reloc. So I 
think there is no problem. Or is there still?


Regards,

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

Re: [Intel-gfx] [PATCH i-g-t v4] benchmarks/gem_wsim: Command submission workload simulator

[Chris Wilson]

On Thu, Apr 20, 2017 at 03:23:27PM +0100, Chris Wilson wrote:
> You either want to reset presumed_offset=-1 each time, or better for all
> concerned write the correct address alongside the seqno (which also
> enables NORELOC).
> 
> Delta incoming.

See attached.

Next concern is that I have full rings which implies that we are not
waiting on each batch before resubmitting with a new seqno?

If I throw a assert(!busy(batch_bo)) before the *b->mapped_seqno am I
going to be upset?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
>From 5bf424c2719e81f926b74f4136610cbdfd26a4d8 Mon Sep 17 00:00:00 2001
From: Chris Wilson 
Date: Thu, 20 Apr 2017 15:30:07 +0100
Subject: [PATCH] seqno-reloc

---
 benchmarks/gem_wsim.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index adf2d6de..e616335b 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -45,6 +45,8 @@
 #include "drmtest.h"
 #include "intel_io.h"
 
+#define LOCAL_I915_GEM_DOMAIN_WC 0x80
+
 enum intel_engine_id {
 	RCS,
 	BCS,
@@ -86,7 +88,9 @@ struct w_step
 		struct drm_i915_gem_relocation_entry reloc;
 		unsigned long bb_sz;
 		uint32_t bb_handle;
-		uint32_t *mapped_batch, *mapped_seqno;
+		uint32_t *mapped_batch;
+		uint64_t *mapped_address;
+		uint32_t *mapped_seqno;
 		unsigned int mapped_len;
 	} b[2]; /* One for each VCS when load balancing */
 };
@@ -405,7 +409,8 @@ terminate_bb(struct w_step *w, struct w_step_eb *b, enum intel_engine_id engine,
 	mmap_len += cmd_offset - mmap_start;
 
 	gem_set_domain(fd, b->bb_handle,
-		   I915_GEM_DOMAIN_CPU, I915_GEM_DOMAIN_CPU);
+		   LOCAL_I915_GEM_DOMAIN_WC,
+		   LOCAL_I915_GEM_DOMAIN_WC);
 
 	ptr = gem_mmap__wc(fd, b->bb_handle, mmap_start, mmap_len, PROT_WRITE);
 	cs = (uint32_t *)((char *)ptr + cmd_offset - mmap_start);
@@ -415,6 +420,7 @@ terminate_bb(struct w_step *w, struct w_step_eb *b, enum intel_engine_id engine,
 		b->reloc.delta = (engine - VCS1) * sizeof(uint32_t);
 
 		*cs++ = MI_STORE_DWORD_IMM;
+		b->mapped_address = (uint64_t *)cs;
 		*cs++ = 0;
 		*cs++ = 0;
 		b->mapped_seqno = cs;
@@ -469,7 +475,6 @@ alloc_step_batch(struct workload *wrk, struct w_step *w, struct w_step_eb *b,
 	}
 
 	if (flags & SEQNO) {
-		b->reloc.presumed_offset = -1;
 		b->reloc.target_handle = 1;
 		b->obj[bb_i].relocs_ptr = to_user_pointer(>reloc);
 		b->obj[bb_i].relocation_count = 1;
@@ -485,8 +490,7 @@ alloc_step_batch(struct workload *wrk, struct w_step *w, struct w_step_eb *b,
 		engine = VCS1;
 	b->eb.flags = eb_engine_map[engine];
 	b->eb.flags |= I915_EXEC_HANDLE_LUT;
-	if (!(flags & SEQNO))
-		b->eb.flags |= I915_EXEC_NO_RELOC;
+	b->eb.flags |= I915_EXEC_NO_RELOC;
 #ifdef DEBUG
 	printf("%u: %u:%x|%x|%x|%x %10lu flags=%llx bb=%x[%u] ctx[%u]=%u\n",
 		w->idx, b->eb.buffer_count, b->obj[0].handle,
@@ -628,8 +632,9 @@ static void
 update_bb_seqno(struct w_step_eb *b, enum intel_engine_id engine,
 		uint32_t seqno)
 {
-	*b->mapped_seqno = seqno;
 	b->reloc.delta = (engine - VCS1) * sizeof(uint32_t);
+	*b->mapped_address = b->reloc.presumed_offset + b->reloc.delta;
+	*b->mapped_seqno = seqno;
 }
 
 static void
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH i-g-t v4] benchmarks/gem_wsim: Command submission workload simulator

[Chris Wilson]

On Thu, Apr 20, 2017 at 01:29:11PM +0100, Tvrtko Ursulin wrote:
> +static void
> +alloc_step_batch(struct workload *wrk, struct w_step *w, struct w_step_eb *b,
> +  enum intel_engine_id engine, unsigned int flags)
> +{
> + unsigned int bb_i, j = 0;
> +
> + b->obj[j].handle = gem_create(fd, 4096);
> + b->obj[j].flags = EXEC_OBJECT_WRITE;
> + j++;
> +
> + if (flags & SEQNO) {
> + b->obj[j].handle = wrk->status_page_handle;
> + j++;
> + }
> +
> + bb_i = j++;
> + b->bb_sz = get_bb_sz(w->duration.max);
> + b->bb_handle = b->obj[bb_i].handle = gem_create(fd, b->bb_sz);
> + terminate_bb(w, b, engine, flags);
> +
> + igt_assert(w->dependency <= 0);
> + if (w->dependency) {
> + int dep_idx = w->idx + w->dependency;
> +
> + igt_assert(dep_idx >= 0 && dep_idx < wrk->nr_steps);
> + igt_assert(wrk->steps[dep_idx].type == BATCH);
> +
> + b->obj[j].handle = b->obj[bb_i].handle;
> + bb_i = j;
> + b->obj[j - 1].handle = wrk->steps[dep_idx].b[0].obj[0].handle;
> + j++;
> +
> + if (wrk->steps[dep_idx].b[1].obj[0].handle) {
> + b->obj[j].handle = b->obj[bb_i].handle;
> + bb_i = j;
> + b->obj[j - 1].handle =
> + wrk->steps[dep_idx].b[1].obj[0].handle;
> + j++;
> + }
> + }
> +
> + if (flags & SEQNO) {
> + b->reloc.presumed_offset = -1;

So as I understand it, you are caching the execbuf/obj/reloc for the
workload and then may reissue later with different seqno on different
rings? In which case we have a problem as the kernel will write back the
updated offsets to b->reloc.presumed_offset and b->obj[].offset and in
future passes they will match and the seqno write will go into the wrong
slot (if it swaps rings).

You either want to reset presumed_offset=-1 each time, or better for all
concerned write the correct address alongside the seqno (which also
enables NORELOC).

Delta incoming.
-Chris

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

Re: [Intel-gfx] [PATCH 12/27] drm/i915: Only report a wakeup if the waiter was truly asleep

[Chris Wilson]

On Thu, Apr 20, 2017 at 02:30:21PM +0100, Tvrtko Ursulin wrote:
> 
> On 19/04/2017 10:41, Chris Wilson wrote:
> >If we attempt to wake up a waiter, who is currently checking the seqno
> >it will be in the TASK_INTERRUPTIBLE state and ttwu will report success.
> >However, it is actually awake and functioning -- so delay reporting the
> >actual wake up until it sleeps.
> >
> >v2: Defend against !CONFIG_SMP
> >v3: Don't filter out calls to wake_up_process

I forgot this patch was inbetween the series, i.e. I am not pursuing
this one at the moment.

> >References: https://bugs.freedesktop.org/show_bug.cgi?id=17
> >Signed-off-by: Chris Wilson 
> >Cc: Tvrtko Ursulin 
> >Cc: Joonas Lahtinen 
> >---
> > drivers/gpu/drm/i915/intel_breadcrumbs.c | 18 --
> > drivers/gpu/drm/i915/intel_ringbuffer.h  |  4 
> > 2 files changed, 20 insertions(+), 2 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
> >b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> >index 9ccbf26124c6..808d3a3cda0a 100644
> >--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
> >+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> >@@ -27,6 +27,12 @@
> >
> > #include "i915_drv.h"
> >
> >+#ifdef CONFIG_SMP
> >+#define task_asleep(tsk) (!(tsk)->on_cpu)
> >+#else
> >+#define task_asleep(tsk) ((tsk) != current)
> >+#endif
> >+
> > static unsigned int __intel_breadcrumbs_wakeup(struct intel_breadcrumbs *b)
> > {
> > struct intel_wait *wait;
> >@@ -37,8 +43,16 @@ static unsigned int __intel_breadcrumbs_wakeup(struct 
> >intel_breadcrumbs *b)
> > wait = b->irq_wait;
> > if (wait) {
> > result = ENGINE_WAKEUP_WAITER;
> >-if (wake_up_process(wait->tsk))
> >+
> >+/* Be careful not to report a successful wakeup if the waiter
> >+ * is currently processing the seqno, where it will have
> >+ * already called set_task_state(TASK_INTERRUPTIBLE).
> >+ */
> >+if (task_asleep(wait->tsk))
> > result |= ENGINE_WAKEUP_ASLEEP;
> >+
> >+if (wake_up_process(wait->tsk))
> >+result |= ENGINE_WAKEUP_SUCCESS;
> 
> The rough idea I had of atomic_inc(>wakeup_cnt) here with
> unconditional wake_up_process, coupled with atomic_dec_and_test in
> the signaler would not work? I was thinking that would avoid
> signaler losing the wakeup and avoid us having to touch the low
> level scheduler data.

Best one I had was to store an atomic counter in each struct intel_wait
to determine if it was inside the wait-for-breadcrumb. But that is
duplicating on-cpu (with the same advantage of not being confused by any
sleep elsewhere in the check-breadcrumb path) and fundamentally less
precise.

> Or what you meant last time by not sure it was worth it was
> referring to the above?

I think the chance that this is affecting a missed breacrumb result is
small, certainly not with the regularity of snb-2600. I had pushed it to
the end, but obviously not far enough down the list. When I looked at
the list of patches, I actually though this was a different patch
"drm/i915: Only wake the waiter from the interrupt if passed"

My apologies for the noise.
-Chris

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

Re: [Intel-gfx] [PATCH 12/27] drm/i915: Only report a wakeup if the waiter was truly asleep

[Tvrtko Ursulin]

On 19/04/2017 10:41, Chris Wilson wrote:

If we attempt to wake up a waiter, who is currently checking the seqno
it will be in the TASK_INTERRUPTIBLE state and ttwu will report success.
However, it is actually awake and functioning -- so delay reporting the
actual wake up until it sleeps.

v2: Defend against !CONFIG_SMP
v3: Don't filter out calls to wake_up_process

References: https://bugs.freedesktop.org/show_bug.cgi?id=17
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 18 --
 drivers/gpu/drm/i915/intel_ringbuffer.h  |  4 
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 9ccbf26124c6..808d3a3cda0a 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -27,6 +27,12 @@

 #include "i915_drv.h"

+#ifdef CONFIG_SMP
+#define task_asleep(tsk) (!(tsk)->on_cpu)
+#else
+#define task_asleep(tsk) ((tsk) != current)
+#endif
+
 static unsigned int __intel_breadcrumbs_wakeup(struct intel_breadcrumbs *b)
 {
struct intel_wait *wait;
@@ -37,8 +43,16 @@ static unsigned int __intel_breadcrumbs_wakeup(struct 
intel_breadcrumbs *b)
wait = b->irq_wait;
if (wait) {
result = ENGINE_WAKEUP_WAITER;
-   if (wake_up_process(wait->tsk))
+
+   /* Be careful not to report a successful wakeup if the waiter
+* is currently processing the seqno, where it will have
+* already called set_task_state(TASK_INTERRUPTIBLE).
+*/
+   if (task_asleep(wait->tsk))
result |= ENGINE_WAKEUP_ASLEEP;
+
+   if (wake_up_process(wait->tsk))
+   result |= ENGINE_WAKEUP_SUCCESS;


The rough idea I had of atomic_inc(>wakeup_cnt) here with 
unconditional wake_up_process, coupled with atomic_dec_and_test in the 
signaler would not work? I was thinking that would avoid signaler losing 
the wakeup and avoid us having to touch the low level scheduler data.


Or what you meant last time by not sure it was worth it was referring to 
the above?


Regards,

Tvrtko


}

return result;
@@ -98,7 +112,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
 * but we still have a waiter. Assuming all batches complete within
 * DRM_I915_HANGCHECK_JIFFIES [1.5s]!
 */
-   if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP) {
+   if (intel_engine_wakeup(engine) == ENGINE_WAKEUP) {
missed_breadcrumb(engine);
mod_timer(>breadcrumbs.fake_irq, jiffies + 1);
} else {
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 00d36aa4e26d..d25b88467e5e 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -668,6 +668,10 @@ static inline bool intel_engine_has_waiter(const struct 
intel_engine_cs *engine)
 unsigned int intel_engine_wakeup(struct intel_engine_cs *engine);
 #define ENGINE_WAKEUP_WAITER BIT(0)
 #define ENGINE_WAKEUP_ASLEEP BIT(1)
+#define ENGINE_WAKEUP_SUCCESS BIT(2)
+#define ENGINE_WAKEUP (ENGINE_WAKEUP_WAITER | \
+  ENGINE_WAKEUP_ASLEEP | \
+  ENGINE_WAKEUP_SUCCESS)

 void __intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine);
 void intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine);


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

[Intel-gfx] [PATCH i-g-t v4] benchmarks/gem_wsim: Command submission workload simulator

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Tool which emits batch buffers to engines with configurable
sequences, durations, contexts, dependencies and userspace waits.

Unfinished but shows promise so sending out for early feedback.

v2:
 * Load workload descriptors from files. (also -w)
 * Help text.
 * Calibration control if needed. (-t)
 * NORELOC | LUT to eb flags.
 * Added sample workload to wsim/workload1.

v3:
 * Multiple parallel different workloads (-w -w ...).
 * Multi-context workloads.
 * Variable (random) batch length.
 * Load balancing (round robin and queue depth estimation).
 * Workloads delays and explicit sync steps.
 * Workload frequency (period) control.

v4:
 * Fixed queue-depth estimation by creating separate batches
   per engine when qd load balancing is on.
 * Dropped separate -s cmd line option. It can turn itself on
   automatically when needed.
 * Keep a single status page and lie about the write hazard
   as suggested by Chris.
 * Use batch_start_offset for controlling the batch duration.
   (Chris)
 * Set status page object cache level. (Chris)
 * Moved workload description to a README.
 * Tidied example workloads.
 * Some other cleanups and refactorings.

TODO list:

 * Fence support.
 * Better error handling.
 * Less 1980's workload parsing.
 * Proper workloads.
 * Threads?
 * ... ?

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: "Rogozhkin, Dmitry V" 
---

Comparing some test workloads under load balancing it seems that it is starting
to work, but it still needs more thorough verification. For example, round-
robin balancing:

# benchmarks/gem_wsim -n 585341 \
  -w benchmarks/wsim/vcs1.wsim \
  -w benchmarks/wsim/vcs_balanced.wsim \
  -r 100 -b 0
Using 585341 nop calibration for 1000us delay.
2 clients.
1: 3.008s elapsed (33.243 workloads/s). 2500 (1250 + 1250) total VCS batches.
0: 4.455s elapsed (22.449 workloads/s). 0 (2500 + 0) total VCS batches.
4.455s elapsed (44.889 workloads/s)


Versus the queue-depth estimation:

# benchmarks/gem_wsim -n 585341 \
  -w benchmarks/wsim/vcs1.wsim \
  -w benchmarks/wsim/vcs_balanced.wsim \
  -r 100 -b 1
Using 585341 nop calibration for 1000us delay.
2 clients.
1: 2.239s elapsed (44.659 workloads/s). 2500 (837 + 1663) total VCS batches. 
Average queue depths 27.575, 19.285.
0: 4.012s elapsed (24.928 workloads/s). 0 (2500 + 0) total VCS batches. Average 
queue depths -nan, -nan.
4.012s elapsed (49.845 workloads/s)

In both cases we run two workloads, one which only submits to VCS1 and one which
can be load-balanced. The latter gets a ~33% boost with queue-depth estimation,
and the non-balancing workload ~10%.

---
 benchmarks/Makefile.sources  |1 +
 benchmarks/gem_wsim.c| 1014 ++
 benchmarks/wsim/README   |   54 ++
 benchmarks/wsim/media_17i7.wsim  |7 +
 benchmarks/wsim/media_load_balance_17i7.wsim |7 +
 benchmarks/wsim/vcs1.wsim|   25 +
 benchmarks/wsim/vcs_balanced.wsim|   25 +
 7 files changed, 1133 insertions(+)
 create mode 100644 benchmarks/gem_wsim.c
 create mode 100644 benchmarks/wsim/README
 create mode 100644 benchmarks/wsim/media_17i7.wsim
 create mode 100644 benchmarks/wsim/media_load_balance_17i7.wsim
 create mode 100644 benchmarks/wsim/vcs1.wsim
 create mode 100644 benchmarks/wsim/vcs_balanced.wsim

diff --git a/benchmarks/Makefile.sources b/benchmarks/Makefile.sources
index 3af54ebe36f2..3a941150abb3 100644
--- a/benchmarks/Makefile.sources
+++ b/benchmarks/Makefile.sources
@@ -14,6 +14,7 @@ benchmarks_prog_list =\
gem_prw \
gem_set_domain  \
gem_syslatency  \
+   gem_wsim\
kms_vblank  \
prime_lookup\
vgem_mmap   \
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
new file mode 100644
index ..adf2d6decf12
--- /dev/null
+++ b/benchmarks/gem_wsim.c
@@ -0,0 +1,1014 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Use discardable buffers for rings

[Chris Wilson]

On Thu, Apr 20, 2017 at 10:49:37AM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Use discardable buffers for rings
> URL   : https://patchwork.freedesktop.org/series/23274/
> State : failure
> 
> == Summary ==
> 
> Series 23274v1 drm/i915: Use discardable buffers for rings
> https://patchwork.freedesktop.org/api/1.0/series/23274/revisions/1/mbox/
> 
> Test gem_exec_flush:
> Subgroup basic-batch-kernel-default-uc:
> pass   -> FAIL   (fi-snb-2600) fdo#17
> Test gem_exec_suspend:
> Subgroup basic-s4-devices:
> dmesg-warn -> PASS   (fi-snb-2600) fdo#100125
> pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125
> Test kms_cursor_legacy:
> Subgroup basic-busy-flip-before-cursor-atomic:
> pass   -> FAIL   (fi-snb-2600)
> Test pm_rpm:
> Subgroup basic-rte:
> incomplete -> PASS   (fi-bsw-n3050) fdo#100718
> 
> fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
> fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
> fdo#100718 https://bugs.freedesktop.org/show_bug.cgi?id=100718

Looks scarier than it actually was. Fixed my typos in the commitmsg and
pushed. Thanks for the review, I thought we had been using internal for
rings ever since we added the internal allocator (that was one of the
intended use cases for the allocator).
-Chris

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

Re: [Intel-gfx] [PATCH v6 13/20] drm/i915/guc: Provide register list to be saved/restored during engine reset

[Joonas Lahtinen]

On ke, 2017-04-19 at 11:35 -0700, Michel Thierry wrote:
> From: Arun Siluvery 
> 
> GuC expects a list of registers from the driver which are saved/restored
> during engine reset. The type of value to be saved is controlled by
> flags. We provide a minimal set of registers that we want GuC to save and
> restore. This is not an issue in case of engine reset as driver initializes
> most of them following an engine reset, but in case of media reset (aka
> watchdog reset) which is completely internal to GuC (including resubmission
> of hung workload), it is necessary to provide this list, otherwise GuC won't
> be able to schedule further workloads after a reset. This is the minimal
> set of registers identified for things to work as expected but if we see
> any new issues, this register list can be expanded.
> 
> In order to not loose any existing workarounds, we have to let GuC know
> the registers and its values. These will be reapplied after the reset.
> Note that we can't just read the current value because most of these
> registers are masked (so we have a workaround for a workaround for a
> workaround).
> 
> v2: REGSET_MASKED is too difficult for GuC, use REGSET_SAVE_DEFAULT_VALUE
> and current value from RING_MODE reg instead; no need to preserve
> head/tail either, be extra paranoid and save whitelisted registers (Daniele).
> 
> v3: Workarounds added only once during _init_workarounds also have to
> been restored, or we risk loosing them after internal GuC reset
> (Daniele).
> 
> Cc: Daniele Ceraolo Spurio 
> Signed-off-by: Arun Siluvery 
> Signed-off-by: Jeff McGee 
> Signed-off-by: Michel Thierry 



> @@ -732,15 +755,16 @@ static int gen9_init_workarounds(struct intel_engine_cs 
> *engine)
> >     int ret;
>  
>   /* WaConextSwitchWithConcurrentTLBInvalidate:skl,bxt,kbl,glk */
> - I915_WRITE(GEN9_CSFE_CHICKEN1_RCS, 
> _MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE));
> + I915_GUC_REG_WRITE(GEN9_CSFE_CHICKEN1_RCS,
> +    
> _MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE));

To make grepping easier, how about?

I915_WRITE(GUC_REG(GEN9_CSFE_CHICKEN1_RCS),
   ...);

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Use discardable buffers for rings

[Patchwork]

== Series Details ==

Series: drm/i915: Use discardable buffers for rings
URL   : https://patchwork.freedesktop.org/series/23274/
State : failure

== Summary ==

Series 23274v1 drm/i915: Use discardable buffers for rings
https://patchwork.freedesktop.org/api/1.0/series/23274/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-snb-2600) fdo#100125
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
pass   -> FAIL   (fi-snb-2600)
Test pm_rpm:
Subgroup basic-rte:
incomplete -> PASS   (fi-bsw-n3050) fdo#100718

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
fdo#100718 https://bugs.freedesktop.org/show_bug.cgi?id=100718

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:434s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:426s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:570s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:508s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:550s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:497s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:477s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:411s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:410s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:429s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:495s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:486s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:459s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:567s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:454s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:577s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:460s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:494s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:432s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:531s
fi-snb-2600  total:278  pass:247  dwarn:0   dfail:0   fail:2   skip:29  
time:400s

2fe165cbf4b2287276f03e607d17341119203d9d drm-tip: 2017y-04m-20d-09h-46m-54s UTC 
integration manifest
886e8ea drm/i915: Use discardable buffers for rings

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4524/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 03/13] lib/igt_aux: Include unistd.h for gettid() on Android

[Arkadiusz Hiler]

On Wed, Apr 19, 2017 at 05:23:46PM +0300, Jani Nikula wrote:
> On Wed, 19 Apr 2017, Arkadiusz Hiler  wrote:
> > On Wed, Apr 19, 2017 at 03:22:19PM +0300, Jani Nikula wrote:
> >> On Wed, 19 Apr 2017, Arkadiusz Hiler  wrote:
> >> > We define gettid() using syscall() because glibc does not provide a
> >> > wrapper.
> >> >
> >> > Android's bionic got the syscall covered though.
> >> >
> >> > Signed-off-by: Arkadiusz Hiler 
> >> > ---
> >> >  lib/igt_aux.h | 5 +
> >> >  1 file changed, 5 insertions(+)
> >> >
> >> > diff --git a/lib/igt_aux.h b/lib/igt_aux.h
> >> > index e62858e..54b9716 100644
> >> > --- a/lib/igt_aux.h
> >> > +++ b/lib/igt_aux.h
> >> > @@ -43,7 +43,12 @@ extern int num_trash_bos;
> >> >  #define NSEC_PER_SEC (1000*USEC_PER_SEC)
> >> >  
> >> >  /* signal interrupt helpers */
> >> > +#ifdef ANDROID
> >> 
> >> Seems like this should be something like HAVE_GETTID, defined by
> >> configure or by android makefiles?
> >
> > Yeah, but that's not that easy (yet) and that's not the only area which
> > would use it - notice the thing with cairo from the cover letter.
> >
> > config.h is generated in a ugly way for Android - lib/Android.mk does
> > that. Also if you ./configure it stops compiling for Android causing
> > confusing error.
> >
> > Whole area could use some heavy reworking.
> >
> > One approach would be to mimic what other projects do:
> >
> >  * have config_android.h with set of sane #defines (as environment is
> >more static and there is no ac/am)
> >
> >  * don't define HAVE_CONFIG_H and just `-include config_android.h` on...
> >Android
> >
> >  * add gettid() discovery via ac for Linux (I don't think that any
> >libc other than bionic wraps that call though)
> >
> >
> > But that would made a whole series.
> > I would like to go with #ifdef ANDROID for now.
> 
> Fair enough.
> 
> It's just that I cringe seeing #ifdef  instead of #ifdef
> , when  and  are not interchangeable or
> 1:1. For example, glibc might include gettid later.
> 
> BR,
> Jani.

I completetly get that, I had mixed feeling adding the ifdef.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Use discardable buffers for rings

[Joonas Lahtinen]

On to, 2017-04-20 at 11:17 +0100, Chris Wilson wrote:
> The contents of a ring are only valid between HEAD and TAIL, when the
> ring is idle (HEAD == TAIL) we can simply let the pages go under memory
> pressue if they are not pinned by an active context. And new content
> will be written and so the ring will again be valid between HEAD and
> TAIL, everything outside can be discarded.
> 
> Note that we take care of ensuring that we do not reset the HEAD
> backwards following a GPU hang on an idle ring.
> 
> The same precautions are what enable us to use stolen memory for rings.
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 08/13] benchmarks/Android.mk: Add gem_latency to skip list

[Arkadiusz Hiler]

On Wed, Apr 19, 2017 at 05:58:28PM +0100, Chris Wilson wrote:
> On Wed, Apr 19, 2017 at 01:01:50PM +0200, Arkadiusz Hiler wrote:
> > AOSP, as of this commit, does not include libdrm with fence defines.
> 
> Pushed local defines that should keep the benchmark happy.
> 
> Please do reset the configure libdrm requirements to what is available
> on min(Android, debian stable). They should be our compile targets.
> -Chris

Series rebased (sans this patch) cleanly on current master.

Everything compiles just fine :-)

Thanks!

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

[Intel-gfx] [PATCH] drm/i915: Use discardable buffers for rings

[Chris Wilson]

The contents of a ring are only valid between HEAD and TAIL, when the
ring is idle (HEAD == TAIL) we can simply let the pages go under memory
pressue if they are not pinned by an active context. And new content
will be written and so the ring will again be valid between HEAD and
TAIL, everything outside can be discarded.

Note that we take care of ensuring that we do not reset the HEAD
backwards following a GPU hang on an idle ring.

The same precautions are what enable us to use stolen memory for rings.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 7d2e5df61028..0cfffc9b4e8f 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1165,7 +1165,7 @@ intel_ring_create_vma(struct drm_i915_private *dev_priv, 
int size)
 
obj = i915_gem_object_create_stolen(dev_priv, size);
if (!obj)
-   obj = i915_gem_object_create(dev_priv, size);
+   obj = i915_gem_object_create_internal(dev_priv, size);
if (IS_ERR(obj))
return ERR_CAST(obj);
 
-- 
2.11.0

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

Re: [Intel-gfx] [i-g-t PATCH v4 1/2] lib/igt_kms: Add support for 4K and audio HDMI EDID injection.

[Abdiel Janulgue]

On 19.04.2017 11:13, Petri Latvala wrote:

> 
> The only Intel-specific part I can spot is that one chunk where you
> check for at-least-hsw. Is that so you can properly report skip
> instead of fail? It would be good to make this all suitable for
> non-Intel hw.
> 

That is meant to report skip on hardware before HSW - those can't
properly handle 4K anyway. I'm not sure how other older non-intel HW
handles 4K though.

> 
> Anyway, series is
> 
> Reviewed-by: Petri Latvala 
> 
> 

Thanks, pushed!

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

Re: [Intel-gfx] [PATCH v6 14/20] drm/i915/guc: Add support for reset engine using GuC commands

[Chris Wilson]

On Wed, Apr 19, 2017 at 04:22:43PM -0700, Michel Thierry wrote:
> On 19/04/17 03:27, Chris Wilson wrote:
> >On Tue, Apr 18, 2017 at 01:23:29PM -0700, Michel Thierry wrote:
> >>This patch adds per engine reset and recovery (TDR) support when GuC is
> >>used to submit workloads to GPU.
> >>
> >>In the case of i915 directly submission to ELSP, driver manages hang
> >>detection, recovery and resubmission. With GuC submission these tasks
> >>are shared between driver and GuC. i915 is still responsible for detecting
> >>a hang, and when it does it only requests GuC to reset that Engine. GuC
> >>internally manages acquiring forcewake and idling the engine before actually
> >>resetting it.
> >>
> >>Once the reset is successful, i915 takes over again and handles 
> >>resubmission.
> >>The scheduler in i915 knows which requests are pending so after resetting
> >>a engine, pending workloads/requests are resubmitted again.
> >>
> >>v2: s/i915_guc_request_engine_reset/i915_guc_reset_engine/ to match the
> >>non-guc funtion names.
> >>
> >>Signed-off-by: Arun Siluvery 
> >>Signed-off-by: Jeff McGee 
> >>Signed-off-by: Michel Thierry 
> >>---
> >>diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> >>b/drivers/gpu/drm/i915/intel_lrc.c
> >>index 7df278fe492e..6295760098a1 100644
> >>--- a/drivers/gpu/drm/i915/intel_lrc.c
> >>+++ b/drivers/gpu/drm/i915/intel_lrc.c
> >>@@ -1176,14 +1176,15 @@ static int gen8_init_common_ring(struct 
> >>intel_engine_cs *engine)
> >>
> >>/* After a GPU reset, we may have requests to replay */
> >>clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
> >>-   if (!i915.enable_guc_submission && !execlists_elsp_idle(engine)) {
> >>+   if (!execlists_elsp_idle(engine)) {
> >>DRM_DEBUG_DRIVER("Restarting %s from requests [0x%x, 0x%x]\n",
> >> engine->name,
> >> port_seqno(>execlist_port[0]),
> >> port_seqno(>execlist_port[1]));
> >>engine->execlist_port[0].count = 0;
> >>engine->execlist_port[1].count = 0;
> >>-   execlists_submit_ports(engine);
> >>+   if (!dev_priv->guc.execbuf_client)
> >>+   execlists_submit_ports(engine);
> >
> >Not sure what you were intending to do here as this only resets the
> >submission count -- which is not used by guc dequeue. Some merit in the
> >making the code look similar, certainly adds the dbg message but I think
> >it is unrelated to the rest of the patch.
> 
> Yes, it only keeps the same debug message (originally added to check
> it was taking the right path). I can remove if you think it doesn't
> provide anything useful.

Just a small patch by itself, it is only a distraction to the larger
patch.
-Chris

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

Re: [Intel-gfx] [PATCH 14/27] drm/i915: Don't mark an execlists context-switch when idle

[Joonas Lahtinen]

On ke, 2017-04-19 at 10:41 +0100, Chris Wilson wrote:
> If we *know* that the engine is idle, i.e. we have not more contexts in
> lift, we can skip any spurious CSB idle interrupts. These spurious

in flight?

> interrupts seem to arrive long after we assert that the engines are
> completely idle, triggering later assertions:
> 
> [  178.896646] intel_engine_is_idle(bcs): interrupt not handled, irq_posted=2
> [  178.896655] [ cut here ]
> [  178.896658] kernel BUG at drivers/gpu/drm/i915/intel_engine_cs.c:226!
> [  178.896661] invalid opcode:  [#1] SMP
> [  178.896663] Modules linked in: i915(E) x86_pkg_temp_thermal(E) 
> crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) ghash_clmulni_intel(E) 
> nls_ascii(E) nls_cp437(E) vfat(E) fat(E) intel_gtt(E) i2c_algo_bit(E) 
> drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) 
> aesni_intel(E) prime_numbers(E) evdev(E) aes_x86_64(E) drm(E) crypto_simd(E) 
> cryptd(E) glue_helper(E) mei_me(E) mei(E) lpc_ich(E) efivars(E) mfd_core(E) 
> battery(E) video(E) acpi_pad(E) button(E) tpm_tis(E) tpm_tis_core(E) tpm(E) 
> autofs4(E) i2c_i801(E) fan(E) thermal(E) i2c_designware_platform(E) 
> i2c_designware_core(E)
> [  178.896694] CPU: 1 PID: 522 Comm: gem_exec_whispe Tainted: GE  
>  4.11.0-rc5+ #14
> [  178.896702] task: 88040aba8d40 task.stack: c93f
> [  178.896722] RIP: 0010:intel_engine_init_global_seqno+0x1db/0x1f0 [i915]
> [  178.896725] RSP: 0018:c93f3ab0 EFLAGS: 00010246
> [  178.896728] RAX:  RBX: 88040af54000 RCX: 
> 
> [  178.896731] RDX: 88041ec933e0 RSI: 88041ec8cc48 RDI: 
> 88041ec8cc48
> [  178.896734] RBP: c93f3ac8 R08:  R09: 
> 047d
> [  178.896736] R10: 0040 R11: 88040b344f80 R12: 
> 
> [  178.896739] R13: 88040bce R14: 88040bce52d8 R15: 
> 88040bce
> [  178.896742] FS:  7f22d8c0() GS:88041ec8() 
> knlGS:
> [  178.896746] CS:  0010 DS:  ES:  CR0: 80050033
> [  178.896749] CR2: 7f41ddd8f000 CR3: 00040bb03000 CR4: 
> 001406e0
> [  178.896752] Call Trace:
> [  178.896768]  reset_all_global_seqno.part.33+0x4e/0xd0 [i915]
> [  178.896782]  i915_gem_request_alloc+0x304/0x330 [i915]
> [  178.896795]  i915_gem_do_execbuffer+0x8a1/0x17d0 [i915]
> [  178.896799]  ? remove_wait_queue+0x48/0x50
> [  178.896812]  ? i915_wait_request+0x300/0x590 [i915]
> [  178.896816]  ? wake_up_q+0x70/0x70
> [  178.896819]  ? refcount_dec_and_test+0x11/0x20
> [  178.896823]  ? reservation_object_add_excl_fence+0xa5/0x100
> [  178.896835]  i915_gem_execbuffer2+0xab/0x1f0 [i915]
> [  178.896844]  drm_ioctl+0x1e6/0x460 [drm]
> [  178.896858]  ? i915_gem_execbuffer+0x260/0x260 [i915]
> [  178.896862]  ? dput+0xcf/0x250
> [  178.896866]  ? full_proxy_release+0x66/0x80
> [  178.896869]  ? mntput+0x1f/0x30
> [  178.896872]  do_vfs_ioctl+0x8f/0x5b0
> [  178.896875]  ? fput+0x9/0x10
> [  178.896878]  ? task_work_run+0x80/0xa0
> [  178.896881]  SyS_ioctl+0x3c/0x70
> [  178.896885]  entry_SYSCALL_64_fastpath+0x17/0x98
> [  178.896888] RIP: 0033:0x7f2ccb455ca7
> [  178.896890] RSP: 002b:7ffcabec72d8 EFLAGS: 0246 ORIG_RAX: 
> 0010
> [  178.896894] RAX: ffda RBX: 55f897a44b90 RCX: 
> 7f2ccb455ca7
> [  178.896897] RDX: 7ffcabec74a0 RSI: 40406469 RDI: 
> 0003
> [  178.896900] RBP: 7f2ccb70a440 R08: 7f2ccb70d0a4 R09: 
> 
> [  178.896903] R10:  R11: 0246 R12: 
> 
> [  178.896905] R13: 55f89782d71a R14: 7ffcabecf838 R15: 
> 0003
> [  178.896908] Code: 00 31 d2 4c 89 ef 8d 70 48 41 ff 95 f8 06 00 00 e9 68 fe 
> ff ff be 0f 00 00 00 48 c7 c7 48 dc 37 a0 e8 fa 33 d6 e0 e9 0b ff ff ff <0f> 
> 0b 0f 0b 0f 0b 0f 0b 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00
> 
> On the other hand, by ignoring the interrupt do we risk running out of
> space in CSB ring? Testing for a few hours suggests not, i.e. that we
> only seem to get the odd delayed CSB idle notification.
> 
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 

Slap your Tested-by too.

Reviewed-by: Joonas Lahtinen 

Even with that, I dislike the port_count macro.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 18/20] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout

[Chris Wilson]

On Wed, Apr 19, 2017 at 06:09:00PM -0700, Michel Thierry wrote:
> This patch is missing:
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index c1013af0b910..a8bdea43a217 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -1135,7 +1135,7 @@ int i915_gem_context_getparam_ioctl(struct
> drm_device *dev, void *data,
>   return PTR_ERR(ctx);
>   }
> 
> - args->size = 0;
> + args->size = (args->param != I915_CONTEXT_PARAM_WATCHDOG) ? 0 :
> args->size;
>   switch (args->param) {
>   case I915_CONTEXT_PARAM_BAN_PERIOD:
>   ret = -EINVAL;
> 
> Or there will be no way to get the current thresholds (chunk was
> missed due to some TRTT code nearby). I'll be sure to include it in
> the next version.

No. It is always preset to 0. The PARAM should set it to the actual
struct size (it would write) and *not* the user's size.
-Chris

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

Re: [Intel-gfx] [PATCH 22/27] drm/i915: Eliminate lots of iterations over the execobjects array

[Joonas Lahtinen]

On ke, 2017-04-19 at 10:41 +0100, Chris Wilson wrote:
> The major scaling bottleneck in execbuffer is the processing of the
> execobjects. Creating an auxiliary list is inefficient when compared to
> using the execobject array we already have allocated.
> 
> Reservation is then split into phases. As we lookup up the VMA, we
> try and bind it back into active location. Only if that fails, do we add
> it to the unbound list for phase 2. In phase 2, we try and add all those
> objects that could not fit into their previous location, with fallback
> to retrying all objects and evicting the VM in case of severe
> fragmentation. (This is the same as before, except that phase 1 is now
> done inline with looking up the VMA to avoid an iteration over the
> execobject array. In the ideal case, we eliminate the separate reservation
> phase). During the reservation phase, we only evict from the VM between
> passes (rather than currently as we try to fit every new VMA). In
> testing with Unreal Engine's Atlantis demo which stresses the eviction
> logic on gen7 class hardware, this speed up the framerate by a factor of
> 2.
> 
> The second loop amalgamation is between move_to_gpu and move_to_active.
> As we always submit the request, even if incomplete, we can use the
> current request to track active VMA as we perform the flushes and
> synchronisation required.
> 
> The next big advancement is to avoid copying back to the user any
> execobjects and relocations that are not changed.
> 
> v2: Add a Theory of Operation spiel.
> v3: Fall back to slow relocations in preparation for flushing userptrs.
> v4: Document struct members, factor out eb_validate_vma(), add a few
> more comments to explain some magic and hide other magic behind macros.
> 
> Signed-off-by: Chris Wilson 

Changelog checks out. Assuming you peeked at the generated html docs:

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 6/9] drm/i915: Convert intel_dp properties to atomic.

[Maarten Lankhorst]

On 19-04-17 17:53, Daniel Vetter wrote:
> On Wed, Apr 12, 2017 at 12:50:04PM +0200, Maarten Lankhorst wrote:
>> intel_dp supports 3 properties, scaling mode, broadcast rgb and
>> force_audio. intel_digital_connector handles the plumbing,
>> so we only have to hook this up in compute_config and init.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/i915/intel_dp.c  | 136 
>> +++
>>  drivers/gpu/drm/i915/intel_drv.h |   3 -
>>  2 files changed, 24 insertions(+), 115 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index b1a0cb3c79d4..f976d10b4f0a 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -1630,6 +1630,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>>  enum port port = dp_to_dig_port(intel_dp)->port;
>>  struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc);
>>  struct intel_connector *intel_connector = intel_dp->attached_connector;
>> +struct intel_digital_connector_state *intel_conn_state =
>> +to_intel_digital_connector_state(conn_state);
>>  int lane_count, clock;
>>  int min_lane_count = 1;
>>  int max_lane_count = intel_dp_max_lane_count(intel_dp);
>> @@ -1655,10 +1657,10 @@ intel_dp_compute_config(struct intel_encoder 
>> *encoder,
>>  pipe_config->has_drrs = false;
>>  if (port == PORT_A)
>>  pipe_config->has_audio = false;
>> -else if (intel_dp->force_audio == HDMI_AUDIO_AUTO)
>> +else if (intel_conn_state->force_audio == HDMI_AUDIO_AUTO)
>>  pipe_config->has_audio = intel_dp->has_audio;
>>  else
>> -pipe_config->has_audio = intel_dp->force_audio == HDMI_AUDIO_ON;
>> +pipe_config->has_audio = intel_conn_state->force_audio == 
>> HDMI_AUDIO_ON;
>>  
>>  if (is_edp(intel_dp) && intel_connector->panel.fixed_mode) {
>>  intel_fixed_panel_mode(intel_connector->panel.fixed_mode,
>> @@ -1673,10 +1675,10 @@ intel_dp_compute_config(struct intel_encoder 
>> *encoder,
>>  
>>  if (HAS_GMCH_DISPLAY(dev_priv))
>>  intel_gmch_panel_fitting(intel_crtc, pipe_config,
>> - 
>> intel_connector->panel.fitting_mode);
>> + conn_state->scaling_mode);
>>  else
>>  intel_pch_panel_fitting(intel_crtc, pipe_config,
>> -
>> intel_connector->panel.fitting_mode);
>> +conn_state->scaling_mode);
>>  }
>>  
>>  if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
>> @@ -1745,7 +1747,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>>  return false;
>>  
>>  found:
>> -if (intel_dp->color_range_auto) {
>> +if (intel_conn_state->broadcast_rgb == INTEL_BROADCAST_RGB_AUTO) {
>>  /*
>>   * See:
>>   * CEA-861-E - 5.1 Default Encoding Parameters
>> @@ -1757,7 +1759,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>>  HDMI_QUANTIZATION_RANGE_LIMITED;
>>  } else {
>>  pipe_config->limited_color_range =
>> -intel_dp->limited_color_range;
>> +intel_conn_state->broadcast_rgb == 
>> INTEL_BROADCAST_RGB_LIMITED;
>>  }
>>  
>>  pipe_config->lane_count = lane_count;
>> @@ -4781,104 +4783,6 @@ static int intel_dp_get_modes(struct drm_connector 
>> *connector)
>>  }
>>  
>>  static int
>> -intel_dp_set_property(struct drm_connector *connector,
>> -  struct drm_property *property,
>> -  uint64_t val)
>> -{
>> -struct drm_i915_private *dev_priv = to_i915(connector->dev);
>> -struct intel_connector *intel_connector = to_intel_connector(connector);
>> -struct intel_encoder *intel_encoder = intel_attached_encoder(connector);
>> -struct intel_dp *intel_dp = enc_to_intel_dp(_encoder->base);
>> -int ret;
>> -
>> -ret = drm_object_property_set_value(>base, property, val);
>> -if (ret)
>> -return ret;
>> -
>> -if (property == dev_priv->force_audio_property) {
>> -int i = val;
>> -bool has_audio, old_has_audio;
>> -int old_force_audio = intel_dp->force_audio;
>> -
>> -if (i == intel_dp->force_audio)
>> -return 0;
>> -
>> -if (old_force_audio == HDMI_AUDIO_AUTO)
>> -old_has_audio = intel_dp->has_audio;
>> -else
>> -old_has_audio = old_force_audio;
>> -
>> -intel_dp->force_audio = i;
>> -
>> -if (i == HDMI_AUDIO_AUTO)
>> -has_audio = intel_dp->has_audio;
>> -else
>> -has_audio = (i == HDMI_AUDIO_ON);
>> -
>> -if (has_audio == 

Re: [Intel-gfx] [PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

[Marek Szyprowski]

Hi All,

On 2017-04-20 09:51, Daniel Vetter wrote:

On Wed, Apr 19, 2017 at 01:36:10PM -0600, Logan Gunthorpe wrote:

Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
in highmem.h, the former can be aliased if any dma-buf user includes
that header.

I'm personally trying to include highmem.h inside scatterlist.h and this
breaks the dma-buf code proper.

Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.

To maintain consistency I've renamed all four of kmap* and kunmap* to be
map* and unmap*. (Even though only kmap_atomic presently conflicts.)

[1] https://www.spinics.net/lists/target-devel/msg15070.html

Signed-off-by: Logan Gunthorpe 
Reviewed-by: Sinclair Yeh 

Acked-by: Daniel Vetter 

Probably simplest if we pull this in through the drm-misc tree for 4.12.
Can we have an ack for the v4l side for that pls?


For the V4L2/videobuf2:
Acked-by: Marek Szyprowski 



Thanks, Daniel

---

Changes since v1:

- Added the missing tegra driver (noticed by kbuild robot)
- Rebased off of drm-intel-next to get the i915 selftest that is new
- Fixed nits Sinclair pointed out.

  drivers/dma-buf/dma-buf.c  | 16 
  drivers/gpu/drm/armada/armada_gem.c|  8 
  drivers/gpu/drm/drm_prime.c|  8 
  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  8 
  drivers/gpu/drm/i915/selftests/mock_dmabuf.c   |  8 
  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  8 
  drivers/gpu/drm/tegra/gem.c|  8 
  drivers/gpu/drm/udl/udl_dmabuf.c   |  8 
  drivers/gpu/drm/vmwgfx/vmwgfx_prime.c  |  8 
  drivers/media/v4l2-core/videobuf2-dma-contig.c |  4 ++--
  drivers/media/v4l2-core/videobuf2-dma-sg.c |  4 ++--
  drivers/media/v4l2-core/videobuf2-vmalloc.c|  4 ++--
  drivers/staging/android/ion/ion.c  |  8 
  include/linux/dma-buf.h| 22 +++---
  14 files changed, 61 insertions(+), 61 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f72aaac..512bdbc 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -405,8 +405,8 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
  || !exp_info->ops->map_dma_buf
  || !exp_info->ops->unmap_dma_buf
  || !exp_info->ops->release
- || !exp_info->ops->kmap_atomic
- || !exp_info->ops->kmap
+ || !exp_info->ops->map_atomic
+ || !exp_info->ops->map
  || !exp_info->ops->mmap)) {
return ERR_PTR(-EINVAL);
}
@@ -872,7 +872,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, unsigned 
long page_num)
  {
WARN_ON(!dmabuf);

-   return dmabuf->ops->kmap_atomic(dmabuf, page_num);
+   return dmabuf->ops->map_atomic(dmabuf, page_num);
  }
  EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);

@@ -889,8 +889,8 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, unsigned 
long page_num,
  {
WARN_ON(!dmabuf);

-   if (dmabuf->ops->kunmap_atomic)
-   dmabuf->ops->kunmap_atomic(dmabuf, page_num, vaddr);
+   if (dmabuf->ops->unmap_atomic)
+   dmabuf->ops->unmap_atomic(dmabuf, page_num, vaddr);
  }
  EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic);

@@ -907,7 +907,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long 
page_num)
  {
WARN_ON(!dmabuf);

-   return dmabuf->ops->kmap(dmabuf, page_num);
+   return dmabuf->ops->map(dmabuf, page_num);
  }
  EXPORT_SYMBOL_GPL(dma_buf_kmap);

@@ -924,8 +924,8 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long 
page_num,
  {
WARN_ON(!dmabuf);

-   if (dmabuf->ops->kunmap)
-   dmabuf->ops->kunmap(dmabuf, page_num, vaddr);
+   if (dmabuf->ops->unmap)
+   dmabuf->ops->unmap(dmabuf, page_num, vaddr);
  }
  EXPORT_SYMBOL_GPL(dma_buf_kunmap);

diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index 1597458..d6c2a5d 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -529,10 +529,10 @@ static const struct dma_buf_ops 
armada_gem_prime_dmabuf_ops = {
.map_dma_buf= armada_gem_prime_map_dma_buf,
.unmap_dma_buf  = armada_gem_prime_unmap_dma_buf,
.release= drm_gem_dmabuf_release,
-   .kmap_atomic= armada_gem_dmabuf_no_kmap,
-   .kunmap_atomic  = armada_gem_dmabuf_no_kunmap,
-   .kmap   = armada_gem_dmabuf_no_kmap,
-   .kunmap = armada_gem_dmabuf_no_kunmap,
+   .map_atomic = armada_gem_dmabuf_no_kmap,
+   .unmap_atomic   = armada_gem_dmabuf_no_kunmap,
+   .map   

[Intel-gfx] [i-g-t PATCH 2/4] igt/igt_core: Provide an option to check for the log buffer contents

[Abdiel Janulgue]

Signed-off-by: Abdiel Janulgue 
---
 lib/igt_core.c | 24 
 lib/igt_core.h |  3 +++
 2 files changed, 27 insertions(+)

diff --git a/lib/igt_core.c b/lib/igt_core.c
index 8a7ba0d..e80a32a 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -329,6 +329,30 @@ static void _igt_log_buffer_dump(void)
pthread_mutex_unlock(_buffer_mutex);
 }
 
+/**
+ * igt_log_buffer_inspect:
+ *
+ * Provides a way to replay the internal igt log buffer for inspection.
+ * @check: A user-specified handler that gets invoked for each line of
+   the log buffer. The handler should return true to stop
+   inspecting the rest of the buffer.
+ * @data: passed as a user argument to the inspection function.
+ */
+void igt_log_buffer_inspect(igt_buffer_log_handler_t check, void *data)
+{
+   uint8_t i;
+   pthread_mutex_lock(_buffer_mutex);
+
+   i = log_buffer.start;
+   do {
+   if (check(log_buffer.entries[i], data))
+   break;
+   i++;
+   } while (i != log_buffer.start && i != log_buffer.end);
+
+   pthread_mutex_unlock(_buffer_mutex);
+}
+
 __attribute__((format(printf, 1, 2)))
 static void kmsg(const char *format, ...)
 #define KERN_EMER  "<0>"
diff --git a/lib/igt_core.h b/lib/igt_core.h
index 6d4cf60..3e0d3c3 100644
--- a/lib/igt_core.h
+++ b/lib/igt_core.h
@@ -817,6 +817,9 @@ void igt_vlog(const char *domain, enum igt_log_level level, 
const char *format,
  */
 #define igt_critical(f...) igt_log(IGT_LOG_DOMAIN, IGT_LOG_CRITICAL, f)
 
+typedef bool (*igt_buffer_log_handler_t)(const char *line, void *data);
+void igt_log_buffer_inspect(igt_buffer_log_handler_t check, void *data);
+
 extern enum igt_log_level igt_log_level;
 
 /**
-- 
2.7.4

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

[Intel-gfx] [i-g-t PATCH 3/4] lib/igt_debugfs: Add helper to return path to device.

[Abdiel Janulgue]

Signed-off-by: Abdiel Janulgue 
---
 lib/igt_debugfs.c | 26 ++
 lib/igt_debugfs.h |  1 +
 2 files changed, 27 insertions(+)

diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
index 7584be5..b019c3b 100644
--- a/lib/igt_debugfs.c
+++ b/lib/igt_debugfs.c
@@ -22,6 +22,9 @@
  *
  */
 
+#ifndef ANDROID
+#define _GNU_SOURCE
+#endif
 #include 
 #include 
 #include 
@@ -198,6 +201,29 @@ int igt_debugfs_dir(int device)
igt_debug("Opening debugfs directory '%s'\n", path);
return open(path, O_RDONLY);
 }
+\
+/**
+ * igt_debugfs_path:
+ * @device: fd of the device
+ *
+ * Returns:
+ * The path to the debugfs directory corresponding to device
+ */
+const char *igt_debugfs_path(int device)
+{
+   char *path = 0;
+
+   if (!path) {
+   char *linkname;
+   int debugfs;
+   igt_assert((debugfs = igt_debugfs_dir(device)) != -1);
+   igt_assert(path = calloc(PATH_MAX, sizeof(char)));
+   igt_assert(asprintf(, "/proc/self/fd/%d", debugfs) != 
-1);
+   igt_assert(readlink(linkname, path, PATH_MAX * sizeof(char)) != 
-1);
+   }
+
+   return path;
+}
 
 /**
  * igt_debugfs_open:
diff --git a/lib/igt_debugfs.h b/lib/igt_debugfs.h
index 7b846a8..76cf409 100644
--- a/lib/igt_debugfs.h
+++ b/lib/igt_debugfs.h
@@ -204,5 +204,6 @@ void igt_enable_prefault(void);
  */
 int igt_get_stable_obj_count(int driver);
 void igt_debugfs_dump(int device, const char *filename);
+const char *igt_debugfs_path(int device);
 
 #endif /* __IGT_DEBUGFS_H__ */
-- 
2.7.4

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

[Intel-gfx] [i-g-t PATCH 1/4] lib/igt_core: Add igt_exec helpers

[Abdiel Janulgue]

Support executing external processes with the goal of capturing its
standard streams to the igt logging infrastructure in addition to its
exit status.

Cc: Daniel Vetter 
Cc: Petri Latvala 
Signed-off-by: Abdiel Janulgue 
---
 lib/igt_core.c | 151 +
 lib/igt_core.h |   3 ++
 2 files changed, 154 insertions(+)

diff --git a/lib/igt_core.c b/lib/igt_core.c
index 403b942..8a7ba0d 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -2073,3 +2073,154 @@ FILE *__igt_fopen_data(const char* igt_srcdir, const 
char* igt_datadir,
 
return fp;
 }
+
+struct output_pipe {
+   int output_fd;
+   int save_fd;
+   int read_fd;
+   int write_fd;
+   bool redirected;
+   enum igt_log_level log_level;
+};
+
+static bool redirect_output(struct output_pipe *p, int output_fd,
+   enum igt_log_level level)
+{
+   int fds[2], flags;
+
+   if (pipe(fds) == -1)
+   return false;
+
+   if ((flags = fcntl(fds[0], F_GETFL) == -1))
+   return false;
+
+   flags |= O_NONBLOCK;
+   if (fcntl(fds[0], F_SETFL, flags) == -1)
+   return false;
+
+   /* save output */
+   if ((p->save_fd = dup(output_fd)) == -1)
+   return false;
+
+   /* Redirect output to our buffer */
+   if (dup2(fds[1], output_fd) == -1)
+   return false;
+
+   p->output_fd = output_fd;
+   p->read_fd = fds[0];
+   p->write_fd = fds[1];
+   p->redirected = true;
+   p->log_level = level;
+
+   return true;
+}
+
+static bool unredirect_output(struct output_pipe *p)
+{
+   close(p->write_fd);
+   if (dup2(p->save_fd, p->output_fd) == -1)
+   return false;
+   close(p->save_fd);
+
+   p->redirected = false;
+
+   return true;
+}
+
+/**
+ * igt_exec:
+ *
+ * Executes the shell command specified in @command and capture its stdout and
+ * stderr to igt_log or igt_warn respectively.
+ *
+ * Returns: The exit status of the executed process. -1 for failure.
+ */
+int igt_exec(const char *command)
+{
+#define OUT 0
+#define ERR 1
+   struct output_pipe op[2];
+   int i, sel_fd, status;
+   fd_set fds;
+   struct timeval timeout = { .tv_sec = 0, .tv_usec = 0 };
+   char buf[PIPE_BUF];
+
+   if (!redirect_output([OUT], STDOUT_FILENO, IGT_LOG_INFO))
+   return -1;
+   if (!redirect_output([ERR], STDERR_FILENO, IGT_LOG_WARN))
+   return -1;
+
+   if ((status = system(command)) == -1)
+   return -1;
+
+   FD_ZERO();
+   FD_SET(op[OUT].read_fd, );
+   FD_SET(op[ERR].read_fd, );
+
+   sel_fd = max(op[OUT].read_fd, op[ERR].read_fd);
+   if (select(sel_fd + 1, , NULL, NULL, ) == -1)
+   return -1;
+
+   for (i = 0; i < ARRAY_SIZE(op); i++) {
+   struct output_pipe *current = [i];
+
+   if (!FD_ISSET(current->read_fd, )) {
+   close(current->read_fd);
+   if (!unredirect_output(current))
+   return -1;
+   continue;
+   }
+
+   memset(buf, 0, sizeof(buf));
+   while (read(current->read_fd, buf, sizeof(buf)) > 0) {
+   if (current->redirected) {
+   if (!unredirect_output(current))
+   return -1;
+   }
+   igt_log(IGT_LOG_DOMAIN, current->log_level,
+   "[cmd] %s", buf);
+   memset(buf, 0, sizeof(buf));
+   }
+   close(current->read_fd);
+   }
+
+   return WEXITSTATUS(status);
+}
+
+/**
+ * igt_exec_quiet:
+ * Similar to igt_exec(), except redirect output to /dev/null
+ *
+ * Returns: The exit status of the executed process. -1 for failure.
+ */
+int igt_exec_quiet(const char *command)
+{
+   int stderr_fd_copy, stdout_fd_copy, status, nullfd;
+
+   /* redirect */
+   if ((nullfd = open("/dev/null", O_WRONLY)) == -1)
+   return -1;
+   if ((stdout_fd_copy = dup(STDOUT_FILENO)) == -1)
+   return -1;
+   if ((stderr_fd_copy = dup(STDERR_FILENO)) == -1)
+   return -1;
+
+   if (dup2(nullfd, STDOUT_FILENO) == -1)
+   return -1;
+   if (dup2(nullfd, STDERR_FILENO) == -1)
+   return -1;
+
+   if ((status = system(command)) == -1)
+   return -1;
+
+   /* restore */
+   if (dup2(stdout_fd_copy, STDOUT_FILENO) == -1)
+   return -1;
+   if (dup2(stderr_fd_copy, STDERR_FILENO) == -1)
+   return -1;
+
+   close(stdout_fd_copy);
+   close(stderr_fd_copy);
+
+   return WEXITSTATUS(status);
+}
diff --git a/lib/igt_core.h b/lib/igt_core.h
index 51b98d8..6d4cf60 100644

[Intel-gfx] [i-g-t PATCH 4/4] Convert shell script tests to C version

[Abdiel Janulgue]

Converted:
 - check_drm_clients (ensures no other clients are running.
   functionality provided by drm_open_driver_master).
 - debugfs_emon_crash
 - debugfs_wedged
 - drv_debugfs_reader
 - sysfs_l3_parity
 - test_rte_check  (same as check_drm_clients)
 - tools_test
 - ZZ_check_dmesg

Cc: Daniel Vetter 
Cc: Petri Latvala 
Signed-off-by: Abdiel Janulgue 
---
 tests/Makefile.sources   |   9 +---
 tests/ZZ_check_dmesg |  11 -
 tests/check_drm_clients  |   6 ---
 tests/debugfs.c  |  75 
 tests/debugfs_emon_crash |  16 ---
 tests/debugfs_wedged |  10 -
 tests/drv_debugfs_reader |   9 
 tests/sysfs_l3_parity|  22 --
 tests/test_rte_check |   6 ---
 tests/tools.c| 111 +++
 tests/tools_test |  16 ---
 11 files changed, 188 insertions(+), 103 deletions(-)
 delete mode 100755 tests/ZZ_check_dmesg
 delete mode 100755 tests/check_drm_clients
 create mode 100644 tests/debugfs.c
 delete mode 100755 tests/debugfs_emon_crash
 delete mode 100755 tests/debugfs_wedged
 delete mode 100755 tests/drv_debugfs_reader
 delete mode 100755 tests/sysfs_l3_parity
 delete mode 100755 tests/test_rte_check
 create mode 100644 tests/tools.c
 delete mode 100755 tests/tools_test

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 7fa9b8f..089428d 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -234,6 +234,8 @@ TESTS_progs = \
drv_module_reload \
kms_sysfs_edid_timing \
perf \
+   debugfs \
+   tools \
$(NULL)
 
 # IMPORTANT: The ZZ_ tests need to be run last!
@@ -242,11 +244,6 @@ TESTS_scripts_M = \
$(NULL)
 
 TESTS_scripts = \
-   debugfs_emon_crash \
-   drv_debugfs_reader \
-   sysfs_l3_parity \
-   test_rte_check \
-   tools_test \
$(NULL)
 
 # This target contains testcases which support automagic subtest enumeration
@@ -308,9 +305,7 @@ HANG = \
$(NULL)
 
 scripts = \
-   check_drm_clients \
ddx_intel_after_fbdev \
-   debugfs_wedged \
drm_lib.sh \
drm_getopt.sh \
$(NULL)
diff --git a/tests/ZZ_check_dmesg b/tests/ZZ_check_dmesg
deleted file mode 100755
index e28ba35..000
--- a/tests/ZZ_check_dmesg
+++ /dev/null
@@ -1,11 +0,0 @@
-#!/bin/sh
-
-if dmesg | grep '\*ERROR\*'  > /dev/null ; then
-   echo "DRM_ERROR dirt in dmesg"
-   exit 1
-fi
-
-if dmesg | grep -- '--\[ cut here \]' > /dev/null  ; then
-   echo "found a backtrace in dmesg"
-   exit 1
-fi
diff --git a/tests/check_drm_clients b/tests/check_drm_clients
deleted file mode 100755
index 2a891b8..000
--- a/tests/check_drm_clients
+++ /dev/null
@@ -1,6 +0,0 @@
-#!/bin/bash
-
-SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
-. $SOURCE_DIR/drm_lib.sh
-
-exit $IGT_EXIT_SUCCESS
diff --git a/tests/debugfs.c b/tests/debugfs.c
new file mode 100644
index 000..2e2f9bb
--- /dev/null
+++ b/tests/debugfs.c
@@ -0,0 +1,75 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+#include "igt.h"
+
+igt_main
+{
+   int fd = -1;
+   igt_skip_on_simulation();
+
+   igt_fixture {
+   fd = drm_open_driver_master(DRIVER_INTEL);
+   igt_require_gem(fd);
+   }
+
+   igt_subtest_group {
+   igt_subtest("debugfs_emon_crash") {
+   int i;
+   char *cmd;
+   igt_assert(asprintf(, "cat %s/i915_emon_status",
+   igt_debugfs_path(fd)) != -1);
+
+   for (i = 0; i < 1000; i++)
+   igt_exec_quiet(cmd);
+
+   free(cmd);
+   

Re: [Intel-gfx] [PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

[Sumit Semwal]

Hi Marek,

Thanks!

On 20 April 2017 at 13:36, Marek Szyprowski  wrote:
> Hi All,
>
> On 2017-04-20 09:51, Daniel Vetter wrote:
>>
>> On Wed, Apr 19, 2017 at 01:36:10PM -0600, Logan Gunthorpe wrote:
>>>
>>> Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
>>> in highmem.h, the former can be aliased if any dma-buf user includes
>>> that header.
>>>
>>> I'm personally trying to include highmem.h inside scatterlist.h and this
>>> breaks the dma-buf code proper.
>>>
>>> Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.
>>>
>>> To maintain consistency I've renamed all four of kmap* and kunmap* to be
>>> map* and unmap*. (Even though only kmap_atomic presently conflicts.)
>>>
>>> [1] https://www.spinics.net/lists/target-devel/msg15070.html
>>>
>>> Signed-off-by: Logan Gunthorpe 
>>> Reviewed-by: Sinclair Yeh 
>>
>> Acked-by: Daniel Vetter 
>>
>> Probably simplest if we pull this in through the drm-misc tree for 4.12.
>> Can we have an ack for the v4l side for that pls?
>
>
> For the V4L2/videobuf2:
> Acked-by: Marek Szyprowski 
>
I will queue it up for drm-misc-fixes so it gets into 4.12.
>
>
>> Thanks, Daniel
Best,
Sumit.

>>>
>>> ---
>>>
>>> Changes since v1:
>>>
>>> - Added the missing tegra driver (noticed by kbuild robot)
>>> - Rebased off of drm-intel-next to get the i915 selftest that is new
>>> - Fixed nits Sinclair pointed out.
>>>
>>>   drivers/dma-buf/dma-buf.c  | 16 
>>>   drivers/gpu/drm/armada/armada_gem.c|  8 
>>>   drivers/gpu/drm/drm_prime.c|  8 
>>>   drivers/gpu/drm/i915/i915_gem_dmabuf.c |  8 
>>>   drivers/gpu/drm/i915/selftests/mock_dmabuf.c   |  8 
>>>   drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  8 
>>>   drivers/gpu/drm/tegra/gem.c|  8 
>>>   drivers/gpu/drm/udl/udl_dmabuf.c   |  8 
>>>   drivers/gpu/drm/vmwgfx/vmwgfx_prime.c  |  8 
>>>   drivers/media/v4l2-core/videobuf2-dma-contig.c |  4 ++--
>>>   drivers/media/v4l2-core/videobuf2-dma-sg.c |  4 ++--
>>>   drivers/media/v4l2-core/videobuf2-vmalloc.c|  4 ++--
>>>   drivers/staging/android/ion/ion.c  |  8 
>>>   include/linux/dma-buf.h| 22
>>> +++---
>>>   14 files changed, 61 insertions(+), 61 deletions(-)
>>>
>>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>>> index f72aaac..512bdbc 100644
>>> --- a/drivers/dma-buf/dma-buf.c
>>> +++ b/drivers/dma-buf/dma-buf.c
>>> @@ -405,8 +405,8 @@ struct dma_buf *dma_buf_export(const struct
>>> dma_buf_export_info *exp_info)
>>>   || !exp_info->ops->map_dma_buf
>>>   || !exp_info->ops->unmap_dma_buf
>>>   || !exp_info->ops->release
>>> - || !exp_info->ops->kmap_atomic
>>> - || !exp_info->ops->kmap
>>> + || !exp_info->ops->map_atomic
>>> + || !exp_info->ops->map
>>>   || !exp_info->ops->mmap)) {
>>> return ERR_PTR(-EINVAL);
>>> }
>>> @@ -872,7 +872,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf,
>>> unsigned long page_num)
>>>   {
>>> WARN_ON(!dmabuf);
>>>
>>> -   return dmabuf->ops->kmap_atomic(dmabuf, page_num);
>>> +   return dmabuf->ops->map_atomic(dmabuf, page_num);
>>>   }
>>>   EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);
>>>
>>> @@ -889,8 +889,8 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf,
>>> unsigned long page_num,
>>>   {
>>> WARN_ON(!dmabuf);
>>>
>>> -   if (dmabuf->ops->kunmap_atomic)
>>> -   dmabuf->ops->kunmap_atomic(dmabuf, page_num, vaddr);
>>> +   if (dmabuf->ops->unmap_atomic)
>>> +   dmabuf->ops->unmap_atomic(dmabuf, page_num, vaddr);
>>>   }
>>>   EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic);
>>>
>>> @@ -907,7 +907,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned
>>> long page_num)
>>>   {
>>> WARN_ON(!dmabuf);
>>>
>>> -   return dmabuf->ops->kmap(dmabuf, page_num);
>>> +   return dmabuf->ops->map(dmabuf, page_num);
>>>   }
>>>   EXPORT_SYMBOL_GPL(dma_buf_kmap);
>>>
>>> @@ -924,8 +924,8 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned
>>> long page_num,
>>>   {
>>> WARN_ON(!dmabuf);
>>>
>>> -   if (dmabuf->ops->kunmap)
>>> -   dmabuf->ops->kunmap(dmabuf, page_num, vaddr);
>>> +   if (dmabuf->ops->unmap)
>>> +   dmabuf->ops->unmap(dmabuf, page_num, vaddr);
>>>   }
>>>   EXPORT_SYMBOL_GPL(dma_buf_kunmap);
>>>
>>> diff --git a/drivers/gpu/drm/armada/armada_gem.c
>>> b/drivers/gpu/drm/armada/armada_gem.c
>>> index 1597458..d6c2a5d 100644
>>> --- a/drivers/gpu/drm/armada/armada_gem.c
>>> +++ 

Re: [Intel-gfx] [PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

[Sumit Semwal]

Hi Logan,

Thanks for the patch.

On 20 April 2017 at 13:21, Daniel Vetter  wrote:
> On Wed, Apr 19, 2017 at 01:36:10PM -0600, Logan Gunthorpe wrote:
>> Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
>> in highmem.h, the former can be aliased if any dma-buf user includes
>> that header.
>>
>> I'm personally trying to include highmem.h inside scatterlist.h and this
>> breaks the dma-buf code proper.
>>
>> Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.
>>
>> To maintain consistency I've renamed all four of kmap* and kunmap* to be
>> map* and unmap*. (Even though only kmap_atomic presently conflicts.)
>>
>> [1] https://www.spinics.net/lists/target-devel/msg15070.html
>>
>> Signed-off-by: Logan Gunthorpe 
>> Reviewed-by: Sinclair Yeh 
>
> Acked-by: Daniel Vetter 
Acked-by: Sumit Semwal 
>
> Probably simplest if we pull this in through the drm-misc tree for 4.12.
> Can we have an ack for the v4l side for that pls?
>
> Thanks, Daniel
>
>> ---
>>
>> Changes since v1:
>>
>> - Added the missing tegra driver (noticed by kbuild robot)
>> - Rebased off of drm-intel-next to get the i915 selftest that is new
>> - Fixed nits Sinclair pointed out.
>>
>>  drivers/dma-buf/dma-buf.c  | 16 
>>  drivers/gpu/drm/armada/armada_gem.c|  8 
>>  drivers/gpu/drm/drm_prime.c|  8 
>>  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  8 
>>  drivers/gpu/drm/i915/selftests/mock_dmabuf.c   |  8 
>>  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  8 
>>  drivers/gpu/drm/tegra/gem.c|  8 
>>  drivers/gpu/drm/udl/udl_dmabuf.c   |  8 
>>  drivers/gpu/drm/vmwgfx/vmwgfx_prime.c  |  8 
>>  drivers/media/v4l2-core/videobuf2-dma-contig.c |  4 ++--
>>  drivers/media/v4l2-core/videobuf2-dma-sg.c |  4 ++--
>>  drivers/media/v4l2-core/videobuf2-vmalloc.c|  4 ++--
>>  drivers/staging/android/ion/ion.c  |  8 
>>  include/linux/dma-buf.h| 22 +++---
>>  14 files changed, 61 insertions(+), 61 deletions(-)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index f72aaac..512bdbc 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -405,8 +405,8 @@ struct dma_buf *dma_buf_export(const struct 
>> dma_buf_export_info *exp_info)
>> || !exp_info->ops->map_dma_buf
>> || !exp_info->ops->unmap_dma_buf
>> || !exp_info->ops->release
>> -   || !exp_info->ops->kmap_atomic
>> -   || !exp_info->ops->kmap
>> +   || !exp_info->ops->map_atomic
>> +   || !exp_info->ops->map
>> || !exp_info->ops->mmap)) {
>>   return ERR_PTR(-EINVAL);
>>   }
>> @@ -872,7 +872,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, 
>> unsigned long page_num)
>>  {
>>   WARN_ON(!dmabuf);
>>
>> - return dmabuf->ops->kmap_atomic(dmabuf, page_num);
>> + return dmabuf->ops->map_atomic(dmabuf, page_num);
>>  }
>>  EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);
>>
>> @@ -889,8 +889,8 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, 
>> unsigned long page_num,
>>  {
>>   WARN_ON(!dmabuf);
>>
>> - if (dmabuf->ops->kunmap_atomic)
>> - dmabuf->ops->kunmap_atomic(dmabuf, page_num, vaddr);
>> + if (dmabuf->ops->unmap_atomic)
>> + dmabuf->ops->unmap_atomic(dmabuf, page_num, vaddr);
>>  }
>>  EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic);
>>
>> @@ -907,7 +907,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long 
>> page_num)
>>  {
>>   WARN_ON(!dmabuf);
>>
>> - return dmabuf->ops->kmap(dmabuf, page_num);
>> + return dmabuf->ops->map(dmabuf, page_num);
>>  }
>>  EXPORT_SYMBOL_GPL(dma_buf_kmap);
>>
>> @@ -924,8 +924,8 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned 
>> long page_num,
>>  {
>>   WARN_ON(!dmabuf);
>>
>> - if (dmabuf->ops->kunmap)
>> - dmabuf->ops->kunmap(dmabuf, page_num, vaddr);
>> + if (dmabuf->ops->unmap)
>> + dmabuf->ops->unmap(dmabuf, page_num, vaddr);
>>  }
>>  EXPORT_SYMBOL_GPL(dma_buf_kunmap);
>>
>> diff --git a/drivers/gpu/drm/armada/armada_gem.c 
>> b/drivers/gpu/drm/armada/armada_gem.c
>> index 1597458..d6c2a5d 100644
>> --- a/drivers/gpu/drm/armada/armada_gem.c
>> +++ b/drivers/gpu/drm/armada/armada_gem.c
>> @@ -529,10 +529,10 @@ static const struct dma_buf_ops 
>> armada_gem_prime_dmabuf_ops = {
>>   .map_dma_buf= armada_gem_prime_map_dma_buf,
>>   .unmap_dma_buf  = armada_gem_prime_unmap_dma_buf,
>>   .release= drm_gem_dmabuf_release,
>> - .kmap_atomic= armada_gem_dmabuf_no_kmap,
>> - .kunmap_atomic  = 

Re: [Intel-gfx] [PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

[Daniel Vetter]

On Wed, Apr 19, 2017 at 01:36:10PM -0600, Logan Gunthorpe wrote:
> Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
> in highmem.h, the former can be aliased if any dma-buf user includes
> that header.
> 
> I'm personally trying to include highmem.h inside scatterlist.h and this
> breaks the dma-buf code proper.
> 
> Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.
> 
> To maintain consistency I've renamed all four of kmap* and kunmap* to be
> map* and unmap*. (Even though only kmap_atomic presently conflicts.)
> 
> [1] https://www.spinics.net/lists/target-devel/msg15070.html
> 
> Signed-off-by: Logan Gunthorpe 
> Reviewed-by: Sinclair Yeh 

Acked-by: Daniel Vetter 

Probably simplest if we pull this in through the drm-misc tree for 4.12.
Can we have an ack for the v4l side for that pls?

Thanks, Daniel

> ---
> 
> Changes since v1:
> 
> - Added the missing tegra driver (noticed by kbuild robot)
> - Rebased off of drm-intel-next to get the i915 selftest that is new
> - Fixed nits Sinclair pointed out.
> 
>  drivers/dma-buf/dma-buf.c  | 16 
>  drivers/gpu/drm/armada/armada_gem.c|  8 
>  drivers/gpu/drm/drm_prime.c|  8 
>  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  8 
>  drivers/gpu/drm/i915/selftests/mock_dmabuf.c   |  8 
>  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  8 
>  drivers/gpu/drm/tegra/gem.c|  8 
>  drivers/gpu/drm/udl/udl_dmabuf.c   |  8 
>  drivers/gpu/drm/vmwgfx/vmwgfx_prime.c  |  8 
>  drivers/media/v4l2-core/videobuf2-dma-contig.c |  4 ++--
>  drivers/media/v4l2-core/videobuf2-dma-sg.c |  4 ++--
>  drivers/media/v4l2-core/videobuf2-vmalloc.c|  4 ++--
>  drivers/staging/android/ion/ion.c  |  8 
>  include/linux/dma-buf.h| 22 +++---
>  14 files changed, 61 insertions(+), 61 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index f72aaac..512bdbc 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -405,8 +405,8 @@ struct dma_buf *dma_buf_export(const struct 
> dma_buf_export_info *exp_info)
> || !exp_info->ops->map_dma_buf
> || !exp_info->ops->unmap_dma_buf
> || !exp_info->ops->release
> -   || !exp_info->ops->kmap_atomic
> -   || !exp_info->ops->kmap
> +   || !exp_info->ops->map_atomic
> +   || !exp_info->ops->map
> || !exp_info->ops->mmap)) {
>   return ERR_PTR(-EINVAL);
>   }
> @@ -872,7 +872,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, 
> unsigned long page_num)
>  {
>   WARN_ON(!dmabuf);
> 
> - return dmabuf->ops->kmap_atomic(dmabuf, page_num);
> + return dmabuf->ops->map_atomic(dmabuf, page_num);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);
> 
> @@ -889,8 +889,8 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, 
> unsigned long page_num,
>  {
>   WARN_ON(!dmabuf);
> 
> - if (dmabuf->ops->kunmap_atomic)
> - dmabuf->ops->kunmap_atomic(dmabuf, page_num, vaddr);
> + if (dmabuf->ops->unmap_atomic)
> + dmabuf->ops->unmap_atomic(dmabuf, page_num, vaddr);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic);
> 
> @@ -907,7 +907,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long 
> page_num)
>  {
>   WARN_ON(!dmabuf);
> 
> - return dmabuf->ops->kmap(dmabuf, page_num);
> + return dmabuf->ops->map(dmabuf, page_num);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kmap);
> 
> @@ -924,8 +924,8 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long 
> page_num,
>  {
>   WARN_ON(!dmabuf);
> 
> - if (dmabuf->ops->kunmap)
> - dmabuf->ops->kunmap(dmabuf, page_num, vaddr);
> + if (dmabuf->ops->unmap)
> + dmabuf->ops->unmap(dmabuf, page_num, vaddr);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kunmap);
> 
> diff --git a/drivers/gpu/drm/armada/armada_gem.c 
> b/drivers/gpu/drm/armada/armada_gem.c
> index 1597458..d6c2a5d 100644
> --- a/drivers/gpu/drm/armada/armada_gem.c
> +++ b/drivers/gpu/drm/armada/armada_gem.c
> @@ -529,10 +529,10 @@ static const struct dma_buf_ops 
> armada_gem_prime_dmabuf_ops = {
>   .map_dma_buf= armada_gem_prime_map_dma_buf,
>   .unmap_dma_buf  = armada_gem_prime_unmap_dma_buf,
>   .release= drm_gem_dmabuf_release,
> - .kmap_atomic= armada_gem_dmabuf_no_kmap,
> - .kunmap_atomic  = armada_gem_dmabuf_no_kunmap,
> - .kmap   = armada_gem_dmabuf_no_kmap,
> - .kunmap = armada_gem_dmabuf_no_kunmap,
> + .map_atomic = armada_gem_dmabuf_no_kmap,
> + .unmap_atomic   = armada_gem_dmabuf_no_kunmap,
> + .map

Re: [Intel-gfx] [PATCH 01/27] drm/i915/selftests: Allocate inode/file dynamically

[Joonas Lahtinen]

On ke, 2017-04-19 at 10:41 +0100, Chris Wilson wrote:
> Avoid having too large a stack by creating the fake struct inode/file on
> the heap instead.
> 
> drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file':
> drivers/gpu/drm/i915/selftests/mock_drm.c:46:1: error: the frame size of 1328 
> bytes is larger than 1280 bytes [-Werror=frame-larger-than=]
> drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file_free':
> drivers/gpu/drm/i915/selftests/mock_drm.c:54:1: error: the frame size of 1312 
> bytes is larger than 1280 bytes [-Werror=frame-larger-than=]
> 
> Reported-by: Arnd Bergmann 
> Fixes: 66d9cb5d805a ("drm/i915: Mock the GEM device for self-testing")
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Tvrtko Ursulin 
> Cc: Matthew Auld 
> Cc: Arnd Bergmann 
> Acked-by: Arnd Bergmann 

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
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/scheduler: add gvt force-single-submission and notification for guc (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/scheduler: add gvt force-single-submission and notification 
for guc (rev4)
URL   : https://patchwork.freedesktop.org/series/21972/
State : success

== Summary ==

Series 21972v4 drm/i915/scheduler: add gvt force-single-submission and 
notification for guc
https://patchwork.freedesktop.org/api/1.0/series/21972/revisions/4/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125

fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:432s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:429s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:576s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:505s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:548s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:485s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:481s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:408s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:405s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:421s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:483s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:495s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:460s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:569s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:449s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:569s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:460s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:496s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:429s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:540s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:399s

1b757084743a73fa672e92b4e5cf00a291667dfc drm-tip: 2017y-04m-19d-12h-50m-15s UTC 
integration manifest
9f1c42d drm/i915: refactor gvt force-single-submission

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4523/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/scheduler: add gvt force-single-submission and notification for guc (rev4)

[Saarinen, Jani]

Hi, 
> == Series Details ==
> 
> Series: drm/i915/scheduler: add gvt force-single-submission and notification
> for guc (rev4)
> URL   : https://patchwork.freedesktop.org/series/21972/
> State : failure
> 
> == Summary ==
> 
> Series 21972v4 drm/i915/scheduler: add gvt force-single-submission and
> notification for guc
> https://patchwork.freedesktop.org/api/1.0/series/21972/revisions/4/mbox/
> 
> Test gem_exec_flush:
> Subgroup basic-batch-kernel-default-uc:
> pass   -> FAIL   (fi-snb-2600) fdo#17
> Test pm_rpm:
> Subgroup basic-pci-d3-state:
> pass   -> INCOMPLETE (fi-byt-j1900)
Right, now seems to match https://bugs.freedesktop.org/show_bug.cgi?id=99740
Marking. Re-testing. 

> Subgroup basic-rte:
> pass   -> INCOMPLETE (fi-bsw-n3050) fdo#100718
> 
> fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
> fdo#100718 https://bugs.freedesktop.org/show_bug.cgi?id=100718
> 
> fi-byt-j1900 total:241  pass:217  dwarn:0   dfail:0   fail:0   skip:23
> 
> 1b757084743a73fa672e92b4e5cf00a291667dfc drm-tip: 2017y-04m-19d-12h-
> 50m-15s UTC integration manifest 03cb65f drm/i915: refactor gvt force-
> single-submission
> 
> == Logs ==

Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo



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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/scheduler: add gvt force-single-submission and notification for guc (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/scheduler: add gvt force-single-submission and notification 
for guc (rev4)
URL   : https://patchwork.freedesktop.org/series/21972/
State : failure

== Summary ==

Series 21972v4 drm/i915/scheduler: add gvt force-single-submission and 
notification for guc
https://patchwork.freedesktop.org/api/1.0/series/21972/revisions/4/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> INCOMPLETE (fi-byt-j1900)
Subgroup basic-rte:
pass   -> INCOMPLETE (fi-bsw-n3050) fdo#100718

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#100718 https://bugs.freedesktop.org/show_bug.cgi?id=100718

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:431s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:426s
fi-bsw-n3050 total:242  pass:207  dwarn:0   dfail:0   fail:0   skip:34 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:510s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:564s
fi-byt-j1900 total:241  pass:217  dwarn:0   dfail:0   fail:0   skip:23 
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:481s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:409s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:413s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:425s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:499s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:462s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:457s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:561s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:451s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:568s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:465s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:497s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:441s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:531s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:397s

1b757084743a73fa672e92b4e5cf00a291667dfc drm-tip: 2017y-04m-19d-12h-50m-15s UTC 
integration manifest
03cb65f drm/i915: refactor gvt force-single-submission

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4522/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/scheduler: add gvt force-single-submission and notification for guc (rev4)

[Saarinen, Jani]

Hi, 
> == Series Details ==
> 
> Series: drm/i915/scheduler: add gvt force-single-submission and notification
> for guc (rev4)
> URL   : https://patchwork.freedesktop.org/series/21972/
> State : failure
> 
> == Summary ==
> 
> Series 21972v4 drm/i915/scheduler: add gvt force-single-submission and
> notification for guc
> https://patchwork.freedesktop.org/api/1.0/series/21972/revisions/4/mbox/
> 
> Test gem_exec_flush:
> Subgroup basic-batch-kernel-default-uc:
> pass   -> FAIL   (fi-snb-2600) fdo#17
> Test gem_exec_suspend:
> Subgroup basic-s4-devices:
> pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125
> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-c:
> pass   -> FAIL   (fi-skl-6700k)
Seems to match https://bugs.freedesktop.org/show_bug.cgi?id=100367
Re-running and marking known for CI. 

> Test pm_rpm:
> Subgroup basic-rte:
> pass   -> INCOMPLETE (fi-bsw-n3050) fdo#100718
> 
> fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
> fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
> fdo#100718 https://bugs.freedesktop.org/show_bug.cgi?id=100718
> 
> fi-skl-6700k total:278  pass:255  dwarn:4   dfail:0   fail:1   skip:18  
> time:457s
> 
> 1b757084743a73fa672e92b4e5cf00a291667dfc drm-tip: 2017y-04m-19d-12h-
> 50m-15s UTC integration manifest
> 4f12487 drm/i915: refactor gvt force-single-submission
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4521/


Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo


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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/scheduler: add gvt force-single-submission and notification for guc (rev4)

[Dong, Chuanxiao]

> -Original Message-
> From: Saarinen, Jani
> Sent: Thursday, April 20, 2017 2:30 PM
> To: intel-gfx@lists.freedesktop.org; Dong, Chuanxiao
> 
> Subject: RE: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/scheduler: add gvt
> force-single-submission and notification for guc (rev4)
> 
> Hi,
> > == Series Details ==
> >
> > Series: drm/i915/scheduler: add gvt force-single-submission and
> > notification for guc (rev4)
> > URL   : https://patchwork.freedesktop.org/series/21972/
> > State : failure
> >
> > == Summary ==
> >
> > Series 21972v4 drm/i915/scheduler: add gvt force-single-submission and
> > notification for guc
> > https://patchwork.freedesktop.org/api/1.0/series/21972/revisions/4/mbo
> > x/
> >
> > Test gem_exec_flush:
> > Subgroup basic-batch-kernel-default-uc:
> > pass   -> FAIL   (fi-snb-2600) fdo#17
> > Test gem_exec_suspend:
> > Subgroup basic-s4-devices:
> > pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125
> > Test kms_pipe_crc_basic:
> > Subgroup suspend-read-crc-pipe-c:
> > pass   -> FAIL   (fi-skl-6700k)
> Seems to match https://bugs.freedesktop.org/show_bug.cgi?id=100367
> Re-running and marking known for CI.

I see. Thanks Jani. :)

Thanks
Chuanxiao

> 
> > Test pm_rpm:
> > Subgroup basic-rte:
> > pass   -> INCOMPLETE (fi-bsw-n3050) fdo#100718
> >
> > fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
> > fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
> > fdo#100718 https://bugs.freedesktop.org/show_bug.cgi?id=100718
> >
> > fi-skl-6700k total:278  pass:255  dwarn:4   dfail:0   fail:1   skip:18
> time:457s
> >
> > 1b757084743a73fa672e92b4e5cf00a291667dfc drm-tip: 2017y-04m-19d-
> 12h-
> > 50m-15s UTC integration manifest
> > 4f12487 drm/i915: refactor gvt force-single-submission
> >
> > == Logs ==
> >
> > For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4521/
> 
> 
> Jani Saarinen
> Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
> 

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

Re: [Intel-gfx] [PATCH v4 2/9] drm/i915: Add plumbing for digital connector state, v2.

[Maarten Lankhorst]

On 19-04-17 17:48, Daniel Vetter wrote:
> On Wed, Apr 12, 2017 at 12:50:00PM +0200, Maarten Lankhorst wrote:
>> Some atomic properties are common between the various kinds of
>> connectors, for example a lot of them use panel fitting mode.
>> It makes sense to put a lot of it in a common place, so each
>> connector can use it while they're being converted.
>>
>> Implement the properties required for the connectors:
>> - scaling mode property
>> - force audio property
>> - broadcast rgb
>> - aspect ratio
>>
>> While at it, make clear that intel_digital_connector_atomic_get_property
>> is a hack that has to be removed when all connector properties
>> are converted to atomic.
>>
>> Changes since v1:
>> - Scaling mode and aspect ratio are partly handled in core now.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/i915/intel_atomic.c  | 142 
>> +--
>>  drivers/gpu/drm/i915/intel_display.c |  14 +++-
>>  drivers/gpu/drm/i915/intel_dp.c  |   2 +-
>>  drivers/gpu/drm/i915/intel_drv.h |  27 ++-
>>  drivers/gpu/drm/i915/intel_dsi.c |   2 +-
>>  drivers/gpu/drm/i915/intel_dvo.c |   2 +-
>>  drivers/gpu/drm/i915/intel_lvds.c|   2 +-
>>  drivers/gpu/drm/i915/intel_panel.c   |   4 +-
>>  8 files changed, 180 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
>> b/drivers/gpu/drm/i915/intel_atomic.c
>> index 50fb1f76cc5f..eb72166675f0 100644
>> --- a/drivers/gpu/drm/i915/intel_atomic.c
>> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> Refactoring idea for the future: intel_atomic.c makes 0 sense, just makes
> sure we have lots of functionality spread all over imo. I think following
> the split-up model I've done in the drm core would be a lot better, with
> intel_connector/encoder/crtc/plane.c for the shared helper functions. And
> then maybe separate files for the per-platform stuff, e.g. i9xx_crtc.c,
> pch_crtc.c and so on.
>
>> @@ -36,7 +36,7 @@
>>  #include "intel_drv.h"
>>  
>>  /**
>> - * intel_connector_atomic_get_property - fetch connector property value
>> + * intel_connector_atomic_get_property - fetch legacy connector property 
>> value
>>   * @connector: connector to fetch property for
>>   * @state: state containing the property value
>>   * @property: property to look up
>> @@ -45,12 +45,14 @@
>>   * 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 connector property.
>> + *
>> + * This is a intermediary solution until all connectors are
>> + * converted to support full atomic properties.
>>   */
>> -int
>> -intel_connector_atomic_get_property(struct drm_connector *connector,
>> -const struct drm_connector_state *state,
>> -struct drm_property *property,
>> -uint64_t *val)
>> +int intel_connector_atomic_get_property(struct drm_connector *connector,
>> +const struct drm_connector_state *state,
>> +struct drm_property *property,
>> +uint64_t *val)
>>  {
>>  int i;
>>  
>> @@ -73,7 +75,133 @@ intel_connector_atomic_get_property(struct drm_connector 
>> *connector,
>>  return -EINVAL;
>>  }
>>  
>> -/*
>> +/**
>> + * intel_digital_connector_atomic_get_property - hook for 
>> connector->atomic_get_property.
>> + * @connector: Connector to get the property for.
>> + * @state: Connector state to retrieve the property from.
>> + * @property: Property to retrieve.
>> + * @val: Return value for the property.
>> + *
>> + * Returns the atomic property value for a digital connector.
>> + */
>> +int intel_digital_connector_atomic_get_property(struct drm_connector 
>> *connector,
>> +const struct 
>> drm_connector_state *state,
>> +struct drm_property *property,
>> +uint64_t *val)
>> +{
>> +struct drm_device *dev = connector->dev;
>> +struct drm_i915_private *dev_priv = to_i915(dev);
>> +struct intel_digital_connector_state *intel_conn_state =
>> +to_intel_digital_connector_state(state);
>> +
>> +if (property == dev_priv->force_audio_property)
>> +*val = intel_conn_state->force_audio;
>> +else if (property == dev_priv->broadcast_rgb_property)
>> +*val = intel_conn_state->broadcast_rgb;
>> +else {
>> +DRM_DEBUG_ATOMIC("Unknown property %s\n", property->name);
>> +return -EINVAL;
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +/**
>> + * intel_digital_connector_atomic_set_property - hook for 
>> connector->atomic_set_property.
>> + * @connector: Connector to set the property for.
>> + * @state: Connector state to set the property on.
>> + * 

[Intel-gfx] [RESEND][GIT PULL] GVT-g next fixes for 4.12

[Zhenyu Wang]

Hi,
 
Please pull gvt next fixes for 4.12.

(resend with subscribed mail address.)

Thanks.

--
The following changes since commit b35f34d1da4e77637869c8041a355da810f69fb6:

  drm/i915/gvt: control the scheduler by timeslice usage (2017-03-30 13:34:10 
+0800)

are available in the git repository at:

  https://github.com/01org/gvt-linux.git tags/gvt-next-fixes-2017-04-20

for you to fetch changes up to c821ee6d2bb4cfc9991bf285f53103cde9d3593a:

  drm/i915/gvt: fix a bounds check in ring_id_to_context_switch_event() 
(2017-04-18 17:50:05 +0800)


gvt-next-fixes-2017-04-20

- some code optimization from Changbin
- debug message cleanup after QoS merge
- misc fixes for display mmio init, reset vgpu warning, etc.


Changbin Du (4):
  drm/i915/gvt: Align render mmio list to cacheline
  drm/i915/gvt: remove redundant platform check for mocs load/restore
  drm/i915/gvt: remove redundant ring id check which cause significant CPU 
misprediction
  drm/i915/gvt: use directly assignment for structure copying

Dan Carpenter (1):
  drm/i915/gvt: fix a bounds check in ring_id_to_context_switch_event()

Pei Zhang (1):
  drm/i915/gvt: add mmio init for virtual display

Zhenyu Wang (3):
  drm/i915/gvt: cleanup some too chatty scheduler message
  drm/i915/gvt: remove some debug messages in scheduler timer handler
  drm/i915/gvt: Fix PTE write flush for taking runtime pm properly

 drivers/gpu/drm/i915/gvt/cmd_parser.c   |  8 +---
 drivers/gpu/drm/i915/gvt/display.c  | 29 -
 drivers/gpu/drm/i915/gvt/execlist.c |  8 +++-
 drivers/gpu/drm/i915/gvt/gtt.c  |  5 +
 drivers/gpu/drm/i915/gvt/render.c   | 10 ++
 drivers/gpu/drm/i915/gvt/sched_policy.c | 17 ++---
 drivers/gpu/drm/i915/gvt/scheduler.c|  5 +
 7 files changed, 42 insertions(+), 40 deletions(-)

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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