[Intel-gfx] [PATCH 55/55] drm/i915: Rename the somewhat reduced i915_gem_object_flush_active()

[Chris Wilson]

On Thu, Jun 18, 2015 at 12:03:12PM +0100, John Harrison wrote:
> On 17/06/2015 15:21, Chris Wilson wrote:
> >On Wed, Jun 17, 2015 at 04:06:05PM +0200, Daniel Vetter wrote:
> >>On Fri, May 29, 2015 at 05:44:16PM +0100, John.C.Harrison at Intel.com wrote:
> >>>From: John Harrison <John.C.Harrison at Intel.com>
> >>>
> >>>The i915_gem_object_flush_active() call used to do lots. Over time it has done
> >>>less and less. Now all it does check the various associated requests to see if
> >>>they can be retired. Hence this patch renames the function and updates the
> >>>comments around it to match the current operation.
> >>>
> >>>For: VIZ-5115
> >>>Signed-off-by: John Harrison <John.C.Harrison at Intel.com>
> >>When rebasing patches and especially like here when also renaming them a
> >>bit please leave some indication of what you've changed. Took me a while
> >>to figure out where one of my pending comments from the previous round
> >>went too.
> >>
> >>And please don't just "v2: rebase", but please add some indicators against
> >>what it conflicted if it's obvious.
> >This function doesn't do an unconditional retire - the new name is much
> >worse since it is inconsistent with how requests retire. In my make GEM
> >umpteen times faster patches, I repurposed this function for reporting
> >the object's current activeness and called it bool i915_gem_oject_active()
> >  - though that is probably better as i915_gem_object_is_active().
> >-Chris
> >
> 
> Retiring is generally not an unconditional operation.

In the code, I use <object>_retire to perform the retiring operation on
that object. I can rename i915_gem_retire_requests if that makes you
happier, but I don't think it needs to since retire_requests does not
imply to me that all requests are retired, just some indefinite value
(though positive indefinite at least!).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre