RE: [PATCH v4] drm/i915/gt: Use poll_timeout_us in place of sliding sleep window

-----Original Message-----
From: Andi Shyti <[email protected]> 
Sent: Friday, July 24, 2026 5:50 AM
To: Cavitt, Jonathan <[email protected]>
Cc: [email protected]; Zuo, Alex <[email protected]>; [email protected]; Shyti, Andi <[email protected]>; Karas, Krzysztof <[email protected]>
Subject: Re: [PATCH v4] drm/i915/gt: Use poll_timeout_us in place of sliding sleep window
> 
> Hi Jonathan,
> 
> ...
> 
> > +	/*
> > +	 * We use a lazy spin wait loop here as we believe that if the CT
> > +	 * buffers are sized correctly the flow control condition should be
> > +	 * rare. Reserving the maximum size in the G2H credits as we don't know
> > +	 * how big the response is going to be.
> > +	 */
> > +	timedout = poll_timeout_us_atomic(err = ct_lazy_spin(ct, &request, action,
> > +							     len, response_buf,
> > +							     response_buf_size,
> > +							     status),
> > +					  err != -EBUSY, USEC_PER_MSEC,
> > +					  POLL_TIMEOUT_DUR, false);
> 
> now poll timeout is not running in atomic context, is there any
> problem in using simply poll_timeout_us() instead of its
> _atomic() brother?

I... don't know?  I guess I can swap it over and we can see if something breaks
during CI validation.
-Jonathan Cavitt

> 
> Andi
> 
> > +
> > +	/* This is only the case if ct is deadlocked or we time out */
> > +	if (ct->stall_time != KTIME_MAX)
> > +		return timedout ?: err;
> > +
> > +	/* Otherwise, ct_write failed and we need to clean up */
> >  	if (unlikely(err))
> >  		goto unlink;
> >  
> > -- 
> > 2.53.0
> > 
>