| Message ID | 20210624070516.21893-2-matthew.brost@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | GuC submission support | expand |
On 24.06.2021 09:04, Matthew Brost wrote: > In upcoming patch we will allow more CTB requests to be sent in > parallel to the GuC for processing, so we shouldn't assume any more > that GuC will always reply without 10ms. > > Use bigger value hardcoded value of 1s instead. > > v2: Add CONFIG_DRM_I915_GUC_CTB_TIMEOUT config option > v3: > (Daniel Vetter) > - Use hardcoded value of 1s rather than config option > > Signed-off-by: Matthew Brost <matthew.brost@intel.com> > Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> > --- > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c > index 43409044528e..a59e239497ee 100644 > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c > @@ -474,14 +474,16 @@ static int wait_for_ct_request_update(struct ct_request *req, u32 *status) > /* > * Fast commands should complete in less than 10us, so sample quickly > * up to that length of time, then switch to a slower sleep-wait loop. > - * No GuC command should ever take longer than 10ms. > + * No GuC command should ever take longer than 10ms but many GuC > + * commands can be inflight at time, so use a 1s timeout on the slower > + * sleep-wait loop. > */ > #define done \ > (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \ > GUC_HXG_ORIGIN_GUC) > err = wait_for_us(done, 10); > if (err) > - err = wait_for(done, 10); > + err = wait_for(done, 1000); can we add #defines for these 10/1000 values? with that Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> > #undef done > > if (unlikely(err)) >
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c index 43409044528e..a59e239497ee 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c @@ -474,14 +474,16 @@ static int wait_for_ct_request_update(struct ct_request *req, u32 *status) /* * Fast commands should complete in less than 10us, so sample quickly * up to that length of time, then switch to a slower sleep-wait loop. - * No GuC command should ever take longer than 10ms. + * No GuC command should ever take longer than 10ms but many GuC + * commands can be inflight at time, so use a 1s timeout on the slower + * sleep-wait loop. */ #define done \ (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \ GUC_HXG_ORIGIN_GUC) err = wait_for_us(done, 10); if (err) - err = wait_for(done, 10); + err = wait_for(done, 1000); #undef done if (unlikely(err))
In upcoming patch we will allow more CTB requests to be sent in parallel to the GuC for processing, so we shouldn't assume any more that GuC will always reply without 10ms. Use bigger value hardcoded value of 1s instead. v2: Add CONFIG_DRM_I915_GUC_CTB_TIMEOUT config option v3: (Daniel Vetter) - Use hardcoded value of 1s rather than config option Signed-off-by: Matthew Brost <matthew.brost@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> --- drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)