Am Dienstag, den 24.11.2015, 15:35 +0800 schrieb Bai Ping:Thanks for your reminder. It is my fault, I missed the imx_clk_cpu function. I will try using cpufreq-dt
On 2015/11/23 17:40, Lucas Stach wrote:This is wrong, we have the step clock requirement on MX5 as well, that's
Am Montag, den 23.11.2015, 22:07 +0800 schrieb Bai Ping:the requirement is the PLL1 used to source the CPU core clock can NOT
The i.MX7Dual/Solo is a new series of the i.MX SOC family.So, what are those requirements, which could not be matched with
The existing cpufreq driver for 'i.MX6' or 'cpufreq-dt' can
NOT match the requirement of this new SOC. This patch adds the
cpufreq driver for i.MX7Dual/Solo.
cpufreq-dt? We should really try to not add another cpufreq driver.
change frequency on the fly,
during the PLL1 frequency change, not clock output from this PLL1 in a
short time. this will lead to glitch
to the core clock. so before we change the PLL1's frequency, we must
switch the CPU core clock to another
clock source, after the PLL1 frequency has been changed, we switch back
core clock to PLL1.
I don't see anything special in here. A single regulator and some clocksI have checked the i.MX5 cpufreq, As on i.MX5, no need to take care of
needing to be controlled in the right way. That's already handled for
i.MX5 with cpufreq-dt. Please look up how it is done there and try to do
it the same way for MX7, or provide substantial information why it
couldn't be done.
the PLL's frequency change flow,
so the cpufreq-dt is the best one to support cpufreq. But on i.MX7, the
PLL design is not the same as on i.MX5,
additional steps needed in CPU frequency changing flow. the issue that
can NOT be tackled by cpufreq-dt is
additional step used by PLL frequency change.
why I asked you to look into this. The MX5 clock controller provides a
virtual ARM clock, that implements the proper clock switch flow. This
allows to reuse cpufreq-dt, thus reducing code duplication in the
cpufreq drivers greatly.
Regards,
Lucas