drivers/gpu/drm/i915/i915_request.h
Source file repositories/reference/linux-study-clean/drivers/gpu/drm/i915/i915_request.h
File Facts
- System
- Linux kernel
- Corpus path
drivers/gpu/drm/i915/i915_request.h- Extension
.h- Size
- 23520 bytes
- Lines
- 734
- Domain
- Driver Families
- Bucket
- drivers/gpu
- Inferred role
- Driver Families: exported/initcall integration point
- Status
- integration implementation candidate
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Exports symbols or registers init work; inspect boot/module ordering and who consumes the exported contract.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/dma-fence.hlinux/hrtimer.hlinux/irq_work.hlinux/llist.hlinux/lockdep.huapi/drm/i915_drm.hgem/i915_gem_context_types.hgt/intel_context_types.hgt/intel_engine_types.hgt/intel_timeline_types.hi915_gem.hi915_ptr_util.hi915_scheduler.hi915_selftest.hi915_sw_fence.hi915_vma_resource.h
Detected Declarations
struct drm_filestruct drm_i915_gem_objectstruct drm_printerstruct i915_depsstruct i915_requeststruct i915_capture_liststruct i915_requeststruct i915_request_duration_cbstruct i915_request_watchdogenum i915_request_statefunction dma_fence_is_i915function to_requestfunction i915_request_getfunction i915_request_get_rcufunction i915_request_putfunction i915_request_signaledfunction i915_request_is_activefunction i915_request_in_priority_queuefunction i915_request_has_initial_breadcrumbfunction i915_seqno_passedfunction __hwsp_seqnofunction hwsp_seqnofunction __i915_request_has_startedfunction timelinefunction pointfunction executionfunction __i915_request_is_completefunction i915_request_completedfunction i915_request_mark_completefunction i915_request_has_waitboostfunction i915_request_has_nopreemptfunction i915_request_has_sentinelfunction i915_request_on_holdfunction i915_request_set_holdfunction i915_request_clear_holdfunction i915_request_timelinefunction i915_request_gem_contextfunction i915_request_active_timelinefunction i915_request_active_seqno
Annotated Snippet
struct i915_capture_list {
struct i915_vma_resource *vma_res;
struct i915_capture_list *next;
};
void i915_request_free_capture_list(struct i915_capture_list *capture);
#else
#define i915_request_free_capture_list(_a) do {} while (0)
#endif
#define RQ_TRACE(rq, fmt, ...) do { \
const struct i915_request *rq__ = (rq); \
ENGINE_TRACE(rq__->engine, "fence %llx:%lld, current %d " fmt, \
rq__->fence.context, rq__->fence.seqno, \
hwsp_seqno(rq__), ##__VA_ARGS__); \
} while (0)
enum {
/*
* I915_FENCE_FLAG_ACTIVE - this request is currently submitted to HW.
*
* Set by __i915_request_submit() on handing over to HW, and cleared
* by __i915_request_unsubmit() if we preempt this request.
*
* Finally cleared for consistency on retiring the request, when
* we know the HW is no longer running this request.
*
* See i915_request_is_active()
*/
I915_FENCE_FLAG_ACTIVE = DMA_FENCE_FLAG_USER_BITS,
/*
* I915_FENCE_FLAG_PQUEUE - this request is ready for execution
*
* Using the scheduler, when a request is ready for execution it is put
* into the priority queue, and removed from that queue when transferred
* to the HW runlists. We want to track its membership within the
* priority queue so that we can easily check before rescheduling.
*
* See i915_request_in_priority_queue()
*/
I915_FENCE_FLAG_PQUEUE,
/*
* I915_FENCE_FLAG_HOLD - this request is currently on hold
*
* This request has been suspended, pending an ongoing investigation.
*/
I915_FENCE_FLAG_HOLD,
/*
* I915_FENCE_FLAG_INITIAL_BREADCRUMB - this request has the initial
* breadcrumb that marks the end of semaphore waits and start of the
* user payload.
*/
I915_FENCE_FLAG_INITIAL_BREADCRUMB,
/*
* I915_FENCE_FLAG_SIGNAL - this request is currently on signal_list
*
* Internal bookkeeping used by the breadcrumb code to track when
* a request is on the various signal_list.
*/
I915_FENCE_FLAG_SIGNAL,
/*
* I915_FENCE_FLAG_NOPREEMPT - this request should not be preempted
*
* The execution of some requests should not be interrupted. This is
* a sensitive operation as it makes the request super important,
* blocking other higher priority work. Abuse of this flag will
* lead to quality of service issues.
*/
I915_FENCE_FLAG_NOPREEMPT,
/*
* I915_FENCE_FLAG_SENTINEL - this request should be last in the queue
*
* A high priority sentinel request may be submitted to clear the
* submission queue. As it will be the only request in-flight, upon
* execution all other active requests will have been preempted and
* unsubmitted. This preemptive pulse is used to re-evaluate the
* in-flight requests, particularly in cases where an active context
* is banned and those active requests need to be cancelled.
*/
I915_FENCE_FLAG_SENTINEL,
/*
* I915_FENCE_FLAG_BOOST - upclock the gpu for this request
*
Annotation
- Immediate include surface: `linux/dma-fence.h`, `linux/hrtimer.h`, `linux/irq_work.h`, `linux/llist.h`, `linux/lockdep.h`, `uapi/drm/i915_drm.h`, `gem/i915_gem_context_types.h`, `gt/intel_context_types.h`.
- Detected declarations: `struct drm_file`, `struct drm_i915_gem_object`, `struct drm_printer`, `struct i915_deps`, `struct i915_request`, `struct i915_capture_list`, `struct i915_request`, `struct i915_request_duration_cb`, `struct i915_request_watchdog`, `enum i915_request_state`.
- Atlas domain: Driver Families / drivers/gpu.
- Implementation status: integration implementation candidate.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.