Hi Janusz, On Fri, 12 Aug 2022 11:53:44 +0200 Janusz Krzysztofik <janusz.krzyszto...@linux.intel.com> wrote:
It seems that there is a numeration issue on this series, as the patches on it are: [PATCH i-g-t 1/3] tests/gem_exec_fence: Fix wrong engine checked for store_dword capability [PATCH i-g-t v2 2/3] tests/gem_exec_fence: Exclude 0 from use in store batches [PATCH i-g-t v3 3/3] tests/gem_exec_fence: Restore pre-hang checks in *await-hang scenarios Maybe some broken script? It is also missing a cover letter. > Commit ed7c8cfb67e3 ("tests/i915/gem_exec_fence: Add > __for_each_physical_engine to utilize all engines."), while replacing > depraciated for_each_physical_engine(e, fd) loop with > __for_each_physical_engine(fd, e2) and gem_can_store_dword() inside that > loop with gem_class_can_store_dword(), didn't switch to e2 consequently -- > eb_ring(e) argument of gem_can_store_dword() was replaced with e->class > passed to gem_class_can_store_dword() instead of e2->class. As a result, > a batch that stores dword is now submitted to all engines, also those that > don't support that operation. Fix it. > > Signed-off-by: Janusz Krzysztofik <janusz.krzyszto...@linux.intel.com> > Cc: Mauro Carvalho Chehab <mauro.che...@linux.intel.com> LGTM. Reviewed-by: Mauro Carvalho Chehab <mche...@kernel.org> > --- > tests/i915/gem_exec_fence.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/i915/gem_exec_fence.c b/tests/i915/gem_exec_fence.c > index 7ff7614dad..048870053a 100644 > --- a/tests/i915/gem_exec_fence.c > +++ b/tests/i915/gem_exec_fence.c > @@ -331,7 +331,7 @@ static void test_fence_await(int fd, const intel_ctx_t > *ctx, > > i = 0; > for_each_ctx_engine(fd, ctx, e2) { > - if (!gem_class_can_store_dword(fd, e->class)) > + if (!gem_class_can_store_dword(fd, e2->class)) > continue; > > if (flags & NONBLOCK) {