All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Fernando Pacheco <fernando.pacheco@intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/4] drm/i915/uc: Place uC firmware in upper range of GGTT
Date: Wed, 10 Apr 2019 00:04:59 +0100	[thread overview]
Message-ID: <155485109928.692.5270506734378167971@skylake-alporthouse-com> (raw)
In-Reply-To: <78b1e1f4-9720-ac76-0661-208dce379bca@intel.com>

Quoting Fernando Pacheco (2019-04-09 23:53:08)
> 
> On 4/9/19 2:53 PM, Chris Wilson wrote:
> > Quoting Fernando Pacheco (2019-04-09 22:31:01)
> >> +int intel_uc_fw_ggtt_pin(struct intel_uc_fw *uc_fw,
> >> +                        struct i915_ggtt *ggtt, u64 start)
> >> +{
> >> +       struct drm_i915_gem_object *obj = uc_fw->obj;
> >> +       int err;
> >> +
> >> +       err = i915_gem_object_set_to_gtt_domain(obj, false);
> > Currently requires struct_mutex, and is not required as we can ensure
> > the pages are flushed on creation.
> 
> My intent was to maintain what was being done before
> but just doing it earlier.
> 
> But if it's not required..

More so that it's illegal in the global reset context :)

There are patches on the list that remove the struct_mutex for this
operation (eek, no, ignore that you aren't allowed to take that lock
inside reset either!), but with a bit of care we shouldn't need the
set-to-gtt-domain at all as we can do the flush trivially (if it's even
required).

> >> +       if (err) {
> >> +               DRM_DEBUG_DRIVER("%s fw set-domain err=%d\n",
> >> +                                intel_uc_fw_type_repr(uc_fw->type), err);
> >> +               return err;
> >> +       }
> >> +
> >> +       err = i915_gem_object_pin_pages(obj);
> > I'm pretty sure we don't need to pin the pages here, as the caller
> > should be holding the pages already for the duration of the bind.
> >
> > So I think this should just reduce to the ggtt bind.
> 
> I might be misunderstanding, so could you please clarify
> what you mean by "should be holding"? Are you stating
> that the caller already holds the pages?

To copy the firmware image into the pages, those pages must exist. To
prevent those pages disappearing, we must have kept them around (i.e
pinned). So we know by construction of the uc_fw object we always have
the pages, and could skip bumping the pin-count around the xfer.
Therefore we only need to bind the existing firmware pages into the GGTT
to perform the dma xfer (after satisfying ourselves that the pages are
indeed flushed).
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2019-04-09 23:05 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-09 21:30 [PATCH 0/4] Perma-pin uC firmware and re-enable global reset Fernando Pacheco
2019-04-09 21:30 ` [PATCH 1/4] drm/i915/uc: Rename uC firmware init function Fernando Pacheco
2019-04-09 22:08   ` Chris Wilson
2019-04-09 21:31 ` [PATCH 2/4] drm/i915/uc: Reserve upper range of GGTT Fernando Pacheco
2019-04-09 21:41   ` Chris Wilson
2019-04-09 21:43     ` Chris Wilson
2019-04-09 22:40     ` Fernando Pacheco
2019-04-15 22:32     ` Fernando Pacheco
2019-04-16  7:21       ` Chris Wilson
2019-04-09 22:12   ` Daniele Ceraolo Spurio
2019-04-09 21:31 ` [PATCH 3/4] drm/i915/uc: Place uC firmware in " Fernando Pacheco
2019-04-09 21:53   ` Chris Wilson
2019-04-09 22:53     ` Fernando Pacheco
2019-04-09 23:04       ` Chris Wilson [this message]
2019-04-09 22:11   ` Chris Wilson
2019-04-09 23:18     ` Fernando Pacheco
2019-04-09 22:22   ` Chris Wilson
2019-04-16 14:51     ` Fernando Pacheco
2019-04-16 15:04       ` Chris Wilson
2019-04-16 15:21         ` Fernando Pacheco
2019-04-09 21:31 ` [PATCH 4/4] Revert "drm/i915/guc: Disable global reset" Fernando Pacheco
2019-04-09 21:54   ` Chris Wilson
2019-04-16 14:45     ` Fernando Pacheco
2019-04-16 15:05       ` Chris Wilson
2019-04-16 15:10         ` Fernando Pacheco
2019-04-09 22:31 ` ✗ Fi.CI.SPARSE: warning for Perma-pin uC firmware and re-enable global reset Patchwork
2019-04-09 22:56 ` ✗ Fi.CI.BAT: failure " Patchwork

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=155485109928.692.5270506734378167971@skylake-alporthouse-com \
    --to=chris@chris-wilson.co.uk \
    --cc=fernando.pacheco@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.