Re: [PATCH 4/8] drm/i915/huc: Add BXT HuC Loading Support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 30/11/2016 23:31, Anusha Srivatsa wrote:
This patch adds the HuC Loading for the BXT by using
the updated file construction.

Version 1.7 of the HuC firmware.

v2: rebased.
v3: rebased on top of drm-tip

Cc: Jeff Mcgee <jeff.mcgee@xxxxxxxxx>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@xxxxxxxxx>
Reviewed-by: Jeff McGee <jeff.mcgee@xxxxxxxxx>
---
 drivers/gpu/drm/i915/intel_huc_loader.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c b/drivers/gpu/drm/i915/intel_huc_loader.c
index 663fcc4..6357c19 100644
--- a/drivers/gpu/drm/i915/intel_huc_loader.c
+++ b/drivers/gpu/drm/i915/intel_huc_loader.c
@@ -40,6 +40,10 @@
  * Note that HuC firmware loading must be done before GuC loading.
  */

+#define BXT_FW_MAJOR 01
+#define BXT_FW_MINOR 07
+#define BXT_BLD_NUM 1398
+
 #define SKL_FW_MAJOR 01
 #define SKL_FW_MINOR 07
 #define SKL_BLD_NUM 1398
@@ -52,6 +56,9 @@
 	SKL_FW_MINOR, SKL_BLD_NUM)
 MODULE_FIRMWARE(I915_SKL_HUC_UCODE);

+#define I915_BXT_HUC_UCODE HUC_FW_PATH(bxt, BXT_FW_MAJOR, \
+	BXT_FW_MINOR, BXT_BLD_NUM)
+MODULE_FIRMWARE(I915_BXT_HUC_UCODE);
 /**
  * huc_ucode_xfer() - DMA's the firmware
  * @dev_priv: the drm device
@@ -159,6 +166,10 @@ void intel_huc_init(struct drm_device *dev)
 		fw_path = I915_SKL_HUC_UCODE;
 		huc_fw->major_ver_wanted = SKL_FW_MAJOR;
 		huc_fw->minor_ver_wanted = SKL_FW_MINOR;
+	} else if (IS_BROXTON(dev_priv)) {
+		fw_path = I915_BXT_HUC_UCODE;
+		huc_fw->major_ver_wanted = BXT_FW_MAJOR;
+		huc_fw->minor_ver_wanted = BXT_FW_MINOR;
 	}

 	huc_fw->uc_fw_path = fw_path;


Build number in the file name still worries me. Last time I've asked about it the thread kind of died off so I will re-state it.

My concern is that if we will be getting firmware releases with the same major-minor but different build numbers, then embedding the build number into the driver prevents loading of a newer firmware unless the kernel is also updated.

I am not sure if that is what we want. Perhaps it is not expected at all that will happen in production so it is not a concern?

Or if it could happen, perhaps we should either push back on the scheme - drop the build number and bump the minor in all cases, or alternatively for our purposes drop the build number from the driver and have a symlinked scheme on disk?

Regards,

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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux