All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali@kernel.org>
To: Konstantin Porotchkin <kostap@marvell.com>,
	Nadav Haklai <nadavh@marvell.com>, Ken Ma <make@marvell.com>,
	Victor Gu <xigu@marvell.com>,
	Jason Hung <jhung@globalscaletechnologies.com>
Cc: "Marek Behún" <kabel@kernel.org>,
	"Viresh Kumar" <viresh.kumar@linaro.org>,
	"Gregory CLEMENT" <gregory.clement@bootlin.com>,
	"Robert Marko" <robert.marko@sartura.hr>,
	"Tomasz Maciej Nowak" <tmn505@gmail.com>,
	"Anders Trier Olesen" <anders.trier.olesen@gmail.com>,
	"Philip Soares" <philips@netisense.com>,
	linux-pm@vger.kernel.org,
	"Sebastian Hesselbarth" <sebastian.hesselbarth@gmail.com>,
	linux-arm-kernel@lists.infradead.org, nnet <nnet@fastmail.fm>
Subject: Re: [PATCH v2] cpufreq: armada-37xx: forbid cpufreq for 1.2 GHz variant
Date: Thu, 8 Jul 2021 16:34:51 +0200	[thread overview]
Message-ID: <20210708143451.4htvdop4zvjufrq6@pali> (raw)
In-Reply-To: <20210702163035.nmb5pniwpqtmaz4b@pali>

Konstantin, Nadav, Ken, Victor, Jason: This issue is pretty serious,
CPU on 1.2GHz A3720 is crashing. Could you please look at it?

On Friday 02 July 2021 18:30:35 Pali Rohár wrote:
> +Jason from GlobalScale as this issue affects GlobalScale Espressobin Ultra and V7 1.2 GHz boards.
> 
> On Thursday 01 July 2021 00:56:01 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.org>
> > 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.
> > 
> > Ken Ma / Victor Gu, you have worked on commit
> > https://github.com/MarvellEmbeddedProcessors/linux-marvell/commit/d6719fdc2b3cac58064f41b531f86993c919aa9a
> > in linux-marvell.
> > Your patch takes away the 1202 mV constant for 1.2 GHz base CPU
> > frequency and instead adds code that computes the voltages from the
> > voltage found in L0 AVS register (which is filled in by WTMI firmware).
> > 
> > Do you know why the code does not work correctly for some 1.2 GHz
> > boards? Do we need to force the L0 voltage to 1202 mV if it is lower,
> > or something?
> > ---
> >  drivers/cpufreq/armada-37xx-cpufreq.c | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/cpufreq/armada-37xx-cpufreq.c b/drivers/cpufreq/armada-37xx-cpufreq.c
> > index 3fc98a3ffd91..c10fc33b29b1 100644
> > --- a/drivers/cpufreq/armada-37xx-cpufreq.c
> > +++ b/drivers/cpufreq/armada-37xx-cpufreq.c
> > @@ -104,7 +104,11 @@ struct armada_37xx_dvfs {
> >  };
> >  
> >  static struct armada_37xx_dvfs armada_37xx_dvfs[] = {
> > -	{.cpu_freq_max = 1200*1000*1000, .divider = {1, 2, 4, 6} },
> > +	/*
> > +	 * 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} }, */
> >  	{.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} },
> > -- 
> > 2.31.1
> > 

WARNING: multiple messages have this Message-ID (diff)
From: "Pali Rohár" <pali@kernel.org>
To: Konstantin Porotchkin <kostap@marvell.com>,
	Nadav Haklai <nadavh@marvell.com>, Ken Ma <make@marvell.com>,
	Victor Gu <xigu@marvell.com>,
	Jason Hung <jhung@globalscaletechnologies.com>
Cc: "Marek Behún" <kabel@kernel.org>,
	"Viresh Kumar" <viresh.kumar@linaro.org>,
	"Gregory CLEMENT" <gregory.clement@bootlin.com>,
	"Robert Marko" <robert.marko@sartura.hr>,
	"Tomasz Maciej Nowak" <tmn505@gmail.com>,
	"Anders Trier Olesen" <anders.trier.olesen@gmail.com>,
	"Philip Soares" <philips@netisense.com>,
	linux-pm@vger.kernel.org,
	"Sebastian Hesselbarth" <sebastian.hesselbarth@gmail.com>,
	linux-arm-kernel@lists.infradead.org, nnet <nnet@fastmail.fm>
Subject: Re: [PATCH v2] cpufreq: armada-37xx: forbid cpufreq for 1.2 GHz variant
Date: Thu, 8 Jul 2021 16:34:51 +0200	[thread overview]
Message-ID: <20210708143451.4htvdop4zvjufrq6@pali> (raw)
In-Reply-To: <20210702163035.nmb5pniwpqtmaz4b@pali>

Konstantin, Nadav, Ken, Victor, Jason: This issue is pretty serious,
CPU on 1.2GHz A3720 is crashing. Could you please look at it?

