[patch] VRAM detection in controlfb

[patch] VRAM detection in controlfb

[Michel Lanners]

[-- Attachment #1: Type: TEXT/plain, Size: 1073 bytes --]

Hi list,

I've finally gotten bored by control's VRAM detection code that is only
semi-functional (either 7x00 or 8x00 VRAM is incorrectly detected).
Until somebody comes up with a failsafe method to detect VRAM, I've
added a command line option to control the amount of VRAM used:

- either kernel command line (compiled-in):

	video=controlfb:vram:3

- or insmod option (no idea whether controlfb works as module):

	insmod controlfb vram=3

Possible values are:

	0 = autodetect (default)
	1 = 2MB bank1
	2 = 2MB bank2
	3 = 4MB (most useful; 4MB doesn't always get detected right)

Larger values get cropped to bits 0 & 1.

If I hear no opposition, I'll send this off to Alan; it might make it
into 2.4.0-final.

Cheers

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "

[-- Attachment #2: controlfb.diff --]
[-- Type: TEXT/plain, Size: 4852 bytes --]

--- linux-2.3.paul/drivers/video/controlfb.c	Fri Apr 21 09:47:27 2000
+++ linux-2.3.paul-work/drivers/video/controlfb.c	Thu Jun  1 00:14:56 2000
@@ -109,6 +109,11 @@
 	} fbcon_cmap;
 };

+static int vram = 0;    /* VRAM config: 1 = 2MB bank1; 2 = 2MB bank2;
+					3 = 4MB */
+MODULE_PARM(vram, "i");
+MODULE_PARM_DESC(vram, "Override VRAM detection: 1 = 2MB bank1; 2 = 2MB bank2; 3 = 4MB");
+
 /******************** Prototypes for exported functions ********************/
 static int control_open(struct fb_info *info, int user);
 static int control_release(struct fb_info *info, int user);
@@ -628,8 +633,8 @@
 	out_le32(&p->control_regs->flags.r, flags);
 	out_le32(&p->control_regs->start_addr.r,
 	    par->yoffset * (par->vxres << cmode));
-	out_le32(&p->control_regs->reg18.r, 0x1e5);
-	out_le32(&p->control_regs->reg19.r, 0);
+       out_le32(&p->control_regs->refr_cnt.r, 0x1e5);
+       out_le32(&p->control_regs->int_en.r, 0);

 	for (i = 0; i < 16; ++i) {
 		controlfb_setcolreg(color_table[i], default_red[i]<<8,
@@ -715,6 +720,29 @@
 	 * - with 4M vram, it appears only as a 4M block at offset 0.
 	 */

+	/* Unfortunately, above is only true on 8x00 machines. 7x00 machines
+	 * behave differently. Until somebody comes up with a way to
+	 * differentiate between the two, you can use the vram= insmod or
+	 * video=controlfb:vram: command-line option to force a specific
+	 * VRAM config.
+	 * 				Michel Lanners <mlan@cpu.lu>
+	 */
+
+	if(vram != 0) {
+		bank1 = vram & 1;
+		bank2 = (vram & 2) / 2;
+		printk(KERN_INFO "controlfb: Overriding VRAM detection, set to"
+			" %s%s%s.\n", (bank1 && bank2) ? "4MB" : "2MB ",
+			(bank1 && !bank2) ? "(bank1)" : "",
+			(!bank1 && bank2) ? "(bank2)" : "");
+		if(!bank1) {
+			p->control_use_bank2 = 1;
+			p->frame_buffer += 0x600000;
+			p->frame_buffer_phys += 0x600000;
+		}
+		goto detect_done;
+	}
+
 	/* We know there is something at 2M if there is something at 0M. */
 	out_8(&p->frame_buffer[0x200000], 0xa5);
 	out_8(&p->frame_buffer[0x200001], 0x38);
@@ -743,7 +771,8 @@
 		p->frame_buffer += 0x600000;
 		p->frame_buffer_phys += 0x600000;
 	}
-
+
+detect_done:
 	p->total_vram = (bank1 + bank2) * 0x200000;

 	printk(KERN_INFO "controlfb: Memory bank 1 %s, bank 2 %s, total VRAM %dMB\n",
@@ -1194,11 +1223,10 @@
 					break;
 			memcpy(fontname, this_opt + 5, i);
 			fontname[i] = 0;
-		}
-		if (!strncmp(this_opt, "vmode:", 6)) {
+		} else if (!strncmp(this_opt, "vmode:", 6)) {
 			int vmode = simple_strtoul(this_opt+6, NULL, 0);
-		if (vmode > 0 && vmode <= VMODE_MAX)
-			default_vmode = vmode;
+			if (vmode > 0 && vmode <= VMODE_MAX)
+				default_vmode = vmode;
 		} else if (!strncmp(this_opt, "cmode:", 6)) {
 			int depth = simple_strtoul(this_opt+6, NULL, 0);
 			switch (depth) {
@@ -1219,6 +1247,8 @@
 				default_cmode = CMODE_32;
 				break;
 			}
+		} else if (!strncmp(this_opt, "vram:", 5)) {
+			vram = 3 & simple_strtoul(this_opt+5, NULL, 0);
 		}
 	}
 }
--- linux-2.3.paul/drivers/video/controlfb.h	Mon Jan  4 01:44:06 1999
+++ linux-2.3.paul-work/drivers/video/controlfb.h	Thu May 25 21:40:41 2000
@@ -21,13 +21,13 @@
  * Structure of the registers for the RADACAL colormap device.
  */
 struct cmap_regs {
-	unsigned char addr;
+	unsigned char addr; 	/* REG-ADDR */
 	char pad1[15];
-	unsigned char d1;
+	unsigned char d1;	/* CRSR-PALETTE */
 	char pad2[15];
-	unsigned char d2;
+	unsigned char d2;	/* REG-DATA */
 	char pad3[15];
-	unsigned char lut;
+	unsigned char lut;	/* COLOR-PALETTE */
 	char pad4[15];
 };

@@ -51,26 +51,27 @@
 	struct preg vesync;	/* vert end sync */
 	struct preg vssync;	/* vert start sync */
 	struct preg vperiod;	/* vert period */
-	struct preg reg8;
+	struct preg reg8;	/* PipeDelayHWCursor */
 	/* Horizontal params are in units of 2 pixels */
 	struct preg hperiod;	/* horiz period - 2 */
 	struct preg hsblank;	/* horiz start blank */
 	struct preg heblank;	/* horiz end blank */
 	struct preg hesync;	/* horiz end sync */
 	struct preg hssync;	/* horiz start sync */
-	struct preg rege;
-	struct preg regf;
-	struct preg reg10;
-	struct preg reg11;
+	struct preg rege;	/* HEQ */
+	struct preg regf;	/* HLFLN */
+	struct preg reg10;	/* HSERR */
+	struct preg reg11;	/* CNTTST */
 	struct preg ctrl;	/* display control */
 	struct preg start_addr;	/* start address: 5 lsbs zero */
 	struct preg pitch;	/* addrs diff between scan lines */
 	struct preg mon_sense;	/* monitor sense bits */
 	struct preg flags;
 	struct preg mode;
-	struct preg reg18;
-	struct preg reg19;
-	struct preg res[6];
+	struct preg refr_cnt;	/* REFRESH-COUNT */
+	struct preg int_en;	/* interrupt enable */
+	struct preg int_st;	/* interrupt status */
+	struct preg res[5];
 };

 struct control_regints {

--134392852-1804289383-959813033=:660-
ontent-Type: TEXT/plain; CHARSET=US-ASCII
Content-Disposition: attachment; filename="controlfb.diff"

Re: [patch] VRAM detection in controlfb

[Takashi Oe]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 560 bytes --]

Hi Michel,

On Thu, 1 Jun 2000, Michel Lanners wrote:

[...]
> If I hear no opposition, I'll send this off to Alan; it might make it
> into 2.4.0-final.

Actually, I have sent a similar patch to DanJ a few weeks ago.  The patch
attached includes a few bug fixes as well as a feature enhancement in that
it is now possible to program all aspects of control frame buffer
geometry/timings to your liking; that is, you can use xvidtune to ruin
your monitor if you are not careful.  Also, mode-switching-on-the-fly is
possible if X server supports it.


Takashi Oe

[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 8579 bytes --]

Re: [patch] VRAM detection in controlfb

[Michel Lanners]

Hi Takashi,

On  31 May, this message from Takashi Oe echoed through cyberspace:
> [...]
>> If I hear no opposition, I'll send this off to Alan; it might make it
>> into 2.4.0-final.
>
> Actually, I have sent a similar patch to DanJ a few weeks ago.

Do you mind if I merge yours and my patch to keep your bugfixes and
enhancements, and my command line code? I think mine is easier in the
sense that you can _exactly_ specify what is in the box, including
indicating the bank for 2MB configs.

For those with multiple display adapters, do you think an option
controlfb:off might make sense? As there is no way to control which card
gets assigned which framebuffer device, that might help in certain
situations...

> The patch
> attached includes a few bug fixes as well as a feature enhancement in that
> it is now possible to program all aspects of control frame buffer
> geometry/timings to your liking; that is, you can use xvidtune to ruin
> your monitor if you are not careful.

I've had a quick try in XFree 4, but that didn't work. How did you do
that?

Also, when running Xfree 4, I get a wrapped-around screen in the sense
that the leftmost ~200 pixels appear on the _right_ side of the monitor.
Might that be the offset of pixel #1 in the framebuffer? Although,
that's around 100 bytes IIRC, so wouldn't explain the 200 pixels at 32
bit/pixel.... FWIW, I'm running Jack Howarth's XF4-12a RPMs.

Thanks

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Takashi Oe]

On Sat, 3 Jun 2000, Michel Lanners wrote:

> Hi Takashi,
>
> On  31 May, this message from Takashi Oe echoed through cyberspace:
> > [...]
> >> If I hear no opposition, I'll send this off to Alan; it might make it
> >> into 2.4.0-final.
> >
> > Actually, I have sent a similar patch to DanJ a few weeks ago.
>
> Do you mind if I merge yours and my patch to keep your bugfixes and
> enhancements, and my command line code? I think mine is easier in the
> sense that you can _exactly_ specify what is in the box, including
> indicating the bank for 2MB configs.

I don't mind, but can you improve the way to specify the vram config?
Your method is precise but not very intuitive.  Besides, is there anyone
with 2MB vram have the vram detection problem with either 2.2 or 2.{3,4}
controlfb codes?  I have only seen the problem with 4 MB, so being able to
specifiy which bank is in use may be overkill.

>
> For those with multiple display adapters, do you think an option
> controlfb:off might make sense? As there is no way to control which card
> gets assigned which framebuffer device, that might help in certain
> situations...
>
> > The patch
> > attached includes a few bug fixes as well as a feature enhancement in that
> > it is now possible to program all aspects of control frame buffer
> > geometry/timings to your liking; that is, you can use xvidtune to ruin
> > your monitor if you are not careful.
>
> I've had a quick try in XFree 4, but that didn't work. How did you do
> that?

I'm using XF4 server with XFree86-3.3.x xvidtune, and it does what I think
it should do.

> Also, when running Xfree 4, I get a wrapped-around screen in the sense
> that the leftmost ~200 pixels appear on the _right_ side of the monitor.
> Might that be the offset of pixel #1 in the framebuffer? Although,
> that's around 100 bytes IIRC, so wouldn't explain the 200 pixels at 32
> bit/pixel.... FWIW, I'm running Jack Howarth's XF4-12a RPMs.

XF4's fbdev is not working right for me either.  The weird displacement
occurs on both of display cards (control, matrox) I have.  I think the
current XF4 is of no use for fbdev only people.

Try fbset for finding resolution/timings you like for now and use
XF68_FBDev.

By the way, I've heard there is a work-in-progress Xpmac with software
accelerated code by Ryuichi.  I'd think this one would be the best X
server for control or any other Apple un-accelerated display adapters.  If
you ask him now, he might consider adding XF86VidMode extension support.


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Geert Uytterhoeven]

On Sat, 3 Jun 2000, Takashi Oe wrote:
> On Sat, 3 Jun 2000, Michel Lanners wrote:
> > Also, when running Xfree 4, I get a wrapped-around screen in the sense
> > that the leftmost ~200 pixels appear on the _right_ side of the monitor.
> > Might that be the offset of pixel #1 in the framebuffer? Although,
> > that's around 100 bytes IIRC, so wouldn't explain the 200 pixels at 32
> > bit/pixel.... FWIW, I'm running Jack Howarth's XF4-12a RPMs.
>
> XF4's fbdev is not working right for me either.  The weird displacement
> occurs on both of display cards (control, matrox) I have.  I think the
> current XF4 is of no use for fbdev only people.

Probably XF4 handles fix.smem_start being not on a page boundary incorrectly.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Geert Uytterhoeven]

On Sat, 3 Jun 2000, Michel Lanners wrote:
> For those with multiple display adapters, do you think an option
> controlfb:off might make sense? As there is no way to control which card
> gets assigned which framebuffer device, that might help in certain
> situations...

Immediately after I read this, I thought: isn't that already implemented
through fbmem.c? Then I remembered that controlfb is initialized from offb, and
not directly from fbmem_init().

