All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Intel-gfx@lists.freedesktop.org
Subject: [RFC 23/33] drm/i915: Convert i915_gem_flush_ggtt_writes to intel_gt
Date: Mon, 17 Jun 2019 19:12:26 +0100	[thread overview]
Message-ID: <20190617181236.7981-24-tvrtko.ursulin@linux.intel.com> (raw)
In-Reply-To: <20190617181236.7981-1-tvrtko.ursulin@linux.intel.com>

From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Having introduced struct intel_gt (named the anonymous structure in i915)
we can start using it to compartmentalize our code better. It makes more
sense logically to have the code internally like this and it will also
help with future split between gt and display in i915.

v2:
 * Keep ggtt flush before fb obj flush. (Chris)

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c    | 12 +++---
 .../drm/i915/gem/selftests/i915_gem_mman.c    |  3 +-
 drivers/gpu/drm/i915/gt/intel_gt.c            | 41 +++++++++++++++++++
 drivers/gpu/drm/i915/gt/intel_gt.h            |  2 +
 drivers/gpu/drm/i915/i915_drv.h               |  2 -
 drivers/gpu/drm/i915/i915_gem.c               | 40 ------------------
 drivers/gpu/drm/i915/i915_vma.c               |  3 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |  2 +-
 8 files changed, 54 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index a4047a585c8b..f58d45ae10d0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -22,6 +22,7 @@
  *
  */
 
+#include "gt/intel_gt.h"
 #include "i915_drv.h"
 #include "i915_gem_clflush.h"
 #include "i915_gem_context.h"
@@ -367,7 +368,6 @@ void
 i915_gem_object_flush_write_domain(struct drm_i915_gem_object *obj,
 				   unsigned int flush_domains)
 {
-	struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
 	struct i915_vma *vma;
 
 	assert_object_held(obj);
@@ -377,17 +377,17 @@ i915_gem_object_flush_write_domain(struct drm_i915_gem_object *obj,
 
 	switch (obj->write_domain) {
 	case I915_GEM_DOMAIN_GTT:
-		i915_gem_flush_ggtt_writes(dev_priv);
-
-		intel_fb_obj_flush(obj,
-				   fb_write_origin(obj, I915_GEM_DOMAIN_GTT));
-
 		for_each_ggtt_vma(vma, obj) {
 			if (vma->iomap)
 				continue;
 
+			intel_gt_flush_ggtt_writes(vma->vm->gt);
 			i915_vma_unset_ggtt_write(vma);
+			break;
 		}
+
+		intel_fb_obj_flush(obj,
+				   fb_write_origin(obj, I915_GEM_DOMAIN_GTT));
 		break;
 
 	case I915_GEM_DOMAIN_WC:
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index 5c81f4b4813a..2812f7fa27fe 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -6,6 +6,7 @@
 
 #include <linux/prime_numbers.h>
 
+#include "gt/intel_gt.h"
 #include "gt/intel_gt_pm.h"
 #include "huge_gem_object.h"
 #include "i915_selftest.h"
@@ -143,7 +144,7 @@ static int check_partial_mapping(struct drm_i915_gem_object *obj,
 		if (offset >= obj->base.size)
 			continue;
 
-		i915_gem_flush_ggtt_writes(to_i915(obj->base.dev));
+		intel_gt_flush_ggtt_writes(&to_i915(obj->base.dev)->gt);
 
 		p = i915_gem_object_get_page(obj, offset >> PAGE_SHIFT);
 		cpu = kmap(p) + offset_in_page(offset);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c b/drivers/gpu/drm/i915/gt/intel_gt.c
index 6f6f61cc142d..2500bef06af4 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -150,3 +150,44 @@ void intel_gt_check_and_clear_faults(struct intel_gt *gt)
 
 	intel_gt_clear_error_registers(gt, ALL_ENGINES);
 }
+
+void intel_gt_flush_ggtt_writes(struct intel_gt *gt)
+{
+	struct drm_i915_private *i915 = gt->i915;
+	intel_wakeref_t wakeref;
+
+	/*
+	 * No actual flushing is required for the GTT write domain for reads
+	 * from the GTT domain. Writes to it "immediately" go to main memory
+	 * as far as we know, so there's no chipset flush. It also doesn't
+	 * land in the GPU render cache.
+	 *
+	 * However, we do have to enforce the order so that all writes through
+	 * the GTT land before any writes to the device, such as updates to
+	 * the GATT itself.
+	 *
+	 * We also have to wait a bit for the writes to land from the GTT.
+	 * An uncached read (i.e. mmio) seems to be ideal for the round-trip
+	 * timing. This issue has only been observed when switching quickly
+	 * between GTT writes and CPU reads from inside the kernel on recent hw,
+	 * and it appears to only affect discrete GTT blocks (i.e. on LLC
+	 * system agents we cannot reproduce this behaviour, until Cannonlake
+	 * that was!).
+	 */
+
+	wmb();
+
+	if (INTEL_INFO(i915)->has_coherent_ggtt)
+		return;
+
+	i915_gem_chipset_flush(i915);
+
+	with_intel_runtime_pm(&i915->runtime_pm, wakeref) {
+		struct intel_uncore *uncore = gt->uncore;
+
+		spin_lock_irq(&uncore->lock);
+		intel_uncore_posting_read_fw(uncore,
+					     RING_HEAD(RENDER_RING_BASE));
+		spin_unlock_irq(&uncore->lock);
+	}
+}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h b/drivers/gpu/drm/i915/gt/intel_gt.h
index 1847c189bd78..d894c1178116 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -18,4 +18,6 @@ void intel_gt_check_and_clear_faults(struct intel_gt *gt);
 void intel_gt_clear_error_registers(struct intel_gt *gt,
 				    intel_engine_mask_t engine_mask);
 
+void intel_gt_flush_ggtt_writes(struct intel_gt *gt);
+
 #endif /* __INTEL_GT_H__ */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2c4c8ee4133b..d9c02bf42052 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2600,8 +2600,6 @@ int __must_check i915_gem_evict_for_node(struct i915_address_space *vm,
 					 unsigned int flags);
 int i915_gem_evict_vm(struct i915_address_space *vm);
 
-void i915_gem_flush_ggtt_writes(struct drm_i915_private *dev_priv);
-
 /* belongs in i915_gem_gtt.h */
 static inline void i915_gem_chipset_flush(struct drm_i915_private *dev_priv)
 {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ac76ac781afe..79c718f053cd 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -232,46 +232,6 @@ i915_gem_create_ioctl(struct drm_device *dev, void *data,
 			       &args->size, &args->handle);
 }
 
-void i915_gem_flush_ggtt_writes(struct drm_i915_private *dev_priv)
-{
-	intel_wakeref_t wakeref;
-
-	/*
-	 * No actual flushing is required for the GTT write domain for reads
-	 * from the GTT domain. Writes to it "immediately" go to main memory
-	 * as far as we know, so there's no chipset flush. It also doesn't
-	 * land in the GPU render cache.
-	 *
-	 * However, we do have to enforce the order so that all writes through
-	 * the GTT land before any writes to the device, such as updates to
-	 * the GATT itself.
-	 *
-	 * We also have to wait a bit for the writes to land from the GTT.
-	 * An uncached read (i.e. mmio) seems to be ideal for the round-trip
-	 * timing. This issue has only been observed when switching quickly
-	 * between GTT writes and CPU reads from inside the kernel on recent hw,
-	 * and it appears to only affect discrete GTT blocks (i.e. on LLC
-	 * system agents we cannot reproduce this behaviour, until Cannonlake
-	 * that was!).
-	 */
-
-	wmb();
-
-	if (INTEL_INFO(dev_priv)->has_coherent_ggtt)
-		return;
-
-	i915_gem_chipset_flush(dev_priv);
-
-	with_intel_runtime_pm(&dev_priv->runtime_pm, wakeref) {
-		struct intel_uncore *uncore = &dev_priv->uncore;
-
-		spin_lock_irq(&uncore->lock);
-		intel_uncore_posting_read_fw(uncore,
-					     RING_HEAD(RENDER_RING_BASE));
-		spin_unlock_irq(&uncore->lock);
-	}
-}
-
 static int
 shmem_pread(struct page *page, int offset, int len, char __user *user_data,
 	    bool needs_clflush)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index b295c53085ee..571c6ddd7eaf 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -23,6 +23,7 @@
  */
 
 #include "gt/intel_engine.h"
+#include "gt/intel_gt.h"
 
 #include "i915_vma.h"
 
@@ -408,7 +409,7 @@ void i915_vma_flush_writes(struct i915_vma *vma)
 	if (!i915_vma_has_ggtt_write(vma))
 		return;
 
-	i915_gem_flush_ggtt_writes(vma->vm->i915);
+	intel_gt_flush_ggtt_writes(vma->vm->gt);
 
 	i915_vma_unset_ggtt_write(vma);
 }
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index 1a60b9fe8221..d9531cb5f235 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -1195,7 +1195,7 @@ static int igt_ggtt_page(void *arg)
 		iowrite32(n, vaddr + n);
 		io_mapping_unmap_atomic(vaddr);
 	}
-	i915_gem_flush_ggtt_writes(i915);
+	intel_gt_flush_ggtt_writes(ggtt->vm.gt);
 
 	i915_random_reorder(order, count, &prng);
 	for (n = 0; n < count; n++) {
-- 
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-06-17 18:13 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-17 18:12 [RFC v5 00/33] Implicit dev_priv removal and GT compartmentalization Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 01/33] drm/i915: Convert intel_vgt_(de)balloon to uncore Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 02/33] drm/i915: Introduce struct intel_gt as replacement for anonymous i915->gt Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 03/33] drm/i915: Move intel_gt initialization to a separate file Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 04/33] drm/i915: Store some backpointers in struct intel_gt Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 05/33] drm/i915: Move intel_gt_pm_init under intel_gt_init_early Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 06/33] drm/i915: Make i915_check_and_clear_faults take intel_gt Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 07/33] drm/i915: Convert i915_gem_init_swizzling to intel_gt Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 08/33] drm/i915: Use intel_uncore_rmw in intel_gt_init_swizzling Tvrtko Ursulin
2019-06-17 19:57   ` Chris Wilson
2019-06-17 18:12 ` [RFC 09/33] drm/i915: Convert init_unused_rings to intel_gt Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 10/33] drm/i915: Convert gt workarounds " Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 11/33] drm/i915: Store backpointer to intel_gt in the engine Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 12/33] drm/i915: Convert intel_mocs_init_l3cc_table to intel_gt Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 13/33] drm/i915: Convert i915_ppgtt_init_hw " Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 14/33] drm/i915: Consolidate some open coded mmio rmw Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 15/33] drm/i915: Convert i915_gem_init_hw to intel_gt Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 16/33] drm/i915: Move intel_engines_resume into common init Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 17/33] drm/i915: Stop using I915_READ/WRITE in intel_wopcm_init_hw Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 18/33] drm/i915: Compartmentalize i915_ggtt_probe_hw Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 19/33] drm/i915: Compartmentalize i915_ggtt_init_hw Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 20/33] drm/i915: Make ggtt invalidation work on ggtt Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 21/33] drm/i915: Store intel_gt backpointer in vm Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 22/33] drm/i915: Compartmentalize i915_gem_suspend/restore_gtt_mappings Tvrtko Ursulin
2019-06-17 18:12 ` Tvrtko Ursulin [this message]
2019-06-17 20:01   ` [RFC 23/33] drm/i915: Convert i915_gem_flush_ggtt_writes to intel_gt Chris Wilson
2019-06-18  7:02     ` Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 24/33] drm/i915: Move i915_gem_chipset_flush " Tvrtko Ursulin
2019-06-17 20:03   ` Chris Wilson
2019-06-17 18:12 ` [RFC 25/33] drm/i915: Compartmentalize timeline_init/park/fini Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 26/33] drm/i915: Compartmentalize i915_ggtt_cleanup_hw Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 27/33] drm/i915: Compartmentalize i915_gem_init_ggtt Tvrtko Ursulin
2019-06-17 20:04   ` Chris Wilson
2019-06-17 18:12 ` [RFC 28/33] drm/i915: Store ggtt pointer in intel_gt Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 29/33] drm/i915: Compartmentalize ring buffer creation Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 30/33] drm/i915: Save trip via top-level i915 in a few more places Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 31/33] drm/i915: Make timelines gt centric Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 32/33] drm/i915: Rename i915_timeline to intel_timeline and move under gt Tvrtko Ursulin
2019-06-17 18:12 ` [RFC 33/33] drm/i915: Eliminate dual personality of i915_scratch_offset Tvrtko Ursulin
2019-06-17 20:07   ` Chris Wilson
2019-06-17 19:08 ` ✗ Fi.CI.BAT: failure for Implicit dev_priv removal and GT compartmentalization (rev9) Patchwork

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=20190617181236.7981-24-tvrtko.ursulin@linux.intel.com \
    --to=tvrtko.ursulin@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.