Re: [PATCH] drm/omap: Migrate minimum FCK/PCK ratio from Kconfig to dts

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

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