All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] tests/gen7_forcewake_mt: Don't set the GGTT bit in SRM command
@ 2014-04-08 21:22 bradley.d.volkin
  2014-04-09  6:20 ` Chris Wilson
  0 siblings, 1 reply; 8+ messages in thread
From: bradley.d.volkin @ 2014-04-08 21:22 UTC (permalink / raw)
  To: intel-gfx

From: Brad Volkin <bradley.d.volkin@intel.com>

The command parser in newer kernels will reject it and setting this
bit is not required for the actual test case.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76670
Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
---
 tests/gen7_forcewake_mt.c | 55 +++++++++++++++++++++++++----------------------
 1 file changed, 29 insertions(+), 26 deletions(-)

diff --git a/tests/gen7_forcewake_mt.c b/tests/gen7_forcewake_mt.c
index fdc34ce..3afd80a 100644
--- a/tests/gen7_forcewake_mt.c
+++ b/tests/gen7_forcewake_mt.c
@@ -121,7 +121,7 @@ static void *thread(void *arg)
 }
 
 #define MI_LOAD_REGISTER_IMM                    (0x22<<23)
-#define MI_STORE_REGISTER_MEM                   (0x24<<23| 1<<22)
+#define MI_STORE_REGISTER_MEM                   (0x24<<23)
 
 igt_simple_main
 {
@@ -140,8 +140,9 @@ igt_simple_main
 	sleep(2);
 
 	for (i = 0; i < 1000; i++) {
+		uint32_t *p;
 		struct drm_i915_gem_execbuffer2 execbuf;
-		struct drm_i915_gem_exec_object2 exec;
+		struct drm_i915_gem_exec_object2 exec[2];
 		struct drm_i915_gem_relocation_entry reloc[2];
 		uint32_t b[] = {
 			MI_LOAD_REGISTER_IMM | 1,
@@ -149,54 +150,56 @@ igt_simple_main
 			2 << 16 | 2,
 			MI_STORE_REGISTER_MEM | 1,
 			FORCEWAKE_MT,
-			5*sizeof(uint32_t),
+			0, // to be patched
 			MI_LOAD_REGISTER_IMM | 1,
 			FORCEWAKE_MT,
 			2 << 16,
 			MI_STORE_REGISTER_MEM | 1,
 			FORCEWAKE_MT,
-			11*sizeof(uint32_t),
+			1 * sizeof(uint32_t), // to be patched
 			MI_BATCH_BUFFER_END,
 			0
 		};
 
-		memset(&exec, 0, sizeof(exec));
-		exec.handle = gem_create(t[0].fd, 4096);
-		exec.relocation_count = 2;
-		exec.relocs_ptr = (uintptr_t)reloc;
-		//exec.flags = EXEC_OBJECT_NEEDS_GTT;
-		gem_write(t[0].fd, exec.handle, 0, b, sizeof(b));
+		memset(exec, 0, sizeof(exec));
+		exec[1].handle = gem_create(t[0].fd, 4096);
+		exec[1].relocation_count = 2;
+		exec[1].relocs_ptr = (uintptr_t)reloc;
+		gem_write(t[0].fd, exec[1].handle, 0, b, sizeof(b));
+		exec[0].handle = gem_create(t[0].fd, 4096);
 
 		reloc[0].offset = 5 * sizeof(uint32_t);
-		reloc[0].delta = 5 * sizeof(uint32_t);
-		reloc[0].target_handle = exec.handle;
-		reloc[0].read_domains = I915_GEM_DOMAIN_INSTRUCTION;
-		reloc[0].write_domain = 0;
+		reloc[0].delta = 0;
+		reloc[0].target_handle = exec[0].handle;
+		reloc[0].read_domains = I915_GEM_DOMAIN_RENDER;
+		reloc[0].write_domain = I915_GEM_DOMAIN_RENDER;
 		reloc[0].presumed_offset = 0;
 
 		reloc[1].offset = 11 * sizeof(uint32_t);
-		reloc[1].delta = 11 * sizeof(uint32_t);
-		reloc[1].target_handle = exec.handle;
-		reloc[1].read_domains = I915_GEM_DOMAIN_INSTRUCTION;
-		reloc[1].write_domain = 0;
+		reloc[1].delta = 1 * sizeof(uint32_t);
+		reloc[1].target_handle = exec[0].handle;
+		reloc[1].read_domains = I915_GEM_DOMAIN_RENDER;
+		reloc[1].write_domain = I915_GEM_DOMAIN_RENDER;
 		reloc[1].presumed_offset = 0;
 
 		memset(&execbuf, 0, sizeof(execbuf));
 		execbuf.buffers_ptr = (uintptr_t)&exec;
-		execbuf.buffer_count = 1;
+		execbuf.buffer_count = 2;
 		execbuf.batch_len = sizeof(b);
 		execbuf.flags = I915_EXEC_SECURE;
 
 		gem_execbuf(t[0].fd, &execbuf);
-		gem_sync(t[0].fd, exec.handle);
-		gem_read(t[0].fd, exec.handle, 0, b, sizeof(b));
-		gem_close(t[0].fd, exec.handle);
+		gem_sync(t[0].fd, exec[1].handle);
 
-		printf("[%d]={ %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x }\n",
-		       i, b[0], b[1], b[2], b[3], b[4], b[5], b[6], b[7], b[8], b[9], b[10], b[11], b[12]);
+		p = gem_mmap(t[0].fd, exec[0].handle, 4096, PROT_READ);
 
-		igt_assert(b[5] & 2);
-		igt_assert((b[11] & 2) == 0);
+		printf("[%d]={ %08x %08x }\n", i, p[0], p[1]);
+		igt_assert(p[0] & 2);
+		igt_assert((p[1] & 2) == 0);
+
+		munmap(p, 4096);
+		gem_close(t[0].fd, exec[0].handle);
+		gem_close(t[0].fd, exec[1].handle);
 
 		usleep(1000);
 	}
-- 
1.8.3.2

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH] tests/gen7_forcewake_mt: Don't set the GGTT bit in SRM command
  2014-04-08 21:22 [PATCH] tests/gen7_forcewake_mt: Don't set the GGTT bit in SRM command bradley.d.volkin
@ 2014-04-09  6:20 ` Chris Wilson
  2014-04-09 13:32   ` Daniel Vetter
  2014-04-09 15:12   ` Volkin, Bradley D
  0 siblings, 2 replies; 8+ messages in thread
From: Chris Wilson @ 2014-04-09  6:20 UTC (permalink / raw)
  To: bradley.d.volkin; +Cc: intel-gfx

On Tue, Apr 08, 2014 at 02:22:16PM -0700, bradley.d.volkin@intel.com wrote:
> From: Brad Volkin <bradley.d.volkin@intel.com>
> 
> The command parser in newer kernels will reject it and setting this
> bit is not required for the actual test case.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76670
> Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>

This was written how I did in the ddx...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] tests/gen7_forcewake_mt: Don't set the GGTT bit in SRM command
  2014-04-09  6:20 ` Chris Wilson
@ 2014-04-09 13:32   ` Daniel Vetter
  2014-04-09 15:12   ` Volkin, Bradley D
  1 sibling, 0 replies; 8+ messages in thread
From: Daniel Vetter @ 2014-04-09 13:32 UTC (permalink / raw)
  To: Chris Wilson, bradley.d.volkin, intel-gfx

On Wed, Apr 09, 2014 at 07:20:30AM +0100, Chris Wilson wrote:
> On Tue, Apr 08, 2014 at 02:22:16PM -0700, bradley.d.volkin@intel.com wrote:
> > From: Brad Volkin <bradley.d.volkin@intel.com>
> > 
> > The command parser in newer kernels will reject it and setting this
> > bit is not required for the actual test case.
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76670
> > Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
> 
> This was written how I did in the ddx...

Oops, sounds like the cmd parser needs to transparently set this when
copying to the hidden batch ... We could of course do some magic in the
kernel and let it pass, but my current plan is that we'll enable the cmd
parser for secure batches only (to avoid the heft perf hit and that's
essentially no worse than what we have already), so that Xorg and mesa
don't need to be run as root on hsw.

But that means for at least sensible test coverage we should still
scan/copy even root batches since until fc22 (or whatever it was) ships we
won't have many systems with non-root X out there yet for testing.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] tests/gen7_forcewake_mt: Don't set the GGTT bit in SRM command
  2014-04-09  6:20 ` Chris Wilson
  2014-04-09 13:32   ` Daniel Vetter
@ 2014-04-09 15:12   ` Volkin, Bradley D
  2014-04-09 16:47     ` Daniel Vetter
  1 sibling, 1 reply; 8+ messages in thread
From: Volkin, Bradley D @ 2014-04-09 15:12 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

On Tue, Apr 08, 2014 at 11:20:30PM -0700, Chris Wilson wrote:
> On Tue, Apr 08, 2014 at 02:22:16PM -0700, bradley.d.volkin@intel.com wrote:
> > From: Brad Volkin <bradley.d.volkin@intel.com>
> > 
> > The command parser in newer kernels will reject it and setting this
> > bit is not required for the actual test case.
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76670
> > Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
> 
> This was written how I did in the ddx...

Oh, I thought you had said that the ddx didn't use MI_STORE_REGISTER_MEM, and
I didn't see it used in the current ddx code, so I thought that part of the
test wasn't relevant to the actual workaround. It looked like it was just a
write so we could see the values and check that they were updated. But if it
is, then yeah, I don't want to change the test behavior.

Brad

> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] tests/gen7_forcewake_mt: Don't set the GGTT bit in SRM command
  2014-04-09 15:12   ` Volkin, Bradley D
@ 2014-04-09 16:47     ` Daniel Vetter
  2014-04-22 16:45       ` Volkin, Bradley D
  0 siblings, 1 reply; 8+ messages in thread
From: Daniel Vetter @ 2014-04-09 16:47 UTC (permalink / raw)
  To: Volkin, Bradley D; +Cc: intel-gfx

On Wed, Apr 09, 2014 at 08:12:28AM -0700, Volkin, Bradley D wrote:
> On Tue, Apr 08, 2014 at 11:20:30PM -0700, Chris Wilson wrote:
> > On Tue, Apr 08, 2014 at 02:22:16PM -0700, bradley.d.volkin@intel.com wrote:
> > > From: Brad Volkin <bradley.d.volkin@intel.com>
> > > 
> > > The command parser in newer kernels will reject it and setting this
> > > bit is not required for the actual test case.
> > > 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76670
> > > Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
> > 
> > This was written how I did in the ddx...
> 
> Oh, I thought you had said that the ddx didn't use MI_STORE_REGISTER_MEM, and
> I didn't see it used in the current ddx code, so I thought that part of the
> test wasn't relevant to the actual workaround. It looked like it was just a
> write so we could see the values and check that they were updated. But if it
> is, then yeah, I don't want to change the test behavior.

Hm right I think Chris said that in the ended he never released a ddx
version with this code. Now I'm indeed rather confused what's going on. If
we don't need it I obviously prefer less complexity in the kernel cmd
parser.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] tests/gen7_forcewake_mt: Don't set the GGTT bit in SRM command
  2014-04-09 16:47     ` Daniel Vetter
@ 2014-04-22 16:45       ` Volkin, Bradley D
  0 siblings, 0 replies; 8+ messages in thread
From: Volkin, Bradley D @ 2014-04-22 16:45 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

On Wed, Apr 09, 2014 at 09:47:57AM -0700, Daniel Vetter wrote:
> On Wed, Apr 09, 2014 at 08:12:28AM -0700, Volkin, Bradley D wrote:
> > On Tue, Apr 08, 2014 at 11:20:30PM -0700, Chris Wilson wrote:
> > > On Tue, Apr 08, 2014 at 02:22:16PM -0700, bradley.d.volkin@intel.com wrote:
> > > > From: Brad Volkin <bradley.d.volkin@intel.com>
> > > > 
> > > > The command parser in newer kernels will reject it and setting this
> > > > bit is not required for the actual test case.
> > > > 
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76670
> > > > Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
> > > 
> > > This was written how I did in the ddx...
> > 
> > Oh, I thought you had said that the ddx didn't use MI_STORE_REGISTER_MEM, and
> > I didn't see it used in the current ddx code, so I thought that part of the
> > test wasn't relevant to the actual workaround. It looked like it was just a
> > write so we could see the values and check that they were updated. But if it
> > is, then yeah, I don't want to change the test behavior.
> 
> Hm right I think Chris said that in the ended he never released a ddx
> version with this code. Now I'm indeed rather confused what's going on. If
> we don't need it I obviously prefer less complexity in the kernel cmd
> parser.

Chris, can you help clarify this?

Thanks,
Brad

> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] tests/gen7_forcewake_mt: Don't set the GGTT bit in SRM command
  2014-05-10 21:11 bradley.d.volkin
@ 2014-05-12 16:50 ` Daniel Vetter
  0 siblings, 0 replies; 8+ messages in thread
From: Daniel Vetter @ 2014-05-12 16:50 UTC (permalink / raw)
  To: bradley.d.volkin; +Cc: intel-gfx

On Sat, May 10, 2014 at 02:11:53PM -0700, bradley.d.volkin@intel.com wrote:
> From: Brad Volkin <bradley.d.volkin@intel.com>
> 
> The command parser in newer kernels will reject it and setting this
> bit is not required for the actual test case.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76670
> Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
> ---
> 
> This is a resend of
> http://lists.freedesktop.org/archives/intel-gfx/2014-April/043223.html
> 
> There was initially some discussion as to the fact that the test was
> written to reflect the implementation of a workaround in the ddx and
> whether this patch lead to a deviation between the two. There was no
> real closure on that discussion, however, I don't believe the
> MI_STORE_REGISTER_MEM aspect of the test is relevant to the ddx code,
> so I'd like to move forward with this or get clear direction on the
> preferred solution.

Afaik Chris agreed that we've never shipped with this, so changing it is
ok. If we're proven wrong we can look at this again. Patch merged to igt,
thanks.
-Daniel
> 
>  tests/gen7_forcewake_mt.c | 55 +++++++++++++++++++++++++----------------------
>  1 file changed, 29 insertions(+), 26 deletions(-)
> 
> diff --git a/tests/gen7_forcewake_mt.c b/tests/gen7_forcewake_mt.c
> index fdc34ce..3afd80a 100644
> --- a/tests/gen7_forcewake_mt.c
> +++ b/tests/gen7_forcewake_mt.c
> @@ -121,7 +121,7 @@ static void *thread(void *arg)
>  }
>  
>  #define MI_LOAD_REGISTER_IMM                    (0x22<<23)
> -#define MI_STORE_REGISTER_MEM                   (0x24<<23| 1<<22)
> +#define MI_STORE_REGISTER_MEM                   (0x24<<23)
>  
>  igt_simple_main
>  {
> @@ -140,8 +140,9 @@ igt_simple_main
>  	sleep(2);
>  
>  	for (i = 0; i < 1000; i++) {
> +		uint32_t *p;
>  		struct drm_i915_gem_execbuffer2 execbuf;
> -		struct drm_i915_gem_exec_object2 exec;
> +		struct drm_i915_gem_exec_object2 exec[2];
>  		struct drm_i915_gem_relocation_entry reloc[2];
>  		uint32_t b[] = {
>  			MI_LOAD_REGISTER_IMM | 1,
> @@ -149,54 +150,56 @@ igt_simple_main
>  			2 << 16 | 2,
>  			MI_STORE_REGISTER_MEM | 1,
>  			FORCEWAKE_MT,
> -			5*sizeof(uint32_t),
> +			0, // to be patched
>  			MI_LOAD_REGISTER_IMM | 1,
>  			FORCEWAKE_MT,
>  			2 << 16,
>  			MI_STORE_REGISTER_MEM | 1,
>  			FORCEWAKE_MT,
> -			11*sizeof(uint32_t),
> +			1 * sizeof(uint32_t), // to be patched
>  			MI_BATCH_BUFFER_END,
>  			0
>  		};
>  
> -		memset(&exec, 0, sizeof(exec));
> -		exec.handle = gem_create(t[0].fd, 4096);
> -		exec.relocation_count = 2;
> -		exec.relocs_ptr = (uintptr_t)reloc;
> -		//exec.flags = EXEC_OBJECT_NEEDS_GTT;
> -		gem_write(t[0].fd, exec.handle, 0, b, sizeof(b));
> +		memset(exec, 0, sizeof(exec));
> +		exec[1].handle = gem_create(t[0].fd, 4096);
> +		exec[1].relocation_count = 2;
> +		exec[1].relocs_ptr = (uintptr_t)reloc;
> +		gem_write(t[0].fd, exec[1].handle, 0, b, sizeof(b));
> +		exec[0].handle = gem_create(t[0].fd, 4096);
>  
>  		reloc[0].offset = 5 * sizeof(uint32_t);
> -		reloc[0].delta = 5 * sizeof(uint32_t);
> -		reloc[0].target_handle = exec.handle;
> -		reloc[0].read_domains = I915_GEM_DOMAIN_INSTRUCTION;
> -		reloc[0].write_domain = 0;
> +		reloc[0].delta = 0;
> +		reloc[0].target_handle = exec[0].handle;
> +		reloc[0].read_domains = I915_GEM_DOMAIN_RENDER;
> +		reloc[0].write_domain = I915_GEM_DOMAIN_RENDER;
>  		reloc[0].presumed_offset = 0;
>  
>  		reloc[1].offset = 11 * sizeof(uint32_t);
> -		reloc[1].delta = 11 * sizeof(uint32_t);
> -		reloc[1].target_handle = exec.handle;
> -		reloc[1].read_domains = I915_GEM_DOMAIN_INSTRUCTION;
> -		reloc[1].write_domain = 0;
> +		reloc[1].delta = 1 * sizeof(uint32_t);
> +		reloc[1].target_handle = exec[0].handle;
> +		reloc[1].read_domains = I915_GEM_DOMAIN_RENDER;
> +		reloc[1].write_domain = I915_GEM_DOMAIN_RENDER;
>  		reloc[1].presumed_offset = 0;
>  
>  		memset(&execbuf, 0, sizeof(execbuf));
>  		execbuf.buffers_ptr = (uintptr_t)&exec;
> -		execbuf.buffer_count = 1;
> +		execbuf.buffer_count = 2;
>  		execbuf.batch_len = sizeof(b);
>  		execbuf.flags = I915_EXEC_SECURE;
>  
>  		gem_execbuf(t[0].fd, &execbuf);
> -		gem_sync(t[0].fd, exec.handle);
> -		gem_read(t[0].fd, exec.handle, 0, b, sizeof(b));
> -		gem_close(t[0].fd, exec.handle);
> +		gem_sync(t[0].fd, exec[1].handle);
>  
> -		printf("[%d]={ %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x }\n",
> -		       i, b[0], b[1], b[2], b[3], b[4], b[5], b[6], b[7], b[8], b[9], b[10], b[11], b[12]);
> +		p = gem_mmap(t[0].fd, exec[0].handle, 4096, PROT_READ);
>  
> -		igt_assert(b[5] & 2);
> -		igt_assert((b[11] & 2) == 0);
> +		printf("[%d]={ %08x %08x }\n", i, p[0], p[1]);
> +		igt_assert(p[0] & 2);
> +		igt_assert((p[1] & 2) == 0);
> +
> +		munmap(p, 4096);
> +		gem_close(t[0].fd, exec[0].handle);
> +		gem_close(t[0].fd, exec[1].handle);
>  
>  		usleep(1000);
>  	}
> -- 
> 1.8.3.2
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH] tests/gen7_forcewake_mt: Don't set the GGTT bit in SRM command
@ 2014-05-10 21:11 bradley.d.volkin
  2014-05-12 16:50 ` Daniel Vetter
  0 siblings, 1 reply; 8+ messages in thread
From: bradley.d.volkin @ 2014-05-10 21:11 UTC (permalink / raw)
  To: intel-gfx

From: Brad Volkin <bradley.d.volkin@intel.com>

The command parser in newer kernels will reject it and setting this
bit is not required for the actual test case.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76670
Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
---

This is a resend of
http://lists.freedesktop.org/archives/intel-gfx/2014-April/043223.html

There was initially some discussion as to the fact that the test was
written to reflect the implementation of a workaround in the ddx and
whether this patch lead to a deviation between the two. There was no
real closure on that discussion, however, I don't believe the
MI_STORE_REGISTER_MEM aspect of the test is relevant to the ddx code,
so I'd like to move forward with this or get clear direction on the
preferred solution.

 tests/gen7_forcewake_mt.c | 55 +++++++++++++++++++++++++----------------------
 1 file changed, 29 insertions(+), 26 deletions(-)

diff --git a/tests/gen7_forcewake_mt.c b/tests/gen7_forcewake_mt.c
index fdc34ce..3afd80a 100644
--- a/tests/gen7_forcewake_mt.c
+++ b/tests/gen7_forcewake_mt.c
@@ -121,7 +121,7 @@ static void *thread(void *arg)
 }
 
 #define MI_LOAD_REGISTER_IMM                    (0x22<<23)
-#define MI_STORE_REGISTER_MEM                   (0x24<<23| 1<<22)
+#define MI_STORE_REGISTER_MEM                   (0x24<<23)
 
 igt_simple_main
 {
@@ -140,8 +140,9 @@ igt_simple_main
 	sleep(2);
 
 	for (i = 0; i < 1000; i++) {
+		uint32_t *p;
 		struct drm_i915_gem_execbuffer2 execbuf;
-		struct drm_i915_gem_exec_object2 exec;
+		struct drm_i915_gem_exec_object2 exec[2];
 		struct drm_i915_gem_relocation_entry reloc[2];
 		uint32_t b[] = {
 			MI_LOAD_REGISTER_IMM | 1,
@@ -149,54 +150,56 @@ igt_simple_main
 			2 << 16 | 2,
 			MI_STORE_REGISTER_MEM | 1,
 			FORCEWAKE_MT,
-			5*sizeof(uint32_t),
+			0, // to be patched
 			MI_LOAD_REGISTER_IMM | 1,
 			FORCEWAKE_MT,
 			2 << 16,
 			MI_STORE_REGISTER_MEM | 1,
 			FORCEWAKE_MT,
-			11*sizeof(uint32_t),
+			1 * sizeof(uint32_t), // to be patched
 			MI_BATCH_BUFFER_END,
 			0
 		};
 
-		memset(&exec, 0, sizeof(exec));
-		exec.handle = gem_create(t[0].fd, 4096);
-		exec.relocation_count = 2;
-		exec.relocs_ptr = (uintptr_t)reloc;
-		//exec.flags = EXEC_OBJECT_NEEDS_GTT;
-		gem_write(t[0].fd, exec.handle, 0, b, sizeof(b));
+		memset(exec, 0, sizeof(exec));
+		exec[1].handle = gem_create(t[0].fd, 4096);
+		exec[1].relocation_count = 2;
+		exec[1].relocs_ptr = (uintptr_t)reloc;
+		gem_write(t[0].fd, exec[1].handle, 0, b, sizeof(b));
+		exec[0].handle = gem_create(t[0].fd, 4096);
 
 		reloc[0].offset = 5 * sizeof(uint32_t);
-		reloc[0].delta = 5 * sizeof(uint32_t);
-		reloc[0].target_handle = exec.handle;
-		reloc[0].read_domains = I915_GEM_DOMAIN_INSTRUCTION;
-		reloc[0].write_domain = 0;
+		reloc[0].delta = 0;
+		reloc[0].target_handle = exec[0].handle;
+		reloc[0].read_domains = I915_GEM_DOMAIN_RENDER;
+		reloc[0].write_domain = I915_GEM_DOMAIN_RENDER;
 		reloc[0].presumed_offset = 0;
 
 		reloc[1].offset = 11 * sizeof(uint32_t);
-		reloc[1].delta = 11 * sizeof(uint32_t);
-		reloc[1].target_handle = exec.handle;
-		reloc[1].read_domains = I915_GEM_DOMAIN_INSTRUCTION;
-		reloc[1].write_domain = 0;
+		reloc[1].delta = 1 * sizeof(uint32_t);
+		reloc[1].target_handle = exec[0].handle;
+		reloc[1].read_domains = I915_GEM_DOMAIN_RENDER;
+		reloc[1].write_domain = I915_GEM_DOMAIN_RENDER;
 		reloc[1].presumed_offset = 0;
 
 		memset(&execbuf, 0, sizeof(execbuf));
 		execbuf.buffers_ptr = (uintptr_t)&exec;
-		execbuf.buffer_count = 1;
+		execbuf.buffer_count = 2;
 		execbuf.batch_len = sizeof(b);
 		execbuf.flags = I915_EXEC_SECURE;
 
 		gem_execbuf(t[0].fd, &execbuf);
-		gem_sync(t[0].fd, exec.handle);
-		gem_read(t[0].fd, exec.handle, 0, b, sizeof(b));
-		gem_close(t[0].fd, exec.handle);
+		gem_sync(t[0].fd, exec[1].handle);
 
-		printf("[%d]={ %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x }\n",
-		       i, b[0], b[1], b[2], b[3], b[4], b[5], b[6], b[7], b[8], b[9], b[10], b[11], b[12]);
+		p = gem_mmap(t[0].fd, exec[0].handle, 4096, PROT_READ);
 
-		igt_assert(b[5] & 2);
-		igt_assert((b[11] & 2) == 0);
+		printf("[%d]={ %08x %08x }\n", i, p[0], p[1]);
+		igt_assert(p[0] & 2);
+		igt_assert((p[1] & 2) == 0);
+
+		munmap(p, 4096);
+		gem_close(t[0].fd, exec[0].handle);
+		gem_close(t[0].fd, exec[1].handle);
 
 		usleep(1000);
 	}
-- 
1.8.3.2

^ permalink raw reply related	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2014-05-12 16:50 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-08 21:22 [PATCH] tests/gen7_forcewake_mt: Don't set the GGTT bit in SRM command bradley.d.volkin
2014-04-09  6:20 ` Chris Wilson
2014-04-09 13:32   ` Daniel Vetter
2014-04-09 15:12   ` Volkin, Bradley D
2014-04-09 16:47     ` Daniel Vetter
2014-04-22 16:45       ` Volkin, Bradley D
2014-05-10 21:11 bradley.d.volkin
2014-05-12 16:50 ` Daniel Vetter

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.