>-----Original Message----- >From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com] >Sent: Thursday, December 1, 2016 5:11 AM >To: Srivatsa, Anusha <anusha.sriva...@intel.com>; intel- >g...@lists.freedesktop.org >Subject: Re: [Intel-gfx] [PATCH 4/8] drm/i915/huc: Add BXT HuC Loading Support > > >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.mc...@intel.com> >> Signed-off-by: Anusha Srivatsa <anusha.sriva...@intel.com> >> Reviewed-by: Jeff McGee <jeff.mc...@intel.com> >> --- >> 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
Hi Tvrtko, Sincere apologies for responding so late. According to my understanding, Jeff correct me if I am wrong, we are finalizing the firmware version number for every kernel version. So a certain kernel will have only one possible firware major-minor and build number for a certain platform. I have cc-ed Jeff in this thread so he can add his comment on build number. Jeff, any comments? Regards, Anusha _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
