* [PATCH 1/2] drm/i915: Add code to accept valid locked WOPCM register values
@ 2018-03-20 23:18 Jackie Li
2018-03-20 23:18 ` [PATCH 2/2] HAX enable guc for CI Jackie Li
` (2 more replies)
0 siblings, 3 replies; 17+ messages in thread
From: Jackie Li @ 2018-03-20 23:18 UTC (permalink / raw)
To: intel-gfx
In current code, we only compare the locked WOPCM register values with the
calculated values. However, we can continue loading GuC/HuC firmware if the
locked (or partially locked) values were valid for current GuC/HuC firmware
sizes.
This patch added a new code path to verify whether the locked register
values can be used for GuC/HuC firmware loading, it will recalculate the
verify the new values if these registers were partially locked, so that we
won't fail the GuC/HuC firmware loading even if the locked register values
are different from the calculated ones.
Signed-off-by: Jackie Li <yaodong.li@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: John Spotswood <john.a.spotswood@intel.com>
---
drivers/gpu/drm/i915/intel_wopcm.c | 183 +++++++++++++++++++++++++++++++------
1 file changed, 157 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c b/drivers/gpu/drm/i915/intel_wopcm.c
index 4117886..fbd8aba 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -138,6 +138,53 @@ static inline int check_hw_restriction(struct drm_i915_private *i915,
return err;
}
+static inline u32 calculate_min_guc_wopcm_base(u32 huc_fw_size)
+{
+ return ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
+ GUC_WOPCM_OFFSET_ALIGNMENT);
+}
+
+static inline u32 calculate_min_guc_wopcm_size(u32 guc_fw_size)
+{
+ return guc_fw_size + GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED;
+}
+
+static inline int calculate_max_guc_wopcm_size(struct intel_wopcm *wopcm,
+ u32 guc_wopcm_base,
+ u32 *guc_wopcm_size)
+{
+ struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
+ u32 ctx_rsvd = context_reserved_size(i915);
+
+ if (guc_wopcm_base >= wopcm->size ||
+ (guc_wopcm_base + ctx_rsvd) >= wopcm->size) {
+ DRM_ERROR("GuC WOPCM base (%uKiB) is too big.\n",
+ guc_wopcm_base / 1024);
+ return -E2BIG;
+ }
+
+ *guc_wopcm_size =
+ (wopcm->size - guc_wopcm_base - ctx_rsvd) & GUC_WOPCM_SIZE_MASK;
+
+ return 0;
+}
+
+static inline int verify_calculated_values(struct drm_i915_private *i915,
+ u32 guc_fw_size, u32 huc_fw_size,
+ u32 guc_wopcm_base,
+ u32 guc_wopcm_size)
+{
+ if (guc_wopcm_size < calculate_min_guc_wopcm_size(guc_fw_size)) {
+ DRM_ERROR("Need %uKiB WOPCM for GuC FW, %uKiB available.\n",
+ calculate_min_guc_wopcm_size(guc_fw_size),
+ guc_wopcm_size / 1024);
+ return -E2BIG;
+ }
+
+ return check_hw_restriction(i915, guc_wopcm_base, guc_wopcm_size,
+ huc_fw_size);
+}
+
/**
* intel_wopcm_init() - Initialize the WOPCM structure.
* @wopcm: pointer to intel_wopcm.
@@ -155,10 +202,8 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
u32 guc_fw_size = intel_uc_fw_get_upload_size(&i915->guc.fw);
u32 huc_fw_size = intel_uc_fw_get_upload_size(&i915->huc.fw);
- u32 ctx_rsvd = context_reserved_size(i915);
u32 guc_wopcm_base;
u32 guc_wopcm_size;
- u32 guc_wopcm_rsvd;
int err;
GEM_BUG_ON(!wopcm->size);
@@ -175,30 +220,17 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
return -E2BIG;
}
- guc_wopcm_base = ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
- GUC_WOPCM_OFFSET_ALIGNMENT);
- if ((guc_wopcm_base + ctx_rsvd) >= wopcm->size) {
- DRM_ERROR("GuC WOPCM base (%uKiB) is too big.\n",
- guc_wopcm_base / 1024);
- return -E2BIG;
- }
-
- guc_wopcm_size = wopcm->size - guc_wopcm_base - ctx_rsvd;
- guc_wopcm_size &= GUC_WOPCM_SIZE_MASK;
+ guc_wopcm_base = calculate_min_guc_wopcm_base(huc_fw_size);
+ err = calculate_max_guc_wopcm_size(wopcm, guc_wopcm_base,
+ &guc_wopcm_size);
+ if (err)
+ return err;
DRM_DEBUG_DRIVER("Calculated GuC WOPCM Region: [%uKiB, %uKiB)\n",
guc_wopcm_base / 1024, guc_wopcm_size / 1024);
- guc_wopcm_rsvd = GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED;
- if ((guc_fw_size + guc_wopcm_rsvd) > guc_wopcm_size) {
- DRM_ERROR("Need %uKiB WOPCM for GuC, %uKiB available.\n",
- (guc_fw_size + guc_wopcm_rsvd) / 1024,
- guc_wopcm_size / 1024);
- return -E2BIG;
- }
-
- err = check_hw_restriction(i915, guc_wopcm_base, guc_wopcm_size,
- huc_fw_size);
+ err = verify_calculated_values(i915, guc_fw_size, huc_fw_size,
+ guc_wopcm_base, guc_wopcm_size);
if (err)
return err;
@@ -208,6 +240,92 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
return 0;
}
+static inline int verify_locked_values(struct intel_wopcm *wopcm,
+ u32 guc_wopcm_base, u32 guc_wopcm_size)
+{
+ struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
+ u32 guc_fw_size = intel_uc_fw_get_upload_size(&i915->guc.fw);
+ u32 huc_fw_size = intel_uc_fw_get_upload_size(&i915->huc.fw);
+ u32 ctx_rsvd = context_reserved_size(i915);
+
+ /*
+ * Locked GuC WOPCM base and size could be any values are large enough
+ * to lead to a wrap around after performing add operations.
+ */
+ if (guc_wopcm_base >= wopcm->size) {
+ DRM_ERROR("Locked base value %uKiB >= WOPCM size %uKiB.\n",
+ guc_wopcm_base / 1024,
+ wopcm->size / 1024);
+ return -E2BIG;
+ }
+
+ if (guc_wopcm_size >= wopcm->size) {
+ DRM_ERROR("Locked size value %uKiB >= WOPCM size %uKiB.\n",
+ guc_wopcm_base / 1024,
+ wopcm->size / 1024);
+ return -E2BIG;
+ }
+
+ if (guc_wopcm_base + guc_wopcm_size + ctx_rsvd > wopcm->size) {
+ DRM_ERROR("Need %uKiB WOPCM in total, %uKiB available.\n",
+ (guc_wopcm_base + guc_wopcm_size + ctx_rsvd) / 1024,
+ (wopcm->size) / 1024);
+ return -E2BIG;
+ }
+
+ if (guc_wopcm_base < calculate_min_guc_wopcm_base(huc_fw_size)) {
+ DRM_ERROR("Need %uKiB WOPCM for HuC FW, %uKiB available.\n",
+ calculate_min_guc_wopcm_base(huc_fw_size) / 1024,
+ guc_wopcm_base / 1024);
+ return -E2BIG;
+ }
+
+ return verify_calculated_values(i915, guc_fw_size, huc_fw_size,
+ guc_wopcm_base, guc_wopcm_size);
+}
+
+static inline int verify_locked_values_and_update(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 size_val = I915_READ(GUC_WOPCM_SIZE);
+ u32 offset_val = I915_READ(DMA_GUC_WOPCM_OFFSET);
+ bool offset_reg_locked = offset_val & GUC_WOPCM_OFFSET_VALID;
+ bool size_reg_locked = size_val & GUC_WOPCM_SIZE_LOCKED;
+ u32 guc_wopcm_base = offset_val & GUC_WOPCM_OFFSET_MASK;
+ u32 guc_wopcm_size = size_val & GUC_WOPCM_SIZE_MASK;
+ int err;
+
+ if (!offset_reg_locked && !size_reg_locked)
+ return 0;
+
+ if (guc_wopcm_base == wopcm->guc.base &&
+ guc_wopcm_size == wopcm->guc.size)
+ return 0;
+
+ if (!offset_reg_locked)
+ guc_wopcm_base = calculate_min_guc_wopcm_base(huc_fw_size);
+
+ if (!size_reg_locked) {
+ err = calculate_max_guc_wopcm_size(wopcm, guc_wopcm_base,
+ &guc_wopcm_size);
+ if (err)
+ return err;
+ }
+
+ DRM_DEBUG_DRIVER("Recalculated GuC WOPCM Region: [%uKiB, %uKiB)\n",
+ guc_wopcm_base / 1024, guc_wopcm_size / 1024);
+
+ err = verify_locked_values(wopcm, guc_wopcm_base, guc_wopcm_size);
+ if (err)
+ return err;
+
+ wopcm->guc.size = guc_wopcm_size;
+ wopcm->guc.base = guc_wopcm_base;
+
+ return 0;
+}
+
static inline int write_and_verify(struct drm_i915_private *dev_priv,
i915_reg_t reg, u32 val, u32 mask,
u32 locked_bit)
@@ -231,7 +349,8 @@ static inline int write_and_verify(struct drm_i915_private *dev_priv,
* will verify the register values to make sure the registers are locked with
* correct values.
*
- * Return: 0 on success. -EIO if registers were locked with incorrect values.
+ * Return: 0 on success. Minus error code if registered were locked with
+ * incorrect values.-EIO if registers failed to lock with correct values.
*/
int intel_wopcm_init_hw(struct intel_wopcm *wopcm)
{
@@ -247,27 +366,39 @@ int intel_wopcm_init_hw(struct intel_wopcm *wopcm)
GEM_BUG_ON(!wopcm->guc.size);
GEM_BUG_ON(!wopcm->guc.base);
+ err = verify_locked_values_and_update(wopcm);
+ if (err) {
+ DRM_ERROR("WOPCM registers are locked with invalid values.\n");
+ goto err_out;
+ }
+
err = write_and_verify(dev_priv, GUC_WOPCM_SIZE, wopcm->guc.size,
GUC_WOPCM_SIZE_MASK | GUC_WOPCM_SIZE_LOCKED,
GUC_WOPCM_SIZE_LOCKED);
- if (err)
+ if (err) {
+ DRM_ERROR("Failed to lock GUC_WOPCM_SIZE with %#x.\n",
+ wopcm->guc.size);
goto err_out;
+ }
huc_agent = USES_HUC(dev_priv) ? HUC_LOADING_AGENT_GUC : 0;
mask = GUC_WOPCM_OFFSET_MASK | GUC_WOPCM_OFFSET_VALID | huc_agent;
err = write_and_verify(dev_priv, DMA_GUC_WOPCM_OFFSET,
wopcm->guc.base | huc_agent, mask,
GUC_WOPCM_OFFSET_VALID);
- if (err)
+ if (err) {
+ DRM_ERROR("Failed to lock DMA_GUC_WOPCM_OFFSET with %#x.\n",
+ wopcm->guc.base);
goto err_out;
+ }
return 0;
err_out:
- DRM_ERROR("Failed to init WOPCM registers:\n");
DRM_ERROR("DMA_GUC_WOPCM_OFFSET=%#x\n",
I915_READ(DMA_GUC_WOPCM_OFFSET));
DRM_ERROR("GUC_WOPCM_SIZE=%#x\n", I915_READ(GUC_WOPCM_SIZE));
+ DRM_ERROR("A system reboot is required.\n");
return err;
}
--
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] 17+ messages in thread* [PATCH 2/2] HAX enable guc for CI
2018-03-20 23:18 [PATCH 1/2] drm/i915: Add code to accept valid locked WOPCM register values Jackie Li
@ 2018-03-20 23:18 ` Jackie Li
2018-03-21 8:36 ` ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Add code to accept valid locked WOPCM register values Patchwork
2018-03-22 20:38 ` [PATCH 1/2] " Michał Winiarski
2 siblings, 0 replies; 17+ messages in thread
From: Jackie Li @ 2018-03-20 23:18 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 c963603..53037b5 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@ struct drm_printer;
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] 17+ messages in thread
* ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Add code to accept valid locked WOPCM register values
2018-03-20 23:18 [PATCH 1/2] drm/i915: Add code to accept valid locked WOPCM register values Jackie Li
2018-03-20 23:18 ` [PATCH 2/2] HAX enable guc for CI Jackie Li
@ 2018-03-21 8:36 ` Patchwork
2018-03-22 20:38 ` [PATCH 1/2] " Michał Winiarski
2 siblings, 0 replies; 17+ messages in thread
From: Patchwork @ 2018-03-21 8:36 UTC (permalink / raw)
To: Jackie Li; +Cc: intel-gfx
== Series Details ==
Series: series starting with [1/2] drm/i915: Add code to accept valid locked WOPCM register values
URL : https://patchwork.freedesktop.org/series/40334/
State : warning
== Summary ==
Series 40334v1 series starting with [1/2] drm/i915: Add code to accept valid locked WOPCM register values
https://patchwork.freedesktop.org/api/1.0/series/40334/revisions/1/mbox/
---- Possible new issues:
Test debugfs_test:
Subgroup read_all_entries:
pass -> DMESG-WARN (fi-skl-6700hq)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass -> DMESG-WARN (fi-skl-6700hq)
Subgroup basic-plain-flip:
pass -> DMESG-WARN (fi-skl-6700hq)
---- Known issues:
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass -> FAIL (fi-gdg-551) fdo#102575
Test kms_busy:
Subgroup basic-flip-c:
pass -> DMESG-WARN (fi-skl-6700hq) fdo#101144 +2
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
incomplete -> PASS (fi-cfl-s2) fdo#105641
fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144
fdo#105641 https://bugs.freedesktop.org/show_bug.cgi?id=105641
fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:431s
fi-bdw-gvtdvm total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:438s
fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:380s
fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:543s
fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:296s
fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:511s
fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:514s
fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:521s
fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:503s
fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:412s
fi-cfl-s2 total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:574s
fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:512s
fi-cnl-drrs total:285 pass:254 dwarn:3 dfail:0 fail:0 skip:28 time:525s
fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:425s
fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:313s
fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:537s
fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:409s
fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:419s
fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:472s
fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:442s
fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:482s
fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:462s
fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:511s
fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:650s
fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:440s
fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:531s
fi-skl-6700hq total:285 pass:253 dwarn:6 dfail:0 fail:0 skip:26 time:554s
fi-skl-6700k2 total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:509s
fi-skl-6770hq total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:501s
fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:428s
fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:582s
fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:404s
9d737cebc219c821989021a3115424165ff7b052 drm-tip: 2018y-03m-20d-14h-56m-05s UTC integration manifest
d2157a6a49e8 HAX enable guc for CI
044dd4569e9a drm/i915: Add code to accept valid locked WOPCM register values
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8425/issues.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 1/2] drm/i915: Add code to accept valid locked WOPCM register values
2018-03-20 23:18 [PATCH 1/2] drm/i915: Add code to accept valid locked WOPCM register values Jackie Li
2018-03-20 23:18 ` [PATCH 2/2] HAX enable guc for CI Jackie Li
2018-03-21 8:36 ` ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Add code to accept valid locked WOPCM register values Patchwork
@ 2018-03-22 20:38 ` Michał Winiarski
2018-03-22 21:27 ` Yaodong Li
2 siblings, 1 reply; 17+ messages in thread
From: Michał Winiarski @ 2018-03-22 20:38 UTC (permalink / raw)
To: Jackie Li; +Cc: intel-gfx
On Tue, Mar 20, 2018 at 04:18:46PM -0700, Jackie Li wrote:
> In current code, we only compare the locked WOPCM register values with the
> calculated values. However, we can continue loading GuC/HuC firmware if the
> locked (or partially locked) values were valid for current GuC/HuC firmware
> sizes.
>
> This patch added a new code path to verify whether the locked register
> values can be used for GuC/HuC firmware loading, it will recalculate the
> verify the new values if these registers were partially locked, so that we
> won't fail the GuC/HuC firmware loading even if the locked register values
> are different from the calculated ones.
>
> Signed-off-by: Jackie Li <yaodong.li@intel.com>
> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
> Cc: Michał Winiarski <michal.winiarski@intel.com>
> Cc: John Spotswood <john.a.spotswood@intel.com>
> ---
> drivers/gpu/drm/i915/intel_wopcm.c | 183 +++++++++++++++++++++++++++++++------
> 1 file changed, 157 insertions(+), 26 deletions(-)
[snip]
> /**
> * intel_wopcm_init() - Initialize the WOPCM structure.
> * @wopcm: pointer to intel_wopcm.
> @@ -155,10 +202,8 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
> struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
> u32 guc_fw_size = intel_uc_fw_get_upload_size(&i915->guc.fw);
> u32 huc_fw_size = intel_uc_fw_get_upload_size(&i915->huc.fw);
> - u32 ctx_rsvd = context_reserved_size(i915);
> u32 guc_wopcm_base;
> u32 guc_wopcm_size;
> - u32 guc_wopcm_rsvd;
> int err;
>
> GEM_BUG_ON(!wopcm->size);
> @@ -175,30 +220,17 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
> return -E2BIG;
> }
>
> - guc_wopcm_base = ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
> - GUC_WOPCM_OFFSET_ALIGNMENT);
> - if ((guc_wopcm_base + ctx_rsvd) >= wopcm->size) {
> - DRM_ERROR("GuC WOPCM base (%uKiB) is too big.\n",
> - guc_wopcm_base / 1024);
> - return -E2BIG;
> - }
> -
> - guc_wopcm_size = wopcm->size - guc_wopcm_base - ctx_rsvd;
> - guc_wopcm_size &= GUC_WOPCM_SIZE_MASK;
> + guc_wopcm_base = calculate_min_guc_wopcm_base(huc_fw_size);
We already discussed this elsewhere, but just to have this part available
for wider audience:
huc_fw_size is unknown (there may be no huc firmware present) - which means
we're still not able to handle module reload from guc-without-huc into
guc-with-huc
Question remains whether we want to support this scenario, or whether we should
tie GuC and HuC together and refuse to operate early on if either one is not
present. We could remove a lot of code this way...
> + err = calculate_max_guc_wopcm_size(wopcm, guc_wopcm_base,
> + &guc_wopcm_size);
> + if (err)
> + return err;
>
> DRM_DEBUG_DRIVER("Calculated GuC WOPCM Region: [%uKiB, %uKiB)\n",
> guc_wopcm_base / 1024, guc_wopcm_size / 1024);
>
> - guc_wopcm_rsvd = GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED;
> - if ((guc_fw_size + guc_wopcm_rsvd) > guc_wopcm_size) {
> - DRM_ERROR("Need %uKiB WOPCM for GuC, %uKiB available.\n",
> - (guc_fw_size + guc_wopcm_rsvd) / 1024,
> - guc_wopcm_size / 1024);
> - return -E2BIG;
> - }
> -
> - err = check_hw_restriction(i915, guc_wopcm_base, guc_wopcm_size,
> - huc_fw_size);
> + err = verify_calculated_values(i915, guc_fw_size, huc_fw_size,
> + guc_wopcm_base, guc_wopcm_size);
Ok - so we're calculating the values in init...
> if (err)
> return err;
>
> @@ -208,6 +240,92 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
> return 0;
> }
>
[snip]
> static inline int write_and_verify(struct drm_i915_private *dev_priv,
> i915_reg_t reg, u32 val, u32 mask,
> u32 locked_bit)
> @@ -231,7 +349,8 @@ static inline int write_and_verify(struct drm_i915_private *dev_priv,
> * will verify the register values to make sure the registers are locked with
> * correct values.
> *
> - * Return: 0 on success. -EIO if registers were locked with incorrect values.
> + * Return: 0 on success. Minus error code if registered were locked with
> + * incorrect values.-EIO if registers failed to lock with correct values.
> */
> int intel_wopcm_init_hw(struct intel_wopcm *wopcm)
> {
> @@ -247,27 +366,39 @@ int intel_wopcm_init_hw(struct intel_wopcm *wopcm)
> GEM_BUG_ON(!wopcm->guc.size);
> GEM_BUG_ON(!wopcm->guc.base);
>
> + err = verify_locked_values_and_update(wopcm);
> + if (err) {
> + DRM_ERROR("WOPCM registers are locked with invalid values.\n");
> + goto err_out;
> + }
> +
...Only to throw everything out if the regs are locked in init_hw?
Since we've changed the logic, I think we should refactor a bit by changing
the ordering.
We could start from checking the regs and partition ourselves if the values are
not locked.
We can then have a common codepath for verification.
> err = write_and_verify(dev_priv, GUC_WOPCM_SIZE, wopcm->guc.size,
> GUC_WOPCM_SIZE_MASK | GUC_WOPCM_SIZE_LOCKED,
> GUC_WOPCM_SIZE_LOCKED);
> - if (err)
> + if (err) {
> + DRM_ERROR("Failed to lock GUC_WOPCM_SIZE with %#x.\n",
> + wopcm->guc.size);
> goto err_out;
> + }
>
> huc_agent = USES_HUC(dev_priv) ? HUC_LOADING_AGENT_GUC : 0;
> mask = GUC_WOPCM_OFFSET_MASK | GUC_WOPCM_OFFSET_VALID | huc_agent;
> err = write_and_verify(dev_priv, DMA_GUC_WOPCM_OFFSET,
> wopcm->guc.base | huc_agent, mask,
> GUC_WOPCM_OFFSET_VALID);
> - if (err)
> + if (err) {
> + DRM_ERROR("Failed to lock DMA_GUC_WOPCM_OFFSET with %#x.\n",
> + wopcm->guc.base);
> goto err_out;
> + }
>
> return 0;
>
> err_out:
> - DRM_ERROR("Failed to init WOPCM registers:\n");
> DRM_ERROR("DMA_GUC_WOPCM_OFFSET=%#x\n",
> I915_READ(DMA_GUC_WOPCM_OFFSET));
> DRM_ERROR("GUC_WOPCM_SIZE=%#x\n", I915_READ(GUC_WOPCM_SIZE));
> + DRM_ERROR("A system reboot is required.\n");
Functionally I think it's a step in the right direction, but I think we should
try even harder to not ever display this error msg.
-Michał
>
> return err;
> }
> --
> 2.7.4
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 1/2] drm/i915: Add code to accept valid locked WOPCM register values
2018-03-22 20:38 ` [PATCH 1/2] " Michał Winiarski
@ 2018-03-22 21:27 ` Yaodong Li
2018-03-23 14:01 ` Michał Winiarski
2018-03-23 14:02 ` Joonas Lahtinen
0 siblings, 2 replies; 17+ messages in thread
From: Yaodong Li @ 2018-03-22 21:27 UTC (permalink / raw)
To: Michał Winiarski; +Cc: intel-gfx
On 03/22/2018 01:38 PM, Michał Winiarski wrote:
> On Tue, Mar 20, 2018 at 04:18:46PM -0700, Jackie Li wrote:
>> In current code, we only compare the locked WOPCM register values with the
>> calculated values. However, we can continue loading GuC/HuC firmware if the
>> locked (or partially locked) values were valid for current GuC/HuC firmware
>> sizes.
>>
>> This patch added a new code path to verify whether the locked register
>> values can be used for GuC/HuC firmware loading, it will recalculate the
>> verify the new values if these registers were partially locked, so that we
>> won't fail the GuC/HuC firmware loading even if the locked register values
>> are different from the calculated ones.
>>
>> Signed-off-by: Jackie Li <yaodong.li@intel.com>
>> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
>> Cc: Michał Winiarski <michal.winiarski@intel.com>
>> Cc: John Spotswood <john.a.spotswood@intel.com>
>> ---
>> drivers/gpu/drm/i915/intel_wopcm.c | 183 +++++++++++++++++++++++++++++++------
>> 1 file changed, 157 insertions(+), 26 deletions(-)
> [snip]
>
>> /**
>> * intel_wopcm_init() - Initialize the WOPCM structure.
>> * @wopcm: pointer to intel_wopcm.
>> @@ -155,10 +202,8 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
>> struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
>> u32 guc_fw_size = intel_uc_fw_get_upload_size(&i915->guc.fw);
>> u32 huc_fw_size = intel_uc_fw_get_upload_size(&i915->huc.fw);
>> - u32 ctx_rsvd = context_reserved_size(i915);
>> u32 guc_wopcm_base;
>> u32 guc_wopcm_size;
>> - u32 guc_wopcm_rsvd;
>> int err;
>>
>> GEM_BUG_ON(!wopcm->size);
>> @@ -175,30 +220,17 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
>> return -E2BIG;
>> }
>>
>> - guc_wopcm_base = ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
>> - GUC_WOPCM_OFFSET_ALIGNMENT);
>> - if ((guc_wopcm_base + ctx_rsvd) >= wopcm->size) {
>> - DRM_ERROR("GuC WOPCM base (%uKiB) is too big.\n",
>> - guc_wopcm_base / 1024);
>> - return -E2BIG;
>> - }
>> -
>> - guc_wopcm_size = wopcm->size - guc_wopcm_base - ctx_rsvd;
>> - guc_wopcm_size &= GUC_WOPCM_SIZE_MASK;
>> + guc_wopcm_base = calculate_min_guc_wopcm_base(huc_fw_size);
> We already discussed this elsewhere, but just to have this part available
> for wider audience:
>
> huc_fw_size is unknown (there may be no huc firmware present) - which means
> we're still not able to handle module reload from guc-without-huc into
> guc-with-huc
>
> Question remains whether we want to support this scenario, or whether we should
> tie GuC and HuC together and refuse to operate early on if either one is not
> present. We could remove a lot of code this way...
Thanks. As we discussed I think we should describe this problem in this way:
we shall not make any assumption on either guc_fw_size and huc_fw_size.
On the other handle, we do need calculate the WOPCM layout based on
both GuC and HuC FW sizes, especially when we want to support modparam
enable_guc to enable/disable HuC FW loading dynamically. That's why I
suggest
to update the FW fetch code to report the FW size no matter we turn the HuC
FW loading on or not.
Other aspect of the discussion is whether we should support enable_guc
switching
from 1 to 3 + Adding new HuC FW to the filesystem without a system reboot.
In another word whether we should support FW image updates
(add/delete/update to a new version) in the filesystem without expecting
a system
reboot. My point is it's unlikely we can support this since the FW sizes
would likely
change and we need reconfigure the WO register with the latest FW
available in
the FS, and I think it worth to do it to 100% make sure we won't run
into any
module loading/init errors.
>
>> + err = calculate_max_guc_wopcm_size(wopcm, guc_wopcm_base,
>> + &guc_wopcm_size);
>> + if (err)
>> + return err;
>>
>> DRM_DEBUG_DRIVER("Calculated GuC WOPCM Region: [%uKiB, %uKiB)\n",
>> guc_wopcm_base / 1024, guc_wopcm_size / 1024);
>>
>> - guc_wopcm_rsvd = GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED;
>> - if ((guc_fw_size + guc_wopcm_rsvd) > guc_wopcm_size) {
>> - DRM_ERROR("Need %uKiB WOPCM for GuC, %uKiB available.\n",
>> - (guc_fw_size + guc_wopcm_rsvd) / 1024,
>> - guc_wopcm_size / 1024);
>> - return -E2BIG;
>> - }
>> -
>> - err = check_hw_restriction(i915, guc_wopcm_base, guc_wopcm_size,
>> - huc_fw_size);
>> + err = verify_calculated_values(i915, guc_fw_size, huc_fw_size,
>> + guc_wopcm_base, guc_wopcm_size);
> Ok - so we're calculating the values in init...
Most likely case, we are going to get these values ready without getting
any forcewake during the init. Then in init_hw we only need to update
these values to the register without wasting anytime on these calculation.
However, this patch introduce more code to handle the rare cases which
these regs were locked with different values from the ones we calculated
in the init phase. In this case, we will try to recalculate/verify these
locked
or partially locked values and try our best to go with the locked values.
>
>> if (err)
>> return err;
>>
>> @@ -208,6 +240,92 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
>> return 0;
>> }
>>
> [snip]
>
>> static inline int write_and_verify(struct drm_i915_private *dev_priv,
>> i915_reg_t reg, u32 val, u32 mask,
>> u32 locked_bit)
>> @@ -231,7 +349,8 @@ static inline int write_and_verify(struct drm_i915_private *dev_priv,
>> * will verify the register values to make sure the registers are locked with
>> * correct values.
>> *
>> - * Return: 0 on success. -EIO if registers were locked with incorrect values.
>> + * Return: 0 on success. Minus error code if registered were locked with
>> + * incorrect values.-EIO if registers failed to lock with correct values.
>> */
>> int intel_wopcm_init_hw(struct intel_wopcm *wopcm)
>> {
>> @@ -247,27 +366,39 @@ int intel_wopcm_init_hw(struct intel_wopcm *wopcm)
>> GEM_BUG_ON(!wopcm->guc.size);
>> GEM_BUG_ON(!wopcm->guc.base);
>>
>> + err = verify_locked_values_and_update(wopcm);
>> + if (err) {
>> + DRM_ERROR("WOPCM registers are locked with invalid values.\n");
>> + goto err_out;
>> + }
>> +
> ...Only to throw everything out if the regs are locked in init_hw?
>
> Since we've changed the logic, I think we should refactor a bit by changing
> the ordering.
> We could start from checking the regs and partition ourselves if the values are
> not locked.
>
> We can then have a common codepath for verification.
We have power domain on at this point so we expect to spend as less
time as possible here. We are expecting the regs were not locked or
locked with the same values as we calculated (e.g. module reloading,
reset, etc) in most case. But for some rare cases (BIOS did upload the
regs) we will have this new path to handle those cases. But these are
all abnormal cases and even should not happen.
>
>> err = write_and_verify(dev_priv, GUC_WOPCM_SIZE, wopcm->guc.size,
>> GUC_WOPCM_SIZE_MASK | GUC_WOPCM_SIZE_LOCKED,
>> GUC_WOPCM_SIZE_LOCKED);
Actually, I think we shall decide whether updating the reg based on the
locking status. Will handle it in v2:)
>> - if (err)
>> + if (err) {
>> + DRM_ERROR("Failed to lock GUC_WOPCM_SIZE with %#x.\n",
>> + wopcm->guc.size);
>> goto err_out;
>> + }
>>
>> huc_agent = USES_HUC(dev_priv) ? HUC_LOADING_AGENT_GUC : 0;
>> mask = GUC_WOPCM_OFFSET_MASK | GUC_WOPCM_OFFSET_VALID | huc_agent;
>> err = write_and_verify(dev_priv, DMA_GUC_WOPCM_OFFSET,
>> wopcm->guc.base | huc_agent, mask,
>> GUC_WOPCM_OFFSET_VALID);
>> - if (err)
>> + if (err) {
>> + DRM_ERROR("Failed to lock DMA_GUC_WOPCM_OFFSET with %#x.\n",
>> + wopcm->guc.base);
>> goto err_out;
>> + }
>>
>> return 0;
>>
>> err_out:
>> - DRM_ERROR("Failed to init WOPCM registers:\n");
>> DRM_ERROR("DMA_GUC_WOPCM_OFFSET=%#x\n",
>> I915_READ(DMA_GUC_WOPCM_OFFSET));
>> DRM_ERROR("GUC_WOPCM_SIZE=%#x\n", I915_READ(GUC_WOPCM_SIZE));
>> + DRM_ERROR("A system reboot is required.\n");
> Functionally I think it's a step in the right direction, but I think we should
> try even harder to not ever display this error msg.
It shall be very very unlikely if we had clear system configure and FW
update sequence. However, we are still expecting such an error. (e.g.
Updated
FW images (with larger sizes) and try to load the new FW without a reboot.
we cannot 100% guarantee the correctness since the WOPCM layout is
locked with
values we calculated based on the old FW status in the FS, thus we will
report such an error
message.
Regards,
-Jackie
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 1/2] drm/i915: Add code to accept valid locked WOPCM register values
2018-03-22 21:27 ` Yaodong Li
@ 2018-03-23 14:01 ` Michał Winiarski
2018-03-23 17:33 ` Yaodong Li
2018-03-23 14:02 ` Joonas Lahtinen
1 sibling, 1 reply; 17+ messages in thread
From: Michał Winiarski @ 2018-03-23 14:01 UTC (permalink / raw)
To: Yaodong Li; +Cc: intel-gfx
On Thu, Mar 22, 2018 at 02:27:59PM -0700, Yaodong Li wrote:
> On 03/22/2018 01:38 PM, Michał Winiarski wrote:
> > On Tue, Mar 20, 2018 at 04:18:46PM -0700, Jackie Li wrote:
> > > In current code, we only compare the locked WOPCM register values with the
> > > calculated values. However, we can continue loading GuC/HuC firmware if the
> > > locked (or partially locked) values were valid for current GuC/HuC firmware
> > > sizes.
> > >
> > > This patch added a new code path to verify whether the locked register
> > > values can be used for GuC/HuC firmware loading, it will recalculate the
> > > verify the new values if these registers were partially locked, so that we
> > > won't fail the GuC/HuC firmware loading even if the locked register values
> > > are different from the calculated ones.
> > >
> > > Signed-off-by: Jackie Li <yaodong.li@intel.com>
> > > Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> > > Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
> > > Cc: Michał Winiarski <michal.winiarski@intel.com>
> > > Cc: John Spotswood <john.a.spotswood@intel.com>
> > > ---
> > > drivers/gpu/drm/i915/intel_wopcm.c | 183 +++++++++++++++++++++++++++++++------
> > > 1 file changed, 157 insertions(+), 26 deletions(-)
> > [snip]
> >
> > > /**
> > > * intel_wopcm_init() - Initialize the WOPCM structure.
> > > * @wopcm: pointer to intel_wopcm.
> > > @@ -155,10 +202,8 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
> > > struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
> > > u32 guc_fw_size = intel_uc_fw_get_upload_size(&i915->guc.fw);
> > > u32 huc_fw_size = intel_uc_fw_get_upload_size(&i915->huc.fw);
> > > - u32 ctx_rsvd = context_reserved_size(i915);
> > > u32 guc_wopcm_base;
> > > u32 guc_wopcm_size;
> > > - u32 guc_wopcm_rsvd;
> > > int err;
> > > GEM_BUG_ON(!wopcm->size);
> > > @@ -175,30 +220,17 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
> > > return -E2BIG;
> > > }
> > > - guc_wopcm_base = ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
> > > - GUC_WOPCM_OFFSET_ALIGNMENT);
> > > - if ((guc_wopcm_base + ctx_rsvd) >= wopcm->size) {
> > > - DRM_ERROR("GuC WOPCM base (%uKiB) is too big.\n",
> > > - guc_wopcm_base / 1024);
> > > - return -E2BIG;
> > > - }
> > > -
> > > - guc_wopcm_size = wopcm->size - guc_wopcm_base - ctx_rsvd;
> > > - guc_wopcm_size &= GUC_WOPCM_SIZE_MASK;
> > > + guc_wopcm_base = calculate_min_guc_wopcm_base(huc_fw_size);
> > We already discussed this elsewhere, but just to have this part available
> > for wider audience:
> >
> > huc_fw_size is unknown (there may be no huc firmware present) - which means
> > we're still not able to handle module reload from guc-without-huc into
> > guc-with-huc
> >
> > Question remains whether we want to support this scenario, or whether we should
> > tie GuC and HuC together and refuse to operate early on if either one is not
> > present. We could remove a lot of code this way...
> Thanks. As we discussed I think we should describe this problem in this way:
> we shall not make any assumption on either guc_fw_size and huc_fw_size.
We can make assumptions on guc_fw_size - it's known in all the relevant cases
(enable_guc=1,2,3).
(unless we want to support varying guc_fw_size - more on that later).
> On the other handle, we do need calculate the WOPCM layout based on
> both GuC and HuC FW sizes, especially when we want to support modparam
> enable_guc to enable/disable HuC FW loading dynamically. That's why I
> suggest
> to update the FW fetch code to report the FW size no matter we turn the HuC
> FW loading on or not.
We could do that, but we don't really *need* to do that.
If user doesn't want HuC, why are we reading HuC from the filesystem? (well,
because we decided we're going to base our paritioning around it).
> Other aspect of the discussion is whether we should support enable_guc
> switching
> from 1 to 3 + Adding new HuC FW to the filesystem without a system reboot.
> In another word whether we should support FW image updates
> (add/delete/update to a new version) in the filesystem without expecting a
> system
> reboot. My point is it's unlikely we can support this since the FW sizes
> would likely
> change and we need reconfigure the WO register with the latest FW available
> in
> the FS, and I think it worth to do it to 100% make sure we won't run into
> any
> module loading/init errors.
It's never going to be 100%, but we can at least try to work with 99% ;)
The only reason why you need HuC size is because you're building the
partitioning from the bottom (starting from HuC).
We could just as well start from the top (starting from GuC).
The only thing you gain by starting from the bottom, is that you're much more
tolerant for variations in GuC fw size (because you're paritioning HuC region
precisely, leaving the rest for GuC. Well, that, and the HW workaround).
The only thing that changes when you're starting from the top, is that you're
going the other way around (more tolerant for HuC fw size variations).
I just posted a series that (among other things) tries to do partitioning from
the top.
To make it more tolerant for size variations, we could reserve a little extra
(either for GuC or HuC, depending on the approach).
-Michał
> >
> > > + err = calculate_max_guc_wopcm_size(wopcm, guc_wopcm_base,
> > > + &guc_wopcm_size);
> > > + if (err)
> > > + return err;
> > > DRM_DEBUG_DRIVER("Calculated GuC WOPCM Region: [%uKiB, %uKiB)\n",
> > > guc_wopcm_base / 1024, guc_wopcm_size / 1024);
> > > - guc_wopcm_rsvd = GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED;
> > > - if ((guc_fw_size + guc_wopcm_rsvd) > guc_wopcm_size) {
> > > - DRM_ERROR("Need %uKiB WOPCM for GuC, %uKiB available.\n",
> > > - (guc_fw_size + guc_wopcm_rsvd) / 1024,
> > > - guc_wopcm_size / 1024);
> > > - return -E2BIG;
> > > - }
> > > -
> > > - err = check_hw_restriction(i915, guc_wopcm_base, guc_wopcm_size,
> > > - huc_fw_size);
> > > + err = verify_calculated_values(i915, guc_fw_size, huc_fw_size,
> > > + guc_wopcm_base, guc_wopcm_size);
> > Ok - so we're calculating the values in init...
> Most likely case, we are going to get these values ready without getting
> any forcewake during the init. Then in init_hw we only need to update
> these values to the register without wasting anytime on these calculation.
> However, this patch introduce more code to handle the rare cases which
> these regs were locked with different values from the ones we calculated
> in the init phase. In this case, we will try to recalculate/verify these
> locked
> or partially locked values and try our best to go with the locked values.
> >
> > > if (err)
> > > return err;
> > > @@ -208,6 +240,92 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
> > > return 0;
> > > }
> > [snip]
> >
> > > static inline int write_and_verify(struct drm_i915_private *dev_priv,
> > > i915_reg_t reg, u32 val, u32 mask,
> > > u32 locked_bit)
> > > @@ -231,7 +349,8 @@ static inline int write_and_verify(struct drm_i915_private *dev_priv,
> > > * will verify the register values to make sure the registers are locked with
> > > * correct values.
> > > *
> > > - * Return: 0 on success. -EIO if registers were locked with incorrect values.
> > > + * Return: 0 on success. Minus error code if registered were locked with
> > > + * incorrect values.-EIO if registers failed to lock with correct values.
> > > */
> > > int intel_wopcm_init_hw(struct intel_wopcm *wopcm)
> > > {
> > > @@ -247,27 +366,39 @@ int intel_wopcm_init_hw(struct intel_wopcm *wopcm)
> > > GEM_BUG_ON(!wopcm->guc.size);
> > > GEM_BUG_ON(!wopcm->guc.base);
> > > + err = verify_locked_values_and_update(wopcm);
> > > + if (err) {
> > > + DRM_ERROR("WOPCM registers are locked with invalid values.\n");
> > > + goto err_out;
> > > + }
> > > +
> > ...Only to throw everything out if the regs are locked in init_hw?
> >
> > Since we've changed the logic, I think we should refactor a bit by changing
> > the ordering.
> > We could start from checking the regs and partition ourselves if the values are
> > not locked.
> >
> > We can then have a common codepath for verification.
> We have power domain on at this point so we expect to spend as less
> time as possible here. We are expecting the regs were not locked or
> locked with the same values as we calculated (e.g. module reloading,
> reset, etc) in most case. But for some rare cases (BIOS did upload the
> regs) we will have this new path to handle those cases. But these are
> all abnormal cases and even should not happen.
> >
> > > err = write_and_verify(dev_priv, GUC_WOPCM_SIZE, wopcm->guc.size,
> > > GUC_WOPCM_SIZE_MASK | GUC_WOPCM_SIZE_LOCKED,
> > > GUC_WOPCM_SIZE_LOCKED);
> Actually, I think we shall decide whether updating the reg based on the
> locking status. Will handle it in v2:)
> > > - if (err)
> > > + if (err) {
> > > + DRM_ERROR("Failed to lock GUC_WOPCM_SIZE with %#x.\n",
> > > + wopcm->guc.size);
> > > goto err_out;
> > > + }
> > > huc_agent = USES_HUC(dev_priv) ? HUC_LOADING_AGENT_GUC : 0;
> > > mask = GUC_WOPCM_OFFSET_MASK | GUC_WOPCM_OFFSET_VALID | huc_agent;
> > > err = write_and_verify(dev_priv, DMA_GUC_WOPCM_OFFSET,
> > > wopcm->guc.base | huc_agent, mask,
> > > GUC_WOPCM_OFFSET_VALID);
> > > - if (err)
> > > + if (err) {
> > > + DRM_ERROR("Failed to lock DMA_GUC_WOPCM_OFFSET with %#x.\n",
> > > + wopcm->guc.base);
> > > goto err_out;
> > > + }
> > > return 0;
> > > err_out:
> > > - DRM_ERROR("Failed to init WOPCM registers:\n");
> > > DRM_ERROR("DMA_GUC_WOPCM_OFFSET=%#x\n",
> > > I915_READ(DMA_GUC_WOPCM_OFFSET));
> > > DRM_ERROR("GUC_WOPCM_SIZE=%#x\n", I915_READ(GUC_WOPCM_SIZE));
> > > + DRM_ERROR("A system reboot is required.\n");
> > Functionally I think it's a step in the right direction, but I think we should
> > try even harder to not ever display this error msg.
> It shall be very very unlikely if we had clear system configure and FW
> update sequence. However, we are still expecting such an error. (e.g.
> Updated
> FW images (with larger sizes) and try to load the new FW without a reboot.
> we cannot 100% guarantee the correctness since the WOPCM layout is locked
> with
> values we calculated based on the old FW status in the FS, thus we will
> report such an error
> message.
>
> Regards,
> -Jackie
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 1/2] drm/i915: Add code to accept valid locked WOPCM register values
2018-03-23 14:01 ` Michał Winiarski
@ 2018-03-23 17:33 ` Yaodong Li
2018-03-26 7:15 ` Joonas Lahtinen
0 siblings, 1 reply; 17+ messages in thread
From: Yaodong Li @ 2018-03-23 17:33 UTC (permalink / raw)
To: Michał Winiarski; +Cc: intel-gfx
On 03/23/2018 07:01 AM, Michał Winiarski wrote:
> On Thu, Mar 22, 2018 at 02:27:59PM -0700, Yaodong Li wrote:
>> On 03/22/2018 01:38 PM, Michał Winiarski wrote:
>>> On Tue, Mar 20, 2018 at 04:18:46PM -0700, Jackie Li wrote:
>>>> In current code, we only compare the locked WOPCM register values with the
>>>> calculated values. However, we can continue loading GuC/HuC firmware if the
>>>> locked (or partially locked) values were valid for current GuC/HuC firmware
>>>> sizes.
>>>>
>>>> This patch added a new code path to verify whether the locked register
>>>> values can be used for GuC/HuC firmware loading, it will recalculate the
>>>> verify the new values if these registers were partially locked, so that we
>>>> won't fail the GuC/HuC firmware loading even if the locked register values
>>>> are different from the calculated ones.
>>>>
>>>> Signed-off-by: Jackie Li <yaodong.li@intel.com>
>>>> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>>> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
>>>> Cc: Michał Winiarski <michal.winiarski@intel.com>
>>>> Cc: John Spotswood <john.a.spotswood@intel.com>
>>>> ---
>>>> drivers/gpu/drm/i915/intel_wopcm.c | 183 +++++++++++++++++++++++++++++++------
>>>> 1 file changed, 157 insertions(+), 26 deletions(-)
>>> [snip]
>>>
>>>> /**
>>>> * intel_wopcm_init() - Initialize the WOPCM structure.
>>>> * @wopcm: pointer to intel_wopcm.
>>>> @@ -155,10 +202,8 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
>>>> struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
>>>> u32 guc_fw_size = intel_uc_fw_get_upload_size(&i915->guc.fw);
>>>> u32 huc_fw_size = intel_uc_fw_get_upload_size(&i915->huc.fw);
>>>> - u32 ctx_rsvd = context_reserved_size(i915);
>>>> u32 guc_wopcm_base;
>>>> u32 guc_wopcm_size;
>>>> - u32 guc_wopcm_rsvd;
>>>> int err;
>>>> GEM_BUG_ON(!wopcm->size);
>>>> @@ -175,30 +220,17 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
>>>> return -E2BIG;
>>>> }
>>>> - guc_wopcm_base = ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
>>>> - GUC_WOPCM_OFFSET_ALIGNMENT);
>>>> - if ((guc_wopcm_base + ctx_rsvd) >= wopcm->size) {
>>>> - DRM_ERROR("GuC WOPCM base (%uKiB) is too big.\n",
>>>> - guc_wopcm_base / 1024);
>>>> - return -E2BIG;
>>>> - }
>>>> -
>>>> - guc_wopcm_size = wopcm->size - guc_wopcm_base - ctx_rsvd;
>>>> - guc_wopcm_size &= GUC_WOPCM_SIZE_MASK;
>>>> + guc_wopcm_base = calculate_min_guc_wopcm_base(huc_fw_size);
>>> We already discussed this elsewhere, but just to have this part available
>>> for wider audience:
>>>
>>> huc_fw_size is unknown (there may be no huc firmware present) - which means
>>> we're still not able to handle module reload from guc-without-huc into
>>> guc-with-huc
>>>
>>> Question remains whether we want to support this scenario, or whether we should
>>> tie GuC and HuC together and refuse to operate early on if either one is not
>>> present. We could remove a lot of code this way...
>> Thanks. As we discussed I think we should describe this problem in this way:
>> we shall not make any assumption on either guc_fw_size and huc_fw_size.
> We can make assumptions on guc_fw_size - it's known in all the relevant cases
> (enable_guc=1,2,3).
> (unless we want to support varying guc_fw_size - more on that later).
What I meant is we cannot make any assumption one the actual size
of guc and huc fw:)
>> On the other handle, we do need calculate the WOPCM layout based on
>> both GuC and HuC FW sizes, especially when we want to support modparam
>> enable_guc to enable/disable HuC FW loading dynamically. That's why I
>> suggest
>> to update the FW fetch code to report the FW size no matter we turn the HuC
>> FW loading on or not.
> We could do that, but we don't really *need* to do that.
> If user doesn't want HuC, why are we reading HuC from the filesystem? (well,
> because we decided we're going to base our paritioning around it).
Because of the enable_guc=1 and enable_guc=3 case and the fact
that we only can write to these registers for once + we need to know
the size to 100% make sure we do the partitioning correctly.
please refer to my patch set:
https://patchwork.freedesktop.org/series/40541/
>> Other aspect of the discussion is whether we should support enable_guc
>> switching
>> from 1 to 3 + Adding new HuC FW to the filesystem without a system reboot.
>> In another word whether we should support FW image updates
>> (add/delete/update to a new version) in the filesystem without expecting a
>> system
>> reboot. My point is it's unlikely we can support this since the FW sizes
>> would likely
>> change and we need reconfigure the WO register with the latest FW available
>> in
>> the FS, and I think it worth to do it to 100% make sure we won't run into
>> any
>> module loading/init errors.
> It's never going to be 100%, but we can at least try to work with 99% ;)
With correct FW images, it would be 100%, isn't it?:)
> The only reason why you need HuC size is because you're building the
> partitioning from the bottom (starting from HuC).
> We could just as well start from the top (starting from GuC).
That's right. but either starting from the bottom (based on HuC FW size) or
starting from the top (based on GuC FW size), we are ignoring one fact
is that
the final layout is depended on both GuC and HuC FW sizes.
> The only thing you gain by starting from the bottom, is that you're much more
> tolerant for variations in GuC fw size (because you're paritioning HuC region
> precisely, leaving the rest for GuC. Well, that, and the HW workaround).
We would guarantee we would have maximum guc wopcm size in this
way which will be the most likely way to meet current hw limitations.
and more important it's simper and easier:)
> The only thing that changes when you're starting from the top, is that you're
> going the other way around (more tolerant for HuC fw size variations).
As I said, I agree that we would likely solve the enable_guc=1 then
enable_guc=3 case with these changes which I think this the the only benefit
that we can get from the starting from the top way.
But my point is just like the from the bottom way, you are ignoring the
HuC FW size. e.g. you will need to grow the guc wopcm size for the hw
restrictions.
The problem is currently we do have this restriction on huc fw size v.s.
guc wopcm
size. In you solution, you are actually counting on the assumption that
guc fw size should be large enough so that we can ignore the huc fw size
and expect it still works when we set enable_huc=3. and my answer to
this is yes it will work for the cases that guc fw size is large enough, but
still risky to fail in case of guc fw size < huc_fw_size + 16K. and that
comes
to my point:
why not make life easier and accurate - If we decide to support dynamically
switching on/off huc fw loading and the fact we can get actual FW sizes,
why not drop all these assumptions and fix it in a way that we won't be
bothered by any FW side changes? :)
Regards,
-Jackie
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 1/2] drm/i915: Add code to accept valid locked WOPCM register values
2018-03-23 17:33 ` Yaodong Li
@ 2018-03-26 7:15 ` Joonas Lahtinen
2018-04-03 0:08 ` Yaodong Li
0 siblings, 1 reply; 17+ messages in thread
From: Joonas Lahtinen @ 2018-03-26 7:15 UTC (permalink / raw)
To: Michał Winiarski, Yaodong Li; +Cc: intel-gfx
Quoting Yaodong Li (2018-03-23 19:33:15)
> As I said, I agree that we would likely solve the enable_guc=1 then
> enable_guc=3 case with these changes which I think this the the only benefit
> that we can get from the starting from the top way.
> But my point is just like the from the bottom way, you are ignoring the
> HuC FW size. e.g. you will need to grow the guc wopcm size for the hw
> restrictions.
> The problem is currently we do have this restriction on huc fw size v.s.
> guc wopcm
> size. In you solution, you are actually counting on the assumption that
> guc fw size should be large enough so that we can ignore the huc fw size
> and expect it still works when we set enable_huc=3. and my answer to
> this is yes it will work for the cases that guc fw size is large enough, but
> still risky to fail in case of guc fw size < huc_fw_size + 16K. and that
> comes
> to my point:
> why not make life easier and accurate - If we decide to support dynamically
> switching on/off huc fw loading and the fact we can get actual FW sizes,
> why not drop all these assumptions and fix it in a way that we won't be
> bothered by any FW side changes? :)
Is not the GuC vs. HuC FW size limitation going to be fixed for upcoming
platforms?
My gut instinct would be to partition based only on the enabled FW sizes,
whichever it be. Then just require a reboot if after that partitioning,
changing the parameter causes the FW not to fit.
Loading the FW, and writing its size to HW registers when there is a
kernel command line parameter to disable its use, seems unexpected.
Regards, Joonas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 1/2] drm/i915: Add code to accept valid locked WOPCM register values
2018-03-26 7:15 ` Joonas Lahtinen
@ 2018-04-03 0:08 ` Yaodong Li
0 siblings, 0 replies; 17+ messages in thread
From: Yaodong Li @ 2018-04-03 0:08 UTC (permalink / raw)
To: Joonas Lahtinen, Michał Winiarski; +Cc: intel-gfx
On 03/26/2018 12:15 AM, Joonas Lahtinen wrote:
> Quoting Yaodong Li (2018-03-23 19:33:15)
>> As I said, I agree that we would likely solve the enable_guc=1 then
>> enable_guc=3 case with these changes which I think this the the only benefit
>> that we can get from the starting from the top way.
>> But my point is just like the from the bottom way, you are ignoring the
>> HuC FW size. e.g. you will need to grow the guc wopcm size for the hw
>> restrictions.
>> The problem is currently we do have this restriction on huc fw size v.s.
>> guc wopcm
>> size. In you solution, you are actually counting on the assumption that
>> guc fw size should be large enough so that we can ignore the huc fw size
>> and expect it still works when we set enable_huc=3. and my answer to
>> this is yes it will work for the cases that guc fw size is large enough, but
>> still risky to fail in case of guc fw size < huc_fw_size + 16K. and that
>> comes
>> to my point:
>> why not make life easier and accurate - If we decide to support dynamically
>> switching on/off huc fw loading and the fact we can get actual FW sizes,
>> why not drop all these assumptions and fix it in a way that we won't be
>> bothered by any FW side changes? :)
> Is not the GuC vs. HuC FW size limitation going to be fixed for upcoming
> platforms?
>
> My gut instinct would be to partition based only on the enabled FW sizes,
> whichever it be. Then just require a reboot if after that partitioning,
> changing the parameter causes the FW not to fit.
That's my thought too. I think it makes sense to reboot the system for
any FW updates, especially when we have these write-once registers.
I believe the main reason we wanted to support enable_guc=1 (GuC FW only)
then enable_guc=3 (GuC + HuC FW) without a system reboot is to facilitate
the debugging.
Regards,
-Jackie
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 1/2] drm/i915: Add code to accept valid locked WOPCM register values
2018-03-22 21:27 ` Yaodong Li
2018-03-23 14:01 ` Michał Winiarski
@ 2018-03-23 14:02 ` Joonas Lahtinen
2018-03-23 14:38 ` Michał Winiarski
1 sibling, 1 reply; 17+ messages in thread
From: Joonas Lahtinen @ 2018-03-23 14:02 UTC (permalink / raw)
To: Michał Winiarski, Yaodong Li; +Cc: intel-gfx
Quoting Yaodong Li (2018-03-22 23:27:59)
> On 03/22/2018 01:38 PM, Michał Winiarski wrote:
> > On Tue, Mar 20, 2018 at 04:18:46PM -0700, Jackie Li wrote:
> >> @@ -175,30 +220,17 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
> >> return -E2BIG;
> >> }
> >>
> >> - guc_wopcm_base = ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
> >> - GUC_WOPCM_OFFSET_ALIGNMENT);
> >> - if ((guc_wopcm_base + ctx_rsvd) >= wopcm->size) {
> >> - DRM_ERROR("GuC WOPCM base (%uKiB) is too big.\n",
> >> - guc_wopcm_base / 1024);
> >> - return -E2BIG;
> >> - }
> >> -
> >> - guc_wopcm_size = wopcm->size - guc_wopcm_base - ctx_rsvd;
> >> - guc_wopcm_size &= GUC_WOPCM_SIZE_MASK;
> >> + guc_wopcm_base = calculate_min_guc_wopcm_base(huc_fw_size);
> > We already discussed this elsewhere, but just to have this part available
> > for wider audience:
> >
> > huc_fw_size is unknown (there may be no huc firmware present) - which means
> > we're still not able to handle module reload from guc-without-huc into
> > guc-with-huc
> >
> > Question remains whether we want to support this scenario, or whether we should
> > tie GuC and HuC together and refuse to operate early on if either one is not
> > present. We could remove a lot of code this way...
> Thanks. As we discussed I think we should describe this problem in this way:
> we shall not make any assumption on either guc_fw_size and huc_fw_size.
> On the other handle, we do need calculate the WOPCM layout based on
> both GuC and HuC FW sizes, especially when we want to support modparam
> enable_guc to enable/disable HuC FW loading dynamically. That's why I
> suggest
> to update the FW fetch code to report the FW size no matter we turn the HuC
> FW loading on or not.
> Other aspect of the discussion is whether we should support enable_guc
> switching
> from 1 to 3 + Adding new HuC FW to the filesystem without a system reboot.
> In another word whether we should support FW image updates
> (add/delete/update to a new version) in the filesystem without expecting
> a system
> reboot. My point is it's unlikely we can support this since the FW sizes
> would likely
> change and we need reconfigure the WO register with the latest FW
> available in
> the FS, and I think it worth to do it to 100% make sure we won't run
> into any
> module loading/init errors.
Did we ask the HW team about this? Surely the intention can't be to both
support dynamic enable/disable but yet having a write-once variable holding
the configuration?
Also, somebody mentioned that these were locked already before loading
i915, so if the firmware sizes have to do with the configuration, how
could that be? We'd have to match BIOS/whatever firmware, and that's not
likely to happen, is it.
Regards, Joonas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 1/2] drm/i915: Add code to accept valid locked WOPCM register values
2018-03-23 14:02 ` Joonas Lahtinen
@ 2018-03-23 14:38 ` Michał Winiarski
0 siblings, 0 replies; 17+ messages in thread
From: Michał Winiarski @ 2018-03-23 14:38 UTC (permalink / raw)
To: Joonas Lahtinen; +Cc: intel-gfx
On Fri, Mar 23, 2018 at 04:02:47PM +0200, Joonas Lahtinen wrote:
> Quoting Yaodong Li (2018-03-22 23:27:59)
> > On 03/22/2018 01:38 PM, Michał Winiarski wrote:
> > > On Tue, Mar 20, 2018 at 04:18:46PM -0700, Jackie Li wrote:
> > >> @@ -175,30 +220,17 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
> > >> return -E2BIG;
> > >> }
> > >>
> > >> - guc_wopcm_base = ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
> > >> - GUC_WOPCM_OFFSET_ALIGNMENT);
> > >> - if ((guc_wopcm_base + ctx_rsvd) >= wopcm->size) {
> > >> - DRM_ERROR("GuC WOPCM base (%uKiB) is too big.\n",
> > >> - guc_wopcm_base / 1024);
> > >> - return -E2BIG;
> > >> - }
> > >> -
> > >> - guc_wopcm_size = wopcm->size - guc_wopcm_base - ctx_rsvd;
> > >> - guc_wopcm_size &= GUC_WOPCM_SIZE_MASK;
> > >> + guc_wopcm_base = calculate_min_guc_wopcm_base(huc_fw_size);
> > > We already discussed this elsewhere, but just to have this part available
> > > for wider audience:
> > >
> > > huc_fw_size is unknown (there may be no huc firmware present) - which means
> > > we're still not able to handle module reload from guc-without-huc into
> > > guc-with-huc
> > >
> > > Question remains whether we want to support this scenario, or whether we should
> > > tie GuC and HuC together and refuse to operate early on if either one is not
> > > present. We could remove a lot of code this way...
> > Thanks. As we discussed I think we should describe this problem in this way:
> > we shall not make any assumption on either guc_fw_size and huc_fw_size.
> > On the other handle, we do need calculate the WOPCM layout based on
> > both GuC and HuC FW sizes, especially when we want to support modparam
> > enable_guc to enable/disable HuC FW loading dynamically. That's why I
> > suggest
> > to update the FW fetch code to report the FW size no matter we turn the HuC
> > FW loading on or not.
> > Other aspect of the discussion is whether we should support enable_guc
> > switching
> > from 1 to 3 + Adding new HuC FW to the filesystem without a system reboot.
> > In another word whether we should support FW image updates
> > (add/delete/update to a new version) in the filesystem without expecting
> > a system
> > reboot. My point is it's unlikely we can support this since the FW sizes
> > would likely
> > change and we need reconfigure the WO register with the latest FW
> > available in
> > the FS, and I think it worth to do it to 100% make sure we won't run
> > into any
> > module loading/init errors.
>
> Did we ask the HW team about this? Surely the intention can't be to both
> support dynamic enable/disable but yet having a write-once variable holding
> the configuration?
>
> Also, somebody mentioned that these were locked already before loading
> i915, so if the firmware sizes have to do with the configuration, how
> could that be? We'd have to match BIOS/whatever firmware, and that's not
> likely to happen, is it.
That was me, and that was an error in my environment. We expect to see unlocked
regs on reboot. And even if we don't (e.g. because it's a module reload), trying
to fit isn't really that hard to do (we're reusing most of the code), so I
believe this is the right approach.
-Michał
> Regards, Joonas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH 1/2] drm/i915/guc: Limit number of scratch registers used for H2G
@ 2018-10-16 9:42 Michal Wajdeczko
2018-10-16 9:42 ` [PATCH 2/2] HAX enable GuC for CI Michal Wajdeczko
0 siblings, 1 reply; 17+ messages in thread
From: Michal Wajdeczko @ 2018-10-16 9:42 UTC (permalink / raw)
To: intel-gfx
We wrongly assumed that GuC is only using last scratch register
for G2H messages, but in fact it is also using register [14] to
report sleep state status. Remove that register from our H2G
send registers pool.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/intel_guc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 230aea6..34927d4e 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -50,7 +50,7 @@ void intel_guc_init_send_regs(struct intel_guc *guc)
unsigned int i;
guc->send_regs.base = i915_mmio_reg_offset(SOFT_SCRATCH(0));
- guc->send_regs.count = SOFT_SCRATCH_COUNT - 1;
+ guc->send_regs.count = SOFT_SCRATCH_COUNT - 2;
for (i = 0; i < guc->send_regs.count; i++) {
fw_domains |= intel_uncore_forcewake_for_reg(dev_priv,
--
1.9.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH 2/2] HAX enable GuC for CI
2018-10-16 9:42 [PATCH 1/2] drm/i915/guc: Limit number of scratch registers used for H2G Michal Wajdeczko
@ 2018-10-16 9:42 ` Michal Wajdeczko
0 siblings, 0 replies; 17+ messages in thread
From: Michal Wajdeczko @ 2018-10-16 9:42 UTC (permalink / raw)
To: intel-gfx
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@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 7e56c51..c681537 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) \
--
1.9.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH 1/2] drm/i915/guc: Fix Gen9 GuC loading workarounds
@ 2018-10-16 8:59 Michal Wajdeczko
2018-10-16 8:59 ` [PATCH 2/2] HAX enable GuC for CI Michal Wajdeczko
0 siblings, 1 reply; 17+ messages in thread
From: Michal Wajdeczko @ 2018-10-16 8:59 UTC (permalink / raw)
To: intel-gfx
In commit 4502e9ec820d ("drm/i915/uc: Unify firmware loading") we
stopped converting errors detected during firmware transfer into
-EAGAIN and this indirectly killed our workarounds for Gen9 GuC.
Reactivate those workarounds by looking for actual -ETIMEDOUT error.
Testcase: igt@drv_selftest@live_hangcheck
Reported-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
References: commit 4502e9ec820d ("drm/i915/uc: Unify firmware loading")
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/intel_uc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index b1b3e81..b34c318 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -376,7 +376,7 @@ int intel_uc_init_hw(struct drm_i915_private *i915)
intel_guc_init_params(guc);
ret = intel_guc_fw_upload(guc);
- if (ret == 0 || ret != -EAGAIN)
+ if (ret == 0 || ret != -ETIMEDOUT)
break;
DRM_DEBUG_DRIVER("GuC fw load failed: %d; will reset and "
--
1.9.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH 2/2] HAX enable GuC for CI
2018-10-16 8:59 [PATCH 1/2] drm/i915/guc: Fix Gen9 GuC loading workarounds Michal Wajdeczko
@ 2018-10-16 8:59 ` Michal Wajdeczko
0 siblings, 0 replies; 17+ messages in thread
From: Michal Wajdeczko @ 2018-10-16 8:59 UTC (permalink / raw)
To: intel-gfx
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@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 7e56c51..c681537 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) \
--
1.9.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH 1/2] drm/i915/guc: fix GuC suspend/resume
@ 2018-10-15 22:10 Daniele Ceraolo Spurio
2018-10-15 22:10 ` [PATCH 2/2] HAX enable GuC for CI Daniele Ceraolo Spurio
0 siblings, 1 reply; 17+ messages in thread
From: Daniele Ceraolo Spurio @ 2018-10-15 22:10 UTC (permalink / raw)
To: intel-gfx
The ENTER/EXIT_S_STATE actions queue the save/restore operation in GuC
FW and then return, so waiting on the H2H is not enough to guarantee
GuC is done.
When all the processing is done, GuC writes 0 to scratch register 14,
so we can poll on that. Note that GuC does not ensure that the value
in the register is different from 0 while the action is in progress
so we need to take care of that ourselves as well.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
---
drivers/gpu/drm/i915/intel_guc.c | 28 +++++++++++++++++++++++++--
drivers/gpu/drm/i915/intel_guc_fwif.h | 6 ++++++
2 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 230aea69385d..f238cd7a9dcf 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -521,6 +521,30 @@ int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset)
return intel_guc_send(guc, action, ARRAY_SIZE(action));
}
+/*
+ * The ENTER/EXIT_S_STATE actions queue the save/restore operation in GuC FW and
+ * then return, so waiting on the H2H is not enough to guarantee GuC is done.
+ * When all the processing is done, GuC writes 0 to scratch register 14, so we
+ * can poll on that. Note that GuC does not ensure that the value in the
+ * register is different from 0 while the action is in progress so we need to
+ * take care of that ourselves as well.
+ */
+static int guc_sleep_state_action(struct intel_guc *guc,
+ const u32 *action, u32 len)
+{
+ struct drm_i915_private *dev_priv = guc_to_i915(guc);
+ int ret;
+
+ I915_WRITE(SOFT_SCRATCH(14), ~0x0);
+
+ ret = intel_guc_send(guc, action, len);
+ if (ret)
+ return ret;
+
+ return intel_wait_for_register(dev_priv, SOFT_SCRATCH(14), ~0x0,
+ INTEL_GUC_SLEEP_STATE_SUCCESS, 10);
+}
+
/**
* intel_guc_suspend() - notify GuC entering suspend state
* @guc: the guc
@@ -533,7 +557,7 @@ int intel_guc_suspend(struct intel_guc *guc)
intel_guc_ggtt_offset(guc, guc->shared_data)
};
- return intel_guc_send(guc, data, ARRAY_SIZE(data));
+ return guc_sleep_state_action(guc, data, ARRAY_SIZE(data));
}
/**
@@ -571,7 +595,7 @@ int intel_guc_resume(struct intel_guc *guc)
intel_guc_ggtt_offset(guc, guc->shared_data)
};
- return intel_guc_send(guc, data, ARRAY_SIZE(data));
+ return guc_sleep_state_action(guc, data, ARRAY_SIZE(data));
}
/**
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 8382d591c784..b0eb5aabe0a7 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -687,6 +687,12 @@ enum intel_guc_report_status {
INTEL_GUC_REPORT_STATUS_COMPLETE = 0x4,
};
+enum intel_guc_sleep_state_status {
+ INTEL_GUC_SLEEP_STATE_SUCCESS = 0x0,
+ INTEL_GUC_SLEEP_STATE_PREEMPT_TO_IDLE_FAILED = 0x1,
+ INTEL_GUC_SLEEP_STATE_ENGINE_RESET_FAILED = 0x2
+};
+
#define GUC_LOG_CONTROL_LOGGING_ENABLED (1 << 0)
#define GUC_LOG_CONTROL_VERBOSITY_SHIFT 4
#define GUC_LOG_CONTROL_VERBOSITY_MASK (0xF << GUC_LOG_CONTROL_VERBOSITY_SHIFT)
--
2.19.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH 2/2] HAX enable GuC for CI
2018-10-15 22:10 [PATCH 1/2] drm/i915/guc: fix GuC suspend/resume Daniele Ceraolo Spurio
@ 2018-10-15 22:10 ` Daniele Ceraolo Spurio
0 siblings, 0 replies; 17+ messages in thread
From: Daniele Ceraolo Spurio @ 2018-10-15 22:10 UTC (permalink / raw)
To: intel-gfx
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@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 7e56c516c815..c681537bcb92 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -45,7 +45,7 @@ struct drm_printer;
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.19.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH 1/2] drm/i915: Keep local modparams copy for mock selftests
@ 2018-07-12 14:07 Jakub Bartmiński
2018-07-12 14:07 ` [PATCH 2/2] HAX enable GuC for CI Jakub Bartmiński
0 siblings, 1 reply; 17+ messages in thread
From: Jakub Bartmiński @ 2018-07-12 14:07 UTC (permalink / raw)
To: intel-gfx; +Cc: Jakub Bartmiński
Some functions used within mock selftests may expect platform-dependent
automatic modparams parameters to have already been resolved, resulting
in failed assertions.
Backing up the modparams before mock selftests and manually setting
offending parameters inside the affected selftests should fix the issue.
Signed-off-by: Jakub Bartmiński <jakub.bartminski@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
---
drivers/gpu/drm/i915/i915_pci.c | 10 ++++++++++
drivers/gpu/drm/i915/selftests/i915_gem_context.c | 6 ++++++
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 55543f1b0236..9e41851f5ca2 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -733,11 +733,21 @@ static int __init i915_init(void)
{
bool use_kms = true;
int err;
+ struct i915_params *backup_modparams;
+
+ backup_modparams = kmalloc(sizeof(*backup_modparams), GFP_KERNEL);
+ if (!backup_modparams)
+ return -ENOMEM;
+ memcpy(backup_modparams, &i915_modparams, sizeof(*backup_modparams));
err = i915_mock_selftests();
if (err)
return err > 0 ? 0 : err;
+ /* Revert any modparams modifications made inside mock selftests */
+ memcpy(&i915_modparams, backup_modparams, sizeof(*backup_modparams));
+ kfree(backup_modparams);
+
/*
* Enable KMS by default, unless explicitly overriden by
* either the i915.modeset prarameter or by the
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
index ab2590242033..de6aad832ac9 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
@@ -597,6 +597,12 @@ int i915_gem_context_mock_selftests(void)
if (!i915)
return -ENOMEM;
+ /*
+ * Platform defaults have not been resolved yet, so we need to prevent
+ * assertion failure on an unresolved enable_guc.
+ */
+ i915_modparams.enable_guc = 0;
+
err = i915_subtests(tests, i915);
drm_dev_put(&i915->drm);
--
2.17.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH 2/2] HAX enable GuC for CI
2018-07-12 14:07 [PATCH 1/2] drm/i915: Keep local modparams copy for mock selftests Jakub Bartmiński
@ 2018-07-12 14:07 ` Jakub Bartmiński
0 siblings, 0 replies; 17+ messages in thread
From: Jakub Bartmiński @ 2018-07-12 14:07 UTC (permalink / raw)
To: intel-gfx
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@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 aebe0469ddaa..3e4e128237ac 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@ struct drm_printer;
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.17.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH 1/2] drm/i915/uc: Introduce intel_uc_suspend|resume
@ 2018-02-23 14:10 Michal Wajdeczko
2018-02-23 14:10 ` [PATCH 2/2] HAX: Enable GuC for CI Michal Wajdeczko
0 siblings, 1 reply; 17+ messages in thread
From: Michal Wajdeczko @ 2018-02-23 14:10 UTC (permalink / raw)
To: intel-gfx
We want to use higher level 'uc' functions as the main entry points to
the GuC/HuC code to hide some details and keep code layered.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/i915_drv.c | 6 +++---
drivers/gpu/drm/i915/i915_gem.c | 4 ++--
drivers/gpu/drm/i915/intel_guc.c | 42 +++++++++++++------------------------
drivers/gpu/drm/i915/intel_guc.h | 4 ++--
drivers/gpu/drm/i915/intel_uc.c | 45 ++++++++++++++++++++++++++++++++++++++++
drivers/gpu/drm/i915/intel_uc.h | 2 ++
6 files changed, 68 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index aaa861b..d61b51c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2575,7 +2575,7 @@ static int intel_runtime_suspend(struct device *kdev)
*/
i915_gem_runtime_suspend(dev_priv);
- intel_guc_suspend(dev_priv);
+ intel_uc_suspend(dev_priv);
intel_runtime_pm_disable_interrupts(dev_priv);
@@ -2597,7 +2597,7 @@ static int intel_runtime_suspend(struct device *kdev)
intel_runtime_pm_enable_interrupts(dev_priv);
- intel_guc_resume(dev_priv);
+ intel_uc_resume(dev_priv);
i915_gem_init_swizzling(dev_priv);
i915_gem_restore_fences(dev_priv);
@@ -2683,7 +2683,7 @@ static int intel_runtime_resume(struct device *kdev)
intel_runtime_pm_enable_interrupts(dev_priv);
- intel_guc_resume(dev_priv);
+ intel_uc_resume(dev_priv);
/*
* No point of rolling back things in case of an error, as the best
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 14c855b..ef6aff8 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4919,7 +4919,7 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
i915_gem_contexts_lost(dev_priv);
mutex_unlock(&dev->struct_mutex);
- intel_guc_suspend(dev_priv);
+ intel_uc_suspend(dev_priv);
cancel_delayed_work_sync(&dev_priv->gpu_error.hangcheck_work);
cancel_delayed_work_sync(&dev_priv->gt.retire_work);
@@ -4986,7 +4986,7 @@ void i915_gem_resume(struct drm_i915_private *i915)
if (i915_gem_init_hw(i915))
goto err_wedged;
- intel_guc_resume(i915);
+ intel_uc_resume(i915);
/* Always reload a context for powersaving. */
if (i915_gem_switch_to_kernel_context(i915))
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 21140cc..6ca6b9a 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -403,22 +403,15 @@ int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset)
/**
* intel_guc_suspend() - notify GuC entering suspend state
- * @dev_priv: i915 device private
+ * @guc: the guc
*/
-int intel_guc_suspend(struct drm_i915_private *dev_priv)
+int intel_guc_suspend(struct intel_guc *guc)
{
- struct intel_guc *guc = &dev_priv->guc;
- u32 data[3];
-
- if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
- return 0;
-
- gen9_disable_guc_interrupts(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);
+ u32 data[] = {
+ INTEL_GUC_ACTION_ENTER_S_STATE,
+ GUC_POWER_D1, /* any value greater than GUC_POWER_D0 */
+ guc_ggtt_offset(guc->shared_data)
+ };
return intel_guc_send(guc, data, ARRAY_SIZE(data));
}
@@ -448,22 +441,15 @@ int intel_guc_reset_engine(struct intel_guc *guc,
/**
* intel_guc_resume() - notify GuC resuming from suspend state
- * @dev_priv: i915 device private
+ * @guc: the guc
*/
-int intel_guc_resume(struct drm_i915_private *dev_priv)
+int intel_guc_resume(struct intel_guc *guc)
{
- struct intel_guc *guc = &dev_priv->guc;
- u32 data[3];
-
- if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
- return 0;
-
- if (i915_modparams.guc_log_level)
- gen9_enable_guc_interrupts(dev_priv);
-
- data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
- data[1] = GUC_POWER_D0;
- data[2] = guc_ggtt_offset(guc->shared_data);
+ u32 data[] = {
+ INTEL_GUC_ACTION_EXIT_S_STATE,
+ GUC_POWER_D0,
+ guc_ggtt_offset(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 52856a9..b9424ac 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -127,8 +127,8 @@ static inline u32 guc_ggtt_offset(struct i915_vma *vma)
int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len);
int intel_guc_sample_forcewake(struct intel_guc *guc);
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);
+int intel_guc_suspend(struct intel_guc *guc);
+int intel_guc_resume(struct intel_guc *guc);
struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size);
u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 9f1bac6..a821f7a 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -445,3 +445,48 @@ void intel_uc_fini_hw(struct drm_i915_private *dev_priv)
if (USES_GUC_SUBMISSION(dev_priv))
gen9_disable_guc_interrupts(dev_priv);
}
+
+int intel_uc_suspend(struct drm_i915_private *i915)
+{
+ struct intel_guc *guc = &i915->guc;
+ int err;
+
+ if (!USES_GUC(i915))
+ return 0;
+
+ if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
+ return 0;
+
+ err = intel_guc_suspend(guc);
+ if (err) {
+ DRM_DEBUG_DRIVER("Failed to suspend GuC, err=%d", err);
+ return err;
+ }
+
+ gen9_disable_guc_interrupts(i915);
+
+ return 0;
+}
+
+int intel_uc_resume(struct drm_i915_private *i915)
+{
+ struct intel_guc *guc = &i915->guc;
+ int err;
+
+ if (!USES_GUC(i915))
+ return 0;
+
+ if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
+ return 0;
+
+ if (i915_modparams.guc_log_level)
+ gen9_enable_guc_interrupts(i915);
+
+ err = intel_guc_resume(guc);
+ if (err) {
+ DRM_DEBUG_DRIVER("Failed to resume GuC, err=%d", err);
+ return err;
+ }
+
+ return 0;
+}
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index f2984e0..f76d51d 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -39,6 +39,8 @@
void intel_uc_fini_hw(struct drm_i915_private *dev_priv);
int intel_uc_init(struct drm_i915_private *dev_priv);
void intel_uc_fini(struct drm_i915_private *dev_priv);
+int intel_uc_suspend(struct drm_i915_private *dev_priv);
+int intel_uc_resume(struct drm_i915_private *dev_priv);
static inline bool intel_uc_is_using_guc(void)
{
--
1.9.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH 2/2] HAX: Enable GuC for CI
2018-02-23 14:10 [PATCH 1/2] drm/i915/uc: Introduce intel_uc_suspend|resume Michal Wajdeczko
@ 2018-02-23 14:10 ` Michal Wajdeczko
0 siblings, 0 replies; 17+ messages in thread
From: Michal Wajdeczko @ 2018-02-23 14:10 UTC (permalink / raw)
To: intel-gfx
v2: except running with HYPERVISOR
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
---
drivers/gpu/drm/i915/i915_params.h | 2 +-
drivers/gpu/drm/i915/intel_uc.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h
index 430f5f9..3deae1e 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,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, 0) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index a821f7a..0e72e60 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -63,6 +63,8 @@ static int __get_platform_enable_guc(struct drm_i915_private *dev_priv)
enable_guc |= ENABLE_GUC_LOAD_HUC;
/* Any platform specific fine-tuning can be done here */
+ if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
+ enable_guc = 0;
return enable_guc;
}
--
1.9.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH 1/2] drm/i915/preemption: Allow preemption between submission ports
@ 2018-02-23 9:04 Chris Wilson
2018-02-23 9:04 ` [PATCH 2/2] HAX: enable GuC for CI Chris Wilson
0 siblings, 1 reply; 17+ messages in thread
From: Chris Wilson @ 2018-02-23 9:04 UTC (permalink / raw)
To: intel-gfx
Sometimes we need to boost the priority of an in-flight request, which
may lead to the situation where the second submission port then contains
a higher priority context than the first and so we need to inject a
preemption event. To do so we must always check inside
execlists_dequeue() whether there is a priority inversion between the
ports themselves as well as the head of the priority sorted queue, and we
cannot just skip dequeuing if the queue is empty.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
drivers/gpu/drm/i915/intel_engine_cs.c | 2 +
drivers/gpu/drm/i915/intel_guc_submission.c | 17 +--
drivers/gpu/drm/i915/intel_lrc.c | 161 ++++++++++++++++------------
drivers/gpu/drm/i915/intel_ringbuffer.h | 5 +
4 files changed, 107 insertions(+), 78 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c
index c31544406974..ce7fcf55ba18 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -423,6 +423,7 @@ static void intel_engine_init_execlist(struct intel_engine_cs *engine)
BUILD_BUG_ON_NOT_POWER_OF_2(execlists_num_ports(execlists));
GEM_BUG_ON(execlists_num_ports(execlists) > EXECLIST_MAX_PORTS);
+ execlists->queue_priority = INT_MIN;
execlists->queue = RB_ROOT;
execlists->first = NULL;
}
@@ -1903,6 +1904,7 @@ void intel_engine_dump(struct intel_engine_cs *engine,
spin_lock_irq(&engine->timeline->lock);
list_for_each_entry(rq, &engine->timeline->requests, link)
print_request(m, rq, "\t\tE ");
+ drm_printf(m, "\t\tQueue priority: %d\n", execlists->queue_priority);
for (rb = execlists->first; rb; rb = rb_next(rb)) {
struct i915_priolist *p =
rb_entry(rb, typeof(*p), node);
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c b/drivers/gpu/drm/i915/intel_guc_submission.c
index 649113c7a3c2..586dde579903 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -75,6 +75,11 @@
*
*/
+static inline struct i915_priolist *to_priolist(struct rb_node *rb)
+{
+ return rb_entry(rb, struct i915_priolist, node);
+}
+
static inline bool is_high_priority(struct intel_guc_client *client)
{
return (client->priority == GUC_CLIENT_PRIORITY_KMD_HIGH ||
@@ -682,15 +687,12 @@ static void guc_dequeue(struct intel_engine_cs *engine)
rb = execlists->first;
GEM_BUG_ON(rb_first(&execlists->queue) != rb);
- if (!rb)
- goto unlock;
-
if (port_isset(port)) {
if (engine->i915->preempt_context) {
struct guc_preempt_work *preempt_work =
&engine->i915->guc.preempt_work[engine->id];
- if (rb_entry(rb, struct i915_priolist, node)->priority >
+ if (execlists->queue_priority >
max(port_request(port)->priotree.priority, 0)) {
execlists_set_active(execlists,
EXECLISTS_ACTIVE_PREEMPT);
@@ -706,8 +708,8 @@ static void guc_dequeue(struct intel_engine_cs *engine)
}
GEM_BUG_ON(port_isset(port));
- do {
- struct i915_priolist *p = rb_entry(rb, typeof(*p), node);
+ while (rb) {
+ struct i915_priolist *p = to_priolist(rb);
struct i915_request *rq, *rn;
list_for_each_entry_safe(rq, rn, &p->requests, priotree.link) {
@@ -736,8 +738,9 @@ static void guc_dequeue(struct intel_engine_cs *engine)
INIT_LIST_HEAD(&p->requests);
if (p->priority != I915_PRIORITY_NORMAL)
kmem_cache_free(engine->i915->priorities, p);
- } while (rb);
+ }
done:
+ execlists->queue_priority = rb ? to_priolist(rb)->priority : INT_MIN;
execlists->first = rb;
if (submit) {
port_assign(port, last);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 964885b5d7cb..4bc72fbaf793 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -169,6 +169,23 @@ static void execlists_init_reg_state(u32 *reg_state,
struct intel_engine_cs *engine,
struct intel_ring *ring);
+static inline struct i915_priolist *to_priolist(struct rb_node *rb)
+{
+ return rb_entry(rb, struct i915_priolist, node);
+}
+
+static inline int rq_prio(const struct i915_request *rq)
+{
+ return rq->priotree.priority;
+}
+
+static inline bool need_preempt(const struct intel_engine_cs *engine,
+ const struct i915_request *last,
+ int prio)
+{
+ return engine->i915->preempt_context && prio > max(rq_prio(last), 0);
+}
+
/**
* intel_lr_context_descriptor_update() - calculate & cache the descriptor
* descriptor for a pinned context
@@ -224,7 +241,7 @@ lookup_priolist(struct intel_engine_cs *engine,
parent = &execlists->queue.rb_node;
while (*parent) {
rb = *parent;
- p = rb_entry(rb, typeof(*p), node);
+ p = to_priolist(rb);
if (prio > p->priority) {
parent = &rb->rb_left;
} else if (prio < p->priority) {
@@ -264,7 +281,7 @@ lookup_priolist(struct intel_engine_cs *engine,
if (first)
execlists->first = &p->node;
- return ptr_pack_bits(p, first, 1);
+ return p;
}
static void unwind_wa_tail(struct i915_request *rq)
@@ -290,14 +307,10 @@ static void __unwind_incomplete_requests(struct intel_engine_cs *engine)
__i915_request_unsubmit(rq);
unwind_wa_tail(rq);
- GEM_BUG_ON(rq->priotree.priority == I915_PRIORITY_INVALID);
- if (rq->priotree.priority != last_prio) {
- p = lookup_priolist(engine,
- &rq->priotree,
- rq->priotree.priority);
- p = ptr_mask_bits(p, 1);
-
- last_prio = rq->priotree.priority;
+ GEM_BUG_ON(rq_prio(rq) == I915_PRIORITY_INVALID);
+ if (rq_prio(rq) != last_prio) {
+ last_prio = rq_prio(rq);
+ p = lookup_priolist(engine, &rq->priotree, last_prio);
}
list_add(&rq->priotree.link, &p->requests);
@@ -397,10 +410,11 @@ static void execlists_submit_ports(struct intel_engine_cs *engine)
desc = execlists_update_context(rq);
GEM_DEBUG_EXEC(port[n].context_id = upper_32_bits(desc));
- GEM_TRACE("%s in[%d]: ctx=%d.%d, seqno=%x\n",
+ GEM_TRACE("%s in[%d]: ctx=%d.%d, seqno=%x, prio=%d\n",
engine->name, n,
port[n].context_id, count,
- rq->global_seqno);
+ rq->global_seqno,
+ rq_prio(rq));
} else {
GEM_BUG_ON(!n);
desc = 0;
@@ -453,12 +467,17 @@ static void inject_preempt_context(struct intel_engine_cs *engine)
_MASKED_BIT_ENABLE(CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT |
CTX_CTRL_ENGINE_CTX_SAVE_INHIBIT));
+ /*
+ * Switch to our empty preempt context so
+ * the state of the GPU is known (idle).
+ */
GEM_TRACE("%s\n", engine->name);
for (n = execlists_num_ports(&engine->execlists); --n; )
elsp_write(0, engine->execlists.elsp);
elsp_write(ce->lrc_desc, engine->execlists.elsp);
execlists_clear_active(&engine->execlists, EXECLISTS_ACTIVE_HWACK);
+ execlists_set_active(&engine->execlists, EXECLISTS_ACTIVE_PREEMPT);
}
static void execlists_dequeue(struct intel_engine_cs *engine)
@@ -495,8 +514,6 @@ static void execlists_dequeue(struct intel_engine_cs *engine)
spin_lock_irq(&engine->timeline->lock);
rb = execlists->first;
GEM_BUG_ON(rb_first(&execlists->queue) != rb);
- if (!rb)
- goto unlock;
if (last) {
/*
@@ -519,54 +536,48 @@ static void execlists_dequeue(struct intel_engine_cs *engine)
if (!execlists_is_active(execlists, EXECLISTS_ACTIVE_HWACK))
goto unlock;
- if (engine->i915->preempt_context &&
- rb_entry(rb, struct i915_priolist, node)->priority >
- max(last->priotree.priority, 0)) {
- /*
- * Switch to our empty preempt context so
- * the state of the GPU is known (idle).
- */
+ if (need_preempt(engine, last, execlists->queue_priority)) {
inject_preempt_context(engine);
- execlists_set_active(execlists,
- EXECLISTS_ACTIVE_PREEMPT);
goto unlock;
- } else {
- /*
- * In theory, we could coalesce more requests onto
- * the second port (the first port is active, with
- * no preemptions pending). However, that means we
- * then have to deal with the possible lite-restore
- * of the second port (as we submit the ELSP, there
- * may be a context-switch) but also we may complete
- * the resubmission before the context-switch. Ergo,
- * coalescing onto the second port will cause a
- * preemption event, but we cannot predict whether
- * that will affect port[0] or port[1].
- *
- * If the second port is already active, we can wait
- * until the next context-switch before contemplating
- * new requests. The GPU will be busy and we should be
- * able to resubmit the new ELSP before it idles,
- * avoiding pipeline bubbles (momentary pauses where
- * the driver is unable to keep up the supply of new
- * work).
- */
- if (port_count(&port[1]))
- goto unlock;
-
- /* WaIdleLiteRestore:bdw,skl
- * Apply the wa NOOPs to prevent
- * ring:HEAD == rq:TAIL as we resubmit the
- * request. See gen8_emit_breadcrumb() for
- * where we prepare the padding after the
- * end of the request.
- */
- last->tail = last->wa_tail;
}
+
+ /*
+ * In theory, we could coalesce more requests onto
+ * the second port (the first port is active, with
+ * no preemptions pending). However, that means we
+ * then have to deal with the possible lite-restore
+ * of the second port (as we submit the ELSP, there
+ * may be a context-switch) but also we may complete
+ * the resubmission before the context-switch. Ergo,
+ * coalescing onto the second port will cause a
+ * preemption event, but we cannot predict whether
+ * that will affect port[0] or port[1].
+ *
+ * If the second port is already active, we can wait
+ * until the next context-switch before contemplating
+ * new requests. The GPU will be busy and we should be
+ * able to resubmit the new ELSP before it idles,
+ * avoiding pipeline bubbles (momentary pauses where
+ * the driver is unable to keep up the supply of new
+ * work). However, we have to double check that the
+ * priorities of the ports haven't been switch.
+ */
+ if (port_count(&port[1]))
+ goto unlock;
+
+ /*
+ * WaIdleLiteRestore:bdw,skl
+ * Apply the wa NOOPs to prevent
+ * ring:HEAD == rq:TAIL as we resubmit the
+ * request. See gen8_emit_breadcrumb() for
+ * where we prepare the padding after the
+ * end of the request.
+ */
+ last->tail = last->wa_tail;
}
- do {
- struct i915_priolist *p = rb_entry(rb, typeof(*p), node);
+ while (rb) {
+ struct i915_priolist *p = to_priolist(rb);
struct i915_request *rq, *rn;
list_for_each_entry_safe(rq, rn, &p->requests, priotree.link) {
@@ -628,8 +639,9 @@ static void execlists_dequeue(struct intel_engine_cs *engine)
INIT_LIST_HEAD(&p->requests);
if (p->priority != I915_PRIORITY_NORMAL)
kmem_cache_free(engine->i915->priorities, p);
- } while (rb);
+ }
done:
+ execlists->queue_priority = rb ? to_priolist(rb)->priority : INT_MIN;
execlists->first = rb;
if (submit)
port_assign(port, last);
@@ -690,7 +702,7 @@ static void execlists_cancel_requests(struct intel_engine_cs *engine)
/* Flush the queued requests to the timeline list (for retiring). */
rb = execlists->first;
while (rb) {
- struct i915_priolist *p = rb_entry(rb, typeof(*p), node);
+ struct i915_priolist *p = to_priolist(rb);
list_for_each_entry_safe(rq, rn, &p->requests, priotree.link) {
INIT_LIST_HEAD(&rq->priotree.link);
@@ -708,7 +720,7 @@ static void execlists_cancel_requests(struct intel_engine_cs *engine)
/* Remaining _unready_ requests will be nop'ed when submitted */
-
+ execlists->queue_priority = INT_MIN;
execlists->queue = RB_ROOT;
execlists->first = NULL;
GEM_BUG_ON(port_isset(execlists->port));
@@ -864,10 +876,11 @@ static void execlists_submission_tasklet(unsigned long data)
EXECLISTS_ACTIVE_USER));
rq = port_unpack(port, &count);
- GEM_TRACE("%s out[0]: ctx=%d.%d, seqno=%x\n",
+ GEM_TRACE("%s out[0]: ctx=%d.%d, seqno=%x, prio=%d\n",
engine->name,
port->context_id, count,
- rq ? rq->global_seqno : 0);
+ rq ? rq->global_seqno : 0,
+ rq ? rq_prio(rq) : 0);
/* Check the context/desc id for this event matches */
GEM_DEBUG_BUG_ON(buf[2 * head + 1] != port->context_id);
@@ -912,15 +925,19 @@ static void execlists_submission_tasklet(unsigned long data)
intel_uncore_forcewake_put(dev_priv, execlists->fw_domains);
}
-static void insert_request(struct intel_engine_cs *engine,
- struct i915_priotree *pt,
- int prio)
+static void queue_request(struct intel_engine_cs *engine,
+ struct i915_priotree *pt,
+ int prio)
{
- struct i915_priolist *p = lookup_priolist(engine, pt, prio);
+ list_add_tail(&pt->link, &lookup_priolist(engine, pt, prio)->requests);
+}
- list_add_tail(&pt->link, &ptr_mask_bits(p, 1)->requests);
- if (ptr_unmask_bits(p, 1))
+static void submit_queue(struct intel_engine_cs *engine, int prio)
+{
+ if (prio > engine->execlists.queue_priority) {
+ engine->execlists.queue_priority = prio;
tasklet_hi_schedule(&engine->execlists.tasklet);
+ }
}
static void execlists_submit_request(struct i915_request *request)
@@ -931,7 +948,8 @@ static void execlists_submit_request(struct i915_request *request)
/* Will be called from irq-context when using foreign fences. */
spin_lock_irqsave(&engine->timeline->lock, flags);
- insert_request(engine, &request->priotree, request->priotree.priority);
+ queue_request(engine, &request->priotree, rq_prio(request));
+ submit_queue(engine, rq_prio(request));
GEM_BUG_ON(!engine->execlists.first);
GEM_BUG_ON(list_empty(&request->priotree.link));
@@ -987,7 +1005,7 @@ static void execlists_schedule(struct i915_request *request, int prio)
* static void update_priorities(struct i915_priotree *pt, prio) {
* list_for_each_entry(dep, &pt->signalers_list, signal_link)
* update_priorities(dep->signal, prio)
- * insert_request(pt);
+ * queue_request(pt);
* }
* but that may have unlimited recursion depth and so runs a very
* real risk of overunning the kernel stack. Instead, we build
@@ -1050,8 +1068,9 @@ static void execlists_schedule(struct i915_request *request, int prio)
pt->priority = prio;
if (!list_empty(&pt->link)) {
__list_del_entry(&pt->link);
- insert_request(engine, pt, prio);
+ queue_request(engine, pt, prio);
}
+ submit_queue(engine, prio);
}
spin_unlock_irq(&engine->timeline->lock);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h b/drivers/gpu/drm/i915/intel_ringbuffer.h
index a9b83bf7e837..c4e9022b34e3 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -257,6 +257,11 @@ struct intel_engine_execlists {
*/
unsigned int port_mask;
+ /**
+ * @queue_priority: Highest pending priority.
+ */
+ int queue_priority;
+
/**
* @queue: queue of requests, in priority lists
*/
--
2.16.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH 2/2] HAX: enable GuC for CI
2018-02-23 9:04 [PATCH 1/2] drm/i915/preemption: Allow preemption between submission ports Chris Wilson
@ 2018-02-23 9:04 ` Chris Wilson
0 siblings, 0 replies; 17+ messages in thread
From: Chris Wilson @ 2018-02-23 9:04 UTC (permalink / raw)
To: intel-gfx
From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
drivers/gpu/drm/i915/i915_params.h | 2 +-
drivers/gpu/drm/i915/intel_uc.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h
index 430f5f9d0ff4..3deae1e22974 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@ struct drm_printer;
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, 0) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 9f1bac6398fb..b48056fb769d 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -63,6 +63,8 @@ static int __get_platform_enable_guc(struct drm_i915_private *dev_priv)
enable_guc |= ENABLE_GUC_LOAD_HUC;
/* Any platform specific fine-tuning can be done here */
+ if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
+ enable_guc = 0;
return enable_guc;
}
--
2.16.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 17+ messages in thread
end of thread, other threads:[~2018-10-16 9:42 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-03-20 23:18 [PATCH 1/2] drm/i915: Add code to accept valid locked WOPCM register values Jackie Li
2018-03-20 23:18 ` [PATCH 2/2] HAX enable guc for CI Jackie Li
2018-03-21 8:36 ` ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Add code to accept valid locked WOPCM register values Patchwork
2018-03-22 20:38 ` [PATCH 1/2] " Michał Winiarski
2018-03-22 21:27 ` Yaodong Li
2018-03-23 14:01 ` Michał Winiarski
2018-03-23 17:33 ` Yaodong Li
2018-03-26 7:15 ` Joonas Lahtinen
2018-04-03 0:08 ` Yaodong Li
2018-03-23 14:02 ` Joonas Lahtinen
2018-03-23 14:38 ` Michał Winiarski
-- strict thread matches above, loose matches on Subject: below --
2018-10-16 9:42 [PATCH 1/2] drm/i915/guc: Limit number of scratch registers used for H2G Michal Wajdeczko
2018-10-16 9:42 ` [PATCH 2/2] HAX enable GuC for CI Michal Wajdeczko
2018-10-16 8:59 [PATCH 1/2] drm/i915/guc: Fix Gen9 GuC loading workarounds Michal Wajdeczko
2018-10-16 8:59 ` [PATCH 2/2] HAX enable GuC for CI Michal Wajdeczko
2018-10-15 22:10 [PATCH 1/2] drm/i915/guc: fix GuC suspend/resume Daniele Ceraolo Spurio
2018-10-15 22:10 ` [PATCH 2/2] HAX enable GuC for CI Daniele Ceraolo Spurio
2018-07-12 14:07 [PATCH 1/2] drm/i915: Keep local modparams copy for mock selftests Jakub Bartmiński
2018-07-12 14:07 ` [PATCH 2/2] HAX enable GuC for CI Jakub Bartmiński
2018-02-23 14:10 [PATCH 1/2] drm/i915/uc: Introduce intel_uc_suspend|resume Michal Wajdeczko
2018-02-23 14:10 ` [PATCH 2/2] HAX: Enable GuC for CI Michal Wajdeczko
2018-02-23 9:04 [PATCH 1/2] drm/i915/preemption: Allow preemption between submission ports Chris Wilson
2018-02-23 9:04 ` [PATCH 2/2] HAX: enable GuC for CI Chris Wilson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox