[Intel-gfx] [PATCH v5] drm/i915: Remove i915.enable_ppgtt override
Chris Wilson
chris at chris-wilson.co.uk
Thu Sep 27 11:07:11 UTC 2018
Quoting Joonas Lahtinen (2018-09-27 11:57:53)
> Quoting Chris Wilson (2018-09-27 11:55:03)
> > Quoting Joonas Lahtinen (2018-09-27 09:20:06)
> > > Quoting Chris Wilson (2018-09-26 23:12:22)
> > > > Now that we are confident in providing full-ppgtt where supported,
> > > > remove the ability to override the context isolation.
> > > >
> > > > v2: Remove faked aliasing-ppgtt for testing as it no longer is accepted.
> > > > v3: s/USES/HAS/ to match usage and reject attempts to load the module on
> > > > old GVT-g setups that do not provide support for full-ppgtt.
> > > > v4: Insulate ABI ppGTT values from our internal enum (later plans
> > > > involve moving ppGTT depth out of the enum, thus potentially breaking
> > > > ABI unless we document the current values).
> > > >
> > > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > > Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> > > > Cc: Matthew Auld <matthew.auld at intel.com>
> > > > Reviewed-by: Joonas Lahtinen <joonas.lahtinen at linux.intel.com> #v3
> > >
> > > + Jani for awareness when handling dinq, this solidifies existing uAPI
> > > And drops the reporting of 48-bit ppGTT through this getparam as we
> > > already have context specific I915_CONTEXT_PARAM_GTT_SIZE for that and
> > > no known abusers for the unintended reporting outside 0,1,2 set.
> >
> > Are we past the 4.20 cutoff? I'd rather have this in 4.21 so that we
> > have a cycle in front of users before sealing the transition.
>
> Yes we are. Just go ahead with the merge.
Done.
-Chris
More information about the Intel-gfx
mailing list