[Intel-gfx] [PATCH v3 1/3] drm/i915: simplify allocation of driver-internal requests

[Dave Gordon]

On 12/01/16 14:27, Chris Wilson wrote:
> On Tue, Jan 12, 2016 at 01:56:48PM +0000, Chris Wilson wrote:
>> But we were removing the engine->default_context as it complicated the
>> rest of the code. I strongly prefer keeping the contexts explicit as
>> context separation should be first and foremost in the driver.
>
> $ git grep kernel_context -- drivers/gpu/drm/i915/ | grep request_alloc
> drivers/gpu/drm/i915/i915_gem_evict.c:		req = i915_gem_request_alloc(ring, dev_priv->kernel_context);
> drivers/gpu/drm/i915/intel_overlay.c:	return i915_gem_request_alloc(ring, dev_priv->kernel_context);
>
> Changing those *two* callsites to pass NULL seems on the odd side, and
> at least for the eviction case discards important information.
> -Chris

Those specific lines won't be touched by my patch, as *they don't 
actually exist in today's drm-intel-nightly* branch. If you want to add 
*new* calls to i915_gem_request_alloc() such as the above then you're 
quite free to pass any context you want, whether it's a real user 
context, the default kernel context explicitly, if you think it's 
important that the reader know that that specific context will be used; 
or NULL if you don't care what context is used.

dev_priv->kernel_context carries exactly the same amount of information 
as NULL; they both mean "I don't have a specific context to use here, so 
(I'm going to) use the one the driver provides for such activities". 
Having the option of using NULL rather than"dev_priv->kernel_context" 
explicitly doesn't prevent you from doing so where the caller cares. But 
I think most callers *don't* care.

.Dave.