Hello @matthias.tx
I would like to know if there was any progress in the analysis of this problem?
Best Regards,
Christian
Hello @C_Mueller,
unfortunately, there’s not much new that can be reported. However, what I found so far is that there’s a way for HDMI cables to be detected independently of the HPD pin. This is called HDMI rxsense (brief discussion here), and it doesn’t seem to be part of the standard but also seems to be a very widely used way to detect whether the cable is plugged in or not. I can’t confirm if this is the cause of the clock running even when the cable is unplugged or not, but it seems likely that it is.
I was looking for a way to disable this so that we could test your setup and see if it makes a difference, but so far I couldn’t find anything. I plan to still check a little more to see if there’s any way to disable this feature and check if the clock indeed stops or not.
On the other hand, the fact that this feature exists and seems to be used (and even important) makes me wonder if this would be the reason for the converter to fail (I would expect converter chips to be able to cope with this considering is a known feature). In any case, if we don’t manage to disable the feature, it will be difficult to test.
Regards,
Rafael
can you provide your schematic at least the part of the Display USBC and conversion part.
best Regards,
Matthias
Our display specialist isolated the problem and striped the circuit down to the HDMI to DP chip (even before the USB).
I sent you the eval board schematic of the chip on the 21.12.2023. In case you haven’t received it I attach it here:
LT6711A_HDMI2DP_RELEASE_V3.pdf (53.5 KB)
If I remember our teams discussion correctly one person from Toradex in the call (I can’t remember who) mentioned a similar problem with a different customer (with a NXP chip).
Regards,
Christian
I like to set up a call with you and our team. But here a summary of what we suggest.
This is what we found so far.
However, what I found so far is that there’s a way for HDMI cables to be detected independently of the HPD pin. This is called HDMI rxsense (brief discussion here ), and it doesn’t seem to be part of the standard but also seems to be a very widely used way to detect whether the cable is plugged in or not. I can’t confirm if this is the cause of the clock running even when the cable is unplugged or not, but it seems likely that it is.
We will check with NXP since we have no information if the rx sense can and if how be disabled.
Since the LT6711 "is a deeply-optimized HDMI re-driver IC that enhances TMDS signal quality by performing cable or board trace loss compensation. " it seems that the chip is trying to retrieve some signal as long as the clock is present. This is probably the cause why the chip does not shut down.
On the the verdin developer board we have a jumper for the HPD line. When we connect a display and we remove the jumper (simulate a disconnect) we still see the clock after that (what seems to be the rxsense) but the display shuts down properly. which is not the case for the LT6711 chip.
One test could be to use a HDMI switch between and switch it to a different port to see if this would have the same result as unplugging.
Best Regards,
Matthias Gohlke
Here is some information about the findings to complete the documentation here in the community.
So the Problem here was that the driver did not stop the HDMI clock output when the HPD pin was pulled low but the HDMI was still plugged in. The question might arise why pull the HPD pin low to trigger a Hot Plug Detect event but leave the HDMI connector connected? Well, there are use cases where HDMI output into a DisplayPort (DP) converter and you trigger the HPD signal via the DP connection. So the HDMI lanes are permanently connected with the HDMI to DP converter.
FIX:
We have a patch that removes the clock from the line when the HPD pin is changed. in this case her kernel 5.15 was used. The change was merged into our downstream branch. Its on our public git for them to test: It is fixed in BSP 6.6
https://git.toradex.com/cgit/linux-toradex.git/commit/?h=toradex_5.15-2.2.x-imx&id=e63f274c8b6ecab8d94cfc53aa58744ffac97f8c
Best Regards,
Matthias