On Thu, 2023-06-08 at 18:14 +0000, Dong, Zhanjun wrote:
> See my comments below.
>
> > -----Original Message-----
> > From: Alan Previn <alan.previn.teres.ale...@intel.com>
alan:snip
> > +static int
> > +__wait_gsc_proxy_completed(struct drm_i915_private *i915,
> > + unsigned long timeout_ms)
> > +{
> > + bool need_to_wait = (IS_ENABLED(CONFIG_INTEL_MEI_GSC_PROXY)
> > &&
> > + i915->media_gt &&
> > + HAS_ENGINE(i915->media_gt, GSC0) &&
> > + intel_uc_fw_is_loadable(&i915->media_gt-
> > > uc.gsc.fw));
> > +
> > + /*
> > + * For gsc proxy component loading + init, we need a much longer
> > timeout
> > + * than what CI selftest infrastrucutre currently uses. This longer wait
> > + * period depends on the kernel config and component driver load
> > ordering
> > + */
> > + if (timeout_ms < 8000)
> > + timeout_ms = 8000;
>
>
> Lgtm, just an concern about the fixed number here, shall we set the minimal
> here, or let i915_selftest.timeout_ms take control? Thus no longer need
> coding change here in the future.
>
> Reviewed-by: Zhanjun Dong <zhanjun.d...@intel.com>
Thanks Zhanjun, unfortunately, based on internal testing,
i915_selftest.timeout_ms default is too
low that it does occasionally timeout for CI. From experience, with a lean
ubuntu config, it typically
takes about ~1 seconds for the mei-gsc-sw-proxy component driver to load after
i915 loads.
Since CI regular unloads and reloads i915, the timeout observed ends up being
reported as issue.
8 seconds was based on internal testing of the worst case scenario - which
hardly ever happens.
We've only seen the 8 second happen when the kernel config has configs enabled
for very many SOC IP
drivers and component driver (seen one at least one customer config) or if the
MTL board IFWI was only
just reflashed (this would be a one-off 8 seconds, we suspect due to the
firmware doing additional steps)
