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

[Jesse Barnes <jbarnes@virtuousgeek.org>]

On Wed, 21 Jul 2010 09:27:54 +1000
Dave Airlie <airlied@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@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.

-- 
Jesse Barnes, Intel Open Source Technology Center