[PATCH 0/5] drm/i915: add VBT firmware loading mechanism

[PATCH 0/5] drm/i915: add VBT firmware loading mechanism

[Jani Nikula]

Some cleanups, Chris' patch as a dependency, and an untested idea to load the
VBT using the firmware loader if requested by the user.

BR,
Jani.

Chris Wilson (1):
  drm/i915: Add i915_param charp macro magic

Jani Nikula (4):
  drm/i915/opregion: bail out early for systems with no opregion VBT
  drm/i915/opregion: try to validate RVDA VBT only if it's there
  drm/i915/opregion: debug log about invalid ACPI OpRegion VBT
  drm/i915/opregion: let user specify override VBT via firmware load

 drivers/gpu/drm/i915/i915_debugfs.c   |   2 +
 drivers/gpu/drm/i915/i915_gpu_error.c |  22 ++++++++
 drivers/gpu/drm/i915/i915_params.c    |   4 ++
 drivers/gpu/drm/i915/i915_params.h    |   1 +
 drivers/gpu/drm/i915/intel_opregion.c | 103 ++++++++++++++++++++++++----------
 5 files changed, 102 insertions(+), 30 deletions(-)

-- 
2.1.4

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

[PATCH 1/5] drm/i915: Add i915_param charp macro magic

[Jani Nikula]

From: Chris Wilson <chris@chris-wilson.co.uk>

Handling the dynamic charp module parameter requires us to copy it for
the error state, or remember to lock it when reading (in case it used
with 0600).

v2: Use __always_inline and __builtin_strcmp

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
 drivers/gpu/drm/i915/i915_debugfs.c   |  2 ++
 drivers/gpu/drm/i915/i915_gpu_error.c | 22 ++++++++++++++++++++++
 2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
index 768461f7c7c6..655e60d609c2 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -72,6 +72,8 @@ static __always_inline void seq_print_param(struct seq_file *m,
 		seq_printf(m, "i915.%s=%d\n", name, *(const int *)x);
 	else if (!__builtin_strcmp(type, "unsigned int"))
 		seq_printf(m, "i915.%s=%u\n", name, *(const unsigned int *)x);
+	else if (!__builtin_strcmp(type, "char *"))
+		seq_printf(m, "i915.%s=%s\n", name, *(const char **)x);
 	else
 		BUILD_BUG();
 }
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c
index 3a3c7c3c4931..2b1d15668192 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -557,6 +557,8 @@ static __always_inline void err_print_param(struct drm_i915_error_state_buf *m,
 		err_printf(m, "i915.%s=%d\n", name, *(const int *)x);
 	else if (!__builtin_strcmp(type, "unsigned int"))
 		err_printf(m, "i915.%s=%u\n", name, *(const unsigned int *)x);
+	else if (!__builtin_strcmp(type, "char *"))
+		err_printf(m, "i915.%s=%s\n", name, *(const char **)x);
 	else
 		BUILD_BUG();
 }
@@ -810,6 +812,12 @@ static void i915_error_object_free(struct drm_i915_error_object *obj)
 	kfree(obj);
 }
 
+static __always_inline void free_param(const char *type, void *x)
+{
+	if (!__builtin_strcmp(type, "char *"))
+		kfree(*(void **)x);
+}
+
 void __i915_gpu_state_free(struct kref *error_ref)
 {
 	struct i915_gpu_state *error =
@@ -840,6 +848,11 @@ void __i915_gpu_state_free(struct kref *error_ref)
 
 	kfree(error->overlay);
 	kfree(error->display);
+
+#define FREE(T, x) free_param(#T, &error->params.x);
+	I915_PARAMS_FOR_EACH(FREE);
+#undef FREE
+
 	kfree(error);
 }
 
@@ -1614,6 +1627,12 @@ static void i915_capture_gen_state(struct drm_i915_private *dev_priv,
 	       sizeof(error->device_info));
 }
 
