[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