From: "Teres Alexis, Alan Previn" <alan.previn.teres.alexis@intel.com>
To: "tvrtko.ursulin@linux.intel.com" <tvrtko.ursulin@linux.intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>
Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH v4] drm/i915/selftest/gsc: Ensure GSC Proxy init completes before selftests
Date: Wed, 12 Jul 2023 17:49:56 +0000 [thread overview]
Message-ID: <134d8655487a1e2b43eebd4b5bd79962a8a6b285.camel@intel.com> (raw)
In-Reply-To: <564e2cfd-4597-9f90-d8df-bf028519e689@linux.intel.com>
On Wed, 2023-07-12 at 10:19 +0100, Tvrtko Ursulin wrote:
> On 11/07/2023 23:02, Alan Previn wrote:
> > On MTL, if the GSC Proxy init flows haven't completed, submissions to the
> > GSC engine will fail. Those init flows are dependent on the mei's
> > gsc_proxy component that is loaded in parallel with i915 and a
> > worker that could potentially start after i915 driver init is done.
> >
> > That said, all subsytems that access the GSC engine today does check
> > for such init flow completion before using the GSC engine. However,
> > selftests currently don't wait on anything before starting.
> >
> >
> >
alan:snip
> > + /*
> > + * The gsc proxy component depends on the kernel component driver load ordering
> > + * and in corner cases (the first time after an IFWI flash), init-completion
> > + * firmware flows take longer.
> > + */
> > + unsigned long timeout_ms = 8000;
> > +
> > + if (need_to_wait &&
> > + (wait_for(intel_gsc_uc_fw_proxy_init_done(&i915->media_gt->uc.gsc, true),
> > + timeout_ms)))
> > + pr_info(DRIVER_NAME "Timed out waiting for gsc_proxy_completion!\n");
>
> Would it make sense to error out here? Or at least upgrade to pr_warn or
> something?
alan: agree on pr_warn (especially since need_for_wait being true and we tried for 8 secs - this should never happen).
>
> I didn't quite understand the points Daniele raised about engine loops
> and resets - in my mind GSC engine is this special thing exercised for
> highly specialized operations and not touched in random for_each_engine
> loop tests, but I also did not really look so might be totally wrong.
alan: after consulting with Daniele further, the concern in the case of
having gsc-proxy-init mid-execution while other selttests
are running (when thinking of tests that have nothing to do with GSC
but has indirect effect like memory-pressure, engine-resets,
etc) is that the proxy-init will bail-out print an error but
that would result in CI reporting a false-negative. We can't skip
that error since CONFIG_INTEL_MEI_GSC_PROXY tells us that the kernel
owner wants GSC-PROXY working.
>
> In any case, v4 reads clear - no confusing comments and not
> over-engineered so is acceptable to me.
>
alan: thanks Tvrtko.
> P.S. Maybe the check *could* be moved to i915_live_selftests, where hw
> dependencies conceptually fit better, and maybe i915_perf_selftests
> would need it too then (?), but it is up to you.
alan: i can do this quickly as a rev5 (after a bit of manual check if perf needs it)
>
> Maybe even in the array selftests/i915_live_selftests.h if we could add
> a facility to make unskippable tests and add this one after the sanity
> check. Which would then achieve the same generalized thing you had in
> the previous version without needing to add a new array/loop.
alan: i rather not attempt this as part of the current patch but will
consider it as a separate patch if you are okay with that?
next prev parent reply other threads:[~2023-07-12 17:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-11 22:02 [Intel-gfx] [PATCH v4] drm/i915/selftest/gsc: Ensure GSC Proxy init completes before selftests Alan Previn
2023-07-11 22:59 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftest/gsc: Ensure GSC Proxy init completes before selftests (rev4) Patchwork
2023-07-12 1:07 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2023-07-12 9:19 ` [Intel-gfx] [PATCH v4] drm/i915/selftest/gsc: Ensure GSC Proxy init completes before selftests Tvrtko Ursulin
2023-07-12 17:49 ` Teres Alexis, Alan Previn [this message]
2023-07-13 7:40 ` Tvrtko Ursulin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=134d8655487a1e2b43eebd4b5bd79962a8a6b285.camel@intel.com \
--to=alan.previn.teres.alexis@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=tvrtko.ursulin@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox