diff options
author | Vladimir Dergachev <volodya@mindspring.com> | 2005-02-19 00:57:23 +0000 |
---|---|---|
committer | Vladimir Dergachev <volodya@mindspring.com> | 2005-02-19 00:57:23 +0000 |
commit | 84290849b4aee336e9db0779d93fc2d7ed8881b1 (patch) | |
tree | 89cdc2fa3c2d8a445ec1bec8487ba6ccdbb6f994 | |
parent | 60070063e2130af0b9d5d34eed7adbae0c0fa67b (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).
-rw-r--r-- | src/radeon_mergedfb.c | 8 |
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, |