[Intel-gfx] [PATCH igt v3 04/11] igt/gem_exec_parse: update hsw_load_register_reg
Matthew Auld
matthew.william.auld at gmail.com
Fri Nov 11 22:01:36 UTC 2016
On 9 November 2016 at 16:15, Robert Bragg <robert at sixbynine.org> wrote:
> This generalises hsw_load_register_reg to loop through an array of
> allowed and disallowed registers and to use the exec_batch[_patched]
> utilities.
>
> Signed-off-by: Robert Bragg <robert at sixbynine.org>
> ---
> tests/gem_exec_parse.c | 139 +++++++++++++++++++++++--------------------------
> 1 file changed, 66 insertions(+), 73 deletions(-)
>
> diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
> index c530bb6..2fea060 100644
> --- a/tests/gem_exec_parse.c
> +++ b/tests/gem_exec_parse.c
> @@ -34,8 +34,11 @@
> #define I915_PARAM_CMD_PARSER_VERSION 28
> #endif
>
> -#define OACONTROL 0x2360
> +#define ARRAY_LEN(A) (sizeof(A) / sizeof(A[0]))
We have ARRAY_SIZE.
> +
> #define DERRMR 0x44050
> +#define OACONTROL 0x2360
> +#define SO_WRITE_OFFSET_0 0x5280
>
> #define HSW_CS_GPR(n) (0x2600 + 8*(n))
> #define HSW_CS_GPR0 HSW_CS_GPR(0)
> @@ -65,8 +68,8 @@ static int command_parser_version(int fd)
> return -1;
> }
>
> -static void exec_batch_patched(int fd, uint32_t cmd_bo, uint32_t *cmds,
> - int size, int patch_offset, uint64_t expected_value)
> +static uint64_t __exec_batch_patched(int fd, uint32_t cmd_bo, uint32_t *cmds,
> + int size, int patch_offset)
> {
> struct drm_i915_gem_execbuffer2 execbuf;
> struct drm_i915_gem_exec_object2 obj[2];
> @@ -100,9 +103,19 @@ static void exec_batch_patched(int fd, uint32_t cmd_bo, uint32_t *cmds,
> gem_sync(fd, cmd_bo);
>
> gem_read(fd,target_bo, 0, &actual_value, sizeof(actual_value));
> - igt_assert_eq(expected_value, actual_value);
>
> gem_close(fd, target_bo);
> +
> + return actual_value;
> +}
> +
> +static void exec_batch_patched(int fd, uint32_t cmd_bo, uint32_t *cmds,
> + int size, int patch_offset,
> + uint64_t expected_value)
> +{
> + igt_assert_eq(__exec_batch_patched(fd, cmd_bo, cmds,
> + size, patch_offset),
> + expected_value);
Formatting seems off.
Seems reasonable so:
Reviewed-by: Matthew Auld <matthew.auld at intel.com>
More information about the Intel-gfx
mailing list