r600_dma_ring_test() failed - synchronization problem with write-combining memory

r600_dma_ring_test() failed - synchronization problem with write-combining memory

[Alexander Fyodorov]

Hi David,

I'm using 3.10.53-rt56 kernel and encounter a problem in
r600_dma_ring_test() when vram memory is mapped as write-combining:
no matter how long the polling is done, old value (0xCAFEDEAD) is read.

Looking with hardware analyzer at what actually happens in the PCI-E bus,
the memory is accessed with 32-byte loads (8 words at a time). That is,
when the memory is mapped as write-combining, the processor converts
every readl() into a 32-bytes load transaction.

After doing some more experiments, it seems that Radeon has some kind of
cache that keeps the old value (0xCAFEDEAD), and this cache is invalidated
when:
1) Some other VRAM address is accessed, or
2) Processor issues a 4-byte load transaction.

The problem is that as long as the memory is write-combining, all loads
will be converted to be 32-bytes long by the CPU, so the test fails with
timeout. But if I comment out this particular ring test, everything
seems to be working fine (tested with Doom 3).

Is it possible that the situation r600_dma_ring_test() checks for does
not happen in real life, and I should be OK commenting it out?

Or maybe the test is broken and some cache-flushing command must be
written into the ring buffer?

BTW this is an out-of-tree architecture, so bisecting is not possible.

Re: r600_dma_ring_test() failed - synchronization problem with write-combining memory

[Christian König]

Hi Alexander,

in the ring test we write the value 0xDEADBEEF and 0xCAFEDEAD into 
registers, not VRAM.

And the register bar shouldn't be accessed write combined, cause that 
could lead to a couple of ordering problems. Why do you think the access 
is done write combined?

For VRAM it is true that we have a couple of different caches between 
the CPU and the actually memory, which need to be flushed explicitly if 
you want to see a value written by the GPU.

Regards,
Christian.

Am 09.10.2014 um 13:39 schrieb Alexander Fyodorov:
> Hi David,
>
> I'm using 3.10.53-rt56 kernel and encounter a problem in
> r600_dma_ring_test() when vram memory is mapped as write-combining:
> no matter how long the polling is done, old value (0xCAFEDEAD) is read.
>
> Looking with hardware analyzer at what actually happens in the PCI-E bus,
> the memory is accessed with 32-byte loads (8 words at a time). That is,
> when the memory is mapped as write-combining, the processor converts
> every readl() into a 32-bytes load transaction.
>
> After doing some more experiments, it seems that Radeon has some kind of
> cache that keeps the old value (0xCAFEDEAD), and this cache is invalidated
> when:
> 1) Some other VRAM address is accessed, or
> 2) Processor issues a 4-byte load transaction.
>
> The problem is that as long as the memory is write-combining, all loads
> will be converted to be 32-bytes long by the CPU, so the test fails with
> timeout. But if I comment out this particular ring test, everything
> seems to be working fine (tested with Doom 3).
>
> Is it possible that the situation r600_dma_ring_test() checks for does
> not happen in real life, and I should be OK commenting it out?
>
> Or maybe the test is broken and some cache-flushing command must be
> written into the ring buffer?
>
> BTW this is an out-of-tree architecture, so bisecting is not possible.
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: r600_dma_ring_test() failed - synchronization problem with write-combining memory

[Alexander Fyodorov]

09.10.2014, 21:42, "Christian König" <christian.koenig@amd.com>:
> Hi Alexander,
>
> in the ring test we write the value 0xDEADBEEF and 0xCAFEDEAD into
> registers, not VRAM.
>
> And the register bar shouldn't be accessed write combined, cause that
> could lead to a couple of ordering problems. Why do you think the access
> is done write combined?

Because there is this code in r600_dma_ring_test():
  void __iomem *ptr = (void *)rdev->vram_scratch.ptr;

And vram_scratch is allocated in r600_vram_scratch_init() with domain RADEON_GEM_DOMAIN_VRAM which implies write-combining. I assumed that this means it points to the video memory.

Also when I look at page table attributes I can see that it is indeed mapped as write-combining. In this test only "rdev->rmmio" area was mapped as UC (the one where radeon_ring_commit() writes to to start the execution).

> For VRAM it is true that we have a couple of different caches between
> the CPU and the actually memory, which need to be flushed explicitly if
> you want to see a value written by the GPU.

Then maybe such a flush is what I need. How do I put it in the instruction ring buffer?
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: r600_dma_ring_test() failed - synchronization problem with write-combining memory

[Christian König]

Am 09.10.2014 um 20:15 schrieb Alexander Fyodorov:
> 09.10.2014, 21:42, "Christian König" <christian.koenig@amd.com>:
>> Hi Alexander,
>>
>> in the ring test we write the value 0xDEADBEEF and 0xCAFEDEAD into
>> registers, not VRAM.
>>
>> And the register bar shouldn't be accessed write combined, cause that
>> could lead to a couple of ordering problems. Why do you think the access
>> is done write combined?
> Because there is this code in r600_dma_ring_test():
>    void __iomem *ptr = (void *)rdev->vram_scratch.ptr;
>
> And vram_scratch is allocated in r600_vram_scratch_init() with domain RADEON_GEM_DOMAIN_VRAM which implies write-combining. I assumed that this means it points to the video memory.

Ah! Sorry, you are talking about the DMA ring test, not the GFX ring 
test. Right in this case we use a bit of VRAM for the test.

> Also when I look at page table attributes I can see that it is indeed mapped as write-combining. In this test only "rdev->rmmio" area was mapped as UC (the one where radeon_ring_commit() writes to to start the execution).

Correct, that's the register bar.

>
>> For VRAM it is true that we have a couple of different caches between
>> the CPU and the actually memory, which need to be flushed explicitly if
>> you want to see a value written by the GPU.
> Then maybe such a flush is what I need. How do I put it in the instruction ring buffer?
At least we need to flush the HDP, but what hardware generation is this 
exactly? Some R6xx don't support hardware flushes in the ring buffer.

Try to call r600_mmio_hdp_flush(rdev) from the loop which checks the 
value written.

Regards,
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: r600_dma_ring_test() failed - synchronization problem with write-combining memory

[Alexander Fyodorov]

09.10.2014, 22:32, "Christian König" <christian.koenig@amd.com>:
> Am 09.10.2014 um 20:15 schrieb Alexander Fyodorov:
>>  09.10.2014, 21:42, "Christian König" <christian.koenig@amd.com>:
>>>  For VRAM it is true that we have a couple of different caches between
>>>  the CPU and the actually memory, which need to be flushed explicitly if
>>>  you want to see a value written by the GPU.
>>  Then maybe such a flush is what I need. How do I put it in the instruction ring buffer?
>
> At least we need to flush the HDP, but what hardware generation is this
> exactly? Some R6xx don't support hardware flushes in the ring buffer.

I observed the problem on HD2400 and HD6670.

> Try to call r600_mmio_hdp_flush(rdev) from the loop which checks the
> value written.

Yep, it helped. Here is the patch against 3.10.53, tested on HD2400.


Flush VRAM cache before each read when polling.

Signed-off-by: Alexander Fyodorov <halcy at yandex.ru>


Index: drivers/gpu/drm/radeon/r600.c
===================================================================
--- drivers/gpu/drm/radeon/r600.c	(revision 11647)
+++ drivers/gpu/drm/radeon/r600.c	(working copy)
@@ -2899,6 +2899,7 @@
 	radeon_ring_unlock_commit(rdev, ring);
 
 	for (i = 0; i < rdev->usec_timeout; i++) {
+		r600_ioctl_wait_idle(rdev, rdev->vram_scratch.robj);
 		tmp = readl(ptr);
 		if (tmp == 0xDEADBEEF)
 			break;
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: r600_dma_ring_test() failed - synchronization problem with write-combining memory

[Alex Deucher]

On Thu, Oct 9, 2014 at 3:10 PM, Alexander Fyodorov <halcy@yandex.ru> wrote:
> 09.10.2014, 22:32, "Christian König" <christian.koenig@amd.com>:
>> Am 09.10.2014 um 20:15 schrieb Alexander Fyodorov:
>>>  09.10.2014, 21:42, "Christian König" <christian.koenig@amd.com>:
>>>>  For VRAM it is true that we have a couple of different caches between
>>>>  the CPU and the actually memory, which need to be flushed explicitly if
>>>>  you want to see a value written by the GPU.
>>>  Then maybe such a flush is what I need. How do I put it in the instruction ring buffer?
>>
>> At least we need to flush the HDP, but what hardware generation is this
>> exactly? Some R6xx don't support hardware flushes in the ring buffer.
>
> I observed the problem on HD2400 and HD6670.
>
>> Try to call r600_mmio_hdp_flush(rdev) from the loop which checks the
>> value written.
>
> Yep, it helped. Here is the patch against 3.10.53, tested on HD2400.
>
>
> Flush VRAM cache before each read when polling.
>
> Signed-off-by: Alexander Fyodorov <halcy at yandex.ru>
>
>
> Index: drivers/gpu/drm/radeon/r600.c
> ===================================================================
> --- drivers/gpu/drm/radeon/r600.c       (revision 11647)
> +++ drivers/gpu/drm/radeon/r600.c       (working copy)
> @@ -2899,6 +2899,7 @@
>         radeon_ring_unlock_commit(rdev, ring);
>
>         for (i = 0; i < rdev->usec_timeout; i++) {
> +               r600_ioctl_wait_idle(rdev, rdev->vram_scratch.robj);
>                 tmp = readl(ptr);
>                 if (tmp == 0xDEADBEEF)
>                         break;

I think I'd prefer to just switch the test to use gart memory since
this code is shared by different asics thay may not all implement hdp
flush the same way.  We can just reserve a couple of slots in the wb
page.

Alex
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: r600_dma_ring_test() failed - synchronization problem with write-combining memory

[Alex Deucher]

On Fri, Oct 10, 2014 at 12:00 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
> On Thu, Oct 9, 2014 at 3:10 PM, Alexander Fyodorov <halcy@yandex.ru> wrote:
>> 09.10.2014, 22:32, "Christian König" <christian.koenig@amd.com>:
>>> Am 09.10.2014 um 20:15 schrieb Alexander Fyodorov:
>>>>  09.10.2014, 21:42, "Christian König" <christian.koenig@amd.com>:
>>>>>  For VRAM it is true that we have a couple of different caches between
>>>>>  the CPU and the actually memory, which need to be flushed explicitly if
>>>>>  you want to see a value written by the GPU.
>>>>  Then maybe such a flush is what I need. How do I put it in the instruction ring buffer?
>>>
>>> At least we need to flush the HDP, but what hardware generation is this
>>> exactly? Some R6xx don't support hardware flushes in the ring buffer.
>>
>> I observed the problem on HD2400 and HD6670.
>>
>>> Try to call r600_mmio_hdp_flush(rdev) from the loop which checks the
>>> value written.
>>
>> Yep, it helped. Here is the patch against 3.10.53, tested on HD2400.
>>
>>
>> Flush VRAM cache before each read when polling.
>>
>> Signed-off-by: Alexander Fyodorov <halcy at yandex.ru>
>>
>>
>> Index: drivers/gpu/drm/radeon/r600.c
>> ===================================================================
>> --- drivers/gpu/drm/radeon/r600.c       (revision 11647)
>> +++ drivers/gpu/drm/radeon/r600.c       (working copy)
>> @@ -2899,6 +2899,7 @@
>>         radeon_ring_unlock_commit(rdev, ring);
>>
>>         for (i = 0; i < rdev->usec_timeout; i++) {
>> +               r600_ioctl_wait_idle(rdev, rdev->vram_scratch.robj);
>>                 tmp = readl(ptr);
>>                 if (tmp == 0xDEADBEEF)
>>                         break;
>
> I think I'd prefer to just switch the test to use gart memory since
> this code is shared by different asics thay may not all implement hdp
> flush the same way.  We can just reserve a couple of slots in the wb
> page.

Also newer versions of the test will need a similar fix.

Alex
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: r600_dma_ring_test() failed - synchronization problem with write-combining memory

[Christian König]

Am 10.10.2014 um 18:02 schrieb Alex Deucher:
> On Fri, Oct 10, 2014 at 12:00 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
>> On Thu, Oct 9, 2014 at 3:10 PM, Alexander Fyodorov <halcy@yandex.ru> wrote:
>>> 09.10.2014, 22:32, "Christian König" <christian.koenig@amd.com>:
>>>> Am 09.10.2014 um 20:15 schrieb Alexander Fyodorov:
>>>>>   09.10.2014, 21:42, "Christian König" <christian.koenig@amd.com>:
>>>>>>   For VRAM it is true that we have a couple of different caches between
>>>>>>   the CPU and the actually memory, which need to be flushed explicitly if
>>>>>>   you want to see a value written by the GPU.
>>>>>   Then maybe such a flush is what I need. How do I put it in the instruction ring buffer?
>>>> At least we need to flush the HDP, but what hardware generation is this
>>>> exactly? Some R6xx don't support hardware flushes in the ring buffer.
>>> I observed the problem on HD2400 and HD6670.
>>>
>>>> Try to call r600_mmio_hdp_flush(rdev) from the loop which checks the
>>>> value written.
>>> Yep, it helped. Here is the patch against 3.10.53, tested on HD2400.
>>>
>>>
>>> Flush VRAM cache before each read when polling.
>>>
>>> Signed-off-by: Alexander Fyodorov <halcy at yandex.ru>
>>>
>>>
>>> Index: drivers/gpu/drm/radeon/r600.c
>>> ===================================================================
>>> --- drivers/gpu/drm/radeon/r600.c       (revision 11647)
>>> +++ drivers/gpu/drm/radeon/r600.c       (working copy)
>>> @@ -2899,6 +2899,7 @@
>>>          radeon_ring_unlock_commit(rdev, ring);
>>>
>>>          for (i = 0; i < rdev->usec_timeout; i++) {
>>> +               r600_ioctl_wait_idle(rdev, rdev->vram_scratch.robj);
>>>                  tmp = readl(ptr);
>>>                  if (tmp == 0xDEADBEEF)
>>>                          break;
>> I think I'd prefer to just switch the test to use gart memory since
>> this code is shared by different asics thay may not all implement hdp
>> flush the same way.  We can just reserve a couple of slots in the wb
>> page.

Works for me as well. We could also grab a few bytes of GART using the 
SA manager.

> Also newer versions of the test will need a similar fix.

See the patch I already send to you, the SDMA on CIK is the only one not 
usign this ring test.

Christian.

>
> Alex

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: r600_dma_ring_test() failed - synchronization problem with write-combining memory

[Alex Deucher]

[-- Attachment #1: Type: text/plain, Size: 2021 bytes --]

On Fri, Oct 10, 2014 at 12:00 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
> On Thu, Oct 9, 2014 at 3:10 PM, Alexander Fyodorov <halcy@yandex.ru> wrote:
>> 09.10.2014, 22:32, "Christian König" <christian.koenig@amd.com>:
>>> Am 09.10.2014 um 20:15 schrieb Alexander Fyodorov:
>>>>  09.10.2014, 21:42, "Christian König" <christian.koenig@amd.com>:
>>>>>  For VRAM it is true that we have a couple of different caches between
>>>>>  the CPU and the actually memory, which need to be flushed explicitly if
>>>>>  you want to see a value written by the GPU.
>>>>  Then maybe such a flush is what I need. How do I put it in the instruction ring buffer?
>>>
>>> At least we need to flush the HDP, but what hardware generation is this
>>> exactly? Some R6xx don't support hardware flushes in the ring buffer.
>>
>> I observed the problem on HD2400 and HD6670.
>>
>>> Try to call r600_mmio_hdp_flush(rdev) from the loop which checks the
>>> value written.
>>
>> Yep, it helped. Here is the patch against 3.10.53, tested on HD2400.
>>
>>
>> Flush VRAM cache before each read when polling.
>>
>> Signed-off-by: Alexander Fyodorov <halcy at yandex.ru>
>>
>>
>> Index: drivers/gpu/drm/radeon/r600.c
>> ===================================================================
>> --- drivers/gpu/drm/radeon/r600.c       (revision 11647)
>> +++ drivers/gpu/drm/radeon/r600.c       (working copy)
>> @@ -2899,6 +2899,7 @@
>>         radeon_ring_unlock_commit(rdev, ring);
>>
>>         for (i = 0; i < rdev->usec_timeout; i++) {
>> +               r600_ioctl_wait_idle(rdev, rdev->vram_scratch.robj);
>>                 tmp = readl(ptr);
>>                 if (tmp == 0xDEADBEEF)
>>                         break;
>
> I think I'd prefer to just switch the test to use gart memory since
> this code is shared by different asics thay may not all implement hdp
> flush the same way.  We can just reserve a couple of slots in the wb
> page.

Does the attached patch work for you as well?

Alex

[-- Attachment #2: 0001-drm-radeon-use-gart-memory-for-DMA-ring-tests.patch --]
[-- Type: text/x-patch, Size: 4168 bytes --]

From 20a3175094169ba368ed5f5463ea2e84a9bf6507 Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexander.deucher@amd.com>
Date: Mon, 13 Oct 2014 13:20:02 -0400
Subject: [PATCH] drm/radeon: use gart memory for DMA ring tests

Avoids HDP cache flush issues when using vram which can
cause ring test failures on certain boards.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Alexander Fyodorov <halcy@yandex.ru>
Cc: stable@vger.kernel.org
---
 drivers/gpu/drm/radeon/cik_sdma.c | 21 ++++++++++++---------
 drivers/gpu/drm/radeon/r600_dma.c | 21 ++++++++++++---------
 drivers/gpu/drm/radeon/radeon.h   |  2 ++
 3 files changed, 26 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik_sdma.c b/drivers/gpu/drm/radeon/cik_sdma.c
index c473c91..7deb2ef 100644
--- a/drivers/gpu/drm/radeon/cik_sdma.c
+++ b/drivers/gpu/drm/radeon/cik_sdma.c
@@ -618,16 +618,19 @@ int cik_sdma_ring_test(struct radeon_device *rdev,
 {
 	unsigned i;
 	int r;
-	void __iomem *ptr = (void *)rdev->vram_scratch.ptr;
+	unsigned index;
 	u32 tmp;
+	u64 gpu_addr;
 
-	if (!ptr) {
-		DRM_ERROR("invalid vram scratch pointer\n");
-		return -EINVAL;
-	}
+	if (ring->idx == R600_RING_TYPE_DMA_INDEX)
+		index = R600_WB_DMA_RING_TEST_OFFSET;
+	else
+		index = CAYMAN_WB_DMA1_RING_TEST_OFFSET;
+
+	gpu_addr = rdev->wb.gpu_addr + index;
 
 	tmp = 0xCAFEDEAD;
-	writel(tmp, ptr);
+	rdev->wb.wb[index/4] = cpu_to_le32(tmp);
 
 	r = radeon_ring_lock(rdev, ring, 5);
 	if (r) {
@@ -635,14 +638,14 @@ int cik_sdma_ring_test(struct radeon_device *rdev,
 		return r;
 	}
 	radeon_ring_write(ring, SDMA_PACKET(SDMA_OPCODE_WRITE, SDMA_WRITE_SUB_OPCODE_LINEAR, 0));
-	radeon_ring_write(ring, rdev->vram_scratch.gpu_addr & 0xfffffffc);
-	radeon_ring_write(ring, upper_32_bits(rdev->vram_scratch.gpu_addr));
+	radeon_ring_write(ring, lower_32_bits(gpu_addr));
+	radeon_ring_write(ring, upper_32_bits(gpu_addr));
 	radeon_ring_write(ring, 1); /* number of DWs to follow */
 	radeon_ring_write(ring, 0xDEADBEEF);
 	radeon_ring_unlock_commit(rdev, ring, false);
 
 	for (i = 0; i < rdev->usec_timeout; i++) {
-		tmp = readl(ptr);
+		tmp = le32_to_cpu(rdev->wb.wb[index/4]);
 		if (tmp == 0xDEADBEEF)
 			break;
 		DRM_UDELAY(1);
diff --git a/drivers/gpu/drm/radeon/r600_dma.c b/drivers/gpu/drm/radeon/r600_dma.c
index a49db83..d9375a3 100644
--- a/drivers/gpu/drm/radeon/r600_dma.c
+++ b/drivers/gpu/drm/radeon/r600_dma.c
@@ -241,16 +241,19 @@ int r600_dma_ring_test(struct radeon_device *rdev,
 {
 	unsigned i;
 	int r;
-	void __iomem *ptr = (void *)rdev->vram_scratch.ptr;
+	unsigned index;
 	u32 tmp;
+	u64 gpu_addr;
 
-	if (!ptr) {
-		DRM_ERROR("invalid vram scratch pointer\n");
-		return -EINVAL;
-	}
+	if (ring->idx == R600_RING_TYPE_DMA_INDEX)
+		index = R600_WB_DMA_RING_TEST_OFFSET;
+	else
+		index = CAYMAN_WB_DMA1_RING_TEST_OFFSET;
+
+	gpu_addr = rdev->wb.gpu_addr + index;
 
 	tmp = 0xCAFEDEAD;
-	writel(tmp, ptr);
+	rdev->wb.wb[index/4] = cpu_to_le32(tmp);
 
 	r = radeon_ring_lock(rdev, ring, 4);
 	if (r) {
@@ -258,13 +261,13 @@ int r600_dma_ring_test(struct radeon_device *rdev,
 		return r;
 	}
 	radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_WRITE, 0, 0, 1));
-	radeon_ring_write(ring, rdev->vram_scratch.gpu_addr & 0xfffffffc);
-	radeon_ring_write(ring, upper_32_bits(rdev->vram_scratch.gpu_addr) & 0xff);
+	radeon_ring_write(ring, lower_32_bits(gpu_addr));
+	radeon_ring_write(ring, upper_32_bits(gpu_addr) & 0xff);
 	radeon_ring_write(ring, 0xDEADBEEF);
 	radeon_ring_unlock_commit(rdev, ring, false);
 
 	for (i = 0; i < rdev->usec_timeout; i++) {
-		tmp = readl(ptr);
+		tmp = le32_to_cpu(rdev->wb.wb[index/4]);
 		if (tmp == 0xDEADBEEF)
 			break;
 		DRM_UDELAY(1);
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index e01424f..588672d 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1132,6 +1132,8 @@ struct radeon_wb {
 #define R600_WB_EVENT_OFFSET     3072
 #define CIK_WB_CP1_WPTR_OFFSET     3328
 #define CIK_WB_CP2_WPTR_OFFSET     3584
+#define R600_WB_DMA_RING_TEST_OFFSET 3588
+#define CAYMAN_WB_DMA1_RING_TEST_OFFSET 3592
 
 /**
  * struct radeon_pm - power management datas
-- 
1.8.3.1


[-- Attachment #3: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: r600_dma_ring_test() failed - synchronization problem with write-combining memory

[Alexander Fyodorov]

13.10.2014, 21:50, "Alex Deucher" <alexdeucher@gmail.com>:
> On Fri, Oct 10, 2014 at 12:00 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
>>  I think I'd prefer to just switch the test to use gart memory since
>>  this code is shared by different asics thay may not all implement hdp
>>  flush the same way.  We can just reserve a couple of slots in the wb
>>  page.
>
> Does the attached patch work for you as well?

Yes, although it became a little bit slower - it now completes in 2 usecs.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel