Re: [PATCH 02/15] drm/i915: Embedded microcontroller (uC) firmware loading support

From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Daniel Vetter <daniel@ffwll.ch>,
	Dave Gordon <david.s.gordon@intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 02/15] drm/i915: Embedded microcontroller (uC) firmware loading support
Date: Thu, 18 Jun 2015 17:35:29 +0200	[thread overview]
Message-ID: <20150618153529.GJ7752@phenom.ffwll.local> (raw)
In-Reply-To: <20150618152752.GO24012@nuc-i3427.alporthouse.com>

On Thu, Jun 18, 2015 at 04:27:52PM +0100, Chris Wilson wrote:
> On Thu, Jun 18, 2015 at 04:49:49PM +0200, Daniel Vetter wrote:
> > Guc is different since we really must have it ready for execbuf, and for
> > that usecase a completion at drm_open time sounds like the right thing.
> 
> But do we? It would be nice if we had a definite answer that the hw was
> ready before we started using it in anger, but I don't see any reason
> why we would have to delay userspace for a slow microcode update...
> 
> (This presupposes that userspace batches are unaffected by GuC/execlist
> setup, which for userspace sanity I hope they are - or at least using
> predicate registers and conditional execution.)

Well I figured a wait_completion or flush_work unconditionally in execbuf
is not to your liking, and it's better to keep that in open. But I think
we should be able to get away with this at execbuf time. Might even be
better since this wouldn't block sw-rendered boot-splashs.

But either way should be suitable I think.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx