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]

Message-ID: <52CBF476.3070306@ti.com>
Date:	Tue, 7 Jan 2014 14:35:02 +0200
From:	Tomi Valkeinen <tomi.valkeinen@...com>
To:	Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>
CC:	"pali.rohar@...il.com" <pali.rohar@...il.com>,
	"pavel@....cz" <pavel@....cz>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: OMAPDSS: DISPC: horizontal timing too tight errors

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 =).

One option is also to increase the blanking timings and pixel clock,
presuming the panel is fine with it. That would allow some more time for
the DISPC to manage scaling.

So are you saying that you can't even play any video in the LCD's native
resolution (i.e. no scaling needed) with fullscreen?

> So, a couple of questions:
> 
> Where do the values in static const u8 limits[3] come from? Are those
> documented somewhere?

If I remember right, these horizontal check timings information came
from some non-public TI guides. Not from the TRM.

> Commit message says "This code is written based on code written by Ville
> Syrjälä <ville.syrjala@...ia.com> in Linux OMAP kernel.", is that code
> publicly available and where (if it is).

It should be in the Nokia's kernel for N9.

> Besides compiling DSS driver with DEBUG enabled and providing the log
> (yeah, I know I should've done it already and have the logs included in
> this mail, but... :) ), is there anything else I can do to find the
> culprit for those errors.

You could look at the original patch in the Nokia kernel to see if the
mainline version is ok. Or maybe even better, try the same use case on
Nokia's kernel to see if it works.

 Tomi

Download attachment "signature.asc" of type "application/pgp-signature" (902 bytes)