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.

SN65DSI86: DPTL_LOSS_OF_DP_SYNC_LOCK_EN

Part Number: SN65DSI86

Dear team,

thank you for your support so far.

We have a board with a i.MX8M Mini SoC connected to the SN65DSI86.

We are running Linux on the SoC, with a modified version of the upsteram driver for the SN65DSI86. All is well at boot (we detect the HPD event, we successfully read the EDID, and we setup the display according to the preferred modeline provided by the display via the EDID).

We are now testing a dynamic resolution change at runtime. The application we are using for this test is modetest. Half the times we change the resolution we lend with a working monitor, but occasionally we might get:

  • a blank screen with an active monitor (backlight on),
  • a blank screen with monitor not active, or
  • a partial picture

The SN65DSI86 is reporting bit 6 (LOSS_OF_DP_SYNC_LOCK_ERR) from register 0xF6, what could lead to this error, any ideas?

Any help very much appreciated.

Thanks,

Fabrizio

  • Fabrizio

    The error at register 0xF6 will be reported when the video timing programmed into the DSI86 doesn’t match with the timing received on the DSI interface. Can you please check the DSI86’s video registers located from 0x20 thru 0x3A and make sure they match the video timing used by the DSI source?

    Thanks
    David

  • Hi David,

    Thank you for your feedback.

    Registers 0x20~0x3A seems to match the video timings used by the DSI source, and there doesn't seem to be a difference (in terms of register values) between a successful case and an unsuccessful one (black screen, broken picture, or monitor rejecting the mode). Can this somehow due to timings with the register writes?

    Thanks,

    Fab

  • Fab

    Are you following the power-up sequence at section 8.4.2?

    Can you map the HSNYC and VSYNC to the GPIO and use a scope to measure the HSYNC/VSYNC between the passing and the failing case?

    If you enable the color bar, does the color bar work consistently all the times?

    Thanks

    David

  • Hi David,

    thank you for your reply.

    The driver is following the power-up sequence at section 8.4.2, but after reviewing it, I have a doubt w.r.t. steps 18 and 19. The display pipeline is mainly made of 3 components in my case: LCD controller=>MIPI DSI controller=>DSI86.

    The MIPI DSI controller completes the enabling phase before the DSI86, and the LCD controller completes the enabling phase after the DSI86, therefore I think I should try and delay VSTREAM_ENABLE to after the LCD controller has finished doing its thing.

    No luck with the GPIOs, they are used to setup the clock.

    I have played a little bit with the colorbars, and it looks like they are consintent, all the time, which is interesting indeed, so perhaps we are not fully compliant with section 8.4.2 after all (step 18 and 19?).

    Thanks,

    Fab

  • Fab

    Yes, I would hold off from setting the VSTREAM_ENABLE bit until both the LCD and MIPI DSI controller complete their enabling phase. 

    From the color bar experiment, the issue looks more on the DSI interface, the DP interface looks to be OK.

    Thanks

    David

  • Hi David,

    thank you for your support.

    We should be getting a new PCB with better signal separation on the DSI lanes in 2 or 3 of weeks.

    I'll keep this thread open for now, and I'll get back to it with more information once I am able to re-test this on the new HW.

    Thanks,

    Fab