All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v4 1/5] drm/i915/guc: Move GuC WOPCM related code into separate files
@ 2017-12-12 22:56 Jackie Li
  2017-12-12 22:56 ` [PATCH v4 2/5] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset Jackie Li
                   ` (5 more replies)
  0 siblings, 6 replies; 16+ messages in thread
From: Jackie Li @ 2017-12-12 22:56 UTC (permalink / raw)
  To: intel-gfx

intel_guc_reg.h should only include definition for GuC registers
and related register bits. GuC WOPCM related values should not
be defined in intel_guc_reg.h

This patch creates a better file structure by moving GuC WOPCM
related definitions int to a new header intel_guc_wopcm.h
and moving GuC WOPCM related functions to a new source file
intel_guc_wopcm.c

Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jackie Li <yaodong.li@intel.com>
---
 drivers/gpu/drm/i915/Makefile          |  1 +
 drivers/gpu/drm/i915/intel_guc.c       | 11 --------
 drivers/gpu/drm/i915/intel_guc.h       |  2 +-
 drivers/gpu/drm/i915/intel_guc_reg.h   |  3 ---
 drivers/gpu/drm/i915/intel_guc_wopcm.c | 47 ++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_guc_wopcm.h | 38 +++++++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_uc.c        |  2 +-
 drivers/gpu/drm/i915/intel_uc_fw.c     |  2 +-
 8 files changed, 89 insertions(+), 17 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_guc_wopcm.c
 create mode 100644 drivers/gpu/drm/i915/intel_guc_wopcm.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 091aef2..1588b2e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -87,6 +87,7 @@ i915-y += intel_uc.o \
 	  intel_guc_fw.o \
 	  intel_guc_log.o \
 	  intel_guc_submission.o \
+	  intel_guc_wopcm.o \
 	  intel_huc.o
 
 # autogenerated null render state
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 177ee69..76519a7 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -370,14 +370,3 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size)
 	i915_gem_object_put(obj);
 	return vma;
 }
-
-u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv)
-{
-	u32 wopcm_size = GUC_WOPCM_TOP;
-
-	/* On BXT, the top of WOPCM is reserved for RC6 context */
-	if (IS_GEN9_LP(dev_priv))
-		wopcm_size -= BXT_GUC_WOPCM_RC6_RESERVED;
-
-	return wopcm_size;
-}
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 5985672..bfdc887 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -31,6 +31,7 @@
 #include "intel_guc_ct.h"
 #include "intel_guc_log.h"
 #include "intel_guc_reg.h"
+#include "intel_guc_wopcm.h"
 #include "intel_uc_fw.h"
 #include "i915_vma.h"
 
@@ -126,6 +127,5 @@ int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
 int intel_guc_suspend(struct drm_i915_private *dev_priv);
 int intel_guc_resume(struct drm_i915_private *dev_priv);
 struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size);
-u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv);
 
 #endif
diff --git a/drivers/gpu/drm/i915/intel_guc_reg.h b/drivers/gpu/drm/i915/intel_guc_reg.h
index 19a9247..144cd74 100644
--- a/drivers/gpu/drm/i915/intel_guc_reg.h
+++ b/drivers/gpu/drm/i915/intel_guc_reg.h
@@ -76,9 +76,6 @@
 
 /* Defines WOPCM space available to GuC firmware */
 #define GUC_WOPCM_SIZE			_MMIO(0xc050)
-/* GuC addresses below GUC_WOPCM_TOP don't map through the GTT */
-#define   GUC_WOPCM_TOP			  (0x80 << 12)	/* 512KB */
-#define   BXT_GUC_WOPCM_RC6_RESERVED	  (0x10 << 12)	/* 64KB  */
 
 /* GuC addresses above GUC_GGTT_TOP also don't map through the GTT */
 #define GUC_GGTT_TOP			0xFEE00000
diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c b/drivers/gpu/drm/i915/intel_guc_wopcm.c
new file mode 100644
index 0000000..87643a0
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c
@@ -0,0 +1,47 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "intel_guc_wopcm.h"
+#include "i915_drv.h"
+
+/*
+ * intel_guc_wopcm_size() - Get the size of GuC WOPCM.
+ * @guc: intel guc.
+ *
+ * Get the platform specific GuC WOPCM size.
+ *
+ * Return: size of the GuC WOPCM.
+ */
+u32 intel_guc_wopcm_size(struct intel_guc *guc)
+{
+	struct drm_i915_private *i915 = guc_to_i915(guc);
+
+	u32 wopcm_size = GUC_WOPCM_TOP;
+
+	/* On BXT, the top of WOPCM is reserved for RC6 context */
+	if (IS_GEN9_LP(i915))
+		wopcm_size -= BXT_GUC_WOPCM_RC6_RESERVED;
+
+	return wopcm_size;
+}
diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.h b/drivers/gpu/drm/i915/intel_guc_wopcm.h
new file mode 100644
index 0000000..04d61c8
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.h
@@ -0,0 +1,38 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#ifndef _INTEL_GUC_WOPCM_H_
+#define _INTEL_GUC_WOPCM_H_
+
+#include <linux/types.h>
+
+struct intel_guc;
+
+/* GuC addresses below GUC_WOPCM_TOP don't map through the GTT */
+#define GUC_WOPCM_TOP			  (0x80 << 12)	/* 512KB */
+#define BXT_GUC_WOPCM_RC6_RESERVED	  (0x10 << 12)	/* 64KB  */
+
+u32 intel_guc_wopcm_size(struct intel_guc *guc);
+
+#endif
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 461047c..44deb80 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -218,7 +218,7 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 	}
 
 	/* init WOPCM */
-	I915_WRITE(GUC_WOPCM_SIZE, intel_guc_wopcm_size(dev_priv));
+	I915_WRITE(GUC_WOPCM_SIZE, intel_guc_wopcm_size(guc));
 	I915_WRITE(DMA_GUC_WOPCM_OFFSET,
 		   GUC_WOPCM_OFFSET_VALUE | HUC_LOADING_AGENT_GUC);
 
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.c b/drivers/gpu/drm/i915/intel_uc_fw.c
index 784eff9..24945cf 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/intel_uc_fw.c
@@ -97,7 +97,7 @@ void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
 
 	/* Header and uCode will be loaded to WOPCM */
 	size = uc_fw->header_size + uc_fw->ucode_size;
