Forums

chanho,

What platform are you working on?

The existing DVI drivers under both Linux and WinCE should be correct, and could be used as a starting point for your HDMI modifications.

From a video perspective there should be no changes required to move from DVI to HDMI other than additional transmitter configuration side channel. Obviously the audio requirements need to be added though.

Please see the following links for more information on configuring the display sub system, and on modifying the existing Linux drivers to support additional video resolutions on the DSS output.

http://wiki.omap.com/index.php/Display_Subsystem

http://wiki.omap.com/index.php/Adding_new_DVI_resolutions

If you are writing directly to registers for some other OS, then the registers you need to consider are...

DISPC_TIMING_H
DISPC_TIMING_V
DISPC_SIZE_LCD

DISPC_TIMING_H can be used to change the relative positions of the edges.

Changing DISPC_POL_FREQ should have inverted the signal. Don't forget that when you touch any of the display sub system registers you must set the control bit GOLCD in order to actually transfer the register settings to the hardware (the transfer is actually performed at the next v-sync after GOLCD in order to ensure not corrupt frames are generated)

What is the actual resolution/frame rate you are trying to generate?

Kind regards,

Steve

Thanks, steve.

We are working on linux 2.6.29 kernel. Reference board is Beagle.

Our resolution is 1280x720p(defined by CEA861B) and Timing values are "pixel clock:74.25Mhz,hsw:40,hfp:110,hbp:220,vsw:5,vfp:5,vbp:20".

DISPC_TIMING_H can be just defined the pixel clock for each hsync period .DISPC_TIMING_H

We couldn't change the relative postion of the edge by any dss register(like DISPC_TIMING_H,  DISPC_TIMING_V,DISPC_SIZE_LCD etc.)

Timing shape for 1280x720p defined by CEA861B is the bellows. 

 But, Our measured timging is the bellows.

vsync width is 5 lines and correct. But, vsync rising edge is slower than CEA861B's one by 1 hsync period.

We are not sure that this probem is cause of the flicker issue. but, we want to remove suspicious point.

Can you help this problem?

Thanks

Chanho min

Hi Chanho,

I'd been looking at this last week on our platform (OMAP3503) with an OLED panel as we have some inexplicable flicker too! I'd noticed exactly the same thing - that the rising edge of vsync seems to synchronise with the falling edge of hsync (not the rising which I'd expect it to be). I don't see any control in the timing registers to change this either.

~Pev

Let me look at this in some more detail and get back to you...

BR,

Steve

Pev,

Are you able to send me the datasheet for this panel and I will have a look to see if I can see anything obvious.

Typically panels can accept much more flexible timings than what VESA specifies, as can most monitors so for this to be an issue is a little strange. It could be that the edges are accuring at exactly the same pixel edge and with jitter on the clock the receivers are sometimes seeing the edge before and sometimes slightly after.

As a test can you try inverting the clock olarity.

In the meantime I will look at moving the edges completely away from each other.

BR,

Steve

Hi, steve

How can I send datasheet to you?

My email is mincho0207@hotmail.com

Thanks for your help!

chanho

OK, to be truly CEA compliant requires, as you have noted, for the syncs to be both positive and concurrent. OMAP cannot generate these syncs.

Now, having said this, most HDMI receivers actually only really use the edge of the syncs to align, so in reality this should not be an issue. Note, it is the receiver and not the transmitter that cares since the transmitter typically just passes the syncs through.

OMAP2 & 3 have been used on many products with DVI and HDMI transmitters at various resolutions with no other issues reported so far.

I have just verified that DISPC_POL_FREQ bits 13 and 12 do in fact invert the H & v sync polarities, so I am not sure why these did not change for you (don't forget to trigger GOLCD after making any changes)

I think your originally reported problems may relate to some other issue.

If you can invert the H & V syncs so they are active low, which I think is actually the default for the PSP release, then you should have a good stable image.

Are you able to try a variety of displays (especially different brands) to see if the issue is display specific? If this is NOT display specific then I believe that the issue is some other configuration issue and not the syncs. If some displays are good but others bad, then it could be sync related.

When you say "We met screen flicker and noise issue" can you describe some more please? For noise do you mean the entire image jumps and is generally corrupt (likely sync issues) or that pixels and/or lines within the image are corrupt (likely pixel clock polarity issues i.e. setup and hold issues).

What are you using as a starting point for your HDMI driver? The PSP DVI driver should be used as a starting point since this has been used for many years in many products at many resolutions. Do these original resolutions and configurations display OK for you? Note, from a video perspective there is no real difference between DVI and HDMI for RGB video.

BR,

Steve

Pev,

Are you able to send me the datasheet for the display so I can check the timing requirements?

Most displays do not usually actually care about this relationship and really only look at the sync edges and the DE signal.

If you can try inverting each and both of the H & V syncs using register DISPC_POL_FREQ bits 12 & 13 in turn you should be able to find a setting that works with your display.

Can you describe the flicker in a little more detail please? What are you displaying (video or a static image etc...)?

Kind regards,

Steve

Steve,

(1)  Digital process delay through the THS8135 triple video DAC:

You mentioned an 8 pxl clock delay in the thread containing the reference design, where you're passing the sync signals through the dual-supply buffer (SN74LVC2T45).  While starting to work through an external logic solution (driving the dual-buffer) it occurred to me that the OMAP may support programmatic delay of HSYNC and VSYNC, and I came across this other thread, where you're discussing DISPC_TIMING_H and DISPC_TIMING_V.  Are these the control parameters that I'm looking to write to effect the 8 pixel clock delay (to compensate for the THS8135 td(D)?

(2)  For a 56Mhz VESA analog RGB display, I'm assuming that my OMAP DSS pixel clock would be programmed in this same vicinity; i.e., 56 Mhz?  This would be driving the THS8135.

Thanks again,

Steve/NY

Steve,

Yes to both questions :)

You can control h-sync & v-sync size and positions with these registers.

As mentioned in the above thread though the exact relationship between h & v is slightly wrong to be truly VESA compliant but this has never been an issue.

BR,

Steve

There is no register  DISPC_POL_FREQ in AM335X dataheet.

Does anyone know hot to adjust the H & V sync in AM335X?

Thanks much.