On Sat, 2003-08-16 at 03:24, Jon Smirl wrote:
linux/pci_ids.h just had a check-in which caused a big
merge conflict with my patch. I have tried to sort it
out.
Please check Radeon PCI IDs and chip families in
radeonfb driver. It is important that the PCI IDs of
secondary devices be marked as such.
This patch merges Rage128 and Radeon changes into a
single patch. It is against current 2.5 bk r1.1188.
So you still go to ROM unconditionally... Well, we should
get that tested, I don't have the offending x86 hardware,
but I'd like to know if that still works with all those
DFPs for which we obtain the EDID via the BIOS image in RAM...
Again, adding that fixed the driver for a _lot_ of users, so
I'd like not to change that until we have a replacement with
real i2c accesses...
(Note: The DFP code may not be in the current 2.6 version of
the driver, it's only in 2.4 afaik, it's part of some radeonfb
updates I have pending).
What we could do is, if we can figure out which is the primary
card, do the RAM search on it only, and use ROM for others,
but then, that leads me to another question regarding multiple
cards: Are they all POSTed (initialized) by the BIOS ? I though
x86 BIOSes only initialized the first card ?
If they aren't, then there's no point in that fix anyway since
neither aty128fb nor radeonfb will work on a card that wasn't
POSTed by the BIOS.
Also, looking quickly at the patches:
- r128: why do you change the chip generations this way ? Is
there any _use_ of that change (splitting PCI/nonPCI) or it's
just that you prefer it like that ? I'd rather leave it the way
it was, and/or eventually add some bit flags indicating if it's
PCI and/or AGP...
- r128 & radeon : your change of the setup functions to turn them
into module params, I'm not sure I like them at least not at this
point. This will change the syntax on the kernel command line at
least, which I'd rather not do at this stage
- AFAIK, Paul Mackerras [off-list ref] is the current aty128fb
maintainer, can you pass the changes through him ?
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
--- Benjamin Herrenschmidt <benh@kernel.crashing.org>
wrote:
The big picture here is that aty128fb and radeonfb
have not had their PCI ID tables updated since 2.6 was
started. Any hardware made since then can't use the
framebuffer drivers.
So you still go to ROM unconditionally... Well, we
should get that tested, I don't have the offending
x86
hardware, but I'd like to know if that still works
with all
those DFPs for which we obtain the EDID via the BIOS
image in RAM...
I can't break something that doesn't exist in the 2.6
framebuffer code.
Again, adding that fixed the driver for a _lot_ of
users, so I'd like not to change that until we have
a
replacement with real i2c accesses...
I am not changing this, it doesn't exist in 2.6.
(Note: The DFP code may not be in the current 2.6
version of the driver, it's only in 2.4 afaik, it's
part of
some radeonfb updates I have pending).
What we could do is, if we can figure out which is
the primary card, do the RAM search on it only, and
use ROM for others, but then, that leads me to
another
question regarding multiple cards: Are they all
POSTed
(initialized) by the BIOS? I though x86 BIOSes only
initialized the first card ?
Only the primary card is POSTed and copied to low RAM.
Note that it is possible to mix vendors and the copy
in RAM may not even belong to a Rage/Radeon.
The correct solution is to read the I2C data like
XFree does and not to rely on the copy in the BIOS.
The Redhat installer also gets it data from I2C.
Reading the copy in low RAM doesn't work if the user
switches monitors either. Besides, how are you sure
the copy in low RAM belongs to your adapter?
Another way to get EDID data is to use an INT10 from a
user level program. This is compilcated because you
need to use the real mode emulator and change the
INT10 vectors for the various cards.
When PCI/X gets here next year this problem will be
much worse since it will be trivial to install
multiple video cards.
I'm all for using EDID data, it just needs to
retrieved in the correct manner.
If they aren't, then there's no point in that fix
anyway
since neither aty128fb nor radeonfb will work on a
card
that wasn't POSTed by the BIOS.
I have a small program that will POST a secondary
card. Starting XFree on them as a primary or secondary
will also POST them.
I have been annoying ATI (without success) for months
trying to get code out of them to do this so that I
can add it directly to the fb driver.
Also, looking quickly at the patches:
- r128: why do you change the chip generations this
way ? Is
there any _use_ of that change (splitting
PCI/nonPCI) or it's
just that you prefer it like that ? I'd rather leave
it the way
it was, and/or eventually add some bit flags
indicating if it's
PCI and/or AGP...
The change was made to select a string for the
appropriate chip generation in the sign-on message.
The driver has to know PCI or AGP. The PCI IDs are
used to tell.
- r128 & radeon : your change of the setup
functions to turn them into module params,
I'm not sure I like them at least not at this
point. This will change the syntax on the kernel
command line at least, which I'd rather not do
at this stage
2.6 has provided module functions to standardize the
module parameter syntax.
The only chage is under the old scheme you could say:
modprobe radeonfb 1024x768
now you have to say:
modprobe radeonfb mode=1024x768
Is there a way to do unnamed params with the new
functions, or was that purposely left out?
I have posted several times indicating that I believe
setting the mode from the load command to be
non-functional in 2.6 anyway and asking for an
explaination of how it is suppose to work.
The current code, which I did not change, only uses
the mode data to set the mode variables and not to
actually set the mode. It I modify the driver to
actually set the mode fbconsole breaks.
- AFAIK, Paul Mackerras [off-list ref] is the
current aty128fb
maintainer, can you pass the changes through him ?
I sent him a copy. Doesn't he read the fbdev list?
=====
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
On Sat, 2003-08-16 at 18:19, Jon Smirl wrote:
quoted hunk
--- Benjamin Herrenschmidt <benh@kernel.crashing.org>
wrote:
The big picture here is that aty128fb and radeonfb
have not had their PCI ID tables updated since 2.6 was
started. Any hardware made since then can't use the
framebuffer drivers.
Yup, and that part of your patch is great. I have more chips
in the version in my tree than in official 2.6, but your list
is definitely more complete.
One reason my version isn't merged upstream yet is that it relies
on some other bits (mostly power management) that James didn't merge
yet, but I could strip them out.
quoted
So you still go to ROM unconditionally... Well, we
should get that tested, I don't have the offending
x86
quoted
hardware, but I'd like to know if that still works
with all
quoted
those DFPs for which we obtain the EDID via the BIOS
image in RAM...
I can't break something that doesn't exist in the 2.6
framebuffer code.
It's in the 2.4 one and I was about to push it to 2.6. It is
necessary for a bunch of cases
quoted
Again, adding that fixed the driver for a _lot_ of
users, so I'd like not to change that until we have
a
quoted
replacement with real i2c accesses...
I am not changing this, it doesn't exist in 2.6.
As I told you, it is in 2.4. The 2.6 codebase isn't up to date,
but that's not a reason not to fix that, the DFP code is necessary
for a lot of machines.
Only the primary card is POSTed and copied to low RAM.
Note that it is possible to mix vendors and the copy
in RAM may not even belong to a Rage/Radeon.
This is a real issue yes.
The correct solution is to read the I2C data like
XFree does and not to rely on the copy in the BIOS.
Yes.
The Redhat installer also gets it data from I2C.
Reading the copy in low RAM doesn't work if the user
switches monitors either. Besides, how are you sure
the copy in low RAM belongs to your adapter?
Another way to get EDID data is to use an INT10 from a
user level program. This is compilcated because you
need to use the real mode emulator and change the
INT10 vectors for the various cards.
Int10 will not work on all archs
When PCI/X gets here next year this problem will be
much worse since it will be trivial to install
multiple video cards.
I'm all for using EDID data, it just needs to
retrieved in the correct manner.
Yes, but the current 2.4 DFP tweak is not that bad, few
people have more than one board, I'm also curious how does
XFree since that EDID thing was copied from it, I suppose
it gives me a c00000 RAM image that isn't the real one but
comes from what it's own call to that card's BIOS POST
generated...
quoted
If they aren't, then there's no point in that fix
anyway
quoted
since neither aty128fb nor radeonfb will work on a
card
quoted
that wasn't POSTed by the BIOS.
I have a small program that will POST a secondary
card. Starting XFree on them as a primary or secondary
will also POST them.
Provided they have an x86 BIOS...
I have been annoying ATI (without success) for months
trying to get code out of them to do this so that I
can add it directly to the fb driver.
They'll not give you that as the POST code is basically board
specific (depends on how things are wired on a given board) and
only the version of BIOS on that board knows that...
The change was made to select a string for the
appropriate chip generation in the sign-on message.
The driver has to know PCI or AGP. The PCI IDs are
used to tell.
quoted
- r128 & radeon : your change of the setup
functions to turn them into module params,
I'm not sure I like them at least not at this
point. This will change the syntax on the kernel
command line at least, which I'd rather not do
at this stage
2.6 has provided module functions to standardize the
module parameter syntax.
The only chage is under the old scheme you could say:
modprobe radeonfb 1024x768
now you have to say:
modprobe radeonfb mode=1024x768
Is there a way to do unnamed params with the new
functions, or was that purposely left out?
What about kernel command line ? This is used a lot for
fbdev drivers
I have posted several times indicating that I believe
setting the mode from the load command to be
non-functional in 2.6 anyway and asking for an
explaination of how it is suppose to work.
The current code, which I did not change, only uses
the mode data to set the mode variables and not to
actually set the mode. It I modify the driver to
actually set the mode fbconsole breaks.
The mode is set by takeover_console on boot, though I didn't
try loading radeonfb as a module, that may be broken.
quoted
- AFAIK, Paul Mackerras [off-list ref] is the
current aty128fb
maintainer, can you pass the changes through him ?
I sent him a copy. Doesn't he read the fbdev list?
I don't know, it's always best to CC at least a maintainer. People
like Paul or I have way too many mails & lists to follow... at least
when I'm on the To or CC list, some filters highlight the message for
me.
Also, while it's not in the comments yet, I took over maintainership
of radeonfb in 2.4. I'm not 100% sure I want to be the maintainer for
2.6 as well (though I did the current port from an older 2.4 version),
let me know if you want to take that role.
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