[Intel-gfx] [PATCH 1/2] drm: allow drivers to provide their own EDID fetching routine

[Jesse Barnes]

On Tue, 20 Jul 2010 16:34:39 -0700
Jesse Barnes <jbarnes at virtuousgeek.org> wrote:

> On Wed, 21 Jul 2010 09:27:54 +1000
> Dave Airlie <airlied at redhat.com> wrote:
> 
> > On Tue, 2010-07-20 at 16:05 -0700, Jesse Barnes wrote:
> > > On Wed, 21 Jul 2010 08:54:30 +1000
> > > Dave Airlie <airlied at redhat.com> wrote:
> > > 
> > > > On Tue, 2010-07-20 at 15:44 -0700, Jesse Barnes wrote:
> > > > > Make drm_edid_read take a new argument, edid_read, to allow drivers to
> > > > > provide their own EDID fetch routine.  Export the bit banging DDC over
> > > > > i2c version of the EDID fetching routine and make the drivers use it.
> > > > > This sets the stage for GMBUS support in the Intel driver.
> > > > > 
> > > > 
> > > > I think this needs some rework.
> > > > 
> > > > You might want to checkout what the radeon driver does for hw i2c
> > > > engine. You should set up your own i2c hw handlers and use those instead
> > > > of bypassing the i2c stack. GMBUS is just another i2c hw block.
> > > 
> > > I'll check it out, but I don't see what using the i2c stack buys us
> > > here except for obfuscation...
> > > 
> > 
> > You'll want to use GMBUS for SDVO at some point in the future, or
> > something else, or you'll want to expose it to userspace for DDC/CI
> > users. Lots of reasons, its not obfuscation at all, what you are doing
> > is dodgy shortcuts.
> 
> Using it for SDVO and other things means some other changes to the
> GMBUS code unfortunately.  Still not seeing how using i2c makes
> userspace exposure or SDVO usage easier, but I don't care, I'll switch
> it around to use i2c core code.

Assuming it helps a all of course.  My hope here was that it would be
able to get EDID out of configurations where we currently have trouble,
like monitor switches or just plain crappy monitors.  If it doesn't
help I don't think there's much need to keep the code around...

-- 
Jesse Barnes, Intel Open Source Technology Center