Re: Odd behavior with dpll4_m4x2_ck on omap3 + DT

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

[-- Attachment #1: Type: text/plain, Size: 1614 bytes --]

On 10/09/13 15:24, Tero Kristo wrote:
> On 09/10/2013 03:19 PM, Tomi Valkeinen wrote:
>> On 10/09/13 15:12, Tero Kristo wrote:
>>
>>> If it claims it is not locked, it means the DPLL itself is disabled. You
>>> could try clk_enable for the clock before doing clk_set_rate.
>>
>> Hmm, so is it required to enable the clock before setting the rate? If
>> so, I think I'm using the clocks wrong in all the places =).
> 
> In generic case, it is not. But DPLLs behave strangely if they go to low
> power stop mode. If there is any downstream clock enabled for a specific
> DPLL it is enabled and things work okay.
> 
> One could also argue that the API behavior in OMAP is wrong currently,
> as the bypass rate is something you are most likely never actually going
> to use for anything....
> 
> Just try the change and check the results.

Ok, so as Stefan said, enabling the clock fixes the issue.

How do you suggest we fix this? Changing omapdss to enable the clock
before changing its rate is not very difficult, so it can be used as a
quick fix. But it doesn't sound like a proper fix if this is not
normally required.

And, maybe I'm missing something as I don't have good understanding of
the PRCM's PLLs, but the current behavior sounds odd. So the DPLL is
off, and in bypass mode. When we try to change the rate of the clock
provided by the PLL, shouldn't it fail, as bypass mode's rate cannot be
changed? Or better, change the non-bypass rate.

How is the DPLL4's clock rate 432000000 anyway in bypass mode. Isn't
bypass mode usually plain sys-clock, or such?

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]