[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140107180509.GC18316@amd.pavel.ucw.cz>
Date: Tue, 7 Jan 2014 19:05:09 +0100
From: Pavel Machek <pavel@....cz>
To: 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 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
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/
Powered by blists - more mailing lists