On Thu, Oct 13, 2011 at 9:36 PM, Eugeni Dodonov <[email protected]> wrote: > On Thu, Oct 13, 2011 at 17:34, Adam Jackson <[email protected]> wrote: >> >> On Thu, 2011-10-13 at 15:11 -0300, Eugeni Dodonov wrote: >> >> > diff --git a/drivers/gpu/drm/i915/intel_i2c.c >> > b/drivers/gpu/drm/i915/intel_i2c.c >> > index d98cee6..b3a6eda 100644 >> > --- a/drivers/gpu/drm/i915/intel_i2c.c >> > +++ b/drivers/gpu/drm/i915/intel_i2c.c >> > @@ -470,3 +470,45 @@ void intel_teardown_gmbus(struct drm_device *dev) >> > kfree(dev_priv->gmbus); >> > dev_priv->gmbus = NULL; >> > } >> > + >> > +/** >> > + * intel_drm_get_valid_edid - gets edid from existent adapters only >> > + * @connector: DRM connector device to use >> > + * @adapter: i2c adapter >> > + * >> > + * Verifies if the i2c adapter is responding to our queries before >> > + * attempting to do proper communication with it. If it does, >> > + * retreive the EDID with help of drm_get_edid >> > + */ >> > +struct edid * >> > +intel_drm_get_valid_edid(struct drm_connector *connector, >> > + struct i2c_adapter *adapter) >> > +{ >> > + int ret; >> > + u8 out_buf[] = { 0x0, 0x0}; >> > + u8 buf[2]; >> > + struct i2c_msg msgs[] = { >> > + { >> > + .addr = 0x50, >> > + .flags = 0, >> > + .len = 1, >> > + .buf = out_buf, >> > + }, >> > + { >> > + .addr = 0x50, >> > + .flags = I2C_M_RD, >> > + .len = 1, >> > + .buf = buf, >> > + } >> > + }; >> > + >> > + /* We just check for -ENXIO - drm_get_edid checks if the transfer >> > + * works and manages the remaining parts of the EDID */ >> > + ret = i2c_transfer(adapter, msgs, 2); >> >> This seems like it should be the implementation body of drm_probe_ddc, >> and like that function should be EXPORT_SYMBOL()'d. Other people want >> to do zero-length reads too, you know. >> >> - ajax > > My other patch in the previous series > (http://www.mail-archive.com/[email protected]/msg05828.html) > did exactly that, but it haven't received any comments, and there was one > report saying that it decreased the detection timing on a radeon card. I > don't have any to test, so I prefer to focus on Intel ones (which I have) > :).
Thats not how we develop in the kernel btw. You should go around trying to poke developers from other drivers to test the patch. Dave. _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
