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
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 ?
It works with Xorg (Version xserver-xorg 6.9.0.dfsg.1-4) using the "radeon" driver.
Created attachment 7562 [details] Xorg log for that card
2.6.16-rc6-mm2 and still no radeonfb :)
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.
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.
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
Created attachment 8332 [details] this is the xorg.log with the same graphics card. radeon driver works OK
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.
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.
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.
i would test it but I have 2.6.17, could you please post the reworked patch as well? Thanks Chris
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?
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.
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
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
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)
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.
Created attachment 8959 [details] dmesg output with CONFIG_FB_RADEON_I2C=n
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.
Created attachment 8961 [details] ATOM BIOS patch v5a, against 2.6.18-rc6 v5a of the patch, rediffed against 2.6.18-rc6.
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
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)
Created attachment 8964 [details] RADEON ATOM patch v5b (2.6.18-rc6) v5b of the ATOM fix, against 2.6.18-rc6
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
Created attachment 8966 [details] dmesg output after applying patch v5b
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
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.
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
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)
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
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
Found it. https://bugs.freedesktop.org/show_bug.cgi?id=5473 H
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)
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
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
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
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
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..)
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.
Created attachment 9409 [details] dmesg output dmesg output for x700
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
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?
OK. Thanks, fbcon was compiled as module, but not loaded automatically. I compiled it into the kernel and now it works. Thank you!
Hello, now it works but the machine never comes back after a suspend to ram :( But thats a different issue I guess ?
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.
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)
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?
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.
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.
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?
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.
What's the status of this report?
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
> 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).
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.
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
Any status on testing with latest kernel? Thanks.
(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.