CVS lock ?

[Vladimir Dergachev]

For some reason I cannot commit to radeon_accel.c and
cvs log radeon_accel.c mentions something about a lock..

Have the repository been frozen already ?

Just in case, I wanted to commit the patch below..

Help would be much appreciated. Thank you !

                 Vladimir Dergachev
PS Patch:

         Modified:
         * programs/Xserver/hw/xfree86/drivers/ati/radeon_accel.c

 	Add DMA robustness fix from Nicolai Haehnle.

 	TODO: move this fix into DRM driver or other parts of Xserver
 	when R300 support is more stable.

 	This fix affects only R300 and later variants and results in
 	small slowdown when using CP acceleration in comparison to
 	the previous version of the driver.

 	We are still a lot faster in CP mode than using MMIO register
 	access.

Index: radeon_accel.c
===================================================================
RCS file: 
/cvs/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_accel.c,v
retrieving revision 1.13
diff -u -r1.13 radeon_accel.c
--- radeon_accel.c      12 Dec 2004 20:42:29 -0000      1.13
+++ radeon_accel.c      16 Dec 2004 12:42:17 -0000
@@ -556,6 +556,44 @@
                    buffer->idx);
      }

+    /* TODO: Fix this more elegantly.
+     * Sometimes (especially with multiple DRI clients), this code
+     * runs immediately after a DRI client issues a rendering command.
+     *
+     * The accel code regularly inserts WAIT_UNTIL_IDLE into the
+     * command buffer that is sent with the indirect buffer below.
+     * The accel code fails to set the 3D cache flush registers for
+     * the R300 before sending WAIT_UNTIL_IDLE. Sending a cache flush
+     * on these new registers is not necessary for pure 2D functionality,
+     * but it *is* necessary after 3D operations.
+     * Without the cache flushes before WAIT_UNTIL_IDLE, the R300 locks up.
+     *
+     * The CP_IDLE call into the DRM indirectly flushes all caches and
+     * thus avoids the lockup problem, but the solution is far from ideal.
+     * Better solutions could be:
+     *  - always flush caches when entering the X server
+     *  - track the type of rendering commands somewhere and issue
+     *    cache flushes when they change
+     * However, I don't feel confident enough with the control flow
+     * inside the X server to implement either fix. -- nh
+     */
+
+    /* On my computer (Radeon Mobility M10)
+       The fix below results in x11perf -shmput500 rate of 225.0/sec
+       which is lower than 264.0/sec I get without it.
+
+       On the other hand, not using CP acceleration at all benchmarks
+       at 144.0/sec.
+
+       For now let us accept this as a lesser evil, especially as the
+       DRM driver for R300 is still in flux.
+
+       Once the code is more stable this should probably be moved into DRM driver.
+    */
+
+    if (info->ChipFamily>=CHIP_FAMILY_R300)
+        drmCommandNone(info->drmFD, DRM_RADEON_CP_IDLE);
+
      indirect.idx     = buffer->idx;
      indirect.start   = start;
      indirect.end     = buffer->used;
@@ -595,6 +633,10 @@
                    buffer->idx);
      }

+    /* Hack for the R300 (see RADEONCPFlushIndirect for explanation) */
+    if (info->ChipFamily>=CHIP_FAMILY_R300)
+        drmCommandNone(info->drmFD, DRM_RADEON_CP_IDLE);
+
      indirect.idx     = buffer->idx;
      indirect.start   = start;
      indirect.end     = buffer->used;