summaryrefslogtreecommitdiff
path: root/drivers/base
diff options
context:
space:
mode:
authorJerome Glisse <jglisse@redhat.com>2010-03-09 14:45:12 +0000
committerDave Airlie <airlied@redhat.com>2010-04-06 11:21:11 +1000
commit90aca4d2740255bd130ea71a91530b9920c70abe (patch)
treeacf9b8a4353e6727cd6cba5b71caaf9f067e465d /drivers/base
parenta2d07b7438f015a0349bc9af3c96a8164549bbc5 (diff)
downloadlinux-next-90aca4d2740255bd130ea71a91530b9920c70abe.tar.gz
drm/radeon/kms: simplify & improve GPU reset V2
This simplify and improve GPU reset for R1XX-R6XX hw, it's not 100% reliable here are result: - R1XX/R2XX works bunch of time in a row, sometimes it seems it can work indifinitly - R3XX/R3XX the most unreliable one, sometimes you will be able to reset few times, sometimes not even once - R5XX more reliable than previous hw, seems to work most of the times but once in a while it fails for no obvious reasons (same status than previous reset just no same happy ending) - R6XX/R7XX are lot more reliable with this patch, still it seems that it can fail after a bunch (reset every 2sec for 3hour bring down the GPU & computer) This have been tested on various hw, for some odd reasons i wasn't able to lockup RS480/RS690 (while they use to love locking up). Note that on R1XX-R5XX the cursor will disapear after lockup haven't checked why, switch to console and back to X will restore cursor. Next step is to record the bogus command that leaded to the lockup. V2 Fix r6xx resume path to avoid reinitializing blit module, use the gpu_lockup boolean to avoid entering inifinite waiting loop on fence while reiniting the GPU Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Diffstat (limited to 'drivers/base')
0 files changed, 0 insertions, 0 deletions