[Intel-gfx] [PATCH 08/11] drm/i915/uc: Simplify firmware path handling

Arkadiusz Hiler arkadiusz.hiler at intel.com
Mon Mar 13 13:48:18 UTC 2017


On Mon, Mar 13, 2017 at 01:39:45PM +0000, Tvrtko Ursulin wrote:
> 
> On 13/03/2017 13:15, Arkadiusz Hiler wrote:
> > Currently fw->path values can represent one of three possible states:
> > 
> >  1) NULL - device without the uC
> >  2) '\0' - device with the uC but have no firmware
> >  3) else - device with the uC and we have firmware
> > 
> > Second case is used only to WARN at a later stage.
> > 
> > We can WARN right away and merge cases 1 and 2.
> > 
> > Code can be even further simplified and common (HuC/GuC logic) happening
> > right before the fetch can be offloaded to the common function.
> > 
> > v2: fewer temporary variables, more straightforward flow (M. Wajdeczko)
> > v3: DRM_ERROR instead of WARN (M. Wajdeczko)
> > v4: coding standard (J. Lahtinen)
> > v5: non-trivial rebase
> > v6: remove path check, we are checking fetch status (M. Wajdeczko)
> > 
> > Cc: Anusha Srivatsa <anusha.srivatsa at intel.com>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> > Cc: Michal Winiarski <michal.winiarski at intel.com>
> > Cc: Michal Wajdeczko <michal.wajdeczko at intel.com>
> > Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> > Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler at intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_guc_loader.c | 36 ++++++++++-----------------------
> >  drivers/gpu/drm/i915/intel_huc.c        | 21 ++++++-------------
> >  drivers/gpu/drm/i915/intel_uc.c         |  4 +++-
> >  3 files changed, 20 insertions(+), 41 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c b/drivers/gpu/drm/i915/intel_guc_loader.c
> > index 0a29c1b..d731f68 100644
> > --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> > +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> > @@ -368,13 +368,6 @@ int intel_guc_init_hw(struct intel_guc *guc)
> >  		intel_uc_fw_status_repr(guc->fw.fetch_status),
> >  		intel_uc_fw_status_repr(guc->fw.load_status));
> > 
> > -	if (!fw_path) {
> > -		return -ENXIO;
> > -	} else if (*fw_path == '\0') {
> > -		WARN(1, "No GuC firmware known for this platform!\n");
> > -		return -ENODEV;
> > -	}
> > -
> >  	if (guc->fw.fetch_status != INTEL_UC_FIRMWARE_SUCCESS)
> >  		return -EIO;
> > 
> > @@ -399,7 +392,6 @@ int intel_guc_init_hw(struct intel_guc *guc)
> >  	return 0;
> >  }
> > 
> > -
> >  /**
> >   * intel_guc_init_fw() - select and prepare firmware for loading
> >   * @guc:	intel_guc struct
> > @@ -412,37 +404,31 @@ int intel_guc_init_hw(struct intel_guc *guc)
> >  void intel_guc_init_fw(struct intel_guc *guc)
> >  {
> >  	struct drm_i915_private *dev_priv = guc_to_i915(guc);
> > -	const char *fw_path;
> > +
> > +	guc->fw.path = NULL;
> > +	guc->fw.fetch_status = INTEL_UC_FIRMWARE_NONE;
> > +	guc->fw.load_status = INTEL_UC_FIRMWARE_NONE;
> > +	guc->fw.fw = INTEL_UC_FW_TYPE_GUC;
> 
> If not too hard on the series and all, maybe bikeshed this field to "type".

Makes sense. Can we do that as a separate patch afterwards?

> More importantly, this field wasn't getting set before? I don't see that it
> got moved in this diff.

Huh. Quick grep on drm-tip revealed that this was not set, only checked
against. Guess it worked due to pure luck.

> > 
> >  	if (IS_SKYLAKE(dev_priv)) {
> > -		fw_path = I915_SKL_GUC_UCODE;
> > +		guc->fw.path = I915_SKL_GUC_UCODE;
> >  		guc->fw.major_ver_wanted = SKL_FW_MAJOR;
> >  		guc->fw.minor_ver_wanted = SKL_FW_MINOR;
> >  	} else if (IS_BROXTON(dev_priv)) {
> > -		fw_path = I915_BXT_GUC_UCODE;
> > +		guc->fw.path = I915_BXT_GUC_UCODE;
> >  		guc->fw.major_ver_wanted = BXT_FW_MAJOR;
> >  		guc->fw.minor_ver_wanted = BXT_FW_MINOR;
> >  	} else if (IS_KABYLAKE(dev_priv)) {
> > -		fw_path = I915_KBL_GUC_UCODE;
> > +		guc->fw.path = I915_KBL_GUC_UCODE;
> >  		guc->fw.major_ver_wanted = KBL_FW_MAJOR;
> >  		guc->fw.minor_ver_wanted = KBL_FW_MINOR;
> >  	} else {
> > -		fw_path = "";	/* unknown device */
> > +		DRM_ERROR("No GuC firmware known for platform with GuC!\n");
> 
> Quick glance over the series suggests intel_guc_init_fw is called
> unconditionally from i915_load_modeset_init meaning this error gets logged
> on all non-GuC platforms? I must be missing something..

intel_uc_init_fw which call that, returns early if !enable_guc_loading.

in intel_uc_snitize_options():
	if (!HAS_GUC) enable_guc_loading = 0

The flow is further improved by next patch.


-- 
Cheers,
Arek


More information about the Intel-gfx mailing list