* [PATCH] radeonfb: Workaround memory corruption accel problem
2005-02-19 23:32 ` Benjamin Herrenschmidt
@ 2005-02-19 23:45 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 3+ messages in thread
From: Benjamin Herrenschmidt @ 2005-02-19 23:45 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Linux Kernel list, Paul Mackerras, Antonino A. Daplas
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 <benh@kernel.crashing.org>
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;
^ permalink raw reply [flat|nested] 3+ messages in thread