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

[Tvrtko Ursulin]

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