HDMI DDC pull up specification

[Fabio Estevam]

Hi,

According to this datasheet (Table 3) :
http://www.nxp.com/documents/data_sheet/PCA9507.pdf

the HDMI SDA/SCL pull ups should be between 1.5k - 2.0k.

On Wandboard these pullups are 2.2k.

Could this cause some of the DDC issues people have been reporting?

Regards,

Fabio Estevam

[nizamov...@gmail.com]

Hi,

This is unlikely, pull-up resistors on i2c bus can vary widely without adverse effects.

Regards,
S.Nizamov

[John Weber]

Agreed, and in fact I've tried pulling it up.  The translator used on the WB is a TXS0102, with a built-in 10K pullup (I think), but I added a 2K to the pads on the board to see if it would cause things to work.  No joy.

But, I hear that the Mainline guys are having some luck here, so perhaps this is a software configuration issue with the 3.0.35 kernel.

[Fabio Estevam]

On Mon, Aug 12, 2013 at 3:23 PM, John Weber <rjohn...@gmail.com> wrote:
> Agreed, and in fact I've tried pulling it up. The translator used on the WB
> is a TXS0102, with a built-in 10K pullup (I think), but I added a 2K to the
> pads on the board to see if it would cause things to work. No joy.
>
> But, I hear that the Mainline guys are having some luck here, so perhaps
> this is a software configuration issue with the 3.0.35 kernel.

According to Tony Prisk, EDID reading is not stable even with mainline kernel:
http://marc.info/?l=linux-arm-kernel&m=137616577919403&w=2

[Tony Prisk]

I have noticed that on my Samsung 22" LED TV, the EDID/DDC reading is
sporatic at best - Sometimes it's fine, other times it fails. Once it
works at bootup, it seems to continue working though. On my old Acer 42"
LCD TV, I haven't seen it fail yet from about 20 tries.

Definitely seems like it could be a timing issue or signal level problem.

Regards
Tony Prisk

[nizamov...@gmail.com]

On Monday, August 12, 2013 9:29:35 PM UTC+2, Tony Prisk wrote:

I have noticed that on my Samsung 22" LED TV, the EDID/DDC reading is
sporatic at best - Sometimes it's fine, other times it fails. Once it
works at bootup, it seems to continue working though. On my old Acer 42"
LCD TV, I haven't seen it fail yet from about 20 tries.

Definitely seems like it could be a timing issue or signal level problem.

Did you try to read edid using with i2cdetect/i2cdump or are judging only by bootup problems?

I am curios what is the frequency for i2c on wandboard and how can it be changed. If I recoll correctly, it should be 100 khz to be safe, but many use 400 khz or even higher.

Best regards,

[Tony Prisk]

I always have it configured at 100Khz, although I haven't actually checked that it is ACTUALLY at 100Khz.
I can dump the DDC info from i2cdump ONLY when it works at boot up. If it fails at boot up (to read the EDID that is), then it fails to dump (or detect) via the I2C tools as well.

I suspect that the I2C bus actually hangs when it fails, but again, I haven't taken the time to confirm it.

Regards
Tony P

[Tony Prisk]

The one thing I didn't mention which has always concerned me a little is that I2C1 and I2C2 seem to be wired together on the schematic. I2C2 is normally configured for the audio codec.

While I suspect this shouldn't cause an issue, as I2C2 would make the lines busy when in use hence making I2C1 busy as well, it's possible that the reason EDID/DDC fails during bootup is because I2C2 is being configured while I2C1 is being used and this causes a bus lockup - purely speculation though... and it doesn't explain why it works fine on one monitor and not on another.

Tony P

[John Weber]

Hi Tony,

> The one thing I didn't mention which has always concerned me a little is that
> I2C1 and I2C2 seem to be wired together on the schematic. I2C2 is normally
> configured for the audio codec.

They are not actually wired together because the shorting resistors from I2C2 to
I2C1 are not populated (or should not be...

John

[Fabio Estevam]

On Mon, Aug 12, 2013 at 4:29 PM, Tony Prisk <li...@prisktech.co.nz> wrote:

> I have noticed that on my Samsung 22" LED TV, the EDID/DDC reading is
> sporatic at best - Sometimes it's fine, other times it fails. Once it works
> at bootup, it seems to continue working though. On my old Acer 42" LCD TV, I
> haven't seen it fail yet from about 20 tries.
>
> Definitely seems like it could be a timing issue or signal level problem.

Should the I2C1 pull-ups be removed (the ones on the mx6 side - R111, R117)?

The i2c1 pads in the mainline kernel are setup as:

MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1

,where bits 14 and 15 specify the internal pull-up of the pad. In our
case we have '01', which corresponds to 47k pull-up.

Maybe we should also review the current i2c pad setup.

Regards,

Fabio Estevam

[John Weber]

In the vanilla kernel we have the I2C pad control set as follows:

#define MX6DL_I2C_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \
PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST | \
PAD_CTL_HYS | PAD_CTL_ODE)

Looks like 100K pullups, with Schmitt trigger inputs, and open drain.

Such a weak pullup in parallel with the 2K pullups on the board 'shouldn't'
affect the strength of the pullup very much. Removing the 2K resistors on the
board would not work. I2C needs a strong pullup and 50K/100K wouldn't do it.
We could try disabling the internal pullup for I2C1 just to see if that helps.

[nizamov...@gmail.com]

After playing with android images, switching displays etc, I accidentally came to the situation where my monitor would not be recognized anymore. I do not recoll that I did software changes, that's why I looked closer to schematics. I guess that I have found the reason for unstable DDC readout.

When the external display is not connected, sudo i2cdetect 0 (it is actually bus 1, not zero, but the numeration of i2c buses were changed in dts) does not find any active ic2 addresses (previously it would find several i2c addresses of my monitor). Most important here is the timing - this command scans all addresses very fast - in a couple of seconds. With the attached monitor, however, its operation is very slow (second per one address) what points to the timeout and wrong level issues on i2c bus.

Now the schematics of wandboard suggests that there is a level translator chip between imx6 i2c bus and external ddc - namely  TXS0102. This is because DDC has 5v levels and imx6 has 3.3 V levels. However, the monitor side of TXS0102 is not well terminated - 2.2K R289 and R291 are envisioned by schematics but not installed, and internal pullups of TXS0102 are just 10K. It is stated in datasheet that external pullups should be used if required. That means that wandboard side of DDC i2cbus is not pulled to the +5v as strong as it normally should be for the long cable. The bus between TXS0102 and imx6 is pulled correctly at least on one side and is very short.

So the solution seems to install R289 and R291, 2.2K each. They are placed near the edge of HDMI connector and are easily accessible.  However, soldering them might be problematic (smd) and it probably will avoid warranty. I did not tried it yet, but pretty much sure that this is a culprit.

What will wandboard engineers say?


Best regards,
S.Nizamov

[nizamov...@gmail.com]

Sorry, just noted that John Weber already pointed to it. Nevermind, there is definitively a timeout problem with attached HDMI cable so there might be some hardware problem.  

Best regards,
S.Nizamov