I looked at the source, and surprise, controlfb can also be initialised on its
own:

    int __init control_init(void)
    {
    #ifndef CONFIG_FB_OF
	    struct device_node *dp;

	    dp = find_devices("control");
	    if (dp != 0)
		    control_of_init(dp);
    #endif /* CONFIG_FB_OF */
	    return 0;
    }

    void __init control_of_init(struct device_node *dp)
    {
	...
    }

Thus if you compile a kernel with CONFIG_FB_OF=n, controlfb will still work! In
addition you can disable it with video=controlfb:off!

If controlfb would (1) use request_mem_region() to mark the I/O regions it uses
busy and (2) be initialized before offb, it would also work when offb is
present and we can remove the test for a control display from offb.

Below you can find an (untested) patch that illustrates this idea. Can someone
please take a look at this?

A similar thing can be done for at least platinumfb, valkyriefb, chipsfb and
imsttfb. Five more steps closer to the removal of offb_init_driver()!

--- controlfb-2.4.0-test1/drivers/video/Config.in.orig	Thu May 25 08:31:53 2000
+++ controlfb-2.4.0-test1/drivers/video/Config.in	Sat Jun  3 09:09:57 2000
@@ -64,8 +64,8 @@
    fi
    if [ "$CONFIG_PPC" = "y" ]; then
       bool '  Open Firmware frame buffer device support' CONFIG_FB_OF
+      bool '    Apple "control" display support' CONFIG_FB_CONTROL
       if [ "$CONFIG_FB_OF" = "y" ]; then
-	 bool '    Apple "control" display support' CONFIG_FB_CONTROL
 	 bool '    Apple "platinum" display support' CONFIG_FB_PLATINUM
 	 bool '    Apple "valkyrie" display support' CONFIG_FB_VALKYRIE
 	 bool '    IMS Twin Turbo display support' CONFIG_FB_IMSTT
--- controlfb-2.4.0-test1/drivers/video/offb.c.orig	Fri Mar 24 09:54:46 2000
+++ controlfb-2.4.0-test1/drivers/video/offb.c	Sat Jun  3 09:06:15 2000
@@ -296,9 +296,6 @@
 #ifdef CONFIG_FB_MATROX
 extern int matrox_of_init(struct device_node *dp);
 #endif /* CONFIG_FB_MATROX */
-#ifdef CONFIG_FB_CONTROL
-extern void control_of_init(struct device_node *dp);
-#endif /* CONFIG_FB_CONTROL */
 #ifdef CONFIG_FB_VALKYRIE
 extern void valkyrie_of_init(struct device_node *dp);
 #endif /* CONFIG_FB_VALKYRIE */
@@ -435,12 +432,6 @@
 	return 1;
     }
 #endif /* CONFIG_FB_MATROX */
-#ifdef CONFIG_FB_CONTROL
-    if(!strcmp(dp->name, "control")) {
-	control_of_init(dp);
-	return 1;
-    }
-#endif /* CONFIG_FB_CONTROL */
 #ifdef CONFIG_FB_VALKYRIE
     if(!strcmp(dp->name, "valkyrie")) {
 	valkyrie_of_init(dp);
--- controlfb-2.4.0-test1/drivers/video/fbmem.c.orig	Fri May 26 14:56:33 2000
+++ controlfb-2.4.0-test1/drivers/video/fbmem.c	Sat Jun  3 09:11:12 2000
@@ -165,10 +165,13 @@
 #ifdef CONFIG_FB_ATY128
 	{ "aty128fb", aty128fb_init, aty128fb_setup },
 #endif
+#ifdef CONFIG_FB_CONTROL
+	{ "controlfb", control_init, control_setup },
+#endif
 #ifdef CONFIG_FB_OF
 	/*
 	 * Offb must be initialized _after_ all other frame buffer devices
-	 * that use PCI probing and PCI resources! [ Geert ]
+	 * that use I/O memory resources! [ Geert ]
 	 */
 	{ "offb", offb_init, offb_setup },
 #endif
@@ -211,9 +214,6 @@
 #ifdef CONFIG_FB_HP300
 	{ "hpfb", hpfb_init, hpfb_setup },
 #endif
-#ifdef CONFIG_FB_CONTROL
-	{ "controlfb", control_init, control_setup },
-#endif
 #ifdef CONFIG_FB_VALKYRIE
 	{ "valkyriefb", valkyriefb_init, valkyriefb_setup },
 #endif
--- controlfb-2.4.0-test1/drivers/video/controlfb.c.orig	Sat Jun  3 09:31:18 2000
+++ controlfb-2.4.0-test1/drivers/video/controlfb.c	Sat Jun  3 09:17:34 2000
@@ -150,9 +150,6 @@
  * Exported functions
  */
 int control_init(void);
-#ifdef CONFIG_FB_OF
-void control_of_init(struct device_node *dp);
-#endif
 void control_setup(char *);

 static int read_control_sense(struct fb_info_control *p);
@@ -202,19 +199,12 @@
 #ifdef MODULE
 int init_module(void)
 {
-	struct device_node *dp;
-
-	printk("Loading...\n");
-	dp = find_devices("control");
-	if (dp != 0)
-		control_of_init(dp);
-	else
-		printk("Failed.\n");
-	printk("Done.\n");
+	control_init();
 }

 void cleanup_module(void)
 {
+	/* FIXME: clean up */
 }
 #endif

@@ -664,35 +654,34 @@

 int __init control_init(void)
 {
-#ifndef CONFIG_FB_OF
 	struct device_node *dp;
-
-	dp = find_devices("control");
-	if (dp != 0)
-		control_of_init(dp);
-#endif /* CONFIG_FB_OF */
-	return 0;
-}
-
-void __init control_of_init(struct device_node *dp)
-{
 	struct fb_info_control	*p;
 	unsigned long		addr, size;
-	int			i, bank1, bank2;
+	int			i, j, bank1, bank2;
+
+	dp = find_devices("control");
+	if (dp == 0)
+		return 0;

 	if(dp->n_addrs != 2) {
 		printk(KERN_ERR "expecting 2 address for control (got %d)", dp->n_addrs);
-		return;
+		return 0;
 	}
 	p = kmalloc(sizeof(*p), GFP_ATOMIC);
 	if (p == 0)
-		return;
+		return 0;
 	memset(p, 0, sizeof(*p));

 	/* Map in frame buffer and registers */
 	for (i = 0; i < dp->n_addrs; ++i) {
 		addr = dp->addrs[i].address;
 		size = dp->addrs[i].size;
+		if (!request_mem_region(addr, size, "controlfb")) {
+			for (j = 0; j < i; j++)
+				release_mem_region(addr, size);
+			kfree(p);
+			return 0;
+		}
 		if (size >= 0x800000) {
 			/* use the big-endian aperture (??) */
 			addr += 0x800000;
@@ -751,6 +740,7 @@
 		2 * (bank1 + bank2));

 	init_control(p);
+	return 0;
 }

 /*

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Michel Dänzer]

Geert Uytterhoeven wrote:

> > XF4's fbdev is not working right for me either.  The weird displacement
> > occurs on both of display cards (control, matrox) I have.  I think the
> > current XF4 is of no use for fbdev only people.
>
> Probably XF4 handles fix.smem_start being not on a page boundary
> incorrectly.

What would it have to do to handle it?


Michel


--
Man invented language to satisfy his deep need to complain.
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86, Team *AMIGA*, AUGS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Franz Sirl]

Am Thu, 01 Jun 2000 schrieb Michel Lanners:

> > Hi list,
>
> I've finally gotten bored by control's VRAM detection code that is only
> semi-functional (either 7x00 or 8x00 VRAM is incorrectly detected).
> Until somebody comes up with a failsafe method to detect VRAM, I've
> added a command line option to control the amount of VRAM used:
>
> - either kernel command line (compiled-in):
>
> 	video=controlfb:vram:3
>
> - or insmod option (no idea whether controlfb works as module):
>
> 	insmod controlfb vram=3
>
> Possible values are:
>
> 	0 = autodetect (default)
> 	1 = 2MB bank1
> 	2 = 2MB bank2
> 	3 = 4MB (most useful; 4MB doesn't always get detected right)
>
> Larger values get cropped to bits 0 & 1.
>
> If I hear no opposition, I'll send this off to Alan; it might make it
> into 2.4.0-final.

Hi,

if you don't mind, would you try to replace the "dcbi" assembler instructions
in the detection code with "dcbf" instructions? It seems Dan inherited my bug
I had in the platinumfb driver...

Franz.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Geert Uytterhoeven]

On Sat, 3 Jun 2000, Michel Dänzer wrote:
> Geert Uytterhoeven wrote:
> > > XF4's fbdev is not working right for me either.  The weird displacement
> > > occurs on both of display cards (control, matrox) I have.  I think the
> > > current XF4 is of no use for fbdev only people.
> >
> > Probably XF4 handles fix.smem_start being not on a page boundary
> > incorrectly.
>
> What would it have to do to handle it?

Round down smem_start and mmap() it, and readd the offset. Cfr.

    ati_smem_start = (unsigned long)fb_fix.smem_start & PAGE_MASK;
    ati_smem_offset = (unsigned long)fb_fix.smem_start & ~PAGE_MASK;
    ati_smem_len = (ati_smem_offset+fb_fix.smem_len+~PAGE_MASK) & PAGE_MASK;

    addr = (unsigned long)mmap(NULL, ati_smem_len, PROT_READ | PROT_WRITE,
				MAP_SHARED, fb_fd, 0);

    ati_smem = addr+ati_smem_offset;

    ...

    munmap((caddr_t)(ati_smem & PAGE_MASK), ati_smem_len);


Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Daniel Jacobowitz]

On Sat, Jun 03, 2000 at 08:28:25AM +0200, Michel Lanners wrote:
> For those with multiple display adapters, do you think an option
> controlfb:off might make sense? As there is no way to control which card
> gets assigned which framebuffer device, that might help in certain
> situations...

Yes, sounds like a great idea.

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Ani Joshi]

On Sat, Jun 03, 2000 at 08:28:25AM +0200, Michel Lanners wrote:
> For those with multiple display adapters, do you think an option
> controlfb:off might make sense? As there is no way to control which card
> gets assigned which framebuffer device, that might help in certain
> situations...

I believe you can set which driver gets init'ed first by using the args:

video=foo:blah video=bar:blah

foo's _init will be called first, and bar's next, (therefore being fb0 and
fb1 respectively).


ani


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Michel Lanners]

Hi Franz,

On   3 Jun, this message from Franz Sirl echoed through cyberspace:
[hacking controlfb]
> if you don't mind, would you try to replace the "dcbi" assembler instructions
> in the detection code with "dcbf" instructions? It seems Dan inherited my bug
> I had in the platinumfb driver...

Sure, no problem.

In what sense is that a bug, and what would be the symptom? I know close
to nothing about PPC assembler, and fully understanding the detection
code might help fix the detection problems we still have in some
situations...

Thanks

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Michel Lanners]

Hi all,

On   3 Jun, this message from Ani Joshi echoed through cyberspace:
>> For those with multiple display adapters, do you think an option
>> controlfb:off might make sense?

Silly me; that's already taken care of in fbmem.c.

>> As there is no way to control which card
>> gets assigned which framebuffer device, that might help in certain
>> situations...
>
> I believe you can set which driver gets init'ed first by using the args:
>
> video=foo:blah video=bar:blah

Right, that's handles in fbmem.c. Unfortunately, I've never seen it
documented anywhere... So, I've started to write up a doc about
framebuffer kernel command line options. I've come across a few
oddities; among others the format of options:

1. What do the vc: and map: options do?
2. Why can you specify more options after 'scrollback:', separated with
   a ',', but not after the 'map:' option (no other options possible),
   whereas you can have more options following 'vc:', but without a
   separator?

Thanks

Michel

BTW, anybody have the fbutils compiled for 2k and recent kernels? I
can't seem to get it to compile....

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Tony Mantler]

At 2:09 AM -0500 6/4/2000, Michel Lanners wrote:
>Hi Franz,
>
>On   3 Jun, this message from Franz Sirl echoed through cyberspace:
>[hacking controlfb]
>> if you don't mind, would you try to replace the "dcbi" assembler
>>instructions
>> in the detection code with "dcbf" instructions? It seems Dan inherited
>>my bug
>> I had in the platinumfb driver...
>
>Sure, no problem.
>
>In what sense is that a bug, and what would be the symptom? I know close
>to nothing about PPC assembler, and fully understanding the detection
>code might help fix the detection problems we still have in some
>situations...

dcbi = data cache block invalidate. If you do this on a dirty cache block,
data will be lost.

dcbf = data cache block flush. If you do this on a block that isn't in a
coherent state, data will be lost.

If you have a block that's both dirty and incoherent... well, don't do that. :)


btw, my mail server messed up and I got bounced off the list a few weeks
back, have I missed anything interesting?


Cheers - Tony :)


--
Tony Mantler       Renaissance Nerd Extraordinaire     nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada                     http://nicoya.feline.pp.se/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Daniel Jacobowitz]

On Sun, Jun 04, 2000 at 10:08:39AM -0500, Tony Mantler wrote:
> dcbi = data cache block invalidate. If you do this on a dirty cache block,
> data will be lost.
>
> dcbf = data cache block flush. If you do this on a block that isn't in a
> coherent state, data will be lost.
>
> If you have a block that's both dirty and incoherent... well, don't do that. :)

Ew.  I wonder if that's our problem...

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Michel Lanners]

On   4 Jun, this message from Daniel Jacobowitz echoed through cyberspace:
>
> On Sun, Jun 04, 2000 at 10:08:39AM -0500, Tony Mantler wrote:
>> dcbi = data cache block invalidate. If you do this on a dirty cache block,
>> data will be lost.
>>
>> dcbf = data cache block flush. If you do this on a block that isn't in a
>> coherent state, data will be lost.
>>
>> If you have a block that's both dirty and incoherent... well, don't do that. :)
>
> Ew.  I wonder if that's our problem...

Would make sense, and I thought so too.... dcbi is wrong in any case for
us, since we did modify that block. However, I wonder whether caching is
on at all for the framebuffer adresses? (And if so, is that a good idea?
Do we want to trash the cache with a xsetroot?)

Anyway, a quick test showed no changes in the detection with dcbf
instead of dcbi. I'll have to test more thoroughly, but only after I get
Xpmac to run again...

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Michel Lanners]

Hi there,

On   3 Jun, this message from Geert Uytterhoeven echoed through cyberspace:
> Immediately after I read this, I thought: isn't that already implemented
> through fbmem.c? Then I remembered that controlfb is initialized from offb, and
> not directly from fbmem_init().
>
> I looked at the source, and surprise, controlfb can also be initialised on its
> own:
(patch deleted)

I applied the patch; XF4 works (just as badly) as before, but Xpmac
crashes big-time (panic on access of bad area (9C9C9D9D, iirc). makes
syslogd panic as well ??). But it started misbehaving already before
your patch, so there is probably something else as well...

I'll keep on looking.

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Tony Mantler]

At 12:48 AM -0500 6/5/2000, Michel Lanners wrote:
>On   4 Jun, this message from Daniel Jacobowitz echoed through cyberspace:
>>
>> On Sun, Jun 04, 2000 at 10:08:39AM -0500, Tony Mantler wrote:
[...]
>>> If you have a block that's both dirty and incoherent... well, don't do
>>>that. :)
>>
>> Ew.  I wonder if that's our problem...
>
>Would make sense, and I thought so too.... dcbi is wrong in any case for
>us, since we did modify that block. However, I wonder whether caching is
>on at all for the framebuffer adresses? (And if so, is that a good idea?
>Do we want to trash the cache with a xsetroot?)

I'm not sure of the design specifics of the Control video, but most of the
Apple video designs I've seen put the high-bandwidth low-latency video ram
right on the main bus, so it's already half way to being a cache in and of
itself (I seem to recall apple's sound manager using vram for buffer
space), and would benefit very little from the CPU cache, except perhaps in
a multi-cpu machine to keep bus chatter down to a minimum, but the exact
tradeoffs of that would take a bit of consideration to quantify.

Besides that, unlike main ram, what has and hasn't been written back to the
framebuffer makes a big difference in what you see on screen. Caching would
probably make for some mighty weird flicker, jumpy or inconsistent video
playback, and all sorts of evil visual gremlins. You could always cache the
framebuffer as write-through, but then any value you might have got from
the caching goes right out the window, as framebuffer writes should
outnumber framebuffer reads by an order of magnitude.

Anyways, that's the long answer. The short answer is: no, you probably
don't want to cache the framebuffer.


Cheers - Tony :)


--
Tony Mantler       Renaissance Nerd Extraordinaire     nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada                     http://nicoya.feline.pp.se/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Michel Dänzer]

Michel Lanners wrote:

> 1. What do the vc: and map: options do?

map: maps framebuffer devices to VCs. E.g. I use

	video=pm2fb:... video=amifb:... video=map:000011

So pm2fb is fb0 and amifb fb1, and VCs 1-4 are handled by pm2fb while 5 and
six are handled by amifb. Hope you get the idea.


> 2. Why can you specify more options after 'scrollback:', separated with
>    a ',', but not after the 'map:' option (no other options possible),

I guess it doesn't make sense to mix map: with device specific options because
it affects all devices.

>    whereas you can have more options following 'vc:', but without a
>    separator?

If only I knew what vc: is for :)


Michel


--
...and that is how we know the Earth to be banana-shaped.
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86, Team *AMIGA*, AUGS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Michel Lanners]

Hi all,

[about caching and framebuffers]
> I'm not sure of the design specifics of the Control video, but most of the
> Apple video designs I've seen put the high-bandwidth low-latency video ram
> right on the main bus, so it's already half way to being a cache in and of
> itself (I seem to recall apple's sound manager using vram for buffer
> space), and would benefit very little from the CPU cache, except perhaps in
> a multi-cpu machine to keep bus chatter down to a minimum, but the exact
> tradeoffs of that would take a bit of consideration to quantify.

In the case of control, the VRAM seems to be the same basic type as main
RAM (i.e. 60/70ns DRAM), and it is conceptually behind a PCI bridge. So
by itself it is not faster than main RAM....

> Besides that, unlike main ram, what has and hasn't been written back to the
> framebuffer makes a big difference in what you see on screen. Caching would
> probably make for some mighty weird flicker, jumpy or inconsistent video
> playback, and all sorts of evil visual gremlins. You could always cache the
> framebuffer as write-through, but then any value you might have got from
> the caching goes right out the window, as framebuffer writes should
> outnumber framebuffer reads by an order of magnitude.

The main reason for marking the VRAM cacheable (_how_ is a different story)
would be so that the CPU can burst to it; the net result being (as I have
understood it, but I may be wrong) that the CPU can fill the PCI bridge's
buffer with fast burst writes, and let the bridge take care of getting
the data to VRAM. According to Apple's doc on their PCI implementation,
all address space excpet main RAM is marked uncacheable by default, but
only cacheable space gets bursted to by the CPU.

So I guess the optimum would be to mark the VRAM cacheable, but in a way that
writes don't go into the cache. Would that be write-through?

> Anyways, that's the long answer. The short answer is: no, you probably
> don't want to cache the framebuffer.

Except for the above reasons ;-)

Cheers

Michel
-------------------------------------------------------
.sig enjoying a day off

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Geert Uytterhoeven]

On Mon, 5 Jun 2000, Michel Lanners wrote:
> So I guess the optimum would be to mark the VRAM cacheable, but in a way that
> writes don't go into the cache. Would that be write-through?

That's indeed write-through. Note that writes will still be cached in such a
way that a consecutive read from the same location will return the cached
value.  But writes will immediately be sent to the host bridge.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Tony Mantler]

At 9:15 AM -0500 6/5/2000, Geert Uytterhoeven wrote:
>On Mon, 5 Jun 2000, Michel Lanners wrote:
>> So I guess the optimum would be to mark the VRAM cacheable, but in a way
>>that
>> writes don't go into the cache. Would that be write-through?
>
>That's indeed write-through. Note that writes will still be cached in such a
>way that a consecutive read from the same location will return the cached
>value.  But writes will immediately be sent to the host bridge.

True enough. Is the vram genuinley behind the PCI bridge, or is it just
magically managed as a PCI resource from the main bus? If the reads and
writes don't really go through the bridge then, again, I don't see that
there would be much benefit in using a write-through cache, with perhaps
the exception of SMP.

It would atleast be worthwhile mapping it non-cached until the driver can
be proven 100% stable (well, 95% atleast) :), then turn caching back on
(write-through, of course) and see what breaks again, knowing this time
that it's definatley cache-related.


And I mean, if all else fails, stability should always prevail over speed,
right?... right?... *tumbleweed rolls by*

;)


Cheers - Tony :)


--
Tony Mantler       Renaissance Nerd Extraordinaire     nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada                     http://nicoya.feline.pp.se/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Timothy A. Seufert]

At 4:15 PM +0200 6/5/00, Geert Uytterhoeven wrote:
>On Mon, 5 Jun 2000, Michel Lanners wrote:
>>  So I guess the optimum would be to mark the VRAM cacheable, but in
>>a way that
>>  writes don't go into the cache. Would that be write-through?
>
>That's indeed write-through. Note that writes will still be cached in such a
>way that a consecutive read from the same location will return the cached
>value.  But writes will immediately be sent to the host bridge.

Unfortunately a side effect of write-through mode is that it prevents
burst writes.  Memory must be cacheable in copy-back mode for
existing PowerPC CPUs to perform burst writes.

Many Intel CPUs implement write combining for precisely this region.
In a memory region marked as OK for write combining, the CPU is free
to wait and collect data from several writes to perform a burst write
rather than performing a write immediately.

   Tim Seufert

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Michael Schmitz]

> > > Probably XF4 handles fix.smem_start being not on a page boundary
> > > incorrectly.
> >
> > What would it have to do to handle it?
>
> Round down smem_start and mmap() it, and readd the offset. Cfr.
>
>     addr = (unsigned long)mmap(NULL, ati_smem_len, PROT_READ | PROT_WRITE,
> 				MAP_SHARED, fb_fd, 0);
>
>     ati_smem = addr+ati_smem_offset;
>

Basically what we do in fbdev.c since two years or so (first happened on
Mac68k). But I don't think that's it: mmap would have barfed if you feed
it a start address that isn't page aligned.
Maybe a timing problem with the monitor?

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Michael Schmitz]

>
> Anyways, that's the long answer. The short answer is: no, you probably
> don't want to cache the framebuffer.

Thanks for the long answer, and all those nasty gremlins have actually
been observed long time ago when people started to play with the
framebuffer drivers. At least on m68k, the framebuffer address space was
set non-cacheable right from the start (in head.S). I would hope that
somehow translated to PPC as well :-)

	Michael

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Michel Lanners]

Hi there,

On   6 Jun, this message from Michael Schmitz echoed through cyberspace:
>> > > Probably XF4 handles fix.smem_start being not on a page boundary
>> > > incorrectly.
>> >
>> > What would it have to do to handle it?
>>
>> Round down smem_start and mmap() it, and readd the offset. Cfr.
>>
>>     addr = (unsigned long)mmap(NULL, ati_smem_len, PROT_READ | PROT_WRITE,
>> 				MAP_SHARED, fb_fd, 0);
>>
>>     ati_smem = addr+ati_smem_offset;
>
> Basically what we do in fbdev.c since two years or so (first happened on
> Mac68k). But I don't think that's it: mmap would have barfed if you feed
> it a start address that isn't page aligned.

How about incorrect rounding? Here is what I see (in ASCII art ;-):

  Pixel (168,-1)                      (0,-1)(0,0)    Pixel (167,0)
  *----------------------------------------**-----------------*
  |                                        ||                 |

I _think_ it starts with line -1, and not line 0. I could be wrong...
There could be an aliased region of VRAM just below framebuffer start...

Entire diplay width is 1152 pixels à 32 bit. So there are 1152-168=984
pixels on screen that are below pixel (0,0) in memory. The offset
between fb address 0 and pixel (0,0) is 80 bytes in this mode. 984
pixels are 964*4=3936 bytes. If you look closely, offset plus
displacement is just 80 bytes (offset again...) below the next page
boundary:
		80 + 3936 = 4016 = 4096 - 80

Bug in my calculation or XF4's?

> Maybe a timing problem with the monitor?

No, because both halves of the display fit together without sync
artefacts.

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Michel Lanners]

Hi all,

On   6 Jun, this message from Michael Schmitz echoed through cyberspace:
>> Anyways, that's the long answer. The short answer is: no, you probably
>> don't want to cache the framebuffer.
>
> Thanks for the long answer, and all those nasty gremlins have actually
> been observed long time ago when people started to play with the
> framebuffer drivers. At least on m68k, the framebuffer address space was
> set non-cacheable right from the start (in head.S). I would hope that
> somehow translated to PPC as well :-)

That's what fbmem.c does in its default mmap(). However, at least for
control (and maybe other comparable video implementations as well), you
get much better performance on scroll and other fb-to-fb copy
operations, without visible inconvenients, when the framebuffer is set
to write-through caching.

For fun, I tried write-back caching as well. Makes for some really nice
visual effects when your killed netscape starts to fade away as the
cache gets slowly flushed ;-))) And it doesn't even get you any speed
improvement...

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Geert Uytterhoeven]

On Tue, 6 Jun 2000, Michel Lanners wrote:
> On   6 Jun, this message from Michael Schmitz echoed through cyberspace:
> >> Anyways, that's the long answer. The short answer is: no, you probably
> >> don't want to cache the framebuffer.
> >
> > Thanks for the long answer, and all those nasty gremlins have actually
> > been observed long time ago when people started to play with the
> > framebuffer drivers. At least on m68k, the framebuffer address space was
> > set non-cacheable right from the start (in head.S). I would hope that
> > somehow translated to PPC as well :-)
>
> That's what fbmem.c does in its default mmap(). However, at least for
> control (and maybe other comparable video implementations as well), you
> get much better performance on scroll and other fb-to-fb copy
> operations, without visible inconvenients, when the framebuffer is set
> to write-through caching.

| $ grep ioremap drivers/video/amifb.c
| 	videomemory = (u_long)ioremap_writethrough(videomemory_phys, videomemorysize);

It does mean that if the accel engine draws something, and the CPU wants to
chnge that, that there may be a cache incoherency. For amifb that doesn't
matter since it's unaccelerated.

Summarized: use write-through cachine for unaccelerated hardware, no caching
for accelerated hardware.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Geert Uytterhoeven]

On Wed, 7 Jun 2000, Ryuichi Oikawa wrote:
> Geert did explain the problem. It is due to incorrect offset estimation.
> Let me explain your case in detail. The authur of fbdev module seems to
> assume frame buffer size as a multiple of page size:
>
> fbdevhw.c
> void* fbdevHWMapVidmem(ScrnInfoPtr pScrn)
> {
> 	fbdevHWPtr fPtr = FBDEVHWPTR(pScrn);
>
> 	TRACE_ENTER("MapVidmem");
> 	if (NULL == fPtr->fbmem) {
> 		fPtr->fboff = fPtr->fix.smem_len & (PAGE_SIZE-1);
> 			    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 		fPtr->fbmem = mmap(NULL, fPtr->fix.smem_len, PROT_READ | PROT_WRITE,
> 				   MAP_SHARED, fPtr->fd, 0);
>
> but the fact is different from his assumption.  As you know very well,
> controlfb adjusts fb memory size by subtracting display offset(in your
> case 80 = 0x50 bytes) so that
>     fboff = (4M - 0x50) & 0xfff = 0xfb0
>     fbmem = smem_start & 0xfffff000 = smem_start - 0x50.
>
> Thus your Xserver's video memory starts at offset
>     (fbmem + fboff) - smem_start = 0xfb0 - 0x50 = 0xf60 = 3936 bytes.
>
> Now you understand the fix is very simple:
> -		fPtr->fboff = fPtr->fix.smem_len & (PAGE_SIZE-1);
> +		fPtr->fboff = fPtr->fix.smem_start & (PAGE_SIZE-1);

That's not sufficient (perhaps it is in this case, though): both fix.smem_start
and fix.smem_len may be not page aligned. To catch all cases, you have to use
the formula from my previous posting.

> But looking through the XF4 fbdev support code I saw two more mistakes
> causing potential problem. One is a confusion of virtual screen width
> with screen pitch:
>
> fbdev.c
> 	pScrn->displayWidth = pScrn->virtualX; /* FIXME: might be wrong */
>
> Yes, this is wrong as the authur noted, but interestingly this code spreads
> over the all drivers supporting fbdev, though I can't distinguish which is
> the original :^)  Maybe polite solution is to fix each driver, but quick
> fix will be
>
> +	pScrn->displayWidth = fPtr->fix.line_width /
> +				(fPtr->var.bits_per_pixel >> 3)

Typo: the field is called `line_length', not `line_width'.

And that formula is valid for chunky displays only, not for interleaved
bitplanes (I suppose pScrn->displayWidth is the width of one line in memory,
counted in pixel units?).

If line_length is 0, you must fallback to xres_virtual / bytes_per_pixel.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248638 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Michael Schmitz]

