TMDS181: Pin Settings - confirmation requested

Buso

1. When I2C_EN is high, functions that are previously controlled through the pin strap mode can only be controlled through I2C interface.
2. For DDC snoop mode, where the DDC lines are only connected to the TMDS181 SCL_SNK / SDA_SNK, the SCL_SRC / SDA_SRC lines are grounded to prevent noise from being interpreted as traffic and driven to the sink.
3. Register can still be read even I2C_EN is low.
4. Please see my response to question #2, you want SCL_SRC/SDA_SRC to be grounded so the noise will not be interpreted as actual traffic.

Thanks
David

Thank you,

following up on a couple of questions:
1. If I had left the TX_TERM_CTL as NC (Auto Select), and pull I2C_EN to HIGH, the value I read from the registers 0Bh for TX_TERM is 00 *no termination", So do I take it the pin strapping is not read in in this case?

2. I have tried to leave the I2C_EN pin input as LOW and tried to just read the registers (using Aardvark), but I cannot do that. Am i missing some settings that would allow me to do this?

3. These questions kinda set the context of a more important questions - similar to the following

e2e.ti.com/.../626622
e2e.ti.com/.../595650
and especially this one
e2e.ti.com/.../772037.

my board has an issue switching from 4K30 to 4K60, with certain sources (graphic cards)
It appears that the HDMI Receiver is unable to lock - keeps trying (based on the trace from the receiver)

Original assumption was SI, and a repeater placed in front of TMDS181 appears to solve the issue.

This is certainly not a solution for us. Our SI has been checked and checked.
The theory is that for some reason, the retimer gets into some unknown state.

All the three threads I listed above are locked and appeared to be solved, but I don't know how it was solved.

any insight you can share?



- jj

JJ

1. TX_TERM_SEL bits will reflect the TX_TERM_CTL pin only when I2C_EN = 0. Please note that TX_TERM_SEL pins will automatically switch between the termination depending on HDMI 1.4 or HDMI 2.0 when it is NC. But when in I2C mode, TX_TERM_SEL bits have to be set manually between HDMI 1.4 and 2.0.

2. If I2C_EN is high, are you able to read the I2C register?

3. When switching from 4K30 to 4K30, are you toggling HPD_SNK pin or PD_EN bit?

Thanks
David

David,

I am able to read the I2C registers with both I2C_EN High and Low, so that is a good thing for our debug.

switching from 4K30 to 4K60 and vice versa, we toggle HPD_SNK, as we are not doing anything with the I2C bus (TMDS181) - we just strap them low with all configuration hard wired.
This also means we do not toggle the PD_EN bit.

May I also ask about the SIG_EN signal?
When it is enabled (by pin strapping), under what condition would it disable the TMDS181 (regardless of the HPD_SNK toggling)? Is there any timing spec related to this power saving feature?

In the other threads, how were the issues resolved?

thanks
jj

David,

let me try my theory on that SIG_EN activation.

IF SIG_EN is activated (pulled up), and TMDS181 is put in stand by mode, it will need some time to 'wake up", right?
If the source is switching between HDMI1.4 to HDMI2.0, by the time it sends HDMI2 traffic, is it possible that TMDS1 has not exited this stand by state yet? In which case, could it miss the CLK_RATIO bit write?

The reason I suspected this is because when we pull this pin low (disabling this feature), our switching issue seems to be non-existent.


jj

JJ

When SIG_EN is enabled, the TMDS181 looks for a valid TMDS clock signal input. The device is fully functional when a valid signal is detected. If no valid TMDS clock signal is detected, the device enters standby mode waiting for a valid signal at the clock input. The internal CDR is shut down and all of the TMDS outputs are in high-Z status.

So It depends on the source behavior when switching between HDMI 1.4 to HDMI 2.0. By spec, the clock supposed to stop when switching from HDMI 1.4 to HDMI 2.0.

But when SIG_EN is enabled again, you do need time for the CDR to lock.

Thanks
David

Thank you, David

Do you any timing information, in terms of how long before the CDR goes to stand by, and how long it takes to come out of standby (time for the CDR to lock)?

- jj

JJ

That will be the Input clock frequency detection and retimer acquisition time, which is typical of 180us.

Thanks
David

David,

We found that disabling clock detection for power saving (pulling sig-en low) appears to solve our issue, meaning, our HDMI receiver is locks to clock and data consistently when we switch from 4k30 to 4k60.

I don't understand why.

I know that our source has a short 'no clock' period (<40 ms), but that should be a sufficient time to exit.

Can you enlighten me as to other impact this signal detection has?

- julia

One more thing, David.

Are there registers (not in the datasheet) that we can check for 'lock' indication"

- jj

JJ

Bit 7 of register 0x00h of Page 1 (Accessing by write 0x01b to register address 0xFFh) is PLL_CLOCK lock indicator.

But there is no CDR lock indicator bit.

Thanks
David

Hi JJ,

1). Bit 7 of register 0x00h of Page 1 (Accessing by write 0x01b to register address 0xFFh) is PLL_CLOCK lock indicator. But there is no CDR lock indicator bit.

2). When switching between 4K30 to 4K60 does data rate changes? I am thinking perhaps there is a data rate change but no loss of signal between on incoming data when we change between these two frames. Is this possible?

Regards,,nasser

Thank you, David, Nasser,

My colleague's original suspicion was along #2: source did a datarate change without stopping and instead of locking to a new clock, TMDS181 kept the lock on the old clock. This made a lot of sense.

however, given that we see no failure now that we strap SIG_EN low, that theory seems to be contradicted.

Any idea why disabling SIG_EN helps in this case?

I am looking for some logic behind whether it makes sense or whether it is senseless.

-JJ

JJ

Can you probe the input of TMDS181 and see if there is no loss of signal when data rate changes?

Thanks
David

David,

I am not sure "when data rate changes" exactly, but there does not seem to be, looking at the input signals.

See the snapshot attached. From the top, we have CLK_IN, Data_IN, Data_Out, CLK Out

Note that when HPD deasserts, we see the Output pauses, yet the Input continues until just before the second pause

There is also that curious period where input clk and data appear to be changing, but reverts back after the pause

Any thought?

-jj