linux-kernel - Re: [BISECTED] OMAP: DSS: clk rate mismatch

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: <52E7614E.8010903@ti.com>
Date:	Tue, 28 Jan 2014 09:50:38 +0200
From:	Tomi Valkeinen <tomi.valkeinen@...com>
To:	Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>
CC:	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <pali.rohar@...il.com>,
	<pavel@....cz>
Subject: Re: [BISECTED] OMAP: DSS: clk rate mismatch

On 2014-01-27 19:30, Ivaylo Dimitrov wrote:
> Hi Tomi,
> 
> linux-next-20140124 DSS is broken on N900  - display stays black (there
> is some noise though). I booted the kernel with qemu and it gives the
> following warning:
> 
> [    0.623779] DSS: set fck to 172800000
> [    0.624237] ------------[ cut here ]------------
> [    0.624298] WARNING: CPU: 0 PID: 1 at
> drivers/video/omap2/dss/dss.c:497 dss_set_fck_rate+0x68/0x8c()
> [    0.624359] clk rate mismatch: 288000000 != 172800000

That says that the omapdss tries to set the func clock to 172.8 MHz, but
after setting the rate, the clock is at 288 MHz.

I just hit the same warning with beagle-xm yesterday, with v3.13-rc6 +
DSS device tree patches, although it might be a different thing. I see
that the actual clock is lower than what omapdss tries to set, you have
the other way around.

The beagle-xm issue is related to a clk-divider fix I have sent some
time ago:

http://mid.gmane.org/1383736008-22764-1-git-send-email-tomi.valkeinen@ti.com

Basically the issue is that omapdss needs to produce very precise pixel
clocks, derived from fck, but the fck rate options are quite limited. So
omapdss tries to find out what kind of rates it could get for the fck,
i.e. it does the clock divider calculations itself that would normally
be left to the clock framework.

That means the omapdss should do rounding the same way as the clock
framework does. But clock framework has no rules about the rounding, so
omapdss easily gets it wrong. And when you add the bug for which I
posted the patch above, it seems the omapdss clock calculations are not
very functional at the moment with fractional clock rates.

However, I think the issue I see with beagle-xm should always result in
lower actual fck than requested, but you see the other way around. So I
wonder if it's something else... N900 clock calculations do initiate
from sdi.c, instead of dpi.c for beagle, but they do look rather
similar, and use the same helper functions from dss.c and dispc.c.

How is the dss clock calculated on n900? Can you attach
debug/clk/clk_summary output?

 Tomi

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