[Intel-gfx] [PATCH 4/8] drm/i915/huc: Add BXT HuC Loading Support

[Srivatsa, Anusha]

>-----Original Message-----
>From: Tvrtko Ursulin [mailto:tvrtko.ursulin at linux.intel.com]
>Sent: Thursday, December 1, 2016 5:11 AM
>To: Srivatsa, Anusha <anusha.srivatsa at intel.com>; intel-
>gfx at 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.mcgee at intel.com>
>> Signed-off-by: Anusha Srivatsa <anusha.srivatsa at intel.com>
>> Reviewed-by: Jeff McGee <jeff.mcgee at 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