Hi Jassi, > 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. Thanks for sharing your experience. > 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 My use case is simpler - cpufreq-cpu0.c or arm_bit_little.c (for bL) driver with maybe two virtual clocks to handle divider's update. > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |