On Fri, Apr 23, 2021 at 05:31:25PM -0500, Jason Ekstrand wrote:
> There's a big comment saying how useful it is but no one is using this
> for anything.
>
> Signed-off-by: Jason Ekstrand <jason@xxxxxxxxxxxxxx>
I was trying to find anything before all your deletions, but alas nothing.
I did spent a bit of time on this, and discovered that the debugfs use was
nuked in
db80a1294c23 ("drm/i915/gem: Remove per-client stats from debugfs/i915_gem_objects")
After going through quite a few iterations, e.g.
5b5efdf79abf ("drm/i915: Make debugfs/per_file_stats scale better")
f6e8aa387171 ("drm/i915: Report the number of closed vma held by each context in debugfs")
The above removed the need for vm->file because stats debugfs file
filtered using stats->vm instead of stats->file.
History goes on until the original introduction of this (again for
debugfs) in
2bfa996e031b ("drm/i915: Store owning file on the i915_address_space")
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 9 ---------
> drivers/gpu/drm/i915/gt/intel_gtt.h | 10 ----------
> drivers/gpu/drm/i915/selftests/mock_gtt.c | 1 -
> 3 files changed, 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 7929d5a8be449..db9153e0f85a7 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -921,17 +921,10 @@ static int gem_context_register(struct i915_gem_context *ctx,
> u32 *id)
> {
> struct drm_i915_private *i915 = ctx->i915;
> - struct i915_address_space *vm;
> int ret;
>
> ctx->file_priv = fpriv;
>
> - mutex_lock(&ctx->mutex);
> - vm = i915_gem_context_vm(ctx);
> - if (vm)
> - WRITE_ONCE(vm->file, fpriv); /* XXX */
> - mutex_unlock(&ctx->mutex);
> -
> ctx->pid = get_task_pid(current, PIDTYPE_PID);
> snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
> current->comm, pid_nr(ctx->pid));
> @@ -1030,8 +1023,6 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, void *data,
> if (IS_ERR(ppgtt))
> return PTR_ERR(ppgtt);
>
> - ppgtt->vm.file = file_priv;
> -
> if (args->extensions) {
> err = i915_user_extensions(u64_to_user_ptr(args->extensions),
> NULL, 0,
> diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h b/drivers/gpu/drm/i915/gt/intel_gtt.h
> index e67e34e179131..4c46068e63c9d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gtt.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
> @@ -217,16 +217,6 @@ struct i915_address_space {
Pls also delete the drm_i915_file_private pre-dcl in this file.
With this added and the history adequately covered in the commit message:
Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
> struct intel_gt *gt;
> struct drm_i915_private *i915;
> struct device *dma;
> - /*
> - * Every address space belongs to a struct file - except for the global
> - * GTT that is owned by the driver (and so @file is set to NULL). In
> - * principle, no information should leak from one context to another
> - * (or between files/processes etc) unless explicitly shared by the
> - * owner. Tracking the owner is important in order to free up per-file
> - * objects along with the file, to aide resource tracking, and to
> - * assign blame.
> - */
> - struct drm_i915_file_private *file;
> u64 total; /* size addr space maps (ex. 2GB for ggtt) */
> u64 reserved; /* size addr space reserved */
>
> diff --git a/drivers/gpu/drm/i915/selftests/mock_gtt.c b/drivers/gpu/drm/i915/selftests/mock_gtt.c
> index 5c7ae40bba634..cc047ec594f93 100644
> --- a/drivers/gpu/drm/i915/selftests/mock_gtt.c
> +++ b/drivers/gpu/drm/i915/selftests/mock_gtt.c
> @@ -73,7 +73,6 @@ struct i915_ppgtt *mock_ppgtt(struct drm_i915_private *i915, const char *name)
> ppgtt->vm.gt = &i915->gt;
> ppgtt->vm.i915 = i915;
> ppgtt->vm.total = round_down(U64_MAX, PAGE_SIZE);
> - ppgtt->vm.file = ERR_PTR(-ENODEV);
> ppgtt->vm.dma = i915->drm.dev;
>
> i915_address_space_init(&ppgtt->vm, VM_CLASS_PPGTT);
> --
> 2.31.1
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
