[Intel-gfx] [PATCH 1/2] drm/i915/guc: prefer 'dev_priv' to 'dev' for static functions

Dave Gordon david.s.gordon at intel.com
Tue Jun 14 13:11:31 UTC 2016


On 13/06/16 10:13, Tvrtko Ursulin wrote:
>
> On 10/06/16 18:29, Dave Gordon wrote:
>> Convert all static functions in i915_guc_submission.c that currently
>> take a 'dev' pointer to take 'dev_priv' instead (there are three,
>> guc_client_alloc(), guc_client_free(), and gem_allocate_guc_obj().
>>
>> Signed-off-by: Dave Gordon <david.s.gordon at intel.com>
>> ---
>>   drivers/gpu/drm/i915/i915_guc_submission.c | 39
>> +++++++++++++++---------------
>>   1 file changed, 19 insertions(+), 20 deletions(-)

[snip]

> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>
> And you can keep the r-b if you rename gem_allocate_guc_obj as Chris has
> suggested.
>
> Regards,
> Tvrtko

I was thinking more of doing a bulk-renaming patch later to make all the 
GuC functions use a more consistent naming scheme, probably along the 
lines of "<prefix><topic>_<object>_<operation>", where <prefix> is empty 
for local functions or intel_/i915_ for externally-visible ones, <topic> 
is probably "guc" for all the functions in the loader and submission 
code, <object> is the class we're manipulating (if it's not the GuC 
itself) and <operation> is what we're doing to it. Fairly standard 
object-based RPN naming, in fact.

Many functions are already named this way, but there's still some legacy 
of Alex's original style which is more topic-verb-object.

So gem_allocate_guc_obj() would become guc_gem_object_alloc(). But I 
probably won't do it until I've finished all the other GuC enhancements ;)

.Dave.


More information about the Intel-gfx mailing list