Re: [PATCH] drm/xe/guc: skip TDR timeout check when ctx_timestamp is 0 or 1

[Matthew Brost <matthew.brost@intel.com>]

On Fri, Sep 04, 2026 at 06:09:43PM +0000, Jia Yao wrote:

+Umesh

> A ctx_timestamp of 0 or 1 indicates an invalid timestamp:
> - 1 (CONTEXT_ACTIVE) is the cookie written by the WA BB immediately
>   after a full context restore, before the spinner has run.
> - 0 can occur when lrc->ctx_timestamp shadow is uninitialized or was
>   last updated while the context was being restored.
> 
> In both cases the timestamp is not yet valid, so reset the sampling
> baseline and wait for the next check_timeout() call.
> 
> Signed-off-by: Jia Yao <jia.yao@intel.com>
> ---
>  drivers/gpu/drm/xe/xe_guc_submit.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c b/drivers/gpu/drm/xe/xe_guc_submit.c
> index 0a6e2b81b5a5..caf02d265533 100644
> --- a/drivers/gpu/drm/xe/xe_guc_submit.c
> +++ b/drivers/gpu/drm/xe/xe_guc_submit.c
> @@ -1429,6 +1429,20 @@ static bool check_timeout(struct xe_exec_queue *q, struct xe_sched_job *job)
>  		return xe_sched_invalidate_job(job, 0);
>  	}
>  
> +	/*
> +	 * A ctx_timestamp of 0 or 1 indicates an invalid timestamp:
> +	 * - 1 (CONTEXT_ACTIVE) is the cookie written by the WA BB immediately
> +	 *   after a full context restore, before the spinner has run.
> +	 * - 0 can occur when lrc->ctx_timestamp shadow is uninitialized or was
> +	 *   last updated while the context was being restored.
> +	 * In both cases the timestamp is not yet valid, so reset the sampling
> +	 * baseline and wait for the next check_timeout() call.
> +	 */

This isn't right. `ctx_timestamp` is the 32-bit value returned by
`xe_lrc_timestamp()`, so 0 and 1 are valid values when the timestamp
wraps. If you were checking the full 64-bit value, then this might make
sense, although I'm not convinced of that either.

My understanding is that `xe_lrc_timestamp()` only inspects these
special states and takes additional action when 0 or 1 are detected. As
a result, those special values should never be propagated to the caller.
In other words, this is not a raw timestamp read, so we shouldn't need
to handle those cases here.

Umesh to confirm my understanding is correct.

Matt

> +	if (ctx_timestamp <= 1) {
> +		job->sample_timestamp = U64_MAX;
> +		return false;
> +	}
> +
>  	job->sample_timestamp = ctx_timestamp;
>  	ctx_job_timestamp = xe_lrc_ctx_job_timestamp(q->lrc[0]);
>  
> -- 
> 2.43.0
>