On Wed, Mar 21, 2012 at 9:30 AM, Jean Delvare <jdelvare at suse.de> wrote: > A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C > devices can typically operate faster than this, 50 kbps should be fine > for all devices (and compliant devices can always stretch the clock if > needed.) > > FWIW, the vast majority of framebuffer drivers set udelay to 10 > already. So set it to 10 in DRM drivers too, this will make EDID block > reads faster. We might even lower the udelay value later if no problem > is reported.
FWIW, our proprietary code uses 50 khz for i2c. So I think it should be fine. Alex > > Signed-off-by: Jean Delvare <jdelvare at suse.de> > Reviewed-by: Alex Deucher <alexdeucher at gmail.com> > Cc: Dave Airlie <airlied at gmail.com> > --- > Changes since v1: > * Split per driver to make merging easier. > * Make the subject line more accurate. > > ?drivers/gpu/drm/radeon/radeon_i2c.c | ? ?2 +- > ?1 file changed, 1 insertion(+), 1 deletion(-) > > --- linux-3.4-rc0.orig/drivers/gpu/drm/radeon/radeon_i2c.c ? ? ?2012-03-21 > 13:43:33.753915151 +0100 > +++ linux-3.4-rc0/drivers/gpu/drm/radeon/radeon_i2c.c ? 2012-03-21 > 13:48:01.619472673 +0100 > @@ -925,7 +925,7 @@ struct radeon_i2c_chan *radeon_i2c_creat > ? ? ? ? ? ? ? ?i2c->algo.bit.setscl = set_clock; > ? ? ? ? ? ? ? ?i2c->algo.bit.getsda = get_data; > ? ? ? ? ? ? ? ?i2c->algo.bit.getscl = get_clock; > - ? ? ? ? ? ? ? i2c->algo.bit.udelay = 20; > + ? ? ? ? ? ? ? i2c->algo.bit.udelay = 10; > ? ? ? ? ? ? ? ?/* vesa says 2.2 ms is enough, 1 jiffy doesn't seem to always > ? ? ? ? ? ? ? ? * make this, 2 jiffies is a lot more reliable */ > ? ? ? ? ? ? ? ?i2c->algo.bit.timeout = 2; > > -- > Jean Delvare > Suse L3
