On 30/09/2019 16:17, Adam Ford wrote:
It looks like it's unhappy that its trying to get one frequency and
getting something different instead.
[ 10.014099] WARNING: CPU: 0 PID: 111 at
drivers/gpu/drm/omapdrm/dss/dss.c:655 dss_set_fck_rate+0x70/0x90
[omapdss]
[ 10.014129] clk rate mismatch: 27870968 != 27000000
I believe this one is for Tomi to comment, his driver does some magic
compares for the requested vs. actual received clock rates. If I am not
mistaken, we are only modifying an integer divider here, and thus it is
physically impossible to get accurate 27MHz rate to display.
I didn't expect exactly 27MHz,but the back trace is what concerns me more.
Ah sorry... DSS driver knows the max divider value, so that it can
iterate over all the rates to find a good one.
I'll send a patch later, but look for omap3630_dss_feats in dss.c, and
change fck_div_max from 32 to 16.
However, looking at
# cat clk/dpll4_ck/clk_rate
864000000
It seems like 864000000 / 32 would be 27 MHz, but instead we're
dividing it by 31 yielding 27870968. I don't know the clocking
architecture, so I don't know what your patch actually did or how the
divide by 16 limit worked into this. If lck cannot divide by 32, it
would be nice to see if it could divide by 27 to get to 32MHz. From
there, the pck could then divide by 4 yielding 9MHz.
That's pretty odd. With Tero's patch (I didn't test it though) the max
divider should be 16. So the minimum fclk rate should be 54MHz. But
somehow the clock framework managed to produce 27870968...
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
