Hi Keith, Sorry for the late reply. On Sunday 29 January 2012 02:26:25 am Keith Packard wrote: > On Sat, 28 Jan 2012 11:07:09 +0100, Jean Delvare <jdelvare@xxxxxxx> > wrote: > > A udelay value of 20 leads to an I2C bus running at only 25 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 if needed.) > > > > FWIW, the vast majority of framebuffer drivers set udelay to 10 > > already. So set it to 10 in DRM drivers too, this will make EDID > > block reads faster. We might even lower the udelay value later if > > no problem is reported. > > That runs the DDC at a whopping 50kbps, which is half of the maximum > rate specified in the DDC/CI standard. I don't know if we can count > on clock stretching (http://www.i2c-bus.org/clock-stretching/), but > if so, I don't know why we wouldn't just go to the standard 100kbps > data rate and be done with it. We may end up doing that. I wanted to play it safe for now as at least Alan Cox expressed concerns with increasing the speed of DDC buses. I don't share them, but being cautious can't hurt. Clock stretching is optional, each slave is free to implement it or not. I very much doubt it is needed when reading and EDID though, even at 100 kbps. Typically what takes time is writing to EEPROMs, but in general EEPROMs will buffer the write and simply stop responding to their slave addresses until done. This is why most EEPROMs have a documented write page size. Displays must be interoperable by design, so I'd hope that every serious display maker would only use EEPROMs that can either cope with 100 kbps or do clock stretching as needed. I have no doubt crappy hardware exists, but I'd rather decrease the clock speed on repeated errors than default to a slow clock speed. Users with good hardware should get the best out of it. > Might be nice to see what frequency Windows uses for i2c; anyone want > to pull a vga cable apart and hook up a logic analyser? Can't do that, sorry. It would certainly be valuable if someone has the time, hardware and interest, however I don't think "Windows" uses a frequency, rather separate video drivers are likely to have their own implementation and speed (if nothing else, simply because recent video cards use hardware I2C engines rather than bit-banging.) -- Jean Delvare Suse L3 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel