Messages in this thread | | | Date | Tue, 07 Jan 2014 20:30:40 +0200 | From | Ivaylo Dimitrov <> | Subject | Re: OMAPDSS: DISPC: horizontal timing too tight errors |
| |
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: >>> Hi, >>> >>> 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. > > Pavel > 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 :)
Ivo
| |