[PATCH 1/2] drm/kms: Make i2c buses faster
jdelvare at suse.de
Fri Oct 21 07:16:28 PDT 2011
On Friday 21 October 2011 03:32:44 pm Alan Cox wrote:
> On Fri, 21 Oct 2011 09:08:30 +0200
> Jean Delvare <jdelvare at 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
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?
More information about the dri-devel