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

[John Harrison]

On 18/06/2015 12:10, Chris Wilson wrote:
> 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
>

Fair enough. I guess I'm still thinking of the driver as it was when I 
first wrote the patch series which was before your re-write for 
read/read optimisations. Like I said, the exact new name isn't as 
important as at least giving it a new name. The old name is definitely 
not valid any more. Feel free to suggest something better.