On Tue, Apr 16, 2013 at 09:53:24AM +0200, "David Müller (ELSOFT AG)" wrote:

Hello

I have a 855GME based system with a TFP410 DVO transmitter and running a vanilla Linux-3.8 kernel.

With the activation of the hardware assisted GMBUS feature (somewhere near kernel 3.5), the detection of the TFP410 DVO transmitter has become flacky, which results in an unusable DVO port.

As a first test, i reduced the I2C frequency from 100kHz to 50kHz and the problem vanished. I used a scope to check the signal quality on the I2C lines to the DVO transmitter, but everything seems to be within the specs.

I also checked the whole DVO transmitter initialisation sequence defined in "intel_dvo.c" and there i noticed that the I2C communication is completely messed up for 1 or 2 I2C transaction after the receipt of the first NAK (in my case, this will be for the CH7xxx chip at addr 0x76).

In the "intel_i2c.c" file, there is a remark that one has to be careful when clearing the NAK condition, otherwise the next I2C transaction may fail. I played around with this piece of code by adding additional delays but to no avail so far.

In the same file, there is also a line which disables the hardware assisted GMBUS functionality for i830 based system. Does anybody know if the 855GME may be struck by the same problem as the i830?

Currenty i have figured out two possible work-arounds:

• add "IS_I85X()" to the list of broken systems
• reduce the clock rate from 100kHz to 50kHz

I guess we should force bit-banging like we already do for sdvo outputs, see the calls to intel_gmbus_force_bit in intel_sdvo.c. Can you please write such a patch, test it on your machine (I don't have any gen2 dvo machines) and then submit it for inclusion?

Please cc me on the patch (and please also cc the intel-gfx mailing list) so it doesn't get lost.

Thanks, Daniel