drm/i915/i915_request.h

62 	 * I915_FENCE_FLAG_ACTIVE - this request is currently submitted to HW.
65 	 * by __i915_request_unsubmit() if we preempt this request.
67 	 * Finally cleared for consistency on retiring the request, when
68 	 * we know the HW is no longer running this request.
75 	 * I915_FENCE_FLAG_PQUEUE - this request is ready for execution
77 	 * Using the scheduler, when a request is ready for execution it is put
87 	 * I915_FENCE_FLAG_HOLD - this request is currently on hold
89 	 * This request has been suspended, pending an ongoing investigation.
94 	 * I915_FENCE_FLAG_INITIAL_BREADCRUMB - this request has the initial
101 	 * I915_FENCE_FLAG_SIGNAL - this request is currently on signal_list
104 	 * a request is on the various signal_list.
109 	 * I915_FENCE_FLAG_NOPREEMPT - this request should not be preempted
112 	 * a sensitive operation as it makes the request super important,
119 	 * I915_FENCE_FLAG_SENTINEL - this request should be last in the queue
121 	 * A high priority sentinel request may be submitted to clear the
122 	 * submission queue. As it will be the only request in-flight, upon
131 	 * I915_FENCE_FLAG_BOOST - upclock the gpu for this request
134 	 * request that the user is waiting on is typically required for
136 	 * the GPU. Here we track such boost requests on a per-request basis.
142  * Request queue structure.
144  * The request queue allows us to note sequence numbers that have been emitted
149  * emission time to be associated with the request for tracking how far ahead
166 	 * Context and ring buffer related to this request
167 	 * Contexts are refcounted, so when this request is associated with a
169 	 * it persists while any request is linked to it. Requests themselves
170 	 * are also refcounted, so the request will only be freed when the last
184 	 * The rcu epoch of when this request was allocated. Used to judiciously
192 	 * We pin the timeline->mutex while constructing the request to
201 	 * Fences for the various phases in the request's lifetime.
203 	 * The submit fence is used to await upon all of the request's
204 	 * dependencies. When it is signaled, the request is ready to run.
205 	 * It is used by the driver to then queue the request for execution.
224 	 * dependency tree for the lifetime of the request (from execbuf
226 	 * request not tied to individual fences.
240 	 * If we need to access the timeline's seqno for this request in
241 	 * another request, we need to keep a read reference to this associated
245 	 * request has not completed and guarded by the timeline mutex.
249 	/** Position in the ring of the start of the request */
262 	/** Position in the ring of the end of the whole request */
268 	/** Preallocate space in the ring for the emitting the request */
271 	/** Batch buffer related to this request if any (used for
279 	 * on the active_list (of their final request).
283 	/** Time at which this request was emitted, in jiffies. */
286 	/** timeline->request entry for this request */
314 struct i915_request *__i915_request_commit(struct i915_request *request);
324 	/* We assume that NULL fence/request are interoperable */  in to_request()
360 bool __i915_request_submit(struct i915_request *request);
361 void i915_request_submit(struct i915_request *request);
363 void __i915_request_unsubmit(struct i915_request *request);
364 void i915_request_unsubmit(struct i915_request *request);
371 #define I915_WAIT_PRIORITY	BIT(1) /* small priority bump for the request */
376 	/* The request may live longer than its HWSP, so check flags first! */  in i915_request_signaled()
413  * @rq: the request, to chase the relevant HW status page
416  * request, but an indication of the current HW state (associated with this
417  * request). Its value will change as the GPU executes more requests.
420  * the local timeline's equivalent) for this request. The request itself
422  * status page has that breadcrumb or later, this request is complete.
441  * i915_request_started - check if the request has begun being executed
442  * @rq: the request
444  * If the timeline is not using initial breadcrumbs, a request is
445  * considered started if the previous request on its timeline (i.e.
450  * it began executing the user payload. A request can therefore be active
454  * If the request has started, its dependencies will have been signaled
458  * However, even if a request has started, it may have been preempted and
463  * Returns true if the request has begun executing the user payload, or
476  * i915_request_is_running - check if the request may actually be executing
477  * @rq: the request
479  * Returns true if the request is currently submitted to hardware, has passed
492  * i915_request_is_ready - check if the request is ready for execution
493  * @rq: the request
495  * Upon construction, the request is instructed to wait upon various
500  * request into its queue and from there submit it for execution. So we
501  * can detect when a request is eligible for execution (and is under control
504  * Returns true if the request is ready for execution (it may be inflight),
560 	/* Valid only while the request is being constructed (or retired). */  in i915_request_timeline()
568 	/* Valid only while the request is being constructed (or retired). */  in i915_request_gem_context()