| Message ID | 20210630135942.29730-1-kabel@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | cpufreq: armada-37xx: forbid cpufreq for 1.2 GHz variant | expand |
On Wed, 30 Jun 2021 15:59:42 +0200 Marek Behún <kabel@kernel.org> wrote: > Signed-off-by: Marek Behún <kabel@kernel.iorg> OMG, this should be Signed-off-by: Marek Behún <kabel@kernel.org> Marek
On Wed, Jun 30, 2021 at 03:59:42PM +0200, Marek Behún wrote: > The 1.2 GHz variant of the Armada 3720 SOC is unstable with DVFS: when > the SOC boots, the WTMI firmware sets clocks and AVS values that work > correctly with 1.2 GHz CPU frequency, but random crashes occur once > cpufreq driver starts scaling. > > We do not know currently what is the reason: > - it may be that the voltage value for L0 for 1.2 GHz variant provided > by the vendor in the OTP is simply incorrect when scaling is used, > - it may be that some delay is needed somewhere, > - it may be something else. > > The most sane solution now seems to be to simply forbid the cpufreq > driver on 1.2 GHz variant. > > Signed-off-by: Marek Behún <kabel@kernel.iorg> > Fixes: 92ce45fb875d ("cpufreq: Add DVFS support for Armada 37xx") > --- > If someone from Marvell could look into this, it would be great since > basically 1.2 GHz variant cannot scale, which is a feature that was > claimed to be supported by the SOC. > --- > drivers/cpufreq/armada-37xx-cpufreq.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/cpufreq/armada-37xx-cpufreq.c b/drivers/cpufreq/armada-37xx-cpufreq.c > index 3fc98a3ffd91..1ef3dde9a40b 100644 > --- a/drivers/cpufreq/armada-37xx-cpufreq.c > +++ b/drivers/cpufreq/armada-37xx-cpufreq.c > @@ -104,7 +104,13 @@ struct armada_37xx_dvfs { > }; > > static struct armada_37xx_dvfs armada_37xx_dvfs[] = { > +#if 0 > + /* > + * The cpufreq scaling for 1.2 GHz variant of the SOC is currently > + * unstable because we do not know how to configure it properly. > + */ > {.cpu_freq_max = 1200*1000*1000, .divider = {1, 2, 4, 6} }, > +#endif I suspect you will get some drive by patches from bot handlers removing the #if 0, since such code is not liked within the kernel, and bot handlers blindly do what the bot tells them. So i would suggest you avoid #if 0, and move the .cpu_req_max entry into the comment. Andrew
diff --git a/drivers/cpufreq/armada-37xx-cpufreq.c b/drivers/cpufreq/armada-37xx-cpufreq.c index 3fc98a3ffd91..1ef3dde9a40b 100644 --- a/drivers/cpufreq/armada-37xx-cpufreq.c +++ b/drivers/cpufreq/armada-37xx-cpufreq.c @@ -104,7 +104,13 @@ struct armada_37xx_dvfs { }; static struct armada_37xx_dvfs armada_37xx_dvfs[] = { +#if 0 + /* + * The cpufreq scaling for 1.2 GHz variant of the SOC is currently + * unstable because we do not know how to configure it properly. + */ {.cpu_freq_max = 1200*1000*1000, .divider = {1, 2, 4, 6} }, +#endif {.cpu_freq_max = 1000*1000*1000, .divider = {1, 2, 4, 5} }, {.cpu_freq_max = 800*1000*1000, .divider = {1, 2, 3, 4} }, {.cpu_freq_max = 600*1000*1000, .divider = {2, 4, 5, 6} },
The 1.2 GHz variant of the Armada 3720 SOC is unstable with DVFS: when the SOC boots, the WTMI firmware sets clocks and AVS values that work correctly with 1.2 GHz CPU frequency, but random crashes occur once cpufreq driver starts scaling. We do not know currently what is the reason: - it may be that the voltage value for L0 for 1.2 GHz variant provided by the vendor in the OTP is simply incorrect when scaling is used, - it may be that some delay is needed somewhere, - it may be something else. The most sane solution now seems to be to simply forbid the cpufreq driver on 1.2 GHz variant. Signed-off-by: Marek Behún <kabel@kernel.iorg> Fixes: 92ce45fb875d ("cpufreq: Add DVFS support for Armada 37xx") --- If someone from Marvell could look into this, it would be great since basically 1.2 GHz variant cannot scale, which is a feature that was claimed to be supported by the SOC. --- drivers/cpufreq/armada-37xx-cpufreq.c | 6 ++++++ 1 file changed, 6 insertions(+)