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.

DLPC3433: DLPC3433: What is register 0xBA

Part Number: DLPC3433
Other Parts Discussed in Thread: DLP3010

Hi,

I'm running Linux-5.13 on DLPC3433 with 720p DMD resolution timings. I did see the image color change in non working condition (like Purple Penguins) and working condition seems to be Yellow Penguins.

The only difference I can see in both the conditions is change in 0xba. Unfortunately I didn't see this register in Rev.D Software Programing guide

Any idea what this register is all about?

  • Jagan,

    The register you are referring to provides Auto-Framing Information such as the following metrics:

    > External VSYNC Rate

    > Total Pixels Per Line

    > Total Lines Per Frame

    > Active Pixels Per Line

    > Active Lines Per Frame

    > Reference Clock Rate

    You may perhaps be seeing a problem with your video input timings if this value is changing significantly. What are you changing on the host side (Linux)?

    Regards,
    Philippe

  • Philippe,

    I have DMD Panel timings on host side with 1280x720 resolution.

    static const struct drm_display_mode ti_dlpc3433_dmd_720p_mode = {
            .clock          = 117000,

            .hdisplay       = 1280,
            .hsync_start    = 1280 + 293,
            .hsync_end      = 1280 + 293 + 22,
            .htotal         = 1280 + 293 + 22 + 41,

            .vdisplay       = 720,
            .vsync_start    = 720 + 268,
            .vsync_end      = 720 + 268 + 3,
            .vtotal         = 720 + 268 + 3 + 201,
    };

    static const struct panel_desc ti_dlpc3433_dmd_720p = {
            .modes = &ti_dlpc3433_dmd_720p_mode,
            .num_modes = 1,
            .bpc = 8,
            .connector_type = DRM_MODE_CONNECTOR_DPI,
    };

    and the DLPC3433 bridge will initialize the registers based on this values.

    Do you see any issues on this?

    Jagan.

  • Jagan,

    Thanks for the input. Will take a look and provide feedback sometime in the next couple of days.

    Regards,

    Philippe

  • Phillippe,

    Just to add few more details, I can see some part of left side of the display is not covered.

  • Jagan,

    Thank you. Is the issue you are seeing content dependent (meaning, do you see different severity of video issues with different images on the screen)?

  • Yes, indeed. The moment I have Yellow Penguins during bootup(I have enabled DRM_LOGO). Look clear imaging expect left corner bar.

    On, the issue side I can see unclear image with same left corner bar during Purple Penguins at boot.

  • Jagan,

    In this case the issue is very likely a video/source problem (rather than a problem with the DLP EVM necessarily). How are you connecting the source (is it a Raspberry Pi) to the EVM? Are you using a ribbon cable?

    Regards,

    Philippe

  • Philippe,

    Yes, the ribbon cable. Means while do you have any working drm timings you setup?

    Jagan.

  • Jagan,

    The DLPC3433 datasheet features timing requirements for the input to the controller. I recommend you start there: https://www.ti.com/lit/ds/symlink/dlpc3433.pdf

    What host processor are you using?

    Regards,

    Philippe

  • Philippe,

    Does the datasheet has porch and sync values? can you point me on exact page number.

    We are using Allwinner R16

    Jagan.

  • Jagan,

    Yes. Please see section 6.12 of the datasheet "Parallel Interface Frame Timing Requirements".

    Regards,

    Philippe

  • Philippe,

    Yes, I can. Trying to find the proper timings based on it. By the way how much is the pixel clock range for producing 60Hz refresh rate?

    Jagan.

  • Jagan,

    The DLPC3433 controller supports a video pixel clock of up to 150 MHz (for all refresh rates).

    Regards,

    Philippe

  • Philippe,

    Using timings from datasheet with 60Hz then the associated clock is 56.3MHz

            .clock          = 56300,

            .hdisplay       = 1280,
            .hsync_start    = 1280 + 8,
            .hsync_end      = 1280 + 8 + 4,
            .htotal         = 1280 + 8 + 4 + 4,

            .vdisplay       = 720,
            .vsync_start    = 720 + 1,
            .vsync_end      = 720 + 1 + 1,
            .vtotal         = 720 + 1 + 1 + 2,

    This won't work on my platform. Only clock I can see work with is 117MHz. ie reason I have updated the timings.

             .clock          = 117000,

            .hdisplay       = 1280,
            .hsync_start    = 1280 + 293,
            .hsync_end      = 1280 + 293 + 22,
            .htotal         = 1280 + 293 + 22 + 41,

            .vdisplay       = 720,
            .vsync_start    = 720 + 268,
            .vsync_end      = 720 + 268 + 3,
            .vtotal         = 720 + 268 + 3 + 201,

    Do you think or test these timings from your side? any confirmation on something went wrong?

    Jagan.

  • Jagan,

    Could you break down these values for us?

    Typically, video timings are broken down to front porch, sync, and back porch (which comprise total blanking time), as well as the display time (which should be 1280 in this case for X). I'm not familiar with HSYNC_START and HSYNC_END variables.

    Regards,

    Philippe

  • Philippe,

    hactive = 1280

    hpf = 293

    hsync = 22

    hbp = 41

    vactive = 720

    vfp = 268

    vsync = 3

    vbp = 201

    Also we are writing hactive in Write Display Size (12h), do we have any register for htotal and front, back porch and sync values?

    Jagan.

  • Philippe,

    Here the exact problem in images.

    Case: 1
    Check the left side gap in boot penguins and kernel logs

    Case: 2
    Check the same left side margin gap while playing video.

    These images are with below timings.

    hactive = 1280

    hfp = 198

    hsync = 40

    hbp = 200

    vactive = 175

    vfp = 40

    vbp = 200

    clock = 117MHz

    vrefresh = 60Hz

    Jagan.

  • Jagan,

    We don't have a register that you need to modify for timing values such as porch and sync. These are automatically detected by the DLPC3433 controller.

    As for your selected settings, something looks wrong. You listed the vertical active as 175. Don't you mean 720 in this case? Are any other values wrong?

    Regards,

    Philippe

  • Hi Philippe,

    Yeah, it is 720 it's typo mistake. Sorry about it.

    Jagan.

  • Jagan,

    Thanks for the information. In the case above what is the VSYNC (line count)? That appears to be missing too.

  • Hi Philippe,

    I have further tweak of the timings. look stable but I still see that left margin.

    hactive = 1280

    hfp = 175

    hsync = 127

    hbp = 170

    vactive = 720

    vfp = 175

    vsync = 48

    vbp = 170

    clock = 117Mhz

    refresh rate = 60Hz

    Jagan.

  • Jagan,

    I was able to try these video timings using a video signal generator with the DLPC343 and can confirm that they work just fine as is. As such I would suspect that there is a video signal integrity issue in your hardware.

    I recommend verifying your connections and shortening them if possible. You could also consider boosting the GPIO drive strength of your parallel video output, if applicable.

    What does the signal output look like? 

    Regards,
    Philippe

  • Philippe,

    Thanks for testing. I don't have signal generator to verify it.

    But if you see the below picture you can identify the gap for logs position marked in red. This is what it shows a side margin while playing Video (See above case: 2 picture)

    Actually the Penguins and logs would cover that gap and appear to fill that gap to make it as full active space.

    This is the key reason for me to suspect it can be a timings issues still. Any possibility to verify that whether this kind of gap appear while testing your signal generator from your side?

    Apart from it, is any of System On Chip driver already tested this chip so-that I can look into Linux source code?

    Jagan.

  • Jagan,

    I'll see if we can find any image artifacts with our test pattern generator + your timings (though I haven't seen anything yet). Is it possible to test your system with standard CVT timings? Those may be more stable for your application.

    Alternatively, you could also try using a laptop with customized video timing outputs over HDMI (with the DLP3010 EVM, for instance) to take your SoC out of the equation. Are you using a custom DLPC3433 board design?

    Regards,

    Philippe

  • Jagan,

    I tried a pattern like what you shared (small font characters on a screen) both in motion and static, and was not able to detect any visual artifacts (or color defects) with the timings you are using. 

    Any updates on use of an alternative video source (such as a laptop) for your display?

    Regards,

    Philippe

  • Philippe,

    Do you mean HDMI out on the board instead of projector output?

    Jagan.

  • Hello Jagan,

    The alternative video source that Philippe mentions above would be either a video generator or computer acting as a front end that would be connected to your display through an HDMI port. He has suggested this to determine if the video front-end is the root of this issue.

    Regards,

    Austin