-	if (size > intel_guc_wopcm_size(dev_priv)) {
+	if (size > intel_guc_wopcm_size(&dev_priv->guc)) {
 		DRM_WARN("%s: Firmware is too large to fit in WOPCM\n",
 			 intel_uc_fw_type_repr(uc_fw->type));
 		err = -E2BIG;
-- 
2.7.4

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

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [PATCH v4 2/5] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset
  2017-12-12 22:56 [PATCH v4 1/5] drm/i915/guc: Move GuC WOPCM related code into separate files Jackie Li
@ 2017-12-12 22:56 ` Jackie Li
  2017-12-12 22:56 ` [PATCH v4 3/5] drm/i915/guc: Implement dynamic WOPCM partitioning Jackie Li
                   ` (4 subsequent siblings)
  5 siblings, 0 replies; 16+ messages in thread
From: Jackie Li @ 2017-12-12 22:56 UTC (permalink / raw)
  To: intel-gfx

GuC related exported functions should start with "intel_guc_"
prefix and pass intel_guc as the first parameter since its guc
related. Current guc_ggtt_offset() failed to follow this code
convention.

This patch renames the guc_ggtt_offset to intel_guc_ggtt_offset
and updates the related code to pass intel_guc pointer to
this function call. so that we have a unified coding style for
GuC code.

Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jackie Li <yaodong.li@intel.com>
---
 drivers/gpu/drm/i915/intel_guc.c            | 12 +++++++-----
 drivers/gpu/drm/i915/intel_guc.h            | 10 ++++++++--
 drivers/gpu/drm/i915/intel_guc_ct.c         |  5 +++--
 drivers/gpu/drm/i915/intel_guc_fw.c         |  2 +-
 drivers/gpu/drm/i915/intel_guc_log.c        |  2 +-
 drivers/gpu/drm/i915/intel_guc_submission.c | 20 ++++++++++----------
 drivers/gpu/drm/i915/intel_huc.c            |  6 ++++--
 7 files changed, 34 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 76519a7..41aee96 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -130,8 +130,10 @@ void intel_guc_init_params(struct intel_guc *guc)
 
 	/* If GuC submission is enabled, set up additional parameters here */
 	if (USES_GUC_SUBMISSION(dev_priv)) {
-		u32 ads = guc_ggtt_offset(guc->ads_vma) >> PAGE_SHIFT;
-		u32 pgs = guc_ggtt_offset(dev_priv->guc.stage_desc_pool);
+		u32 ads = intel_guc_ggtt_offset(guc,
+						guc->ads_vma) >> PAGE_SHIFT;
+		u32 pgs = intel_guc_ggtt_offset(guc,
+						dev_priv->guc.stage_desc_pool);
 		u32 ctx_in_16 = GUC_MAX_STAGE_DESCRIPTORS / 16;
 
 		params[GUC_CTL_DEBUG] |= ads << GUC_ADS_ADDR_SHIFT;
@@ -279,7 +281,7 @@ int intel_guc_suspend(struct drm_i915_private *dev_priv)
 	data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
 	/* any value greater than GUC_POWER_D0 */
 	data[1] = GUC_POWER_D1;
-	data[2] = guc_ggtt_offset(guc->shared_data);
+	data[2] = intel_guc_ggtt_offset(guc, guc->shared_data);
 
 	return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
@@ -302,7 +304,7 @@ int intel_guc_reset_engine(struct intel_guc *guc,
 	data[3] = 0;
 	data[4] = 0;
 	data[5] = guc->execbuf_client->stage_id;
-	data[6] = guc_ggtt_offset(guc->shared_data);
+	data[6] = intel_guc_ggtt_offset(guc, guc->shared_data);
 
 	return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
@@ -324,7 +326,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
 
 	data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
 	data[1] = GUC_POWER_D0;
-	data[2] = guc_ggtt_offset(guc->shared_data);
+	data[2] = intel_guc_ggtt_offset(guc, guc->shared_data);
 
 	return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index bfdc887..399612d 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -101,13 +101,19 @@ static inline void intel_guc_notify(struct intel_guc *guc)
 	guc->notify(guc);
 }
 
-/*
+/* intel_guc_ggtt_offset() - Get the GGTT offset of @vma.
+ * @guc: intel guc.
+ * @vma: i915 graphics virtual memory area.
+ *
  * GuC does not allow any gfx GGTT address that falls into range [0, WOPCM_TOP),
  * which is reserved for Boot ROM, SRAM and WOPCM. Currently this top address is
  * 512K. In order to exclude 0-512K address space from GGTT, all gfx objects
  * used by GuC is pinned with PIN_OFFSET_BIAS along with size of WOPCM.
+ *
+ * Return: GGTT offset that meets the GuC gfx address requirement.
  */
-static inline u32 guc_ggtt_offset(struct i915_vma *vma)
+static inline u32 intel_guc_ggtt_offset(struct intel_guc *guc,
+					struct i915_vma *vma)
 {
 	u32 offset = i915_ggtt_offset(vma);
 
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c b/drivers/gpu/drm/i915/intel_guc_ct.c
index 24ad557..0a0d3d5 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -156,7 +156,8 @@ static int ctch_init(struct intel_guc *guc,
 		err = PTR_ERR(blob);
 		goto err_vma;
 	}
-	DRM_DEBUG_DRIVER("CT: vma base=%#x\n", guc_ggtt_offset(ctch->vma));
+	DRM_DEBUG_DRIVER("CT: vma base=%#x\n",
+			 intel_guc_ggtt_offset(guc, ctch->vma));
 
 	/* store pointers to desc and cmds */
 	for (i = 0; i < ARRAY_SIZE(ctch->ctbs); i++) {
@@ -202,7 +203,7 @@ static int ctch_open(struct intel_guc *guc,
 	}
 
 	/* vma should be already allocated and map'ed */
-	base = guc_ggtt_offset(ctch->vma);
+	base = intel_guc_ggtt_offset(guc, ctch->vma);
 
 	/* (re)initialize descriptors
 	 * cmds buffers are in the second half of the blob page
diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c b/drivers/gpu/drm/i915/intel_guc_fw.c
index cbc51c9..2369ff7 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -174,7 +174,7 @@ static int guc_xfer_ucode(struct intel_guc *guc, struct i915_vma *vma)
 	I915_WRITE(DMA_COPY_SIZE, guc_fw->header_size + guc_fw->ucode_size);
 
 	/* Set the source address for the new blob */
-	offset = guc_ggtt_offset(vma) + guc_fw->header_offset;
+	offset = intel_guc_ggtt_offset(guc, vma) + guc_fw->header_offset;
 	I915_WRITE(DMA_ADDR_0_LOW, lower_32_bits(offset));
 	I915_WRITE(DMA_ADDR_0_HIGH, upper_32_bits(offset) & 0xFFFF);
 
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c b/drivers/gpu/drm/i915/intel_guc_log.c
index 1a2c5ee..41c2529 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -572,7 +572,7 @@ int intel_guc_log_create(struct intel_guc *guc)
 		(GUC_LOG_ISR_PAGES << GUC_LOG_ISR_SHIFT) |
 		(GUC_LOG_CRASH_PAGES << GUC_LOG_CRASH_SHIFT);
 
-	offset = guc_ggtt_offset(vma) >> PAGE_SHIFT; /* in pages */
+	offset = intel_guc_ggtt_offset(guc, vma) >> PAGE_SHIFT; /* in pages */
 	guc->log.flags = (offset << GUC_LOG_BUF_ADDR_SHIFT) | flags;
 
 	return 0;
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c b/drivers/gpu/drm/i915/intel_guc_submission.c
index 912ff14..8bdbe48 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -401,8 +401,8 @@ static void guc_stage_desc_init(struct intel_guc *guc,
 		lrc->context_desc = lower_32_bits(ce->lrc_desc);
 
 		/* The state page is after PPHWSP */
-		lrc->ring_lrca =
-			guc_ggtt_offset(ce->state) + LRC_STATE_PN * PAGE_SIZE;
+		lrc->ring_lrca = intel_guc_ggtt_offset(guc, ce->state) +
+				 LRC_STATE_PN * PAGE_SIZE;
 
 		/* XXX: In direct submission, the GuC wants the HW context id
 		 * here. In proxy submission, it wants the stage id
@@ -410,7 +410,7 @@ static void guc_stage_desc_init(struct intel_guc *guc,
 		lrc->context_id = (client->stage_id << GUC_ELC_CTXID_OFFSET) |
 				(guc_engine_id << GUC_ELC_ENGINE_OFFSET);
 
-		lrc->ring_begin = guc_ggtt_offset(ce->ring->vma);
+		lrc->ring_begin = intel_guc_ggtt_offset(guc, ce->ring->vma);
 		lrc->ring_end = lrc->ring_begin + ce->ring->size - 1;
 		lrc->ring_next_free_location = lrc->ring_begin;
 		lrc->ring_current_tail_pointer_value = 0;
@@ -426,7 +426,7 @@ static void guc_stage_desc_init(struct intel_guc *guc,
 	 * The doorbell, process descriptor, and workqueue are all parts
 	 * of the client object, which the GuC will reference via the GGTT
 	 */
-	gfx_addr = guc_ggtt_offset(client->vma);
+	gfx_addr = intel_guc_ggtt_offset(guc, client->vma);
 	desc->db_trigger_phy = sg_dma_address(client->vma->pages->sgl) +
 				client->doorbell_offset;
 	desc->db_trigger_cpu = ptr_to_u64(__get_doorbell(client));
@@ -649,7 +649,7 @@ static void inject_preempt_context(struct work_struct *work)
 	data[3] = engine->guc_id;
 	data[4] = guc->execbuf_client->priority;
 	data[5] = guc->execbuf_client->stage_id;
-	data[6] = guc_ggtt_offset(guc->shared_data);
+	data[6] = intel_guc_ggtt_offset(guc, guc->shared_data);
 
 	if (WARN_ON(intel_guc_send(guc, data, ARRAY_SIZE(data)))) {
 		execlists_clear_active(&engine->execlists,
@@ -1139,7 +1139,7 @@ static void guc_policies_init(struct guc_policies *policies)
 static int guc_ads_create(struct intel_guc *guc)
 {
 	struct drm_i915_private *dev_priv = guc_to_i915(guc);
-	struct i915_vma *vma;
+	struct i915_vma *vma, *rcs_state;
 	struct page *page;
 	/* The ads obj includes the struct itself and buffers passed to GuC */
 	struct {
@@ -1185,9 +1185,9 @@ static int guc_ads_create(struct intel_guc *guc)
 	 * to find it. Note that we have to skip our header (1 page),
 	 * because our GuC shared data is there.
 	 */
-	blob->ads.golden_context_lrca =
-		guc_ggtt_offset(dev_priv->kernel_context->engine[RCS].state) +
-		skipped_offset;
+	rcs_state = dev_priv->kernel_context->engine[RCS].state;
+	blob->ads.golden_context_lrca = intel_guc_ggtt_offset(guc, rcs_state) +
+					skipped_offset;
 
 	/*
 	 * The GuC expects us to exclude the portion of the context image that
@@ -1199,7 +1199,7 @@ static int guc_ads_create(struct intel_guc *guc)
 		blob->ads.eng_state_size[engine->guc_id] =
 			engine->context_size - skipped_size;
 
-	base = guc_ggtt_offset(vma);
+	base = intel_guc_ggtt_offset(guc, vma);
 	blob->ads.scheduler_policies = base + ptr_offset(blob, policies);
 	blob->ads.reg_state_buffer = base + ptr_offset(blob, reg_state_buffer);
 	blob->ads.reg_state_addr = base + ptr_offset(blob, reg_state);
diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index 974be3d..6482174 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -148,7 +148,8 @@ static int huc_ucode_xfer(struct intel_uc_fw *huc_fw, struct i915_vma *vma)
 	intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
 
 	/* Set the source address for the uCode */
-	offset = guc_ggtt_offset(vma) + huc_fw->header_offset;
+	offset = intel_guc_ggtt_offset(&dev_priv->guc, vma) +
+		 huc_fw->header_offset;
 	I915_WRITE(DMA_ADDR_0_LOW, lower_32_bits(offset));
 	I915_WRITE(DMA_ADDR_0_HIGH, upper_32_bits(offset) & 0xFFFF);
 
@@ -224,7 +225,8 @@ int intel_huc_auth(struct intel_huc *huc)
 	}
 
 	ret = intel_guc_auth_huc(guc,
-				 guc_ggtt_offset(vma) + huc->fw.rsa_offset);
+				 intel_guc_ggtt_offset(guc, vma) +
+				 huc->fw.rsa_offset);
 	if (ret) {
 		DRM_ERROR("HuC: GuC did not ack Auth request %d\n", ret);
 		goto out;
-- 
2.7.4

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

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [PATCH v4 3/5] drm/i915/guc: Implement dynamic WOPCM partitioning
  2017-12-12 22:56 [PATCH v4 1/5] drm/i915/guc: Move GuC WOPCM related code into separate files Jackie Li
  2017-12-12 22:56 ` [PATCH v4 2/5] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset Jackie Li
@ 2017-12-12 22:56 ` Jackie Li
  2017-12-13  9:11   ` Joonas Lahtinen
  2017-12-12 22:56 ` [PATCH v4 4/5] drm/i915/guc: Add WOPCM partitioning support for CNL Jackie Li
                   ` (3 subsequent siblings)
  5 siblings, 1 reply; 16+ messages in thread
From: Jackie Li @ 2017-12-12 22:56 UTC (permalink / raw)
  To: intel-gfx; +Cc: Sujaritha Sundaresan

Hardware may have specific restrictions on GuC WOPCM partition
size versus HuC firmware size. With static WOPCM partitioning,
there's no way to adjust the GuC WOPCM partition size based on
the actual HuC firmware size, so that GuC/HuC loading failure
would occur even if there was enough WOPCM space for both
GuC and HuC firmware.

This patch enables the dynamic calculation of the WOPCM aperture
sizes used by GuC and HuC firmware. GuC WOPCM offset is set to
HuC size + reserved WOPCM size. GuC WOPCM size is set to
total WOPCM size - GuC WOPCM offset - RC6CTX size. In this case,
GuC WOPCM offset will be updated based on the size of HuC firmware
while GuC WOPCM size will be set to use all the remaining WOPCM space.

v2:
 - Removed intel_wopcm_init (Ville/Sagar/Joonas)
 - Renamed and Moved the intel_wopcm_partition into intel_guc (Sagar)
 - Removed unnecessary function calls (Joonas)
 - Init GuC WOPCM partition as soon as firmware fetching is completed

v3:
 - Fixed indentation issues (Chris)
 - Removed layering violation code (Chris/Michal)
 - Created separat files for GuC wopcm code  (Michal)
 - Used inline function to avoid code duplication (Michal)

v4:
 - Preset the GuC WOPCM top during early GuC init (Chris)
 - Fail intel_uc_init_hw() as soon as GuC WOPCM partitioning failed

Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: John Spotswood <john.a.spotswood@intel.com>
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jackie Li <yaodong.li@intel.com>
---
 drivers/gpu/drm/i915/i915_gem_context.c |   9 +--
 drivers/gpu/drm/i915/intel_guc.c        |   5 +-
 drivers/gpu/drm/i915/intel_guc.h        |  12 ++--
 drivers/gpu/drm/i915/intel_guc_wopcm.c  | 105 +++++++++++++++++++++++++++++---
 drivers/gpu/drm/i915/intel_guc_wopcm.h  |  39 ++++++++++--
 drivers/gpu/drm/i915/intel_huc.c        |   2 +-
 drivers/gpu/drm/i915/intel_uc.c         |  10 ++-
 drivers/gpu/drm/i915/intel_uc_fw.c      |  11 +++-
 drivers/gpu/drm/i915/intel_uc_fw.h      |  16 +++++
 9 files changed, 178 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c
index 21ce374..016acec 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -312,12 +312,13 @@ __create_hw_context(struct drm_i915_private *dev_priv,
 	ctx->desc_template =
 		default_desc_template(dev_priv, dev_priv->mm.aliasing_ppgtt);
 
-	/* GuC requires the ring to be placed above GUC_WOPCM_TOP. If GuC is not
-	 * present or not in use we still need a small bias as ring wraparound
-	 * at offset 0 sometimes hangs. No idea why.
+	/*
+	 * GuC requires the ring to be placed above GuC WOPCM top. If GuC is not
+-	 * present or not in use we still need a small bias as ring wraparound
+-	 * at offset 0 sometimes hangs. No idea why.
 	 */
 	if (USES_GUC(dev_priv))
-		ctx->ggtt_offset_bias = GUC_WOPCM_TOP;
+		ctx->ggtt_offset_bias = dev_priv->guc.wopcm.top;
 	else
 		ctx->ggtt_offset_bias = I915_GTT_PAGE_SIZE;
 
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 41aee96..585a644 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -63,6 +63,7 @@ void intel_guc_init_early(struct intel_guc *guc)
 {
 	intel_guc_fw_init_early(guc);
 	intel_guc_ct_init_early(&guc->ct);
+	intel_guc_wopcm_init_early(&guc->wopcm);
 
 	mutex_init(&guc->send_mutex);
 	guc->send = intel_guc_send_nop;
@@ -339,7 +340,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
  * This is a wrapper to create an object for use with the GuC. In order to
  * use it inside the GuC, an object needs to be pinned lifetime, so we allocate
  * both some backing storage and a range inside the Global GTT. We must pin
- * it in the GGTT somewhere other than than [0, GUC_WOPCM_TOP) because that
+ * it in the GGTT somewhere other than than [0, GuC WOPCM top) because that
  * range is reserved inside GuC.
  *
  * Return:	A i915_vma if successful, otherwise an ERR_PTR.
@@ -360,7 +361,7 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size)
 		goto err;
 
 	ret = i915_vma_pin(vma, 0, PAGE_SIZE,
-			   PIN_GLOBAL | PIN_OFFSET_BIAS | GUC_WOPCM_TOP);
+			   PIN_GLOBAL | PIN_OFFSET_BIAS | guc->wopcm.top);
 	if (ret) {
 		vma = ERR_PTR(ret);
 		goto err;
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 399612d..b8248ba 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -49,6 +49,7 @@ struct intel_guc {
 	struct intel_uc_fw fw;
 	struct intel_guc_log log;
 	struct intel_guc_ct ct;
+	struct intel_guc_wopcm wopcm;
 
 	/* Log snapshot if GuC errors during load */
 	struct drm_i915_gem_object *load_err_log;
@@ -105,10 +106,10 @@ static inline void intel_guc_notify(struct intel_guc *guc)
  * @guc: intel guc.
  * @vma: i915 graphics virtual memory area.
  *
- * GuC does not allow any gfx GGTT address that falls into range [0, WOPCM_TOP),
- * which is reserved for Boot ROM, SRAM and WOPCM. Currently this top address is
- * 512K. In order to exclude 0-512K address space from GGTT, all gfx objects
- * used by GuC is pinned with PIN_OFFSET_BIAS along with size of WOPCM.
+ * GuC does not allow any gfx GGTT address that falls into range
+ * [0, GuC WOPCM top), which is reserved for Boot ROM, SRAM and WOPCM.
+ * All gfx objects used by GuC is pinned with PIN_OFFSET_BIAS along with
+ * top of WOPCM.
  *
  * Return: GGTT offset that meets the GuC gfx address requirement.
  */
@@ -117,7 +118,8 @@ static inline u32 intel_guc_ggtt_offset(struct intel_guc *guc,
 {
 	u32 offset = i915_ggtt_offset(vma);
 
-	GEM_BUG_ON(offset < GUC_WOPCM_TOP);
+	GEM_BUG_ON(!guc->wopcm.valid);
+	GEM_BUG_ON(offset < guc->wopcm.top);
 	GEM_BUG_ON(range_overflows_t(u64, offset, vma->size, GUC_GGTT_TOP));
 
 	return offset;
diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c b/drivers/gpu/drm/i915/intel_guc_wopcm.c
index 87643a0..60a6afe 100644
--- a/drivers/gpu/drm/i915/intel_guc_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c
@@ -25,23 +25,108 @@
 #include "intel_guc_wopcm.h"
 #include "i915_drv.h"
 
+static inline u32 guc_reserved_wopcm_size(struct intel_guc *guc)
+{
+	struct drm_i915_private *i915 = guc_to_i915(guc);
+
+	/* On BXT, the top of WOPCM is reserved for RC6 context */
+	if (IS_GEN9_LP(i915))
+		return BXT_WOPCM_RC6_RESERVED;
+
+	return 0;
+}
+
+static inline int gen9_wocpm_size_check(struct drm_i915_private *i915)
+{
+	struct intel_guc_wopcm *wopcm = &i915->guc.wopcm;
+	u32 wopcm_base;
+	u32 delta;
+
+	/*
+	 * Check hardware restriction on Gen9
+	 * GuC WOPCM size is at least 4 bytes larger than GuC WOPCM base due
+	 * to hardware limitation on Gen9.
+	 */
+	wopcm_base = wopcm->offset + GEN9_GUC_WOPCM_OFFSET;
+	if (unlikely(wopcm_base > wopcm->size))
+		return -E2BIG;
+
+	delta = wopcm->size - wopcm_base;
+	if (unlikely(delta < GEN9_GUC_WOPCM_DELTA))
+		return -E2BIG;
+
+	return 0;
+}
+
+static inline int guc_wopcm_size_check(struct intel_guc *guc)
+{
+	struct drm_i915_private *i915 = guc_to_i915(guc);
+
+	if (IS_GEN9(i915))
+		return gen9_wocpm_size_check(i915);
+
+	return 0;
+}
+
 /*
- * intel_guc_wopcm_size() - Get the size of GuC WOPCM.
+ * intel_guc_wopcm_init() - Initialize the GuC WOPCM partition.
  * @guc: intel guc.
+ * @guc_fw_size: size of GuC firmware.
+ * @huc_fw_size: size of HuC firmware.
  *
- * Get the platform specific GuC WOPCM size.
+ * This function tries to initialize the WOPCM partition based on HuC firmware
+ * size and the reserved WOPCM memory size.
  *
- * Return: size of the GuC WOPCM.
+ * Return: 0 on success, non-zero error code on failure.
  */
-u32 intel_guc_wopcm_size(struct intel_guc *guc)
+int intel_guc_init_wopcm(struct intel_guc *guc, u32 guc_fw_size,
+			 u32 huc_fw_size)
 {
-	struct drm_i915_private *i915 = guc_to_i915(guc);
+	u32 reserved = guc_reserved_wopcm_size(guc);
+	u32 offset, size, top;
+	int err;
 
-	u32 wopcm_size = GUC_WOPCM_TOP;
+	if (guc->wopcm.valid)
+		return 0;
 
-	/* On BXT, the top of WOPCM is reserved for RC6 context */
-	if (IS_GEN9_LP(i915))
-		wopcm_size -= BXT_GUC_WOPCM_RC6_RESERVED;
+	if (!guc_fw_size)
+		return -EINVAL;
+
+	if (reserved >= WOPCM_DEFAULT_SIZE)
+		return -E2BIG;
+
+	offset = huc_fw_size + WOPCM_RESERVED_SIZE;
+	if (offset >= WOPCM_DEFAULT_SIZE)
+		return -E2BIG;
+
+	/* Hardware requires GuC WOPCM offset needs to be 16K aligned. */
+	offset = ALIGN(offset, WOPCM_OFFSET_ALIGNMENT);
+	if ((offset + reserved) >= WOPCM_DEFAULT_SIZE)
+		return -E2BIG;
+
+	top = WOPCM_DEFAULT_SIZE - offset;
+	size = top - reserved;
+
+	/*
+	 * GuC size needs to be less than or equal to GuC WOPCM size.
+	 * Need extra 8K stack for GuC.
+	 */
+	if ((guc_fw_size + GUC_WOPCM_STACK_RESERVED) > size)
+		return -E2BIG;
+
+	guc->wopcm.offset = offset;
+	guc->wopcm.size = size;
+	guc->wopcm.top = top;
+
+	/* Check platform specific restrictions */
+	err = guc_wopcm_size_check(guc);
+	if (err)
+		return err;
+
+	guc->wopcm.valid = true;
+
+	DRM_DEBUG_DRIVER("GuC WOPCM offset %dKB, size %dKB, top %dKB\n",
+			 offset >> 10, size >> 10, top >> 10);
 
-	return wopcm_size;
+	return 0;
 }
diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.h b/drivers/gpu/drm/i915/intel_guc_wopcm.h
index 04d61c8..2f9d03a 100644
--- a/drivers/gpu/drm/i915/intel_guc_wopcm.h
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.h
@@ -29,10 +29,41 @@
 
 struct intel_guc;
 
-/* GuC addresses below GUC_WOPCM_TOP don't map through the GTT */
-#define GUC_WOPCM_TOP			  (0x80 << 12)	/* 512KB */
-#define BXT_GUC_WOPCM_RC6_RESERVED	  (0x10 << 12)	/* 64KB  */
+/* Default WOPCM size 1MB */
+#define WOPCM_DEFAULT_SIZE		(0x1 << 20)
+/* Reserved WOPCM size 16KB */
+#define WOPCM_RESERVED_SIZE		(0x4000)
+/* GUC WOPCM Offset need to be 16KB aligned */
+#define WOPCM_OFFSET_ALIGNMENT		(0x4000)
+/* 8KB stack reserved for GuC FW*/
+#define GUC_WOPCM_STACK_RESERVED	(0x2000)
+/* 24KB WOPCM reserved for RC6 CTX on BXT */
+#define BXT_WOPCM_RC6_RESERVED		(0x6000)
 
-u32 intel_guc_wopcm_size(struct intel_guc *guc);
+#define GEN9_GUC_WOPCM_DELTA		4
+#define GEN9_GUC_WOPCM_OFFSET		(0x24000)
+
+struct intel_guc_wopcm {
+	u32 offset;
+	u32 size;
+	u32 top;
+	bool valid;
+};
+
+/*
+ * intel_guc_wopcm_init_early() - Early initialization of the GuC WOPCM.
+ * @wopcm: GuC WOPCM.
+ *
+ * Setup the GuC WOPCM top to the top of the overall WOPCM. This will guarantee
+ * that the allocation of the GuC accessible objects won't fall into WOPCM when
+ * GuC partition isn't present.
+ *
+ */
+static inline void intel_guc_wopcm_init_early(struct intel_guc_wopcm *wopcm)
+{
+	wopcm->top = WOPCM_DEFAULT_SIZE;
+}
+
+int intel_guc_init_wopcm(struct intel_guc *guc, u32 guc_size, u32 huc_size);
 
 #endif
diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index 6482174..dda2955 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -217,7 +217,7 @@ int intel_huc_auth(struct intel_huc *huc)
 		return -ENOEXEC;
 
 	vma = i915_gem_object_ggtt_pin(huc->fw.obj, NULL, 0, 0,
-				PIN_OFFSET_BIAS | GUC_WOPCM_TOP);
+				PIN_OFFSET_BIAS | guc->wopcm.top);
 	if (IS_ERR(vma)) {
 		ret = PTR_ERR(vma);
 		DRM_ERROR("HuC: Failed to pin huc fw object %d\n", ret);
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 44deb80..d5c2a95 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -191,6 +191,8 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 {
 	struct intel_guc *guc = &dev_priv->guc;
 	struct intel_huc *huc = &dev_priv->huc;
+	u32 guc_fw_size = intel_uc_fw_get_size(&guc->fw);
+	u32 huc_fw_size = intel_uc_fw_get_size(&huc->fw);
 	int ret, attempts;
 
 	if (!USES_GUC(dev_priv))
@@ -201,6 +203,10 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 		goto err_out;
 	}
 
+	ret = intel_guc_init_wopcm(guc, guc_fw_size, huc_fw_size);
+	if (ret)
+		goto err_out;
+
 	guc_disable_communication(guc);
 	gen9_reset_guc_interrupts(dev_priv);
 
@@ -218,9 +224,9 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 	}
 
 	/* init WOPCM */
-	I915_WRITE(GUC_WOPCM_SIZE, intel_guc_wopcm_size(guc));
+	I915_WRITE(GUC_WOPCM_SIZE, guc->wopcm.size);
 	I915_WRITE(DMA_GUC_WOPCM_OFFSET,
-		   GUC_WOPCM_OFFSET_VALUE | HUC_LOADING_AGENT_GUC);
+		   guc->wopcm.offset | HUC_LOADING_AGENT_GUC);
 
 	/* WaEnableuKernelHeaderValidFix:skl */
 	/* WaEnableGuCBootHashCheckNotSet:skl,bxt,kbl */
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.c b/drivers/gpu/drm/i915/intel_uc_fw.c
index 24945cf..791263a 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/intel_uc_fw.c
@@ -95,9 +95,13 @@ void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
 	uc_fw->ucode_offset = uc_fw->header_offset + uc_fw->header_size;
 	uc_fw->ucode_size = (css->size_dw - css->header_size_dw) * sizeof(u32);
 
-	/* Header and uCode will be loaded to WOPCM */
+	/*
+	 * Header and uCode will be loaded to WOPCM
+	 * Only check the size against the overall available WOPCM here. Will
+	 * continue to check the size during WOPCM partition calculation.
+	 */
 	size = uc_fw->header_size + uc_fw->ucode_size;
-	if (size > intel_guc_wopcm_size(&dev_priv->guc)) {
+	if (size > WOPCM_DEFAULT_SIZE) {
 		DRM_WARN("%s: Firmware is too large to fit in WOPCM\n",
 			 intel_uc_fw_type_repr(uc_fw->type));
 		err = -E2BIG;
@@ -207,6 +211,7 @@ int intel_uc_fw_upload(struct intel_uc_fw *uc_fw,
 		       int (*xfer)(struct intel_uc_fw *uc_fw,
 				   struct i915_vma *vma))
 {
+	struct drm_i915_private *i915 = to_i915(uc_fw->obj->base.dev);
 	struct i915_vma *vma;
 	int err;
 
@@ -230,7 +235,7 @@ int intel_uc_fw_upload(struct intel_uc_fw *uc_fw,
 	}
 
 	vma = i915_gem_object_ggtt_pin(uc_fw->obj, NULL, 0, 0,
-				       PIN_OFFSET_BIAS | GUC_WOPCM_TOP);
+				       PIN_OFFSET_BIAS | i915->guc.wopcm.top);
 	if (IS_ERR(vma)) {
 		err = PTR_ERR(vma);
 		DRM_DEBUG_DRIVER("%s fw ggtt-pin err=%d\n",
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.h b/drivers/gpu/drm/i915/intel_uc_fw.h
index d5fd460..d00d888 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/intel_uc_fw.h
@@ -115,6 +115,22 @@ static inline bool intel_uc_fw_is_selected(struct intel_uc_fw *uc_fw)
 	return uc_fw->path != NULL;
 }
 
+/*
+ * intel_uc_fw_get_size() - Get the size of the firmware.
+ * @uc_fw: intel_uc_fw structure.
+ *
+ * Get the size of the firmware that will be placed in WOPCM.
+ *
+ * Return: Zero on invalid firmware status. actual size on success.
+ */
+static inline u32 intel_uc_fw_get_size(struct intel_uc_fw *uc_fw)
+{
+	if (uc_fw->fetch_status != INTEL_UC_FIRMWARE_SUCCESS)
+		return 0;
+
+	return uc_fw->header_size + uc_fw->ucode_size;
+}
+
 void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
 		       struct intel_uc_fw *uc_fw);
 int intel_uc_fw_upload(struct intel_uc_fw *uc_fw,
-- 
2.7.4

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

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [PATCH v4 4/5] drm/i915/guc: Add WOPCM partitioning support for CNL
  2017-12-12 22:56 [PATCH v4 1/5] drm/i915/guc: Move GuC WOPCM related code into separate files Jackie Li
  2017-12-12 22:56 ` [PATCH v4 2/5] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset Jackie Li
  2017-12-12 22:56 ` [PATCH v4 3/5] drm/i915/guc: Implement dynamic WOPCM partitioning Jackie Li
@ 2017-12-12 22:56 ` Jackie Li
  2017-12-12 22:56 ` [PATCH v4 5/5] HAX Enable GuC Submission for CI Jackie Li
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 16+ messages in thread
From: Jackie Li @ 2017-12-12 22:56 UTC (permalink / raw)
  To: intel-gfx

CNL has different WOPCM size and hardware restriction on GuC
WOPCM size.

This patch returns the correct WOPCM reserved size on CNL and
adds the GuC WOPCM size check for CNL.

Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: John Spotswood <john.a.spotswood@intel.com>
Cc: Jeff McGee <jeff.mcgee@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jackie Li <yaodong.li@intel.com>
---
 drivers/gpu/drm/i915/intel_guc_wopcm.c | 21 +++++++++++++++++++++
 drivers/gpu/drm/i915/intel_guc_wopcm.h |  3 +++
 2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c b/drivers/gpu/drm/i915/intel_guc_wopcm.c
index 60a6afe..e23d7a4 100644
--- a/drivers/gpu/drm/i915/intel_guc_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c
@@ -33,6 +33,9 @@ static inline u32 guc_reserved_wopcm_size(struct intel_guc *guc)
 	if (IS_GEN9_LP(i915))
 		return BXT_WOPCM_RC6_RESERVED;
 
+	if (IS_GEN10(i915))
+		return CNL_WOPCM_RESERVED;
+
 	return 0;
 }
 
@@ -58,6 +61,21 @@ static inline int gen9_wocpm_size_check(struct drm_i915_private *i915)
 	return 0;
 }
 
+static inline int cnl_a0_wopcm_size_check(struct drm_i915_private *i915)
+{
+	struct intel_guc_wopcm *wopcm = &i915->guc.wopcm;
+	u32 huc_size = intel_uc_fw_get_size(&i915->huc.fw);
+
+	/*
+	 * On CNL A0, hardware requires guc size to be larger than or equal to
+	 * HuC kernel size.
+	 */
+	if (unlikely(wopcm->size - GEN10_GUC_WOPCM_OFFSET < huc_size))
+		return -E2BIG;
+
+	return 0;
+}
+
 static inline int guc_wopcm_size_check(struct intel_guc *guc)
 {
 	struct drm_i915_private *i915 = guc_to_i915(guc);
@@ -65,6 +83,9 @@ static inline int guc_wopcm_size_check(struct intel_guc *guc)
 	if (IS_GEN9(i915))
 		return gen9_wocpm_size_check(i915);
 
+	if (IS_CNL_REVID(i915, CNL_REVID_A0, CNL_REVID_A0))
+		return cnl_a0_wopcm_size_check(i915);
+
 	return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.h b/drivers/gpu/drm/i915/intel_guc_wopcm.h
index 2f9d03a..5bb5092 100644
--- a/drivers/gpu/drm/i915/intel_guc_wopcm.h
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.h
@@ -39,9 +39,12 @@ struct intel_guc;
 #define GUC_WOPCM_STACK_RESERVED	(0x2000)
 /* 24KB WOPCM reserved for RC6 CTX on BXT */
 #define BXT_WOPCM_RC6_RESERVED		(0x6000)
+/* 36KB WOPCM reserved on CNL */
+#define CNL_WOPCM_RESERVED		(0x9000)
 
 #define GEN9_GUC_WOPCM_DELTA		4
 #define GEN9_GUC_WOPCM_OFFSET		(0x24000)
+#define GEN10_GUC_WOPCM_OFFSET		(0x4000)
 
 struct intel_guc_wopcm {
 	u32 offset;
-- 
2.7.4

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

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [PATCH v4 5/5] HAX Enable GuC Submission for CI
  2017-12-12 22:56 [PATCH v4 1/5] drm/i915/guc: Move GuC WOPCM related code into separate files Jackie Li
                   ` (2 preceding siblings ...)
  2017-12-12 22:56 ` [PATCH v4 4/5] drm/i915/guc: Add WOPCM partitioning support for CNL Jackie Li
@ 2017-12-12 22:56 ` Jackie Li
  2017-12-12 23:18 ` ✗ Fi.CI.BAT: failure for series starting with [v4,1/5] drm/i915/guc: Move GuC WOPCM related code into separate files Patchwork
  2017-12-13  8:19 ` [PATCH v4 1/5] " Joonas Lahtinen
  5 siblings, 0 replies; 16+ messages in thread
From: Jackie Li @ 2017-12-12 22:56 UTC (permalink / raw)
  To: intel-gfx

Signed-off-by: Jackie Li <yaodong.li@intel.com>
---
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h
index 792ce26..9725c5a 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -45,7 +45,7 @@
 	param(int, disable_power_well, -1) \
 	param(int, enable_ips, 1) \
 	param(int, invert_brightness, 0) \
-	param(int, enable_guc, 0) \
+	param(int, enable_guc, -1) \
 	param(int, guc_log_level, -1) \
 	param(char *, guc_firmware_path, NULL) \
 	param(char *, huc_firmware_path, NULL) \
-- 
2.7.4

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

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* ✗ Fi.CI.BAT: failure for series starting with [v4,1/5] drm/i915/guc: Move GuC WOPCM related code into separate files
  2017-12-12 22:56 [PATCH v4 1/5] drm/i915/guc: Move GuC WOPCM related code into separate files Jackie Li
                   ` (3 preceding siblings ...)
  2017-12-12 22:56 ` [PATCH v4 5/5] HAX Enable GuC Submission for CI Jackie Li
@ 2017-12-12 23:18 ` Patchwork
  2017-12-13  8:19 ` [PATCH v4 1/5] " Joonas Lahtinen
  5 siblings, 0 replies; 16+ messages in thread
From: Patchwork @ 2017-12-12 23:18 UTC (permalink / raw)
  To: Jackie Li; +Cc: intel-gfx

== Series Details ==

Series: series starting with [v4,1/5] drm/i915/guc: Move GuC WOPCM related code into separate files
URL   : https://patchwork.freedesktop.org/series/35255/
State : failure

== Summary ==

Series 35255v1 series starting with [v4,1/5] drm/i915/guc: Move GuC WOPCM related code into separate files
https://patchwork.freedesktop.org/api/1.0/series/35255/revisions/1/mbox/

Test core_auth:
        Subgroup basic-auth:
                pass       -> SKIP       (fi-glk-1)
Test core_prop_blob:
        Subgroup basic:
                pass       -> SKIP       (fi-glk-1)
Test debugfs_test:
        Subgroup read_all_entries:
                pass       -> DMESG-WARN (fi-skl-6260u)
                pass       -> DMESG-WARN (fi-skl-6600u)
                pass       -> DMESG-WARN (fi-skl-6700hq)
                pass       -> DMESG-WARN (fi-skl-6700k)
                pass       -> DMESG-WARN (fi-skl-6770hq)
                pass       -> DMESG-WARN (fi-skl-gvtdvm)
                pass       -> DMESG-WARN (fi-bxt-dsi)
                pass       -> DMESG-WARN (fi-bxt-j4205)
                pass       -> DMESG-WARN (fi-kbl-7500u) fdo#103285
                pass       -> DMESG-WARN (fi-kbl-7560u)
                pass       -> DMESG-WARN (fi-kbl-7567u)
                pass       -> DMESG-WARN (fi-kbl-r)
                pass       -> SKIP       (fi-glk-1)
Test drv_getparams_basic:
        Subgroup basic-eu-total:
                pass       -> SKIP       (fi-glk-1)
        Subgroup basic-subslice-total:
                pass       -> SKIP       (fi-glk-1)
Test drv_hangman:
        Subgroup error-state-basic:
                pass       -> SKIP       (fi-glk-1)
Test gem_basic:
        Subgroup bad-close:
                pass       -> SKIP       (fi-glk-1)
        Subgroup create-close:
                pass       -> SKIP       (fi-glk-1)
        Subgroup create-fd-close:
                pass       -> SKIP       (fi-glk-1)
Test gem_busy:
        Subgroup basic-busy-default:
                pass       -> SKIP       (fi-glk-1)
        Subgroup basic-hang-default:
                pass       -> SKIP       (fi-glk-1)
Test gem_close_race:
        Subgroup basic-process:
                pass       -> SKIP       (fi-glk-1)
        Subgroup basic-threads:
                pass       -> SKIP       (fi-glk-1)
Test gem_cpu_reloc:
        Subgroup basic:
                pass       -> SKIP       (fi-glk-1)
Test gem_cs_tlb:
        Subgroup basic-default:
                pass       -> SKIP       (fi-glk-1)
Test gem_ctx_create:
        Subgroup basic:
                pass       -> SKIP       (fi-glk-1)
        Subgroup basic-files:
                pass       -> SKIP       (fi-glk-1) fdo#103706 +7
Test gem_ctx_exec:
        Subgroup basic:
                pass       -> SKIP       (fi-glk-1)
Test gem_ctx_param:
        Subgroup basic:
                pass       -> SKIP       (fi-glk-1)
        Subgroup basic-default:
                pass       -> SKIP       (fi-glk-1)
Test gem_ctx_switch:
        Subgroup basic-default:
                pass       -> SKIP       (fi-glk-1)
        Subgroup basic-default-heavy:
                pass       -> SKIP       (fi-glk-1)
Test gem_exec_basic:
        Subgroup basic-blt:
                pass       -> SKIP       (fi-glk-1)
        Subgroup basic-bsd:
                pass       -> SKIP       (fi-glk-1)
        Subgroup basic-default:
                pass       -> SKIP       (fi-glk-1)
        Subgroup basic-render:
                pass       -> SKIP       (fi-glk-1)
        Subgroup basic-vebox:
                pass       -> SKIP       (fi-glk-1)
        Subgroup gtt-blt:
                pass       -> SKIP       (fi-glk-1)
        Subgroup gtt-bsd:
                pass       -> SKIP       (fi-glk-1)
        Subgroup gtt-default:
                pass       -> SKIP       (fi-glk-1)
        Subgroup gtt-render:
                pass       -> SKIP       (fi-glk-1)
        Subgroup gtt-vebox:
                pass       -> SKIP       (fi-glk-1)
        Subgroup readonly-blt:
                pass       -> SKIP       (fi-glk-1)
        Subgroup readonly-bsd:
                pass       -> SKIP       (fi-glk-1)
        Subgroup readonly-default:
                pass       -> SKIP       (fi-glk-1)
WARNING: Long output truncated

8874c0f95698c533c0daf69c6c41834d837fef87 drm-tip: 2017y-12m-12d-21h-34m-33s UTC integration manifest
2cd95f9c999f HAX Enable GuC Submission for CI
65bad8a5b9ba drm/i915/guc: Add WOPCM partitioning support for CNL
1d5092f7f8cd drm/i915/guc: Implement dynamic WOPCM partitioning
23413278b914 drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset
2200a62616d8 drm/i915/guc: Move GuC WOPCM related code into separate files

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7477/issues.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v4 1/5] drm/i915/guc: Move GuC WOPCM related code into separate files
  2017-12-12 22:56 [PATCH v4 1/5] drm/i915/guc: Move GuC WOPCM related code into separate files Jackie Li
                   ` (4 preceding siblings ...)
  2017-12-12 23:18 ` ✗ Fi.CI.BAT: failure for series starting with [v4,1/5] drm/i915/guc: Move GuC WOPCM related code into separate files Patchwork
@ 2017-12-13  8:19 ` Joonas Lahtinen
  2017-12-13 18:29   ` Yaodong Li
  5 siblings, 1 reply; 16+ messages in thread
From: Joonas Lahtinen @ 2017-12-13  8:19 UTC (permalink / raw)
  To: Jackie Li, intel-gfx

On Tue, 2017-12-12 at 14:56 -0800, Jackie Li wrote:
> intel_guc_reg.h should only include definition for GuC registers
> and related register bits. GuC WOPCM related values should not
> be defined in intel_guc_reg.h
> 
> This patch creates a better file structure by moving GuC WOPCM
> related definitions int to a new header intel_guc_wopcm.h
> and moving GuC WOPCM related functions to a new source file
> intel_guc_wopcm.c
> 
> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Signed-off-by: Jackie Li <yaodong.li@intel.com>

<SNIP>

> +++ b/drivers/gpu/drm/i915/intel_uc.c
> @@ -218,7 +218,7 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
>  	}
>  
>  	/* init WOPCM */
> -	I915_WRITE(GUC_WOPCM_SIZE, intel_guc_wopcm_size(dev_priv));
> +	I915_WRITE(GUC_WOPCM_SIZE, intel_guc_wopcm_size(guc));

This is a write-once register, the code needs to be refactored to
account that somebody (like an ugly BIOS) wrote it already and we have
to live with that value. Otherwise we're digging a hole for future
selves.

We should also verify that the write sticks as we expect.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v4 3/5] drm/i915/guc: Implement dynamic WOPCM partitioning
  2017-12-12 22:56 ` [PATCH v4 3/5] drm/i915/guc: Implement dynamic WOPCM partitioning Jackie Li
@ 2017-12-13  9:11   ` Joonas Lahtinen
  2017-12-13 18:19     ` Yaodong Li
  0 siblings, 1 reply; 16+ messages in thread
From: Joonas Lahtinen @ 2017-12-13  9:11 UTC (permalink / raw)
  To: Jackie Li, intel-gfx; +Cc: Sujaritha Sundaresan

On Tue, 2017-12-12 at 14:56 -0800, Jackie Li wrote:
> Hardware may have specific restrictions on GuC WOPCM partition
> size versus HuC firmware size. With static WOPCM partitioning,
> there's no way to adjust the GuC WOPCM partition size based on
> the actual HuC firmware size, so that GuC/HuC loading failure
> would occur even if there was enough WOPCM space for both
> GuC and HuC firmware.

WOPCM being a shared feature of the hardware, it should not go under
intel_guc_ prefix.

There should be a clear division of what is specific to GuC feature
only and what is just a feature that happens to be used by GuC (and
equally can be used by HuC too).

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v4 3/5] drm/i915/guc: Implement dynamic WOPCM partitioning
  2017-12-13  9:11   ` Joonas Lahtinen
@ 2017-12-13 18:19     ` Yaodong Li
  2017-12-13 21:34       ` Michal Wajdeczko
  0 siblings, 1 reply; 16+ messages in thread
From: Yaodong Li @ 2017-12-13 18:19 UTC (permalink / raw)
  To: Joonas Lahtinen, intel-gfx; +Cc: Sujaritha Sundaresan

On 12/13/2017 01:11 AM, Joonas Lahtinen wrote:
> On Tue, 2017-12-12 at 14:56 -0800, Jackie Li wrote:
>> Hardware may have specific restrictions on GuC WOPCM partition
>> size versus HuC firmware size. With static WOPCM partitioning,
>> there's no way to adjust the GuC WOPCM partition size based on
>> the actual HuC firmware size, so that GuC/HuC loading failure
>> would occur even if there was enough WOPCM space for both
>> GuC and HuC firmware.
> WOPCM being a shared feature of the hardware, it should not go under
> intel_guc_ prefix.
>
> There should be a clear division of what is specific to GuC feature
> only and what is just a feature that happens to be used by GuC (and
> equally can be used by HuC too).
the intel_guc_wopcm here only refers to the wopcm used by
GuC, this structure only defines the GuC related wopcm info.
(wopcm partition for GuC). We only need to set these values
(defined in this structure) to GuC registers. And this structure
should never be touched if GuC was disabled. so it should be
a part of GuC.

Regards, Jackie
>
> Regards, Joonas

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v4 1/5] drm/i915/guc: Move GuC WOPCM related code into separate files
  2017-12-13  8:19 ` [PATCH v4 1/5] " Joonas Lahtinen
@ 2017-12-13 18:29   ` Yaodong Li
  0 siblings, 0 replies; 16+ messages in thread
From: Yaodong Li @ 2017-12-13 18:29 UTC (permalink / raw)
  To: Joonas Lahtinen, intel-gfx

On 12/13/2017 12:19 AM, Joonas Lahtinen wrote:
> On Tue, 2017-12-12 at 14:56 -0800, Jackie Li wrote:
>> intel_guc_reg.h should only include definition for GuC registers
>> and related register bits. GuC WOPCM related values should not
>> be defined in intel_guc_reg.h
>>
>> This patch creates a better file structure by moving GuC WOPCM
>> related definitions int to a new header intel_guc_wopcm.h
>> and moving GuC WOPCM related functions to a new source file
>> intel_guc_wopcm.c
>>
>> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>> Signed-off-by: Jackie Li <yaodong.li@intel.com>
> <SNIP>
>
>> +++ b/drivers/gpu/drm/i915/intel_uc.c
>> @@ -218,7 +218,7 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
>>   	}
>>   
>>   	/* init WOPCM */
>> -	I915_WRITE(GUC_WOPCM_SIZE, intel_guc_wopcm_size(dev_priv));
>> +	I915_WRITE(GUC_WOPCM_SIZE, intel_guc_wopcm_size(guc));
> This is a write-once register, the code needs to be refactored to
> account that somebody (like an ugly BIOS) wrote it already and we have
> to live with that value. Otherwise we're digging a hole for future
> selves.
It's the way the current code works. I will work out a new patch to
do the code refactoring. Anyhow, this is a good catch! Thanks!
>
> We should also verify that the write sticks as we expect.
For the verification - the following dynamic partitioning patch will
guarantee the correctness of this size value. As for the successful
register updating, I will address it within the new patch code refactoring
patch.
>
> Regards, Joonas

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v4 3/5] drm/i915/guc: Implement dynamic WOPCM partitioning
  2017-12-13 18:19     ` Yaodong Li
@ 2017-12-13 21:34       ` Michal Wajdeczko
  2017-12-13 22:59         ` Yaodong Li
  0 siblings, 1 reply; 16+ messages in thread
From: Michal Wajdeczko @ 2017-12-13 21:34 UTC (permalink / raw)
  To: Joonas Lahtinen, intel-gfx, Yaodong Li; +Cc: Sujaritha Sundaresan

On Wed, 13 Dec 2017 19:19:06 +0100, Yaodong Li <yaodong.li@intel.com>  
wrote:

> On 12/13/2017 01:11 AM, Joonas Lahtinen wrote:
>> On Tue, 2017-12-12 at 14:56 -0800, Jackie Li wrote:
>>> Hardware may have specific restrictions on GuC WOPCM partition
>>> size versus HuC firmware size. With static WOPCM partitioning,
>>> there's no way to adjust the GuC WOPCM partition size based on
>>> the actual HuC firmware size, so that GuC/HuC loading failure
>>> would occur even if there was enough WOPCM space for both
>>> GuC and HuC firmware.
>> WOPCM being a shared feature of the hardware, it should not go under
>> intel_guc_ prefix.
>>
>> There should be a clear division of what is specific to GuC feature
>> only and what is just a feature that happens to be used by GuC (and
>> equally can be used by HuC too).
> the intel_guc_wopcm here only refers to the wopcm used by
> GuC, this structure only defines the GuC related wopcm info.
> (wopcm partition for GuC). We only need to set these values
> (defined in this structure) to GuC registers. And this structure
> should never be touched if GuC was disabled. so it should be
> a part of GuC.
>

But note that yours intel_guc_wopcm is just one of many wopcm partitions.
I think it would be a good idea to create "intel_wopcm.c|h" and keep
all related code and data there (including verification of early setup
done by bios, wopcpm reporting, partitioning).

Then we can do rest of the programming right there or just take values that
will be programmed individually by interested components (but former is
preferred to avoid spreading single feature code over too many places)

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v4 3/5] drm/i915/guc: Implement dynamic WOPCM partitioning
  2017-12-13 21:34       ` Michal Wajdeczko
@ 2017-12-13 22:59         ` Yaodong Li
  2017-12-14 11:43           ` Joonas Lahtinen
  0 siblings, 1 reply; 16+ messages in thread
From: Yaodong Li @ 2017-12-13 22:59 UTC (permalink / raw)
  To: Michal Wajdeczko, Joonas Lahtinen, intel-gfx; +Cc: Sujaritha Sundaresan

On 12/13/2017 01:34 PM, Michal Wajdeczko wrote:
> On Wed, 13 Dec 2017 19:19:06 +0100, Yaodong Li <yaodong.li@intel.com> 
> wrote:
>
>> On 12/13/2017 01:11 AM, Joonas Lahtinen wrote:
>>> On Tue, 2017-12-12 at 14:56 -0800, Jackie Li wrote:
>>>> Hardware may have specific restrictions on GuC WOPCM partition
>>>> size versus HuC firmware size. With static WOPCM partitioning,
>>>> there's no way to adjust the GuC WOPCM partition size based on
>>>> the actual HuC firmware size, so that GuC/HuC loading failure
>>>> would occur even if there was enough WOPCM space for both
>>>> GuC and HuC firmware.
>>> WOPCM being a shared feature of the hardware, it should not go under
>>> intel_guc_ prefix.
>>>
>>> There should be a clear division of what is specific to GuC feature
>>> only and what is just a feature that happens to be used by GuC (and
>>> equally can be used by HuC too).
>> the intel_guc_wopcm here only refers to the wopcm used by
>> GuC, this structure only defines the GuC related wopcm info.
>> (wopcm partition for GuC). We only need to set these values
>> (defined in this structure) to GuC registers. And this structure
>> should never be touched if GuC was disabled. so it should be
>> a part of GuC.
>>
>
> But note that yours intel_guc_wopcm is just one of many wopcm partitions.
> I think it would be a good idea to create "intel_wopcm.c|h" and keep
> all related code and data there (including verification of early setup
> done by bios, wopcpm reporting, partitioning).
>
> Then we can do rest of the programming right there or just take values 
> that
> will be programmed individually by interested components (but former is
> preferred to avoid spreading single feature code over too many places)
>
The KMD only needs to take care of the setup of the GuC WOPCM partition. 
Other
HW WOPCM (e.g HuC) usages are all transparent to kernel driver. Plus, 
the GuC WOPM
partitioning is needed only when GuC is enabled and uc firmwares are 
loaded correctly.
The only reason for us to have an intel_wopcm is to maintain the overall 
WOPCM info
such as WOPCM size and base. However, it's not necessary since we can 
reuse existing
driver code to get these info.

Regards,
-Jackie
> Michal

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v4 3/5] drm/i915/guc: Implement dynamic WOPCM partitioning
  2017-12-13 22:59         ` Yaodong Li
@ 2017-12-14 11:43           ` Joonas Lahtinen
  2017-12-15  4:55             ` Yaodong Li
  0 siblings, 1 reply; 16+ messages in thread
From: Joonas Lahtinen @ 2017-12-14 11:43 UTC (permalink / raw)
  To: Yaodong Li, Michal Wajdeczko, intel-gfx; +Cc: Sujaritha Sundaresan

On Wed, 2017-12-13 at 14:59 -0800, Yaodong Li wrote:
> On 12/13/2017 01:34 PM, Michal Wajdeczko wrote:
> > On Wed, 13 Dec 2017 19:19:06 +0100, Yaodong Li <yaodong.li@intel.com> 
> > wrote:
> > 
> > > On 12/13/2017 01:11 AM, Joonas Lahtinen wrote:
> > > > On Tue, 2017-12-12 at 14:56 -0800, Jackie Li wrote:
> > > > > Hardware may have specific restrictions on GuC WOPCM partition
> > > > > size versus HuC firmware size. With static WOPCM partitioning,
> > > > > there's no way to adjust the GuC WOPCM partition size based on
> > > > > the actual HuC firmware size, so that GuC/HuC loading failure
> > > > > would occur even if there was enough WOPCM space for both
> > > > > GuC and HuC firmware.
> > > > 
> > > > WOPCM being a shared feature of the hardware, it should not go under
> > > > intel_guc_ prefix.
> > > > 
> > > > There should be a clear division of what is specific to GuC feature
> > > > only and what is just a feature that happens to be used by GuC (and
> > > > equally can be used by HuC too).
> > > 
> > > the intel_guc_wopcm here only refers to the wopcm used by
> > > GuC, this structure only defines the GuC related wopcm info.
> > > (wopcm partition for GuC). We only need to set these values
> > > (defined in this structure) to GuC registers. And this structure
> > > should never be touched if GuC was disabled. so it should be
> > > a part of GuC.
> > > 
> > 
> > But note that yours intel_guc_wopcm is just one of many wopcm partitions.
> > I think it would be a good idea to create "intel_wopcm.c|h" and keep
> > all related code and data there (including verification of early setup
> > done by bios, wopcpm reporting, partitioning).
> > 
> > Then we can do rest of the programming right there or just take values 
> > that
> > will be programmed individually by interested components (but former is
> > preferred to avoid spreading single feature code over too many places)
> > 
> 
> The KMD only needs to take care of the setup of the GuC WOPCM partition. 
> Other
> HW WOPCM (e.g HuC) usages are all transparent to kernel driver. Plus, 
> the GuC WOPM
> partitioning is needed only when GuC is enabled and uc firmwares are 
> loaded correctly.
> The only reason for us to have an intel_wopcm is to maintain the overall 
> WOPCM info
> such as WOPCM size and base. However, it's not necessary since we can 
> reuse existing
> driver code to get these info.

I'd go with Michal here, the WOPCM is its own entity in existence.
Partitioning defintely sounds like it should be intel_wopcm stuff,
which may yield intel_wopcm_partition under "guc", so then you are
still able to reference "guc->wopcm.base" where it makes sense.

And how that partition is programmed to GuC registers for it to be
used, is then stuff to go under intel_guc. And then you have another
intel_wopcm_partition for "huc".

We should avoid incorrect abstractions, just to avoid a few lines of
code. That's how the hardware features seem to exist, that's how we
should map them in the code.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v4 3/5] drm/i915/guc: Implement dynamic WOPCM partitioning
  2017-12-14 11:43           ` Joonas Lahtinen
@ 2017-12-15  4:55             ` Yaodong Li
  2017-12-15 10:21               ` Joonas Lahtinen
  0 siblings, 1 reply; 16+ messages in thread
From: Yaodong Li @ 2017-12-15  4:55 UTC (permalink / raw)
  To: Joonas Lahtinen, Michal Wajdeczko, intel-gfx; +Cc: Sujaritha Sundaresan

On 12/14/2017 03:43 AM, Joonas Lahtinen wrote:
> On Wed, 2017-12-13 at 14:59 -0800, Yaodong Li wrote:
>> On 12/13/2017 01:34 PM, Michal Wajdeczko wrote:
>>> On Wed, 13 Dec 2017 19:19:06 +0100, Yaodong Li <yaodong.li@intel.com>
>>> wrote:
>>>
>>>> On 12/13/2017 01:11 AM, Joonas Lahtinen wrote:
>>>>> On Tue, 2017-12-12 at 14:56 -0800, Jackie Li wrote:
>>>>>> Hardware may have specific restrictions on GuC WOPCM partition
>>>>>> size versus HuC firmware size. With static WOPCM partitioning,
>>>>>> there's no way to adjust the GuC WOPCM partition size based on
>>>>>> the actual HuC firmware size, so that GuC/HuC loading failure
>>>>>> would occur even if there was enough WOPCM space for both
>>>>>> GuC and HuC firmware.
>>>>> WOPCM being a shared feature of the hardware, it should not go under
>>>>> intel_guc_ prefix.
>>>>>
>>>>> There should be a clear division of what is specific to GuC feature
>>>>> only and what is just a feature that happens to be used by GuC (and
>>>>> equally can be used by HuC too).
>>>> the intel_guc_wopcm here only refers to the wopcm used by
>>>> GuC, this structure only defines the GuC related wopcm info.
>>>> (wopcm partition for GuC). We only need to set these values
>>>> (defined in this structure) to GuC registers. And this structure
>>>> should never be touched if GuC was disabled. so it should be
>>>> a part of GuC.
>>>>
>>> But note that yours intel_guc_wopcm is just one of many wopcm partitions.
>>> I think it would be a good idea to create "intel_wopcm.c|h" and keep
>>> all related code and data there (including verification of early setup
>>> done by bios, wopcpm reporting, partitioning).
>>>
>>> Then we can do rest of the programming right there or just take values
>>> that
>>> will be programmed individually by interested components (but former is
>>> preferred to avoid spreading single feature code over too many places)
>>>
>> The KMD only needs to take care of the setup of the GuC WOPCM partition.
>> Other
>> HW WOPCM (e.g HuC) usages are all transparent to kernel driver. Plus,
>> the GuC WOPM
>> partitioning is needed only when GuC is enabled and uc firmwares are
>> loaded correctly.
>> The only reason for us to have an intel_wopcm is to maintain the overall
>> WOPCM info
>> such as WOPCM size and base. However, it's not necessary since we can
>> reuse existing
>> driver code to get these info.
> I'd go with Michal here, the WOPCM is its own entity in existence.
> Partitioning defintely sounds like it should be intel_wopcm stuff,
> which may yield intel_wopcm_partition under "guc", so then you are
> still able to reference "guc->wopcm.base" where it makes sense.
>
> And how that partition is programmed to GuC registers for it to be
> used, is then stuff to go under intel_guc. And then you have another
> intel_wopcm_partition for "huc".
>
> We should avoid incorrect abstractions, just to avoid a few lines of
> code. That's how the hardware features seem to exist, that's how we
> should map them in the code.
Thanks for your comments. but I have some different opinions.

Agreed that wopcm exists no matter GuC is enabled or not. And we
can reuse existing code to get/verify related info we need for driver level
description of wopcm. that one reason I don't think we need intel_wopcm.

Regarding the partitioning - We need it only when GuC was enabled. In this
case, it makes sense to do it at least in uc level. Plus, from HW point 
of view,
HW only relies on GuC wopcm offset and size to determine the layout
(or say partitions) of the wopcm. In this case, a good abstraction of 
the HW
interface would be:
   struct guc_wopcm {
     u32 offset;
     u32 size;
   };
   guc_wopcm_setup() - which does actual HW status check and GuC wopcm 
setup.
   guc_wopcm_init() - which init/verify the offset and size values 
required by HW.
That's the second reason I think use of intel_guc_wopcm.c is more accurate
since it reflected the actual HW interface and could be enabled/disabled
along with GuC code.

Regarding the generic abstraction of intel_wopcm_partition for both GuC 
& HuC.
I am not sure what's the benefit of such an abstraction. For two reasons:
a) HW is only aware of the GuC WOPCM boundaries and doesn't provide any 
interface
     to configure the partition for HuC, which means we even won't use 
these info in
     the rest of the driver code.
b) For debugging and tracking propose, we can easily get overall layout 
of WOPCM
     by just using overall wopcm description and GuC wopcm usage.

Please do let me know if anything was wrong :-)

Regards,
-Jackie
> Regards, Joonas

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v4 3/5] drm/i915/guc: Implement dynamic WOPCM partitioning
  2017-12-15  4:55             ` Yaodong Li
@ 2017-12-15 10:21               ` Joonas Lahtinen
  2017-12-15 19:16                 ` Yaodong Li
  0 siblings, 1 reply; 16+ messages in thread
From: Joonas Lahtinen @ 2017-12-15 10:21 UTC (permalink / raw)
  To: Yaodong Li, Michal Wajdeczko, intel-gfx; +Cc: Sujaritha Sundaresan

On Thu, 2017-12-14 at 20:55 -0800, Yaodong Li wrote:
> On 12/14/2017 03:43 AM, Joonas Lahtinen wrote:
> > On Wed, 2017-12-13 at 14:59 -0800, Yaodong Li wrote:
> > > On 12/13/2017 01:34 PM, Michal Wajdeczko wrote:
> > > > On Wed, 13 Dec 2017 19:19:06 +0100, Yaodong Li <yaodong.li@intel.com>
> > > > wrote:
> > > > 
> > > > > On 12/13/2017 01:11 AM, Joonas Lahtinen wrote:
> > > > > > On Tue, 2017-12-12 at 14:56 -0800, Jackie Li wrote:
> > > > > > > Hardware may have specific restrictions on GuC WOPCM partition
> > > > > > > size versus HuC firmware size. With static WOPCM partitioning,
> > > > > > > there's no way to adjust the GuC WOPCM partition size based on
> > > > > > > the actual HuC firmware size, so that GuC/HuC loading failure
> > > > > > > would occur even if there was enough WOPCM space for both
> > > > > > > GuC and HuC firmware.
> > > > > > 
> > > > > > WOPCM being a shared feature of the hardware, it should not go under
> > > > > > intel_guc_ prefix.
> > > > > > 
> > > > > > There should be a clear division of what is specific to GuC feature
> > > > > > only and what is just a feature that happens to be used by GuC (and
> > > > > > equally can be used by HuC too).
> > > > > 
> > > > > the intel_guc_wopcm here only refers to the wopcm used by
> > > > > GuC, this structure only defines the GuC related wopcm info.
> > > > > (wopcm partition for GuC). We only need to set these values
> > > > > (defined in this structure) to GuC registers. And this structure
> > > > > should never be touched if GuC was disabled. so it should be
> > > > > a part of GuC.
> > > > > 
> > > > 
> > > > But note that yours intel_guc_wopcm is just one of many wopcm partitions.
> > > > I think it would be a good idea to create "intel_wopcm.c|h" and keep
> > > > all related code and data there (including verification of early setup
> > > > done by bios, wopcpm reporting, partitioning).
> > > > 
> > > > Then we can do rest of the programming right there or just take values
> > > > that
> > > > will be programmed individually by interested components (but former is
> > > > preferred to avoid spreading single feature code over too many places)
> > > > 
> > > 
> > > The KMD only needs to take care of the setup of the GuC WOPCM partition.
> > > Other
> > > HW WOPCM (e.g HuC) usages are all transparent to kernel driver. Plus,
> > > the GuC WOPM
> > > partitioning is needed only when GuC is enabled and uc firmwares are
> > > loaded correctly.
> > > The only reason for us to have an intel_wopcm is to maintain the overall
> > > WOPCM info
> > > such as WOPCM size and base. However, it's not necessary since we can
> > > reuse existing
> > > driver code to get these info.
> > 
> > I'd go with Michal here, the WOPCM is its own entity in existence.
> > Partitioning defintely sounds like it should be intel_wopcm stuff,
> > which may yield intel_wopcm_partition under "guc", so then you are
> > still able to reference "guc->wopcm.base" where it makes sense.
> > 
> > And how that partition is programmed to GuC registers for it to be
> > used, is then stuff to go under intel_guc. And then you have another
> > intel_wopcm_partition for "huc".
> > 
> > We should avoid incorrect abstractions, just to avoid a few lines of
> > code. That's how the hardware features seem to exist, that's how we
> > should map them in the code.
> 
> Thanks for your comments. but I have some different opinions.
> 
> Agreed that wopcm exists no matter GuC is enabled or not. And we
> can reuse existing code to get/verify related info we need for driver level
> description of wopcm. that one reason I don't think we need intel_wopcm.
> 
> Regarding the partitioning - We need it only when GuC was enabled. In this
> case, it makes sense to do it at least in uc level. Plus, from HW point 
> of view,
> HW only relies on GuC wopcm offset and size to determine the layout
> (or say partitions) of the wopcm. In this case, a good abstraction of 
> the HW
> interface would be:
>    struct guc_wopcm {
>      u32 offset;
>      u32 size;
>    };
>    guc_wopcm_setup() - which does actual HW status check and GuC wopcm 
> setup.
>    guc_wopcm_init() - which init/verify the offset and size values 
> required by HW.
> That's the second reason I think use of intel_guc_wopcm.c is more accurate
> since it reflected the actual HW interface and could be enabled/disabled
> along with GuC code.
> 
> Regarding the generic abstraction of intel_wopcm_partition for both GuC 
> & HuC.
> I am not sure what's the benefit of such an abstraction. For two reasons:
> a) HW is only aware of the GuC WOPCM boundaries and doesn't provide any 
> interface
>      to configure the partition for HuC, which means we even won't use 
> these info in
>      the rest of the driver code.
> b) For debugging and tracking propose, we can easily get overall layout 
> of WOPCM
>      by just using overall wopcm description and GuC wopcm usage.
> 

It's literally an entity called WOPCM, which is partitioned and one of
the partitions is used for GuC. I don't see how many more resons you
need for intel_wopcm prefix, struct intel_wopcm_partition abstraction
and struct intel_wopcm_partition instance for GuC?

Why would we try to make the naming scheme to imply something else,
it'll make the developer's life harder when trying to look at it. I had
to go look at the spec to make any sense of this, so let's try to avoid
that for the next developer.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v4 3/5] drm/i915/guc: Implement dynamic WOPCM partitioning
  2017-12-15 10:21               ` Joonas Lahtinen
@ 2017-12-15 19:16                 ` Yaodong Li
  0 siblings, 0 replies; 16+ messages in thread
From: Yaodong Li @ 2017-12-15 19:16 UTC (permalink / raw)
  To: Joonas Lahtinen, Michal Wajdeczko, intel-gfx; +Cc: Sujaritha Sundaresan

On 12/15/2017 02:21 AM, Joonas Lahtinen wrote:
> On Thu, 2017-12-14 at 20:55 -0800, Yaodong Li wrote:
>> On 12/14/2017 03:43 AM, Joonas Lahtinen wrote:
>>> On Wed, 2017-12-13 at 14:59 -0800, Yaodong Li wrote:
>>>> On 12/13/2017 01:34 PM, Michal Wajdeczko wrote:
>>>>> On Wed, 13 Dec 2017 19:19:06 +0100, Yaodong Li <yaodong.li@intel.com>
>>>>> wrote:
>>>>>
>>>>>> On 12/13/2017 01:11 AM, Joonas Lahtinen wrote:
>>>>>>> On Tue, 2017-12-12 at 14:56 -0800, Jackie Li wrote:
>>>>>>>> Hardware may have specific restrictions on GuC WOPCM partition
>>>>>>>> size versus HuC firmware size. With static WOPCM partitioning,
>>>>>>>> there's no way to adjust the GuC WOPCM partition size based on
>>>>>>>> the actual HuC firmware size, so that GuC/HuC loading failure
>>>>>>>> would occur even if there was enough WOPCM space for both
>>>>>>>> GuC and HuC firmware.
>>>>>>> WOPCM being a shared feature of the hardware, it should not go under
>>>>>>> intel_guc_ prefix.
>>>>>>>
>>>>>>> There should be a clear division of what is specific to GuC feature
>>>>>>> only and what is just a feature that happens to be used by GuC (and
>>>>>>> equally can be used by HuC too).
>>>>>> the intel_guc_wopcm here only refers to the wopcm used by
>>>>>> GuC, this structure only defines the GuC related wopcm info.
>>>>>> (wopcm partition for GuC). We only need to set these values
>>>>>> (defined in this structure) to GuC registers. And this structure
>>>>>> should never be touched if GuC was disabled. so it should be
>>>>>> a part of GuC.
>>>>>>
>>>>> But note that yours intel_guc_wopcm is just one of many wopcm partitions.
>>>>> I think it would be a good idea to create "intel_wopcm.c|h" and keep
>>>>> all related code and data there (including verification of early setup
>>>>> done by bios, wopcpm reporting, partitioning).
>>>>>
>>>>> Then we can do rest of the programming right there or just take values
>>>>> that
>>>>> will be programmed individually by interested components (but former is
>>>>> preferred to avoid spreading single feature code over too many places)
>>>>>
>>>> The KMD only needs to take care of the setup of the GuC WOPCM partition.
>>>> Other
>>>> HW WOPCM (e.g HuC) usages are all transparent to kernel driver. Plus,
>>>> the GuC WOPM
>>>> partitioning is needed only when GuC is enabled and uc firmwares are
>>>> loaded correctly.
>>>> The only reason for us to have an intel_wopcm is to maintain the overall
>>>> WOPCM info
>>>> such as WOPCM size and base. However, it's not necessary since we can
>>>> reuse existing
>>>> driver code to get these info.
>>> I'd go with Michal here, the WOPCM is its own entity in existence.
>>> Partitioning defintely sounds like it should be intel_wopcm stuff,
>>> which may yield intel_wopcm_partition under "guc", so then you are
>>> still able to reference "guc->wopcm.base" where it makes sense.
>>>
>>> And how that partition is programmed to GuC registers for it to be
>>> used, is then stuff to go under intel_guc. And then you have another
>>> intel_wopcm_partition for "huc".
>>>
>>> We should avoid incorrect abstractions, just to avoid a few lines of
>>> code. That's how the hardware features seem to exist, that's how we
>>> should map them in the code.
>> Thanks for your comments. but I have some different opinions.
>>
>> Agreed that wopcm exists no matter GuC is enabled or not. And we
>> can reuse existing code to get/verify related info we need for driver level
>> description of wopcm. that one reason I don't think we need intel_wopcm.
>>
>> Regarding the partitioning - We need it only when GuC was enabled. In this
>> case, it makes sense to do it at least in uc level. Plus, from HW point
>> of view,
>> HW only relies on GuC wopcm offset and size to determine the layout
>> (or say partitions) of the wopcm. In this case, a good abstraction of
>> the HW
>> interface would be:
>>     struct guc_wopcm {
>>       u32 offset;
>>       u32 size;
>>     };
>>     guc_wopcm_setup() - which does actual HW status check and GuC wopcm
>> setup.
>>     guc_wopcm_init() - which init/verify the offset and size values
>> required by HW.
>> That's the second reason I think use of intel_guc_wopcm.c is more accurate
>> since it reflected the actual HW interface and could be enabled/disabled
>> along with GuC code.
>>
>> Regarding the generic abstraction of intel_wopcm_partition for both GuC
>> & HuC.
>> I am not sure what's the benefit of such an abstraction. For two reasons:
>> a) HW is only aware of the GuC WOPCM boundaries and doesn't provide any
>> interface
>>       to configure the partition for HuC, which means we even won't use
>> these info in
>>       the rest of the driver code.
>> b) For debugging and tracking propose, we can easily get overall layout
>> of WOPCM
>>       by just using overall wopcm description and GuC wopcm usage.
>>
> It's literally an entity called WOPCM, which is partitioned and one of
> the partitions is used for GuC. I don't see how many more resons you
> need for intel_wopcm prefix, struct intel_wopcm_partition abstraction
> and struct intel_wopcm_partition instance for GuC?
>
> Why would we try to make the naming scheme to imply something else,
> it'll make the developer's life harder when trying to look at it. I had
> to go look at the spec to make any sense of this, so let's try to avoid
> that for the next developer.
Actually I started the patch with both intel_wopcm and intel_wopcm_partition
defined and implemented. The more I think about it the more I felt
it makes sense to keep the code within GuC level since the main work of
these code is quite simple - trying to find valid values for GuC wopcm.
that's the reason why I renamed it from intel_wopcm_partition to 
intel_guc_wopcm
because with intel_wopcm_partition defined, it will be confusing that we
only have intel_wopcm_partition defined for GuC.

