[Intel-gfx] [PATCH 05/22] drm/i915/selftests: Take GEM runtime wakeref

Chris Wilson chris at chris-wilson.co.uk
Mon Apr 1 15:44:26 UTC 2019


Quoting Tvrtko Ursulin (2019-04-01 16:34:11)
> 
> On 25/03/2019 09:03, Chris Wilson wrote:
> > Transition from calling the lower level intel_runtime_pm functions to
> > using the GEM runtime_pm functions (i915_gem_unpark, i915_gem_park) now
> > that they are decoupled from struct_mutex. This has the small advantage
> > of reducing our overhead for request emission and ensuring that GEM
> > state is locked awake during the tests (to reduce interference).
> 
> Too tedious to read in detail. Actually not purely tedious, but 
> inversion of get and unpark (positive and negative) is just constantly 
> hard to read.
> 
> Otherwise there are some aspect of this I like - like more explicitly 
> controlling the GEM/GT readiness, and some which I don't, like: a) 
> churn, b) changing the direction from the recommendation insofar to grab 
> rpm over the smallest section, to now reversing that, and c) 
> i915_gem_unpark as a name was okay in the old world, but if this is now 
> a central API to wake up the device I am not so crazy about the unpark name.

(c) I'll take suggestions over, as I really don't like having to unpark
first. Tempted by i915_gem_runtime_pm_get(), although that may be too
close to intel_runtime_pm_get() that any difference in semantics will
get confusing.

For (b), I'll just say it's now a choice of how long you want to take
the named wakeref for request emission. You can push that down to the
request alloc, but the intention is to change a lot of these callsites
to requiring explicit control of the GEM wakeref so that we can use
a simpler (simpler only in code because it requires more work by the
caller) i915_request_create.
-Chris


More information about the Intel-gfx mailing list