[Intel-gfx] [PATCH] drm/i915: Don't use enums for hardware engine id
Michal Wajdeczko
michal.wajdeczko at intel.com
Wed Mar 1 19:35:59 UTC 2017
On Tue, Feb 28, 2017 at 09:53:37PM +0000, Chris Wilson wrote:
> On Tue, Feb 28, 2017 at 07:07:38PM +0100, Michal Wajdeczko wrote:
> > On Tue, Feb 28, 2017 at 04:52:34PM +0000, Chris Wilson wrote:
> > > On Tue, Feb 28, 2017 at 04:43:02PM +0000, Chris Wilson wrote:
> > > > On Tue, Feb 28, 2017 at 02:12:09PM +0000, Michal Wajdeczko wrote:
> > > > > +/* Hardware Engine ID definitions */
> > > > > +#define RCS_HW 0
> > > > > +#define VCS_HW 1
> > > > > +#define BCS_HW 2
> > > > > +#define VECS_HW 3
> > > > > +#define VCS2_HW 4
> > > >
> > > > So don't put them in the header if they may have inconsistent meanings.
> > >
> > > Or if you do want to keep them in a header, either i915_reg.h or
> > > intel_engine_reg.h as somewhere out of the way, and clear that they are
> > > not meant for the rest of the bookkeeping in intel_ringbuffer.h.
> >
> > I can't find nice spot for these engine IDs in the i915_reg.h
> >
> > Can I just move these definitions to the top of this header?
>
> I would rather we spend a little effort on splitting our driver API from
> hw innards.
Sounds reasonable.
As it looks that engine->hw_id is mostly used in code related to semaphores,
I'll move these engine definitions to i915_reg.h near MI_SEMAPHORE_SIGNAL
instruction.
In case of guc_id, it looks that these engine ids are already defined in
intel_guc_fwif.h (see GUC_RENDER_ENGINE..GUC_VIDEO_ENGINE2)
For now they are the same, but who knows what the future brings ;)
-Michal
More information about the Intel-gfx
mailing list