On Tue, Oct 1, 2019 at 4:31 AM Tomi Valkeinen tomi.valkeinen@ti.com wrote:
On 01/10/2019 11:12, Tero Kristo wrote:
On 01/10/2019 08:07, Tomi Valkeinen wrote:
On 30/09/2019 20:48, Tero Kristo wrote:
Hmmh, after some testing, it seems there is bad stuff happening with the divider clock implementation, I am re-working it as of now. Basically what is wrong is that with a divider max value of say 16, the driver attempts to craft the max value into a mask, but this ends up being 0x1f. If the max value is 15, it ends up into 0xf which is correct.
Ok, that explains the max not working.
It doesn't explain the other issue, where the TRM says the max div is 32, but it does not work. But taking the max div from the old SoCs, 16, is not correct either, as it seems that dividers up to 31 work ok.
Tomi
Ok, attached a series that hopefully fixes it, any testing feedback welcome before I post this properly.
This also supports omap36xx dpll4_m4_ck divider up-to 31, other omap3 family is limited to 16.
Thank you! This works for me.
Works for me. This also needs the change to dss.c to change the max from 32 to 31. I'll send a patch for that separately.
Tomi,
Do you want me to push a patch to remove the CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK hack once these patches have been posted? It seems like the divider fix eliminates the need for this hack.
adam
Tomi
-- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki