Quoting Daniele Ceraolo Spurio (2019-07-30 00:47:26) > intel_uc is part of intel_gt so it makes logical sense for it to be > resumed as part of it. Note that, since gt_resume is also called during > the init flow, a state variable has been added to intel_uc to avoid > asking an already running GuC to resume. > > Signed-off-by: Daniele Ceraolo Spurio <[email protected]> > Cc: Michal Wajdeczko <[email protected]> > Cc: Chris Wilson <[email protected]> > --- > drivers/gpu/drm/i915/gem/i915_gem_pm.c | 2 -- > drivers/gpu/drm/i915/gt/intel_gt_pm.c | 3 +++ > drivers/gpu/drm/i915/gt/uc/intel_uc.c | 10 ++++++++-- > drivers/gpu/drm/i915/gt/uc/intel_uc.h | 2 ++ > 4 files changed, 13 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c > b/drivers/gpu/drm/i915/gem/i915_gem_pm.c > index b5561cbdc5ea..25610de3961b 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c > @@ -265,8 +265,6 @@ void i915_gem_resume(struct drm_i915_private *i915) > if (intel_gt_resume(&i915->gt)) > goto err_wedged; > > - intel_uc_resume(&i915->gt.uc); > - > /* Always reload a context for powersaving. */ > if (!i915_gem_load_power_context(i915)) > goto err_wedged;
This sequence itself does not belong to i915_gem_resume() and needs to be lifted to intel_gt_resume (that is establishing the baseline GT power context). So I would rather postpone this to try and avoid having to introduce bool suspended if at all possible. Another rule of thumb to consider is that we should be able to throw gt initialisation into an async task (and I'm considering an async task per engine, although for a large part we can achieve asynchronicity via HW queues). -Chris _______________________________________________ Intel-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/intel-gfx