On Friday 02 July 2021 18:30:35 Pali Rohár wrote:
> +Jason from GlobalScale as this issue affects GlobalScale Espressobin Ultra and V7 1.2 GHz boards.
> 
> On Thursday 01 July 2021 00:56:01 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.org>
> > 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.
> > 
> > Ken Ma / Victor Gu, you have worked on commit
> > https://github.com/MarvellEmbeddedProcessors/linux-marvell/commit/d6719fdc2b3cac58064f41b531f86993c919aa9a
> > in linux-marvell.
> > Your patch takes away the 1202 mV constant for 1.2 GHz base CPU
> > frequency and instead adds code that computes the voltages from the
> > voltage found in L0 AVS register (which is filled in by WTMI firmware).
> > 
> > Do you know why the code does not work correctly for some 1.2 GHz
> > boards? Do we need to force the L0 voltage to 1202 mV if it is lower,
> > or something?
> > ---
> >  drivers/cpufreq/armada-37xx-cpufreq.c | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/cpufreq/armada-37xx-cpufreq.c b/drivers/cpufreq/armada-37xx-cpufreq.c
> > index 3fc98a3ffd91..c10fc33b29b1 100644
> > --- a/drivers/cpufreq/armada-37xx-cpufreq.c
> > +++ b/drivers/cpufreq/armada-37xx-cpufreq.c
> > @@ -104,7 +104,11 @@ struct armada_37xx_dvfs {
> >  };
> >  
> >  static struct armada_37xx_dvfs armada_37xx_dvfs[] = {
> > -	{.cpu_freq_max = 1200*1000*1000, .divider = {1, 2, 4, 6} },
> > +	/*
> > +	 * 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} }, */
> >  	{.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} },
> > -- 
> > 2.31.1
> > 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-07-08 14:34 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-30 13:59 [PATCH] cpufreq: armada-37xx: forbid cpufreq for 1.2 GHz variant Marek Behún
2021-06-30 13:59 ` Marek Behún
2021-06-30 14:02 ` Marek Behún
2021-06-30 14:02   ` Marek Behún
2021-06-30 15:22 ` Andrew Lunn
2021-06-30 15:22   ` Andrew Lunn
2021-06-30 22:56 ` [PATCH v2] " Marek Behún
2021-06-30 22:56   ` Marek Behún
2021-07-01  2:05   ` Viresh Kumar
2021-07-01  2:05     ` Viresh Kumar
2021-07-02 16:30   ` Pali Rohár
2021-07-02 16:30     ` Pali Rohár
2021-07-08 14:34     ` Pali Rohár [this message]
2021-07-08 14:34       ` Pali Rohár
2021-07-15 19:33       ` Pali Rohár
2021-07-15 19:33         ` Pali Rohár
2021-08-08 19:30         ` Pali Rohár
2021-08-08 19:30           ` Pali Rohár
2021-08-09  4:02           ` Viresh Kumar
2021-08-09  4:02             ` Viresh Kumar
2022-08-01 12:36           ` Pali Rohár
2022-08-01 12:36             ` Pali Rohár
2022-08-01 14:01             ` [EXT] " Elad Nachman
2022-08-01 14:01               ` Elad Nachman
2022-08-01 14:12               ` Pali Rohár
2022-08-01 14:12                 ` Pali Rohár
2022-08-01 14:15                 ` Elad Nachman
2022-08-01 14:15                   ` Elad Nachman
2022-08-01 17:56                   ` Pali Rohár
2022-08-01 17:56                     ` Pali Rohár
     [not found]                     ` <BN9PR18MB42518C761E574D862D30CDA7DB9A9@BN9PR18MB4251.namprd18.prod.outlook.com>
2022-08-02 16:42                       ` Robert Marko
2022-08-02 16:42                         ` Robert Marko
2022-08-02 16:52                         ` Elad Nachman
2022-08-02 16:52                           ` Elad Nachman
2022-08-02 16:56                           ` Robert Marko
2022-08-02 16:56                             ` Robert Marko
2022-08-02 17:17                             ` Pali Rohár
2022-08-02 17:17                               ` Pali Rohár
2022-08-17  9:40                               ` Robert Marko
2022-08-17  9:40                                 ` Robert Marko
2022-08-17 23:10                                 ` Pali Rohár
2022-08-17 23:10                                   ` Pali Rohár
2022-08-18  8:14                                   ` Robert Marko
2022-08-18  8:14                                     ` Robert Marko
2022-08-25 21:49                                     ` Pali Rohár
2022-08-25 21:49                                       ` Pali Rohár

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210708143451.4htvdop4zvjufrq6@pali \
    --to=pali@kernel.org \
    --cc=anders.trier.olesen@gmail.com \
    --cc=gregory.clement@bootlin.com \
    --cc=jhung@globalscaletechnologies.com \
    --cc=kabel@kernel.org \
    --cc=kostap@marvell.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=make@marvell.com \
    --cc=nadavh@marvell.com \
    --cc=nnet@fastmail.fm \
    --cc=philips@netisense.com \
    --cc=robert.marko@sartura.hr \
    --cc=sebastian.hesselbarth@gmail.com \
    --cc=tmn505@gmail.com \
    --cc=viresh.kumar@linaro.org \
    --cc=xigu@marvell.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.