On Tue, Dec 10, 2013 at 10:02 PM, Lukasz Majewski <l.majewski@xxxxxxxxxxx> wrote: >> >> Actually these values are not for PLL, but for the dividers. >> If you see below, the PLL rate setting is done through clk_set_rate() >> going via CCF. But I found an issue if the divider values are set via >> clk_set_rate API. >> What I found is, the system goes into freeze if all the divider >> values are not set in one shot. So we cannot call multiple >> clk_set_rate()'s on each divider. Thats why I continued with non-CCF >> way of setting the divider. > > I see. I'm not an expert on common clock framework (CCF), but for me > conceptually clock dividers setting shall be handled by CCF. > > However, I've poked a bit at CCF. There isn't any out of the box > solutions available. > > A "virtual" clock can be defined and inside its implementation we can > atomically set dividers. Another solution would be to hack the current > CCF to provide atomic clock operations > CCF isn't only for clocks that have single divider or gate control register. One could define a clock that manipulates more than one divider/gate in one CCF callback. It is already abstract enough. So implementing a virtual clock is the solution, imho. BTW, on my platform linux needs to send a 'non-atomic' IPC message to a master co-processor to scale up/down cpufreq. I just define a virtual clock and use the generic bL cpufreq driver drivers/cpufreq/arm_big_little.c -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