+static __always_inline void dup_param(const char *type, void *x)
+{
+	if (!__builtin_strcmp(type, "char *"))
+		*(void **)x = kstrdup(*(void **)x, GFP_ATOMIC);
+}
+
 static int capture(void *data)
 {
 	struct i915_gpu_state *error = data;
@@ -1625,6 +1644,9 @@ static int capture(void *data)
 					   error->i915->gt.last_init_time));
 
 	error->params = i915;
+#define DUP(T, x) dup_param(#T, &error->params.x);
+	I915_PARAMS_FOR_EACH(DUP);
+#undef DUP
 
 	i915_capture_gen_state(error->i915, error);
 	i915_capture_reg_state(error->i915, error);
-- 
2.1.4

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

[PATCH 2/5] drm/i915/opregion: bail out early for systems with no opregion VBT

[Jani Nikula]

Reduce indent. No functional changes.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
 drivers/gpu/drm/i915/intel_opregion.c | 64 +++++++++++++++++------------------
 1 file changed, 32 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c
index 4a862a358c70..0ab92dd570b0 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -911,6 +911,8 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
 	char buf[sizeof(OPREGION_SIGNATURE)];
 	int err = 0;
 	void *base;
+	const void *vbt = NULL;
+	u32 vbt_size = 0;
 
 	BUILD_BUG_ON(sizeof(struct opregion_header) != 0x100);
 	BUILD_BUG_ON(sizeof(struct opregion_acpi) != 0x100);
@@ -963,45 +965,43 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
 	if (mboxes & MBOX_ASLE_EXT)
 		DRM_DEBUG_DRIVER("ASLE extension supported\n");
 
-	if (!dmi_check_system(intel_no_opregion_vbt)) {
-		const void *vbt = NULL;
-		u32 vbt_size = 0;
-
-		if (opregion->header->opregion_ver >= 2 && opregion->asle &&
-		    opregion->asle->rvda && opregion->asle->rvds) {
-			opregion->rvda = memremap(opregion->asle->rvda,
-						  opregion->asle->rvds,
-						  MEMREMAP_WB);
-			vbt = opregion->rvda;
-			vbt_size = opregion->asle->rvds;
-		}
+	if (dmi_check_system(intel_no_opregion_vbt))
+		goto out;
+
+	if (opregion->header->opregion_ver >= 2 && opregion->asle &&
+	    opregion->asle->rvda && opregion->asle->rvds) {
+		opregion->rvda = memremap(opregion->asle->rvda,
+					  opregion->asle->rvds,
+					  MEMREMAP_WB);
+		vbt = opregion->rvda;
+		vbt_size = opregion->asle->rvds;
+	}
 
+	if (intel_bios_is_valid_vbt(vbt, vbt_size)) {
+		DRM_DEBUG_KMS("Found valid VBT in ACPI OpRegion (RVDA)\n");
+		opregion->vbt = vbt;
+		opregion->vbt_size = vbt_size;
+	} else {
+		vbt = base + OPREGION_VBT_OFFSET;
+		/*
+		 * The VBT specification says that if the ASLE ext mailbox is
+		 * not used its area is reserved, but on some CHT boards the VBT
+		 * extends into the ASLE ext area. Allow this even though it is
+		 * against the spec, so we do not end up rejecting the VBT on
+		 * those boards (and end up not finding the LCD panel because of
+		 * this).
+		 */
+		vbt_size = (mboxes & MBOX_ASLE_EXT) ?
+			OPREGION_ASLE_EXT_OFFSET : OPREGION_SIZE;
+		vbt_size -= OPREGION_VBT_OFFSET;
 		if (intel_bios_is_valid_vbt(vbt, vbt_size)) {
-			DRM_DEBUG_KMS("Found valid VBT in ACPI OpRegion (RVDA)\n");
+			DRM_DEBUG_KMS("Found valid VBT in ACPI OpRegion (Mailbox #4)\n");
 			opregion->vbt = vbt;
 			opregion->vbt_size = vbt_size;
-		} else {
-			vbt = base + OPREGION_VBT_OFFSET;
-			/*
-			 * The VBT specification says that if the ASLE ext
-			 * mailbox is not used its area is reserved, but
-			 * on some CHT boards the VBT extends into the
-			 * ASLE ext area. Allow this even though it is
-			 * against the spec, so we do not end up rejecting
-			 * the VBT on those boards (and end up not finding the
-			 * LCD panel because of this).
-			 */
-			vbt_size = (mboxes & MBOX_ASLE_EXT) ?
-				OPREGION_ASLE_EXT_OFFSET : OPREGION_SIZE;
-			vbt_size -= OPREGION_VBT_OFFSET;
-			if (intel_bios_is_valid_vbt(vbt, vbt_size)) {
-				DRM_DEBUG_KMS("Found valid VBT in ACPI OpRegion (Mailbox #4)\n");
-				opregion->vbt = vbt;
-				opregion->vbt_size = vbt_size;
-			}
 		}
 	}
 
+out:
 	return 0;
 
 err_out:
-- 
2.1.4

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

[PATCH 3/5] drm/i915/opregion: try to validate RVDA VBT only if it's there

[Jani Nikula]

Seems more sensible this way, and reduces indent for the more common
case.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
 drivers/gpu/drm/i915/intel_opregion.c | 41 +++++++++++++++++------------------
 1 file changed, 20 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c
index 0ab92dd570b0..96b9801e8eb5 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -911,8 +911,8 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
 	char buf[sizeof(OPREGION_SIGNATURE)];
 	int err = 0;
 	void *base;
-	const void *vbt = NULL;
-	u32 vbt_size = 0;
+	const void *vbt;
+	u32 vbt_size;
 
 	BUILD_BUG_ON(sizeof(struct opregion_header) != 0x100);
 	BUILD_BUG_ON(sizeof(struct opregion_acpi) != 0x100);
@@ -975,30 +975,29 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
 					  MEMREMAP_WB);
 		vbt = opregion->rvda;
 		vbt_size = opregion->asle->rvds;
+		if (intel_bios_is_valid_vbt(vbt, vbt_size)) {
+			DRM_DEBUG_KMS("Found valid VBT in ACPI OpRegion (RVDA)\n");
+			opregion->vbt = vbt;
+			opregion->vbt_size = vbt_size;
+			goto out;
+		}
 	}
 
+	vbt = base + OPREGION_VBT_OFFSET;
+	/*
+	 * The VBT specification says that if the ASLE ext mailbox is not used
+	 * its area is reserved, but on some CHT boards the VBT extends into the
+	 * ASLE ext area. Allow this even though it is against the spec, so we
+	 * do not end up rejecting the VBT on those boards (and end up not
+	 * finding the LCD panel because of this).
+	 */
+	vbt_size = (mboxes & MBOX_ASLE_EXT) ?
+		OPREGION_ASLE_EXT_OFFSET : OPREGION_SIZE;
+	vbt_size -= OPREGION_VBT_OFFSET;
 	if (intel_bios_is_valid_vbt(vbt, vbt_size)) {
-		DRM_DEBUG_KMS("Found valid VBT in ACPI OpRegion (RVDA)\n");
+		DRM_DEBUG_KMS("Found valid VBT in ACPI OpRegion (Mailbox #4)\n");
 		opregion->vbt = vbt;
 		opregion->vbt_size = vbt_size;
-	} else {
-		vbt = base + OPREGION_VBT_OFFSET;
-		/*
-		 * The VBT specification says that if the ASLE ext mailbox is
-		 * not used its area is reserved, but on some CHT boards the VBT
-		 * extends into the ASLE ext area. Allow this even though it is
-		 * against the spec, so we do not end up rejecting the VBT on
-		 * those boards (and end up not finding the LCD panel because of
-		 * this).
-		 */
-		vbt_size = (mboxes & MBOX_ASLE_EXT) ?
-			OPREGION_ASLE_EXT_OFFSET : OPREGION_SIZE;
-		vbt_size -= OPREGION_VBT_OFFSET;
-		if (intel_bios_is_valid_vbt(vbt, vbt_size)) {
-			DRM_DEBUG_KMS("Found valid VBT in ACPI OpRegion (Mailbox #4)\n");
-			opregion->vbt = vbt;
-			opregion->vbt_size = vbt_size;
-		}
 	}
 
 out:
-- 
2.1.4

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

[PATCH 4/5] drm/i915/opregion: debug log about invalid ACPI OpRegion VBT

[Jani Nikula]

Leave more breadcrumbs for debuggers.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
 drivers/gpu/drm/i915/intel_opregion.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c
index 96b9801e8eb5..30ad721fa93d 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -980,6 +980,8 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
 			opregion->vbt = vbt;
 			opregion->vbt_size = vbt_size;
 			goto out;
+		} else {
+			DRM_DEBUG_KMS("Invalid VBT in ACPI OpRegion (RVDA)\n");
 		}
 	}
 
@@ -998,6 +1000,8 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
 		DRM_DEBUG_KMS("Found valid VBT in ACPI OpRegion (Mailbox #4)\n");
 		opregion->vbt = vbt;
 		opregion->vbt_size = vbt_size;
+	} else {
+		DRM_DEBUG_KMS("Invalid VBT in ACPI OpRegion (Mailbox #4)\n");
 	}
 
 out:
-- 
2.1.4

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

[PATCH 5/5] drm/i915/opregion: let user specify override VBT via firmware load

[Jani Nikula]

Sometimes it would be most enlightening to debug systems by replacing
the VBT to be used. For example, in the referenced bug the BIOS provides
different VBT depending on the boot mode (UEFI vs. legacy). It would be
interesting to try the failing boot mode with the VBT from the working
boot, and see if that makes a difference.

Add a module parameter to load the VBT using the firmware loader, not
unlike the EDID firmware mechanism.

References: https://bugs.freedesktop.org/show_bug.cgi?id=97822#c83
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
 drivers/gpu/drm/i915/i915_params.c    |  4 ++++
 drivers/gpu/drm/i915/i915_params.h    |  1 +
 drivers/gpu/drm/i915/intel_opregion.c | 40 +++++++++++++++++++++++++++++++++++
 3 files changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c
index 2e9645e6555a..6d1d127a0f60 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -113,6 +113,10 @@ MODULE_PARM_DESC(vbt_sdvo_panel_type,
 	"Override/Ignore selection of SDVO panel mode in the VBT "
 	"(-2=ignore, -1=auto [default], index in VBT BIOS table)");
 
+module_param_named_unsafe(vbt_firmware, i915.vbt_firmware, charp, 0400);
+MODULE_PARM_DESC(vbt_firmware,
+		 "Load VBT from specified file under /lib/firmware");
+
 module_param_named_unsafe(reset, i915.reset, bool, 0600);
 MODULE_PARM_DESC(reset, "Attempt GPU resets (default: true)");
 
diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h
index 55d47eea172e..a0fe557c666e 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -28,6 +28,7 @@
 #include <linux/cache.h> /* for __read_mostly */
 
 #define I915_PARAMS_FOR_EACH(func) \
+	func(char *, vbt_firmware); \
 	func(int, modeset); \
 	func(int, panel_ignore_lid); \
 	func(int, semaphores); \
diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c
index 30ad721fa93d..a85bbdd3131d 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -27,6 +27,7 @@
 
 #include <linux/acpi.h>
 #include <linux/dmi.h>
+#include <linux/firmware.h>
 #include <acpi/video.h>
 
 #include <drm/drmP.h>
@@ -903,6 +904,42 @@ static const struct dmi_system_id intel_no_opregion_vbt[] = {
 	{ }
 };
 
+static int intel_load_vbt_firmware(struct drm_i915_private *dev_priv)
+{
+	struct intel_opregion *opregion = &dev_priv->opregion;
+	const struct firmware *fw = NULL;
+	const char *name = i915.vbt_firmware;
+	int ret;
+
+	if (!name || !*name)
+		return -ENOENT;
+
+	ret = request_firmware(&fw, name, &dev_priv->drm.pdev->dev);
+	if (ret) {
+		DRM_ERROR("Requesting VBT firmware \"%s\" failed (%d)\n",
+			  name, ret);
+		return ret;
+	}
+
+	if (intel_bios_is_valid_vbt(fw->data, fw->size)) {
+		opregion->vbt = kmemdup(fw->data, fw->size, GFP_KERNEL);
+		if (opregion->vbt) {
+			DRM_DEBUG_KMS("Found valid VBT firmware \"%s\"\n", name);
+			opregion->vbt_size = fw->size;
+			ret = 0;
+		} else {
+			ret = -ENOMEM;
+		}
+	} else {
+		DRM_DEBUG_KMS("Invalid VBT firmware \"%s\"\n", name);
+		ret = -EINVAL;
+	}
+
+	release_firmware(fw);
+
+	return ret;
+}
+
 int intel_opregion_setup(struct drm_i915_private *dev_priv)
 {
 	struct intel_opregion *opregion = &dev_priv->opregion;
@@ -965,6 +1002,9 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
 	if (mboxes & MBOX_ASLE_EXT)
 		DRM_DEBUG_DRIVER("ASLE extension supported\n");
 
+	if (!intel_load_vbt_firmware(dev_priv))
+		goto out;
+
 	if (dmi_check_system(intel_no_opregion_vbt))
 		goto out;
 
-- 
2.1.4

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

Re: [PATCH 5/5] drm/i915/opregion: let user specify override VBT via firmware load

[Chris Wilson]

On Tue, Feb 21, 2017 at 06:40:25PM +0200, Jani Nikula wrote:
> Sometimes it would be most enlightening to debug systems by replacing
> the VBT to be used. For example, in the referenced bug the BIOS provides
> different VBT depending on the boot mode (UEFI vs. legacy). It would be
> interesting to try the failing boot mode with the VBT from the working
> boot, and see if that makes a difference.
> 
> Add a module parameter to load the VBT using the firmware loader, not
> unlike the EDID firmware mechanism.

What's the mechanism by which they would create a valid VBT file?
Does
	cat /sys/kernel/debug/dri/0/i915_opregion > vbt.fw
work and provide a starting point for corrections?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✓ Fi.CI.BAT: success for drm/i915: add VBT firmware loading mechanism

[Patchwork]

== Series Details ==

Series: drm/i915: add VBT firmware loading mechanism
URL   : https://patchwork.freedesktop.org/series/20016/
State : success

== Summary ==

Series 20016v1 drm/i915: add VBT firmware loading mechanism
https://patchwork.freedesktop.org/api/1.0/series/20016/revisions/1/mbox/

Test kms_pipe_crc_basic:
        Subgroup suspend-read-crc-pipe-b:
                pass       -> INCOMPLETE (fi-skl-6260u) fdo#99750

fdo#99750 https://bugs.freedesktop.org/show_bug.cgi?id=99750

fi-bdw-5557u     total:253  pass:242  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050     total:253  pass:214  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205     total:253  pass:234  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700     total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900     total:253  pass:226  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820     total:253  pass:222  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770      total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r     total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650       total:253  pass:203  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m     total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770      total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u     total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u     total:211  pass:203  dwarn:0   dfail:0   fail:0   skip:7  
fi-skl-6700hq    total:253  pass:236  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k     total:253  pass:231  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hq    total:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m     total:253  pass:225  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600      total:253  pass:224  dwarn:0   dfail:0   fail:0   skip:29 

e922d8924920be31fc76f5813bc1fde5d6cbf950 drm-tip: 2017y-02m-21d-16h-18m-14s UTC integration manifest
ed5e919 drm/i915/opregion: let user specify override VBT via firmware load
3d9b54b drm/i915/opregion: debug log about invalid ACPI OpRegion VBT
f334ec2 drm/i915/opregion: try to validate RVDA VBT only if it's there
9263b15 drm/i915/opregion: bail out early for systems with no opregion VBT
b59c780 drm/i915: Add i915_param charp macro magic

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3916/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 5/5] drm/i915/opregion: let user specify override VBT via firmware load

[Jani Nikula]

On Tue, 21 Feb 2017, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> On Tue, Feb 21, 2017 at 06:40:25PM +0200, Jani Nikula wrote:
>> Sometimes it would be most enlightening to debug systems by replacing
>> the VBT to be used. For example, in the referenced bug the BIOS provides
>> different VBT depending on the boot mode (UEFI vs. legacy). It would be
>> interesting to try the failing boot mode with the VBT from the working
>> boot, and see if that makes a difference.
>> 
>> Add a module parameter to load the VBT using the firmware loader, not
>> unlike the EDID firmware mechanism.
>
> What's the mechanism by which they would create a valid VBT file?
> Does
> 	cat /sys/kernel/debug/dri/0/i915_opregion > vbt.fw
> work and provide a starting point for corrections?
 
The debugfs file for just the VBT is i915_vbt.

For starters I only thought of using the VBT from the other boot mode,
and didn't really think of actually modifying the file, let alone making
it easy to modify the file using some tool for example.

There is a Windows-only BIOS Modification Program, or BMP, to modify the
VBT. It's referenced in a bunch of public documentation, but apparently
the tool itself is not publicly available. And even if it were, it's
neither free nor for Linux. I've never touched it myself.

Given the fact that we have tools/intel_vbt_decode in IGT, it should not
be hard to write such a tool. The information is all there for an
interested party. Just a SMOP. ;)

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 5/5] drm/i915/opregion: let user specify override VBT via firmware load

[Chris Wilson]

On Wed, Feb 22, 2017 at 10:15:12AM +0200, Jani Nikula wrote:
> On Tue, 21 Feb 2017, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > On Tue, Feb 21, 2017 at 06:40:25PM +0200, Jani Nikula wrote:
> >> Sometimes it would be most enlightening to debug systems by replacing
> >> the VBT to be used. For example, in the referenced bug the BIOS provides
> >> different VBT depending on the boot mode (UEFI vs. legacy). It would be
> >> interesting to try the failing boot mode with the VBT from the working
> >> boot, and see if that makes a difference.
> >> 
> >> Add a module parameter to load the VBT using the firmware loader, not
> >> unlike the EDID firmware mechanism.
> >
> > What's the mechanism by which they would create a valid VBT file?
> > Does
> > 	cat /sys/kernel/debug/dri/0/i915_opregion > vbt.fw
> > work and provide a starting point for corrections?
>  
> The debugfs file for just the VBT is i915_vbt.
> 
> For starters I only thought of using the VBT from the other boot mode,
> and didn't really think of actually modifying the file, let alone making
> it easy to modify the file using some tool for example.
> 
> There is a Windows-only BIOS Modification Program, or BMP, to modify the
> VBT. It's referenced in a bunch of public documentation, but apparently
> the tool itself is not publicly available. And even if it were, it's
> neither free nor for Linux. I've never touched it myself.
> 
> Given the fact that we have tools/intel_vbt_decode in IGT, it should not
> be hard to write such a tool. The information is all there for an
> interested party. Just a SMOP. ;)

No worries, all I wanted was a very short step-by-step guide as to how
one would experiment with, use, or test this feature.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx