All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Arkadiusz Hiler <arkadiusz.hiler@intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 4/8] drm/i915/uc: Rename intel_?uc_init() to intel_?uc_fetch_fw()
Date: Wed, 22 Feb 2017 15:59:01 +0200	[thread overview]
Message-ID: <1487771941.3483.30.camel@linux.intel.com> (raw)
In-Reply-To: <20170222124125.4437-5-arkadiusz.hiler@intel.com>

On ke, 2017-02-22 at 13:41 +0100, Arkadiusz Hiler wrote:
> Trying to have subject_verb_object ordering and more descriptive names,
> the intel_huc_init() and intel_guc_init() functions are renamed:
> 
>  * `intel_guc` is the subject, so those functions now take intel_guc
>    structure, instead of the dev_priv
>  * fetch is the verb
>  * fw is the object which better describes the function's role
> 
> Same change is done for the huc counterpart.
> 
> Also we bulk call both functions from higher-level intel_uc_fetch_fw:
>  * intel being the subject (taking the dev_priv as param)
>  * fetch being the verb
>  * uc_fw being the subject
> 
> v2: settle on intel_uc_fetch_fw name (M. Wajdeczko)
> 
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Michal Winiarski <michal.winiarski@intel.com>
> Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>

<SNIP>

> @@ -609,8 +609,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
>  	if (ret)
>  		goto cleanup_irq;
>  
> -	intel_huc_init(dev_priv);
> -	intel_guc_init(dev_priv);
> +	intel_uc_fetch_fw(dev_priv);

intel_uc_init fits this context. (See below)

>  /**
> - * intel_guc_init() - define parameters and fetch firmware
> - * @dev_priv:	i915 device private
> + * intel_guc_fetch_fw() - define parameters and fetch firmware
> + * @guc:	intel_guc struct
>   *
>   * Called early during driver load, but after GEM is initialised.
>   *
>   * The firmware will be transferred to the GuC's memory later,
>   * when intel_guc_init_hw() is called.
>   */

"define parameters" is little vague, maybe "select and fetch firmware"?

