* r600_dma_ring_test() failed - synchronization problem with write-combining memory @ 2014-10-09 11:39 Alexander Fyodorov 2014-10-09 17:42 ` Christian König 0 siblings, 1 reply; 10+ messages in thread From: Alexander Fyodorov @ 2014-10-09 11:39 UTC (permalink / raw) To: airlied, dri-devel 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: r600_dma_ring_test() failed - synchronization problem with write-combining memory 2014-10-09 11:39 r600_dma_ring_test() failed - synchronization problem with write-combining memory Alexander Fyodorov @ 2014-10-09 17:42 ` Christian König 2014-10-09 18:15 ` Alexander Fyodorov 0 siblings, 1 reply; 10+ messages in thread From: Christian König @ 2014-10-09 17:42 UTC (permalink / raw) To: Alexander Fyodorov, airlied, dri-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: r600_dma_ring_test() failed - synchronization problem with write-combining memory 2014-10-09 17:42 ` Christian König @ 2014-10-09 18:15 ` Alexander Fyodorov 2014-10-09 18:32 ` Christian König 0 siblings, 1 reply; 10+ messages in thread From: Alexander Fyodorov @ 2014-10-09 18:15 UTC (permalink / raw) To: Christian König, airlied@linux.ie, dri-devel@lists.freedesktop.org 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: r600_dma_ring_test() failed - synchronization problem with write-combining memory 2014-10-09 18:15 ` Alexander Fyodorov @ 2014-10-09 18:32 ` Christian König 2014-10-09 19:10 ` Alexander Fyodorov 0 siblings, 1 reply; 10+ messages in thread From: Christian König @ 2014-10-09 18:32 UTC (permalink / raw) To: Alexander Fyodorov, gpudriverdevsupport, dri-devel@lists.freedesktop.org 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: r600_dma_ring_test() failed - synchronization problem with write-combining memory 2014-10-09 18:32 ` Christian König @ 2014-10-09 19:10 ` Alexander Fyodorov 2014-10-10 16:00 ` Alex Deucher 0 siblings, 1 reply; 10+ messages in thread From: Alexander Fyodorov @ 2014-10-09 19:10 UTC (permalink / raw) To: Christian König, gpudriverdevsupport, dri-devel@lists.freedesktop.org 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: r600_dma_ring_test() failed - synchronization problem with write-combining memory 2014-10-09 19:10 ` Alexander Fyodorov @ 2014-10-10 16:00 ` Alex Deucher 2014-10-10 16:02 ` Alex Deucher 2014-10-13 17:50 ` Alex Deucher 0 siblings, 2 replies; 10+ messages in thread From: Alex Deucher @ 2014-10-10 16:00 UTC (permalink / raw) To: Alexander Fyodorov Cc: dri-devel@lists.freedesktop.org, Christian König, gpudriverdevsupport 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: r600_dma_ring_test() failed - synchronization problem with write-combining memory 2014-10-10 16:00 ` Alex Deucher @ 2014-10-10 16:02 ` Alex Deucher 2014-10-10 16:03 ` Christian König 2014-10-13 17:50 ` Alex Deucher 1 sibling, 1 reply; 10+ messages in thread From: Alex Deucher @ 2014-10-10 16:02 UTC (permalink / raw) To: Alexander Fyodorov Cc: dri-devel@lists.freedesktop.org, Christian König, gpudriverdevsupport 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: r600_dma_ring_test() failed - synchronization problem with write-combining memory 2014-10-10 16:02 ` Alex Deucher @ 2014-10-10 16:03 ` Christian König 0 siblings, 0 replies; 10+ messages in thread From: Christian König @ 2014-10-10 16:03 UTC (permalink / raw) To: Alex Deucher, Alexander Fyodorov Cc: dri-devel@lists.freedesktop.org, gpudriverdevsupport 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: r600_dma_ring_test() failed - synchronization problem with write-combining memory 2014-10-10 16:00 ` Alex Deucher 2014-10-10 16:02 ` Alex Deucher @ 2014-10-13 17:50 ` Alex Deucher 2014-10-14 14:12 ` Alexander Fyodorov 1 sibling, 1 reply; 10+ messages in thread From: Alex Deucher @ 2014-10-13 17:50 UTC (permalink / raw) To: Alexander Fyodorov Cc: dri-devel@lists.freedesktop.org, Christian König, gpudriverdevsupport [-- 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 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: r600_dma_ring_test() failed - synchronization problem with write-combining memory 2014-10-13 17:50 ` Alex Deucher @ 2014-10-14 14:12 ` Alexander Fyodorov 0 siblings, 0 replies; 10+ messages in thread From: Alexander Fyodorov @ 2014-10-14 14:12 UTC (permalink / raw) To: Alex Deucher Cc: dri-devel@lists.freedesktop.org, Christian König, gpudriverdevsupport 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-10-14 14:12 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-10-09 11:39 r600_dma_ring_test() failed - synchronization problem with write-combining memory Alexander Fyodorov 2014-10-09 17:42 ` Christian König 2014-10-09 18:15 ` Alexander Fyodorov 2014-10-09 18:32 ` Christian König 2014-10-09 19:10 ` Alexander Fyodorov 2014-10-10 16:00 ` Alex Deucher 2014-10-10 16:02 ` Alex Deucher 2014-10-10 16:03 ` Christian König 2014-10-13 17:50 ` Alex Deucher 2014-10-14 14:12 ` Alexander Fyodorov
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.