Re: [PATCH v2] drm/xe/gsc: Handle GSCCS ER interrupt

["Teres Alexis, Alan Previn" <alan.previn.teres.alexis@intel.com>]

LGTM - i see the GSC-class specific preemption override in rev2 as
discussed - Thanks.

Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>

On Mon, 2024-03-04 at 06:56 -0800, Daniele Ceraolo Spurio wrote:
> Starting on Xe2, the GSCCS engine reset is a 2-step process. When the
> driver or the GuC hits the GDRST register, the CS is immediately
> reset
> and a success is reported, but the GSC shim continues its reset in
> the
> background. While the shim reset is ongoing, the CS is able to accept
> new context submission, but any commands that require the shim will
> be stalled until the reset is completed. This means that we can keep
> submitting to the GSCCS as long as we make sure that the preemption
> timeout is big enough to cover any delay introduced by the reset;
> since
> the GSC preempt timeout is not tunable at runtime, we only need to
> check
> that the value set in kconfig is big enough (and increase it if it
> isn't).
> When the shim reset completes, a specific CS interrupt is triggered,
> in response to which we need to check the GSCI_TIMER_STATUS register
> to see if the reset was successful or not.
> Note that the GSCI_TIMER_STATUS register is not power save/restored,
> so it gets reset on MC6 entry. However, a reset failure stops MC6,
> so in that scenario we're always guaranteed to find the correct
> value.
> 
> Since we can't check the register within interrupt context, the
> existing GSC worker has been updated to handle it.
> The expected action to take on ER failure is to trigger a driver FLR,
> but we still don't support that, so for now we just print an error. A
> comment has been added to the code to keep track of the FLR
> requirement.
alan:snip