Sorry for the naming thing. It kept changing along with the code 
reviewing, one
reason probably because I really wanted to catch up with all these good 
ideas
and provide a solid solution to this problem.

Again these are my own understanding. If you still think we should use a
intel_wopcm.c|h for these changes. I definitely will respect it and try 
to make things
happen in that way :-) I will hold the submission until we agree on the 
code structure.

Regards,
-Jackie
>
> Regards, Joonas

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2017-12-15 19:17 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-12 22:56 [PATCH v4 1/5] drm/i915/guc: Move GuC WOPCM related code into separate files Jackie Li
2017-12-12 22:56 ` [PATCH v4 2/5] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset Jackie Li
2017-12-12 22:56 ` [PATCH v4 3/5] drm/i915/guc: Implement dynamic WOPCM partitioning Jackie Li
2017-12-13  9:11   ` Joonas Lahtinen
2017-12-13 18:19     ` Yaodong Li
2017-12-13 21:34       ` Michal Wajdeczko
2017-12-13 22:59         ` Yaodong Li
2017-12-14 11:43           ` Joonas Lahtinen
2017-12-15  4:55             ` Yaodong Li
2017-12-15 10:21               ` Joonas Lahtinen
2017-12-15 19:16                 ` Yaodong Li
2017-12-12 22:56 ` [PATCH v4 4/5] drm/i915/guc: Add WOPCM partitioning support for CNL Jackie Li
2017-12-12 22:56 ` [PATCH v4 5/5] HAX Enable GuC Submission for CI Jackie Li
2017-12-12 23:18 ` ✗ Fi.CI.BAT: failure for series starting with [v4,1/5] drm/i915/guc: Move GuC WOPCM related code into separate files Patchwork
2017-12-13  8:19 ` [PATCH v4 1/5] " Joonas Lahtinen
2017-12-13 18:29   ` Yaodong Li

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.