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? -- Jean Delvare Suse L3 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel