From: Jason Ekstrand <jason@jlekstrand.net>
To: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: Matthew Auld <matthew.auld@intel.com>
Subject: [Intel-gfx] [PATCH 1/7] drm/i915/gem: Check object_can_migrate from object_migrate
Date: Wed, 21 Jul 2021 15:13:37 -0500 [thread overview]
Message-ID: <20210721201343.2962674-2-jason@jlekstrand.net> (raw)
In-Reply-To: <20210721201343.2962674-1-jason@jlekstrand.net>
We don't roll them together entirely because there are still a couple
cases where we want a separate can_migrate check. For instance, the
display code checks that you can migrate a buffer to LMEM before it
accepts it in fb_create. The dma-buf import code also uses it to do an
early check and return a different error code if someone tries to attach
a LMEM-only dma-buf to another driver.
However, no one actually wants to call object_migrate when can_migrate
has failed. The stated intention is for self-tests but none of those
actually take advantage of this unsafe migration.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: Daniel Vetter <daniel@ffwll.ch>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 13 ++-----------
.../gpu/drm/i915/gem/selftests/i915_gem_migrate.c | 15 ---------------
2 files changed, 2 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 9da7b288b7ede..f2244ae09a613 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -584,12 +584,6 @@ bool i915_gem_object_can_migrate(struct drm_i915_gem_object *obj,
* completed yet, and to accomplish that, i915_gem_object_wait_migration()
* must be called.
*
- * This function is a bit more permissive than i915_gem_object_can_migrate()
- * to allow for migrating objects where the caller knows exactly what is
- * happening. For example within selftests. More specifically this
- * function allows migrating I915_BO_ALLOC_USER objects to regions
- * that are not in the list of allowable regions.
- *
* Note: the @ww parameter is not used yet, but included to make sure
* callers put some effort into obtaining a valid ww ctx if one is
* available.
@@ -616,11 +610,8 @@ int i915_gem_object_migrate(struct drm_i915_gem_object *obj,
if (obj->mm.region == mr)
return 0;
- if (!i915_gem_object_evictable(obj))
- return -EBUSY;
-
- if (!obj->ops->migrate)
- return -EOPNOTSUPP;
+ if (!i915_gem_object_can_migrate(obj, id))
+ return -EINVAL;
return obj->ops->migrate(obj, mr);
}
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
index 0b7144d2991ca..28a700f08b49a 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
@@ -61,11 +61,6 @@ static int igt_create_migrate(struct intel_gt *gt, enum intel_region_id src,
if (err)
continue;
- if (!i915_gem_object_can_migrate(obj, dst)) {
- err = -EINVAL;
- continue;
- }
-
err = i915_gem_object_migrate(obj, &ww, dst);
if (err)
continue;
@@ -114,11 +109,6 @@ static int lmem_pages_migrate_one(struct i915_gem_ww_ctx *ww,
return err;
if (i915_gem_object_is_lmem(obj)) {
- if (!i915_gem_object_can_migrate(obj, INTEL_REGION_SMEM)) {
- pr_err("object can't migrate to smem.\n");
- return -EINVAL;
- }
-
err = i915_gem_object_migrate(obj, ww, INTEL_REGION_SMEM);
if (err) {
pr_err("Object failed migration to smem\n");
@@ -137,11 +127,6 @@ static int lmem_pages_migrate_one(struct i915_gem_ww_ctx *ww,
}
} else {
- if (!i915_gem_object_can_migrate(obj, INTEL_REGION_LMEM)) {
- pr_err("object can't migrate to lmem.\n");
- return -EINVAL;
- }
-
err = i915_gem_object_migrate(obj, ww, INTEL_REGION_LMEM);
if (err) {
pr_err("Object failed migration to lmem\n");
--
2.31.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2021-07-21 20:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-21 20:13 [Intel-gfx] [PATCH 0/7] drm/i915: Migrate memory to SMEM when imported cross-device (v8) Jason Ekstrand
2021-07-21 20:13 ` Jason Ekstrand [this message]
2021-07-21 20:13 ` [Intel-gfx] [PATCH 2/7] drm/i915/gem: Refactor placement setup for i915_gem_object_create* (v2) Jason Ekstrand
2021-07-21 20:13 ` [Intel-gfx] [PATCH 3/7] drm/i915/gem: Call i915_gem_flush_free_objects() in i915_gem_dumb_create() Jason Ekstrand
2021-07-21 20:13 ` [Intel-gfx] [PATCH 4/7] drm/i915/gem: Unify user object creation (v3) Jason Ekstrand
2021-07-21 20:13 ` [Intel-gfx] [PATCH 5/7] drm/i915/gem/ttm: Respect the objection region in placement_from_obj Jason Ekstrand
2021-07-21 20:13 ` [Intel-gfx] [PATCH 6/7] drm/i915/gem: Correct the locking and pin pattern for dma-buf (v8) Jason Ekstrand
2021-07-21 20:13 ` [Intel-gfx] [PATCH 7/7] drm/i915/gem: Migrate to system at dma-buf attach time (v7) Jason Ekstrand
2021-07-21 21:20 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Migrate memory to SMEM when imported cross-device (rev3) Patchwork
2021-07-21 21:50 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-07-22 3:22 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2021-07-16 14:14 [Intel-gfx] [PATCH 0/7] drm/i915: Migrate memory to SMEM when imported cross-device (v7) Jason Ekstrand
2021-07-16 14:14 ` [Intel-gfx] [PATCH 1/7] drm/i915/gem: Check object_can_migrate from object_migrate Jason Ekstrand
2021-07-15 22:38 [Intel-gfx] [PATCH 0/7] drm/i915: Migrate memory to SMEM when imported cross-device Jason Ekstrand
2021-07-15 22:38 ` [Intel-gfx] [PATCH 1/7] drm/i915/gem: Check object_can_migrate from object_migrate Jason Ekstrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210721201343.2962674-2-jason@jlekstrand.net \
--to=jason@jlekstrand.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=matthew.auld@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).