From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by gabe.freedesktop.org (Postfix) with ESMTPS id 574BA6EA31 for ; Mon, 17 May 2021 18:34:27 +0000 (UTC) Date: Mon, 17 May 2021 11:34:26 -0700 Message-ID: <8735ulryz1.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" In-Reply-To: References: <20210419060928.671111-1-viswax.krishna.raveendra.talabattula@intel.com> <87sg3mpyfl.wl-ashutosh.dixit@intel.com> <87h7j7csnd.wl-ashutosh.dixit@intel.com> MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Subject: Re: [igt-dev] [PATCH] [i-g-t] tests/i915: Remove I915_CACHING_NONE List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: igt-dev-bounces@lists.freedesktop.org Sender: "igt-dev" To: Petri Latvala Cc: igt-dev@lists.freedesktop.org, hariom.pandey@intel.com List-ID: 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, wrote: > > > > > > > > From: Viswa Krishna Raveendra Talabattula > > > > > > > > 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"). _______________________________________________ igt-dev mailing list igt-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/igt-dev