[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