From: Jon Smirl <hidden> Date: 2003-08-14 03:43:45
Hopefully these is the last versions. They implement:
1) add every know PCI ID
2) access ROM directly instead of relying on copy in
low RAM. This allows multiple cards. Required
MPP_TB_CONFIG fix in driver.
3) implemented kernel 2.6 module parameters
4) Cleaned up error paths and made sure resources are
released on errors. Both build without compiler
warnings now. You can ins/rm mod multiple times
without problem. Just don't do it from a window in
your X server.
5) Driver marks both primary and secondary devices as
being in use.
These drivers are bigger than the old ones but that's
because I added descriptions for the parameters and a
bunch more error messages. Code is probably smaller.
Strip the strings and remove unneeded entries from the
device table for embedded systems.
I don't own Apple hardware. Anyone want to make sure I
didn't break Powerbooks?
It would be nice if someone with Radeon documentation
verified my chip IDs and family classifications. It is
important that secondary devices are marked correctly
in the driver. I did the best I could from Xfree
source and PCI databases.
Patches are against the current 2.6 kernel tree.
Anyone want to volunteer to get these into the kernel?
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-08-14 10:42:07
On Thu, 2003-08-14 at 05:43, Jon Smirl wrote:
Hopefully these is the last versions. They implement:
Please CC me any further radeonfb patches, I have my own stuff
pending that I need to sync (and I sort of took over maintainership)
1) add every know PCI ID
2) access ROM directly instead of relying on copy in
low RAM. This allows multiple cards. Required
MPP_TB_CONFIG fix in driver.
This is a problem. We also parse it to find the DFP EDID and/or
flat panel informations, do that work with the real ROM ? I don't
know much about x86 BIOSes, but at least for the DFP EDID, I suppose
that one is read in RAM by the BIOS, not in the ROM...
3) implemented kernel 2.6 module parameters
4) Cleaned up error paths and made sure resources are
released on errors. Both build without compiler
warnings now. You can ins/rm mod multiple times
without problem. Just don't do it from a window in
your X server.
5) Driver marks both primary and secondary devices as
being in use.
These drivers are bigger than the old ones but that's
because I added descriptions for the parameters and a
bunch more error messages. Code is probably smaller.
Strip the strings and remove unneeded entries from the
device table for embedded systems.
I don't own Apple hardware. Anyone want to make sure I
didn't break Powerbooks?
You may want to look at the version I have in my tree
on ppc.bkbits.net/linuxppc-2.5-benh. I don't have much time
to sync with your before a couple of weeks for now... This version
rely on my Power Management stuffs I posted earlier that James didn't
seem to merge yet though.
It would be nice if someone with Radeon documentation
verified my chip IDs and family classifications. It is
important that secondary devices are marked correctly
in the driver. I did the best I could from Xfree
source and PCI databases.
The ChipIDs aren't in the documentation. I suppose the best source
here is the XFree driver.
Patches are against the current 2.6 kernel tree.
Anyone want to volunteer to get these into the kernel?
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
--
Benjamin Herrenschmidt [off-list ref]
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
From: Alex Deucher <hidden> Date: 2003-08-14 13:22:40
--- Jon Smirl <jonsmirl@yahoo.com> wrote:
Hopefully these is the last versions. They implement:
1) add every know PCI ID
2) access ROM directly instead of relying on copy in
low RAM. This allows multiple cards. Required
MPP_TB_CONFIG fix in driver.
Is this patch necessary for xfree86? It may address some of the issues
in the email threads I sent out yesterday (ie, problems with multiple
radeon cards and xfree86). if so would you consider making one?
Alex
3) implemented kernel 2.6 module parameters
4) Cleaned up error paths and made sure resources are
released on errors. Both build without compiler
warnings now. You can ins/rm mod multiple times
without problem. Just don't do it from a window in
your X server.
5) Driver marks both primary and secondary devices as
being in use.
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
From: Jon Smirl <hidden> Date: 2003-08-14 16:00:54
--- Benjamin Herrenschmidt <benh@kernel.crashing.org>
wrote:
This is a problem. We also parse it to find the DFP
EDID and/or flat panel informations, do that work
with the real ROM ? I don't know much about x86
BIOSes, but at least for the DFP EDID, I suppose
that one is read in RAM by the BIOS, not in the
ROM...
On x86 machines low RAM contains a copy of the ROM,
now you are getting a pointer to the real ROM. The
contents are identical. The only difference is that
you need to use the readb()/readw()/etc macros to read
it. On the x86 readb() does nothing, but on other
platforms it will trigger a PCI read cycle. This plus
side to this is that you can use multiple video cards.
The ROM stuff is only enabled on the X86 platform. It
was IFDEF'd that way before I made my changes. I did
not change the way it was previously IFDEF'd for other
platforms. You may want to try enabling the ROM on
the Apple platforms. It will probably work, if it does
change the IFDEFs. The old technique of relying on the
copy in low memory does not work on Apples since their
BIOS doesn't make the copy, that's why it was IFDEF'd
off.
You may want to look at the version I have in my
tree on ppc.bkbits.net/linuxppc-2.5-benh. I don't
have
much time to sync with your before a couple of weeks
for now... This version rely on my Power Management
stuffs I posted earlier that James didn't seem to
merge
yet though.
I looked through the diff for this. The only potential
conflict is where I cleaned up some error paths.
Please keep my changes as the old code was not freeing
resources where it should have. You may want to
experiment with enabling the ROM on the Mac.
My code does not change the behavior of the driver
other than by adding PCI IDs and the way the ROM is
accessed on the X86. It would be nice if you could
check out my code and at least make sure it compiles
and loads on a Powerbook.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
From: Jon Smirl <hidden> Date: 2003-08-14 17:13:11
--- Alex Deucher <agd5f@yahoo.com> wrote:
quoted
2) access ROM directly instead of relying on copy
in low RAM. This allows multiple cards. Required
MPP_TB_CONFIG fix in driver.
Is this patch necessary for xfree86? It may address
some of the issues
in the email threads I sent out yesterday (ie,
problems with multiple
radeon cards and xfree86). if so would you consider
making one?
Xfree code does not have the patch, but is Xfree
experiencing the bug? Xfree accesses the hardware very
differently than the framebuffer drivers.
I suspect that you would see this problem if you were
using something else for your primary video and a
Radeon for secondary. The first time you ran Xfree it
would work. But when you exited and restarted Xfree it
would hang when starting the secondary display.
Where does XFree reset the secondary card? The code
below needs to run right after the reset in the radeon
driver. I added it to my Rage128 driver too but I have
not observed the problem with them.
Framebuffer code is different and triggers the bug the
first time the secondary display is accessed.
/* Fix from ATI for problem with Radeon hardware not
leaving ROM enabled */
unsigned int temp;
temp = INREG(RADEON_MPP_TB_CONFIG);
temp &= 0x00ffffffu;
temp |= 0x04 << 24;
OUTREG(RADEON_MPP_TB_CONFIG, temp);
temp = INREG(RADEON_MPP_TB_CONFIG);
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
From: Alex Deucher <hidden> Date: 2003-08-14 18:06:07
I haven't tried multiple radeon cards, but I seem to recall several
people having this problem right around when 4.3.0 was released. I
don't think a "proper" fix ever went in and I think the issue was to be
revisited later. I don't know if it's needed anymore or not.
Alex
--- Jon Smirl <jonsmirl@yahoo.com> wrote:
quoted hunk
--- Alex Deucher <agd5f@yahoo.com> wrote:
quoted
quoted
2) access ROM directly instead of relying on copy
in low RAM. This allows multiple cards. Required
MPP_TB_CONFIG fix in driver.
Is this patch necessary for xfree86? It may address
some of the issues
in the email threads I sent out yesterday (ie,
problems with multiple
radeon cards and xfree86). if so would you consider
making one?
Xfree code does not have the patch, but is Xfree
experiencing the bug? Xfree accesses the hardware very
differently than the framebuffer drivers.
I suspect that you would see this problem if you were
using something else for your primary video and a
Radeon for secondary. The first time you ran Xfree it
would work. But when you exited and restarted Xfree it
would hang when starting the secondary display.
Where does XFree reset the secondary card? The code
below needs to run right after the reset in the radeon
driver. I added it to my Rage128 driver too but I have
not observed the problem with them.
Framebuffer code is different and triggers the bug the
first time the secondary display is accessed.
/* Fix from ATI for problem with Radeon hardware not
leaving ROM enabled */
unsigned int temp;
temp = INREG(RADEON_MPP_TB_CONFIG);
temp &= 0x00ffffffu;
temp |= 0x04 << 24;
OUTREG(RADEON_MPP_TB_CONFIG, temp);
temp = INREG(RADEON_MPP_TB_CONFIG);
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
From: Otto Solares <hidden> Date: 2003-08-14 18:26:31
On Wed, Aug 13, 2003 at 08:43:38PM -0700, Jon Smirl wrote:
Hopefully these is the last versions. They implement:
1) add every know PCI ID
2) access ROM directly instead of relying on copy in
low RAM. This allows multiple cards. Required
MPP_TB_CONFIG fix in driver.
3) implemented kernel 2.6 module parameters
4) Cleaned up error paths and made sure resources are
released on errors. Both build without compiler
warnings now. You can ins/rm mod multiple times
without problem. Just don't do it from a window in
your X server.
5) Driver marks both primary and secondary devices as
being in use.
nice work!
i know you are working with the dri fb drivers, is any
progress and what is the current state?
-solca
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
From: Steven Newbury <hidden> Date: 2003-08-14 18:32:55
On Thu, 2003-08-14 at 19:06, Alex Deucher wrote:
I haven't tried multiple radeon cards, but I seem to recall several
people having this problem right around when 4.3.0 was released. I
don't think a "proper" fix ever went in and I think the issue was to be
revisited later. I don't know if it's needed anymore or not.
It is still needed, Radeon as a secondary display only works on the
first initialisation (it can not find ROM on subsequent attempts) in all
XFree86 versions I have tried up to and including current CVS. At least
on my hardware... :-/
quoted hunk
Alex
--- Jon Smirl <jonsmirl@yahoo.com> wrote:
quoted
--- Alex Deucher <agd5f@yahoo.com> wrote:
quoted
quoted
2) access ROM directly instead of relying on copy
in low RAM. This allows multiple cards. Required
MPP_TB_CONFIG fix in driver.
Is this patch necessary for xfree86? It may address
some of the issues
in the email threads I sent out yesterday (ie,
problems with multiple
radeon cards and xfree86). if so would you consider
making one?
Xfree code does not have the patch, but is Xfree
experiencing the bug? Xfree accesses the hardware very
differently than the framebuffer drivers.
I suspect that you would see this problem if you were
using something else for your primary video and a
Radeon for secondary. The first time you ran Xfree it
would work. But when you exited and restarted Xfree it
would hang when starting the secondary display.
Where does XFree reset the secondary card? The code
below needs to run right after the reset in the radeon
driver. I added it to my Rage128 driver too but I have
not observed the problem with them.
Framebuffer code is different and triggers the bug the
first time the secondary display is accessed.
/* Fix from ATI for problem with Radeon hardware not
leaving ROM enabled */
unsigned int temp;
temp = INREG(RADEON_MPP_TB_CONFIG);
temp &= 0x00ffffffu;
temp |= 0x04 << 24;
OUTREG(RADEON_MPP_TB_CONFIG, temp);
temp = INREG(RADEON_MPP_TB_CONFIG);
From: Jon Smirl <hidden> Date: 2003-08-14 18:55:51
--- Otto Solares <solca@guug.org> wrote:
nice work!
i know you are working with the dri fb drivers, is
any progress and what is the current state?
I am working on embedded Mesa, which is another name
for standalone OpenGL. Embedded Mesa is based on the
3D DRI code but it handles 2D very differently.
Xfree/DRI scans the PCI bus and initializes hardware
in it's user space process. Embedded Mesa instead
loads the framebuffer drivers and uses them to
initialize the hardware. This makes Embedded Mesa much
simpler since it relies on the framebuffer drivers for
a lot of things such as mode switching and PCI bus
scanning.
You can get a snapshot of my work with this:
bk clone bk://mesa3d.bkbits.net/jonsmirl local_name
Standalone OpenGL works for most all Radeon chips if
you also use the updated framebuffers. Rage128 and MGA
support and being worked on but they are not ready
yet. This is development level code and it is not
ready for testing.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
From: James Simmons <hidden> Date: 2003-08-14 19:33:07
quoted
nice work!
i know you are working with the dri fb drivers, is
any progress and what is the current state?
I am working on embedded Mesa, which is another name
for standalone OpenGL. Embedded Mesa is based on the
3D DRI code but it handles 2D very differently.
Xfree/DRI scans the PCI bus and initializes hardware
in it's user space process. Embedded Mesa instead
loads the framebuffer drivers and uses them to
initialize the hardware. This makes Embedded Mesa much
simpler since it relies on the framebuffer drivers for
a lot of things such as mode switching and PCI bus
scanning.
You can get a snapshot of my work with this:
bk clone bk://mesa3d.bkbits.net/jonsmirl local_name
Standalone OpenGL works for most all Radeon chips if
you also use the updated framebuffers. Rage128 and MGA
support and being worked on but they are not ready
yet. This is development level code and it is not
ready for testing.
Oh wow. That is way to cool!!!! I suggest you merge your work with
the khronos group. It would be really nice to see a embedded OpenML
implementation. I'm looking into this since I plan to implement Java3D
/JavaX media layer for GNU Classpath/Kaffe in the near future.
http://www.khronos.org/
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
From: Otto Solares <hidden> Date: 2003-08-14 20:18:54
On Thu, Aug 14, 2003 at 11:55:51AM -0700, Jon Smirl wrote:
quoted hunk
--- Otto Solares <solca@guug.org> wrote:
quoted
nice work!
i know you are working with the dri fb drivers, is
any progress and what is the current state?
I am working on embedded Mesa, which is another name
for standalone OpenGL. Embedded Mesa is based on the
3D DRI code but it handles 2D very differently.
Xfree/DRI scans the PCI bus and initializes hardware
in it's user space process. Embedded Mesa instead
loads the framebuffer drivers and uses them to
initialize the hardware. This makes Embedded Mesa much
simpler since it relies on the framebuffer drivers for
a lot of things such as mode switching and PCI bus
scanning.
good! IMO this is the future for linux!
i would like to see this work merged with the dri.sf.net
folks and a unified set of drivers for both fb and Xfree.
Is this possible, is this your objective? or embedded
mesa will always be an standalone project...
-solca
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
From: Jon Smirl <hidden> Date: 2003-08-14 21:45:48
--- Otto Solares <solca@guug.org> wrote:
good! IMO this is the future for linux!
i would like to see this work merged with the
dri.sf.net folks and a unified set of drivers for
both fb and Xfree. Is this possible, is this your
objective? or embedded mesa will always be an
standalone project...
The long term plan is for a single OpenGL shared
object that runs standalone, with DirectFB or under
XFree/DRI. There is nothing technical stopping this,
it just a matter of adjusting bunches of code.
3D drivers from DRI work in the embedded version with
minor changes mostly having to do with removing GLX
code from the drivers. 2D is a different story.
Significant code needs to be adjusted for each driver.
I am working on the Rage128 driver currently. Radeon
and MGA are done. Nothing else has been started yet.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-08-14 22:04:19
On Thu, 2003-08-14 at 18:00, Jon Smirl wrote:
quoted hunk
--- Benjamin Herrenschmidt <benh@kernel.crashing.org>
wrote:
quoted
This is a problem. We also parse it to find the DFP
EDID and/or flat panel informations, do that work
with the real ROM ? I don't know much about x86
BIOSes, but at least for the DFP EDID, I suppose
that one is read in RAM by the BIOS, not in the
ROM...
On x86 machines low RAM contains a copy of the ROM,
now you are getting a pointer to the real ROM. The
contents are identical. The only difference is that
you need to use the readb()/readw()/etc macros to read
it. On the x86 readb() does nothing, but on other
platforms it will trigger a PCI read cycle. This plus
side to this is that you can use multiple video cards.
Well... Again, this has to be verified in real life, but
my understanding is that the BIOS code, once it has probed
the DFP flat panel, will put the EDID data in RAM somewhere
within the copy of the BIOS, which is where we then find
it... The best thing would still be, of course, to implement
full DDC probing in radeonfb like XFree does. This has been
on my todolist for a while now, but I lack time.
Ben.
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
From: Jon Smirl <hidden> Date: 2003-08-14 22:47:30
--- Benjamin Herrenschmidt <benh@kernel.crashing.org>
wrote:
Well... Again, this has to be verified in real life,
but
my understanding is that the BIOS code, once it has
probed
the DFP flat panel, will put the EDID data in RAM
somewhere
within the copy of the BIOS, which is where we then
find
it... The best thing would still be, of course, to
implement
full DDC probing in radeonfb like XFree does. This
has been
on my todolist for a while now, but I lack time.
Ben.
Putting the EDID data into the RAM copy will never
work the case where there are multiple cards since
there is only one copy of the ROM in low RAM.
Personally I'd just like to ignore the boot VROM and
do everything in the Radeon driver code. But ATI won't
give out detailed info on how to read EDID or reset
the card with C code from the driver. So instead we
end up with the idiotic x86 emulator and doing INT10's
in simulated real mode.
Maybe someone with more leverage can coax this info
out of them.....
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-08-15 08:18:37
Putting the EDID data into the RAM copy will never
work the case where there are multiple cards since
there is only one copy of the ROM in low RAM.
Yup, but at least it works for single cards, and that
helps a lot of users until radeonfb can do better
Personally I'd just like to ignore the boot VROM and
do everything in the Radeon driver code. But ATI won't
give out detailed info on how to read EDID or reset
the card with C code from the driver. So instead we
end up with the idiotic x86 emulator and doing INT10's
in simulated real mode.
Maybe someone with more leverage can coax this info
out of them.....
Getting the full POST code is probably a lost cause. However,
if you look at the current XFree CVS driver, you'll see rather
complete code to get the EDID via DDC/i2c on all connectors.
Ben.
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01