[PATCH 1/2] drm: allow drivers to provide their own EDID fetching routine
Dave Airlie
airlied at redhat.com
Tue Jul 20 16:35:38 PDT 2010
On Tue, 2010-07-20 at 16:34 -0700, Jesse Barnes 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.
>
You can expose /dev/i2c devices properly to userspace, you can't do that
with the code you proposed.
Dave.
More information about the dri-devel
mailing list