All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
To: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 5/8] drm/i915/uc: Make intel_uc_fw_fetch() static
Date: Wed, 22 Feb 2017 16:04:45 +0100	[thread overview]
Message-ID: <20170222150445.GF23207@ahiler-desk.igk.intel.com> (raw)
In-Reply-To: <1487773040.3483.45.camel@linux.intel.com>

On Wed, Feb 22, 2017 at 04:17:20PM +0200, Joonas Lahtinen wrote:
> On ke, 2017-02-22 at 13:41 +0100, Arkadiusz Hiler wrote:
> > intel_uc_fw_fetch() is confusingly named in the light of recent changes.
> > 
> > It's also in the wrong place - 'guc_loader.h' - it's used for both guc
> > and huc, which was reflected in name, but not it's location, so let's
> > move it to 'intel_uc.c'.
> > 
> > We can make a intel_uc_fw callback out of it, to avoid leaking it
> > outside `intel_uc.c`
> > 
> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > Cc: Michal Winiarski <michal.winiarski@intel.com>
> > Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
> 
> <SNIP>
> 
> > @@ -32,7 +36,10 @@ void intel_uc_init_early(struct drm_i915_private *dev_priv)
> >  
> >  void intel_uc_fetch_fw(struct drm_i915_private *dev_priv)
> >  {
> > +	dev_priv->huc.fw.fetch = uc_fetch_fw;
> >  	intel_huc_fetch_fw(&dev_priv->huc);
> > +
> > +	dev_priv->guc.fw.fetch = uc_fetch_fw;
> 
> I'm bit confused, I was under impression these functions were going to
> be different for each uC? If they're not, then it most definitely
> should not be a function pointer.

The issue I presented on the IRC (maybe not clearly enough) was just
placement and naming of that function. The proposition with callback
seemd odd, but since it was backed by couple of people I commited to it.

Glad you spoted that here.

> 	int ret;
> 
> 	ret = intel_huc_select_fw(dev_priv->huc);
> 	if (ret)
> 		goto err;
> 	ret = intel_uc_fw_prepare(&dev_priv->huc->fw);
> 	if (ret)
> 		goto err;
> 
> 	ret = intel_guc_select_fw(dev_priv->guc);
> 	if (ret)
> 		goto err_huc;
> 	ret = intel_uc_fw_prepare(&dev_priv->guc->fw);
> 	if (ret)
> 		
> goto err_huc;
> 
> 	return 0;
> 
> err_huc:
> 	intel_uc_fw_unprepare(&dev_priv->huc->fw);
> err:
> 	return ret;
> 
> By always involving proper onion teardown, no dangling objects are left
> around.

That's exactly what I was missing in my approach. Thanks!

> >  	intel_guc_fetch_fw(&dev_priv->guc);
> >  }
> >  
> > @@ -120,3 +127,137 @@ int intel_guc_sample_forcewake(struct intel_guc *guc)
> > >  	return intel_guc_send(guc, action, ARRAY_SIZE(action));
> >  }
> >  
> > +static void uc_fetch_fw(struct drm_i915_private *dev_priv,
> > +			  struct intel_uc_fw *uc_fw)
> > +{
> > +	struct pci_dev *pdev = dev_priv->drm.pdev;
> > +	struct drm_i915_gem_object *obj;
> > +	const struct firmware *fw = NULL;
> > +	struct uc_css_header *css;
> > +	size_t size;
> > +	int err;
> 
> This function should be named differently, because it doesn't simply
> fetch it, but also validates and makes an object of it (which may be
> left dangling).

intel_uc_fw_prepare you've used in the example above seems like a good
name.

Onto fixing this mess. Thanks for the input :-)

-- 
Cheers,
Arek
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-02-22 15:04 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
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 [this message]
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 5/8] drm/i915/uc: Make intel_uc_fw_fetch() static Arkadiusz Hiler
2017-02-17 13:39   ` Michal Wajdeczko
2017-02-21 11:44     ` 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=20170222150445.GF23207@ahiler-desk.igk.intel.com \
    --to=arkadiusz.hiler@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=joonas.lahtinen@linux.intel.com \
    /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.