> > Now you understand the fix is very simple:
> > -		fPtr->fboff = fPtr->fix.smem_len & (PAGE_SIZE-1);
> > +		fPtr->fboff = fPtr->fix.smem_start & (PAGE_SIZE-1);
>
> That's not sufficient (perhaps it is in this case, though): both fix.smem_start
> and fix.smem_len may be not page aligned. To catch all cases, you have to use
> the formula from my previous posting.

Did that just get lost between XFree release 3 and 4, or did we have it
wrong all along? I wonder if that was what caused problems on some m68k
Mac video hardware ...

> > Yes, this is wrong as the authur noted, but interestingly this code spreads
> > over the all drivers supporting fbdev, though I can't distinguish which is
> > the original :^)  Maybe polite solution is to fix each driver, but quick
> > fix will be
> >
> > +	pScrn->displayWidth = fPtr->fix.line_width /
> > +				(fPtr->var.bits_per_pixel >> 3)
>
> Typo: the field is called `line_length', not `line_width'.
>
> And that formula is valid for chunky displays only, not for interleaved
> bitplanes (I suppose pScrn->displayWidth is the width of one line in memory,
> counted in pixel units?).
>
> If line_length is 0, you must fallback to xres_virtual / bytes_per_pixel.

Is the displayWidth / xres_virtual synonymous to the line length (offset
between start of subsequent lines), or might displayWidth be used for
something else altogether? displayWidth seems a misnomer (on some
hardware, there's no video RAM between the end of one scan line and the
probably page aligned start of the next ...)?

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Geert Uytterhoeven]

On Wed, 7 Jun 2000, Michael Schmitz wrote:
> > > Now you understand the fix is very simple:
> > > -		fPtr->fboff = fPtr->fix.smem_len & (PAGE_SIZE-1);
> > > +		fPtr->fboff = fPtr->fix.smem_start & (PAGE_SIZE-1);
> >
> > That's not sufficient (perhaps it is in this case, though): both fix.smem_start
> > and fix.smem_len may be not page aligned. To catch all cases, you have to use
> > the formula from my previous posting.
>
> Did that just get lost between XFree release 3 and 4, or did we have it
> wrong all along? I wonder if that was what caused problems on some m68k
> Mac video hardware ...

It should be correct in 3.3.x.

> > > Yes, this is wrong as the authur noted, but interestingly this code spreads
> > > over the all drivers supporting fbdev, though I can't distinguish which is
> > > the original :^)  Maybe polite solution is to fix each driver, but quick
> > > fix will be
> > >
> > > +	pScrn->displayWidth = fPtr->fix.line_width /
> > > +				(fPtr->var.bits_per_pixel >> 3)
> >
> > Typo: the field is called `line_length', not `line_width'.
> >
> > And that formula is valid for chunky displays only, not for interleaved
> > bitplanes (I suppose pScrn->displayWidth is the width of one line in memory,
> > counted in pixel units?).
> >
> > If line_length is 0, you must fallback to xres_virtual / bytes_per_pixel.
>
> Is the displayWidth / xres_virtual synonymous to the line length (offset
> between start of subsequent lines), or might displayWidth be used for
> something else altogether? displayWidth seems a misnomer (on some
> hardware, there's no video RAM between the end of one scan line and the
> probably page aligned start of the next ...)?

At least in 3.3.6, X wasn't capable of handling displays where the offset to
the next line was not equal to what you'd expect from xres_virtual. The only
way to make such hardware work is to fake the virtual screen width
(displayWidth) by something derived from line_length.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Ryuichi Oikawa]

From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Subject: Re: [patch] VRAM detection in controlfb

>
> On Wed, 7 Jun 2000, Ryuichi Oikawa wrote:
> > Geert did explain the problem. It is due to incorrect offset estimation.
> > Let me explain your case in detail. The authur of fbdev module seems to
> > assume frame buffer size as a multiple of page size:
> >
> > fbdevhw.c
> > void* fbdevHWMapVidmem(ScrnInfoPtr pScrn)
> > {
> > 	fbdevHWPtr fPtr = FBDEVHWPTR(pScrn);
> >
> > 	TRACE_ENTER("MapVidmem");
> > 	if (NULL == fPtr->fbmem) {
> > 		fPtr->fboff = fPtr->fix.smem_len & (PAGE_SIZE-1);
> > 			    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > 		fPtr->fbmem = mmap(NULL, fPtr->fix.smem_len, PROT_READ | PROT_WRITE,
> > 				   MAP_SHARED, fPtr->fd, 0);
> >
> > but the fact is different from his assumption.  As you know very well,
> > controlfb adjusts fb memory size by subtracting display offset(in your
> > case 80 = 0x50 bytes) so that
> >     fboff = (4M - 0x50) & 0xfff = 0xfb0
> >     fbmem = smem_start & 0xfffff000 = smem_start - 0x50.
> >
> > Thus your Xserver's video memory starts at offset
> >     (fbmem + fboff) - smem_start = 0xfb0 - 0x50 = 0xf60 = 3936 bytes.
> >
> > Now you understand the fix is very simple:
> > -		fPtr->fboff = fPtr->fix.smem_len & (PAGE_SIZE-1);
> > +		fPtr->fboff = fPtr->fix.smem_start & (PAGE_SIZE-1);
>
> That's not sufficient (perhaps it is in this case, though): both fix.smem_start
> and fix.smem_len may be not page aligned. To catch all cases, you have to use
Can't /dev/fb mmap handle this case?  I just thought I saw some page
handling code which adds extra page in fbmem.c. I'm using this for /dev/mem:

  int pages, trailer_page = 0;

  if(basePhys & (PAGE_SIZE - 1))
    ++trailer_page;
  pages = (memSize + PAGE_SIZE - 1)/PAGE_SIZE + trailer_page;
  *baseVirt = (pointer)mmap(0, pages*PAGE_SIZE, PROT_READ|PROT_WRITE,
			    MAP_SHARED, fd, basePhys & PAGE_MASK);
  *baseVirt += basePhys & (PAGE_SIZE - 1);


> the formula from my previous posting.

> > But looking through the XF4 fbdev support code I saw two more mistakes
> > causing potential problem. One is a confusion of virtual screen width
> > with screen pitch:
> >
> > fbdev.c
> > 	pScrn->displayWidth = pScrn->virtualX; /* FIXME: might be wrong */
> >
> > Yes, this is wrong as the authur noted, but interestingly this code spreads
> > over the all drivers supporting fbdev, though I can't distinguish which is
> > the original :^)  Maybe polite solution is to fix each driver, but quick
> > fix will be
> >
> > +	pScrn->displayWidth = fPtr->fix.line_width /
> > +				(fPtr->var.bits_per_pixel >> 3)
>
> Typo: the field is called `line_length', not `line_width'.
 Ah, I see, but I simply cut & pasted it.... where this comes?

> And that formula is valid for chunky displays only, not for interleaved
> bitplanes (I suppose pScrn->displayWidth is the width of one line in memory,
> counted in pixel units?).
Yes, it is used calculate video memory address from the x, y coordinate.
How is displayWidth used for planar architecture? Is setting
displayWidth == xres_virtual necessary to work properly?

> If line_length is 0, you must fallback to xres_virtual / bytes_per_pixel.
Like this?
+	if(fPtr->fix.line_width)
+		pScrn->displayWidth = fPtr->fix.line_width /
+				(fPtr->var.bits_per_pixel >> 3)


Thanks you,

--------------------------------------
Ryuichi Oikawa
roikawa@rr.iij4u.or.jp
http://www.rr.iij4u.or.jp/~roikawa
--------------------------------------

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] VRAM detection in controlfb

[Geert Uytterhoeven]

On Thu, 8 Jun 2000, Ryuichi Oikawa wrote:
> From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> > That's not sufficient (perhaps it is in this case, though): both fix.smem_start
> > and fix.smem_len may be not page aligned. To catch all cases, you have to use
> Can't /dev/fb mmap handle this case?  I just thought I saw some page
> handling code which adds extra page in fbmem.c. I'm using this for /dev/mem:
>
>   int pages, trailer_page = 0;
>
>   if(basePhys & (PAGE_SIZE - 1))
>     ++trailer_page;
>   pages = (memSize + PAGE_SIZE - 1)/PAGE_SIZE + trailer_page;
>   *baseVirt = (pointer)mmap(0, pages*PAGE_SIZE, PROT_READ|PROT_WRITE,
> 			    MAP_SHARED, fd, basePhys & PAGE_MASK);
>   *baseVirt += basePhys & (PAGE_SIZE - 1);
>
> > the formula from my previous posting.

>From a first look, that looks very similar to my formula.

> > > But looking through the XF4 fbdev support code I saw two more mistakes
> > > causing potential problem. One is a confusion of virtual screen width
> > > with screen pitch:
> > >
> > > fbdev.c
> > > 	pScrn->displayWidth = pScrn->virtualX; /* FIXME: might be wrong */
> > >
> > > Yes, this is wrong as the authur noted, but interestingly this code spreads
> > > over the all drivers supporting fbdev, though I can't distinguish which is
> > > the original :^)  Maybe polite solution is to fix each driver, but quick
> > > fix will be
> > >
> > > +	pScrn->displayWidth = fPtr->fix.line_width /
> > > +				(fPtr->var.bits_per_pixel >> 3)
> >
> > Typo: the field is called `line_length', not `line_width'.
>  Ah, I see, but I simply cut & pasted it.... where this comes?
>
> > And that formula is valid for chunky displays only, not for interleaved
> > bitplanes (I suppose pScrn->displayWidth is the width of one line in memory,
> > counted in pixel units?).
> Yes, it is used calculate video memory address from the x, y coordinate.
> How is displayWidth used for planar architecture? Is setting
> displayWidth == xres_virtual necessary to work properly?

For non-interleaved bitplanes, the same formula as for chunky pixels is valid.
For interleaved bitplanes, displayWidth == xres_virtual (assumed you can
display the full xres_virtual).

> > If line_length is 0, you must fallback to xres_virtual / bytes_per_pixel.
> Like this?
> +	if(fPtr->fix.line_width)
> +		pScrn->displayWidth = fPtr->fix.line_width /
> +				(fPtr->var.bits_per_pixel >> 3)

Yes. But ilbm (interleaved bitplanes) still has to use a different formula.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/