[Intel-gfx] [PATCH 5/5] drm/i915: Tidy batch pool logic

[Chris Wilson]

On Fri, Feb 13, 2015 at 02:00:50PM +0000, John Harrison wrote:
> >+	list_move_tail(&obj->batch_pool_list, &pool->cache_list);
> Why is it now safe to do a move_tail instead of add_tail if the node
> has just been allocated? Was the original add_tail() wrong or am I
> not spotting some critical difference to how new pool objects are
> created?

The link is initialised in i915_gem_object_init(). It was always safe to
use list_move_tail.

> >+	i915_gem_object_pin_pages(obj);
> Is it worth updating the function description comment to add a line
> about the returned buffer now being pinned and the caller must worry
> about unpinning it?

Didn't even spot that there was a function description. The other choice
is to just push the pinning into the caller, the emphasis was on moving
get_pages() into the allocator, and so for consistency it should also
pin the pages. Will update.

Now I just want to rename it from batch pool to buffer pool...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre