On Fri, Jan 29, 2016 at 11:58:14AM +0000, Daniele Ceraolo Spurio wrote: > > > On 29/01/16 11:35, Chris Wilson wrote: > >On Fri, Jan 29, 2016 at 11:16:37AM +0000, Daniele Ceraolo Spurio wrote: > >> > >>On 29/01/16 10:58, Chris Wilson wrote: > >>>On Fri, Jan 29, 2016 at 09:21:33AM +0000, daniele.ceraolospurio@xxxxxxxxx wrote: > >>>>From: Daniele Ceraolo Spurio <daniele.ceraolospurio@xxxxxxxxx> > >>>> > >>>>gem_require_ring will submit an execbuf using the provided flags and > >>>>skip the test if the ioctl fails. This test is however designed to catch > >>>>issues with the ioctl, so it should fail if the ioctl fails on a ring > >>>>that the HW possesses. > >>>> > >>>>Instead of using gem_require_ring we can use the getparam ioctl. The new > >>>>checker has been added to the test file and not to the commmon library > >>>>because this test is the only special case where we want to not use > >>>>gem_has_ring > >>>That would be gem_exec_param. > >>>-Chris > >>I don't understand what you mean, can you elaborate a bit? > >For the purposes of checking that the kernel honours the ABI, the tests > >belong in gem_exec_params. > > > >For the purposes of CI, a testing going from PASS -> SKIP is just as > >indicative of a problem as test going from PASS -> FAIL or any other > >state. > > The difference would be that the CI system still reports that BAT > succeeded if one or more tests go from PASS to SKIP (e.g. http://lists.freedesktop.org/archives/intel-gfx/2016-January/086586.html). Fortunately, the results are sometimes even read. > >>What I wanted to fix here is the fact that the logic to skip the > >>test and the test itself are identical, which means that this test > >>can't fail. As far as I can tell gem_exec_param is trying to catch > >>errors in the handling of invalid flags, while in this test we check > >>for errors in the handling of valid flags instead. > >Basically the logic is repeated, that is not an issue for its purpose. > >-Chris > > This patch can be dropped then. But can be refactored for gem_exec_param! -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
