public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Matthew Auld <matthew.auld@intel.com>
To: intel-gfx@lists.freedesktop.org
Subject: [PATCH v2 20/22] drm/i915/selftests: fallback to using the gpu to trash stolen
Date: Thu,  3 Oct 2019 20:24:42 +0100	[thread overview]
Message-ID: <20191003192444.10113-21-matthew.auld@intel.com> (raw)
In-Reply-To: <20191003192444.10113-1-matthew.auld@intel.com>

If we lack a mappable aperture, opt for nuking stolen memory with the
blitter engine.

Signed-off-by: Matthew Auld <matthew.auld@intel.com>
---
 drivers/gpu/drm/i915/selftests/i915_gem.c | 95 +++++++++++++++++++----
 1 file changed, 80 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem.c b/drivers/gpu/drm/i915/selftests/i915_gem.c
index 37593831b539..c4d7599af4f7 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem.c
@@ -6,6 +6,8 @@
 
 #include <linux/random.h>
 
+#include "gem/i915_gem_region.h"
+#include "gem/i915_gem_object_blt.h"
 #include "gem/selftests/igt_gem_utils.h"
 #include "gem/selftests/mock_context.h"
 #include "gt/intel_gt.h"
@@ -34,14 +36,25 @@ static int switch_to_context(struct drm_i915_private *i915,
 	return 0;
 }
 
-static void trash_stolen(struct drm_i915_private *i915)
+static void trash_stolen_cpu(struct drm_i915_private *i915)
 {
 	struct i915_ggtt *ggtt = &i915->ggtt;
 	const u64 slot = ggtt->error_capture.start;
 	const resource_size_t size = resource_size(&i915->dsm);
+	intel_wakeref_t wakeref;
 	unsigned long page;
 	u32 prng = 0x12345678;
 
+	/*
+	 * As a final sting in the tail, invalidate stolen. Under a real S4,
+	 * stolen is lost and needs to be refilled on resume. However, under
+	 * CI we merely do S4-device testing (as full S4 is too unreliable
+	 * for automated testing across a cluster), so to simulate the effect
+	 * of stolen being trashed across S4, we trash it ourselves.
+	 */
+
+	wakeref = intel_runtime_pm_get(&i915->runtime_pm);
+
 	for (page = 0; page < size; page += PAGE_SIZE) {
 		const dma_addr_t dma = i915->dsm.start + page;
 		u32 __iomem *s;
@@ -58,24 +71,53 @@ static void trash_stolen(struct drm_i915_private *i915)
 	}
 
 	ggtt->vm.clear_range(&ggtt->vm, slot, PAGE_SIZE);
+
+	intel_runtime_pm_put(&i915->runtime_pm, wakeref);
 }
 
-static void simulate_hibernate(struct drm_i915_private *i915)
+static int trash_stolen_gpu(struct i915_gem_context *ctx)
 {
-	intel_wakeref_t wakeref;
+	struct drm_i915_private *i915 = ctx->vm->i915;
+	const resource_size_t size = resource_size(&i915->dsm);
+	struct intel_memory_region *clone;
+	struct drm_i915_gem_object *obj;
+	struct intel_context *ce;
+	u32 prng = 0x12345678;
+	int err;
 
-	wakeref = intel_runtime_pm_get(&i915->runtime_pm);
+	if (!HAS_ENGINE(i915, BCS0))
+		return 0;
 
-	/*
-	 * As a final sting in the tail, invalidate stolen. Under a real S4,
-	 * stolen is lost and needs to be refilled on resume. However, under
-	 * CI we merely do S4-device testing (as full S4 is too unreliable
-	 * for automated testing across a cluster), so to simulate the effect
-	 * of stolen being trashed across S4, we trash it ourselves.
-	 */
-	trash_stolen(i915);
+	if (!size)
+		return 0;
 
-	intel_runtime_pm_put(&i915->runtime_pm, wakeref);
+	clone = mock_region_create(i915, i915->dsm.start, size, PAGE_SIZE, 0);
+	if (IS_ERR(clone))
+		return PTR_ERR(clone);
+
+	obj = i915_gem_object_create_region(clone, size, 0);
+	if (IS_ERR(obj)) {
+		err = PTR_ERR(obj);
+		goto out_region;
+	}
+
+	ce = i915_gem_context_get_engine(ctx, BCS0);
+	if (IS_ERR(ce)) {
+		err = PTR_ERR(ce);
+		goto out_put;
+	}
+
+	mutex_lock(&i915->drm.struct_mutex);
+	err = i915_gem_object_fill_blt(obj, ce, prng);
+	mutex_unlock(&i915->drm.struct_mutex);
+
+	intel_context_put(ce);
+out_put:
+	i915_gem_object_put(obj);
+out_region:
+	intel_memory_region_put(clone);
+
+	return err;
 }
 
 static int pm_prepare(struct drm_i915_private *i915)
@@ -148,6 +190,21 @@ static int igt_gem_suspend(void *arg)
 	if (err)
 		goto out;
 
+	/*
+	 * If we lack the mappable aperture we can't really access stolen from
+	 * the cpu, but we can always trash it from the gpu, we just need to do
+	 * so early, before we start suspending stuff. We shouldn't see any
+	 * hangs doing this so early, since things like ring state won't be
+	 * allocated in stolen if we can't access it from the cpu. Although if
+	 * that's the case maybe there is not much point in bothering with this
+	 * anyway...
+	 */
+	if (!HAS_MAPPABLE_APERTURE(i915)) {
+		err = trash_stolen_gpu(ctx);
+		if (err)
+			goto out;
+	}
+
 	err = pm_prepare(i915);
 	if (err)
 		goto out;
@@ -155,7 +212,8 @@ static int igt_gem_suspend(void *arg)
 	pm_suspend(i915);
 
 	/* Here be dragons! Note that with S3RST any S3 may become S4! */
-	simulate_hibernate(i915);
+	if (HAS_MAPPABLE_APERTURE(i915))
+		trash_stolen_cpu(i915);
 
 	pm_resume(i915);
 
@@ -187,6 +245,12 @@ static int igt_gem_hibernate(void *arg)
 	if (err)
 		goto out;
 
+	if (!HAS_MAPPABLE_APERTURE(i915)) {
+		err = trash_stolen_gpu(ctx);
+		if (err)
+			goto out;
+	}
+
 	err = pm_prepare(i915);
 	if (err)
 		goto out;
@@ -194,7 +258,8 @@ static int igt_gem_hibernate(void *arg)
 	pm_hibernate(i915);
 
 	/* Here be dragons! */
-	simulate_hibernate(i915);
+	if (HAS_MAPPABLE_APERTURE(i915))
+		trash_stolen_cpu(i915);
 
 	pm_resume(i915);
 
-- 
2.20.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2019-10-03 19:25 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-03 19:24 [PATCH v2 00/22] LMEM basics Matthew Auld
2019-10-03 19:24 ` [PATCH v2 01/22] drm/i915/stolen: make the object creation interface consistent Matthew Auld
2019-10-03 19:29   ` Chris Wilson
2019-10-03 19:24 ` [PATCH v2 02/22] drm/i915: introduce intel_memory_region Matthew Auld
2019-10-03 19:24 ` [PATCH v2 03/22] drm/i915/region: support contiguous allocations Matthew Auld
2019-10-03 19:24 ` [PATCH v2 04/22] drm/i915/region: support volatile objects Matthew Auld
2019-10-03 19:40   ` Chris Wilson
2019-10-03 19:24 ` [PATCH v2 05/22] drm/i915: Add memory region information to device_info Matthew Auld
2019-10-03 19:24 ` [PATCH v2 06/22] drm/i915: support creating LMEM objects Matthew Auld
2019-10-03 19:46   ` Chris Wilson
2019-10-03 19:24 ` [PATCH v2 07/22] drm/i915: setup io-mapping for LMEM Matthew Auld
2019-10-03 19:24 ` [PATCH v2 08/22] drm/i915/lmem: support kernel mapping Matthew Auld
2019-10-03 19:48   ` Chris Wilson
2019-10-03 19:24 ` [PATCH v2 09/22] drm/i915/selftests: add write-dword test for LMEM Matthew Auld
2019-10-03 19:24 ` [PATCH v2 10/22] drm/i915/selftests: extend coverage to include LMEM huge-pages Matthew Auld
2019-10-03 19:24 ` [PATCH v2 11/22] drm/i915: enumerate and init each supported region Matthew Auld
2019-10-03 19:24 ` [PATCH v2 12/22] drm/i915: treat shmem as a region Matthew Auld
2019-10-03 19:24 ` [PATCH v2 13/22] drm/i915: treat stolen " Matthew Auld
2019-10-03 19:43   ` Tang, CQ
2019-10-03 19:24 ` [PATCH v2 14/22] drm/i915: define HAS_MAPPABLE_APERTURE Matthew Auld
2019-10-03 19:53   ` Chris Wilson
2019-10-03 19:24 ` [PATCH v2 15/22] drm/i915: do not map aperture if it is not available Matthew Auld
2019-10-03 19:24 ` [PATCH v2 16/22] drm/i915: set num_fence_regs to 0 if there is no aperture Matthew Auld
2019-10-03 19:24 ` [PATCH v2 17/22] drm/i915: error capture with no ggtt slot Matthew Auld
2019-10-03 19:24 ` [PATCH v2 18/22] drm/i915: Don't try to place HWS in non-existing mappable region Matthew Auld
2019-10-03 19:24 ` [PATCH v2 19/22] drm/i915: don't allocate the ring in stolen if we lack aperture Matthew Auld
2019-10-03 19:37   ` Tang, CQ
2019-10-03 19:55   ` Chris Wilson
2019-10-03 19:24 ` Matthew Auld [this message]
2019-10-03 20:02   ` [PATCH v2 20/22] drm/i915/selftests: fallback to using the gpu to trash stolen Chris Wilson
2019-10-03 19:24 ` [PATCH v2 21/22] drm/i915/selftests: check for missing aperture Matthew Auld
2019-10-03 19:24 ` [PATCH v2 22/22] HAX drm/i915: add the fake lmem region Matthew Auld
2019-10-03 22:11 ` ✗ Fi.CI.CHECKPATCH: warning for LMEM basics (rev2) Patchwork
2019-10-03 22:21 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-10-03 22:34 ` ✓ Fi.CI.BAT: success " Patchwork
2019-10-04 11:34 ` ✗ Fi.CI.IGT: failure " Patchwork
2019-10-04 12:06   ` Kai Vehmanen
2019-10-04 12:08     ` Chris Wilson

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=20191003192444.10113-21-matthew.auld@intel.com \
    --to=matthew.auld@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /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