drivers/gpu/drm/i915/gt/intel_timeline_types.h
Source file repositories/reference/linux-study-clean/drivers/gpu/drm/i915/gt/intel_timeline_types.h
File Facts
- System
- Linux kernel
- Corpus path
drivers/gpu/drm/i915/gt/intel_timeline_types.h- Extension
.h- Size
- 2713 bytes
- Lines
- 93
- Domain
- Driver Families
- Bucket
- drivers/gpu
- Inferred role
- Driver Families: implementation source
- Status
- source 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.
- 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/list.hlinux/kref.hlinux/mutex.hlinux/rcupdate.hlinux/types.hi915_active_types.h
Detected Declarations
struct i915_vmastruct i915_syncmapstruct intel_gtstruct intel_timeline
Annotated Snippet
struct intel_timeline {
u64 fence_context;
u32 seqno;
struct mutex mutex; /* protects the flow of requests */
/*
* pin_count and active_count track essentially the same thing:
* How many requests are in flight or may be under construction.
*
* We need two distinct counters so that we can assign different
* lifetimes to the events for different use-cases. For example,
* we want to permanently keep the timeline pinned for the kernel
* context so that we can issue requests at any time without having
* to acquire space in the GGTT. However, we want to keep tracking
* the activity (to be able to detect when we become idle) along that
* permanently pinned timeline and so end up requiring two counters.
*
* Note that the active_count is protected by the intel_timeline.mutex,
* but the pin_count is protected by a combination of serialisation
* from the intel_context caller plus internal atomicity.
*/
atomic_t pin_count;
atomic_t active_count;
void *hwsp_map;
const u32 *hwsp_seqno;
struct i915_vma *hwsp_ggtt;
u32 hwsp_offset;
bool has_initial_breadcrumb;
/**
* List of breadcrumbs associated with GPU requests currently
* outstanding.
*/
struct list_head requests;
/*
* Contains an RCU guarded pointer to the last request. No reference is
* held to the request, users must carefully acquire a reference to
* the request using i915_active_fence_get(), or manage the RCU
* protection themselves (cf the i915_active_fence API).
*/
struct i915_active_fence last_request;
struct i915_active active;
/** A chain of completed timelines ready for early retirement. */
struct intel_timeline *retire;
/**
* We track the most recent seqno that we wait on in every context so
* that we only have to emit a new await and dependency on a more
* recent sync point. As the contexts may be executed out-of-order, we
* have to track each individually and can not rely on an absolute
* global_seqno. When we know that all tracked fences are completed
* (i.e. when the driver is idle), we know that the syncmap is
* redundant and we can discard it without loss of generality.
*/
struct i915_syncmap *sync;
struct list_head link;
struct intel_gt *gt;
struct list_head engine_link;
struct kref kref;
struct rcu_head rcu;
};
#endif /* __I915_TIMELINE_TYPES_H__ */
Annotation
- Immediate include surface: `linux/list.h`, `linux/kref.h`, `linux/mutex.h`, `linux/rcupdate.h`, `linux/types.h`, `i915_active_types.h`.
- Detected declarations: `struct i915_vma`, `struct i915_syncmap`, `struct intel_gt`, `struct intel_timeline`.
- Atlas domain: Driver Families / drivers/gpu.
- Implementation status: source 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.