[igt-dev] [PATCH] [i-g-t] tests/i915: Remove I915_CACHING_NONE

[Dixit, Ashutosh]

On Mon, 17 May 2021 02:11:30 -0700, Petri Latvala wrote:
>
> On Wed, May 12, 2021 at 06:46:30PM -0700, Dixit, Ashutosh wrote:
> > On Sun, 18 Apr 2021 23:42:54 -0700, Dixit, Ashutosh wrote:
> > >
> > > On Sun, 18 Apr 2021 23:09:28 -0700, <viswax.krishna.raveendra.talabattula at intel.com> wrote:
> > > >
> > > > From: Viswa Krishna Raveendra Talabattula <viswax.krishna.raveendra.talabattula at intel.com>
> > > >
> > > > The userptr memory does not support I915_CACHING_NONE(no caching) level
> > > > as per the below commit related to i915 in the kernel
> > > >
> > > > drm/i915: Reject more ioctls for userptr, v2.
> > > >
> > > > Hence removing the cache level of I915_CACHING_NONE from the test case
> > >
> > > Instead of dropping the test should we check for -ENXIO return?
> >
> > Because setting I915_CACHING_NONE on a userptr is not an unreasonable
> > operation, if it is not supported IMO IGT should check for an -ENXIO return
> > if someone tries to set I915_CACHING_NONE.
> >
> > The only complication here is that this is a ABI change. So if IGT runs on
> > an older kernel set_caching() will return 0 whereas it will return -ENXIO
> > with a new kernel. There seems to be no way of determining a priori what
> > the expected return is.
> >
> > I am copying Petri too. Checking for both 0 and -ENXIO would sort of defeat
> > the purpose. Also, having the IGT fail on older kernels is also probably
> > unacceptable.
>
> There is some value in making sure the operation doesn't fail with
> something funky like ECONNREFUSED. How much value, that depends, up to
> you.
>
> Is it an option to have this mapping:
>
> ENXIO - pass
> 0 - warn, with something like "kernel behaves in a deprecated way"
> anything else - fail

Thanks, I think that's a good idea. So for now let's have the test pass on
both -ENXIO and 0 return code, but if the return code is 0 let's do an
igt_warn("Deprecated return code 0 from __gem_set_caching").