linux-next: manual merge of the drm tree with Linus' tree

[Stephen Rothwell]

Hi Dave,

Today's linux-next merge of the drm tree got a conflict in
drivers/gpu/drm/i915/i915_gem_execbuffer.c between commit d23db88c3ab2
("drm/i915: Prevent negative relocation deltas from wrapping") from
Linus' tree and commit a8ebba75b358 ("drm/i915: Use the coarse
ping-pong mechanism based on drm fd to dispatch the BSD command on BDW
GT3") from the drm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@xxxxxxxxxxxxxxxx

diff --cc drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 20fef6c50267,008e208e9a3a..000000000000
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@@ -597,38 -595,8 +600,38 @@@ i915_gem_execbuffer_reserve_vma(struct 
  	return 0;
  }
  
 +static bool
 +eb_vma_misplaced(struct i915_vma *vma, bool has_fenced_gpu_access)
 +{
 +	struct drm_i915_gem_exec_object2 *entry = vma->exec_entry;
 +	struct drm_i915_gem_object *obj = vma->obj;
 +	bool need_fence, need_mappable;
 +
 +	need_fence =
 +		has_fenced_gpu_access &&
 +		entry->flags & EXEC_OBJECT_NEEDS_FENCE &&
 +		obj->tiling_mode != I915_TILING_NONE;
 +	need_mappable = need_fence || need_reloc_mappable(vma);
 +
 +	WARN_ON((need_mappable || need_fence) &&
 +	       !i915_is_ggtt(vma->vm));
 +
 +	if (entry->alignment &&
 +	    vma->node.start & (entry->alignment - 1))
 +		return true;
 +
 +	if (need_mappable && !obj->map_and_fenceable)
 +		return true;
 +
 +	if (entry->flags & __EXEC_OBJECT_NEEDS_BIAS &&
 +	    vma->node.start < BATCH_OFFSET_BIAS)
 +		return true;
 +
 +	return false;
 +}
 +
  static int
- i915_gem_execbuffer_reserve(struct intel_ring_buffer *ring,
+ i915_gem_execbuffer_reserve(struct intel_engine_cs *ring,
  			    struct list_head *vmas,
  			    bool *need_relocs)
  {
@@@ -1018,25 -1009,37 +1028,56 @@@ i915_reset_gen7_sol_offsets(struct drm_
  	return 0;
  }
  
 +static struct drm_i915_gem_object *
 +eb_get_batch(struct eb_vmas *eb)
 +{
 +	struct i915_vma *vma = list_entry(eb->vmas.prev, typeof(*vma), exec_list);
 +
 +	/*
 +	 * SNA is doing fancy tricks with compressing batch buffers, which leads
 +	 * to negative relocation deltas. Usually that works out ok since the
 +	 * relocate address is still positive, except when the batch is placed
 +	 * very low in the GTT. Ensure this doesn't happen.
 +	 *
 +	 * Note that actual hangs have only been observed on gen7, but for
 +	 * paranoia do it everywhere.
 +	 */
 +	vma->exec_entry->flags |= __EXEC_OBJECT_NEEDS_BIAS;
 +
 +	return vma->obj;
 +}
 +
+ /**
+  * Find one BSD ring to dispatch the corresponding BSD command.
+  * The Ring ID is returned.
+  */
+ static int gen8_dispatch_bsd_ring(struct drm_device *dev,
+ 				  struct drm_file *file)
+ {
+ 	struct drm_i915_private *dev_priv = dev->dev_private;
+ 	struct drm_i915_file_private *file_priv = file->driver_priv;
+ 
+ 	/* Check whether the file_priv is using one ring */
+ 	if (file_priv->bsd_ring)
+ 		return file_priv->bsd_ring->id;
+ 	else {
+ 		/* If no, use the ping-pong mechanism to select one ring */
+ 		int ring_id;
+ 
+ 		mutex_lock(&dev->struct_mutex);
+ 		if (dev_priv->mm.bsd_ring_dispatch_index == 0) {
+ 			ring_id = VCS;
+ 			dev_priv->mm.bsd_ring_dispatch_index = 1;
+ 		} else {
+ 			ring_id = VCS2;
+ 			dev_priv->mm.bsd_ring_dispatch_index = 0;
+ 		}
+ 		file_priv->bsd_ring = &dev_priv->ring[ring_id];
+ 		mutex_unlock(&dev->struct_mutex);
+ 		return ring_id;
+ 	}
+ }
+ 
  static int
  i915_gem_do_execbuffer(struct drm_device *dev, void *data,
  		       struct drm_file *file,

Attachment: signature.asc
Description: PGP signature