Signed-off-by: Solomon Peachy <redacted>
Newer Radeon graphics cards use a different table layout in their
BIOSes, known as 'ATOM'.
I've attached a patch (against 2.6.15) which implements the PLL and LVDS
parsing out of the ATOM BIOSes, using the current X.org sources as a
reference. Notably absent is the code which detects the connectors and
TDMS information, but it's of lesser importance at the moment.
This code still has quirks, but I'm not sure if those are due to bugs in
my patch or incomplete/buggy support for the RV410. So I'd appreciate
it if people could try this out, especially if they have a newer ATOM
BIOS in their radeon card, and let me know what happens.
Finally, this patch also has PCI IDs added for my Radeon Mobility X700
(M26) adapter.
Below is the dump of my system with this driver:
radeonfb_pci_register BEGIN
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 18 (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
ATOM BIOS detected
radeonfb: Retreived PLL infos from BIOS
radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=330.00 Mhz, System=358.00 MHz
radeonfb: PLL min 20000 max 50000
XXXX Write ATOM BIOS connector parse
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
radeonfb: I2C (port 2) ... not found
radeonfb: I2C (port 4) ... not found
Non-DDC laptop panel detected
radeonfb: I2C (port 3) ... not found
radeonfb: I2C (port 4) ... not found
radeonfb: Monitor 1 type LCD found
radeonfb: Monitor 2 type CRT found
radeonfb: detected LVDS panel size from BIOS: 1680x1050
BIOS provided panel power delay: 15369
Setting up default mode based on panel info
radeonfb: Dynamic Clock Power Management enabled
hStart = 1728, hEnd = 1760, hTotal = 1840
vStart = 1053, vEnd = 1059, vTotal = 1080
h_total_disp = 0xd100e5 hsync_strt_wid = 0x406ba
v_total_disp = 0x4190437 vsync_strt_wid = 0x6041c
pixclock = 8387
freq = 11923
freq = 11923, PLL min = 20000, PLL max = 50000
ref_div = 12, ref_clk = 2700, output_freq = 23846
ref_div = 12, ref_clk = 2700, output_freq = 23846
post div = 0x1
fb_div = 0x6a
ppll_div_3 = 0x1006a
Console: switching to colour frame buffer device 210x65
radeonfb (0000:01:00.0): ATI Radeon VS
radeonfb_pci_register END
And at this point, I have yummy hires fbdev goodness.
I also have a question about the panel_info.pwr_delay field --- Is this
is supposed to be the time we wait for the LCD to settle after a power
state change? X.org seems to use 200ms everywhere, but the default in
radeonfb seems to be 2000ms, and my panel is reporting a whopping
15369ms. I'm also forced to use the default pll.ref_div of 12, and I've
tweaked the code to make that default universal if the BIOS information
is clearly bogus.
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.
From: Petr Vandrovec <hidden> Date: 2006-01-03 23:29:38
Stuffed Crust wrote:
Signed-off-by: Solomon Peachy <redacted>
Newer Radeon graphics cards use a different table layout in their
BIOSes, known as 'ATOM'.
I've attached a patch (against 2.6.15) which implements the PLL and LVDS
parsing out of the ATOM BIOSes, using the current X.org sources as a
reference. Notably absent is the code which detects the connectors and
TDMS information, but it's of lesser importance at the moment.
This code still has quirks, but I'm not sure if those are due to bugs in
my patch or incomplete/buggy support for the RV410. So I'd appreciate
it if people could try this out, especially if they have a newer ATOM
BIOS in their radeon card, and let me know what happens.
Thanks. It correctly detects panel size from BIOS, unfortunately it behaves
like X.org driver (which is probably expected). I captured video just in case
it provides some clue to somebody
(http://platan.vc.cvut.cz/ftp/private/radeon/video.avi). Otherwise I'll try
some trial & error session during weekend.
Jan 3 23:58:02 debian kernel: radeonfb_pci_register BEGIN
Jan 3 23:58:02 debian kernel: ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 18
(level, low) -> IRQ 209
Jan 3 23:58:02 debian kernel: radeonfb (0000:01:00.0): Found 131072k of DDR 128
bits wide videoram
Jan 3 23:58:02 debian kernel: radeonfb (0000:01:00.0): mapped 16384k videoram
Jan 3 23:58:02 debian kernel: ATOM BIOS detected
Jan 3 23:58:02 debian kernel: radeonfb: Retreived PLL infos from BIOS
Jan 3 23:58:02 debian kernel: radeonfb: Reference=27.00 MHz (RefDiv=14)
Memory=280.00 Mhz, System=358.00 MHz
Jan 3 23:58:02 debian kernel: radeonfb: PLL min 20000 max 50000
Jan 3 23:58:02 debian kernel: XXXX Write ATOM BIOS connector parse
Jan 3 23:58:02 debian kernel: Starting monitor auto detection...
Jan 3 23:58:02 debian kernel: radeonfb: I2C (port 1) ... not found
Jan 3 23:58:02 debian kernel: radeonfb: I2C (port 2) ... not found
Jan 3 23:58:02 debian kernel: radeonfb: I2C (port 3) ... not found
Jan 3 23:58:02 debian kernel: radeonfb: I2C (port 4) ... not found
Jan 3 23:58:02 debian kernel: radeonfb: I2C (port 2) ... not found
Jan 3 23:58:02 debian kernel: radeonfb: I2C (port 4) ... not found
Jan 3 23:58:02 debian kernel: Non-DDC laptop panel detected
Jan 3 23:58:02 debian kernel: radeonfb: I2C (port 3) ... not found
Jan 3 23:58:02 debian kernel: radeonfb: I2C (port 4) ... not found
Jan 3 23:58:02 debian kernel: radeonfb: Monitor 1 type LCD found
Jan 3 23:58:02 debian kernel: radeonfb: Monitor 2 type CRT found
Jan 3 23:58:02 debian kernel: radeonfb: detected LVDS panel size from BIOS:
1920x1200
Jan 3 23:58:02 debian kernel: BIOS provided panel power delay: 15369
Jan 3 23:58:02 debian kernel: Setting up default mode based on panel info
Jan 3 23:58:02 debian kernel: radeonfb: Dynamic Clock Power Management enabled
Jan 3 23:58:02 debian kernel: hStart = 2020, hEnd = 2052, hTotal = 2184
Jan 3 23:58:02 debian kernel: vStart = 1202, vEnd = 1208, vTotal = 1235
Jan 3 23:58:02 debian kernel: h_total_disp = 0xef0110^I hsync_strt_wid = 0x407de
Jan 3 23:58:02 debian kernel: v_total_disp = 0x4af04d2^I vsync_strt_wid = 0x604b1
Jan 3 23:58:02 debian kernel: pixclock = 6589
Jan 3 23:58:02 debian kernel: freq = 15176
Jan 3 23:58:02 debian kernel: freq = 15176, PLL min = 20000, PLL max = 50000
Jan 3 23:58:02 debian kernel: ref_div = 14, ref_clk = 2700, output_freq = 30352
Jan 3 23:58:02 debian kernel: ref_div = 14, ref_clk = 2700, output_freq = 30352
Jan 3 23:58:02 debian kernel: post div = 0x1
Jan 3 23:58:02 debian kernel: fb_div = 0x9d
Jan 3 23:58:02 debian kernel: ppll_div_3 = 0x1009d
Jan 3 23:58:02 debian kernel: Console: switching to colour frame buffer device
240x75
Jan 3 23:58:02 debian kernel: radeonfb (0000:01:00.0): ATI Radeon VS
Jan 3 23:58:02 debian kernel: radeonfb_pci_register END
Thanks,
Petr
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2006-01-05 09:58:20
On Tue, 2006-01-03 at 15:44 -0500, Stuffed Crust wrote:
Signed-off-by: Solomon Peachy <redacted>
Newer Radeon graphics cards use a different table layout in their
BIOSes, known as 'ATOM'.
I've attached a patch (against 2.6.15) which implements the PLL and LVDS
parsing out of the ATOM BIOSes, using the current X.org sources as a
reference. Notably absent is the code which detects the connectors and
TDMS information, but it's of lesser importance at the moment.
Inresting. I started doing that (and updated the pre-ATOM BIOS code too)
but never finished... One thing you could do that would be useful is
move the various BIOS code to separate function and setup function
pointers that can be set based on the BIOS type instead of the endless
stream if (atom_bios) xxx else yyy. That way, it will be cleaner and
I'll be able to more easily add other variations like retreiving infos
from Open Firmware on ppc etc...
Ben.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
On Thu, Jan 05, 2006 at 08:59:15PM +1100, Benjamin Herrenschmidt wrote:
Inresting. I started doing that (and updated the pre-ATOM BIOS code too)
but never finished... One thing you could do that would be useful is
move the various BIOS code to separate function and setup function
pointers that can be set based on the BIOS type instead of the endless
stream if (atom_bios) xxx else yyy. That way, it will be cleaner and
I'll be able to more easily add other variations like retreiving infos
from Open Firmware on ppc etc...
Will do. I'll probably get to it during the weekend.
Off the top of my head there's LVDS info, PLL, Connector, and TMDS
detection/mangling to be split out; anything else?
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2006-02-14 21:28:58
On Tue, 2006-01-03 at 15:44 -0500, Stuffed Crust wrote:
Signed-off-by: Solomon Peachy <redacted>
Newer Radeon graphics cards use a different table layout in their
BIOSes, known as 'ATOM'.
I've attached a patch (against 2.6.15) which implements the PLL and LVDS
parsing out of the ATOM BIOSes, using the current X.org sources as a
reference. Notably absent is the code which detects the connectors and
TDMS information, but it's of lesser importance at the moment.
This code still has quirks, but I'm not sure if those are due to bugs in
my patch or incomplete/buggy support for the RV410. So I'd appreciate
it if people could try this out, especially if they have a newer ATOM
BIOS in their radeon card, and let me know what happens.
Finally, this patch also has PCI IDs added for my Radeon Mobility X700
(M26) adapter.
Hi !
What's the status of this patch ? Do you have a new version ? People are
heving enough problems with recent cards to justify getting something in
soon...
Thanks,
Ben.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
On Wed, Feb 15, 2006 at 08:28:49AM +1100, Benjamin Herrenschmidt wrote:
What's the status of this patch ? Do you have a new version ? People are
heving enough problems with recent cards to justify getting something in
soon...
Sorry about the delay, but as you mentioned earlier, you know how those
higher-priority things are.
I've attached my current WIP. It has no additional functionality over
the original patch, but it's rearranged to be quite a bit cleaner, using
function pointers for the atom/legacy bits.
I haven't tested this particular patch out, but it does compile.
The reversed DAC/TDMS detection and connector parsing stuff is still
unwritten for ATOM BIOSes. I plan on digging into the X.Org sources
later tonight.
Of course other stuff like OpenFirmware could be integrated better, but
I'd rather leave that for people who can test things.
Let me know what you think. It's against 2.6.15, FWIW.
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.
On Wed, Feb 22, 2006 at 05:19:16PM -0500, Stuffed Crust wrote:
On Wed, Feb 15, 2006 at 08:28:49AM +1100, Benjamin Herrenschmidt wrote:
quoted
What's the status of this patch ? Do you have a new version ? People are
heving enough problems with recent cards to justify getting something in
soon...
Sorry about the delay, but as you mentioned earlier, you know how those
higher-priority things are.
I've attached my current WIP. It has no additional functionality over
the original patch, but it's rearranged to be quite a bit cleaner, using
function pointers for the atom/legacy bits.
I haven't tested this particular patch out, but it does compile.
The reversed DAC/TDMS detection and connector parsing stuff is still
unwritten for ATOM BIOSes. I plan on digging into the X.Org sources
later tonight.
And to follow up to myself, here is a third patch. I've started
incorporating bits and pieces from the "oooold" non-working rewrite
that you sent me for inspiration. Changes from last patch:
* Naming cleanups
* Merge the OpenFirmware PLL detection into the function pointer mess.
* Merge the oooold patch's legacy bios connector parsing code, As the
original stuff didn't really do anything anyway, I don't see the harm.
* Merge the ooold patch's atom bios connector parsing code, but it still
doesn't work yet. It's late and my eyes hurt.
The good news is that I'm typing this using this patch on my Radeon
M26 (mmm.. 1680x1050!), but the bad news is that I don't know if the
legacy BIOS code works, especially the connector parsing stuff.
Let me know if I'm going down the right path. The RadeonFB driver is
pretty complicated, so I'm trying to take baby steps as I figure more
of it out.
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2006-02-23 06:51:06
And to follow up to myself, here is a third patch. I've started
incorporating bits and pieces from the "oooold" non-working rewrite
that you sent me for inspiration. Changes from last patch:
* Naming cleanups
* Merge the OpenFirmware PLL detection into the function pointer mess.
* Merge the oooold patch's legacy bios connector parsing code, As the
original stuff didn't really do anything anyway, I don't see the harm.
* Merge the ooold patch's atom bios connector parsing code, but it still
doesn't work yet. It's late and my eyes hurt.
The good news is that I'm typing this using this patch on my Radeon
M26 (mmm.. 1680x1050!), but the bad news is that I don't know if the
legacy BIOS code works, especially the connector parsing stuff.
Let me know if I'm going down the right path. The RadeonFB driver is
pretty complicated, so I'm trying to take baby steps as I figure more
of it out.
From your comments, you sound on the right track. I haven't had time to
review the patches yet but I'll do asap, I'm very happy somebody is
tackling those issues :)
Ben.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
On Thu, Feb 23, 2006 at 05:50:58PM +1100, Benjamin Herrenschmidt wrote:
quoted
From your comments, you sound on the right track. I haven't had time to
review the patches yet but I'll do asap, I'm very happy somebody is
tackling those issues :)
Fourth pass. This patch supercedes the previous, and adds:
* ATOM BIOS support for connector detection
* TMDS parsing for both ATOM and Legacy BIOSes.
* Additional PCI IDs forall known M26 variants
* Default PLL clocks for R420 family
I've tested this patch out on my laptop's ATOM X700/M26/RV410, and on a
dualhead Legacy 7500/RV200 add-in card. All heads, tables, etc were
detected properly.
It doesn't do anything with this new connector data other than
to report it. Integrating this stuff with the existing monitor detection
logic comes next, using the rinfo->connectors table instead of the
rinfo->mon[12]_type stuff. (at the very least, we shouldn't look for
something plugged into a non-existant head...)
And of course, OpenFirmware integration, and doing something with the
TMDS PLL information.
I'm unsure how to best to proceed from here, so this patch is it until
I get some more directed feedback.
Signed-Off-By: Solomon Peachy <redacted>
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2006-02-23 23:15:27
And of course, OpenFirmware integration, and doing something with the
TMDS PLL information.
Yeah. Also, I need to create some kind of table of known OpenFirmware
cards and their associated connector maping since unfortunately, the
firmware driver doesn't provide the information... But I'll do that
afterward.
I'm unsure how to best to proceed from here, so this patch is it until
I get some more directed feedback.
I'll review properly next week.
Ben.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2006-03-01 03:46:35
I basically have two chunks of remaining code to write:
1) The OpenFirmware stuff, which basically requires some re-jiggering of
arguments passed in and return codes.
Or just write a small howto and I will do the job :) I've been very busy
lately mostly due to my newborn child, thus I didn't help more than
that, but I'm really interested in your work. I also want to bring along
a bunch of fixes like the memory mapping fixes I've been doing on X.org
radeon driver recently.
2) User-specified layout code isn't smart enough to try the secondary
connectors if the primary connectors don't have anything connected.
(This could be lessened by extending the syntax to explicitly state
CRT,CRT2,DFP,DFP2,etc..)
Agreed. (And X too btw ...)
In fact, we need a way to provide the driver with the full connector
mapping I think, in case it can't be obtained from the firmware.
Then there's the big open question of how we should allow the user
to override the connector table, in case we mis-detect or don't have a
table to begin with. If we have DDC enabled we can build a
connector table by probing all DDC ports, using the existing logic.
module option is the easy/cheap way but sucks in some ways... sysfs per
device instance is nice but a bit "too late" unless we have a way for
the driver to re-probe... which is a good thing to have anyway since we
might finally deal with screen hotplug :)
In fact, a mix of both might do the trick... module/kernel argument for
a default override and sysfs for "live" override ?
I would however not bother too much at the moment with that. Let's get
the rest working first
Thoughts?
(This work builds on the radeon-atom-4 patch, and is definately in the
"heavily experimental" stage. I'll post a patch once I have time to
clean it up and fix the first two points)
Thanks.
I'll look at your stuff in more detail asap and will then let it simmer
in -mm if I'm happy enough for at least a kernel version...
Ben.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
On Fri, Feb 24, 2006 at 10:15:21AM +1100, Benjamin Herrenschmidt wrote:
quoted
I'm unsure how to best to proceed from here, so this patch is it until
I get some more directed feedback.
I'll review properly next week.
I've since completely gutted the radeon_probe_screens code, and now it
takes advantage of (and relies heavily on) the connector table stuffs.
It's far, far cleaner now, yay!
I basically have two chunks of remaining code to write:
1) The OpenFirmware stuff, which basically requires some re-jiggering of
arguments passed in and return codes.
2) User-specified layout code isn't smart enough to try the secondary
connectors if the primary connectors don't have anything connected.
(This could be lessened by extending the syntax to explicitly state
CRT,CRT2,DFP,DFP2,etc..)
Then there's the big open question of how we should allow the user
to override the connector table, in case we mis-detect or don't have a
table to begin with. If we have DDC enabled we can build a
connector table by probing all DDC ports, using the existing logic.
Thoughts?
(This work builds on the radeon-atom-4 patch, and is definately in the
"heavily experimental" stage. I'll post a patch once I have time to
clean it up and fix the first two points)
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.
On Wed, Mar 01, 2006 at 02:46:29PM +1100, Benjamin Herrenschmidt wrote:
In fact, a mix of both might do the trick... module/kernel argument for
a default override and sysfs for "live" override ?
Nowadays you can use sysfs to both display and modify module parameters,
so making use of that would be the best.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
On Wed, Mar 01, 2006 at 02:46:29PM +1100, Benjamin Herrenschmidt wrote:
Or just write a small howto and I will do the job :) I've been very busy
lately mostly due to my newborn child, thus I didn't help more than
Congratulations (and my condolances :P) on the kid!
that, but I'm really interested in your work. I also want to bring along
a bunch of fixes like the memory mapping fixes I've been doing on X.org
radeon driver recently.
I often get lockups in a radeonfb console, could that be related
to the mmap stuff you've been fixing?
In fact, we need a way to provide the driver with the full connector
mapping I think, in case it can't be obtained from the firmware.
I have a crude "bootstrap the connector table via ddc probing" but it
has problems with secondary heads as well, and obviously without ddc it
won't work anyway. Either the user provices a connector table or we
pray the defaults, one way or another, are sane. :)
Of course, once a non-detectable layout is known, we can add it into an
appropriate driver table.
module option is the easy/cheap way but sucks in some ways... sysfs per
device instance is nice but a bit "too late" unless we have a way for
the driver to re-probe... which is a good thing to have anyway since we
might finally deal with screen hotplug :)
MM, that would be nice.. but I don't want to think about the console
interactions required for display reconfiguration. That said, the new
code is capable of re-detecting at any time, but I'm sure the radeonfb
core has issues.
I'll look at your stuff in more detail asap and will then let it simmer
in -mm if I'm happy enough for at least a kernel version...
I'm about to mail out v5 of the patch.
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.
On Wed, Mar 01, 2006 at 03:36:11PM -0500, Stuffed Crust wrote:
I'm about to mail out v5 of the patch.
Signed-Off-By: Solomon Peachy <redacted>
The short set of changes in this patch (against 2.6.15.4)
* 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 can split it apart into smaller logical chunks if desired, but I don't
think anyone's in a hurry to merge this upstream just yet. :) So,
anyone who has a radeon console and is feeling brave, please give this a
whirl. If you are specifying a monitor layout, try it without the
layout string.
This is the last of the work I can do on this thing, as I don't have the
hardware (or bug reports/feedback) to develop it further.
Version 5 of the Radeon-Atom patch is attached. Changes since v4:
* Completely reworks the old monitor detection code to use the
connector table. Cleaned out a ton of cruft.
* Connector info and LVDS info are pulled on OpenFirmware systems,
(untested -- I don't have appropriate hardware)
* Add a module argument to disable BIOS connector tables.
* Bootstraping the connector table via ddc probing.
* If user specifies a specific layout, code isn't smart enough to try
secondary heads if the primary head has nothing attached. The
OpenFirmware code may have similar problems.
4th version changes since v3:
* ATOM BIOS support for connector detection
* TMDS parsing for both ATOM and Legacy BIOSes.
* Additional PCI IDs forall known M26 variants
* Default PLL clocks for R420 family
3rd version changes since v2:
* Naming cleanups
* Merge the OpenFirmware PLL detection into the function pointer mess.
* Merge the oooold patch's legacy bios connector parsing code, As the
original stuff didn't really do anything anyway, I don't see the harm.
* Merge the ooold patch's atom bios connector parsing code, but it still
doesn't work yet. It's late and my eyes hurt.
2nd version changes since v1:
* It has no additional functionality over the original patch, but it's
rearranged to be quite a bit cleaner, using function pointers for the
atom/legacy bits.
Original Patch:
* Added PCI IDs for Radeon M26 (aka Mobility X700)
* Detect ATOM BIOSes, pull PLL/LVDS details from ATOM BIOSes
* Default PLL divider to 12, and catch obviously bogus results
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2006-03-01 21:47:14
On Wed, 2006-03-01 at 16:34 -0500, Stuffed Crust wrote:
On Wed, Mar 01, 2006 at 03:36:11PM -0500, Stuffed Crust wrote:
quoted
I'm about to mail out v5 of the patch.
Signed-Off-By: Solomon Peachy <redacted>
The short set of changes in this patch (against 2.6.15.4)
* 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
Ok, good. I need some time to review properly. There are a few things I
want to change, for example, some of the OF stuff should be decided at
runtime, not compile time (what set of callbacks to use) since some OF
machines do use x86 cards, etc... but I can fix all of these things.
Thanks for the great work.
Ben.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642