[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f01bf6ec-e531-371b-4f66-312b12379273@ti.com>
Date: Tue, 1 Oct 2019 12:31:38 +0300
From: Tomi Valkeinen <tomi.valkeinen@...com>
To: Tero Kristo <t-kristo@...com>, Adam Ford <aford173@...il.com>
CC: "H. Nikolaus Schaller" <hns@...delico.com>,
Tony Lindgren <tony@...mide.com>,
Linux-OMAP <linux-omap@...r.kernel.org>,
Adam Ford <adam.ford@...icpd.com>,
Benoît Cousson <bcousson@...libre.com>,
dri-devel <dri-devel@...ts.freedesktop.org>,
devicetree <devicetree@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drm/omap: Migrate minimum FCK/PCK ratio from Kconfig to
dts
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.
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
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Powered by blists - more mailing lists