We’re making LVDS out of the imx8 HDMI signal to feed an LCD and the HDMI signal does produce a data enable high period within the VSYNC pulse (according to HDMI spec these should be data island, or audio packages). See attached image for Reference (bottom is a zoomed version of the start of the vsync pulse visible also in the top waveforms):
We did disable HDMI sound in the device tree (in both files: fsl-imx8qm-apalis-v1.1.dtsi and fsl-imx8qm-apalis-eval.dtsi) and no hdmi sound device is showing up anymode by alsa/pulseaudio but this data enable period is still present, is there anything we can do to get rid of it?
Thank you for using the Toradex Community page. Looking at your waveforms, it seems that the polarity of the data enable signal is wrong.
The timings and signal polarities of the LVDS interfaces are not really standardized. For most displays, the data enable signal is active high. This means the signal needs to be high during the active time of the horizontal line and low during the front and back porch of the signal. Some displays use only the data enable signal for synchronization and ignore the HSYNC and VSYNC signals.
Since the polarity of the data enable and the sync signals are not standardized, there must be a way to configure it. Does your bridge have an option to change the polarity? Does it have a setting register or a strapping pin for that?
Unfortunately, I am not an HDMI expert. Therefore, I am not sure how transparent an HDMI to LVDS bridge is. If you are not able to find a polarity setting in your bridge, It might be worth looking into the HDMI timing settings. Maybe there is a polarity setting there.
good idea, but sadly the polarities are OK. That was the very early issues we had. The DE signal is active high in this picture, but it should stay low (data not enabled) during the whole VSYNC pulse (what we see zoomed in the picture). The DE high period i marked should not be present. We have a perfect picture on our LCD with another source that produces an exact equivalent waveform but without the DE high pulse during VSYNC. There must be a way to disable whatever is sent there (at least I hope so) but I cannot make my mind on how…Do you have any idea where such things might be hidden inside the Yocto layers of drivers…?
We would be extremely grateful for any ideas.
We also tried to mask out the pulse via hardware gates, but unfortunately the introduces propagation delay of around 2ns already destroyed the signal.
It seems like you need to really alter the timings by yourself (VPORCH, HPORCH values). And this information can usually be found on the documentation of the IC that you use. Could you please tell us which IC you are using or alternatively, send us a link to the Datasheet?
Hello,
porch times are correct, with a laptop configured to have exactly the same porch times and it works. We need to get rid of the marked data enable spike. This is the only difference between the working and non working signal.
Thank you for the suggestion. As for clarification: we do a HDMI to RGB translation, and then RGB to LVDS using the combination of a TPG401A and a DS90C387 and the measurted courve is coming from a LVDS to RGB de-serializer to make sure nothing is lost on the RGB-LVDS translation.
Hello @mwagner,
I have been studying your problem description, and I saw some things I want to confirm:
It seems to me that the chip that is generating the DE signal is the TFP401 (https://www.ti.com/lit/ds/symlink/tfp401.pdf), and it is doing it based solely on the HDMI signals, right?
I looked at the datasheet to find out how this chip generates the DE signal, and the information I could find is this:
So it seems that the chip should be able to automatically identify the presence of the blanking time to drive the DE output.
Based on these descriptions, it seems that the only thing that should matter to the DE output is the combination of the existence of the VSYNC / HSYNC pulses, the HDMI timings (I would assume that the TFP401 is able to detect the preamble packets for the active video area, otherwise how could it be able to detect the video?), and possibly the existence of the data island. As you already mentioned that you removed the audio configuration, I can’t think of anything else that could be going wrong.
porch times are correct, with a laptop configured to have exactly the same porch times and it works.
When you mention that it works with the laptop you mean that the laptop is connected to your TFP401 → DS90C387 and it drives your display properly?
Does this spurious toggle of the DE signal happen on every frame together with the VSYNC?
As an additional question, what’s the reason for not using the Apalis LVDS output to drive this display directly?
Thank you in advance for the information,
Rafael Beims
thank you very much for your detailed answer. Although I personally was in parental leave during the last month my colleagues were able to solve this issue with a new kernel version. Since then the unwanted pulse was gone and everything works fine now.
For answering your question why we’re not using the APALIS LVDS output: We’re having the option of a 3 meter video cable and are able to hot plug the display in our device, so LVDS is not an option because of too many data pairs.
Thank you very much for all of your kind suggestions and help!
Moritz Wagner
Hi @mwagner,
Thank you for your feedback. Could please provide us with what kernel version solved the issue?
In the end, what was the complete solution?
Is it just the new kernel and removing the audio HDMI components?
after catching up with my colleague I can tell the following:
He used the boot2Qt image for QT version 5.15.2 and updated it manually to yocto dunfell. The kernel version is now:
Linux b2qt-apalis-imx8 5.4.129-0+git.cb88cc157bfb #1 SMP PREEMPT Wed Sep 29 18:17:21 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
And HDMI audio is not explicitely disabled, it worked right out of the box with this kernel.
