On Tue, Nov 22, 2016 at 03:45:59PM +0000, Chris Wilson wrote: > On Mon, Nov 14, 2016 at 08:51:21PM +0000, Robert Bragg wrote: > > This combines some parts of the recently added store_lri test with the > > registers test to be able to first load a distinguishable value before > > the LRI and explicitly read back the register to determine if the > > command succeeded or was a NOOP. > > > > For now though we won't look at OACONTROL without checking for version 9 > > of the command parser. > > > > This updates the 'bad' test to check the OASTATUS2 register so that we > > can explicitly read back from the register to check it becomes a NOOP. > > > > This adds a struct test_lri for associating a mask with the init/test > > values so we ignore things like hw status bits that might interfere > > with the result. > > > > Signed-off-by: Robert Bragg <robert@xxxxxxxxxxxxx> > > Reviewed-by: Matthew Auld <matthew.auld@xxxxxxxxx> > > --- > > tests/gem_exec_parse.c | 94 ++++++++++++++++++++++++++------------------------ > > 1 file changed, 49 insertions(+), 45 deletions(-) > > > > diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c > > index 2bc6340..43f25ce 100644 > > --- a/tests/gem_exec_parse.c > > +++ b/tests/gem_exec_parse.c > > @@ -35,6 +35,7 @@ > > #endif > > > > #define DERRMR 0x44050 > > +#define OASTATUS2 0x2368 > > #define OACONTROL 0x2360 > > #define SO_WRITE_OFFSET_0 0x5280 > > > > @@ -253,27 +254,35 @@ static void exec_batch_chained(int fd, uint32_t cmd_bo, uint32_t *cmds, > > gem_close(fd, target_bo); > > } > > > > -static void stray_lri(int fd, uint32_t handle) > > Ahem. Why did you remove that agnostic test without replacing it? In a later patch, that was annoying. But it is not being tested for the rejection. test_lri() doesn't check the register write took (always useful to test the setup first), nor does it provide a good hint as to which lri failed. Either that needs expanding upon, or the multiple tests extracted into separate subtests. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx