Hi !

A conflict between X and radeonfb can cause system memory corruption
when switching console from X (note that this is not realted to the
recent radeonfb patches, the problem has been there forever as far as I
can tell).

This patch works around it in radeonfb by making sure the "offsets"
register that driver the memory mapping of the accel engine are always
properly set before every accel op. A better fix should be done in fbcon
ultimately.

Please apply to 2.6.11

Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>

Index: linux-work/drivers/video/aty/radeon_accel.c
===================================================================
--- linux-work.orig/drivers/video/aty/radeon_accel.c    2005-01-24 
17:09:44.000000000 +1100
+++ linux-work/drivers/video/aty/radeon_accel.c 2005-02-20 10:41:37.000000000 
+1100
@@ -4,6 +4,41 @@
  * "ACCEL_MMIO" ifdef branches in XFree86
  * --dte
  */
+
+static void radeon_fixup_offset(struct radeonfb_info *rinfo)
+{
+       u32 local_base;
+
+       /* *** Ugly workaround *** */
+       /*
+        * On some platforms, the video memory is mapped at 0 in radeon chip 
space
+        * (like PPCs) by the firmware. X will always move it up so that it's 
seen
+        * by the chip to be at the same address as the PCI BAR.
+        * That means that when switching back from X, there is a mismatch 
between
+        * the offsets programmed into the engine. This means that potentially,
+        * accel operations done before radeonfb has a chance to re-init the 
engine
+        * will have incorrect offsets, and potentially trash system memory !
+        *
+        * The correct fix is for fbcon to never call any accel op before the 
engine
+        * has properly been re-initialized (by a call to set_var), but this is 
a
+        * complex fix. This workaround in the meantime, called before every 
accel
+        * operation, makes sure the offsets are in sync.
+        */
+
+       radeon_fifo_wait (1);
+       local_base = INREG(MC_FB_LOCATION) << 16;
+       if (local_base == rinfo->fb_local_base)
+               return;
+
+       rinfo->fb_local_base = local_base;
+
+       radeon_fifo_wait (3);
+       OUTREG(DEFAULT_PITCH_OFFSET, (rinfo->pitch << 0x16) |
+                                    (rinfo->fb_local_base >> 10));
+       OUTREG(DST_PITCH_OFFSET, (rinfo->pitch << 0x16) | (rinfo->fb_local_base 
>> 10));
+       OUTREG(SRC_PITCH_OFFSET, (rinfo->pitch << 0x16) | (rinfo->fb_local_base 
>> 10));
+}
+
 static void radeonfb_prim_fillrect(struct radeonfb_info *rinfo, 
                                   const struct fb_fillrect *region)
 {
@@ -38,6 +73,8 @@
                return;
        }
 
+       radeon_fixup_offset(rinfo);
+
        vxres = info->var.xres_virtual;
        vyres = info->var.yres_virtual;
 
@@ -105,6 +142,8 @@
                return;
        }
 
+       radeon_fixup_offset(rinfo);
+
        vxres = info->var.xres_virtual;
        vyres = info->var.yres_virtual;
 



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to