linux-kernel - Re: OMAPDSS: DISPC: horizontal timing too tight errors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 07 Jan 2014 20:30:40 +0200
From:	Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>
To:	Pavel Machek <pavel@....cz>, Tomi Valkeinen <tomi.valkeinen@...com>
CC:	Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>,
	"pali.rohar@...il.com" <pali.rohar@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/