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
This commit is contained in:
Jani Nikula 2022-02-10 17:45:47 +02:00
parent f9bf77df11
commit 5472b3f2d9
11 changed files with 117 additions and 94 deletions

View File

@ -79,6 +79,7 @@
#include "pxp/intel_pxp.h"
#include "i915_file_private.h"
#include "i915_gem_context.h"
#include "i915_trace.h"
#include "i915_user_extensions.h"

View File

@ -25,6 +25,7 @@
#include "i915_cmd_parser.h"
#include "i915_drv.h"
#include "i915_file_private.h"
#include "i915_gem_clflush.h"
#include "i915_gem_context.h"
#include "i915_gem_evict.h"

View File

@ -28,6 +28,7 @@
#include "pxp/intel_pxp.h"
#include "i915_drv.h"
#include "i915_file_private.h"
#include "i915_gem_clflush.h"
#include "i915_gem_context.h"
#include "i915_gem_dmabuf.h"

View File

@ -9,6 +9,7 @@
#include <drm/drm_file.h>
#include "i915_drv.h"
#include "i915_file_private.h"
#include "i915_gem_context.h"
#include "i915_gem_ioctls.h"
#include "i915_gem_object.h"

View File

@ -4,6 +4,7 @@
* Copyright © 2016 Intel Corporation
*/
#include "i915_file_private.h"
#include "mock_context.h"
#include "selftests/mock_drm.h"
#include "selftests/mock_gtt.h"

View File

@ -14,6 +14,7 @@
#include "gt/intel_gt_regs.h"
#include "i915_drv.h"
#include "i915_file_private.h"
#include "i915_gpu_error.h"
#include "i915_irq.h"
#include "intel_breadcrumbs.h"

View File

@ -73,6 +73,7 @@
#include "pxp/intel_pxp_pm.h"
#include "i915_file_private.h"
#include "i915_debugfs.h"
#include "i915_driver.h"
#include "i915_drv.h"

View File

@ -48,7 +48,6 @@
#include <linux/dma-resv.h>
#include <linux/shmem_fs.h>
#include <linux/stackdepot.h>
#include <linux/xarray.h>
#include <drm/drm_gem.h>
#include <drm/drm_auth.h>
@ -180,98 +179,6 @@ struct i915_hotplug {
I915_GEM_DOMAIN_INSTRUCTION | \
I915_GEM_DOMAIN_VERTEX)
struct drm_i915_file_private {
struct drm_i915_private *dev_priv;
union {
struct drm_file *file;
struct rcu_head rcu;
};
/** @proto_context_lock: Guards all struct i915_gem_proto_context
* operations
*
* This not only guards @proto_context_xa, but is always held
* whenever we manipulate any struct i915_gem_proto_context,
* including finalizing it on first actual use of the GEM context.
*
* See i915_gem_proto_context.
*/
struct mutex proto_context_lock;
/** @proto_context_xa: xarray of struct i915_gem_proto_context
*
* Historically, the context uAPI allowed for two methods of
* setting context parameters: SET_CONTEXT_PARAM and
* CONTEXT_CREATE_EXT_SETPARAM. The former is allowed to be called
* at any time while the later happens as part of
* GEM_CONTEXT_CREATE. Everything settable via one was settable
* via the other. While some params are fairly simple and setting
* them on a live context is harmless such as the context priority,
* others are far trickier such as the VM or the set of engines.
* In order to swap out the VM, for instance, we have to delay
* until all current in-flight work is complete, swap in the new
* VM, and then continue. This leads to a plethora of potential
* race conditions we'd really rather avoid.
*
* We have since disallowed setting these more complex parameters
* on active contexts. This works by delaying the creation of the
* actual context until after the client is done configuring it
* with SET_CONTEXT_PARAM. From the perspective of the client, it
* has the same u32 context ID the whole time. From the
* perspective of i915, however, it's a struct i915_gem_proto_context
* right up until the point where we attempt to do something which
* the proto-context can't handle. Then the struct i915_gem_context
* gets created.
*
* This is accomplished via a little xarray dance. When
* GEM_CONTEXT_CREATE is called, we create a struct
* i915_gem_proto_context, reserve a slot in @context_xa but leave
* it NULL, and place the proto-context in the corresponding slot
* in @proto_context_xa. Then, in i915_gem_context_lookup(), we
* first check @context_xa. If it's there, we return the struct
* i915_gem_context and we're done. If it's not, we look in
* @proto_context_xa and, if we find it there, we create the actual
* context and kill the proto-context.
*
* In order for this dance to work properly, everything which ever
* touches a struct i915_gem_proto_context is guarded by
* @proto_context_lock, including context creation. Yes, this
* means context creation now takes a giant global lock but it
* can't really be helped and that should never be on any driver's
* fast-path anyway.
*/
struct xarray proto_context_xa;
/** @context_xa: xarray of fully created i915_gem_context
*
* Write access to this xarray is guarded by @proto_context_lock.
* Otherwise, writers may race with finalize_create_context_locked().
*
* See @proto_context_xa.
*/
struct xarray context_xa;
struct xarray vm_xa;
unsigned int bsd_engine;
/*
* Every context ban increments per client ban score. Also
* hangs in short succession increments ban score. If ban threshold
* is reached, client is considered banned and submitting more work
* will fail. This is a stop gap measure to limit the badly behaving
* clients access to gpu. Note that unbannable contexts never increment
* the client ban score.
*/
#define I915_CLIENT_SCORE_HANG_FAST 1
#define I915_CLIENT_FAST_HANG_JIFFIES (60 * HZ)
#define I915_CLIENT_SCORE_CONTEXT_BAN 3
#define I915_CLIENT_SCORE_BANNED 9
/** ban_score: Accumulated score of all ctx bans and fast hangs. */
atomic_t ban_score;
unsigned long hang_timestamp;
};
struct sdvo_device_mapping {
u8 initialized;
u8 dvo_port;

View File

@ -0,0 +1,108 @@
/* SPDX-License-Identifier: MIT */
/*
* Copyright © 2021 Intel Corporation
*/
#ifndef __I915_FILE_PRIVATE_H__
#define __I915_FILE_PRIVATE_H__
#include <linux/mutex.h>
#include <linux/types.h>
#include <linux/xarray.h>
struct drm_i915_private;
struct drm_file;
struct drm_i915_file_private {
struct drm_i915_private *dev_priv;
union {
struct drm_file *file;
struct rcu_head rcu;
};
/** @proto_context_lock: Guards all struct i915_gem_proto_context
* operations
*
* This not only guards @proto_context_xa, but is always held
* whenever we manipulate any struct i915_gem_proto_context,
* including finalizing it on first actual use of the GEM context.
*
* See i915_gem_proto_context.
*/
struct mutex proto_context_lock;
/** @proto_context_xa: xarray of struct i915_gem_proto_context
*
* Historically, the context uAPI allowed for two methods of
* setting context parameters: SET_CONTEXT_PARAM and
* CONTEXT_CREATE_EXT_SETPARAM. The former is allowed to be called
* at any time while the later happens as part of
* GEM_CONTEXT_CREATE. Everything settable via one was settable
* via the other. While some params are fairly simple and setting
* them on a live context is harmless such as the context priority,
* others are far trickier such as the VM or the set of engines.
* In order to swap out the VM, for instance, we have to delay
* until all current in-flight work is complete, swap in the new
* VM, and then continue. This leads to a plethora of potential
* race conditions we'd really rather avoid.
*
* We have since disallowed setting these more complex parameters
* on active contexts. This works by delaying the creation of the
* actual context until after the client is done configuring it
* with SET_CONTEXT_PARAM. From the perspective of the client, it
* has the same u32 context ID the whole time. From the
* perspective of i915, however, it's a struct i915_gem_proto_context
* right up until the point where we attempt to do something which
* the proto-context can't handle. Then the struct i915_gem_context
* gets created.
*
* This is accomplished via a little xarray dance. When
* GEM_CONTEXT_CREATE is called, we create a struct
* i915_gem_proto_context, reserve a slot in @context_xa but leave
* it NULL, and place the proto-context in the corresponding slot
* in @proto_context_xa. Then, in i915_gem_context_lookup(), we
* first check @context_xa. If it's there, we return the struct
* i915_gem_context and we're done. If it's not, we look in
* @proto_context_xa and, if we find it there, we create the actual
* context and kill the proto-context.
*
* In order for this dance to work properly, everything which ever
* touches a struct i915_gem_proto_context is guarded by
* @proto_context_lock, including context creation. Yes, this
* means context creation now takes a giant global lock but it
* can't really be helped and that should never be on any driver's
* fast-path anyway.
*/
struct xarray proto_context_xa;
/** @context_xa: xarray of fully created i915_gem_context
*
* Write access to this xarray is guarded by @proto_context_lock.
* Otherwise, writers may race with finalize_create_context_locked().
*
* See @proto_context_xa.
*/
struct xarray context_xa;
struct xarray vm_xa;
unsigned int bsd_engine;
/*
* Every context ban increments per client ban score. Also
* hangs in short succession increments ban score. If ban threshold
* is reached, client is considered banned and submitting more work
* will fail. This is a stop gap measure to limit the badly behaving
* clients access to gpu. Note that unbannable contexts never increment
* the client ban score.
*/
#define I915_CLIENT_SCORE_HANG_FAST 1
#define I915_CLIENT_FAST_HANG_JIFFIES (60 * HZ)
#define I915_CLIENT_SCORE_CONTEXT_BAN 3
#define I915_CLIENT_SCORE_BANNED 9
/** ban_score: Accumulated score of all ctx bans and fast hangs. */
atomic_t ban_score;
unsigned long hang_timestamp;
};
#endif /* __I915_FILE_PRIVATE_H__ */

View File

@ -53,9 +53,9 @@
#include "gt/intel_workarounds.h"
#include "i915_drv.h"
#include "i915_file_private.h"
#include "i915_trace.h"
#include "i915_vgpu.h"
#include "intel_pm.h"
static int

View File

@ -209,6 +209,7 @@
#include "gt/intel_ring.h"
#include "i915_drv.h"
#include "i915_file_private.h"
#include "i915_perf.h"
#include "i915_perf_oa_regs.h"