xref: /linux/drivers/gpu/drm/i915/gt/intel_timeline_types.h (revision 8be98d2f2a0a262f8bf8a0bc1fdf522b3c7aab17)
1 /* SPDX-License-Identifier: MIT */
2 /*
3  * Copyright © 2016 Intel Corporation
4  */
5 
6 #ifndef __I915_TIMELINE_TYPES_H__
7 #define __I915_TIMELINE_TYPES_H__
8 
9 #include <linux/list.h>
10 #include <linux/kref.h>
11 #include <linux/mutex.h>
12 #include <linux/rcupdate.h>
13 #include <linux/types.h>
14 
15 #include "i915_active_types.h"
16 
17 struct i915_vma;
18 struct i915_syncmap;
19 struct intel_gt;
20 
21 struct intel_timeline {
22 	u64 fence_context;
23 	u32 seqno;
24 
25 	struct mutex mutex; /* protects the flow of requests */
26 
27 	/*
28 	 * pin_count and active_count track essentially the same thing:
29 	 * How many requests are in flight or may be under construction.
30 	 *
31 	 * We need two distinct counters so that we can assign different
32 	 * lifetimes to the events for different use-cases. For example,
33 	 * we want to permanently keep the timeline pinned for the kernel
34 	 * context so that we can issue requests at any time without having
35 	 * to acquire space in the GGTT. However, we want to keep tracking
36 	 * the activity (to be able to detect when we become idle) along that
37 	 * permanently pinned timeline and so end up requiring two counters.
38 	 *
39 	 * Note that the active_count is protected by the intel_timeline.mutex,
40 	 * but the pin_count is protected by a combination of serialisation
41 	 * from the intel_context caller plus internal atomicity.
42 	 */
43 	atomic_t pin_count;
44 	atomic_t active_count;
45 
46 	void *hwsp_map;
47 	const u32 *hwsp_seqno;
48 	struct i915_vma *hwsp_ggtt;
49 	u32 hwsp_offset;
50 
51 	bool has_initial_breadcrumb;
52 
53 	/**
54 	 * List of breadcrumbs associated with GPU requests currently
55 	 * outstanding.
56 	 */
57 	struct list_head requests;
58 
59 	/*
60 	 * Contains an RCU guarded pointer to the last request. No reference is
61 	 * held to the request, users must carefully acquire a reference to
62 	 * the request using i915_active_fence_get(), or manage the RCU
63 	 * protection themselves (cf the i915_active_fence API).
64 	 */
65 	struct i915_active_fence last_request;
66 
67 	struct i915_active active;
68 
69 	/** A chain of completed timelines ready for early retirement. */
70 	struct intel_timeline *retire;
71 
72 	/**
73 	 * We track the most recent seqno that we wait on in every context so
74 	 * that we only have to emit a new await and dependency on a more
75 	 * recent sync point. As the contexts may be executed out-of-order, we
76 	 * have to track each individually and can not rely on an absolute
77 	 * global_seqno. When we know that all tracked fences are completed
78 	 * (i.e. when the driver is idle), we know that the syncmap is
79 	 * redundant and we can discard it without loss of generality.
80 	 */
81 	struct i915_syncmap *sync;
82 
83 	struct list_head link;
84 	struct intel_gt *gt;
85 
86 	struct list_head engine_link;
87 
88 	struct kref kref;
89 	struct rcu_head rcu;
90 };
91 
92 #endif /* __I915_TIMELINE_TYPES_H__ */
93