[i915][855GME][GMBUS] Detection of DVO transmitter unreliable

[i915][855GME][GMBUS] Detection of DVO transmitter unreliable

["David Müller (ELSOFT AG)"]

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


Does anybody have an idea what this could be and how to fix it?


Dave

Re: [i915][855GME][GMBUS] Detection of DVO transmitter unreliable

[Daniel Vetter]

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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch