2020-01-07 13:40:09 +00:00
|
|
|
// SPDX-License-Identifier: MIT
|
|
|
|
/*
|
|
|
|
* Copyright © 2020 Intel Corporation
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/slab.h> /* fault-inject.h is not standalone! */
|
|
|
|
|
|
|
|
#include <linux/fault-inject.h>
|
2021-12-02 20:34:00 +00:00
|
|
|
#include <linux/sched/mm.h>
|
2020-01-07 13:40:09 +00:00
|
|
|
|
2021-10-28 09:26:37 +00:00
|
|
|
#include <drm/drm_cache.h>
|
|
|
|
|
2021-04-27 08:54:14 +00:00
|
|
|
#include "gem/i915_gem_lmem.h"
|
2020-01-07 13:40:09 +00:00
|
|
|
#include "i915_trace.h"
|
|
|
|
#include "intel_gt.h"
|
|
|
|
#include "intel_gtt.h"
|
|
|
|
|
2021-04-27 08:54:14 +00:00
|
|
|
struct drm_i915_gem_object *alloc_pt_lmem(struct i915_address_space *vm, int sz)
|
|
|
|
{
|
|
|
|
struct drm_i915_gem_object *obj;
|
|
|
|
|
2021-06-25 10:38:24 +00:00
|
|
|
/*
|
|
|
|
* To avoid severe over-allocation when dealing with min_page_size
|
|
|
|
* restrictions, we override that behaviour here by allowing an object
|
|
|
|
* size and page layout which can be smaller. In practice this should be
|
|
|
|
* totally fine, since GTT paging structures are not typically inserted
|
|
|
|
* into the GTT.
|
|
|
|
*
|
|
|
|
* Note that we also hit this path for the scratch page, and for this
|
|
|
|
* case it might need to be 64K, but that should work fine here since we
|
|
|
|
* used the passed in size for the page size, which should ensure it
|
|
|
|
* also has the same alignment.
|
|
|
|
*/
|
2021-09-22 06:25:25 +00:00
|
|
|
obj = __i915_gem_object_create_lmem_with_ps(vm->i915, sz, sz,
|
|
|
|
vm->lmem_pt_obj_flags);
|
2021-04-27 08:54:14 +00:00
|
|
|
/*
|
|
|
|
* Ensure all paging structures for this vm share the same dma-resv
|
|
|
|
* object underneath, with the idea that one object_lock() will lock
|
|
|
|
* them all at once.
|
|
|
|
*/
|
2021-06-01 07:46:41 +00:00
|
|
|
if (!IS_ERR(obj)) {
|
|
|
|
obj->base.resv = i915_vm_resv_get(vm);
|
|
|
|
obj->shares_resv_from = vm;
|
|
|
|
}
|
|
|
|
|
2021-04-27 08:54:14 +00:00
|
|
|
return obj;
|
|
|
|
}
|
|
|
|
|
2020-07-29 16:42:18 +00:00
|
|
|
struct drm_i915_gem_object *alloc_pt_dma(struct i915_address_space *vm, int sz)
|
2020-01-07 13:40:09 +00:00
|
|
|
{
|
2021-03-23 15:50:29 +00:00
|
|
|
struct drm_i915_gem_object *obj;
|
|
|
|
|
2020-01-07 13:40:09 +00:00
|
|
|
if (I915_SELFTEST_ONLY(should_fail(&vm->fault_attr, 1)))
|
|
|
|
i915_gem_shrink_all(vm->i915);
|
|
|
|
|
2021-03-23 15:50:29 +00:00
|
|
|
obj = i915_gem_object_create_internal(vm->i915, sz);
|
2021-04-27 08:54:14 +00:00
|
|
|
/*
|
|
|
|
* Ensure all paging structures for this vm share the same dma-resv
|
|
|
|
* object underneath, with the idea that one object_lock() will lock
|
|
|
|
* them all at once.
|
|
|
|
*/
|
2021-06-01 07:46:41 +00:00
|
|
|
if (!IS_ERR(obj)) {
|
|
|
|
obj->base.resv = i915_vm_resv_get(vm);
|
|
|
|
obj->shares_resv_from = vm;
|
|
|
|
}
|
|
|
|
|
2021-03-23 15:50:29 +00:00
|
|
|
return obj;
|
2020-01-07 13:40:09 +00:00
|
|
|
}
|
|
|
|
|
2021-04-27 08:54:13 +00:00
|
|
|
int map_pt_dma(struct i915_address_space *vm, struct drm_i915_gem_object *obj)
|
2020-01-07 13:40:09 +00:00
|
|
|
{
|
2021-04-27 08:54:14 +00:00
|
|
|
enum i915_map_type type;
|
2021-04-27 08:54:13 +00:00
|
|
|
void *vaddr;
|
2020-01-07 13:40:09 +00:00
|
|
|
|
2021-04-27 08:54:14 +00:00
|
|
|
type = i915_coherent_map_type(vm->i915, obj, true);
|
|
|
|
vaddr = i915_gem_object_pin_map_unlocked(obj, type);
|
2021-04-27 08:54:13 +00:00
|
|
|
if (IS_ERR(vaddr))
|
|
|
|
return PTR_ERR(vaddr);
|
2021-03-23 15:50:29 +00:00
|
|
|
|
|
|
|
i915_gem_object_make_unshrinkable(obj);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-04-27 08:54:13 +00:00
|
|
|
int map_pt_dma_locked(struct i915_address_space *vm, struct drm_i915_gem_object *obj)
|
2021-03-23 15:50:29 +00:00
|
|
|
{
|
2021-04-27 08:54:14 +00:00
|
|
|
enum i915_map_type type;
|
2021-04-27 08:54:13 +00:00
|
|
|
void *vaddr;
|
2021-03-23 15:50:29 +00:00
|
|
|
|
2021-04-27 08:54:14 +00:00
|
|
|
type = i915_coherent_map_type(vm->i915, obj, true);
|
|
|
|
vaddr = i915_gem_object_pin_map(obj, type);
|
2021-04-27 08:54:13 +00:00
|
|
|
if (IS_ERR(vaddr))
|
|
|
|
return PTR_ERR(vaddr);
|
2020-01-07 13:40:09 +00:00
|
|
|
|
2020-07-29 16:42:18 +00:00
|
|
|
i915_gem_object_make_unshrinkable(obj);
|
|
|
|
return 0;
|
2020-01-07 13:40:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void __i915_vm_close(struct i915_address_space *vm)
|
|
|
|
{
|
|
|
|
struct i915_vma *vma, *vn;
|
|
|
|
|
2020-02-27 08:57:13 +00:00
|
|
|
if (!atomic_dec_and_mutex_lock(&vm->open, &vm->mutex))
|
|
|
|
return;
|
|
|
|
|
2020-01-07 13:40:09 +00:00
|
|
|
list_for_each_entry_safe(vma, vn, &vm->bound_list, vm_link) {
|
|
|
|
struct drm_i915_gem_object *obj = vma->obj;
|
|
|
|
|
|
|
|
/* Keep the obj (and hence the vma) alive as _we_ destroy it */
|
|
|
|
if (!kref_get_unless_zero(&obj->base.refcount))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
atomic_and(~I915_VMA_PIN_MASK, &vma->flags);
|
|
|
|
WARN_ON(__i915_vma_unbind(vma));
|
|
|
|
__i915_vma_put(vma);
|
|
|
|
|
|
|
|
i915_gem_object_put(obj);
|
|
|
|
}
|
|
|
|
GEM_BUG_ON(!list_empty(&vm->bound_list));
|
2020-02-27 08:57:13 +00:00
|
|
|
|
2020-01-07 13:40:09 +00:00
|
|
|
mutex_unlock(&vm->mutex);
|
|
|
|
}
|
|
|
|
|
2021-03-23 15:50:29 +00:00
|
|
|
/* lock the vm into the current ww, if we lock one, we lock all */
|
|
|
|
int i915_vm_lock_objects(struct i915_address_space *vm,
|
|
|
|
struct i915_gem_ww_ctx *ww)
|
|
|
|
{
|
2021-06-01 07:46:41 +00:00
|
|
|
if (vm->scratch[0]->base.resv == &vm->_resv) {
|
2021-03-23 15:50:29 +00:00
|
|
|
return i915_gem_object_lock(vm->scratch[0], ww);
|
|
|
|
} else {
|
|
|
|
struct i915_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
|
|
|
|
|
|
|
|
/* We borrowed the scratch page from ggtt, take the top level object */
|
|
|
|
return i915_gem_object_lock(ppgtt->pd->pt.base, ww);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-01-07 13:40:09 +00:00
|
|
|
void i915_address_space_fini(struct i915_address_space *vm)
|
|
|
|
{
|
|
|
|
drm_mm_takedown(&vm->mm);
|
|
|
|
mutex_destroy(&vm->mutex);
|
|
|
|
}
|
|
|
|
|
2021-06-01 07:46:41 +00:00
|
|
|
/**
|
|
|
|
* i915_vm_resv_release - Final struct i915_address_space destructor
|
|
|
|
* @kref: Pointer to the &i915_address_space.resv_ref member.
|
|
|
|
*
|
|
|
|
* This function is called when the last lock sharer no longer shares the
|
|
|
|
* &i915_address_space._resv lock.
|
|
|
|
*/
|
|
|
|
void i915_vm_resv_release(struct kref *kref)
|
|
|
|
{
|
|
|
|
struct i915_address_space *vm =
|
|
|
|
container_of(kref, typeof(*vm), resv_ref);
|
|
|
|
|
|
|
|
dma_resv_fini(&vm->_resv);
|
|
|
|
kfree(vm);
|
|
|
|
}
|
|
|
|
|
2020-01-07 13:40:09 +00:00
|
|
|
static void __i915_vm_release(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct i915_address_space *vm =
|
drm/i915: Stop rcu support for i915_address_space
The full audit is quite a bit of work:
- i915_dpt has very simple lifetime (somehow we create a display pagetable vm
per object, so its _very_ simple, there's only ever a single vma in there),
and uses i915_vm_close(), which internally does a i915_vm_put(). No rcu.
Aside: wtf is i915_dpt doing in the intel_display.c garbage collector as a new
feature, instead of added as a separate file with some clean-ish interface.
Also, i915_dpt unfortunately re-introduces some coding patterns from
pre-dma_resv_lock conversion times.
- i915_gem_proto_ctx is fully refcounted and no rcu, all protected by
fpriv->proto_context_lock.
- i915_gem_context is itself rcu protected, and that might leak to anything it
points at. Before
commit cf977e18610e66e48c31619e7e0cfa871be9eada
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Dec 2 11:21:40 2020 +0000
drm/i915/gem: Spring clean debugfs
and
commit db80a1294c231b6ac725085f046bb2931e00c9db
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Jan 18 11:08:54 2021 +0000
drm/i915/gem: Remove per-client stats from debugfs/i915_gem_objects
we had a bunch of debugfs files that relied on rcu protecting everything, but
those are gone now. The main one was removed even earlier with
There doesn't seem to be anything left that's actually protecting
stuff now that the ctx->vm itself is invariant. See
commit ccbc1b97948ab671335e950271e39766729736c3
Author: Jason Ekstrand <jason@jlekstrand.net>
Date: Thu Jul 8 10:48:30 2021 -0500
drm/i915/gem: Don't allow changing the VM on running contexts (v4)
Note that we drop the vm refcount before the final release of the gem context
refcount, so this is all very dangerous even without rcu. Note that aside from
later on creating new engines (a defunct feature) and debug output we're never
looked at gem_ctx->vm for anything functional, hence why this is ok.
Fingers crossed.
Preceeding patches removed all vestiges of rcu use from gem_ctx->vm
derferencing to make it clear it's really not used.
The gem_ctx->rcu protection was introduced in
commit a4e7ccdac38ec8335d9e4e2656c1a041c77feae1
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Oct 4 14:40:09 2019 +0100
drm/i915: Move context management under GEM
The commit message is somewhat entertaining because it fails to
mention this fact completely, and compensates that by an in-commit
changelog entry that claims that ctx->vm is protected by ctx->mutex.
Which was the case _before_ this commit, but no longer after it.
- intel_context holds a full reference. Unfortunately intel_context is also rcu
protected and the reference to the ->vm is dropped before the
rcu barrier - only the kfree is delayed. So again we need to check
whether that leaks anywhere on the intel_context->vm. RCU is only
used to protect intel_context sitting on the breadcrumb lists, which
don't look at the vm anywhere, so we are fine.
Nothing else relies on rcu protection of intel_context and hence is
fully protected by the kref refcount alone, which protects
intel_context->vm in turn.
The breadcrumbs rcu usage was added in
commit c744d50363b714783bbc88d986cc16def13710f7
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Nov 26 14:04:06 2020 +0000
drm/i915/gt: Split the breadcrumb spinlock between global and contexts
its parent commit added the intel_context rcu protection:
commit 14d1eaf08845c534963c83f754afe0cb14cb2512
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Nov 26 14:04:05 2020 +0000
drm/i915/gt: Protect context lifetime with RCU
given some credence to my claim that I've actually caught them all.
- drm_i915_gem_object's shares_resv_from pointer has a full refcount to the
dma_resv, which is a sub-refcount that's released after the final
i915_vm_put() has been called. Safe.
Aside: Maybe we should have a struct dma_resv_shared which is just dma_resv +
kref as a stand-alone thing. It's a pretty useful pattern which other drivers
might want to copy.
For a bit more context see
commit 4d8151ae5329cf50781a02fd2298a909589a5bab
Author: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Date: Tue Jun 1 09:46:41 2021 +0200
drm/i915: Don't free shared locks while shared
- the fpriv->vm_xa was relying on rcu_read_lock for lookup, but that
was updated in a prep patch too to just be a spinlock-protected
lookup.
- intel_gt->vm is set at driver load in intel_gt_init() and released
in intel_gt_driver_release(). There seems to be some issue that
in some error paths this is called twice, but otherwise no rcu to be
found anywhere. This was added in the below commit, which
unfortunately doesn't explain why this complication exists.
commit e6ba76480299a0d77c51d846f7467b1673aad25b
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Sat Dec 21 16:03:24 2019 +0000
drm/i915: Remove i915->kernel_context
The proper fix most likely for this is to start using drmm_ at large
scale, but that's also huge amounts of work.
- i915_vma->vm is some real pain, because rcu is rcu protected, at
least in the vma lookup in the context lookup cache in
eb_lookup_vma(). This was added in
commit 4ff4b44cbb70c269259958cbcc48d7b8a2cb9ec8
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Jun 16 15:05:16 2017 +0100
drm/i915: Store a direct lookup from object handle to vma
This was changed to a radix tree from the hashtable in, but with the
locking unchanged, in
commit d1b48c1e7184d9bc4ae6d7f9fe2eed9efed11ffc
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Aug 16 09:52:08 2017 +0100
drm/i915: Replace execbuf vma ht with an idr
In
commit 93159e12353c2a47e5576d642845a91fa00530bf
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Mar 23 09:28:41 2020 +0000
drm/i915/gem: Avoid gem_context->mutex for simple vma lookup
the locking was changed from dev->struct_mutex to rcu, which added
the requirement to rcu protect i915_vma. Somehow this was missed in
review (or I'm completely blind).
Irrespective of all that the vma lookup cache rcu_read_lock grabs a
full reference of the vma and the rcu doesn't leak further. So no
impact on i915_address_space from that.
I have not found any other rcu use for i915_vma, but given that it
seems broken I also didn't bother to do a careful in-depth audit.
Alltogether there's nothing left in-tree anymore which requires that a
pointer deref to an i915_address_space is safe undre rcu_read_lock
only.
rcu protection of i915_address_space was introduced in
commit b32fa811156328aea5a3c2ff05cc096490382456
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Jun 20 19:37:05 2019 +0100
drm/i915/gtt: Defer address space cleanup to an RCU worker
by mixing up a bugfixing (i915_address_space needs to be released from
a worker) with enabling rcu support. The commit message also seems
somewhat confused, because it talks about cleanup of WC pages
requiring sleep, while the code and linked bugzilla are about a
requirement to take dev->struct_mutex (which yes sleeps but it's a
much more specific problem). Since final kref_put can be called from
pretty much anywhere (including hardirq context through the
scheduler's i915_active cleanup) we need a worker here. Hence that
part must be kept.
Ideally all these reclaim workers should have some kind of integration
with our shrinkers, but for some of these it's rather tricky. Anyway,
that's a preexisting condition in the codeebase that we wont fix in
this patch here.
We also remove the rcu_barrier in ggtt_cleanup_hw added in
commit 60a4233a4952729089e4df152e730f8f4d0e82ce
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Jul 29 14:24:12 2019 +0100
drm/i915: Flush the i915_vm_release before ggtt shutdown
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20210902142057.929669-11-daniel.vetter@ffwll.ch
2021-09-02 14:20:57 +00:00
|
|
|
container_of(work, struct i915_address_space, release_work);
|
2020-01-07 13:40:09 +00:00
|
|
|
|
|
|
|
vm->cleanup(vm);
|
|
|
|
i915_address_space_fini(vm);
|
|
|
|
|
2021-06-01 07:46:41 +00:00
|
|
|
i915_vm_resv_put(vm);
|
2020-01-07 13:40:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void i915_vm_release(struct kref *kref)
|
|
|
|
{
|
|
|
|
struct i915_address_space *vm =
|
|
|
|
container_of(kref, struct i915_address_space, ref);
|
|
|
|
|
|
|
|
GEM_BUG_ON(i915_is_ggtt(vm));
|
|
|
|
trace_i915_ppgtt_release(vm);
|
|
|
|
|
drm/i915: Stop rcu support for i915_address_space
The full audit is quite a bit of work:
- i915_dpt has very simple lifetime (somehow we create a display pagetable vm
per object, so its _very_ simple, there's only ever a single vma in there),
and uses i915_vm_close(), which internally does a i915_vm_put(). No rcu.
Aside: wtf is i915_dpt doing in the intel_display.c garbage collector as a new
feature, instead of added as a separate file with some clean-ish interface.
Also, i915_dpt unfortunately re-introduces some coding patterns from
pre-dma_resv_lock conversion times.
- i915_gem_proto_ctx is fully refcounted and no rcu, all protected by
fpriv->proto_context_lock.
- i915_gem_context is itself rcu protected, and that might leak to anything it
points at. Before
commit cf977e18610e66e48c31619e7e0cfa871be9eada
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Dec 2 11:21:40 2020 +0000
drm/i915/gem: Spring clean debugfs
and
commit db80a1294c231b6ac725085f046bb2931e00c9db
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Jan 18 11:08:54 2021 +0000
drm/i915/gem: Remove per-client stats from debugfs/i915_gem_objects
we had a bunch of debugfs files that relied on rcu protecting everything, but
those are gone now. The main one was removed even earlier with
There doesn't seem to be anything left that's actually protecting
stuff now that the ctx->vm itself is invariant. See
commit ccbc1b97948ab671335e950271e39766729736c3
Author: Jason Ekstrand <jason@jlekstrand.net>
Date: Thu Jul 8 10:48:30 2021 -0500
drm/i915/gem: Don't allow changing the VM on running contexts (v4)
Note that we drop the vm refcount before the final release of the gem context
refcount, so this is all very dangerous even without rcu. Note that aside from
later on creating new engines (a defunct feature) and debug output we're never
looked at gem_ctx->vm for anything functional, hence why this is ok.
Fingers crossed.
Preceeding patches removed all vestiges of rcu use from gem_ctx->vm
derferencing to make it clear it's really not used.
The gem_ctx->rcu protection was introduced in
commit a4e7ccdac38ec8335d9e4e2656c1a041c77feae1
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Oct 4 14:40:09 2019 +0100
drm/i915: Move context management under GEM
The commit message is somewhat entertaining because it fails to
mention this fact completely, and compensates that by an in-commit
changelog entry that claims that ctx->vm is protected by ctx->mutex.
Which was the case _before_ this commit, but no longer after it.
- intel_context holds a full reference. Unfortunately intel_context is also rcu
protected and the reference to the ->vm is dropped before the
rcu barrier - only the kfree is delayed. So again we need to check
whether that leaks anywhere on the intel_context->vm. RCU is only
used to protect intel_context sitting on the breadcrumb lists, which
don't look at the vm anywhere, so we are fine.
Nothing else relies on rcu protection of intel_context and hence is
fully protected by the kref refcount alone, which protects
intel_context->vm in turn.
The breadcrumbs rcu usage was added in
commit c744d50363b714783bbc88d986cc16def13710f7
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Nov 26 14:04:06 2020 +0000
drm/i915/gt: Split the breadcrumb spinlock between global and contexts
its parent commit added the intel_context rcu protection:
commit 14d1eaf08845c534963c83f754afe0cb14cb2512
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Nov 26 14:04:05 2020 +0000
drm/i915/gt: Protect context lifetime with RCU
given some credence to my claim that I've actually caught them all.
- drm_i915_gem_object's shares_resv_from pointer has a full refcount to the
dma_resv, which is a sub-refcount that's released after the final
i915_vm_put() has been called. Safe.
Aside: Maybe we should have a struct dma_resv_shared which is just dma_resv +
kref as a stand-alone thing. It's a pretty useful pattern which other drivers
might want to copy.
For a bit more context see
commit 4d8151ae5329cf50781a02fd2298a909589a5bab
Author: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Date: Tue Jun 1 09:46:41 2021 +0200
drm/i915: Don't free shared locks while shared
- the fpriv->vm_xa was relying on rcu_read_lock for lookup, but that
was updated in a prep patch too to just be a spinlock-protected
lookup.
- intel_gt->vm is set at driver load in intel_gt_init() and released
in intel_gt_driver_release(). There seems to be some issue that
in some error paths this is called twice, but otherwise no rcu to be
found anywhere. This was added in the below commit, which
unfortunately doesn't explain why this complication exists.
commit e6ba76480299a0d77c51d846f7467b1673aad25b
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Sat Dec 21 16:03:24 2019 +0000
drm/i915: Remove i915->kernel_context
The proper fix most likely for this is to start using drmm_ at large
scale, but that's also huge amounts of work.
- i915_vma->vm is some real pain, because rcu is rcu protected, at
least in the vma lookup in the context lookup cache in
eb_lookup_vma(). This was added in
commit 4ff4b44cbb70c269259958cbcc48d7b8a2cb9ec8
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Jun 16 15:05:16 2017 +0100
drm/i915: Store a direct lookup from object handle to vma
This was changed to a radix tree from the hashtable in, but with the
locking unchanged, in
commit d1b48c1e7184d9bc4ae6d7f9fe2eed9efed11ffc
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Aug 16 09:52:08 2017 +0100
drm/i915: Replace execbuf vma ht with an idr
In
commit 93159e12353c2a47e5576d642845a91fa00530bf
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Mar 23 09:28:41 2020 +0000
drm/i915/gem: Avoid gem_context->mutex for simple vma lookup
the locking was changed from dev->struct_mutex to rcu, which added
the requirement to rcu protect i915_vma. Somehow this was missed in
review (or I'm completely blind).
Irrespective of all that the vma lookup cache rcu_read_lock grabs a
full reference of the vma and the rcu doesn't leak further. So no
impact on i915_address_space from that.
I have not found any other rcu use for i915_vma, but given that it
seems broken I also didn't bother to do a careful in-depth audit.
Alltogether there's nothing left in-tree anymore which requires that a
pointer deref to an i915_address_space is safe undre rcu_read_lock
only.
rcu protection of i915_address_space was introduced in
commit b32fa811156328aea5a3c2ff05cc096490382456
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Jun 20 19:37:05 2019 +0100
drm/i915/gtt: Defer address space cleanup to an RCU worker
by mixing up a bugfixing (i915_address_space needs to be released from
a worker) with enabling rcu support. The commit message also seems
somewhat confused, because it talks about cleanup of WC pages
requiring sleep, while the code and linked bugzilla are about a
requirement to take dev->struct_mutex (which yes sleeps but it's a
much more specific problem). Since final kref_put can be called from
pretty much anywhere (including hardirq context through the
scheduler's i915_active cleanup) we need a worker here. Hence that
part must be kept.
Ideally all these reclaim workers should have some kind of integration
with our shrinkers, but for some of these it's rather tricky. Anyway,
that's a preexisting condition in the codeebase that we wont fix in
this patch here.
We also remove the rcu_barrier in ggtt_cleanup_hw added in
commit 60a4233a4952729089e4df152e730f8f4d0e82ce
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Jul 29 14:24:12 2019 +0100
drm/i915: Flush the i915_vm_release before ggtt shutdown
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20210902142057.929669-11-daniel.vetter@ffwll.ch
2021-09-02 14:20:57 +00:00
|
|
|
queue_work(vm->i915->wq, &vm->release_work);
|
2020-01-07 13:40:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void i915_address_space_init(struct i915_address_space *vm, int subclass)
|
|
|
|
{
|
|
|
|
kref_init(&vm->ref);
|
2021-06-01 07:46:41 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Special case for GGTT that has already done an early
|
|
|
|
* kref_init here.
|
|
|
|
*/
|
|
|
|
if (!kref_read(&vm->resv_ref))
|
|
|
|
kref_init(&vm->resv_ref);
|
|
|
|
|
drm/i915: Stop rcu support for i915_address_space
The full audit is quite a bit of work:
- i915_dpt has very simple lifetime (somehow we create a display pagetable vm
per object, so its _very_ simple, there's only ever a single vma in there),
and uses i915_vm_close(), which internally does a i915_vm_put(). No rcu.
Aside: wtf is i915_dpt doing in the intel_display.c garbage collector as a new
feature, instead of added as a separate file with some clean-ish interface.
Also, i915_dpt unfortunately re-introduces some coding patterns from
pre-dma_resv_lock conversion times.
- i915_gem_proto_ctx is fully refcounted and no rcu, all protected by
fpriv->proto_context_lock.
- i915_gem_context is itself rcu protected, and that might leak to anything it
points at. Before
commit cf977e18610e66e48c31619e7e0cfa871be9eada
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Dec 2 11:21:40 2020 +0000
drm/i915/gem: Spring clean debugfs
and
commit db80a1294c231b6ac725085f046bb2931e00c9db
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Jan 18 11:08:54 2021 +0000
drm/i915/gem: Remove per-client stats from debugfs/i915_gem_objects
we had a bunch of debugfs files that relied on rcu protecting everything, but
those are gone now. The main one was removed even earlier with
There doesn't seem to be anything left that's actually protecting
stuff now that the ctx->vm itself is invariant. See
commit ccbc1b97948ab671335e950271e39766729736c3
Author: Jason Ekstrand <jason@jlekstrand.net>
Date: Thu Jul 8 10:48:30 2021 -0500
drm/i915/gem: Don't allow changing the VM on running contexts (v4)
Note that we drop the vm refcount before the final release of the gem context
refcount, so this is all very dangerous even without rcu. Note that aside from
later on creating new engines (a defunct feature) and debug output we're never
looked at gem_ctx->vm for anything functional, hence why this is ok.
Fingers crossed.
Preceeding patches removed all vestiges of rcu use from gem_ctx->vm
derferencing to make it clear it's really not used.
The gem_ctx->rcu protection was introduced in
commit a4e7ccdac38ec8335d9e4e2656c1a041c77feae1
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Oct 4 14:40:09 2019 +0100
drm/i915: Move context management under GEM
The commit message is somewhat entertaining because it fails to
mention this fact completely, and compensates that by an in-commit
changelog entry that claims that ctx->vm is protected by ctx->mutex.
Which was the case _before_ this commit, but no longer after it.
- intel_context holds a full reference. Unfortunately intel_context is also rcu
protected and the reference to the ->vm is dropped before the
rcu barrier - only the kfree is delayed. So again we need to check
whether that leaks anywhere on the intel_context->vm. RCU is only
used to protect intel_context sitting on the breadcrumb lists, which
don't look at the vm anywhere, so we are fine.
Nothing else relies on rcu protection of intel_context and hence is
fully protected by the kref refcount alone, which protects
intel_context->vm in turn.
The breadcrumbs rcu usage was added in
commit c744d50363b714783bbc88d986cc16def13710f7
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Nov 26 14:04:06 2020 +0000
drm/i915/gt: Split the breadcrumb spinlock between global and contexts
its parent commit added the intel_context rcu protection:
commit 14d1eaf08845c534963c83f754afe0cb14cb2512
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Nov 26 14:04:05 2020 +0000
drm/i915/gt: Protect context lifetime with RCU
given some credence to my claim that I've actually caught them all.
- drm_i915_gem_object's shares_resv_from pointer has a full refcount to the
dma_resv, which is a sub-refcount that's released after the final
i915_vm_put() has been called. Safe.
Aside: Maybe we should have a struct dma_resv_shared which is just dma_resv +
kref as a stand-alone thing. It's a pretty useful pattern which other drivers
might want to copy.
For a bit more context see
commit 4d8151ae5329cf50781a02fd2298a909589a5bab
Author: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Date: Tue Jun 1 09:46:41 2021 +0200
drm/i915: Don't free shared locks while shared
- the fpriv->vm_xa was relying on rcu_read_lock for lookup, but that
was updated in a prep patch too to just be a spinlock-protected
lookup.
- intel_gt->vm is set at driver load in intel_gt_init() and released
in intel_gt_driver_release(). There seems to be some issue that
in some error paths this is called twice, but otherwise no rcu to be
found anywhere. This was added in the below commit, which
unfortunately doesn't explain why this complication exists.
commit e6ba76480299a0d77c51d846f7467b1673aad25b
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Sat Dec 21 16:03:24 2019 +0000
drm/i915: Remove i915->kernel_context
The proper fix most likely for this is to start using drmm_ at large
scale, but that's also huge amounts of work.
- i915_vma->vm is some real pain, because rcu is rcu protected, at
least in the vma lookup in the context lookup cache in
eb_lookup_vma(). This was added in
commit 4ff4b44cbb70c269259958cbcc48d7b8a2cb9ec8
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Jun 16 15:05:16 2017 +0100
drm/i915: Store a direct lookup from object handle to vma
This was changed to a radix tree from the hashtable in, but with the
locking unchanged, in
commit d1b48c1e7184d9bc4ae6d7f9fe2eed9efed11ffc
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Aug 16 09:52:08 2017 +0100
drm/i915: Replace execbuf vma ht with an idr
In
commit 93159e12353c2a47e5576d642845a91fa00530bf
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Mar 23 09:28:41 2020 +0000
drm/i915/gem: Avoid gem_context->mutex for simple vma lookup
the locking was changed from dev->struct_mutex to rcu, which added
the requirement to rcu protect i915_vma. Somehow this was missed in
review (or I'm completely blind).
Irrespective of all that the vma lookup cache rcu_read_lock grabs a
full reference of the vma and the rcu doesn't leak further. So no
impact on i915_address_space from that.
I have not found any other rcu use for i915_vma, but given that it
seems broken I also didn't bother to do a careful in-depth audit.
Alltogether there's nothing left in-tree anymore which requires that a
pointer deref to an i915_address_space is safe undre rcu_read_lock
only.
rcu protection of i915_address_space was introduced in
commit b32fa811156328aea5a3c2ff05cc096490382456
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Jun 20 19:37:05 2019 +0100
drm/i915/gtt: Defer address space cleanup to an RCU worker
by mixing up a bugfixing (i915_address_space needs to be released from
a worker) with enabling rcu support. The commit message also seems
somewhat confused, because it talks about cleanup of WC pages
requiring sleep, while the code and linked bugzilla are about a
requirement to take dev->struct_mutex (which yes sleeps but it's a
much more specific problem). Since final kref_put can be called from
pretty much anywhere (including hardirq context through the
scheduler's i915_active cleanup) we need a worker here. Hence that
part must be kept.
Ideally all these reclaim workers should have some kind of integration
with our shrinkers, but for some of these it's rather tricky. Anyway,
that's a preexisting condition in the codeebase that we wont fix in
this patch here.
We also remove the rcu_barrier in ggtt_cleanup_hw added in
commit 60a4233a4952729089e4df152e730f8f4d0e82ce
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Jul 29 14:24:12 2019 +0100
drm/i915: Flush the i915_vm_release before ggtt shutdown
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20210902142057.929669-11-daniel.vetter@ffwll.ch
2021-09-02 14:20:57 +00:00
|
|
|
INIT_WORK(&vm->release_work, __i915_vm_release);
|
2020-01-07 13:40:09 +00:00
|
|
|
atomic_set(&vm->open, 1);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The vm->mutex must be reclaim safe (for use in the shrinker).
|
|
|
|
* Do a dummy acquire now under fs_reclaim so that any allocation
|
|
|
|
* attempt holding the lock is immediately reported by lockdep.
|
|
|
|
*/
|
|
|
|
mutex_init(&vm->mutex);
|
|
|
|
lockdep_set_subclass(&vm->mutex, subclass);
|
drm/i915: Use trylock in shrinker for ggtt on bsw vt-d and bxt, v2.
The stop_machine() lock may allocate memory, but is called inside
vm->mutex, which is taken in the shrinker. This will cause a lockdep
splat, as can be seen below:
<4>[ 462.585762] ======================================================
<4>[ 462.585768] WARNING: possible circular locking dependency detected
<4>[ 462.585773] 5.12.0-rc5-CI-Trybot_7644+ #1 Tainted: G U
<4>[ 462.585779] ------------------------------------------------------
<4>[ 462.585783] i915_selftest/5540 is trying to acquire lock:
<4>[ 462.585788] ffffffff826440b0 (cpu_hotplug_lock){++++}-{0:0}, at: stop_machine+0x12/0x30
<4>[ 462.585814]
but task is already holding lock:
<4>[ 462.585818] ffff888125369c70 (&vm->mutex/1){+.+.}-{3:3}, at: i915_vma_pin_ww+0x38e/0xb40 [i915]
<4>[ 462.586301]
which lock already depends on the new lock.
<4>[ 462.586305]
the existing dependency chain (in reverse order) is:
<4>[ 462.586309]
-> #2 (&vm->mutex/1){+.+.}-{3:3}:
<4>[ 462.586323] i915_gem_shrinker_taints_mutex+0x2d/0x50 [i915]
<4>[ 462.586719] i915_address_space_init+0x12d/0x130 [i915]
<4>[ 462.587092] ppgtt_init+0x4e/0x80 [i915]
<4>[ 462.587467] gen8_ppgtt_create+0x3e/0x5c0 [i915]
<4>[ 462.587828] i915_ppgtt_create+0x28/0xf0 [i915]
<4>[ 462.588203] intel_gt_init+0x123/0x370 [i915]
<4>[ 462.588572] i915_gem_init+0x129/0x1f0 [i915]
<4>[ 462.588971] i915_driver_probe+0x753/0xd80 [i915]
<4>[ 462.589320] i915_pci_probe+0x43/0x1d0 [i915]
<4>[ 462.589671] pci_device_probe+0x9e/0x110
<4>[ 462.589680] really_probe+0xea/0x410
<4>[ 462.589690] driver_probe_device+0xd9/0x140
<4>[ 462.589697] device_driver_attach+0x4a/0x50
<4>[ 462.589704] __driver_attach+0x83/0x140
<4>[ 462.589711] bus_for_each_dev+0x75/0xc0
<4>[ 462.589718] bus_add_driver+0x14b/0x1f0
<4>[ 462.589724] driver_register+0x66/0xb0
<4>[ 462.589731] i915_init+0x70/0x87 [i915]
<4>[ 462.590053] do_one_initcall+0x56/0x2e0
<4>[ 462.590061] do_init_module+0x55/0x200
<4>[ 462.590068] load_module+0x2703/0x2990
<4>[ 462.590074] __do_sys_finit_module+0xad/0x110
<4>[ 462.590080] do_syscall_64+0x33/0x80
<4>[ 462.590089] entry_SYSCALL_64_after_hwframe+0x44/0xae
<4>[ 462.590096]
-> #1 (fs_reclaim){+.+.}-{0:0}:
<4>[ 462.590109] fs_reclaim_acquire+0x9f/0xd0
<4>[ 462.590118] kmem_cache_alloc_trace+0x3d/0x430
<4>[ 462.590126] intel_cpuc_prepare+0x3b/0x1b0
<4>[ 462.590133] cpuhp_invoke_callback+0x9e/0x890
<4>[ 462.590141] _cpu_up+0xa4/0x130
<4>[ 462.590147] cpu_up+0x82/0x90
<4>[ 462.590153] bringup_nonboot_cpus+0x4a/0x60
<4>[ 462.590159] smp_init+0x21/0x5c
<4>[ 462.590167] kernel_init_freeable+0x8a/0x1b7
<4>[ 462.590175] kernel_init+0x5/0xff
<4>[ 462.590181] ret_from_fork+0x22/0x30
<4>[ 462.590187]
-> #0 (cpu_hotplug_lock){++++}-{0:0}:
<4>[ 462.590199] __lock_acquire+0x1520/0x2590
<4>[ 462.590207] lock_acquire+0xd1/0x3d0
<4>[ 462.590213] cpus_read_lock+0x39/0xc0
<4>[ 462.590219] stop_machine+0x12/0x30
<4>[ 462.590226] bxt_vtd_ggtt_insert_entries__BKL+0x36/0x50 [i915]
<4>[ 462.590601] ggtt_bind_vma+0x5d/0x80 [i915]
<4>[ 462.590970] i915_vma_bind+0xdc/0x1c0 [i915]
<4>[ 462.591374] i915_vma_pin_ww+0x435/0xb40 [i915]
<4>[ 462.591779] make_obj_busy+0xcb/0x330 [i915]
<4>[ 462.592170] igt_mmap_offset_exhaustion+0x45f/0x4c0 [i915]
<4>[ 462.592562] __i915_subtests.cold.7+0x42/0x92 [i915]
<4>[ 462.592995] __run_selftests.part.3+0x10d/0x172 [i915]
<4>[ 462.593428] i915_live_selftests.cold.5+0x1f/0x47 [i915]
<4>[ 462.593860] i915_pci_probe+0x93/0x1d0 [i915]
<4>[ 462.594210] pci_device_probe+0x9e/0x110
<4>[ 462.594217] really_probe+0xea/0x410
<4>[ 462.594226] driver_probe_device+0xd9/0x140
<4>[ 462.594233] device_driver_attach+0x4a/0x50
<4>[ 462.594240] __driver_attach+0x83/0x140
<4>[ 462.594247] bus_for_each_dev+0x75/0xc0
<4>[ 462.594254] bus_add_driver+0x14b/0x1f0
<4>[ 462.594260] driver_register+0x66/0xb0
<4>[ 462.594267] i915_init+0x70/0x87 [i915]
<4>[ 462.594586] do_one_initcall+0x56/0x2e0
<4>[ 462.594592] do_init_module+0x55/0x200
<4>[ 462.594599] load_module+0x2703/0x2990
<4>[ 462.594605] __do_sys_finit_module+0xad/0x110
<4>[ 462.594612] do_syscall_64+0x33/0x80
<4>[ 462.594618] entry_SYSCALL_64_after_hwframe+0x44/0xae
<4>[ 462.594625]
other info that might help us debug this:
<4>[ 462.594629] Chain exists of:
cpu_hotplug_lock --> fs_reclaim --> &vm->mutex/1
<4>[ 462.594645] Possible unsafe locking scenario:
<4>[ 462.594648] CPU0 CPU1
<4>[ 462.594652] ---- ----
<4>[ 462.594655] lock(&vm->mutex/1);
<4>[ 462.594664] lock(fs_reclaim);
<4>[ 462.594671] lock(&vm->mutex/1);
<4>[ 462.594679] lock(cpu_hotplug_lock);
<4>[ 462.594686]
*** DEADLOCK ***
<4>[ 462.594690] 4 locks held by i915_selftest/5540:
<4>[ 462.594696] #0: ffff888100fbc240 (&dev->mutex){....}-{3:3}, at: device_driver_attach+0x18/0x50
<4>[ 462.594715] #1: ffffc900006cb9a0 (reservation_ww_class_acquire){+.+.}-{0:0}, at: make_obj_busy+0x81/0x330 [i915]
<4>[ 462.595118] #2: ffff88812a6081e8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: make_obj_busy+0x21f/0x330 [i915]
<4>[ 462.595519] #3: ffff888125369c70 (&vm->mutex/1){+.+.}-{3:3}, at: i915_vma_pin_ww+0x38e/0xb40 [i915]
<4>[ 462.595934]
stack backtrace:
<4>[ 462.595939] CPU: 0 PID: 5540 Comm: i915_selftest Tainted: G U 5.12.0-rc5-CI-Trybot_7644+ #1
<4>[ 462.595947] Hardware name: GOOGLE Kefka/Kefka, BIOS MrChromebox 02/04/2018
<4>[ 462.595952] Call Trace:
<4>[ 462.595961] dump_stack+0x7f/0xad
<4>[ 462.595974] check_noncircular+0x12e/0x150
<4>[ 462.595982] ? save_stack.isra.17+0x3f/0x70
<4>[ 462.595991] ? drm_mm_insert_node_in_range+0x34a/0x5b0
<4>[ 462.596000] ? i915_vma_pin_ww+0x9ec/0xb40 [i915]
<4>[ 462.596410] __lock_acquire+0x1520/0x2590
<4>[ 462.596419] ? do_init_module+0x55/0x200
<4>[ 462.596429] lock_acquire+0xd1/0x3d0
<4>[ 462.596435] ? stop_machine+0x12/0x30
<4>[ 462.596445] ? gen8_ggtt_insert_entries+0xf0/0xf0 [i915]
<4>[ 462.596816] cpus_read_lock+0x39/0xc0
<4>[ 462.596824] ? stop_machine+0x12/0x30
<4>[ 462.596831] stop_machine+0x12/0x30
<4>[ 462.596839] bxt_vtd_ggtt_insert_entries__BKL+0x36/0x50 [i915]
<4>[ 462.597210] ggtt_bind_vma+0x5d/0x80 [i915]
<4>[ 462.597580] i915_vma_bind+0xdc/0x1c0 [i915]
<4>[ 462.597986] i915_vma_pin_ww+0x435/0xb40 [i915]
<4>[ 462.598395] ? make_obj_busy+0xcb/0x330 [i915]
<4>[ 462.598786] make_obj_busy+0xcb/0x330 [i915]
<4>[ 462.599180] ? 0xffffffff81000000
<4>[ 462.599187] ? debug_mutex_unlock+0x50/0xa0
<4>[ 462.599198] igt_mmap_offset_exhaustion+0x45f/0x4c0 [i915]
<4>[ 462.599592] __i915_subtests.cold.7+0x42/0x92 [i915]
<4>[ 462.600026] ? i915_perf_selftests+0x20/0x20 [i915]
<4>[ 462.600422] ? __i915_nop_setup+0x10/0x10 [i915]
<4>[ 462.600820] __run_selftests.part.3+0x10d/0x172 [i915]
<4>[ 462.601253] i915_live_selftests.cold.5+0x1f/0x47 [i915]
<4>[ 462.601686] i915_pci_probe+0x93/0x1d0 [i915]
<4>[ 462.602037] ? _raw_spin_unlock_irqrestore+0x3d/0x60
<4>[ 462.602047] pci_device_probe+0x9e/0x110
<4>[ 462.602057] really_probe+0xea/0x410
<4>[ 462.602067] driver_probe_device+0xd9/0x140
<4>[ 462.602075] device_driver_attach+0x4a/0x50
<4>[ 462.602084] __driver_attach+0x83/0x140
<4>[ 462.602091] ? device_driver_attach+0x50/0x50
<4>[ 462.602099] ? device_driver_attach+0x50/0x50
<4>[ 462.602107] bus_for_each_dev+0x75/0xc0
<4>[ 462.602116] bus_add_driver+0x14b/0x1f0
<4>[ 462.602124] driver_register+0x66/0xb0
<4>[ 462.602133] i915_init+0x70/0x87 [i915]
<4>[ 462.602453] ? 0xffffffffa0606000
<4>[ 462.602458] do_one_initcall+0x56/0x2e0
<4>[ 462.602466] ? kmem_cache_alloc_trace+0x374/0x430
<4>[ 462.602476] do_init_module+0x55/0x200
<4>[ 462.602484] load_module+0x2703/0x2990
<4>[ 462.602500] ? __do_sys_finit_module+0xad/0x110
<4>[ 462.602507] __do_sys_finit_module+0xad/0x110
<4>[ 462.602519] do_syscall_64+0x33/0x80
<4>[ 462.602527] entry_SYSCALL_64_after_hwframe+0x44/0xae
<4>[ 462.602535] RIP: 0033:0x7fab69d8d89d
Changes since v1:
- Add lockdep annotations during init, to ensure that lockdep is primed.
This also fixes a false positive when reading /proc/lockdep_stats
during module reload.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210426102351.921874-1-maarten.lankhorst@linux.intel.com
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2021-04-26 10:23:51 +00:00
|
|
|
|
|
|
|
if (!intel_vm_no_concurrent_access_wa(vm->i915)) {
|
|
|
|
i915_gem_shrinker_taints_mutex(vm->i915, &vm->mutex);
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* CHV + BXT VTD workaround use stop_machine(),
|
|
|
|
* which is allowed to allocate memory. This means &vm->mutex
|
|
|
|
* is the outer lock, and in theory we can allocate memory inside
|
|
|
|
* it through stop_machine().
|
|
|
|
*
|
|
|
|
* Add the annotation for this, we use trylock in shrinker.
|
|
|
|
*/
|
|
|
|
mutex_acquire(&vm->mutex.dep_map, 0, 0, _THIS_IP_);
|
|
|
|
might_alloc(GFP_KERNEL);
|
|
|
|
mutex_release(&vm->mutex.dep_map, _THIS_IP_);
|
|
|
|
}
|
2021-06-01 07:46:41 +00:00
|
|
|
dma_resv_init(&vm->_resv);
|
2020-01-07 13:40:09 +00:00
|
|
|
|
|
|
|
GEM_BUG_ON(!vm->total);
|
|
|
|
drm_mm_init(&vm->mm, 0, vm->total);
|
|
|
|
vm->mm.head_node.color = I915_COLOR_UNEVICTABLE;
|
|
|
|
|
|
|
|
INIT_LIST_HEAD(&vm->bound_list);
|
|
|
|
}
|
|
|
|
|
2021-04-27 08:54:13 +00:00
|
|
|
void *__px_vaddr(struct drm_i915_gem_object *p)
|
|
|
|
{
|
|
|
|
enum i915_map_type type;
|
|
|
|
|
|
|
|
GEM_BUG_ON(!i915_gem_object_has_pages(p));
|
|
|
|
return page_unpack_bits(p->mm.mapping, &type);
|
|
|
|
}
|
|
|
|
|
2020-07-29 16:42:18 +00:00
|
|
|
dma_addr_t __px_dma(struct drm_i915_gem_object *p)
|
2020-01-07 13:40:09 +00:00
|
|
|
{
|
2020-07-29 16:42:18 +00:00
|
|
|
GEM_BUG_ON(!i915_gem_object_has_pages(p));
|
|
|
|
return sg_dma_address(p->mm.pages->sgl);
|
2020-01-07 13:40:09 +00:00
|
|
|
}
|
|
|
|
|
2020-07-29 16:42:18 +00:00
|
|
|
struct page *__px_page(struct drm_i915_gem_object *p)
|
2020-01-07 13:40:09 +00:00
|
|
|
{
|
2020-07-29 16:42:18 +00:00
|
|
|
GEM_BUG_ON(!i915_gem_object_has_pages(p));
|
|
|
|
return sg_page(p->mm.pages->sgl);
|
2020-01-07 13:40:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
2020-07-29 16:42:18 +00:00
|
|
|
fill_page_dma(struct drm_i915_gem_object *p, const u64 val, unsigned int count)
|
2020-01-07 13:40:09 +00:00
|
|
|
{
|
2021-04-27 08:54:13 +00:00
|
|
|
void *vaddr = __px_vaddr(p);
|
2020-07-29 16:42:18 +00:00
|
|
|
|
|
|
|
memset64(vaddr, val, count);
|
|
|
|
clflush_cache_range(vaddr, PAGE_SIZE);
|
2020-01-07 13:40:09 +00:00
|
|
|
}
|
|
|
|
|
2020-07-29 16:42:18 +00:00
|
|
|
static void poison_scratch_page(struct drm_i915_gem_object *scratch)
|
2020-01-24 11:51:33 +00:00
|
|
|
{
|
2021-04-27 08:54:13 +00:00
|
|
|
void *vaddr = __px_vaddr(scratch);
|
2020-07-29 16:42:18 +00:00
|
|
|
u8 val;
|
2020-01-24 11:51:33 +00:00
|
|
|
|
2020-07-29 16:42:18 +00:00
|
|
|
val = 0;
|
|
|
|
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
|
|
|
|
val = POISON_FREE;
|
2020-01-24 11:51:33 +00:00
|
|
|
|
2021-04-27 08:54:13 +00:00
|
|
|
memset(vaddr, val, scratch->base.size);
|
2021-10-28 09:26:37 +00:00
|
|
|
drm_clflush_virt_range(vaddr, scratch->base.size);
|
2020-01-24 11:51:33 +00:00
|
|
|
}
|
|
|
|
|
2020-07-29 16:42:18 +00:00
|
|
|
int setup_scratch_page(struct i915_address_space *vm)
|
2020-01-07 13:40:09 +00:00
|
|
|
{
|
|
|
|
unsigned long size;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* In order to utilize 64K pages for an object with a size < 2M, we will
|
|
|
|
* need to support a 64K scratch page, given that every 16th entry for a
|
|
|
|
* page-table operating in 64K mode must point to a properly aligned 64K
|
|
|
|
* region, including any PTEs which happen to point to scratch.
|
|
|
|
*
|
|
|
|
* This is only relevant for the 48b PPGTT where we support
|
|
|
|
* huge-gtt-pages, see also i915_vma_insert(). However, as we share the
|
|
|
|
* scratch (read-only) between all vm, we create one 64k scratch page
|
|
|
|
* for all.
|
|
|
|
*/
|
|
|
|
size = I915_GTT_PAGE_SIZE_4K;
|
|
|
|
if (i915_vm_is_4lvl(vm) &&
|
2020-07-29 16:42:18 +00:00
|
|
|
HAS_PAGE_SIZES(vm->i915, I915_GTT_PAGE_SIZE_64K))
|
2020-01-07 13:40:09 +00:00
|
|
|
size = I915_GTT_PAGE_SIZE_64K;
|
|
|
|
|
|
|
|
do {
|
2020-07-29 16:42:18 +00:00
|
|
|
struct drm_i915_gem_object *obj;
|
2020-01-07 13:40:09 +00:00
|
|
|
|
2021-12-08 14:16:12 +00:00
|
|
|
obj = vm->alloc_scratch_dma(vm, size);
|
2020-07-29 16:42:18 +00:00
|
|
|
if (IS_ERR(obj))
|
2020-01-07 13:40:09 +00:00
|
|
|
goto skip;
|
|
|
|
|
2021-04-27 08:54:13 +00:00
|
|
|
if (map_pt_dma(vm, obj))
|
2020-07-29 16:42:18 +00:00
|
|
|
goto skip_obj;
|
|
|
|
|
|
|
|
/* We need a single contiguous page for our scratch */
|
|
|
|
if (obj->mm.page_sizes.sg < size)
|
|
|
|
goto skip_obj;
|
|
|
|
|
|
|
|
/* And it needs to be correspondingly aligned */
|
|
|
|
if (__px_dma(obj) & (size - 1))
|
|
|
|
goto skip_obj;
|
|
|
|
|
2020-01-24 11:51:33 +00:00
|
|
|
/*
|
|
|
|
* Use a non-zero scratch page for debugging.
|
|
|
|
*
|
|
|
|
* We want a value that should be reasonably obvious
|
|
|
|
* to spot in the error state, while also causing a GPU hang
|
|
|
|
* if executed. We prefer using a clear page in production, so
|
|
|
|
* should it ever be accidentally used, the effect should be
|
|
|
|
* fairly benign.
|
|
|
|
*/
|
2020-07-29 16:42:18 +00:00
|
|
|
poison_scratch_page(obj);
|
|
|
|
|
|
|
|
vm->scratch[0] = obj;
|
|
|
|
vm->scratch_order = get_order(size);
|
2020-01-07 13:40:09 +00:00
|
|
|
return 0;
|
|
|
|
|
2020-07-29 16:42:18 +00:00
|
|
|
skip_obj:
|
|
|
|
i915_gem_object_put(obj);
|
2020-01-07 13:40:09 +00:00
|
|
|
skip:
|
|
|
|
if (size == I915_GTT_PAGE_SIZE_4K)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2021-12-08 14:16:13 +00:00
|
|
|
/*
|
|
|
|
* If we need 64K minimum GTT pages for device local-memory,
|
|
|
|
* like on XEHPSDV, then we need to fail the allocation here,
|
|
|
|
* otherwise we can't safely support the insertion of
|
|
|
|
* local-memory pages for this vm, since the HW expects the
|
|
|
|
* correct physical alignment and size when the page-table is
|
|
|
|
* operating in 64K GTT mode, which includes any scratch PTEs,
|
|
|
|
* since userspace can still touch them.
|
|
|
|
*/
|
|
|
|
if (HAS_64K_PAGES(vm->i915))
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2020-01-07 13:40:09 +00:00
|
|
|
size = I915_GTT_PAGE_SIZE_4K;
|
|
|
|
} while (1);
|
|
|
|
}
|
|
|
|
|
|
|
|
void free_scratch(struct i915_address_space *vm)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2020-07-29 16:42:18 +00:00
|
|
|
for (i = 0; i <= vm->top; i++)
|
|
|
|
i915_gem_object_put(vm->scratch[i]);
|
2020-01-07 13:40:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void gtt_write_workarounds(struct intel_gt *gt)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *i915 = gt->i915;
|
|
|
|
struct intel_uncore *uncore = gt->uncore;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This function is for gtt related workarounds. This function is
|
|
|
|
* called on driver load and after a GPU reset, so you can place
|
|
|
|
* workarounds here even if they get overwritten by GPU reset.
|
|
|
|
*/
|
|
|
|
/* WaIncreaseDefaultTLBEntries:chv,bdw,skl,bxt,kbl,glk,cfl,cnl,icl */
|
|
|
|
if (IS_BROADWELL(i915))
|
|
|
|
intel_uncore_write(uncore,
|
|
|
|
GEN8_L3_LRA_1_GPGPU,
|
|
|
|
GEN8_L3_LRA_1_GPGPU_DEFAULT_VALUE_BDW);
|
|
|
|
else if (IS_CHERRYVIEW(i915))
|
|
|
|
intel_uncore_write(uncore,
|
|
|
|
GEN8_L3_LRA_1_GPGPU,
|
|
|
|
GEN8_L3_LRA_1_GPGPU_DEFAULT_VALUE_CHV);
|
|
|
|
else if (IS_GEN9_LP(i915))
|
|
|
|
intel_uncore_write(uncore,
|
|
|
|
GEN8_L3_LRA_1_GPGPU,
|
|
|
|
GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_BXT);
|
2021-06-05 15:53:52 +00:00
|
|
|
else if (GRAPHICS_VER(i915) >= 9 && GRAPHICS_VER(i915) <= 11)
|
2020-01-07 13:40:09 +00:00
|
|
|
intel_uncore_write(uncore,
|
|
|
|
GEN8_L3_LRA_1_GPGPU,
|
|
|
|
GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_SKL);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* To support 64K PTEs we need to first enable the use of the
|
|
|
|
* Intermediate-Page-Size(IPS) bit of the PDE field via some magical
|
|
|
|
* mmio, otherwise the page-walker will simply ignore the IPS bit. This
|
|
|
|
* shouldn't be needed after GEN10.
|
|
|
|
*
|
|
|
|
* 64K pages were first introduced from BDW+, although technically they
|
|
|
|
* only *work* from gen9+. For pre-BDW we instead have the option for
|
|
|
|
* 32K pages, but we don't currently have any support for it in our
|
|
|
|
* driver.
|
|
|
|
*/
|
|
|
|
if (HAS_PAGE_SIZES(i915, I915_GTT_PAGE_SIZE_64K) &&
|
2021-06-05 15:53:52 +00:00
|
|
|
GRAPHICS_VER(i915) <= 10)
|
2020-01-07 13:40:09 +00:00
|
|
|
intel_uncore_rmw(uncore,
|
|
|
|
GEN8_GAMW_ECO_DEV_RW_IA,
|
|
|
|
0,
|
|
|
|
GAMW_ECO_ENABLE_64K_IPS_FIELD);
|
|
|
|
|
2021-06-05 15:53:52 +00:00
|
|
|
if (IS_GRAPHICS_VER(i915, 8, 11)) {
|
2020-01-07 13:40:09 +00:00
|
|
|
bool can_use_gtt_cache = true;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* According to the BSpec if we use 2M/1G pages then we also
|
|
|
|
* need to disable the GTT cache. At least on BDW we can see
|
|
|
|
* visual corruption when using 2M pages, and not disabling the
|
|
|
|
* GTT cache.
|
|
|
|
*/
|
|
|
|
if (HAS_PAGE_SIZES(i915, I915_GTT_PAGE_SIZE_2M))
|
|
|
|
can_use_gtt_cache = false;
|
|
|
|
|
|
|
|
/* WaGttCachingOffByDefault */
|
|
|
|
intel_uncore_write(uncore,
|
|
|
|
HSW_GTT_CACHE_EN,
|
|
|
|
can_use_gtt_cache ? GTT_CACHE_EN_ALL : 0);
|
drm/i915/gt: Make WARN* drm specific where drm_priv ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
command: spatch --sp-file <script> --dir drivers/gpu/drm/i915/gt \
--linux-spacing --in-place
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200115034455.17658-7-pankaj.laxminarayan.bharadiya@intel.com
2020-01-15 03:44:50 +00:00
|
|
|
drm_WARN_ON_ONCE(&i915->drm, can_use_gtt_cache &&
|
|
|
|
intel_uncore_read(uncore,
|
|
|
|
HSW_GTT_CACHE_EN) == 0);
|
2020-01-07 13:40:09 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void tgl_setup_private_ppat(struct intel_uncore *uncore)
|
|
|
|
{
|
|
|
|
/* TGL doesn't support LLC or AGE settings */
|
|
|
|
intel_uncore_write(uncore, GEN12_PAT_INDEX(0), GEN8_PPAT_WB);
|
|
|
|
intel_uncore_write(uncore, GEN12_PAT_INDEX(1), GEN8_PPAT_WC);
|
|
|
|
intel_uncore_write(uncore, GEN12_PAT_INDEX(2), GEN8_PPAT_WT);
|
|
|
|
intel_uncore_write(uncore, GEN12_PAT_INDEX(3), GEN8_PPAT_UC);
|
|
|
|
intel_uncore_write(uncore, GEN12_PAT_INDEX(4), GEN8_PPAT_WB);
|
|
|
|
intel_uncore_write(uncore, GEN12_PAT_INDEX(5), GEN8_PPAT_WB);
|
|
|
|
intel_uncore_write(uncore, GEN12_PAT_INDEX(6), GEN8_PPAT_WB);
|
|
|
|
intel_uncore_write(uncore, GEN12_PAT_INDEX(7), GEN8_PPAT_WB);
|
|
|
|
}
|
|
|
|
|
2021-07-28 22:03:26 +00:00
|
|
|
static void icl_setup_private_ppat(struct intel_uncore *uncore)
|
2020-01-07 13:40:09 +00:00
|
|
|
{
|
|
|
|
intel_uncore_write(uncore,
|
|
|
|
GEN10_PAT_INDEX(0),
|
|
|
|
GEN8_PPAT_WB | GEN8_PPAT_LLC);
|
|
|
|
intel_uncore_write(uncore,
|
|
|
|
GEN10_PAT_INDEX(1),
|
|
|
|
GEN8_PPAT_WC | GEN8_PPAT_LLCELLC);
|
|
|
|
intel_uncore_write(uncore,
|
|
|
|
GEN10_PAT_INDEX(2),
|
2020-10-15 12:21:37 +00:00
|
|
|
GEN8_PPAT_WB | GEN8_PPAT_ELLC_OVERRIDE);
|
2020-01-07 13:40:09 +00:00
|
|
|
intel_uncore_write(uncore,
|
|
|
|
GEN10_PAT_INDEX(3),
|
|
|
|
GEN8_PPAT_UC);
|
|
|
|
intel_uncore_write(uncore,
|
|
|
|
GEN10_PAT_INDEX(4),
|
|
|
|
GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(0));
|
|
|
|
intel_uncore_write(uncore,
|
|
|
|
GEN10_PAT_INDEX(5),
|
|
|
|
GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(1));
|
|
|
|
intel_uncore_write(uncore,
|
|
|
|
GEN10_PAT_INDEX(6),
|
|
|
|
GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(2));
|
|
|
|
intel_uncore_write(uncore,
|
|
|
|
GEN10_PAT_INDEX(7),
|
|
|
|
GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(3));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The GGTT and PPGTT need a private PPAT setup in order to handle cacheability
|
|
|
|
* bits. When using advanced contexts each context stores its own PAT, but
|
|
|
|
* writing this data shouldn't be harmful even in those cases.
|
|
|
|
*/
|
|
|
|
static void bdw_setup_private_ppat(struct intel_uncore *uncore)
|
|
|
|
{
|
2020-10-15 12:21:37 +00:00
|
|
|
struct drm_i915_private *i915 = uncore->i915;
|
2020-01-07 13:40:09 +00:00
|
|
|
u64 pat;
|
|
|
|
|
|
|
|
pat = GEN8_PPAT(0, GEN8_PPAT_WB | GEN8_PPAT_LLC) | /* for normal objects, no eLLC */
|
|
|
|
GEN8_PPAT(1, GEN8_PPAT_WC | GEN8_PPAT_LLCELLC) | /* for something pointing to ptes? */
|
|
|
|
GEN8_PPAT(3, GEN8_PPAT_UC) | /* Uncached objects, mostly for scanout */
|
|
|
|
GEN8_PPAT(4, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(0)) |
|
|
|
|
GEN8_PPAT(5, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(1)) |
|
|
|
|
GEN8_PPAT(6, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(2)) |
|
|
|
|
GEN8_PPAT(7, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(3));
|
|
|
|
|
2020-10-15 12:21:37 +00:00
|
|
|
/* for scanout with eLLC */
|
2021-06-05 15:53:52 +00:00
|
|
|
if (GRAPHICS_VER(i915) >= 9)
|
2020-10-15 12:21:37 +00:00
|
|
|
pat |= GEN8_PPAT(2, GEN8_PPAT_WB | GEN8_PPAT_ELLC_OVERRIDE);
|
|
|
|
else
|
|
|
|
pat |= GEN8_PPAT(2, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC);
|
|
|
|
|
2020-01-07 13:40:09 +00:00
|
|
|
intel_uncore_write(uncore, GEN8_PRIVATE_PAT_LO, lower_32_bits(pat));
|
|
|
|
intel_uncore_write(uncore, GEN8_PRIVATE_PAT_HI, upper_32_bits(pat));
|
|
|
|
}
|
|
|
|
|
|
|
|
static void chv_setup_private_ppat(struct intel_uncore *uncore)
|
|
|
|
{
|
|
|
|
u64 pat;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Map WB on BDW to snooped on CHV.
|
|
|
|
*
|
|
|
|
* Only the snoop bit has meaning for CHV, the rest is
|
|
|
|
* ignored.
|
|
|
|
*
|
|
|
|
* The hardware will never snoop for certain types of accesses:
|
|
|
|
* - CPU GTT (GMADR->GGTT->no snoop->memory)
|
|
|
|
* - PPGTT page tables
|
|
|
|
* - some other special cycles
|
|
|
|
*
|
|
|
|
* As with BDW, we also need to consider the following for GT accesses:
|
|
|
|
* "For GGTT, there is NO pat_sel[2:0] from the entry,
|
|
|
|
* so RTL will always use the value corresponding to
|
|
|
|
* pat_sel = 000".
|
|
|
|
* Which means we must set the snoop bit in PAT entry 0
|
|
|
|
* in order to keep the global status page working.
|
|
|
|
*/
|
|
|
|
|
|
|
|
pat = GEN8_PPAT(0, CHV_PPAT_SNOOP) |
|
|
|
|
GEN8_PPAT(1, 0) |
|
|
|
|
GEN8_PPAT(2, 0) |
|
|
|
|
GEN8_PPAT(3, 0) |
|
|
|
|
GEN8_PPAT(4, CHV_PPAT_SNOOP) |
|
|
|
|
GEN8_PPAT(5, CHV_PPAT_SNOOP) |
|
|
|
|
GEN8_PPAT(6, CHV_PPAT_SNOOP) |
|
|
|
|
GEN8_PPAT(7, CHV_PPAT_SNOOP);
|
|
|
|
|
|
|
|
intel_uncore_write(uncore, GEN8_PRIVATE_PAT_LO, lower_32_bits(pat));
|
|
|
|
intel_uncore_write(uncore, GEN8_PRIVATE_PAT_HI, upper_32_bits(pat));
|
|
|
|
}
|
|
|
|
|
|
|
|
void setup_private_pat(struct intel_uncore *uncore)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *i915 = uncore->i915;
|
|
|
|
|
2021-06-05 15:53:52 +00:00
|
|
|
GEM_BUG_ON(GRAPHICS_VER(i915) < 8);
|
2020-01-07 13:40:09 +00:00
|
|
|
|
2021-06-05 15:53:52 +00:00
|
|
|
if (GRAPHICS_VER(i915) >= 12)
|
2020-01-07 13:40:09 +00:00
|
|
|
tgl_setup_private_ppat(uncore);
|
2021-07-28 22:03:26 +00:00
|
|
|
else if (GRAPHICS_VER(i915) >= 11)
|
|
|
|
icl_setup_private_ppat(uncore);
|
2020-01-07 13:40:09 +00:00
|
|
|
else if (IS_CHERRYVIEW(i915) || IS_GEN9_LP(i915))
|
|
|
|
chv_setup_private_ppat(uncore);
|
|
|
|
else
|
|
|
|
bdw_setup_private_ppat(uncore);
|
|
|
|
}
|
|
|
|
|
2020-12-19 02:03:43 +00:00
|
|
|
struct i915_vma *
|
|
|
|
__vm_create_scratch_for_read(struct i915_address_space *vm, unsigned long size)
|
|
|
|
{
|
|
|
|
struct drm_i915_gem_object *obj;
|
|
|
|
struct i915_vma *vma;
|
|
|
|
|
|
|
|
obj = i915_gem_object_create_internal(vm->i915, PAGE_ALIGN(size));
|
|
|
|
if (IS_ERR(obj))
|
|
|
|
return ERR_CAST(obj);
|
|
|
|
|
|
|
|
i915_gem_object_set_cache_coherency(obj, I915_CACHING_CACHED);
|
|
|
|
|
|
|
|
vma = i915_vma_instance(obj, vm, NULL);
|
|
|
|
if (IS_ERR(vma)) {
|
|
|
|
i915_gem_object_put(obj);
|
|
|
|
return vma;
|
|
|
|
}
|
|
|
|
|
2021-03-23 15:50:13 +00:00
|
|
|
return vma;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct i915_vma *
|
|
|
|
__vm_create_scratch_for_read_pinned(struct i915_address_space *vm, unsigned long size)
|
|
|
|
{
|
|
|
|
struct i915_vma *vma;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
vma = __vm_create_scratch_for_read(vm, size);
|
|
|
|
if (IS_ERR(vma))
|
|
|
|
return vma;
|
|
|
|
|
2020-12-19 02:03:43 +00:00
|
|
|
err = i915_vma_pin(vma, 0, 0,
|
|
|
|
i915_vma_is_ggtt(vma) ? PIN_GLOBAL : PIN_USER);
|
|
|
|
if (err) {
|
|
|
|
i915_vma_put(vma);
|
|
|
|
return ERR_PTR(err);
|
|
|
|
}
|
|
|
|
|
|
|
|
return vma;
|
|
|
|
}
|
|
|
|
|
2020-01-07 13:40:09 +00:00
|
|
|
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
|
|
|
|
#include "selftests/mock_gtt.c"
|
|
|
|
#endif
|