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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jul 20, 2010 at 7:43 PM, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote:
> On Tue, 20 Jul 2010 16:34:39 -0700
> Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote:
>
>> On Wed, 21 Jul 2010 09:27:54 +1000
>> Dave Airlie <airlied@xxxxxxxxxx> 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@xxxxxxxxxx> 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...

>From my experience, I doubt you'll see any improvement; KVMs and
crappy monitors are still crappy.  The hw i2c engines are mostly there
to reduce CPU usage and allow i2c transactions to be interrupt driven.

Alex
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux