[Intel-gfx] [PATCH 18/46] drm/i915: Markup paired operations on display power domains

Chris Wilson chris at chris-wilson.co.uk
Thu Jan 10 10:00:40 UTC 2019


Quoting John Harrison (2019-01-10 00:55:07)
> On 1/7/2019 03:54, Chris Wilson wrote:
> > The majority of runtime-pm operations are bounded and scoped within a
> > function; these are easy to verify that the wakeref are handled
> > correctly. We can employ the compiler to help us, and reduce the number
> > of wakerefs tracked when debugging, by passing around cookies provided
> > by the various rpm_get functions to their rpm_put counterpart. This
> > makes the pairing explicit, and given the required wakeref cookie the
> > compiler can verify that we pass an initialised value to the rpm_put
> > (quite handy for double checking error paths).
> >
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Cc: Jani Nikula <jani.nikula at intel.com>
> > ---
> > diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
> > index b0cbad2e83c5..faff6cf1aaa1 100644
> > --- a/drivers/gpu/drm/i915/i915_perf.c
> > +++ b/drivers/gpu/drm/i915/i915_perf.c
> > @@ -1364,14 +1364,14 @@ static void i915_oa_stream_destroy(struct i915_perf_stream *stream)
> >   
> >       free_oa_buffer(dev_priv);
> >   
> > -     put_oa_config(dev_priv, stream->oa_config);
> > -
> >       intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
> >       intel_runtime_pm_put(dev_priv, stream->wakeref);
> >   
> >       if (stream->ctx)
> >               oa_put_render_ctx_id(stream);
> >   
> > +     put_oa_config(dev_priv, stream->oa_config);
> > +
> >       if (dev_priv->perf.oa.spurious_report_rs.missed) {
> >               DRM_NOTE("%d spurious OA report notices suppressed due to ratelimiting\n",
> >                        dev_priv->perf.oa.spurious_report_rs.missed);
> 
> Is this not reversing a change from patch 9/46? Is there a reason why 
> the oa_config scope needs to change temporarily for some of the series? 
> Or can this diff be folded down and optimised out of both patches?

No, I just applied the removal to the wrong patch. That explains how it
was still in the series when I had thought I had applied the review
comments!
-Chris


More information about the Intel-gfx mailing list