Bug 6215 - radeonfb doesn't work at all with ATI Radeon XPRESS 200M 5955 (PCIE)
Summary: radeonfb doesn't work at all with ATI Radeon XPRESS 200M 5955 (PCIE)
Status: CLOSED PATCH_ALREADY_AVAILABLE
Alias: None
Product: Drivers
Classification: Unclassified
Component: Console/Framebuffers (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Benjamin Herrenschmidt
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-11 11:53 UTC by Ralf Hildebrandt
Modified: 2007-07-05 09:10 UTC (History)
9 users (show)

See Also:
Kernel Version: 2.6.16-rc5-mm3
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
Xorg log for that card (135.51 KB, text/plain)
2006-03-12 08:37 UTC, Ralf Hildebrandt
Details
this is the xorg.log with the same graphics card. radeon driver works OK (37.28 KB, text/plain)
2006-06-18 07:33 UTC, Christian Hoffmann
Details
if i add my PCI ids to the radeonfb driver, I get this output. Panel size etc are wrong. And of course it doesnt work. (9.44 KB, text/plain)
2006-06-18 07:35 UTC, Christian Hoffmann
Details
ATOM BIOS parsing patch, plus X700 support. (72.99 KB, patch)
2006-06-19 10:53 UTC, Solomon Peachy
Details | Diff
ATOM BIOS parsing for radeonfb, rebased against 2.6.17 (plus X700/M26 support) (198 bytes, patch)
2006-09-05 07:48 UTC, Solomon Peachy
Details | Diff
dmesg output with CONFIG_FB_RADEON_I2C=y (17.60 KB, text/plain)
2006-09-06 09:48 UTC, Chí-Thanh Christopher Nguyễn
Details
dmesg output with CONFIG_FB_RADEON_I2C=n (17.64 KB, text/plain)
2006-09-06 09:51 UTC, Chí-Thanh Christopher Nguyễn
Details
v5a of the ATOM BIOS patch, against 2.6.17 (72.69 KB, patch)
2006-09-06 11:20 UTC, Solomon Peachy
Details | Diff
ATOM BIOS patch v5a, against 2.6.18-rc6 (72.94 KB, patch)
2006-09-06 11:22 UTC, Solomon Peachy
Details | Diff
RADEON ATOM patch v5b (2.6.17) (72.97 KB, patch)
2006-09-06 13:31 UTC, Solomon Peachy
Details | Diff
RADEON ATOM patch v5b (2.6.18-rc6) (73.22 KB, patch)
2006-09-06 13:38 UTC, Solomon Peachy
Details | Diff
edid files from /sys (30.00 KB, application/x-tar)
2006-09-06 13:55 UTC, Chí-Thanh Christopher Nguyễn
Details
dmesg output after applying patch v5b (17.78 KB, text/plain)
2006-09-06 13:59 UTC, Chí-Thanh Christopher Nguyễn
Details
Radeon ATOM patch v6a (vs 2.6.18.x) plus PCI IDs (190 bytes, patch)
2006-11-05 05:42 UTC, Solomon Peachy
Details | Diff
dmesg output (15.07 KB, text/plain)
2006-11-05 07:25 UTC, Christian Hoffmann
Details
radeonfb ATOM patch v6a, rebased to 2.6.19-rc5 (84.88 KB, patch)
2006-11-08 21:09 UTC, Solomon Peachy
Details | Diff
simple patch that addes the ids to radeonfb (1.18 KB, patch)
2007-04-07 21:29 UTC, Jory A. Pratt
Details | Diff

Description Ralf Hildebrandt 2006-03-11 11:53:43 UTC
Most recent kernel where this bug did not occur: -
Distribution: Debian/unstable
Hardware Environment: ATI Radeon XPRESS 200M 5955 (PCIE)
Software Environment:
Problem Description:

This card works OK with X.org, but "modprobe radeonfb" gives me NO output, and 
the "dmesg" output also indicates no clue as to radeonfb's presence.
Needless to say, the FB console doesn't work either.

lspci -v lists:

0000:01:05.0 VGA compatible controller: ATI Technologies Inc ATI Radeon XPRESS 
200M 5955 (PCIE) (prog-if 00 [VGA])
        Subsystem: Micro-Star International Co., Ltd.: Unknown device 0131
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 10
        Memory at f0000000 (32-bit, prefetchable) [size=128M]
        I/O ports at d800 [size=256]
        Memory at fbef0000 (32-bit, non-prefetchable) [size=64K]
        Expansion ROM at fbec0000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 2

# grep -i radeon .config
CONFIG_DRM_RADEON=m
# CONFIG_FB_RADEON_OLD is not set
CONFIG_FB_RADEON=m
CONFIG_FB_RADEON_I2C=y
CONFIG_FB_RADEON_DEBUG=y

# lsmod| egrep "(radeon|i2c)" 
radeonfb              142844  0 
fb                     44700  1 radeonfb
i2c_algo_bit            8136  1 radeonfb
cfbcopyarea             3392  1 radeonfb
cfbimgblt               2560  1 radeonfb
cfbfillrect             3648  1 radeonfb
radeon                109856  0 
drm                    61652  1 radeon
ir_kbd_i2c              6160  1 saa7134
ir_common              23492  2 saa7134,ir_kbd_i2c
Comment 1 Benjamin Herrenschmidt 2006-03-11 15:13:40 UTC
I'm surprised it works with X.org... which driver do you use in X ? I though
X200 wasn't supported at all due to a weird memory controller that nobody has
reverse engineered yet (and no specs of course). Maybe you are using the vesa
driver in X ? If it actually works with "radeon", can you attach the X log ?
Comment 2 Ralf Hildebrandt 2006-03-12 08:36:46 UTC
It works with Xorg (Version xserver-xorg 6.9.0.dfsg.1-4) using the "radeon" 
driver.

Comment 3 Ralf Hildebrandt 2006-03-12 08:37:34 UTC
Created attachment 7562 [details]
Xorg log for that card
Comment 4 Ralf Hildebrandt 2006-03-20 03:59:59 UTC
2.6.16-rc6-mm2 and still no radeonfb :)
Comment 5 Benjamin Herrenschmidt 2006-03-22 17:25:50 UTC
Yes, sorry about that. I'm still busy trying to make X radeon driver stable
again and am fixing loads of bugs there. Once that's done, I need to sync with
Solomon Peachy who is doing some other great work on radeonfb to bring that and
all my memory map related X fixes back into radeonfb. I simply didn't have time
so far.
Comment 6 Solomon Peachy 2006-03-30 10:09:20 UTC
I have some spare cycles I can devote to further radeonfb work.  Let me know if
there's something I can do to ease your workload.
Comment 7 Christian Hoffmann 2006-06-18 07:31:50 UTC
Hello,

I have a Mobility X700 PCIE and have the same issue. The xorg radeon driver
works ok, but radeonfb doesnt kick in. I add the PCI id myself, but with little
luck: the detected panel properties are completely wrong.

Here some infos:
lspci -v:
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility X700
(PCIE) (prog-if 00 [VGA])
        Subsystem: Acer Incorporated [ALI] Unknown device 007e
        Flags: bus master, fast devsel, latency 0, IRQ 10
        Memory at c8000000 (32-bit, prefetchable) [size=128M]
        I/O ports at 9000 [size=256]
        Memory at c0100000 (32-bit, non-prefetchable) [size=64K]
        [virtual] Expansion ROM at c0120000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 2
        Capabilities: [58] Express Endpoint IRQ 0
        Capabilities: [80] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
        Capabilities: [100] Advanced Error Reporting

lspci -vn:

01:00.0 0300: 1002:5653
        Subsystem: 1025:007e
        Flags: bus master, fast devsel, latency 0, IRQ 10
        Memory at c8000000 (32-bit, prefetchable) [size=128M]
        I/O ports at 9000 [size=256]
        Memory at c0100000 (32-bit, non-prefetchable) [size=64K]
        [virtual] Expansion ROM at c0120000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 2
        Capabilities: [58] Express Endpoint IRQ 0
        Capabilities: [80] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
        Capabilities: [100] Advanced Error Reporting


Comment 8 Christian Hoffmann 2006-06-18 07:33:19 UTC
Created attachment 8332 [details]
this is the xorg.log with the same graphics card. radeon driver works OK
Comment 9 Christian Hoffmann 2006-06-18 07:35:54 UTC
Created attachment 8333 [details]
if i add my PCI ids to the radeonfb driver, I get this output. Panel size etc are wrong. And of course it doesnt work.
Comment 10 Benjamin Herrenschmidt 2006-06-18 16:52:40 UTC
Solomon has a patch for that, not sure what the status is at this point... I
didn't find the time to include it lately but it would be nice if he could
attach his latest version to this bug report.
Comment 11 Solomon Peachy 2006-06-19 10:53:25 UTC
Created attachment 8344 [details]
ATOM BIOS parsing patch, plus X700 support.

I've attached the last work I did on this; it adds mostly-complete ATOM parsing
and re-jiggers a few other things relating to multi-head detection.  It's
against 2.6.15, but doesn't apply cleanly to 2.6.16 and 2.6.17.  I'll re-base
it later today.

I can do more work with this if so desired.
Comment 12 Christian Hoffmann 2006-06-21 23:25:38 UTC
i would test it but I have 2.6.17, could you please post the reworked patch as well?

Thanks Chris
Comment 13 Chí-Thanh Christopher Nguyễn 2006-08-03 16:11:01 UTC
Is it planned to include this patch in 2.6.18?
If not, is there a workaround to pass the correct panel parameters manually to
radeonfb?
Comment 14 Solomon Peachy 2006-09-05 07:48:16 UTC
Created attachment 8943 [details]
ATOM BIOS parsing for radeonfb, rebased against 2.6.17 (plus X700/M26 support)

This is an updated version of the radeon-atom-5 patch, rebased against 2.6.17. 
It only took me three months.  :)

I'd love to see this work get into the mainline kernel, as it lets many more
people use radeonfb, especially if they have newer hardware.

I've tested this on my RV410 (X700/M26 PCIE) laptop and an old RV200 (7500 AGP)
card.
Comment 15 Solomon Peachy 2006-09-05 08:20:14 UTC
The short set of changes in the radeonfb-atom-2.6.17-v5 patch:

 * ATOM BIOS support for newer Radeon cards
 * Clean method of detecting and handling disparate BIOS types
 * Radeon RV410/M26/M26GL (aka Mobility X700/FireGL5000) card IDs
 * Default PLL clocks for R420 and variants
 * Handle bogus PLL divider with sane default.
 * All new connector/head detection code that uses bios/firmware
   defaults whenever possible
Comment 16 Chí-Thanh Christopher Nguyễn 2006-09-06 06:57:28 UTC
I think the type of attachment 8943 [details] should be "text/html" and not "patch".

Unfortunately, the display on my Mobility Radeon X700 PCIE still gets garbled
when activating the framebuffer console.

radeonfb dmesg output:

radeonfb: Retrieved PLL infos from ATOM BIOS
radeonfb: Reference=27.00 MHz (RefDiv=7) Memory=300.00 Mhz, System=358.00 MHz
radeonfb: PLL min 20000 max 50000
TMDS PLL from BIOS: 16500 b0112
 * Connector 1 is Internal Panel. Head 0, Monitor: CRT EDID probed
   ddc port: 0, dac: -1, tmds: -1
 * Connector 2 is VGA. Head -1, Monitor: None
   ddc port: 2, dac: 0, tmds: -1
 * Connector 3 is S-Video. Head -1, Monitor: None
   ddc port: 2, dac: 1, tmds: -1
 * Connector 4 is DVI-D. Head -1, Monitor: None
   ddc port: 1, dac: -1, tmds: 0
radeonfb: Dynamic Clock Power Management enabled
radeonfb (0000:01:00.0): ATI Radeon VS
Comment 17 Solomon Peachy 2006-09-06 07:38:15 UTC
This is the curious line:

 * Connector 1 is Internal Panel. Head 0, Monitor: CRT EDID probed

What seems to be happening is i2c 
It tells me that it thinks you have an internal panel, but it thinks you have a
CRT attached.  It even gets an EDID, which is unusual.  

So, this is what I need from you:

0) What is the architechure of your system (eg ppc or x86), and what is the
physical configuration you have?  (eg Laptop LCD, plus CRT plugged into the VGA
port)
1) Turn on CONFIG_FB_RADEON_DEBUG, and paste the full output for your current
config.
2) A list of the module arguments you're using, if any.
3) is CONFIG_FB_RADEON_I2C enabled?  (should be)
4) If you are using the laptop's LCD only, try adding monitor_layout=LVDS,NONE
to the command line (this should work)
Comment 18 Chí-Thanh Christopher Nguyễn 2006-09-06 09:48:48 UTC
Created attachment 8958 [details]
dmesg output with CONFIG_FB_RADEON_I2C=y

I am running x86_64 architecture (gentoo-2.6.17) and use the internal panel
only. If I connect an external CRT on boot, the panel will remain dark.

This attachmend is the output when CONFIG_FB_RADEON_I2C is enabled. Specifying
monitor_layout=LVDS,NONE will not help.

What helps is disabling I2C, the screen is no longer garbled after activating
the framebuffer console.
Comment 19 Chí-Thanh Christopher Nguyễn 2006-09-06 09:51:52 UTC
Created attachment 8959 [details]
dmesg output with CONFIG_FB_RADEON_I2C=n
Comment 20 Solomon Peachy 2006-09-06 11:20:46 UTC
Created attachment 8960 [details]
v5a of the ATOM BIOS patch, against 2.6.17 

I've attached an updated version of the v5 patch that should take care of the
I2C/DDC mis-detection on your system.  

I have a version of this patch against 2.6.18-rc6; I'll attach it later.
Comment 21 Solomon Peachy 2006-09-06 11:22:04 UTC
Created attachment 8961 [details]
ATOM BIOS patch v5a, against 2.6.18-rc6

v5a of the patch, rediffed against 2.6.18-rc6.
Comment 22 Chí-Thanh Christopher Nguyễn 2006-09-06 13:16:39 UTC
Thank you, the panel is detected correctly with patch v5a. I have noticed that
X.org 7.1 will also mis-detect the panel as CRT unless I add

MonitorLayout "LVDS, NONE"

to the "Device" section of xorg.conf
Comment 23 Solomon Peachy 2006-09-06 13:31:23 UTC
Created attachment 8963 [details]
RADEON ATOM patch v5b (2.6.17)

On further reflection, my v5a patch is not the ideal solution.	If the EDID
data is valid, we should use it (and return the correct monitor type) as it's
possible that there won't be LVDS info in the BIOS.

Please try the v5b patch, and send me a copy of the kernel log and the EDID
data from the panel.  (Leave I2C on, please..)	Your EDID data will help me
determine how to proceed.

(find /sys |grep edid)
Comment 24 Solomon Peachy 2006-09-06 13:38:38 UTC
Created attachment 8964 [details]
RADEON ATOM patch v5b (2.6.18-rc6)

v5b of the ATOM fix, against 2.6.18-rc6
Comment 25 Chí-Thanh Christopher Nguyễn 2006-09-06 13:55:48 UTC
Created attachment 8965 [details]
edid files from /sys

The tar contains the following files:

/sys/module/radeonfb/sections/.text.radeon_show_edid4
/sys/module/radeonfb/sections/.text.radeon_show_edid3
/sys/module/radeonfb/sections/.text.radeon_show_edid2
/sys/module/radeonfb/sections/.text.radeon_show_edid1
/sys/module/radeonfb/sections/.text.radeon_show_one_edid
/sys/devices/pci0000:00/0000:00:02.0/0000:01:00.0/edid1
Comment 26 Chí-Thanh Christopher Nguyễn 2006-09-06 13:59:54 UTC
Created attachment 8966 [details]
dmesg output after applying patch v5b
Comment 27 Henning Botha 2006-09-14 09:39:09 UTC
Good to see someone is updating radeonfb, thanks Solomon.

Version 5b doesn't appear to detect my panel ("Monitor: None"), though it does
"assume" correctly that its native resolution is 1280x800.

On loading this way the screen just goes black. My dmesg output is below, please
let me know if you need more.

Thanks.

radeonfb: Retrieved PLL infos from ATOM BIOS
radeonfb: Reference=27.00 MHz (RefDiv=7) Memory=330.00 Mhz, System=358.00 MHz
radeonfb: PLL min 20000 max 50000
TMDS PLL from BIOS: 16500 b0112
 * Connector 1 is Internal Panel. Head -1, Monitor: None 
   ddc port: 2, dac: -1, tmds: -1
 * Connector 2 is VGA. Head -1, Monitor: None 
   ddc port: 2, dac: 0, tmds: -1
 * Connector 3 is S-Video. Head -1, Monitor: None 
   ddc port: 2, dac: 1, tmds: -1
 * Connector 4 is DVI-D. Head -1, Monitor: None 
   ddc port: 1, dac: -1, tmds: 0
radeonfb: Assuming panel size 1280x800
radeonfb: Dynamic Clock Power Management enabled
Console: switching to colour frame buffer device 160x64
radeonfb (0000:01:00.0): ATI Radeon VS 
Comment 28 Solomon Peachy 2006-09-14 12:56:39 UTC
Henning,

If you could re-build the driver with CONFIG_FB_RADEON_DEBUG=y, and paste the
output of that.. it will help tell me where things are going wrong.  The odd
thing here is that it isn't assigning "displays" to "heads". 

Next, check what CONFIG_FB_RADEON_I2C is set to; change it, rebuild, and send me
the results of that.  (basically, I need to see the results of I2C both enabled
and disabled when you have DEBUG turned on..)

Also, does it work when you specify a layout?  (like monitor_layout=LVDS,NONE)

Finally.. if you're using 2.6.18-rc, try this patch instead:

  http://www.shaftnet.org/users/pizza/radeonfb-atom-2.6.18-v6.diff

It adds a few more features and fixes (and many, many cardIDs) but those are
unrelated to the BIOS parsing and head detection/selection changes.
Comment 29 Henning Botha 2006-09-15 03:35:17 UTC
Here are the results of my experiments.

With DDC:
radeonfb_pci_register BEGIN
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 18 (level, low) -> IRQ 50
radeonfb (0000:01:00.0): Found 131072k of DDR 128 bits wide videoram
radeonfb (0000:01:00.0): mapped 16384k videoram
radeonfb: Retrieved PLL infos from ATOM BIOS
radeonfb: Reference=27.00 MHz (RefDiv=7) Memory=330.00 Mhz, System=358.00 MHz
radeonfb: PLL min 20000 max 50000
TMDS PLL from BIOS: 16500 b0112
index 0 port 0 conn 1 dac 0 ddc 2 tmds -1
index 1 port 0 conn 7 dac -1 ddc 2 tmds -1
index 2 port 0 conn 5 dac 1 ddc 2 tmds -1
index 3 port 1 conn 3 dac -1 ddc 1 tmds 0
Starting monitor auto detection...
radeonfb: I2C (port 2) ... not found
radeonfb: I2C (port 2) ... not found
radeonfb: I2C (port 2) ... not found
radeonfb: I2C (port 1) ... not found
 * Connector 1 is Internal Panel. Head -1, Monitor: None 
   ddc port: 2, dac: -1, tmds: -1
 * Connector 2 is VGA. Head -1, Monitor: None 
   ddc port: 2, dac: 0, tmds: -1
 * Connector 3 is S-Video. Head -1, Monitor: None 
   ddc port: 2, dac: 1, tmds: -1
 * Connector 4 is DVI-D. Head -1, Monitor: None 
   ddc port: 1, dac: -1, tmds: 0
Parsing EDID data for panel info
Guessing panel info...
radeonfb: Assuming panel size 1280x800
radeonfb: Dynamic Clock Power Management enabled
hStart = 1296, hEnd = 1512, hTotal = 1568
vStart = 1025, vEnd = 1037, vTotal = 1165
h_total_disp = 0x9f00c3^I   hsync_strt_wid = 0x9b051a
v_total_disp = 0x3ff048c^I   vsync_strt_wid = 0x8c0400
pixclock = 12500
freq = 8000
freq = 8000, PLL min = 20000, PLL max = 50000
ref_div = 7, ref_clk = 2700, output_freq = 32000
ref_div = 7, ref_clk = 2700, output_freq = 32000
post div = 0x2
fb_div = 0x53
ppll_div_3 = 0x20053
Console: switching to colour frame buffer device 160x64
radeonfb (0000:01:00.0): ATI Radeon VS 
radeonfb_pci_register END

No DDC:
radeonfb (0000:01:00.0): Found 131072k of DDR 128 bits wide videoram
radeonfb (0000:01:00.0): mapped 16384k videoram
radeonfb: Retrieved PLL infos from ATOM BIOS
radeonfb: Reference=27.00 MHz (RefDiv=7) Memory=330.00 Mhz, System=358.00 MHz
radeonfb: PLL min 20000 max 50000
TMDS PLL from BIOS: 16500 b0112
index 0 port 0 conn 1 dac 0 ddc 2 tmds -1
index 1 port 0 conn 7 dac -1 ddc 2 tmds -1
index 2 port 0 conn 5 dac 1 ddc 2 tmds -1
index 3 port 1 conn 3 dac -1 ddc 1 tmds 0
Starting monitor auto detection...
 * Connector 1 is Internal Panel. Head -1, Monitor: Not Probed Yet 
   ddc port: 2, dac: -1, tmds: -1
 * Connector 2 is VGA. Head -1, Monitor: Not Probed Yet 
   ddc port: 2, dac: 0, tmds: -1
 * Connector 3 is S-Video. Head -1, Monitor: Not Probed Yet 
   ddc port: 2, dac: 1, tmds: -1
 * Connector 4 is DVI-D. Head -1, Monitor: Not Probed Yet 
   ddc port: 1, dac: -1, tmds: 0
Parsing EDID data for panel info
Guessing panel info...
radeonfb: Assuming panel size 1280x800
radeonfb: Dynamic Clock Power Management enabled
hStart = 1296, hEnd = 1512, hTotal = 1568
vStart = 1025, vEnd = 1037, vTotal = 1165
h_total_disp = 0x9f00c3^I   hsync_strt_wid = 0x9b051a
v_total_disp = 0x3ff048c^I   vsync_strt_wid = 0x8c0400
pixclock = 12500
freq = 8000
freq = 8000, PLL min = 20000, PLL max = 50000
ref_div = 7, ref_clk = 2700, output_freq = 32000
ref_div = 7, ref_clk = 2700, output_freq = 32000
post div = 0x2
fb_div = 0x53
ppll_div_3 = 0x20053
Console: switching to colour frame buffer device 160x64
radeonfb (0000:01:00.0): ATI Radeon VS 
radeonfb_pci_register END

I have 2.6.17 so I couldn't try the other driver. However, specifying the
monitor layout manually (no ddc) worked like a charm:
radeonfb_pci_register BEGIN
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 18 (level, low) -> IRQ 50
radeonfb (0000:01:00.0): Found 131072k of DDR 128 bits wide videoram
radeonfb (0000:01:00.0): mapped 16384k videoram
radeonfb: Retrieved PLL infos from ATOM BIOS
radeonfb: Reference=27.00 MHz (RefDiv=7) Memory=330.00 Mhz, System=358.00 MHz
radeonfb: PLL min 20000 max 50000
TMDS PLL from BIOS: 16500 b0112
index 0 port 0 conn 1 dac 0 ddc 2 tmds -1
index 1 port 0 conn 7 dac -1 ddc 2 tmds -1
index 2 port 0 conn 5 dac 1 ddc 2 tmds -1
index 3 port 1 conn 3 dac -1 ddc 1 tmds 0
Using specified monitor layout: LVDS,NONE
 * Connector 1 is Internal Panel. Head 0, Monitor: LVDS Flat panel 
   ddc port: 2, dac: -1, tmds: -1
 * Connector 2 is VGA. Head -1, Monitor: Not Probed Yet 
   ddc port: 2, dac: 0, tmds: -1
 * Connector 3 is S-Video. Head -1, Monitor: Not Probed Yet 
   ddc port: 2, dac: 1, tmds: -1
 * Connector 4 is DVI-D. Head -1, Monitor: Not Probed Yet 
   ddc port: 1, dac: -1, tmds: 0
radeonfb: detected LVDS panel size from BIOS: 1280x800
BIOS provided panel power delay: 15368
Setting up default mode based on panel info
radeonfb: Dynamic Clock Power Management enabled
hStart = 1301, hEnd = 1333, hTotal = 1408
vStart = 804, vEnd = 808, vTotal = 816
h_total_disp = 0x9f00af^I   hsync_strt_wid = 0x4050f
v_total_disp = 0x31f032f^I   vsync_strt_wid = 0x40323
pixclock = 14513
freq = 6890
freq = 6890, PLL min = 20000, PLL max = 50000
ref_div = 7, ref_clk = 2700, output_freq = 27560
ref_div = 7, ref_clk = 2700, output_freq = 27560
post div = 0x2
fb_div = 0x47
ppll_div_3 = 0x20047
Console: switching to colour frame buffer device 160x50
radeonfb (0000:01:00.0): ATI Radeon VS 
radeonfb_pci_register END 

I will keep using this for now, but if you need any more testing done I'll be
happy to help.

Thanks,
Henning
Comment 30 Solomon Peachy 2006-09-15 08:39:30 UTC
Okay, I've found the bug responsible for the "guessing panel" stuff not
resulting in a valid head setting, and that's fixed.

I still haven't figured out why we're not automatically detecting your LCD -- If
I believe the code, the LVDS register shows the panel is turned off.

So, this is what I'd like you to do.

around like 1156 in radeon_monitor.c, change this line:

                     || (INREG(LVDS_GEN_CNTL) & LVDS_ON))) {

to read:

                     || (INREG(LVDS_GEN_CNTL) & LVDS_EN))) {

rebuild, leave DDC and DEBUG on, and remove the monitor layout, and let me know
what happens.  (the latter is what Xorg uses, I think)
Comment 31 Henning Botha 2006-09-15 11:42:16 UTC
Solomon,

Exactly the same as before. Here's the log.

radeonfb_pci_register BEGIN
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 18 (level, low) -> IRQ 50
radeonfb (0000:01:00.0): Found 131072k of DDR 128 bits wide videoram
radeonfb (0000:01:00.0): mapped 16384k videoram
radeonfb: Retrieved PLL infos from ATOM BIOS
radeonfb: Reference=27.00 MHz (RefDiv=7) Memory=330.00 Mhz, System=358.00 MHz
radeonfb: PLL min 20000 max 50000
TMDS PLL from BIOS: 16500 b0112
index 0 port 0 conn 1 dac 0 ddc 2 tmds -1
index 1 port 0 conn 7 dac -1 ddc 2 tmds -1
index 2 port 0 conn 5 dac 1 ddc 2 tmds -1
index 3 port 1 conn 3 dac -1 ddc 1 tmds 0
Using specified monitor layout: LVDS,NONE
radeonfb: I2C (port 2) ... not found
 * Connector 1 is Internal Panel. Head 0, Monitor: LVDS Flat panel 
   ddc port: 2, dac: -1, tmds: -1
 * Connector 2 is VGA. Head -1, Monitor: Not Probed Yet 
   ddc port: 2, dac: 0, tmds: -1
 * Connector 3 is S-Video. Head -1, Monitor: Not Probed Yet 
   ddc port: 2, dac: 1, tmds: -1
 * Connector 4 is DVI-D. Head -1, Monitor: Not Probed Yet 
   ddc port: 1, dac: -1, tmds: 0
radeonfb: detected LVDS panel size from BIOS: 1280x800
BIOS provided panel power delay: 15368
Setting up default mode based on panel info
radeonfb: Dynamic Clock Power Management enabled
hStart = 1301, hEnd = 1333, hTotal = 1408
vStart = 804, vEnd = 808, vTotal = 816
h_total_disp = 0x9f00af^I   hsync_strt_wid = 0x4050f
v_total_disp = 0x31f032f^I   vsync_strt_wid = 0x40323
pixclock = 14513
freq = 6890
freq = 6890, PLL min = 20000, PLL max = 50000
ref_div = 7, ref_clk = 2700, output_freq = 27560
ref_div = 7, ref_clk = 2700, output_freq = 27560
post div = 0x2
fb_div = 0x47
ppll_div_3 = 0x20047
Console: switching to colour frame buffer device 160x50
radeonfb (0000:01:00.0): ATI Radeon VS 
radeonfb_pci_register END

H
Comment 32 Henning Botha 2006-09-15 14:25:01 UTC
The X11 ATI driver has the same issue (with the same "solution" -
monitorlayout). There's more here:
https://launchpad.net/distros/ubuntu/+source/xserver-xorg-video-ati/+bug/22985

There's some mention of an upstream bug, but I'm not sure if they mean Ubuntu or
the driver itself (I couldn't find anything on the freedesktop bugzilla).

H
Comment 33 Henning Botha 2006-09-15 15:12:45 UTC
Found it. https://bugs.freedesktop.org/show_bug.cgi?id=5473

H
Comment 34 Solomon Peachy 2006-09-15 15:19:24 UTC
XOrg does head detection somewhat differently though, so their bug reports
doesn't directly apply.  That said, in this case it does seem to be related.

https://bugs.freedesktop.org/show_bug.cgi?id=5473

And FWIW, that last log you posted still had a monitor layout specified; I need
to see the log without it, if you don't mind..

The current patches:

http://www.shaftnet.org/users/pizza/radeonfb-atom-2.6.18-v6a.diff
http://www.shaftnet.org/users/pizza/radeonfb-atom-2.6.17-v5c.diff

I have something else in the works, but it's a bit of a kludge that will
probably break other layouts (eg when the lid is closed)  
Comment 35 Henning Botha 2006-09-15 15:30:54 UTC
Sorry, no idea how that parameter slipped in. Here you are:

radeonfb_pci_register BEGIN
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 18 (level, low) -> IRQ 50
radeonfb (0000:01:00.0): Found 131072k of DDR 128 bits wide videoram
radeonfb (0000:01:00.0): mapped 16384k videoram
radeonfb: Retrieved PLL infos from ATOM BIOS
radeonfb: Reference=27.00 MHz (RefDiv=7) Memory=330.00 Mhz, System=358.00 MHz
radeonfb: PLL min 20000 max 50000
TMDS PLL from BIOS: 16500 b0112
index 0 port 0 conn 1 dac 0 ddc 2 tmds -1
index 1 port 0 conn 7 dac -1 ddc 2 tmds -1
index 2 port 0 conn 5 dac 1 ddc 2 tmds -1
index 3 port 1 conn 3 dac -1 ddc 1 tmds 0
Starting monitor auto detection...
radeonfb: I2C (port 2) ... not found
radeonfb: I2C (port 2) ... not found
radeonfb: I2C (port 2) ... not found
radeonfb: I2C (port 1) ... not found
 * Connector 1 is Internal Panel. Head -1, Monitor: None 
   ddc port: 2, dac: -1, tmds: -1
 * Connector 2 is VGA. Head -1, Monitor: None 
   ddc port: 2, dac: 0, tmds: -1
 * Connector 3 is S-Video. Head -1, Monitor: None 
   ddc port: 2, dac: 1, tmds: -1
 * Connector 4 is DVI-D. Head -1, Monitor: None 
   ddc port: 1, dac: -1, tmds: 0
Parsing EDID data for panel info
Guessing panel info...
radeonfb: Assuming panel size 1280x800
radeonfb: Dynamic Clock Power Management enabled
hStart = 1296, hEnd = 1512, hTotal = 1568
vStart = 1025, vEnd = 1037, vTotal = 1165
h_total_disp = 0x9f00c3	   hsync_strt_wid = 0x9b051a
v_total_disp = 0x3ff048c	   vsync_strt_wid = 0x8c0400
pixclock = 12500
freq = 8000
freq = 8000, PLL min = 20000, PLL max = 50000
ref_div = 7, ref_clk = 2700, output_freq = 32000
ref_div = 7, ref_clk = 2700, output_freq = 32000
post div = 0x2
fb_div = 0x53
ppll_div_3 = 0x20053
Console: switching to colour frame buffer device 160x64
radeonfb (0000:01:00.0): ATI Radeon VS 
radeonfb_pci_register END

H
Comment 36 Adam K 2006-09-23 05:46:38 UTC
FYI, your v6a patch works here on 2.6.18 with my AGP radeon x700 (RV410), device
ID 0x5e4b.

It immediately jumps to 1600x1200, which is fine for one of the monitors
connected to the card, but is too high for the other monitor.  Not a big deal,
but a minor inconvenience.

radeonfb_pci_register BEGIN
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 217
radeonfb (0000:01:00.0): Found 131072k of DDR 128 bits wide videoram
radeonfb (0000:01:00.0): mapped 16384k videoram
radeonfb: Found Intel x86 BIOS ROM Image
Retrieved PLL infos from ATOM BIOS
radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=432.00 Mhz, System=425.00 MHz
PLL min 20000 max 50000
TMDS PLL from BIOS: 16500 a0112
index 0 port 0 conn 1 dac 0 ddc 2 tmds -1
index 2 port 0 conn 5 dac 1 ddc 2 tmds -1
index 3 port 1 conn 2 dac -1 ddc 1 tmds 0
index 4 port 1 conn 2 dac 1 ddc 1 tmds -1
Starting monitor auto detection...
radeonfb: I2C (port 1) ... found CRT display
radeonfb: I2C (port 2) ... not found
radeonfb: I2C (port 2) ... not found
radeonfb: I2C (port 1) ... found CRT display
 * Connector 1 is DVI-I. Head 0, Monitor: CRT (EDID probed)
   ddc port: 1, dac: -1, tmds: 0
 * Connector 2 is VGA. Head -1, Monitor: None 
   ddc port: 2, dac: 0, tmds: -1
 * Connector 3 is S-Video. Head -1, Monitor: None 
   ddc port: 2, dac: 1, tmds: -1
 * Connector 4 is DVI-I. Head 1, Monitor: CRT (EDID probed)
   ddc port: 1, dac: 1, tmds: -1
hStart = 1664, hEnd = 1856, hTotal = 2160
vStart = 1201, vEnd = 1204, vTotal = 1250
h_total_disp = 0xc7010d    hsync_strt_wid = 0x18068a
v_total_disp = 0x4af04e1           vsync_strt_wid = 0x304b0
pixclock = 4357
freq = 22951
freq = 22951, PLL min = 20000, PLL max = 50000
ref_div = 12, ref_clk = 2700, output_freq = 22951
ref_div = 12, ref_clk = 2700, output_freq = 22951
post div = 0x0
fb_div = 0x66
ppll_div_3 = 0x66
Console: switching to colour frame buffer device 200x75
radeonfb (0000:01:00.0): ATI Radeon ^K 
radeonfb_pci_register END

Comment 37 Christian Hoffmann 2006-11-05 05:20:33 UTC
Hello, I applied v6a patch and now it works (somewhat). It detects 1680x1050 
which is native lcd resolution, but nothing shows up when booting, though the 
boot process works and I get the x login manager after a while. When adding 
vga=0x133 video=radeonfb:1680x1050-32@60 as a kernel parameter, I see 
something: but the screen is shifted to the right for 5 secs, then back to 
normal. Can someone point me to the correct boot params? I use a 64 bit 
system, so vbetest doesnt work/exists.

Chris
Comment 38 Christian Hoffmann 2006-11-05 05:29:45 UTC
Forget to attach output for debugging, if needed


Nov  5 13:47:16 r2d2 radeonfb_pci_register BEGIN
Nov  5 13:47:16 r2d2 ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKC] -> GSI 
10 (level, low) -> IRQ 10
Nov  5 13:47:16 r2d2 radeonfb (0000:01:00.0): Found 131072k of DDR 128 bits 
wide videoram
Nov  5 13:47:16 r2d2 radeonfb (0000:01:00.0): mapped 16384k videoram
Nov  5 13:47:16 r2d2 Retrieved PLL infos from ATOM BIOS
Nov  5 13:47:16 r2d2 radeonfb: Reference=27.00 MHz (RefDiv=7) Memory=330.00 
Mhz, System=358.00 MHz
Nov  5 13:47:16 r2d2 PLL min 20000 max 50000
Nov  5 13:47:16 r2d2 TMDS PLL from BIOS: 16500 b0112
Nov  5 13:47:16 r2d2 i2c_adapter i2c-1: adapter [monid] registered
Nov  5 13:47:16 r2d2 i2c_adapter i2c-2: adapter [dvi] registered
Nov  5 13:47:16 r2d2 i2c_adapter i2c-3: adapter [vga] registered
Nov  5 13:47:16 r2d2 i2c_adapter i2c-4: adapter [crt2] registered
Nov  5 13:47:16 r2d2 i2c_adapter i2c-2: adapter [dvi] registered
Nov  5 13:47:16 r2d2 i2c_adapter i2c-3: adapter [vga] registered
Nov  5 13:47:16 r2d2 i2c_adapter i2c-4: adapter [crt2] registered
Nov  5 13:47:16 r2d2 index 0 port 0 conn 1 dac 0 ddc 2 tmds -1
Nov  5 13:47:16 r2d2 index 1 port 5 conn 7 dac -1 ddc -1 tmds -1
Nov  5 13:47:16 r2d2 index 2 port 0 conn 5 dac 1 ddc 2 tmds -1
Nov  5 13:47:16 r2d2 index 3 port 1 conn 2 dac -1 ddc 1 tmds 0
Nov  5 13:47:16 r2d2 Starting monitor auto detection...
Nov  5 13:47:16 r2d2 radeonfb: I2C (port -1) ... found LVDS panel
Nov  5 13:47:16 r2d2 i2c_adapter i2c-3: master_xfer[0] W, addr=0x50, len=1
Nov  5 13:47:16 r2d2 i2c_adapter i2c-3: master_xfer[1] R, addr=0x50, len=128
Nov  5 13:47:16 r2d2 i2c_adapter i2c-3: master_xfer[0] W, addr=0x50, len=1
Nov  5 13:47:16 r2d2 i2c_adapter i2c-3: master_xfer[1] R, addr=0x50, len=128
Nov  5 13:47:16 r2d2 i2c_adapter i2c-3: master_xfer[0] W, addr=0x50, len=1
Nov  5 13:47:16 r2d2 i2c_adapter i2c-3: master_xfer[1] R, addr=0x50, len=128
Nov  5 13:47:16 r2d2 radeonfb: I2C (port 2) ... not found
Nov  5 13:47:16 r2d2 i2c_adapter i2c-3: master_xfer[0] W, addr=0x50, len=1
Nov  5 13:47:16 r2d2 i2c_adapter i2c-3: master_xfer[1] R, addr=0x50, len=128
Nov  5 13:47:16 r2d2 i2c_adapter i2c-3: master_xfer[0] W, addr=0x50, len=1
Nov  5 13:47:16 r2d2 i2c_adapter i2c-3: master_xfer[1] R, addr=0x50, len=128
Nov  5 13:47:16 r2d2 i2c_adapter i2c-3: master_xfer[0] W, addr=0x50, len=1
Nov  5 13:47:16 r2d2 i2c_adapter i2c-3: master_xfer[1] R, addr=0x50, len=128
Nov  5 13:47:16 r2d2 radeonfb: I2C (port 2) ... not found
Nov  5 13:47:16 r2d2 i2c_adapter i2c-2: master_xfer[0] W, addr=0x50, len=1
Nov  5 13:47:16 r2d2 i2c_adapter i2c-2: master_xfer[1] R, addr=0x50, len=128
Nov  5 13:47:16 r2d2 i2c_adapter i2c-2: master_xfer[0] W, addr=0x50, len=1
Nov  5 13:47:16 r2d2 i2c_adapter i2c-2: master_xfer[1] R, addr=0x50, len=128
Nov  5 13:47:16 r2d2 i2c_adapter i2c-2: master_xfer[0] W, addr=0x50, len=1
Nov  5 13:47:16 r2d2 i2c_adapter i2c-2: master_xfer[1] R, addr=0x50, len=128
Nov  5 13:47:16 r2d2 radeonfb: I2C (port 1) ... not found
Nov  5 13:47:16 r2d2 * Connector 1 is Internal Panel. Head 0, Monitor: LVDS 
Flat panel
Nov  5 13:47:16 r2d2 ddc port: -1, dac: -1, tmds: -1
Nov  5 13:47:16 r2d2 * Connector 2 is VGA. Head -1, Monitor: None
Nov  5 13:47:16 r2d2 ddc port: 2, dac: 0, tmds: -1
Nov  5 13:47:16 r2d2 * Connector 3 is S-Video. Head -1, Monitor: None
Nov  5 13:47:16 r2d2 ddc port: 2, dac: 1, tmds: -1
Nov  5 13:47:16 r2d2 * Connector 4 is DVI-I. Head -1, Monitor: None
Nov  5 13:47:16 r2d2 ddc port: 1, dac: -1, tmds: 0
Nov  5 13:47:16 r2d2 radeonfb: detected LVDS panel size from BIOS: 1680x1050
Nov  5 13:47:16 r2d2 BIOS provided panel power delay: 15369
Nov  5 13:47:16 r2d2 Setting up default mode based on panel info
Nov  5 13:47:16 r2d2 radeonfb: Dynamic Clock Power Management enabled
Nov  5 13:47:16 r2d2 radeonfb (0000:01:00.0): ATI Radeon VS
Nov  5 13:47:16 r2d2 radeonfb_pci_register END


Comment 39 Solomon Peachy 2006-11-05 05:35:51 UTC
I see you have a X700 too.

Can you build it with CONFIG_RADEON_DEBUG on, and post the kernel log you get? 
IS the log you posted the "default" one?  Does 'video=radeonfb:1680x1050-8@60'
work?  (Leave out the vga=...) what about a lower resolution, say, 1024x768?

(my patch seems to have fallen through the cracks again.. time to poke the fbdev
list..)
Comment 40 Solomon Peachy 2006-11-05 05:42:16 UTC
Created attachment 9408 [details]
Radeon ATOM patch v6a (vs 2.6.18.x) plus PCI IDs

This patch also contains PCI IDs for all known X300, X600, X700, X800, and X850
cards.	

This patch is actually dated 9/19/2006, but I apparently forgot to attach it to
the bug ticket.
Comment 41 Christian Hoffmann 2006-11-05 07:25:41 UTC
Created attachment 9409 [details]
dmesg output

dmesg output for x700
Comment 42 Christian Hoffmann 2006-11-05 07:28:16 UTC
I changed to radeonfb=1024x768 and removed vga=xxx, but I dont get framebuffer 
console at all now. Seems to be plain text console. Any ideas?
dmesg output attached (see previous post)
Chris
Comment 43 Chí-Thanh Christopher Nguyễn 2006-11-05 17:22:08 UTC
The dmesg output from attachment 9409 [details] does not include the kernel command line,
so I'm just guessing that you wrote 'radeonfb=1024x768' instead of
'video=radeonfb:1024x768'.

If fbcon was compiled as a module, is it loaded?
Comment 44 Christian Hoffmann 2006-11-06 00:42:07 UTC
OK. Thanks, fbcon was compiled as module, but not loaded automatically. I 
compiled it into the kernel and now it works. 

Thank you!
Comment 45 Christian Hoffmann 2006-11-07 12:31:44 UTC
Hello,

now it works but the machine never comes back after a suspend to ram :( But 
thats a different issue I guess ?
Comment 46 Solomon Peachy 2006-11-08 21:09:45 UTC
Created attachment 9436 [details]
radeonfb ATOM patch v6a, rebased to 2.6.19-rc5

This is identical to the 2.6.18.x-v6a patch, except it's been rebased vs
2.6.19-rc5.  It should be appearing in the -mm tree shortly, but I'm attaching
it here as well.

Feedback and flames welcome.
Comment 47 Chí-Thanh Christopher Nguyễn 2006-11-24 12:52:10 UTC
2.6.19-rc6-mm1 has been released, but apparently without the radeonfb patch.

Interestingly, the patch against 2.6.18.x produces different output from the
2.6.19-rc5 patch in attachment 9436 [details].

dmesg diff:

*** dmesg.2.6.18        Fri Nov 24 21:41:00 2006
--- dmesg.2.6.19-rc5    Fri Nov 24 21:41:32 2006
***************
*** 11,17 ****
--- 11,23 ----
  index 3 port 1 conn 3 dac -1 ddc 1 tmds 0
  Starting monitor auto detection...
  radeonfb: I2C (port 0) ... found LVDS panel
+ i2c_adapter i2c-3: unable to read EDID block.
+ i2c_adapter i2c-3: unable to read EDID block.
+ i2c_adapter i2c-3: unable to read EDID block.
  radeonfb: I2C (port 2) ... not found
+ i2c_adapter i2c-3: unable to read EDID block.
+ i2c_adapter i2c-3: unable to read EDID block.
+ i2c_adapter i2c-3: unable to read EDID block.
  radeonfb: I2C (port 2) ... not found
  radeonfb: I2C (port 1) ... not found
   * Connector 1 is Internal Panel. Head 0, Monitor: LVDS Flat panel (EDID probed)
Comment 48 Jory A. Pratt 2006-12-18 11:15:53 UTC
I just found this bug ... figured I would test the latest patch against 2.6.19.1
I have one small problem that I am not sure of tho.

<code>
	OUTREG(reg, INREG(reg) &
			~(VGA_DDC_DATA_OUTPUT | VGA_DDC_CLK_OUTPUT));
</code>

Is it safe to remove this as it is only part left not in the original diff?
Comment 49 Benjamin Herrenschmidt 2006-12-18 12:04:35 UTC
I don't know what you mean by "Is it safe to remove this as it is only part left
not in the original diff?" ... it appears to be necessary to clear the DDC lines
or DDC will not work properly on some cards.
Comment 50 Jory A. Pratt 2007-01-03 07:38:04 UTC
http://rafb.net/p/MjtxNT61.nln.html    http://rafb.net/p/Q7ZafR60.nln.html

One is current state after patching >2.6.19-rc5 
Other is failed portion of patch.

Comment 51 Chí-Thanh Christopher Nguyễn 2007-03-06 08:06:58 UTC
On the kernel mailing list it was mentioned that the current driver can be made
to work with a Radeon XPRESS 200M IGP.

http://thread.gmane.org/gmane.linux.kernel/500703

Is there something that is keeping the radeonfb patch out of the -mm tree?
Comment 52 Jory A. Pratt 2007-04-07 21:29:44 UTC
Created attachment 11097 [details]
simple patch that addes the ids to radeonfb

Well it appears this bug will never be fixed. As so much has changed over the
last test patch that has never seen its way to mm here is a temporary patch
that will at least give you a working radeonfb.
Comment 53 Antonino Daplas 2007-04-28 17:13:17 UTC
What's the status of this report? 
Comment 54 Chí-Thanh Christopher Nguyễn 2007-04-28 17:55:47 UTC
There was a newer patch posted to the linux-fbdev-devel mailing list
http://thread.gmane.org/gmane.linux.fbdev.devel/9830/focus=9879

However, there are some major fb/drm changes (gpu layer) looming. Not sure which
one will get merged first.
http://thread.gmane.org/gmane.linux.kernel/485814/focus=487874
Comment 55 Antonino Daplas 2007-04-28 18:19:45 UTC
> There was a newer patch posted to the linux-fbdev-devel mailing list
> http://thread.gmane.org/gmane.linux.fbdev.devel/9830/focus=9879

Ah, okay, I've seen this.  BenH, any problems with this patch?  How about
sending it to the -mm tree as is and let it simmer there?  You'll get a wider
testing audience too. 

> However, there are some major fb/drm changes (gpu layer) looming. Not sure which
> one will get merged first.
> http://thread.gmane.org/gmane.linux.kernel/485814/focus=487874

Oh, that, that's an infrastructure change, an attempt to merge fb and drm.  I
doubt that will get to mainline soon, and there are multiple projects that are
related to that (ie modesetting-101 branch of drm).
Comment 56 Benjamin Herrenschmidt 2007-04-28 18:27:28 UTC
Last I went through it, I spotted a few things and it needs serious testing on
powermacs that I had no time to do. I started reworking the whole thing but
never finished... it's getting really tough finding time to work on radeonfb lately.
Comment 57 Jory A. Pratt 2007-05-13 16:06:55 UTC
This is resolved in latest git :) which means 2.6.22 will support xpress 200M
with radeonfb out the gate !!!!!

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=dd1447134454b169d5ae353aceb93f2368db8547
Comment 58 Natalie Protasevich 2007-07-04 10:48:30 UTC
Any status on testing with latest kernel? 
Thanks.
Comment 59 Jory A. Pratt 2007-07-04 10:57:25 UTC
(In reply to comment #58)
> Any status on testing with latest kernel? 
> Thanks.
> 

This bug should be closed the fb is fine now with radeonfb in 2.6.22. The problem is fixed and works well IMO and I been using every single 2.6.22_rcX all the way up to rc7 which is the latest.

Note You need to log in before you can comment on or make changes to this bug.