summaryrefslogtreecommitdiff
path: root/src/radeon_mergedfb.c
diff options
context:
space:
mode:
authorVladimir Dergachev <volodya@mindspring.com>2005-02-19 00:57:23 +0000
committerVladimir Dergachev <volodya@mindspring.com>2005-02-19 00:57:23 +0000
commit84290849b4aee336e9db0779d93fc2d7ed8881b1 (patch)
tree89cdc2fa3c2d8a445ec1bec8487ba6ccdbb6f994 /src/radeon_mergedfb.c
parent60070063e2130af0b9d5d34eed7adbae0c0fa67b (diff)
Modified:
programs/Xserver/hw/xfree86/drivers/ati/radeon_mergedfb.c Add a call to RADEONWaitForIdleMMIO() within RADEONChooseCursorCRTC() as this function uses OUTREGP() which, internally, calls INREG(). Thus (due to SilkenMouse) INREG() could be called while CP engine was busy. I have observed this lockup on RV350 + R300 3d driver and have no idea why no issues were reported for R200 cards. Perhaps, few of them have enough memory to run merged fb and 3d simultaneously ? This fix is the right thing to do, however, we might also need to put fifo management calls into other cursor handling functions (in particular those that write cursor image directly to video memory).
Diffstat (limited to 'src/radeon_mergedfb.c')
-rw-r--r--src/radeon_mergedfb.c8
1 files changed, 8 insertions, 0 deletions
diff --git a/src/radeon_mergedfb.c b/src/radeon_mergedfb.c
index c4d00c96..89bc19fa 100644
--- a/src/radeon_mergedfb.c
+++ b/src/radeon_mergedfb.c
@@ -1444,6 +1444,14 @@ RADEONChooseCursorCRTC(ScrnInfoPtr pScrn1, int x, int y)
((RADEONMergedDisplayModePtr)info->CurrentLayout.mode->Private)->CRT2Position;
ScrnInfoPtr pScrn2 = info->CRT2pScrn;
+ /*
+ Note: we need WaitForIdle here because OUTREGP() involves an INREG() to obtain a previous
+ value. This fix is needed for RV350 + 3d driver (or we get a lockup otherwise).
+
+ It is also indicated by documentation (we should not be doing INREG if CP engine is active)
+ */
+ RADEONWaitForIdleMMIO(pScrn1);
+
if (srel == radeonClone) {
/* show cursor 2 */
OUTREGP(RADEON_CRTC2_GEN_CNTL, RADEON_CRTC2_CUR_EN,