tjh.dev
Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
drm/i915: split out i915_file_private.h from i915_drv.h
Limit the scope of struct drm_i915_file_private to the files that
actually need it.
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e375859dc1729a1b988036e4103e5b1bd48caa00.1644507885.git.jani.nikula@intel.com
+117
-94
+1
drivers/gpu/drm/i915/gem/i915_gem_context.c
+1
drivers/gpu/drm/i915/gem/i915_gem_context.c
+1
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+1
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+1
drivers/gpu/drm/i915/gem/i915_gem_object.c
+1
drivers/gpu/drm/i915/gem/i915_gem_object.c
+1
drivers/gpu/drm/i915/gem/i915_gem_throttle.c
+1
drivers/gpu/drm/i915/gem/i915_gem_throttle.c
+1
drivers/gpu/drm/i915/gem/selftests/mock_context.c
+1
drivers/gpu/drm/i915/gem/selftests/mock_context.c
+1
drivers/gpu/drm/i915/gt/intel_reset.c
+1
drivers/gpu/drm/i915/gt/intel_reset.c
+1
drivers/gpu/drm/i915/i915_driver.c
+1
drivers/gpu/drm/i915/i915_driver.c
-93
drivers/gpu/drm/i915/i915_drv.h
-93
drivers/gpu/drm/i915/i915_drv.h
···
48
48
#include <linux/dma-resv.h>
49
49
#include <linux/shmem_fs.h>
50
50
#include <linux/stackdepot.h>
51
-
#include <linux/xarray.h>
52
51
53
52
#include <drm/drm_gem.h>
54
53
#include <drm/drm_auth.h>
···
178
179
I915_GEM_DOMAIN_COMMAND | \
179
180
I915_GEM_DOMAIN_INSTRUCTION | \
180
181
I915_GEM_DOMAIN_VERTEX)
181
-
182
-
struct drm_i915_file_private {
183
-
struct drm_i915_private *dev_priv;
184
-
185
-
union {
186
-
struct drm_file *file;
187
-
struct rcu_head rcu;
188
-
};
189
-
190
-
/** @proto_context_lock: Guards all struct i915_gem_proto_context
191
-
* operations
192
-
*
193
-
* This not only guards @proto_context_xa, but is always held
194
-
* whenever we manipulate any struct i915_gem_proto_context,
195
-
* including finalizing it on first actual use of the GEM context.
196
-
*
197
-
* See i915_gem_proto_context.
198
-
*/
199
-
struct mutex proto_context_lock;
200
-
201
-
/** @proto_context_xa: xarray of struct i915_gem_proto_context
202
-
*
203
-
* Historically, the context uAPI allowed for two methods of
204
-
* setting context parameters: SET_CONTEXT_PARAM and
205
-
* CONTEXT_CREATE_EXT_SETPARAM. The former is allowed to be called
206
-
* at any time while the later happens as part of
207
-
* GEM_CONTEXT_CREATE. Everything settable via one was settable
208
-
* via the other. While some params are fairly simple and setting
209
-
* them on a live context is harmless such as the context priority,
210
-
* others are far trickier such as the VM or the set of engines.
211
-
* In order to swap out the VM, for instance, we have to delay
212
-
* until all current in-flight work is complete, swap in the new
213
-
* VM, and then continue. This leads to a plethora of potential
214
-
* race conditions we'd really rather avoid.
215
-
*
216
-
* We have since disallowed setting these more complex parameters
217
-
* on active contexts. This works by delaying the creation of the
218
-
* actual context until after the client is done configuring it
219
-
* with SET_CONTEXT_PARAM. From the perspective of the client, it
220
-
* has the same u32 context ID the whole time. From the
221
-
* perspective of i915, however, it's a struct i915_gem_proto_context
222
-
* right up until the point where we attempt to do something which
223
-
* the proto-context can't handle. Then the struct i915_gem_context
224
-
* gets created.
225
-
*
226
-
* This is accomplished via a little xarray dance. When
227
-
* GEM_CONTEXT_CREATE is called, we create a struct
228
-
* i915_gem_proto_context, reserve a slot in @context_xa but leave
229
-
* it NULL, and place the proto-context in the corresponding slot
230
-
* in @proto_context_xa. Then, in i915_gem_context_lookup(), we
231
-
* first check @context_xa. If it's there, we return the struct
232
-
* i915_gem_context and we're done. If it's not, we look in
233
-
* @proto_context_xa and, if we find it there, we create the actual
234
-
* context and kill the proto-context.
235
-
*
236
-
* In order for this dance to work properly, everything which ever
237
-
* touches a struct i915_gem_proto_context is guarded by
238
-
* @proto_context_lock, including context creation. Yes, this
239
-
* means context creation now takes a giant global lock but it
240
-
* can't really be helped and that should never be on any driver's
241
-
* fast-path anyway.
242
-
*/
243
-
struct xarray proto_context_xa;
244
-
245
-
/** @context_xa: xarray of fully created i915_gem_context
246
-
*
247
-
* Write access to this xarray is guarded by @proto_context_lock.
248
-
* Otherwise, writers may race with finalize_create_context_locked().
249
-
*
250
-
* See @proto_context_xa.
251
-
*/
252
-
struct xarray context_xa;
253
-
struct xarray vm_xa;
254
-
255
-
unsigned int bsd_engine;
256
-
257
-
/*
258
-
* Every context ban increments per client ban score. Also
259
-
* hangs in short succession increments ban score. If ban threshold
260
-
* is reached, client is considered banned and submitting more work
261
-
* will fail. This is a stop gap measure to limit the badly behaving
262
-
* clients access to gpu. Note that unbannable contexts never increment
263
-
* the client ban score.
264
-
*/
265
-
#define I915_CLIENT_SCORE_HANG_FAST 1
266
-
#define I915_CLIENT_FAST_HANG_JIFFIES (60 * HZ)
267
-
#define I915_CLIENT_SCORE_CONTEXT_BAN 3
268
-
#define I915_CLIENT_SCORE_BANNED 9
269
-
/** ban_score: Accumulated score of all ctx bans and fast hangs. */
270
-
atomic_t ban_score;
271
-
unsigned long hang_timestamp;
272
-
};
273
182
274
183
struct sdvo_device_mapping {
275
184
u8 initialized;
+108
drivers/gpu/drm/i915/i915_file_private.h
+108
drivers/gpu/drm/i915/i915_file_private.h
···
1
+
/* SPDX-License-Identifier: MIT */
2
+
/*
3
+
* Copyright © 2021 Intel Corporation
4
+
*/
5
+
6
+
#ifndef __I915_FILE_PRIVATE_H__
7
+
#define __I915_FILE_PRIVATE_H__
8
+
9
+
#include <linux/mutex.h>
10
+
#include <linux/types.h>
11
+
#include <linux/xarray.h>
12
+
13
+
struct drm_i915_private;
14
+
struct drm_file;
15
+
16
+
struct drm_i915_file_private {
17
+
struct drm_i915_private *dev_priv;
18
+
19
+
union {
20
+
struct drm_file *file;
21
+
struct rcu_head rcu;
22
+
};
23
+
24
+
/** @proto_context_lock: Guards all struct i915_gem_proto_context
25
+
* operations
26
+
*
27
+
* This not only guards @proto_context_xa, but is always held
28
+
* whenever we manipulate any struct i915_gem_proto_context,
29
+
* including finalizing it on first actual use of the GEM context.
30
+
*
31
+
* See i915_gem_proto_context.
32
+
*/
33
+
struct mutex proto_context_lock;
34
+
35
+
/** @proto_context_xa: xarray of struct i915_gem_proto_context
36
+
*
37
+
* Historically, the context uAPI allowed for two methods of
38
+
* setting context parameters: SET_CONTEXT_PARAM and
39
+
* CONTEXT_CREATE_EXT_SETPARAM. The former is allowed to be called
40
+
* at any time while the later happens as part of
41
+
* GEM_CONTEXT_CREATE. Everything settable via one was settable
42
+
* via the other. While some params are fairly simple and setting
43
+
* them on a live context is harmless such as the context priority,
44
+
* others are far trickier such as the VM or the set of engines.
45
+
* In order to swap out the VM, for instance, we have to delay
46
+
* until all current in-flight work is complete, swap in the new
47
+
* VM, and then continue. This leads to a plethora of potential
48
+
* race conditions we'd really rather avoid.
49
+
*
50
+
* We have since disallowed setting these more complex parameters
51
+
* on active contexts. This works by delaying the creation of the
52
+
* actual context until after the client is done configuring it
53
+
* with SET_CONTEXT_PARAM. From the perspective of the client, it
54
+
* has the same u32 context ID the whole time. From the
55
+
* perspective of i915, however, it's a struct i915_gem_proto_context
56
+
* right up until the point where we attempt to do something which
57
+
* the proto-context can't handle. Then the struct i915_gem_context
58
+
* gets created.
59
+
*
60
+
* This is accomplished via a little xarray dance. When
61
+
* GEM_CONTEXT_CREATE is called, we create a struct
62
+
* i915_gem_proto_context, reserve a slot in @context_xa but leave
63
+
* it NULL, and place the proto-context in the corresponding slot
64
+
* in @proto_context_xa. Then, in i915_gem_context_lookup(), we
65
+
* first check @context_xa. If it's there, we return the struct
66
+
* i915_gem_context and we're done. If it's not, we look in
67
+
* @proto_context_xa and, if we find it there, we create the actual
68
+
* context and kill the proto-context.
69
+
*
70
+
* In order for this dance to work properly, everything which ever
71
+
* touches a struct i915_gem_proto_context is guarded by
72
+
* @proto_context_lock, including context creation. Yes, this
73
+
* means context creation now takes a giant global lock but it
74
+
* can't really be helped and that should never be on any driver's
75
+
* fast-path anyway.
76
+
*/
77
+
struct xarray proto_context_xa;
78
+
79
+
/** @context_xa: xarray of fully created i915_gem_context
80
+
*
81
+
* Write access to this xarray is guarded by @proto_context_lock.
82
+
* Otherwise, writers may race with finalize_create_context_locked().
83
+
*
84
+
* See @proto_context_xa.
85
+
*/
86
+
struct xarray context_xa;
87
+
struct xarray vm_xa;
88
+
89
+
unsigned int bsd_engine;
90
+
91
+
/*
92
+
* Every context ban increments per client ban score. Also
93
+
* hangs in short succession increments ban score. If ban threshold
94
+
* is reached, client is considered banned and submitting more work
95
+
* will fail. This is a stop gap measure to limit the badly behaving
96
+
* clients access to gpu. Note that unbannable contexts never increment
97
+
* the client ban score.
98
+
*/
99
+
#define I915_CLIENT_SCORE_HANG_FAST 1
100
+
#define I915_CLIENT_FAST_HANG_JIFFIES (60 * HZ)
101
+
#define I915_CLIENT_SCORE_CONTEXT_BAN 3
102
+
#define I915_CLIENT_SCORE_BANNED 9
103
+
/** ban_score: Accumulated score of all ctx bans and fast hangs. */
104
+
atomic_t ban_score;
105
+
unsigned long hang_timestamp;
106
+
};
107
+
108
+
#endif /* __I915_FILE_PRIVATE_H__ */
+1
-1
drivers/gpu/drm/i915/i915_gem.c
+1
-1
drivers/gpu/drm/i915/i915_gem.c