On Fri, Oct 21, 2011 at 10:16 AM, Jean Delvare <jdelvare@xxxxxxx> 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@xxxxxxx> 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? IIRC, we generally target the radeon hw i2c engines to run at 50 khz. Alex > > -- > Jean Delvare > Suse L3 > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel