Skip to contentSkip to conversation

radeonfb: massive update of PM code

PATCH In review Benjamin Herrenschmidt 2 participants 6 messages Jan 18, 2005 – Jan 28, 2005 Framebuffer layer

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 radeonfb: massive update of PM code

Hi !

This patch is a quite massive update to radeonfb. It adds the ability to reboot from scratch the various chip models used on the recent powermac laptops, adds a bunch of new chips (including R420 support, untested), plus various fixes here or there including LCD & flat panel blanking, abuse of stack usage in radeonfb_set_par(), and finally, adapts the PM code to the recent powermac changes.

drivers/video/aty/radeon_monitor.c +16 -15
Index: linux-work/drivers/video/aty/radeon_monitor.c
===================================================================
@@ -1,11 +1,6 @@
 #include "radeonfb.h"
 #include "../edid.h"
 
-#ifdef CONFIG_PPC_OF
-#include <asm/prom.h>
-#include <asm/pci-bridge.h>
-#endif /* CONFIG_PPC_OF */
-
 static struct fb_var_screeninfo radeonfb_default_var = {
 	.xres		= 640,
 	.yres		= 480,
@@ -64,9 +59,11 @@
  * models with broken OF probing by hard-coding known EDIDs for some Mac
  * laptops internal LVDS panel. (XXX: not done yet)
  */
-static int __devinit radeon_parse_montype_prop(struct device_node *dp, u8 **out_EDID, int hdno)
+static int __devinit radeon_parse_montype_prop(struct device_node *dp, u8 **out_EDID,
+					       int hdno)
 {
-        static char *propnames[] = { "DFP,EDID", "LCD,EDID", "EDID", "EDID1", "EDID2",  NULL };
+        static char *propnames[] = { "DFP,EDID", "LCD,EDID", "EDID",
+				     "EDID1", "EDID2",  NULL };
 	u8 *pedid = NULL;
 	u8 *pmt = NULL;
 	u8 *tmp;
@@ -122,7 +119,7 @@
 
 	RTRACE("radeon_probe_OF_head\n");
 
-        dp = pci_device_to_OF_node(rinfo->pdev);
+        dp = rinfo->of_node;
         while (dp == NULL)
 		return MT_NONE;
 
@@ -502,8 +499,9 @@
 #endif /* CONFIG_PPC_OF */
 #ifdef CONFIG_FB_RADEON_I2C
 			if (rinfo->mon1_type == MT_NONE)
-				rinfo->mon1_type = radeon_probe_i2c_connector(rinfo, ddc_dvi,
-								      &rinfo->mon1_EDID);
+				rinfo->mon1_type =
+					radeon_probe_i2c_connector(rinfo, ddc_dvi,
+								   &rinfo->mon1_EDID);
 			if (rinfo->mon1_type == MT_NONE)
 				rinfo->mon1_type =
 					radeon_probe_i2c_connector(rinfo, ddc_vga,
@@ -545,7 +543,8 @@
 		 */
 #ifdef CONFIG_PPC_OF
 		if (rinfo->mon1_type == MT_NONE)
-			rinfo->mon1_type = radeon_probe_OF_head(rinfo, 0, &rinfo->mon1_EDID);
+			rinfo->mon1_type = radeon_probe_OF_head(rinfo, 0,
+								&rinfo->mon1_EDID);
 #endif /* CONFIG_PPC_OF */
 #ifdef CONFIG_FB_RADEON_I2C
 		if (rinfo->mon1_type == MT_NONE)
@@ -572,7 +571,8 @@
 		 */
 #ifdef CONFIG_PPC_OF
 		if (rinfo->mon2_type == MT_NONE)
-			rinfo->mon2_type = radeon_probe_OF_head(rinfo, 1, &rinfo->mon2_EDID);
+			rinfo->mon2_type = radeon_probe_OF_head(rinfo, 1,
+								&rinfo->mon2_EDID);
 #endif /* CONFIG_PPC_OF */
 #ifdef CONFIG_FB_RADEON_I2C
 		if (rinfo->mon2_type == MT_NONE)
@@ -814,9 +814,10 @@
 	 * Now build modedb from EDID
 	 */
 	if (rinfo->mon1_EDID) {
-		rinfo->mon1_modedb = fb_create_modedb(rinfo->mon1_EDID,
-						      &rinfo->mon1_dbsize);
-		fb_get_monitor_limits(rinfo->mon1_EDID, &rinfo->info->monspecs);
+		fb_edid_to_monspecs(rinfo->mon1_EDID, &rinfo->info->monspecs);
+		fb_videomode_to_modelist(rinfo->info->monspecs.modedb,
+					 rinfo->info->monspecs.modedb_len,
+					 &rinfo->info->modelist);
 	}
 
 	
include/video/radeon.h +252 -220

652 lines not on this page · raw message

drivers/video/aty/radeon_base.c +358 -251

1,106 lines not on this page · raw message

drivers/video/aty/radeon_pm.c +2208 -394

1,168 lines not on this page · raw message

drivers/video/aty/radeonfb.h +166 -64

230 lines not on this page · raw message

drivers/video/aty/ati_ids.h +48 -5

53 lines not on this page · raw message

The rest of this diff is not shown. View the raw message.

Part of the diff is not shown here. View the raw message.

#1 lore raw

On 18 Jan 2005 at 12h01, Benjamin Herrenschmidt wrote:

Hi,

Quoted 1 line

+module_param(default_dynclk, int, -2);

Btw, I have been told that module_param()'s third parameters is an octal used for permissions (as 0644).

Signature · 3 lines
Colin
  Reality continues to ruin my life.
		-- Calvin
#2 lore raw
Quoted 8 lines · Colin Leroy

On 18 Jan 2005 at 12h01, Benjamin Herrenschmidt wrote:

Hi,

Quoted 1 line

+module_param(default_dynclk, int, -2);

Btw, I have been told that module_param()'s third parameters is an octal used for permissions (as 0644).

Ah ... oh well, I'll have to check that out with Rusty Ben.

#3 lore raw
In reply to Benjamin Herrenschmidt

On 18 Jan 2005 at 12h01, Benjamin Herrenschmidt wrote:

Hi Ben,

Quoted 6 lines

This patch is a quite massive update to radeonfb. It adds the ability to reboot from scratch the various chip models used on the recent powermac laptops, adds a bunch of new chips (including R420 support, untested), plus various fixes here or there including LCD & flat panel blanking, abuse of stack usage in radeonfb_set_par(), and finally, adapts the PM code to the recent powermac changes.

I just upgraded to 2.6.10, applied the 6 other patches you sent and this one. This one makes some heavy video corruption on my iBook G4 (PowerBook6,3). The patch applies with a 27 lines offset at most hunks, but does no rejects.

I'm using xorg 6.7.0, and your test sleep patch #7 on 2.6.9 worked fine.

Tell me if I can be of any help...

Thanks!

Signature · 2 lines
Colin
  "Dinner not ready: (A)bort (R)etry (P)izza"
#4 lore raw
Quoted 11 lines · Colin Leroy

On 18 Jan 2005 at 12h01, Benjamin Herrenschmidt wrote:

Hi Ben,

Quoted 6 lines

This patch is a quite massive update to radeonfb. It adds the ability to reboot from scratch the various chip models used on the recent powermac laptops, adds a bunch of new chips (including R420 support, untested), plus various fixes here or there including LCD & flat panel blanking, abuse of stack usage in radeonfb_set_par(), and finally, adapts the PM code to the recent powermac changes.

Quoted 8 lines

I just upgraded to 2.6.10, applied the 6 other patches you sent and this one. This one makes some heavy video corruption on my iBook G4 (PowerBook6,3). The patch applies with a 27 lines offset at most hunks, but does no rejects.

I'm using xorg 6.7.0, and your test sleep patch #7 on 2.6.9 worked fine.

Tell me if I can be of any help...

Well, this is basically equivalent to sleep #7 patch, so I'm not sure what's wrong...

Ben.

#5 lore raw

On 28 Jan 2005 at 10h01, Benjamin Herrenschmidt wrote:

Hi,=20

Quoted 2 lines

Well, this is basically equivalent to sleep #7 patch, so I'm not sure what's wrong...

Maybe the dynclk parameter which default changed? I'll do more tests as soon as possible...

--=20
Colin
4. la d=E9t=E9rioration de la t=EAte peut avoir de graves cons=E9quences.=
=20