> -void intel_guc_init(struct drm_i915_private *dev_priv)
> +void intel_guc_fetch_fw(struct intel_guc *guc)
>  {
> -	struct intel_uc_fw *guc_fw = &dev_priv->guc.fw;
> +	struct drm_i915_private *dev_priv = guc_to_i915(guc);
>  	const char *fw_path;
>  
>  	if (!HAS_GUC(dev_priv)) {

This parameter dance needs to be moved away from guc_fetch_fw function,
into intel_sanitize_options (I'm pretty sure I've mentioned this
earlier).

> @@ -751,23 +751,23 @@ void intel_guc_init(struct drm_i915_private *dev_priv)
>  		fw_path = NULL;
>  	} else if (IS_SKYLAKE(dev_priv)) {
>  		fw_path = I915_SKL_GUC_UCODE;
> -		guc_fw->major_ver_wanted = SKL_FW_MAJOR;
> -		guc_fw->minor_ver_wanted = SKL_FW_MINOR;
> +		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->major_ver_wanted = BXT_FW_MAJOR;
> -		guc_fw->minor_ver_wanted = BXT_FW_MINOR;
> +		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->major_ver_wanted = KBL_FW_MAJOR;
> -		guc_fw->minor_ver_wanted = KBL_FW_MINOR;
> +		guc->fw.major_ver_wanted = KBL_FW_MAJOR;
> +		guc->fw.minor_ver_wanted = KBL_FW_MINOR;
>  	} else {
>  		fw_path = "";	/* unknown device */
>  	}
>  
> -	guc_fw->path = fw_path;
> -	guc_fw->fetch_status = INTEL_UC_FIRMWARE_NONE;
> -	guc_fw->load_status = INTEL_UC_FIRMWARE_NONE;
> +	guc->fw.path = fw_path;

Just get rid of fw_path variable and assign directly, also hoist the
warning to the else branch, which can then do "return;"
 
> +	guc->fw.fetch_status = INTEL_UC_FIRMWARE_NONE;
> +	guc->fw.load_status = INTEL_UC_FIRMWARE_NONE;

Hoist this assignment before the if block, so no need to special for
the early return from else branch.

<SNIP>
 
>  /**
> - * intel_huc_init() - initiate HuC firmware loading request
> - * @dev_priv: the drm_i915_private device
> + * intel_huc_fetch_fw() - initiate HuC firmware loading request

Correct this commit too to be more descriptive.

> + * @huc:	intel_huc struct
>   *
>   * Called early during driver load, but after GEM is initialised. The loading
>   * will continue only when driver explicitly specify firmware name and version.
> @@ -152,42 +152,41 @@ static int huc_ucode_xfer(struct drm_i915_private *dev_priv)
>   *
>   * The DMA-copying to HW is done later when intel_huc_init_hw() is called.
>   */
> -void intel_huc_init(struct drm_i915_private *dev_priv)
> +void intel_huc_fetch_fw(struct intel_huc *huc)
>  {
> -	struct intel_huc *huc = &dev_priv->huc;
> -	struct intel_uc_fw *huc_fw = &huc->fw;
> +	struct drm_i915_private *dev_priv = huc_to_i915(huc);
>  	const char *fw_path = NULL;

Similarly arrange to get rid of fw_path here.

<SNIP>

> @@ -30,6 +30,12 @@ void intel_uc_init_early(struct drm_i915_private *dev_priv)
>  	mutex_init(&dev_priv->guc.send_mutex);
>  }
>  
> +void intel_uc_fetch_fw(struct drm_i915_private *dev_priv)

This function might be worth calling intel_uc_init (See above), if the
need comes to add other stuff. But either way.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-02-22 13:59 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-22 12:41 [PATCH v4 0/8] GuC Scrub vol. 1 Arkadiusz Hiler
2017-02-22 12:41 ` [PATCH 1/8] drm/i915/uc: Rename intel_?uc_{setup, load}() to _init_hw() Arkadiusz Hiler
2017-02-22 12:41 ` [PATCH 2/8] drm/i915/uc: Drop superfluous externs in intel_uc.h Arkadiusz Hiler
2017-02-23  8:38   ` Joonas Lahtinen
2017-02-22 12:41 ` [PATCH 3/8] drm/i915/huc: Add huc_to_i915 Arkadiusz Hiler
2017-02-22 12:41 ` [PATCH 4/8] drm/i915/uc: Rename intel_?uc_init() to intel_?uc_fetch_fw() Arkadiusz Hiler
2017-02-22 13:59   ` Joonas Lahtinen [this message]
2017-02-22 15:29     ` Arkadiusz Hiler
2017-02-23  7:45       ` Joonas Lahtinen
2017-02-22 12:41 ` [PATCH 5/8] drm/i915/uc: Make intel_uc_fw_fetch() static Arkadiusz Hiler
2017-02-22 14:17   ` Joonas Lahtinen
2017-02-22 15:04     ` Arkadiusz Hiler
2017-02-22 12:41 ` [PATCH 6/8] drm/i915/guc: Extract param logic form guc_init Arkadiusz Hiler
2017-02-23  8:37   ` Joonas Lahtinen
2017-02-22 12:41 ` [PATCH 7/8] drm/i915/guc: Simplify intel_guc_init_hw() Arkadiusz Hiler
2017-02-23  8:32   ` Joonas Lahtinen
2017-02-22 12:41 ` [PATCH 8/8] drm/i915/uc: Simplify firmware path handling Arkadiusz Hiler
2017-02-22 12:53   ` Chris Wilson
2017-02-22 15:30     ` Arkadiusz Hiler
2017-02-22 15:52       ` Arkadiusz Hiler
2017-02-23  7:58         ` Joonas Lahtinen
2017-02-23  8:09   ` Joonas Lahtinen
2017-02-22 16:22 ` ✓ Fi.CI.BAT: success for GuC Scrub vol. 1 (rev4) Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2017-02-17 13:05 [PATCH v3 0/8] GuC Scrub vol. 1 Arkadiusz Hiler
2017-02-17 13:05 ` [PATCH 4/8] drm/i915/uc: Rename intel_?uc_init() to intel_?uc_fetch_fw() Arkadiusz Hiler
2017-02-17 13:31   ` Michal Wajdeczko
2017-02-21 11:37     ` Arkadiusz Hiler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1487771941.3483.30.camel@linux.intel.com \
    --to=joonas.lahtinen@linux.intel.com \
    --cc=arkadiusz.hiler@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.