• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 34 subscribers
  • Views 170 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SN65DSI84: invalid LVDS syncrhonization, LCD flickering or no VSYNC signal

Enne Bi
Prodigy 15 points
Part Number: SN65DSI84

Tool/software:

Hello everyone.

We are experiencing an LCD syncrhonization issue that causes LCD flickering or no video on an LVDS LCD screen, depending on the display timing configuration.

The application is converting the MIPI-DSI signal from an i.MX 8M Mini processor to the SN65DSI84 LVDS bridge on a VAR-SOM-MX8M-MINI Variscite SOM. It works with some LCD displays, but we are unable to configure the interface in a way that precisely matches the device tree.

 

The I2C registers are all verified against the given device tree panel section. The test pattern works without any issue just by setting CHA_TEST_PATTERN (any other register gets configured at drive probe phase).

The application uses a single DSI channel, 4 lanes, and a single LVDS output, RGB888.

We already asked for help about the configuration of the MIPI-DSI side on the SOC manufacturer's forums. But here we hope to get some suggestions about what could cause the issue on the bridge side.

 

The LCD is a 1280x800px with a pixel clock set at 72.4MHz.

Register settings

  • ACTIVE_LINE_LENGTH: 1280 / 0x500
  • VERTICAL DISPLAY SIZE: 800 / 0x320
  • SYNC_DELAY: 33 / 0x21
  • HSYNC_PULSE_WIDTH: 40 / 0x28
  • VSYNC_PULSE_WIDTH: 15 / 0x0F
  • HORIZONTAL_BACK_PORCH: 40 / 0x28
  • VERTICAL_BACK_PORCH: 14 / 0x0E
  • HORIZONTAL_FRONT_PORCH: 80 / 0x50
  • VERTICAL_FRONT_PORCH: 9 / 0x09

 

This is the I2C dump:

~#i2cdump -y -f 0 0x2c
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 35 38 49 53 44 20 20 20 01 00 85 10 00 01 00 00    58ISD   ?.??.?..
10: 26 00 2c 00 00 00 00 00 18 05 03 00 00 00 00 00    &.,.....???.....
20: 00 05 00 00 20 03 00 00 21 00 00 00 28 00 00 00    .?.. ?..!...(...
30: 0f 00 00 00 28 00 0e 00 50 00 09 00 00 00 00 00    ?...(.?.P.?.....

The DSI Tuner matches the configuration in Device Tree, except we're trying to locate the information about the MIPI-DSI clocks that seems automatically generated by the driver but they are not reported in the clock tree.

We deserialized the LVDS signals, and we discovered that:

  • The LVDS clock exactly matches the pixel clock frequency
  • Horizontal and vertical pulse witdh are the same as configured in DT
  • Horizontal and vertical back porch timings are as configured, together with vertical front porch
  • Horizontal front porch timing is NEVER respected, even when a certain configuration works, it's because the output is within the LCD tolerance.
  • By slightly changing the configuration (basically the LCD clock or some the other timings, still within LCD tolerances) we experienced unpredictable changes on the LCD signals, up to the VSYNC pulse disappearing completely.

 

Just as an example, in the following diagram the blue line (C2) is the DE signal, while the red (C3) is HSYNC.

HFP has been programmed to 48, HBP to 80. HBP is respected, while we measure HFP to be around 135 pixel clocks instead of 48.

Siince the Linux driver is taking care of configuring both the LVDS and the MIPI-DSI timings, we kindly ask if anyone ever experienced the same issue, or if you have hints on what could cause it or where we should investigate.

  • 0
    TI__Expert 3223 points

    Hi Enne,

    Thanks for sharing your issue.

    Can you elaborate on what the 'device tree' is you are referring to?

    I would try the following steps:

    • Ensure you are following the power-up sequence in the "Recommended Initialization Sequence" of the datasheet
    • Operate within the line time requirement
    • Recommend following App note SLLA356 "Troubleshooting SN65DSI8x"

    Thanks,

    Ragav  Subramanian

  • 0 in reply to Ragav Subramanian
    Prodigy 15 points

    Hello Ragav,
     thank you for your interest in this.

    I generically used the term "device tree' to indicate that what I am expecting from the configured Linux sources matches the chip level registers I am reading back. I'm not expecting to get deeper in the kernel driver here.

    The issues appears to be related to the line time requirement. According to SLLA356 and SLLA332B (SN65DSI8x Video Configuration Guide), "The line time (horizontal sync to the next horizontal sync) on the input must match the line time on the LVDS interface.".

    From my understanding, the statement implies that the SOC LCDIF pixel clock must be the same in the all chain up to the LVDS bridge. The kernel driver does not enforce the requirement and the match needs to be manual. In the kernel version in use, the PLL configuration in this chain may not allow a fine adjustment (while the hardware design allows it to be precisely tuned).

    What is happening here is that the processor makes use of a pixel clock that can be different (and in this case, it is) from the actual  DSI CLK clock that is used as a reference for LVDS pixel clock source (integer divider in the SN65DSI84). I was expecting the two pixel clocks to be interdependent, but I am measuring an actual pixel clock on the LVDS output that is different from the DSI pixel clock that I read back from the clock debug information from sysfs.  I was not expecting this to be possible and I am still investigating to have a better understanding of the clock paths within the SOC.

    With the sentence "the DSI8x does not realign timing, so if the line time is different then there will be issues.", is it possible that, under certain circumnstances, the IC may be just cause jittering on the sync signals and work or not depending on the tolerance of the LCD hardware?

    If there are no additional consideration and our assumption is correct, I will accept the suggested solution.

    Thank you!

  • 0 in reply to Enne Bi
    TI__Guru** 107710 points

    Hello Enne,

    Ragav is OoO and should be back tomorrow.

  • +1 in reply to Hamzeh Jaradat
    TI__Expert 3223 points

    Hi Enne,

    Enne Bi said:
    What is happening here is that the processor makes use of a pixel clock that can be different (and in this case, it is) from the actual  DSI CLK clock that is used as a reference for LVDS pixel clock source (integer divider in the SN65DSI84). I was expecting the two pixel clocks to be interdependent, but I am measuring an actual pixel clock on the LVDS output that is different from the DSI pixel clock that I read back from the clock debug information from sysfs.  I was not expecting this to be possible and I am still investigating to have a better understanding of the clock paths within the SOC.

    This difference in PCLK from SoC and Serdes would surely cause issues on output. Please align the serdes PCLK with DSI clock speed/PCLK from SoC for proper functionality.

    Enne Bi said:
    With the sentence "the DSI8x does not realign timing, so if the line time is different then there will be issues.", is it possible that, under certain circumnstances, the IC may be just cause jittering on the sync signals and work or not depending on the tolerance of the LCD hardware?

    Yes, with misaligned timing the IC may cause jittering and if the misalignment does not fall within the LCD tolerance, then there may be no display altogether.

    Please try to see if you can align the timing and follow-up with the outcome.

    Thanks,

    Ragav Subramanian

  • 0 in reply to Ragav Subramanian
    Prodigy 15 points

    Hi Ragav,

     we will investigate further about the reasons why the bridge and DSI drivers allow to set a (limited number of) mismatching clock speeds and how the patches applied to newer kernel versions address the issue.
    We confirmed that, for the clock speeds we were able to test, if the DSI and the pixel clock are corresponding, the image on the LCD is displayed correctly.

    Thank you for you support!