Re: Patch for review and testing

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Wed, 2004-01-28 at 09:09, James Simmons wrote:
> > > I like to submit this patch to linus today. Could you test it to see if it 
> > > works on ppcs. 
> > 
> > Well... you didn't update the drivers calling get_EDID_from_OF (I think
> > only rivafb at this point). 
> 
> The patch is against the vanilla tree. In the fbdev-2.5 tree I have to 
> update rivafb for this. Actually I will remove that code from rivafb. 
> 
> > Also, I plan to deprecate that function in
> > fbmon anyway, so don't bother, leave it alone for now. The way the
> > display/EDID infos are laid out in the OF device tree isn't that
> > generic and I'm considering letting each driver has its own version...
> 
> Then I will remove it.

Not yet, not until the new version is in. It does work someway with the
current code. Let me deal with those OF things please.

> That was to make the function generic. Well it doesn't matter as I'm going 
> to remove the OF function so the pci stuff can go away.

Actually, that may not be a good approach neither... You probably want
to check that you are indeed dealing with the default VGA device so an
additional card don't get an unrelated EDID, no ?

Also, other archs may want to implement this function too. Keep the
struct device as an argument, check for bus_type before casting to PCI,
and we should probably, in the x86 PCI code, "remember" the pci_dev of
the default VGA (if not done already) and compare it on calls to this
function. (To be completely clean, I also need to know if I'm the
primary VGA in radeonfb and aty128fb).
 
> > Finally, I don't see the point of submiting things to Linus at this
> > point, especially this patch which isn't critical (and you didn't even
> > submit driver changes for _using_ the new feature). 
> 
> Actually it is. The BIOS calls can hang some intel machines or make 
> booting  up to 5 seconds longer waiting for the data. If this was not the 
> case I wouldn't be submitting it.

What about a cmdline option then ? it's too early during boot to check
for it ? vendors will build kernels with or without the CONFIG_ option,
and people won't change it, so I'm afraid it will be useless... Is the
BIOS call standard ? There may be a way to workaround the hang, no ? Or
it's one of those calls that Windows never uses and are broken in half
of the BIOSes around ?

> > Andrew is the
> > maintainer of current 2.6.x stable, patches have to go to him first,
> > stage in -mm for a while to be tested, and then go to Linus.
> 
> This is just making the code conditional.  I will send another patch in a 
> minute then.
-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn