• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 3910 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.

AM5728: HDMI interlaced format support

Chris Anderson20
Intellectual 690 points
Part Number: AM5728

We have a requirement to output 1080i, NTSC, and PAL interlaced video to the DSS HDMI port on our AM5728-based streaming appliance using SDK 02.00.01.07 and kernel 4.1.13.

It appears that DSS interlaced format support exists for LCDs but not HDMI - by default, all EDID-enumerated interlaced formats on HDMI fail a timing check in hdmi5.c. 

If the interlace conditional next to the comment "TODO: proper interlace support" in hdmi_display_check_timing() is removed, interlaced output is enabled but incorrect (at least when supplying strided, field-merged buffers):

  1. 525i and 625i generate bad video output timing.
  2. One of the fields in 1080i is vertically offset by ~2 pixels.
  3. Field dominance is scrambled; it alternates between being off by 1 or 2 fields, causing jitter and striping artifacts.

How do we get these problems corrected?

  • 0
    TI__Guru*** 125430 points

    Can you migrate to Proc SDK 3.02?  I see patches for interlaced HDMI were added to the 4.4 kernel.  Alternatively you could try pulling in some of the patches.  There was a lot of work done around display/HDMI for the 4.4 kernel though, so you might have better results by making the full migration.  Here are a couple pertinent patches:

  • 0 in reply to Brad Griffis
    Intellectual 690 points

    Thanks for the info on the patches. 

    Migrating to the new kernel/SDK is not really an option for us at this time - we've made a lot of mods to other components that would need to be migrated as well.

    I'll have a go at retro-fitting - if you have pointers to any other relevant changes, please provide them.

  • 0 in reply to Chris Anderson20
    TI__Guru*** 125430 points

    Actually, better yet, I see these patches are already integrated into the TI 4.1 kernel source tree:

    http://git.ti.com/ti-linux-kernel/ti-linux-kernel/commits/ti-linux-4.1.y

    You might want to rebase whatever work you've done on top of the latest of that tree above.  Alternatively, if you look at the commit history for some of the main display-related files (such as drivers/video/fbdev/omap2/dss/hdmi5_core.c) you can pluck some of the patches and apply them to your tree.

  • 0 in reply to Brad Griffis
    Intellectual 690 points

    Thanks - that was very helpful. Going through the commit logs for the 4.1.y branch I've been able to merge all of the relevant changes, which address all but one of the HDMI-out interlaced display problems we are having.

    The remaining issue is that the fields do not always get correctly timed when send to the HDMI output. That is, some frames look OK, but then for awhile the interlaced output will alternate fields from two different frames, causing a jitter effect, then go back to the correct behavior again. The effect is cyclic, so would seem to be the result of a beat frequency between different sampling clocks.

    We know that the interlaced buffers contain the correct fields because they are shared with the H.264 codec, and its encoded field-separated output is correct. Since we are using merged buffers, the problem would seem to be in the output driver path; it looks as if dominance flags are not being respected or the paired fields, when output, are not required to be DMA'ed during the same frame interval.

    How do we resolve this last problem?

  • 0 in reply to Chris Anderson20
    TI__Guru*** 125430 points

    Please list the commits you have integrated into your kernel.

  • 0 in reply to Brad Griffis
    Intellectual 690 points

    OK, here are all the commits that I merged over to our kernel. My method was to look for descriptions that mentioned interlace or the DSS HDMI out and review the message for relevance, look for associated dependencies and check other commits by the same author over a similar date range, and pull anything that seemed potentially relevant into our build.

    commit 2a51690d469d73b2415ec8c47c4fc270d3bfa0c6
    Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Date: Tue Jan 5 11:43:13 2016 +0200
    OMAPDSS: work-around for errata i886

    commit 7cb311429aadd70fa08f1fa988161e287c11bf62
    Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Date: Wed Jan 13 18:41:36 2016 +0200
    OMAPDSS: DISPC: Fix field order for HDMI

    commit dd0dd0adbedd1c0e3427a3a305eae22b41704857
    Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Date: Wed Jan 13 18:41:35 2016 +0200
    OMAPDSS: HDMI: fix WP timings for ilace

    commit 0344a0081ffc2f9b19fc41b4af47950be11cdcaa
    Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Date: Wed Jan 13 18:41:32 2016 +0200
    drm/omap: support double-pixel

    commit a831e396b5f60425929cd9cb5c9e26480aacecef
    Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Date:   Wed Jan 13 18:41:31 2016 +0200
    OMAPDSS: DISPC: support double-pixel mode

    commit 0c3f1396d5e87c680af513b1e6ee4a8bdc13091c
    Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Date: Wed Jan 13 18:41:40 2016 +0200
    OMAPDSS: HDMI5: allow interlace

    commit e8a4c48d31b0efccc3acca2056fc9b3f296ac6de
    Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Date: Wed Jan 13 18:41:33 2016 +0200
    OMAPDSS: HDMI: support double-pixel pixel clock

    commit 3460911b548ffaf7dba06eed3d6e9fc3f8a172d0
    Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Date: Wed Jan 13 18:41:39 2016 +0200
    OMAPDSS: HDMI5: Add interlace support

    commit b7230ca5edd64674c57580f817556274298eaaf8
    Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Date: Wed Jan 13 18:41:38 2016 +0200
    OMAPDSS: HDMI5: clean up timings copy

    commit a37477a65e33e584e1a86fcb6ecab9cde3b6a3c2
    Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Date: Wed Jan 13 18:41:37 2016 +0200
    OMAPDSS: HDMI5: Fix FC HSW value

    commit 9f5ec00966c8bfa2098424a55647f413e6af4cf3
    Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Date: Tue Jan 19 13:44:40 2016 +0200
    OMAPDSS: remove unused dispc_ovl_check

  • 0 in reply to Brad Griffis
    TI__Mastermind 22946 points

    Hi Chris,

    Interlace support in DSS driver is not mature. As you have noticed, the driver expects progressive frame (meaning cannot except fields input) and then display alternate lines from that input frame to display interlace output. Problem is that SW only sees vblank event, and both even and odd interlace field gives the same event. So SW doesn't have mechanism to know which field is being shown. If the SW changes the input frame on every vblank (or every other vblank)and then misses one vblank event, the interlace output's field ordering will obviously change. This might be the issue you are facing.

    Currently omapdrm reacts to both ODD and EVEN irqs. So when the app does a page flip, it can happen on either. If omapdrm is changed to react only on EVEN or ODD, then the field ordering should stay same. This approach has drawback that if you show normal progressive frame on interlace output. you will only get half the framerate. And in some scenario, the app would need to change the field where the page flip happens.


    You can try this hack to see if it helps -
    This is for 4.9, but it should be very similar on earlier kernels too:

    diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c b/drivers/gpu/drm/omapdrm/dss/dispc.c
    index fa404939ba8a..7d1e9781c666 100644
    --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
    +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
    @@ -224,7 +224,7 @@ static const struct {
    },
    [OMAP_DSS_CHANNEL_DIGIT] = {
    .name = "DIGIT",
    - .vsync_irq = DISPC_IRQ_EVSYNC_ODD | DISPC_IRQ_EVSYNC_EVEN,
    + .vsync_irq = /*DISPC_IRQ_EVSYNC_ODD |*/ DISPC_IRQ_EVSYNC_EVEN,
    .framedone_irq = DISPC_IRQ_FRAMEDONETV,
    .sync_lost_irq = DISPC_IRQ_SYNC_LOST_DIGIT,
    .gamma = {

  • 0 in reply to Manisha Agrawal
    Intellectual 690 points

    Unfortunately this change, as you mention, causes all progressive formats to display at half frame rate. It also does not account for the field dominance reversal between NTSC and the other interlaced formats.

    We need to be able to freely switch between all progressive and interlaced output resolutions/modes and have them work correctly - is this unsupported?

  • 0 in reply to Chris Anderson20
    TI__Mastermind 22946 points

    Chris Anderson20 said:
    We need to be able to freely switch between all progressive and interlaced output resolutions/modes and have them work correctly - is this unsupported?

    Yes, this isn't supported. Interlace display feature itself is not fully supported due to restriction with vblank events.

  • 0 in reply to Chris Anderson20
    TI__Mastermind 22946 points
    Hi Chris,

    I understand with the suggested hack patch, the framerate reduced by half but did you find that the original reported jitter issue went away applying it?

    Regards,
    Manisha
  • 0 in reply to Manisha Agrawal
    Intellectual 690 points

    No, jitter was not corrected because it is due to bad field sequencing which results from the driver's incorrect handling of field buffers on the vertical interrupt.

    Only original issues #1 and #2 were corrected by this fix.