Chris Wilson <chris@chris-wilson.co.uk>

Chris Wilson <chris@chris-wilson.co.uk>

[Peter Clifton]

[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]

Non-fastforward of drm-intel-next

Hi Chris,

I was looking at logs of the drm-intel-next branch, and noted that one
of the commits:

commit b5dc608c98d929abbf2fe932ed07b3c868d83342
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Oct 20 20:59:57 2010 +0100

    drm/i915: Copy the updated reloc->presumed_offset back to the user

Refers to a regression introduced in commit 12f889c

That commit is not in the git history for drm-intel-next, as it was
killed by a non-fast-forward push.

I've not quite been able to figure out what the non-fast-forward commit
was all about (whether it was a rebase or something?), but I noted in my
reflogs:

git reflog show --date=rfc drm-intel/drm-intel-next
297b0c5 refs/remotes/drm-intel/drm-intel-next@{Fri, 22 Oct 2010 21:39:05 +0100}: fetch drm-intel: fast-forward
878a3c3 refs/remotes/drm-intel/drm-intel-next@{Fri, 22 Oct 2010 12:36:57 +0100}: fetch drm-intel: fast-forward
b5dc608 refs/remotes/drm-intel/drm-intel-next@{Thu, 21 Oct 2010 00:28:04 +0100}: fetch drm-intel: fast-forward
69dc498 refs/remotes/drm-intel/drm-intel-next@{Wed, 20 Oct 2010 14:05:40 +0100}: fetch drm-intel: forced-update
36eb1cd refs/remotes/drm-intel/drm-intel-next@{Tue, 19 Oct 2010 21:27:46 +0100}: fetch drm-intel: fast-forward
12f889c refs/remotes/drm-intel/drm-intel-next@{Tue, 19 Oct 2010 21:13:20 +0100}: fetch drm-intel: fast-forward
2d7b836 refs/remotes/drm-intel/drm-intel-next@{Wed, 13 Oct 2010 17:53:30 +0100}: fetch drm-intel: storing head

And that around the forced update, we have this delta. Was it intentional?

(Attached).

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)

[-- Attachment #2: forced_update_36eb1cd..69dc498.diff --]
[-- Type: text/x-patch, Size: 2491 bytes --]

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1ce109a..6e85496 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1580,7 +1580,7 @@ i915_gem_object_move_to_active(struct drm_gem_object *obj,
 
 	/* Move from whatever list we were on to the tail of execution. */
 	list_move_tail(&obj_priv->mm_list, &dev_priv->mm.active_list);
-	list_add_tail(&obj_priv->ring_list, &ring->active_list);
+	list_move_tail(&obj_priv->ring_list, &ring->active_list);
 	obj_priv->last_rendering_seqno = seqno;
 }
 
@@ -1593,7 +1593,7 @@ i915_gem_object_move_to_flushing(struct drm_gem_object *obj)
 
 	BUG_ON(!obj_priv->active);
 	list_move_tail(&obj_priv->mm_list, &dev_priv->mm.flushing_list);
-	list_del(&obj_priv->ring_list);
+	list_del_init(&obj_priv->ring_list);
 	obj_priv->last_rendering_seqno = 0;
 }
 
@@ -1635,7 +1635,7 @@ i915_gem_object_move_to_inactive(struct drm_gem_object *obj)
 		list_move_tail(&obj_priv->mm_list, &dev_priv->mm.pinned_list);
 	else
 		list_move_tail(&obj_priv->mm_list, &dev_priv->mm.inactive_list);
-	list_del(&obj_priv->ring_list);
+	list_del_init(&obj_priv->ring_list);
 
 	BUG_ON(!list_empty(&obj_priv->gpu_write_list));
 
@@ -1880,7 +1880,7 @@ i915_gem_retire_requests_ring(struct drm_device *dev,
 
 		obj_priv = list_first_entry(&ring->active_list,
 					    struct drm_i915_gem_object,
-					    mm_list);
+					    ring_list);
 
 		if (!i915_seqno_passed(seqno, obj_priv->last_rendering_seqno))
 			break;
@@ -3246,17 +3246,16 @@ i915_gem_execbuffer_relocate(struct drm_i915_gem_object *obj,
 	struct drm_i915_gem_relocation_entry __user *user_relocs;
 	struct drm_gem_object *target_obj = NULL;
 	uint32_t target_handle = 0;
-	int i, ret;
+	int i, ret = 0;
 
 	user_relocs = (void __user *)(uintptr_t)entry->relocs_ptr;
 	for (i = 0; i < entry->relocation_count; i++) {
 		struct drm_i915_gem_relocation_entry reloc;
 		uint32_t target_offset;
 
-		ret = __copy_from_user_inatomic(&reloc,
-						user_relocs+i,
-						sizeof(reloc));
-		if (ret) {
+		if (__copy_from_user_inatomic(&reloc,
+					      user_relocs+i,
+					      sizeof(reloc))) {
 			ret = -EFAULT;
 			break;
 		}
@@ -4286,6 +4285,7 @@ struct drm_gem_object * i915_gem_alloc_object(struct drm_device *dev,
 	obj->base.driver_private = NULL;
 	obj->fence_reg = I915_FENCE_REG_NONE;
 	INIT_LIST_HEAD(&obj->mm_list);
+	INIT_LIST_HEAD(&obj->ring_list);
 	INIT_LIST_HEAD(&obj->gpu_write_list);
 	obj->madv = I915_MADV_WILLNEED;
 

[-- Attachment #3: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Chris Wilson <chris@chris-wilson.co.uk>

[Peter Clifton]

On Fri, 2010-10-22 at 23:48 +0100, Peter Clifton wrote:
> Non-fastforward of drm-intel-next
> 
> Hi Chris,

Sorry.. meant to 'CC you, and appear to have dropped your email in the
subject line.

I hope this doesn't get you too much more spam through the address being
prominently visible in mail archives.

Sorry once again!

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)

Re: Chris Wilson <chris@chris-wilson.co.uk>

[Chris Wilson]

On Fri, 22 Oct 2010 23:48:01 +0100, Peter Clifton <pcjc2@cam.ac.uk> wrote:
> Non-fastforward of drm-intel-next

Damn, you weren't meant to spot that the major snafu I had separating out
the requests into a per-ring and global lists. That was what I was trying
to hide...

Time to bury my shame,
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre