All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michał Winiarski" <michal.winiarski@intel.com>
To: intel-gfx@lists.freedesktop.org
Subject: [PATCH 5/8] drm/i915/guc: Use GuC FW size and HW restrictions to determine WOPCM partition
Date: Fri, 23 Mar 2018 13:34:08 +0100	[thread overview]
Message-ID: <20180323123411.3214-5-michal.winiarski@intel.com> (raw)
In-Reply-To: <20180323123411.3214-1-michal.winiarski@intel.com>

We need GuC to load HuC, but it's also possible for GuC to operate on
its own. We don't know what the size of HuC FW may be, so, not wanting
to make any platform-specific hardcoded guesses, we assume that its size
is 0... Which is a very bad approximation.
This has a very unfortunate consequence - once we've booted with GuC and
no HuC, we'll never be able to load HuC (unless we reboot, since the
registers are locked).
Rather than using unknown values in our computations - let's partition
based on GuC size.
We have one HW restriction where we're using HuC size (GuC size needs to
be roughly similar to HuC size - which may be unknown at this point),
luckily, another HW restriction makes it very unlikely to run in any
sort of issues in this case.

Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jackie Li <yaodong.li@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
---
 drivers/gpu/drm/i915/intel_wopcm.c | 60 +++++++++++++++++++++-----------------
 1 file changed, 34 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_wopcm.c b/drivers/gpu/drm/i915/intel_wopcm.c
index 52841d340002..295d302e97b9 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -167,7 +167,22 @@ static int check_ctx_rsvd_fits(struct intel_wopcm *wopcm, u32 ctx_rsvd)
 	return 0;
 }
 
-static int wopcm_check_hw_restrictions(struct intel_wopcm *wopcm)
+static inline void
+__guc_region_grow(struct intel_wopcm *wopcm, u32 size)
+{
+	/*
+	 * We're growing guc region in the direction of lower addresses.
+	 * We need to use multiples of base alignment, because it has more
+	 * strict alignment rules.
+	 */
+	size = DIV_ROUND_UP(size, 2);
+	size = ALIGN(size, GUC_WOPCM_OFFSET_ALIGNMENT);
+
+	wopcm->guc.base -= size;
+	wopcm->guc.size += size;
+}
+
+static void wopcm_adjust_for_hw_restrictions(struct intel_wopcm *wopcm)
 {
 	struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
 	u32 huc_fw_size = intel_uc_fw_get_upload_size(&i915->huc.fw);
@@ -177,22 +192,18 @@ static int wopcm_check_hw_restrictions(struct intel_wopcm *wopcm)
 		size = gen9_size_for_dword_gap_restriction(wopcm->guc.base,
 							   wopcm->guc.size);
 		if (size)
-			goto err;
+			__guc_region_grow(wopcm, size);
 
 		size = gen9_size_for_huc_restriction(wopcm->guc.size,
 						     huc_fw_size);
 		if (size)
-			goto err;
-	}
-
-	return 0;
+			__guc_region_grow(wopcm, size);
 
-err:
-	DRM_ERROR("GuC WOPCM size %uKiB is too small. %uKiB more needed.\n",
-		  wopcm->guc.size / 1024,
-		  size / 1024);
-
-	return -E2BIG;
+		GEM_BUG_ON(gen9_size_for_dword_gap_restriction(wopcm->guc.base,
+							       wopcm->guc.size));
+		GEM_BUG_ON(gen9_size_for_huc_restriction(wopcm->guc.size,
+							 huc_fw_size));
+	}
 }
 
 static bool wopcm_check_components_fit(struct intel_wopcm *wopcm)
@@ -218,21 +229,16 @@ static bool wopcm_check_components_fit(struct intel_wopcm *wopcm)
 	return 0;
 }
 
-static int wopcm_guc_init(struct intel_wopcm *wopcm)
+static int wopcm_guc_region_init(struct intel_wopcm *wopcm)
 {
 	struct drm_i915_private *dev_priv = wopcm_to_i915(wopcm);
-	u32 huc_fw_size = intel_uc_fw_get_upload_size(&dev_priv->huc.fw);
+	u32 guc_fw_size = intel_uc_fw_get_upload_size(&dev_priv->guc.fw);
 	u32 ctx_rsvd = context_reserved_size(dev_priv);
 
-	wopcm->guc.base = ALIGN_DOWN(huc_fw_size_in_wopcm(huc_fw_size),
-				     GUC_WOPCM_OFFSET_ALIGNMENT);
+	wopcm->guc.size = guc_fw_size_in_wopcm(guc_fw_size);
 
-	wopcm->guc.size = ALIGN(wopcm->size - wopcm->guc.base - ctx_rsvd,
-				PAGE_SIZE);
-
-	DRM_DEBUG_DRIVER("GuC WOPCM Region: [%uKiB, %uKiB)\n",
-			 wopcm->guc.base / 1024,
-			 (wopcm->guc.base + wopcm->guc.size) / 1024);
+	wopcm->guc.base = ALIGN_DOWN(wopcm->size - ctx_rsvd - wopcm->guc.size,
+				     GUC_WOPCM_OFFSET_ALIGNMENT);
 
 	return 0;
 }
@@ -255,18 +261,20 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
 
 	GEM_BUG_ON(!wopcm->size);
 
-	err = wopcm_guc_init(wopcm);
+	err = wopcm_guc_region_init(wopcm);
 	if (err)
 		return err;
 
-	err = wopcm_check_hw_restrictions(wopcm);
-	if (err)
-		return err;
+	wopcm_adjust_for_hw_restrictions(wopcm);
 
 	err = wopcm_check_components_fit(wopcm);
 	if (err)
 		return err;
 
+	DRM_DEBUG_DRIVER("GuC WOPCM Region: [%uKiB, %uKiB)\n",
+			 wopcm->guc.base / 1024,
+			 (wopcm->guc.base + wopcm->guc.size) / 1024);
+
 	return 0;
 }
 
-- 
2.14.3

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

  parent reply	other threads:[~2018-03-23 12:35 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-23 12:34 [PATCH 1/8] drm/i915/guc: Use _FW variants for mmio access in GuC irq handler Michał Winiarski
2018-03-23 12:34 ` [PATCH 2/8] drm/i915/guc: Move FW size sanity check back to fetch Michał Winiarski
2018-03-23 12:34 ` [PATCH 3/8] drm/i915/guc: Extend the GEN9 WOPCM HW restrictions to early CNL Michał Winiarski
2018-03-23 18:41   ` Daniele Ceraolo Spurio
2018-03-23 12:34 ` [PATCH 4/8] drm/i915/guc: Separate WOPCM partitioning from constraints check Michał Winiarski
2018-03-23 19:30   ` Yaodong Li
2018-03-23 12:34 ` Michał Winiarski [this message]
2018-03-23 20:00   ` [PATCH 5/8] drm/i915/guc: Use GuC FW size and HW restrictions to determine WOPCM partition Yaodong Li
2018-03-26 10:04     ` Michał Winiarski
2018-04-03  1:00       ` Yaodong Li
2018-03-23 12:34 ` [PATCH 6/8] drm/i915/guc: Don't give up on WOPCM partitioning regs mismatch Michał Winiarski
2018-03-23 12:34 ` [PATCH 7/8] drm/i915/guc: Don't touch WOPCM if we're not using GuC Michał Winiarski
2018-03-23 22:08   ` Yaodong Li
2018-03-23 12:34 ` [PATCH 8/8] HAX enable guc for CI Michał Winiarski
2018-03-23 16:03 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/8] drm/i915/guc: Use _FW variants for mmio access in GuC irq handler Patchwork
2018-03-23 16:04 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-03-23 16:18 ` ✗ Fi.CI.BAT: failure " Patchwork
2018-03-23 17:17 ` [PATCH 1/8] " Daniele Ceraolo Spurio
2018-03-28 13:51   ` Joonas Lahtinen
2018-03-28 16:56     ` Michał Winiarski
2018-03-28 12:50 ` Joonas Lahtinen

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=20180323123411.3214-5-michal.winiarski@intel.com \
    --to=michal.winiarski@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.