| Message ID | 20190522193203.23932-9-michal.wajdeczko@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | GuC fixes | expand |
Quoting Michal Wajdeczko (2019-05-22 20:32:02) > Knowing that GuC will be reset soon, we may stop all communication > immediately without doing graceful cleanup as it is not needed. The difference between stop and disable is that it avoids the serialisation, right? Is this patch still required -- do we still need the complication in two similar but subtly different paths? -Chris
On Wed, 22 May 2019 22:06:53 +0200, Chris Wilson <chris@chris-wilson.co.uk> wrote: > Quoting Michal Wajdeczko (2019-05-22 20:32:02) >> Knowing that GuC will be reset soon, we may stop all communication >> immediately without doing graceful cleanup as it is not needed. > > The difference between stop and disable is that it avoids the > serialisation, right? Is this patch still required -- do we still > need the complication in two similar but subtly different paths? This patch helps us capture any unwanted/unexpected attempts to talk with GuC after we decided to reset it. We need 'disable' part as current and upcoming firmware still expects us to do graceful cleanup. This may be changed in the future releases. And we can use 'disable' as this will break atomic_reset tests. -Michal
Quoting Michal Wajdeczko (2019-05-23 16:53:27) > On Wed, 22 May 2019 22:06:53 +0200, Chris Wilson > <chris@chris-wilson.co.uk> wrote: > > > Quoting Michal Wajdeczko (2019-05-22 20:32:02) > >> Knowing that GuC will be reset soon, we may stop all communication > >> immediately without doing graceful cleanup as it is not needed. > > > > The difference between stop and disable is that it avoids the > > serialisation, right? Is this patch still required -- do we still > > need the complication in two similar but subtly different paths? > > This patch helps us capture any unwanted/unexpected attempts to talk > with GuC after we decided to reset it. We need 'disable' part as current > and upcoming firmware still expects us to do graceful cleanup. This may > be changed in the future releases. And we can use 'disable' as this will > break atomic_reset tests. Please promote that to the commitmsg :) -Chris
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.h b/drivers/gpu/drm/i915/intel_guc_ct.h index f5e7f0663304..41ba593a4df7 100644 --- a/drivers/gpu/drm/i915/intel_guc_ct.h +++ b/drivers/gpu/drm/i915/intel_guc_ct.h @@ -96,4 +96,9 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct); int intel_guc_ct_enable(struct intel_guc_ct *ct); void intel_guc_ct_disable(struct intel_guc_ct *ct); +static inline void intel_guc_ct_stop(struct intel_guc_ct *ct) +{ + ct->host_channel.enabled = false; +} + #endif /* _INTEL_GUC_CT_H_ */ diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 3d81a512e5c8..f17cb3dad90b 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -224,6 +224,17 @@ static int guc_enable_communication(struct intel_guc *guc) return 0; } +static void guc_stop_communication(struct intel_guc *guc) +{ + struct drm_i915_private *i915 = guc_to_i915(guc); + + if (HAS_GUC_CT(i915)) + intel_guc_ct_stop(&guc->ct); + + guc->send = intel_guc_send_nop; + guc->handler = intel_guc_to_host_event_handler_nop; +} + static void guc_disable_communication(struct intel_guc *guc) { struct drm_i915_private *i915 = guc_to_i915(guc); @@ -485,7 +496,7 @@ void intel_uc_reset_prepare(struct drm_i915_private *i915) if (!USES_GUC(i915)) return; - guc_disable_communication(guc); + guc_stop_communication(guc); __uc_sanitize(i915); }
Knowing that GuC will be reset soon, we may stop all communication immediately without doing graceful cleanup as it is not needed. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> --- drivers/gpu/drm/i915/intel_guc_ct.h | 5 +++++ drivers/gpu/drm/i915/intel_uc.c | 13 ++++++++++++- 2 files changed, 17 insertions(+), 1 deletion(-)