Re: [PATCH] drm/i915: Don't use enums for hardware engine id

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux