[Help][RS780E][mipsel]Screen corruption sometimes

[Alex Deucher]

2011/8/23 Chen Jie <chenj at lemote.com>:
> Hi,
>
> 在 2011年8月19日 上午10:18，Alex Deucher <alexdeucher at gmail.com>写道：
>>
>> > 在 2011年8月8日 下午5:35，Dave Airlie <airlied at gmail.com>写道：
>> >> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-kms-flush-HDP-cache-on-move-tests.patch
Type: text/x-diff
Size: 1252 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-driver-ati/attachments/20110823/5e99c729/attachment.patch>