[Intel-gfx] [PATCH 07/23] drm/i915: Move HAS_GUC_UCODE definition to platform definition
Daniel Vetter
daniel at ffwll.ch
Tue Aug 2 14:16:59 UTC 2016
On Tue, Aug 02, 2016 at 11:10:46AM +0100, Dave Gordon wrote:
> On 21/07/16 18:10, Dave Gordon wrote:
> > On 21/07/16 11:38, Tvrtko Ursulin wrote:
> > >
> > > On 20/07/16 22:07, Rodrigo Vivi wrote:
> > > > please kill this _ucode variation that is just a alias to guc
> > > > instead....
> > >
> > > Not sure, it was added with a particular goal. Cc Dave in case he wants
> > > to comment.
> > >
> > > Regards,
> > > Tvrtko
> >
> > The comment is already in the source code, just above the lines that
> > this patch changes.
> >
> > .Dave.
>
> Which is to say that,
> + having a GuC that can be used for command submission
> + having a GuC that requires firmware before use
> are logically distinct properties, and are both subsets of
> * having GuC hardware.
>
> We can *imagine* products that might:
>
> (1) have a GuC that requires firmware before use ...
> (2) have a GuC with predefined but reloadable firmware ...
> (3) have a GuC that contains a permanent firmware image ...
> x
> (a) ... which supports command submission but not SLPC
> (b) ... which supports both command submission and SLPC
> (c) ... which supports SLPC but not command submission
>
> where all combinations are logically plausible, even though we only have
> (1a) in today's devices. So we might as well make future development easier
> rather than more difficult; it is always easier to make different things
> equivalent than to separate identical things into different cases.
Let's please not add code for everything we can imagine. If there's a
product in the pipeline for which the above is true then sure, makes sense
(but needs one of the generic "needed for future platforms" notice in the
commit message). Otherwise I'll vote to nuke the difference.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the Intel-gfx
mailing list