linux-kernel - linux-next: manual merge of the drm tree with the drm-intel-fixes tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20140522154402.5daf8ac6@canb.auug.org.au>
Date:	Thu, 22 May 2014 15:44:02 +1000
From:	Stephen Rothwell <sfr@...b.auug.org.au>
To:	Dave Airlie <airlied@...ux.ie>
Cc:	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Chris Wilson <chris@...is-wilson.co.uk>,
	Zhao Yakui <yakui.zhao@...el.com>
Subject: linux-next: manual merge of the drm tree with the drm-intel-fixes
 tree

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 4eda4e461109
("drm/i915: Prevent negative relocation deltas from wrapping") from the
drm-intel-fixes 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@...b.auug.org.au

diff --cc drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 6651195edcad,47fe8ecef135..000000000000
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@@ -1018,25 -1007,37 +1026,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->ring_index == 0) {
+ 			ring_id = VCS;
+ 			dev_priv->ring_index = 1;
+ 		} else {
+ 			ring_id = VCS2;
+ 			dev_priv->ring_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,

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)