drivers/gpu/drm/i915/i915_request.c
Source file repositories/reference/linux-study-clean/drivers/gpu/drm/i915/i915_request.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/gpu/drm/i915/i915_request.c- Extension
.c- Size
- 68143 bytes
- Lines
- 2316
- 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-array.hlinux/dma-fence-chain.hlinux/irq_work.hlinux/prefetch.hlinux/sched.hlinux/sched/clock.hlinux/sched/signal.hlinux/sched/mm.hdrm/drm_print.hgem/i915_gem_context.hgt/intel_breadcrumbs.hgt/intel_context.hgt/intel_engine.hgt/intel_engine_heartbeat.hgt/intel_engine_regs.hgt/intel_gpu_commands.hgt/intel_reset.hgt/intel_ring.hgt/intel_rps.hi915_active.hi915_config.hi915_deps.hi915_driver.hi915_drv.hi915_trace.hselftests/mock_request.cselftests/i915_request.c
Detected Declarations
struct execute_cbstruct request_waitfunction i915_fence_signaledfunction i915_fence_enable_signalingfunction i915_fence_waitfunction i915_fence_releasefunction irq_execute_cbfunction __notify_execute_cbfunction __notify_execute_cb_irqfunction irq_work_immfunction i915_request_notify_execute_cb_immfunction __i915_request_fillfunction i915_request_active_enginefunction __rq_watchdog_expiredfunction __rq_init_watchdogfunction __rq_arm_watchdogfunction __rq_cancel_watchdogfunction i915_request_free_capture_listfunction i915_request_retirefunction i915_request_retire_uptofunction __engine_activefunction __request_in_flightfunction __await_executionfunction i915_request_submitfunction fatal_errorfunction __i915_request_skipfunction i915_request_set_error_oncefunction __i915_request_submitfunction i915_request_submitfunction __i915_request_unsubmitfunction timelinefunction i915_request_cancelfunction submit_notifyfunction semaphore_notifyfunction retire_requestsfunction request_alloc_slowfunction __i915_request_ctorfunction __i915_request_createfunction i915_request_createfunction i915_request_await_startfunction already_busywaitingfunction __emit_semaphore_waitfunction can_use_semaphore_waitfunction emit_semaphore_waitfunction intel_timeline_sync_has_startfunction intel_timeline_sync_set_startfunction __i915_request_await_executionfunction time
Annotated Snippet
struct execute_cb {
struct irq_work work;
struct i915_sw_fence *fence;
};
static struct kmem_cache *slab_requests;
static struct kmem_cache *slab_execute_cbs;
static const char *i915_fence_get_driver_name(struct dma_fence *fence)
{
return dev_name(to_request(fence)->i915->drm.dev);
}
static const char *i915_fence_get_timeline_name(struct dma_fence *fence)
{
const struct i915_gem_context *ctx;
/*
* The timeline struct (as part of the ppgtt underneath a context)
* may be freed when the request is no longer in use by the GPU.
* We could extend the life of a context to beyond that of all
* fences, possibly keeping the hw resource around indefinitely,
* or we just give them a false name. Since
* dma_fence_ops.get_timeline_name is a debug feature, the occasional
* lie seems justifiable.
*/
if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
return "signaled";
ctx = i915_request_gem_context(to_request(fence));
if (!ctx)
return "[" DRIVER_NAME "]";
return ctx->name;
}
static bool i915_fence_signaled(struct dma_fence *fence)
{
return i915_request_completed(to_request(fence));
}
static bool i915_fence_enable_signaling(struct dma_fence *fence)
{
return i915_request_enable_breadcrumb(to_request(fence));
}
static signed long i915_fence_wait(struct dma_fence *fence,
bool interruptible,
signed long timeout)
{
return i915_request_wait_timeout(to_request(fence),
interruptible | I915_WAIT_PRIORITY,
timeout);
}
struct kmem_cache *i915_request_slab_cache(void)
{
return slab_requests;
}
static void i915_fence_release(struct dma_fence *fence)
{
struct i915_request *rq = to_request(fence);
GEM_BUG_ON(rq->guc_prio != GUC_PRIO_INIT &&
rq->guc_prio != GUC_PRIO_FINI);
i915_request_free_capture_list(fetch_and_zero(&rq->capture_list));
if (rq->batch_res) {
i915_vma_resource_put(rq->batch_res);
rq->batch_res = NULL;
}
/*
* The request is put onto a RCU freelist (i.e. the address
* is immediately reused), mark the fences as being freed now.
* Otherwise the debugobjects for the fences are only marked as
* freed when the slab cache itself is freed, and so we would get
* caught trying to reuse dead objects.
*/
i915_sw_fence_fini(&rq->submit);
i915_sw_fence_fini(&rq->semaphore);
/*
* Keep one request on each engine for reserved use under mempressure.
*
* We do not hold a reference to the engine here and so have to be
* very careful in what rq->engine we poke. The virtual engine is
* referenced via the rq->context and we released that ref during
* i915_request_retire(), ergo we must not dereference a virtual
Annotation
- Immediate include surface: `linux/dma-fence-array.h`, `linux/dma-fence-chain.h`, `linux/irq_work.h`, `linux/prefetch.h`, `linux/sched.h`, `linux/sched/clock.h`, `linux/sched/signal.h`, `linux/sched/mm.h`.
- Detected declarations: `struct execute_cb`, `struct request_wait`, `function i915_fence_signaled`, `function i915_fence_enable_signaling`, `function i915_fence_wait`, `function i915_fence_release`, `function irq_execute_cb`, `function __notify_execute_cb`, `function __notify_execute_cb_irq`, `function irq_work_imm`.
- 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.