Re: [PATCH] DDC2/I2C Support

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

> There was the patch I submitted some 8 months ago and has been in the kernel 
> since linux-2.5.x.  For X86, it will get the EDID block via VBE calls before 
> the kernel goes to protected mode.  This is used by get_EDID_from_BIOS() in 
> fbmon.c. Actual code is in boot/arch/i386/boot/video.S[store_edid]
> 
> Currently, it's always compiled in and some people reported problems with it 
> (like taking 5 minutes to boot - probably BIOS using DDC1). I just added a 
> kernel config for it so people can choose to compile it out.  However, with 
> most drivers still not having DDC/I2C support, it's an easy way of getting 
> the EDID block.

Ok, if we go that way, we also need to store somewhere the PCI ID of
the primary display for which the EDID was "captured" or we'll do
weird things with several cards. I need to know which card is the
primary one anyway in radeonfb for other reasons (I need to fallback
to the RAM image of the BIOS with some laptops for the on-board
display)...

> > Can we define a "parsed_EDID" structure or whatever we call it that
> > contains the list of modes, the monspecs, and other informations
> > obtained from the EDID all at once ? I also need the display model
> > name and vendor for example (to deal with some "fixups"). it would
> > be convenient to have one single parsing pass extracting all the
> > informations to one structure...
> >
> 
> Ok, this should not be hard.

Good ;)

> > > --------------------------------------------------------
> > >
> > > 5. [fbcon.c]: Minor fixes on the cursor and scrolling.
> >
> > That pops up something else in my mind... Shouldn't we take the console
> > sempahore when doing cursor ops in the workqueue ?
> 
> I believe so.  I'm not sure where to start though. info->fb_cursor is called 
> by at least two functons (fbcon_cursor, fb_flash_cursor), and I don't see any 
> form of locking, especially for the data in info->cursor which is constantly 
> being modified by one and read by another.

In the work queue code itself. I'll do a patch for that after testing
here. (See my other race fixes).

> > I strongly suggest that you look at what I've done for radeonfb and stty
> > in my tree with FB_ACTIVATE_FIND and my mode search algorithm....
> 
> Ok. 
> > Boot parameters are evil... we should default to the "right" way whenever
> > possible. Let's make sure we properly deal with either complete modes
> 
> Evil, yes, but for now, necessary. Until the stty fix (and the 
> FB_ACTIVATE_FIND) is accepted by James, I will need this new boot parameter. 
>  
> I'll submit a new patch (without the fbi2c code) by next week.  Still too busy 
> to work full time with fbdev.

No problem, we can always extract the good stuff from your current
one anyway :)

Ben.




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click