[PATCH 1/2] drm/kms: Make i2c buses faster
alexdeucher at gmail.com
Fri Oct 21 11:05:48 PDT 2011
On Fri, Oct 21, 2011 at 10:16 AM, Jean Delvare <jdelvare at suse.de> wrote:
> 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 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?
IIRC, we generally target the radeon hw i2c engines to run at 50 khz.
> Jean Delvare
> Suse L3
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
More information about the dri-devel