On Tue, 2017-04-04 at 11:51 +0200, Lucas Stach wrote:
> Am Freitag, den 31.03.2017, 22:25 +0300 schrieb Leonard Crestez:
> >
> > If the cpufreq driver tries to modify voltage/freq during suspend/resume
> > it might need to control an external PMIC via I2C or SPI but those
> > devices might be already suspended.
> >
> > To avoid this scenario we just increase cpufreq to highest setpoint
> > before suspend. This issue can easily be triggered by ldo-bypass but in
> > theory any regulator set_voltage call can end up having to modify
> > external supply voltages.
> >
> > Signed-off-by: Leonard Crestez <leonard.cres...@nxp.com>
> > Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
> > ---
> > drivers/cpufreq/imx6q-cpufreq.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/cpufreq/imx6q-cpufreq.c
> > b/drivers/cpufreq/imx6q-cpufreq.c
> > index be90ee3..e2c1fbf 100644
> > --- a/drivers/cpufreq/imx6q-cpufreq.c
> > +++ b/drivers/cpufreq/imx6q-cpufreq.c
> > @@ -162,6 +162,7 @@ static int imx6q_set_target(struct cpufreq_policy
> > *policy, unsigned int index)
> > static int imx6q_cpufreq_init(struct cpufreq_policy *policy)
> > {
> > policy->clk = arm_clk;
> > + policy->suspend_freq = freq_table[soc_opp_count - 1].frequency;
> I think soc_opp_count includes all OPPs from the DT, some of which might
> be disabled based on the fuse settings of the SoC. So this should
> probably not switch to the highest OPP unconditionally, but rather
> switch to the highest _enabled_ OPP.
You're right, this does not appear to be correct. Looking at
soc_opp_count it should probably be a local variable in the code
initializing imx6_soc_volt. And the imx6_soc_volt array itself could
now be replaced with opp's support for multiple supply voltages.
I'll post v2.
