[PATCH]: Make radeonfb work alot better with new powerbooks

[PATCH]: Make radeonfb work alot better with new powerbooks

[Daniel Berlin]

This patch makes the radeonfb work a lot better on the rev b powerbooks.
It's against benh's latest, as of last night.
Fixed/added:
1. Any other mode besides 640x480 was absurdly slow. Unusable, in fact.
It now is pretty darn quick, and completely usable.
2. It would default to 640x480, rather than 1152x768, on rev b powerbooks.
3. It would also determine that we had no monitor, and no display panel,
because it couldn't read the video bios that doesn't exist in the
powerbooks.
In reality, the LCD is on the DVI port.
So for rev b powerbooks, we go ahead and say so, and let it detect
the flat panel size/stretching/etc.
4. It would assume blanking meant blanking the crt. It will now turn off
the lcd as well.
5. It now supports the backlevel lighting control. It's the same on the
rage128 and the radeon, so i copied and renamed the routines from
aty128fb.c

It *shouldn't* have any problems on a normal radeon powermac, but i don't
have one to try it out on.

Hopefully, this is useful for someone besides me.
--Dan

diff -rupwBb ./radeon.h ../../benh/drivers/video/radeon.h
--- ./radeon.h	Wed Nov  7 09:54:02 2001
+++ ../../benh/drivers/video/radeon.h	Wed Nov  7 20:25:10 2001
@@ -523,6 +523,9 @@
 #define LVDS_PANEL_TYPE				   (1 << 2)
 #define LVDS_PANEL_FORMAT			   (1 << 3)
 #define LVDS_EN					   (1 << 7)
+#define LVDS_BL_MOD_LEVEL_MASK			   0x0000ff00
+#define LVDS_BL_MOD_LEVEL_SHIFT			   8
+#define LVDS_BL_MOD_EN				   (1 << 16)
 #define LVDS_DIGON				   (1 << 18)
 #define LVDS_BLON				   (1 << 19)
 #define LVDS_SEL_CRTC2				   (1 << 23)
diff -rupwBb ./radeonfb.c ../../benh/drivers/video/radeonfb.c
--- ./radeonfb.c	Wed Nov  7 09:54:03 2001
+++ ../../benh/drivers/video/radeonfb.c	Wed Nov  7 20:30:51 2001
@@ -41,8 +41,16 @@
 #include <linux/pci.h>

 #include <asm/io.h>
-#if defined(__powerpc__)
+#ifdef CONFIG_PPC
 #include <asm/prom.h>
+#include <asm/pci-bridge.h>
+#include <video/macmodes.h>
+#ifdef CONFIG_NVRAM
+#include <linux/nvram.h>
+#endif
+#endif
+#ifdef CONFIG_PMAC_BACKLIGHT
+#include <asm/backlight.h>
 #endif

 #include <video/fbcon.h>
@@ -547,6 +555,10 @@ static char fontname[40] __initdata;
 static char *mode_option __initdata;
 static char noaccel __initdata = 0;
 static char panel_yres __initdata = 0;
+#ifdef CONFIG_PPC
+static int default_vmode __initdata = VMODE_1024_768_60;
+static int default_cmode __initdata = CMODE_8;
+#endif

 #ifdef FBCON_HAS_CFB8
 static struct display_switch fbcon_radeon8;
@@ -613,6 +625,15 @@ static struct fb_ops radeon_fb_ops = {
 	fb_pan_display:		radeonfb_pan_display,
 	fb_ioctl:		radeonfb_ioctl,
 };
+#ifdef CONFIG_PMAC_BACKLIGHT
+static int radeon_set_backlight_enable(int on, int level, void* data);
+static int radeon_set_backlight_level(int level, void* data);
+
+static struct backlight_controller radeon_backlight_controller = {
+	radeon_set_backlight_enable,
+	radeon_set_backlight_level
+};
+#endif /* CONFIG_PMAC_BACKLIGHT */


 static struct pci_driver radeonfb_driver = {
@@ -843,8 +864,17 @@ static int radeonfb_pci_register (struct
 	radeon_get_pllinfo(rinfo, bios_seg);

 	RTRACE("radeonfb: probed %s %dk videoram\n", (rinfo->ram_type), (rinfo->video_ram/1024));
-
+#if !defined(__powerpc__)
 	radeon_get_moninfo(rinfo);
+#else
+	if (machine_is_compatible ("PowerBook3,3")) {
+		RTRACE("radeonfb: This is a powerbook, setting display mode to LCD\n");
+		rinfo->dviDisp_type = MT_LCD;
+	} else {
+		radeon_get_moninfo(rinfo);
+	}
+
+#endif
 	if ((rinfo->dviDisp_type == MT_DFP) || (rinfo->dviDisp_type == MT_LCD) ||
 	    (rinfo->crtDisp_type == MT_DFP)) {
 		if (!radeon_get_dfpinfo(rinfo)) {
@@ -908,6 +937,10 @@ static int radeonfb_pci_register (struct
 		/* initialize the engine */
 		radeon_engine_init (rinfo);
 	}
+#ifdef CONFIG_PMAC_BACKLIGHT
+	if (rinfo->dviDisp_type == MT_LCD)
+		register_backlight_controller(&radeon_backlight_controller, rinfo, "ati");
+#endif /* CONFIG_PMAC_BACKLIGHT */

 	printk ("radeonfb: ATI %s %s %d MB\n", rinfo->name, rinfo->ram_type,
 		(rinfo->video_ram/(1024*1024)));
@@ -1121,7 +1154,7 @@ static void radeon_get_moninfo (struct r
 		/* primary DVI port */
 		if (tmp & 0x08)
 			rinfo->dviDisp_type = MT_DFP;
-		else if (tmp & 0x4)
+		else if (tmp & 0x04)
 			rinfo->dviDisp_type = MT_LCD;
 		else if (tmp & 0x200)
 			rinfo->dviDisp_type = MT_CRT;
@@ -1172,7 +1205,12 @@ static int radeon_get_dfpinfo (struct ra
 			rinfo->panel_xres = 640; break;
 		case 600:
 			rinfo->panel_xres = 800; break;
-		case 786:
+	case 768:
+#ifdef CONFIG_PPC
+	if (machine_is_compatible("PowerBook3,3"))
+		rinfo->panel_xres = 1152; break;
+	else
+#endif
 			rinfo->panel_xres = 1024; break;
 		case 1024:
 			rinfo->panel_xres = 1280; break;
@@ -1241,6 +1279,8 @@ static void radeon_engine_init (struct r

 	/* disable 3D engine */
 	OUTREG(RB3D_CNTL, 0);
+	OUTREG(MC_FB_LOCATION, 0xffff0000);
+	OUTREG(MC_AGP_LOCATION, 0xffff0000);

 	radeon_engine_reset ();

@@ -1326,6 +1366,15 @@ static int __devinit radeon_init_disp (s
         disp = &rinfo->disp;

         disp->var = radeonfb_default_var;
+#ifdef CONFIG_PPC
+	if (machine_is_compatible("PowerBook3,3"))
+	{
+		default_vmode = VMODE_1152_768_60;
+		default_cmode = CMODE_8;
+		if (mac_vmode_to_var(default_vmode, default_cmode, &disp->var))
+			disp->var = radeonfb_default_var;
+	}
+#endif
         info->disp = disp;

         radeon_set_dispsw (rinfo, disp);
@@ -1333,7 +1382,7 @@ static int __devinit radeon_init_disp (s
 	if (noaccel)
 	        disp->scrollmode = SCROLL_YREDRAW;
 	else
-		disp->scrollmode = 0;
+		disp->scrollmode = SCROLL_YNOMOVE;

         rinfo->currcon_display = disp;

@@ -1353,8 +1402,20 @@ static int radeon_init_disp_var (struct
                               NULL, 0, NULL, 8);
         else
 #endif
+#ifdef CONFIG_PPC
+		if (machine_is_compatible("PowerBook3,3"))
+		{
+			default_vmode = VMODE_1152_768_60;
+			default_cmode = CMODE_8;
+			if (mac_vmode_to_var(default_vmode, default_cmode, &rinfo->disp.var))
+				rinfo->disp.var = radeonfb_default_var;
+		}
+		else
+#endif
+		{
                 fb_find_mode (&rinfo->disp.var, &rinfo->info, "640x480-8@60",
                               NULL, 0, NULL, 0);
+		}

 	if (noaccel)
 		rinfo->disp.var.accel_flags &= ~FB_ACCELF_TEXT;
@@ -1528,7 +1589,7 @@ static int radeonfb_get_fix (struct fb_f
         fix->type_aux = disp->type_aux;
         fix->visual = disp->visual;

-        fix->xpanstep = 1;
+        fix->xpanstep = 8;
         fix->ypanstep = 1;
         fix->ywrapstep = 0;

@@ -1537,9 +1598,9 @@ static int radeonfb_get_fix (struct fb_f
         fix->mmio_start = rinfo->mmio_base_phys;
         fix->mmio_len = RADEON_REGSIZE;
 	if (noaccel)
-	        fix->accel = FB_ACCEL_NONE;
+	        fix->accel &= ~FB_ACCELF_TEXT;
 	else
-		fix->accel = 40;	/* XXX */
+		fix->accel |= FB_ACCELF_TEXT;	/* XXX */

         return 0;
 }
@@ -1681,7 +1742,7 @@ static int radeonfb_set_var (struct fb_v
                 if (noaccel)
                         disp->scrollmode = SCROLL_YREDRAW;
                 else
-                        disp->scrollmode = 0;
+                        disp->scrollmode = SCROLL_YNOMOVE;

                 if (info && info->changevar)
                         info->changevar(con);
@@ -1771,6 +1832,60 @@ static int radeonfb_ioctl (struct inode
 {
 	return -EINVAL;
 }
+#ifdef CONFIG_PMAC_BACKLIGHT
+static int backlight_conv[] = {
+	0xff, 0xc0, 0xb5, 0xaa, 0x9f, 0x94, 0x89, 0x7e,
+	0x73, 0x68, 0x5d, 0x52, 0x47, 0x3c, 0x31, 0x24
+};
+
+/* We turn off the LCD completely instead of just dimming the backlight.
+ * This provides greater power saving and the display is useless without
+ * backlight anyway
+ */
+#define BACKLIGHT_LVDS_OFF
+/* That one prevents proper CRT output with LCD off */
+#undef BACKLIGHT_DAC_OFF
+
+static int
+radeon_set_backlight_enable(int on, int level, void* data)
+{
+	struct radeonfb_info *rinfo = (struct radeonfb_info *)data;
+	unsigned int reg = INREG(LVDS_GEN_CNTL);
+
+	reg |= LVDS_BL_MOD_EN | LVDS_BLON;
+	if (on && level > BACKLIGHT_OFF) {
+		reg &= ~LVDS_BL_MOD_LEVEL_MASK;
+		reg |= (backlight_conv[level] << LVDS_BL_MOD_LEVEL_SHIFT);
+#ifdef BACKLIGHT_LVDS_OFF
+		reg |= LVDS_ON | LVDS_EN;
+		reg &= ~LVDS_DISPLAY_DIS;
+#endif
+		OUTREG(LVDS_GEN_CNTL, reg);
+#ifdef BACKLIGHT_DAC_OFF
+		OUTREG(DAC_CNTL, INREG(DAC_CNTL) & (~DAC_PDWN));
+#endif
+	} else {
+		reg &= ~LVDS_BL_MOD_LEVEL_MASK;
+		reg |= (backlight_conv[0] << LVDS_BL_MOD_LEVEL_SHIFT);
+#ifdef BACKLIGHT_LVDS_OFF
+		reg &= ~(LVDS_ON | LVDS_EN);
+		reg |= LVDS_DISPLAY_DIS;
+#endif
+		OUTREG(LVDS_GEN_CNTL, reg);
+#ifdef BACKLIGHT_DAC_OFF
+		OUTREG(DAC_CNTL, INREG(DAC_CNTL) | DAC_PDWN);
+#endif
+	}
+
+	return 0;
+}
+
+static int
+radeon_set_backlight_level(int level, void* data)
+{
+	return radeon_set_backlight_enable(1, level, data);
+}
+#endif /* CONFIG_PMAC_BACKLIGHT */


 static int radeonfb_switch (int con, struct fb_info *info)
@@ -1830,10 +1945,17 @@ static void radeonfb_blank (int blank, s
 {
         struct radeonfb_info *rinfo = (struct radeonfb_info *) info;
         u32 val = INREG(CRTC_EXT_CNTL);
+        u32 val2 = INREG (LVDS_GEN_CNTL);
+
+#ifdef CONFIG_PMAC_BACKLIGHT
+	if (blank)
+		set_backlight_enable(0);
+#endif /* CONFIG_PMAC_BACKLIGHT */

         /* reset it */
         val &= ~(CRTC_DISPLAY_DIS | CRTC_HSYNC_DIS |
                  CRTC_VSYNC_DIS);
+	val2 &= ~(LVDS_DISPLAY_DIS);

         switch (blank) {
                 case VESA_NO_BLANKING:
@@ -1845,12 +1967,20 @@ static void radeonfb_blank (int blank, s
                         val |= (CRTC_DISPLAY_DIS | CRTC_HSYNC_DIS);
                         break;
                 case VESA_POWERDOWN:
+		val2 |= (LVDS_DISPLAY_DIS);
                         val |= (CRTC_DISPLAY_DIS | CRTC_VSYNC_DIS |
                                 CRTC_HSYNC_DIS);
                         break;
         }
-
+	if (rinfo->dviDisp_type == MT_LCD)
+		OUTREG(LVDS_GEN_CNTL, val2);
+	else
         OUTREG(CRTC_EXT_CNTL, val);
+
+#ifdef CONFIG_PMAC_BACKLIGHT
+	if (!blank)
+		set_backlight_enable(1);
+#endif
 }

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

Re: [PATCH]: Make radeonfb work alot better with new powerbooks

[Benjamin Herrenschmidt]

>
>This patch makes the radeonfb work a lot better on the rev b powerbooks.
>It's against benh's latest, as of last night.

Heh, Great ! I ordered a new TiPb but didn't get it yet :)

Could you send me a tarball of /proc/device-tree ?

>Fixed/added:
>1. Any other mode besides 640x480 was absurdly slow. Unusable, in fact.
>It now is pretty darn quick, and completely usable.
>2. It would default to 640x480, rather than 1152x768, on rev b powerbooks.
>3. It would also determine that we had no monitor, and no display panel,
>because it couldn't read the video bios that doesn't exist in the
>powerbooks.
>In reality, the LCD is on the DVI port.
>So for rev b powerbooks, we go ahead and say so, and let it detect
>the flat panel size/stretching/etc.

We need to fix this for DVI LCDs as well, for both radeon and aty128fb.

"Mac" radeons will put the monitor EDID in the device-tree, so we could
probably just parse that, but r128's firmware won't. I'd rather implement
the proper i2c code for reading that and add a generic fbdev ioctl for
retreiveing it (as it's not card specific) so userland tools can use it
to generate proper XF86Config as well.

>4. It would assume blanking meant blanking the crt. It will now turn off
>the lcd as well.
>5. It now supports the backlevel lighting control. It's the same on the
>rage128 and the radeon, so i copied and renamed the routines from
>aty128fb.c

Beware with blanking of the CRT/LCD. The current code I have for r128
seem to have problems. I've user reports on r128 of "burned" lines after
keeping the LCD off a long timech fortunately disappeared, but only after
several hours of normal use. I suspect a different shutdown sequence should
be used to properly turn off the LVDS and the panel itself, but I don't know
what for sure, the docs I have from ATI aren't very precise.

I want to remove part of that code and let only LVDS_DIS and backlight off.

>It *shouldn't* have any problems on a normal radeon powermac, but i don't
>have one to try it out on.

I'll try it on the radeon AGP card I have at work, if it still works, I'll
include it in my tree and bk _devel.

>Hopefully, this is useful for someone besides me.

Yup ;)

Regards,
Ben./


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

Re: [PATCH]: Make radeonfb work alot better with new powerbooks

[Daniel Berlin]

On Thursday, November 8, 2001, at 05:22  AM, Benjamin Herrenschmidt
wrote:

>>
>> This patch makes the radeonfb work a lot better on the rev b
>> powerbooks.
>> It's against benh's latest, as of last night.
>
> Heh, Great ! I ordered a new TiPb but didn't get it yet :)
:)
They are very nice.
In case you were wondering, here's a rundown of how things work:
Firewire is an LSI FW500 chip (AFAICT), and works with ohci1394 in your
tree without any changes.
The ethernet phy is something i've never seen before (It works, being
detected as a generic PHY). It's got an ID number that doesn't seem to
be like any of the others we can detect, but i could be wrong.
Sound seems the same as the ibook2 (TAS chip).
>
> Could you send me a tarball of /proc/device-tree ?
>
Sure, i'll do it when i get home today.
>> Fixed/added:
>> 1. Any other mode besides 640x480 was absurdly slow. Unusable, in fact.
>> It now is pretty darn quick, and completely usable.
>> 2. It would default to 640x480, rather than 1152x768, on rev b
>> powerbooks.
>> 3. It would also determine that we had no monitor, and no display
>> panel,
>> because it couldn't read the video bios that doesn't exist in the
>> powerbooks.
>> In reality, the LCD is on the DVI port.
>> So for rev b powerbooks, we go ahead and say so, and let it detect
>> the flat panel size/stretching/etc.
>
> We need to fix this for DVI LCDs as well, for both radeon and aty128fb.
> "Mac" radeons will put the monitor EDID in the device-tree, so we could
> probably just parse that, but r128's firmware won't. I'd rather
> implement
> the proper i2c code for reading that and add a generic fbdev ioctl for
> retreiveing it (as it's not card specific) so userland tools can use it
> to generate proper XF86Config as well.

The code to do i2c on the radeon and aty128fb doesn't seem that tricky
to implement ( At least, from reading the xfree86 drivers), so i might
take a whack at it.
>
>> 4. It would assume blanking meant blanking the crt. It will now turn
>> off
>> the lcd as well.
>> 5. It now supports the backlevel lighting control. It's the same on the
>> rage128 and the radeon, so i copied and renamed the routines from
>> aty128fb.c
>
> Beware with blanking of the CRT/LCD. The current code I have for r128
> seem to have problems. I've user reports on r128 of "burned" lines after
> keeping the LCD off a long timech fortunately disappeared, but only
> after
> several hours of normal use. I suspect a different shutdown sequence
> should
> be used to properly turn off the LVDS and the panel itself, but I don't
> know
> what for sure, the docs I have from ATI aren't very precise.
>
> I want to remove part of that code and let only LVDS_DIS and backlight
> off.
>
>> It *shouldn't* have any problems on a normal radeon powermac, but i
>> don't
>> have one to try it out on.
>
> I'll try it on the radeon AGP card I have at work, if it still works,
> I'll
> include it in my tree and bk _devel.
>
>> Hopefully, this is useful for someone besides me.
>
> Yup ;)
>
> Regards,
> Ben./
>


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

Re: [PATCH]: Make radeonfb work alot better with new powerbooks

[Benjamin Herrenschmidt]

>
>On Thursday, November 8, 2001, at 05:22  AM, Benjamin Herrenschmidt
>wrote:
>
>>>
>>> This patch makes the radeonfb work a lot better on the rev b
>>> powerbooks.
>>> It's against benh's latest, as of last night.
>>
>> Heh, Great ! I ordered a new TiPb but didn't get it yet :)
>:)
>They are very nice.
>In case you were wondering, here's a rundown of how things work:
>Firewire is an LSI FW500 chip (AFAICT), and works with ohci1394 in your
>tree without any changes.

It's not UniNorth internal firewire ? weird...

>The ethernet phy is something i've never seen before (It works, being
>detected as a generic PHY). It's got an ID number that doesn't seem to
>be like any of the others we can detect, but i could be wrong.

Apple love using a new phy for each new model. I just hope it's not yet
another undocumented broadcom part... well if it is (which is probably
the case if it's a gigabit), we might have to wait for the darwin driver
to get updated before beeing able to do gigabit.

>Sound seems the same as the ibook2 (TAS chip).

Ok, looks like I'll finally have a good excuse to work on this driver :)

>The code to do i2c on the radeon and aty128fb doesn't seem that tricky
>to implement ( At least, from reading the xfree86 drivers), so i might
>take a whack at it.

Ok. New coders are always welcome ;) There are a lot of things that would
be great on both the M3 (r128) and the new radeon: better support for
external CRT, support for S-video output, better panel detect...

Ben.


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

Re: [PATCH]: Make radeonfb work alot better with new powerbooks

[Daniel Berlin]

On Thursday, November 8, 2001, at 11:38  AM, Benjamin Herrenschmidt
wrote:

>>
>> On Thursday, November 8, 2001, at 05:22  AM, Benjamin Herrenschmidt
>> wrote:
>>
>>>>
>>>> This patch makes the radeonfb work a lot better on the rev b
>>>> powerbooks.
>>>> It's against benh's latest, as of last night.
>>>
>>> Heh, Great ! I ordered a new TiPb but didn't get it yet :)
>> :)
>> They are very nice.
>> In case you were wondering, here's a rundown of how things work:
>> Firewire is an LSI FW500 chip (AFAICT), and works with ohci1394 in your
>> tree without any changes.
>
> It's not UniNorth internal firewire ? weird...
Sorry, sorry, i was looking at the wrong node (node order changed, and i
wasn't paying attention to the GUID's).
That's the bridge on my IDE drive.
It's uninorth internal.
>
>> The ethernet phy is something i've never seen before (It works, being
>> detected as a generic PHY). It's got an ID number that doesn't seem to
>> be like any of the others we can detect, but i could be wrong.
>
> Apple love using a new phy for each new model. I just hope it's not yet
> another undocumented broadcom part... well if it is (which is probably
> the case if it's a gigabit), we might have to wait for the darwin driver
> to get updated before beeing able to do gigabit.
>
>> Sound seems the same as the ibook2 (TAS chip).
>
> Ok, looks like I'll finally have a good excuse to work on this driver :)
>
>> The code to do i2c on the radeon and aty128fb doesn't seem that tricky
>> to implement ( At least, from reading the xfree86 drivers), so i might
>> take a whack at it.
> Ben.
>


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

Re: [PATCH]: Make radeonfb work alot better with new powerbooks

[Adrian Cox]

Benjamin Herrenschmidt wrote:


> Ok. New coders are always welcome ;) There are a lot of things that would
> be great on both the M3 (r128) and the new radeon: better support for
> external CRT, support for S-video output, better panel detect...


I've been considering an attempt at the panel scaling on the r128, based
on the code in the X driver.

On the other chip I work on (CT69030) I deal with panel issues by
assuming that the boot firmware set the correct panel width, height and
type. How safe is this approach on the r128?

--
Adrian Cox   http://www.humboldt.co.uk/


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

Re: [PATCH]: Make radeonfb work alot better with new powerbooks

[Benjamin Herrenschmidt]

>On the other chip I work on (CT69030) I deal with panel issues by
>assuming that the boot firmware set the correct panel width, height and
>type. How safe is this approach on the r128?

Doesn't work. Some radeon firmwares will set a device-tree property
with the panel EDID, but r128's wont afaik, and I think it's bogus
in some cases. I'd prefer we use the i2c.

Ben.


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