| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
| |
For VPU352MHz enabled, SOC/PU voltage can NOT be lower than 1250mV,
as only 396M and 792M setpoint's SOC/PU voltage is lower than
1250mV and we already disable 396M setpoint, so here we just increase
SOC/PU voltage for 792M setpoint when VPU352M is enabled.
Signed-off-by: Anson Huang <b20788@freescale.com>
|
| |
|
|
|
|
|
|
| |
PU regulator is not a necessary regulator for cpufreq, not all
i.MX6 SoCs have PU regulator, so remove the dependency to support
i.MX6SX which has NO PU regulator.
Signed-off-by: Anson Huang <b20788@freescale.com>
|
| |
|
|
|
|
|
|
|
| |
The mutex, set_cpufreq_lock, should be initialized before the driver is
registered. Else if the default governor is set to performance or ondemand,
the cpufreq driver will try to set the freq to the max freq supported and
this will cause a crash during boot.
Signed-off-by: Ranjani Vaidyanathan <ra5478@freescale.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For changing the cpu frequency the i.MX6q has to be switched to some
intermediate clock during the PLL reprogramming. The driver tries
to be clever to keep the enable count correct but gets it wrong. If
the cpufreq is increased it calls clk_disable_unprepare twice
on pll2_pfd2_396m. This puts all other devices which get their clock
from pll2_pfd2_396m into a nonworking state.
Fix this by removing the clk enabling/disabling altogether since the
clk core will do this automatically during a reparent.
[shawn.guo: The driver assumes that cpu always boots with 800MHz, and
the first transition on 400MHz must be entering 400MHz setpoint. But
it turns out that's not always the case. In some system, cpu boots up
at 400MHz and then the first transition on 400MHz will be leaving
400MHz setpoint rather than entering. In this case, the use count of
pll2_pfd2_396m will be wrong. Anyway, since clock framework has been
nicely handling the clk enabling during reparent, we should not need
to worry about it.]
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During suspend/resume, when cpufreq driver try to increase
voltage/freq, it needs to control I2C/SPI to communicate with
external PMIC to adjust voltage, but these I2C/SPI devices may
be already suspended, to avoid such scenario, we just increase
cpufreq to highest setpoint before suspend.
As this pm notification's updating cpu policy may work together
with cpufreq governor, both of them may call set_target at same
time, so we need to add mutex lock to prevent this scenario,
otherwise, the clock use count will be wrong.
Signed-off-by: Anson Huang <b20788@freescale.com>
|
|
|
Change references to iMX6q to iMX6 as the CPUFREQ driver is
common to all iMX6x chips.
Reanme imx6q-cpufreq.c to cpufreq-imx6.c.
Signed-off-by: Ranjani Vaidyanathan <ra5478@freescale.com>
|
