• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 102 subscribers
  • Views 276 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

PROCESSOR-SDK-AM62X: AM62x dss pixel shift

Tran Thang
Prodigy 120 points
Part Number: PROCESSOR-SDK-AM62X

Tool/software:

Dear TI expert.

In our system using AM62x. We use LVDS->GMSL serializer ->GMSL Deserializer device, DPI->GMSL serializer -> GMSL Deserializer device. We met the issue that the pixel in LVDS is shift to left by 1px. We can correct it by plus hfp (horizontal front porch) to 1 and minus hpb (horizontal back porch) to 1, But then DPI is shifted. So my question is:

Any requirement to choice value of hfp hpb and h syn length ?.

Is it normally when we plus hfp and minus hbp it effect to visiable image ?

Do you have any ideal about the reason that can cause the pixel shift ?

Thanks for your support.

  • 0
    TI__Guru**** 168594 points

    Hello Tran Thang,

    Thank you for the query.

    I need to check internally if we have interfaced with the GSML serializer and have some thoughts

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Prodigy 590 points

    Hi,

    Can you confirm one pipeline is being used to feed both displays? If so, the timing should be identical between DPI and LVDS. Can the LVDS pixel output shift issue be fixed in the serializer itself? Also, if you view DPI and LVDS natively (serializer bypassed) - do you still have the pixel shift issue for LVDS?

    Best regards,

    Luis Parga

  • 0 in reply to Luis Parga
    Prodigy 120 points

    Hello

    The issue only occurr on custom GMSL Deserializer device . We use graber card to test and don't have this issue.

    The LVDS use plan1, overlay layer 0. DPI use plan0, overlay layer 0. We check DSS_VP_TIMING_H and DSS_VP_TIMING_V it have same value in two channel.

    We have two phase Splash screen (on M4) and Linux. In Linux LVDS and DPI also shift by 1 px but we can adjust it  by add hfp by 1 and minus hbp by 1. But in splash screen, the workaround not working for LVDS (DPI worked).

    We compare some register and make registers setup in Splash screen the same as Linux. But LVDS not working.

    The list of register that we check is:

    VP_DSS_OLDI_CFG
    VP_TIMING_H
    VP_TIMING_V
    VP_POL_FREQ
    VP_SIZE_SCREEN
    VP_CONTROL
    OVR_ATTRIBUTES
    VID_SIZE
    GLOBAL_MFLAG_ATTRIBUTE
    VP_CONFIG
    VID_ATTRIBUTES

    Can you guest some other register that we need to check to make sure LVDS in splash screen working as Linux?

  • 0 in reply to Tran Thang
    TI__Guru**** 168594 points

    Hello Tran Thang,

    Let me follow-up with Luis and update you.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Prodigy 590 points

    Hi Tran,

    Can you confirm both the programming of the custom GMSL Deserializer device and the timing it expects are correct?

    Best regards,

    Luis Parga

  • 0 in reply to Luis Parga
    Prodigy 120 points

    Hello, our GMSL Deserializer work on Linux and when we swap Deserializer of DPI and LVDS the DPI site still have output and LVDS still don't. So we think the our GMSL Deserializer not have problem in setting.

  • 0 in reply to Tran Thang
    Prodigy 120 points

    Hello I update some test:

    Remove DSS_VID_BA_0 so Linux will show image from M4F buffer-> two channel have output, so the data in buffer of M4 not have problem

    Remove GMSL driver in Linux, all GMSL config done in M4-> two channel have output, so GMSL config have no problem

    We also try m4 with only LVDS and try swap plane of LVDS and DPI -> both case don't have LVDS output (if image from LVDS be shifted our deserializer device will not show it)

  • 0 in reply to Tran Thang
    TI__Guru**** 168594 points

    Hello Tran Thang,

    Thank you.

    Luis Parga, any thoughts please.

    Regards,

    Sreenivasa