2011/8/23 Chen Jie <[email protected]>: > Hi, > > 在 2011年8月19日 上午10:18，Alex Deucher <[email protected]>写道： >> >> > 在 2011年8月8日 下午5:35，Dave Airlie <[email protected]>写道： >> >> You might want to try some of 3.1-rc1 kernel drm radeon code, Ben >> >> Herrenschmidt did a bunch of powerpc fixes that might >> >> be required on MIPS. >> >> >> > We tried 3.1-rc2, the corruption remains, attachment is the dmesg log >> > from 3.1-rc2. >> >> The sbios reserves a contiguous chunk of system memory as VRAM. Does >> your system properly account for this stolen memory? If not, the >> kernel and the GPU may both be trying to use it. > > Not sure I understand it or not, but we're using the sideport way, and > has a dedicated 128M DDR2 memory as VRAM.
The default behavior of the system bios is to set up sideport memory interleaved with stolen system memory. Unless your bios only enables sideport you'll need to respect the stolen system memory used as vram. Also, sideport memory has really limited memory bandwidth. It's a powersaving feature as if you un-interleave the sideport memory, you can put the display in sideport and stop memory access via the CPU. For decent performance, you need to use system memory or interleaved sideport and system memory. > > BTW: > 1. Is there any way to disable gtt? I tried to hack it and rendered no > display on screen. Not really. > 2. I've hacked radeon_test_moves(): > * It will allocate N(as much as possible) gtt and vram bo. > * For gtt->vram test, It first copies all N gtt bo to N vram bo, > then do the check. > * For vram->gtt test, it first copies all N vram bo to N gtt bo, > then do the check. > > The details are at: > * http://dev.lemote.com/files/upload/software/temp/Radeon.test/radeon_test.c > * diff with original radeon_test_moves(): > http://dev.lemote.com/files/upload/software/temp/Radeon.test/radeon_test.diff > > The new bo moving test is pass, but when I changed the bo size to 4M, > the kernel panic with unaligned access at some point after bo moving > test. The original radeon_test_moves() is ok for 4M bo size. Could > someone reviews the new radeon_test_moves() to find if this was caused > by some mistakes of the code or is a potential bug of the platform? See if the attached patch helps. It flushes the HDP caches if the driver uses the wait_idle callback rather than flushing in the fence emit. Alex
From d0a59ae53b1ff52bb1b59088b0835fbfff69baa2 Mon Sep 17 00:00:00 2001 From: Alex Deucher <[email protected]> Date: Tue, 23 Aug 2011 10:07:41 -0400 Subject: [PATCH] drm/radeon/kms: flush HDP cache on move tests Signed-off-by: Alex Deucher <[email protected]> --- drivers/gpu/drm/radeon/radeon_test.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_test.c b/drivers/gpu/drm/radeon/radeon_test.c index dee4a0c..e0590ea 100644 --- a/drivers/gpu/drm/radeon/radeon_test.c +++ b/drivers/gpu/drm/radeon/radeon_test.c @@ -117,6 +117,9 @@ void radeon_test_moves(struct radeon_device *rdev) DRM_ERROR("Failed to wait for GTT->VRAM fence %d\n", i); goto out_cleanup; } + /* callback hw specific functions if any */ + if (rdev->asic->ioctl_wait_idle) + rdev->asic->ioctl_wait_idle(rdev, vram_obj); radeon_fence_unref(&fence); @@ -160,6 +163,9 @@ void radeon_test_moves(struct radeon_device *rdev) DRM_ERROR("Failed to wait for VRAM->GTT fence %d\n", i); goto out_cleanup; } + /* callback hw specific functions if any */ + if (rdev->asic->ioctl_wait_idle) + rdev->asic->ioctl_wait_idle(rdev, vram_obj); radeon_fence_unref(&fence); -- 1.7.1.1
_______________________________________________ xorg-driver-ati mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-driver-ati
