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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
