[PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
tomi.valkeinen at ti.com
Mon May 12 04:38:04 PDT 2014
On 09/05/14 17:37, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen at ti.com> [140509 01:02]:
>> On 09/05/14 02:20, Tony Lindgren wrote:
>>> * Tony Lindgren <tony at atomide.com> [140429 16:53]:
>>>> Otherwise we can get often errors like the following and the
>>>> display won't come on:
>>>> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
>>>> omapdss APPLY error: SYNC_LOST on channel lcd, restarting
>>>> the output with video overlays disabled
>>>> There are some earlier references to this issue:
>>>> It seems that it's safe to set the lower values even for 3630.
>>>> If we can confirm that 3630 works with the higher values
>>>> reliably we can add further detection.
>>> BTW, I'm also seeing this warning on 3730-evm it may be related:
>>> [ 3.523101] ------------[ cut here ]------------
>>> [ 3.528015] WARNING: CPU: 0 PID: 6 at drivers/video/fbdev/omap2/dss/dss.c:483 dss_set_fck_rate+0x6c/0x8c()
>>> [ 3.538360] clk rate mismatch: 108000000 != 115200000
>>> [ 3.543518] Modules linked in:
>> Hmm... Can you paste the clk_summary from debugfs? Somehow the clock
>> framework calculates the clock rate differently than the dss. Or do we
>> have different clock.dts files used for 3730 and 3630?
> OK pasted to the other email in this thread.
I mean the debugs for clock framework. The above warning means that the
clock framework says the clock rate is X, but the dss had calculated
that it should be Y. So there's a difference how the clock framework
calculates the rate and how the dss calculates it.
And yes, dss shouldn't calculate it. But I don't know how to get good
pixel clocks if we didn't.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the linux-arm-kernel