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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
