Re: Tracking down radeonfb failure
Nikolaus Schulz wrote:
[ blank screen booting kernel 2.6.7 with radeonfb, missing EDID info ]
> Apparently radeonfb fails to retrieve necessary display info.
>
> ,----[ dmesg of 2.6.7 with CONFIG_FB_RADEON_DEBUG ]
> | PCI: Probing PCI hardware
> | Registering openpic with sysfs...
> | radeonfb_pci_register BEGIN
> | PCI: Enabling device 0000:00:10.0 (0086 -> 0087)
> | aper_base: 98000000 MC_FB_LOC to: 9bff9800, MC_AGP_LOC to: ffffa000
> | radeonfb: probed DDR SGRAM 32768k videoram
> | radeonfb: mapped 16384k videoram
> | radeonfb: Invalid ROM signature 0 should be 0xaa55
> | radeonfb: Retreived PLL infos from Open Firmware
> | radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=180.00 Mhz, System=180.00 MHz
> | Starting monitor auto detection...
> | radeonfb: I2C (port 1) ... not found
> | radeonfb: I2C (port 2) ... not found
> | radeonfb: I2C (port 3) ... not found
> | radeonfb: I2C (port 4) ... not found
> | radeon_probe_OF_head
> | head: ATY,Bee_A (letter: A, head_no: 0)
> | analyzing OF properties...
> | display-type: LCD
> | radeon_probe_OF_head
> | head: ATY,Bee_A (letter: A, head_no: 1)
> | radeonfb: I2C (port 3) ... not found
> | radeonfb: I2C (port 4) ... not found
> | radeonfb: Monitor 1 type LCD found
> | radeonfb: Monitor 2 type no found
> | Guessing panel info...
> | radeonfb: Assuming panel size 8x1
^^^^^^^^^^^^^^^^^^^^^^^
This is the critical failure.
> | radeonfb: Power Management enabled for Mobility chipsets
> | Registered "ati" backlight controller, level: 15/15
> | radeonfb: ATI Radeon LW DDR SGRAM 32 MB
> | radeonfb_pci_register END
> `----
[...]
> ,----[ radeon_monitor.c lines 825-833 ]
> | RTRACE("Guessing panel info...\n");
> | if (rinfo->panel_info.xres == 0 || rinfo->panel_info.yres == 0) {
> | u32 tmp = INREG(FP_HORZ_STRETCH) & HORZ_PANEL_SIZE;
> | rinfo->panel_info.xres = ((tmp >> HORZ_PANEL_SHIFT) + 1) * 8;
> | tmp = INREG(FP_VERT_STRETCH) & VERT_PANEL_SIZE;
> | rinfo->panel_info.yres = (tmp >> VERT_PANEL_SHIFT) + 1;
> | }
> | if (rinfo->panel_info.xres == 0 || rinfo->panel_info.yres == 0) {
> | printk(KERN_WARNING "radeonfb: Can't find panel size, going back to CRT\n");
> `----
>
> I'd say this looks plain wrong, the second "if" will never be triggered.
Hmmm. I'll file this as a kernel bug.
> This is the source of the weird "Assuming panel size 8x1" message in
> dmesg. --
Apparently only this detection of the panel size needs to be fixed to
make it work.
At least AFAICS for now, the patch below, hardcoding the panel size into
the driver, is good enough for me. Both the console and X are now fine.
--- PATCH ---
diff -ru a/drivers/video/aty/radeon_monitor.c b/drivers/video/aty/radeon_monitor.c
--- a/drivers/video/aty/radeon_monitor.c Wed Jun 16 07:18:37 2004
+++ b/drivers/video/aty/radeon_monitor.c Sun Sep 5 04:44:14 2004
@@ -829,10 +829,10 @@
tmp = INREG(FP_VERT_STRETCH) & VERT_PANEL_SIZE;
rinfo->panel_info.yres = (tmp >> VERT_PANEL_SHIFT) + 1;
}
- if (rinfo->panel_info.xres == 0 || rinfo->panel_info.yres == 0) {
- printk(KERN_WARNING "radeonfb: Can't find panel size, going back to CRT\n");
- rinfo->mon1_type = MT_CRT;
- goto pickup_default;
+ if (rinfo->panel_info.xres == 8 || rinfo->panel_info.yres == 1) {
+ rinfo->panel_info.xres = 1024;
+ rinfo->panel_info.yres = 768;
+ printk(KERN_WARNING "radeonfb: Can't find panel size, falling back to hardcoded value\n");
}
printk(KERN_WARNING "radeonfb: Assuming panel size %dx%d\n",
rinfo->panel_info.xres, rinfo->panel_info.yres);
--- END PATCH ---
Even if it's really a hardware failure -- as e.g. Benh assumed in [1]:
MacOS is still okay, obviously its driver has some mechanism to cope
with this situation.
This means there is some way to determine the panel size the radeonfb
driver misses, right?
Please, can someone comment on this issue?
Nikolaus
[1] http://lists.debian.org/debian-powerpc/2003/08/msg00473.html
Reply to: