On 8/19/2019 9:25 PM, Summers, Stuart wrote:
On Mon, 2019-08-19 at 18:23 -0700, Daniele Ceraolo Spurio wrote:First uc firmware release for EHL. Signed-off-by: Daniele Ceraolo Spurio < [email protected]> Cc: Matt Roper <[email protected]> Cc: Anusha Srivatsa <[email protected]> Cc: Michal Wajdeczko <[email protected]> --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c index bd22bf11adad..296a82603be0 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -39,12 +39,13 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, * Must be ordered based on platform + revid, from newer to older. */ #define INTEL_UC_FIRMWARE_DEFS(fw_def, guc_def, huc_def) \ - fw_def(ICELAKE, 0, guc_def(icl, 33, 0, 0), huc_def(icl, 8, 4, 3238)) \ - fw_def(COFFEELAKE, 0, guc_def(kbl, 33, 0, 0), huc_def(kbl, 02, 00, 1810)) \ - fw_def(GEMINILAKE, 0, guc_def(glk, 33, 0, 0), huc_def(glk, 03, 01, 2893)) \ - fw_def(KABYLAKE, 0, guc_def(kbl, 33, 0, 0), huc_def(kbl, 02, 00, 1810)) \ - fw_def(BROXTON, 0, guc_def(bxt, 33, 0, 0), huc_def(bxt, 01, 8, 2893)) \ - fw_def(SKYLAKE, 0, guc_def(skl, 33, 0, 0), huc_def(skl, 01, 07, 1398)) + fw_def(ELKHARTLAKE, 0, guc_def(ehl, 33, 0, 4), huc_def(ehl, 9, 0, 0)) \Is there a reason you are bumping straight to 33.0.4 for EHL rather than sticking with the existing firmware version? Or worded differently, why don't we bump everything to 33.0.4 if we're adding EHL here to stay in sync between the platforms?
33.0.4 is the first release to include an EHL build, so I didn't have the choice to stick with 33.0.0 for it, otherwise I would have. As for why I didn't update all the other blobs, it was because AFAICS from the release notes there are no changes that we need at the moment, mostly because the only thing we do with GuC is authenticating HuC and that flow is pretty static. All the 33.0.* releases are compatible at the interface level so I opted to avoid pushing several more binaries just to keep the numbers the same with no real benefit.
As a general point, I think we should expect that the patch number might vary across platforms as we get platform-specific features/fixes, but major and minor, which indicate the interface version, will be in sync.
Daniele
Thanks, Stuart+ fw_def(ICELAKE, 0, guc_def(icl, 33, 0, 0), huc_def(icl, 8, 4, 3238)) \ + fw_def(COFFEELAKE, 0, guc_def(kbl, 33, 0, 0), huc_def(kbl, 02, 00, 1810)) \ + fw_def(GEMINILAKE, 0, guc_def(glk, 33, 0, 0), huc_def(glk, 03, 01, 2893)) \ + fw_def(KABYLAKE, 0, guc_def(kbl, 33, 0, 0), huc_def(kbl, 02, 00, 1810)) \ + fw_def(BROXTON, 0, guc_def(bxt, 33, 0, 0), huc_def(bxt, 01, 8, 2893)) \ + fw_def(SKYLAKE, 0, guc_def(skl, 33, 0, 0), huc_def(skl, 01, 07, 1398))#define __MAKE_UC_FW_PATH(prefix_, name_, separator_, major_,minor_, patch_) \ "i915/" \
_______________________________________________ Intel-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/intel-gfx
