Re: [PATCH 1/2] drm/kms: Make i2c buses faster

[Jean Delvare <jdelvare@suse.de>]

Hi Alan,

On Friday 21 October 2011 03:32:44 pm Alan Cox wrote:
> On Fri, 21 Oct 2011 09:08:30 +0200
> 
> Jean Delvare <jdelvare@suse.de> wrote:
> > A udelay value of 20 leads to an I2C bus running at only 25 kbps. A
> > value of 40 as the nouveau driver has is even slower at 12.5 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 is needed.)
> 
> That depends on your cable, drive and signal quality. It's not
>  something you just turn up because it seems a good idea. Reliability
>  is MUCH more important than shaving microseconds off monitor probe
>  times.

We're talking milliseconds here, not microseconds. Namely 23 ms per 128-
byte EDID block for intel and radeon, 69 ms for nouveau.

I very much doubt that cable quality is an issue here. DDC is a very 
slow bus (even at the maximum speed of 100 kbps) compared to the video 
signal which is running through the other wires in the VGA or DDC cable. 
If you really reach the point where DDC becomes unreliable, I doubt the 
video signal is anywhere next to usable.

More importantly, my initial motivation for sending this patch is that 
it may help prevent problems due to the software nature of bit-banged 
I2C. A faster clock means shorter (time-wise) messages, which in turn 
means less risks to be disturbed by interrupts or CPU overload.

Last but not least, I can't believe that so many framebuffer drivers 
would have been using these settings for years if it caused trouble.

Does anyone know at which speed hardware I2C engines are running the DDC 
bus on various graphics cards?

-- 
Jean Delvare
Suse L3