public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Dave Gordon <david.s.gordon@intel.com>
To: yu.dai@intel.com, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v3 03/15] drm/i915: Unified firmware loading mechanism
Date: Thu, 23 Apr 2015 18:12:18 +0100	[thread overview]
Message-ID: <553927F2.6060906@intel.com> (raw)
In-Reply-To: <1429305680-4990-4-git-send-email-yu.dai@intel.com>

On 17/04/15 22:21, yu.dai@intel.com wrote:
> From: Dave Gordon <david.s.gordon@intel.com>
> 
> Factor out the common code of loading firmware into a new file,
> leaving only the uC-specific parts in the GuC loaders.
> 
> Issue: VIZ-4884
> Signed-off-by: Alex Dai <yu.dai@intel.com>
> Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
> ---
>  drivers/gpu/drm/i915/Makefile          |   3 +
>  drivers/gpu/drm/i915/intel_uc_loader.c | 244 +++++++++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/intel_uc_loader.h |  78 +++++++++++
>  3 files changed, 325 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/intel_uc_loader.c
>  create mode 100644 drivers/gpu/drm/i915/intel_uc_loader.h

In general, yes; but I noticed that the firmware image blob isn't
released in the 'success' path, which means we're keeping both the raw
image and the GEM copy around forever. It would be better to release the
raw image and only keep the GEM object (which is swappable).

Unfortunately, that wouldn't work with the current version of the GuC
loader because of the way it needs the data reorganised for DMA, and
therefore accesses the blob on each reload :(

So I think the way to go here is to upgrade the uc_fw_check() callback
to allow it to override the way the data is saved, if the default (GEM
object is just a copy of the firmware image) doesn't match the specific
uC requirements.

The GuC callback can then shuffle the data during this one-off copy, and
the subsequent DMA transfer will be much more straightforward.

I'll post a new suggestion for this file soon, probably tomorrow ...

.Dave.

> diff --git a/drivers/gpu/drm/i915/intel_uc_loader.c b/drivers/gpu/drm/i915/intel_uc_loader.c

> +static void uc_fw_finish(struct drm_device *dev, struct intel_uc_fw *uc_fw)
> +{
> +	struct drm_i915_gem_object *obj = NULL;
> +	const struct firmware *fw;
> +
> +	DRM_DEBUG_DRIVER("before waiting: %s fw fetch status %d, fw %p\n",
> +		uc_fw->uc_name, uc_fw->uc_fw_fetch_status, uc_fw->uc_fw_blob);
> +
> +	WARN_ON(!mutex_is_locked(&dev->struct_mutex));
> +	WARN_ON(uc_fw->uc_fw_fetch_status != INTEL_UC_FIRMWARE_PENDING);
> +
> +	wait_for_completion(&uc_fw->uc_fw_fetched);
> +
> +	DRM_DEBUG_DRIVER("after waiting: %s fw fetch status %d, fw %p\n",
> +		uc_fw->uc_name, uc_fw->uc_fw_fetch_status, uc_fw->uc_fw_blob);
> +
> +	fw = uc_fw->uc_fw_blob;
> +	if (!fw) {
> +		/* no firmware found; try again in case FS was not mounted */
> +		DRM_DEBUG_DRIVER("retry fetching %s fw from <%s>\n",
> +			uc_fw->uc_name, uc_fw->uc_fw_path);
> +		if (request_firmware(&fw, uc_fw->uc_fw_path, &dev->pdev->dev))
> +			goto fail;
> +		DRM_DEBUG_DRIVER("fetch %s fw from <%s> succeeded, fw %p\n",
> +			uc_fw->uc_name, uc_fw->uc_fw_path, fw);
> +		uc_fw->uc_fw_blob = fw;
> +	}
> +
> +	obj = i915_gem_alloc_object(dev, round_up(fw->size, PAGE_SIZE));
> +	if (!obj)
> +		goto fail;
> +
> +	if (i915_gem_object_write(obj, fw->data, fw->size))
> +		goto fail;
> +
> +	DRM_DEBUG_DRIVER("%s fw fetch status SUCCESS\n", uc_fw->uc_name);
> +	uc_fw->uc_fw_obj = obj;
> +	uc_fw->uc_fw_size = fw->size;
> +	uc_fw->uc_fw_fetch_status = INTEL_UC_FIRMWARE_SUCCESS;

We ought to be able to release_firmware() here.

> +	return;
> +
> +fail:
> +	DRM_DEBUG_DRIVER("%s fw fetch status FAIL; fw %p, obj %p\n",
> +		uc_fw->uc_name, fw, obj);
> +	DRM_ERROR("Failed to fetch %s firmware from <%s>\n",
> +		  uc_fw->uc_name, uc_fw->uc_fw_path);
> +
> +	if (obj)
> +		drm_gem_object_unreference(&obj->base);
> +
> +	uc_fw->uc_fw_fetch_status = INTEL_UC_FIRMWARE_FAIL;
> +	uc_fw->uc_fw_blob = NULL;
> +	release_firmware(fw);		/* OK even if fw is NULL */
> +}

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-04-23 17:12 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-17 21:21 [PATCH v3 00/15] *** Command submission via GuC for SKL *** yu.dai
2015-04-17 21:21 ` [PATCH v3 01/15] drm/i915: Add guc firmware interface headers yu.dai
2015-04-17 21:21 ` [PATCH v3 02/15] drm/i915: Add i915_gem_object_write() to i915_gem.c yu.dai
2015-04-21 18:41   ` Dave Gordon
2015-04-21 18:46     ` Dave Gordon
2015-04-17 21:21 ` [PATCH v3 03/15] drm/i915: Unified firmware loading mechanism yu.dai
2015-04-23 17:12   ` Dave Gordon [this message]
2015-04-17 21:21 ` [PATCH v3 04/15] drm/i915: GuC firmware loader yu.dai
2015-04-23 17:48   ` Dave Gordon
2015-04-28 15:12     ` Dave Gordon
2015-04-28 15:18       ` Yu Dai
2015-04-17 21:21 ` [PATCH v3 05/15] drm/i915: Defer default hardware context initialisation until first open yu.dai
2015-04-23 12:25   ` Dave Gordon
2015-04-17 21:21 ` [PATCH v3 06/15] drm/i915: Move execlists defines from .c to .h yu.dai
2015-04-22 14:02   ` Dave Gordon
2015-04-17 21:21 ` [PATCH v3 07/15] drm/i915: Add functions to allocate / release gem obj for GuC yu.dai
2015-04-18 13:47   ` Chris Wilson
2015-04-20 16:02     ` Yu Dai
2015-04-20 19:52       ` Chris Wilson
2015-04-20 20:09         ` Yu Dai
2015-04-20 20:33           ` Chris Wilson
2015-04-21 17:23             ` Dave Gordon
2015-04-21 20:41               ` Chris Wilson
2015-04-17 21:21 ` [PATCH v3 08/15] drm/i915: Functions to support command submission via GuC yu.dai
2015-04-18 13:48   ` Chris Wilson
2015-04-20 16:07     ` Yu Dai
2015-04-20 19:43       ` Chris Wilson
2015-04-20 20:01         ` Yu Dai
2015-04-17 21:21 ` [PATCH v3 09/15] drm/i915: Integration of GuC client yu.dai
2015-04-17 21:21 ` [PATCH v3 10/15] drm/i915: Interrupt routing for GuC scheduler yu.dai
2015-04-17 21:21 ` [PATCH v3 11/15] drm/i915: Enable commands submission via GuC yu.dai
2015-04-17 21:21 ` [PATCH v3 12/15] drm/i915: debugfs of GuC status yu.dai
2015-04-17 21:21 ` [PATCH v3 13/15] drm/i915: Enable GuC firmware log yu.dai
2015-04-17 21:21 ` [PATCH v3 14/15] drm/i915: Taking forcewake during GuC load yu.dai
2015-04-28 15:22   ` Dave Gordon
2015-04-17 21:21 ` [PATCH v3 15/15] Documentation/drm: kerneldoc for GuC yu.dai
2015-04-18  1:13   ` shuang.he

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=553927F2.6060906@intel.com \
    --to=david.s.gordon@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=yu.dai@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox