Re: [PATCH 5/5] drm/i915: Tidy batch pool logic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux