I'm driving a TFP410 parallel to DVI (HDMI) converter using a DM368. Unfortunately I can't generate the exact clock frequencies required for HDMI CEA modes (74.25 MHz, 148.5 Mhz, etc.), I'm stuck with dividing a PLL. The PLL is 680 MHz, so the frequencies within the 720p-1080p video range I can use are basically 68, 75.5, 85, 97, 113 and 136 MHz.
I've written a kernel EDID parser that I'm using to get timing requirements from the monitors and feed them to the video encoder onboard the DM368. I know the video timings I'm sending to the TFP410 serialiser (HS/VS active lines, front/back porch, sync pulse width) are correct since that I'm testing them at the DVI/HDMI output using a development board where I can compare them with working signal sources. I'm also parsing maximum clock, min-max refresh ratios and keeping them into account when deciding the output clock.
Despite all this, I can't get the image to display on the oldest monitors (newer monitors are fine). I've spent quite some time on this, so I can tell you that for example, in one of the oldest monitors I can display an image by increasing the active size (720p to ~730p), or decreasing the clock (from 75.5 to 68 MHz). However, this approach doesn't really scale.
Are my problems due to my imperfect frequencies or is there something else I should look into? Unfortunately I can't add an external 74.25 MHz clock source at this stage.
HDMI is complicated and I'm afraid I don't understand it properly. I just wish monitors respected what they advertise in their EDID, but I'm starting to believe no one uses those specs anyway (max clock, min/max fps, etc.).
Best Answer
The thing is, once you go outside the spec, anything can happen (and usually does on a major customer demo!). You might get it to work, sort of, sometimes, but as soon as you break spec, you are responsible for whatever does not work reliably.
I am not at all surprised that some monitors work and some do not, IME it is usually the computer monitors that are fussy while tellies will often take any old rubbish.
There are about half a dozen or so sets of frame timings that pretty much everything accepts, basically the broadcast derived ones, but they tend to need that clock that you don't have, and yea, EDID is often best ignored (or at least taken with caution), buggy does not begin to describe some of them.
One gotcha is to check the sound, as the dividers to derive the 48K audio rate from the pixel clock will be off, and that may cause issues.
Time for a board respin?