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:
signature.asc
Description: OpenPGP digital signature
