Re: OMAPDSS: DISPC: horizontal timing too tight errors

From: Ivaylo Dimitrov
Date: Tue Jan 07 2014 - 13:31:00 EST

On 07.01.2014 20:05, Pavel Machek wrote:
On Tue 2014-01-07 14:35:02, Tomi Valkeinen wrote:
On 2014-01-06 11:43, Ivaylo Dimitrov wrote:

commit 7faa92339bbb1e6b9a80983b206642517327eb75 "OMAPDSS: DISPC: Handle
synclost errors in OMAP3" introduces some limits check to prevent
SYNCLOST errors on OMAP3 in a specific usecase. The problem I see here
(on Nokia N900, Maemo 5, linux 3.13-rc6, DSP accel video decoding) is
that those checks effectively prevent fullscreen video playback of
anything above lets say 640x350 with "horizontal timing too tight"
errors spit in dmesg log. If I hack check_horiz_timing_omap3 function to
always return true, I can happily play videos up to (and including) 720p
resolutions, with no SYNCLOST errors.

I never worked with the patch in question, but my understanding is that
the core issue is quite difficult to solve optimally for all cases.
There are so many variables involved. So it may well be that the patch
in question does it a bit over-safely. Then again, it might as well have
a bug =).

Can we simply revert 7faa92339bbb1e6b9a80983b206642517327eb75 ?

Working around undocumented problems on unspecified machine, but
breaking configuration people actually use seems like a bad idea.


The similar code exists in both omap1(N900 stock) and N9 kernels, I guess there is some other bug (somewhere else), trying to find it as we speak :)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at