[Intel-gfx] [CI v2 2/2] drm/i915/guc: Introduce buffer based cmd transport

[Chris Wilson]

On Tue, May 23, 2017 at 11:59:46AM -0700, Daniele Ceraolo Spurio wrote:
> On 22/05/17 04:30, Michal Wajdeczko wrote:
> >+static int ctch_init(struct intel_guc *guc,
> >+		     struct intel_guc_ct_channel *ctch)
> >+{
> >+	struct i915_vma *vma;
> >+	void *blob;
> >+	int err;
> >+	int i;
> >+
> >+	GEM_BUG_ON(ctch->vma);
> >+
> >+#if INTEL_GUC_CT_MAX_CHANNELS > 1
> 
> Bikeshed: after reviewing the GuC design intent for CT buffers I
> think we can remove the ida logic completely, even if
> INTEL_GUC_CT_MAX_CHANNELS > 1. Currently we don't expect more than 1
> pair, but, if my understanding is correct, in case we ever need more
> than 1 channel the number should be statically determined and not a
> dynamic thing. I would therefore prefer a static define for it.
> e.g.:
> 
> #define GUC_KMD_CTCH 0
> 
> and if we ever have more:
> 
> #define GUC_xxx_CTCH 1
> #define GUC_yyy_CTCH 2
> 
> We can then pass in the owner when we open the channel:
> 
> ctch_open(guc, ctch, GUC_KMD_CTCH);

If we do forsee that we don't need an ida for the at least the near
future, can we kill it? I'm still dubious about having
INTEL_GUC_CT_MAX_CHANNELS around not tied to any hw/fw concepts or
limits. At the least if you do split the ida into a separate patch, you
can apply it when you need it later.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre