All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali@kernel.org>
To: Gregory Clement <gregory.clement@bootlin.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org
Cc: "Marek Behún" <kabel@kernel.org>,
	"Miquel Raynal" <miquel.raynal@bootlin.com>,
	"Tomasz Maciej Nowak" <tmn505@gmail.com>,
	"Luka Perkov" <luka.perkov@sartura.hr>,
	"Andre Heider" <a.heider@gmail.com>,
	"Vladimir Vid" <vladimir.vid@sartura.hr>,
	"Russell King" <rmk+kernel@armlinux.org.uk>,
	"Gérald Kerma" <gerald@gk2.net>,
	"Konstantin Porotchkin" <kostap@marvell.com>
Subject: [PATCH mvebu v2 06/10] clk: mvebu: armada-37xx-periph: Fix workaround for switching from L1 to L0
Date: Thu, 14 Jan 2021 13:40:28 +0100	[thread overview]
Message-ID: <20210114124032.12765-7-pali@kernel.org> (raw)
In-Reply-To: <20210114124032.12765-1-pali@kernel.org>

When CPU frequency is at 250 MHz and set_rate() is called with 500 MHz (L1)
quickly followed by a call with 1 GHz (L0), the CPU does not necessarily
stay in L1 for at least 20ms as is required by Marvell errata.

This situation happens frequently with the ondemand cpufreq governor and
can be also reproduced with userspace governor. In most cases it causes CPU
to crash.

This change fixes the above issue and ensures that the CPU always stays in
L1 for at least 20ms when switching from any state to L0.

Signed-off-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: 61c40f35f5cd ("clk: mvebu: armada-37xx-periph: Fix switching CPU rate from 300Mhz to 1.2GHz")
Cc: stable@vger.kernel.org
---
 drivers/clk/mvebu/armada-37xx-periph.c | 45 ++++++++++++++++++++++----
 1 file changed, 39 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/mvebu/armada-37xx-periph.c b/drivers/clk/mvebu/armada-37xx-periph.c
index b15e177bea7e..32ac6b6b7530 100644
--- a/drivers/clk/mvebu/armada-37xx-periph.c
+++ b/drivers/clk/mvebu/armada-37xx-periph.c
@@ -84,6 +84,7 @@ struct clk_pm_cpu {
 	void __iomem *reg_div;
 	u8 shift_div;
 	struct regmap *nb_pm_base;
+	unsigned long l1_expiration;
 };
 
 #define to_clk_double_div(_hw) container_of(_hw, struct clk_double_div, hw)
@@ -504,22 +505,52 @@ static long clk_pm_cpu_round_rate(struct clk_hw *hw, unsigned long rate,
  * 2. Sleep 20ms for stabling VDD voltage
  * 3. Then switch from L1 (500/600 MHz) to L0 (1000/1200 MHz).
  */
-static void clk_pm_cpu_set_rate_wa(unsigned long rate, struct regmap *base)
+static void clk_pm_cpu_set_rate_wa(struct clk_pm_cpu *pm_cpu,
+				   unsigned int new_level, unsigned long rate,
+				   struct regmap *base)
 {
 	unsigned int cur_level;
 
-	if (rate < 1000 * 1000 * 1000)
-		return;
-
 	regmap_read(base, ARMADA_37XX_NB_CPU_LOAD, &cur_level);
 	cur_level &= ARMADA_37XX_NB_CPU_LOAD_MASK;
-	if (cur_level <= ARMADA_37XX_DVFS_LOAD_1)
+
+	if (cur_level == new_level)
+		return;
+
+	/*
+	 * System wants to go to L1 on its own. If we are going from L2/L3,
+	 * remember when 20ms will expire. If from L0, set the value so that
+	 * next switch to L0 won't have to wait.
+	 */
+	if (new_level == ARMADA_37XX_DVFS_LOAD_1) {
+		if (cur_level == ARMADA_37XX_DVFS_LOAD_0)
+			pm_cpu->l1_expiration = jiffies;
+		else
+			pm_cpu->l1_expiration = jiffies + msecs_to_jiffies(20);
 		return;
+	}
+
+	/*
+	 * If we are setting to L2/L3, just invalidate L1 expiration time,
+	 * sleeping is not needed.
+	 */
+	if (rate < 1000*1000*1000)
+		goto invalidate_l1_exp;
+
+	/*
+	 * We are going to L0 with rate >= 1GHz. Check whether we have been at
+	 * L1 for long enough time. If not, go to L1 for 20ms.
+	 */
+	if (pm_cpu->l1_expiration && jiffies >= pm_cpu->l1_expiration)
+		goto invalidate_l1_exp;
 
 	regmap_update_bits(base, ARMADA_37XX_NB_CPU_LOAD,
 			   ARMADA_37XX_NB_CPU_LOAD_MASK,
 			   ARMADA_37XX_DVFS_LOAD_1);
 	msleep(20);
+
+invalidate_l1_exp:
+	pm_cpu->l1_expiration = 0;
 }
 
 static int clk_pm_cpu_set_rate(struct clk_hw *hw, unsigned long rate,
@@ -553,7 +584,9 @@ static int clk_pm_cpu_set_rate(struct clk_hw *hw, unsigned long rate,
 			reg = ARMADA_37XX_NB_CPU_LOAD;
 			mask = ARMADA_37XX_NB_CPU_LOAD_MASK;
 
-			clk_pm_cpu_set_rate_wa(rate, base);
+			/* Apply workaround when base CPU frequency is 1000 or 1200 MHz */
+			if (parent_rate >= 1000*1000*1000)
+				clk_pm_cpu_set_rate_wa(pm_cpu, load_level, rate, base);
 
 			regmap_update_bits(base, reg, mask, load_level);
 
-- 
2.20.1


WARNING: multiple messages have this Message-ID (diff)
From: "Pali Rohár" <pali@kernel.org>
To: Gregory Clement <gregory.clement@bootlin.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org
Cc: "Marek Behún" <kabel@kernel.org>,
	"Tomasz Maciej Nowak" <tmn505@gmail.com>,
	"Luka Perkov" <luka.perkov@sartura.hr>,
	"Andre Heider" <a.heider@gmail.com>,
	"Vladimir Vid" <vladimir.vid@sartura.hr>,
	"Russell King" <rmk+kernel@armlinux.org.uk>,
	"Gérald Kerma" <gerald@gk2.net>,
	"Miquel Raynal" <miquel.raynal@bootlin.com>,
	"Konstantin Porotchkin" <kostap@marvell.com>
Subject: [PATCH mvebu v2 06/10] clk: mvebu: armada-37xx-periph: Fix workaround for switching from L1 to L0
Date: Thu, 14 Jan 2021 13:40:28 +0100	[thread overview]
Message-ID: <20210114124032.12765-7-pali@kernel.org> (raw)
In-Reply-To: <20210114124032.12765-1-pali@kernel.org>

When CPU frequency is at 250 MHz and set_rate() is called with 500 MHz (L1)
quickly followed by a call with 1 GHz (L0), the CPU does not necessarily
stay in L1 for at least 20ms as is required by Marvell errata.

This situation happens frequently with the ondemand cpufreq governor and
can be also reproduced with userspace governor. In most cases it causes CPU
to crash.

This change fixes the above issue and ensures that the CPU always stays in
L1 for at least 20ms when switching from any state to L0.

Signed-off-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: 61c40f35f5cd ("clk: mvebu: armada-37xx-periph: Fix switching CPU rate from 300Mhz to 1.2GHz")
Cc: stable@vger.kernel.org
---
 drivers/clk/mvebu/armada-37xx-periph.c | 45 ++++++++++++++++++++++----
 1 file changed, 39 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/mvebu/armada-37xx-periph.c b/drivers/clk/mvebu/armada-37xx-periph.c
index b15e177bea7e..32ac6b6b7530 100644
--- a/drivers/clk/mvebu/armada-37xx-periph.c
+++ b/drivers/clk/mvebu/armada-37xx-periph.c
@@ -84,6 +84,7 @@ struct clk_pm_cpu {
 	void __iomem *reg_div;
 	u8 shift_div;
 	struct regmap *nb_pm_base;
+	unsigned long l1_expiration;
 };
 
 #define to_clk_double_div(_hw) container_of(_hw, struct clk_double_div, hw)
@@ -504,22 +505,52 @@ static long clk_pm_cpu_round_rate(struct clk_hw *hw, unsigned long rate,
  * 2. Sleep 20ms for stabling VDD voltage
  * 3. Then switch from L1 (500/600 MHz) to L0 (1000/1200 MHz).
  */
-static void clk_pm_cpu_set_rate_wa(unsigned long rate, struct regmap *base)
+static void clk_pm_cpu_set_rate_wa(struct clk_pm_cpu *pm_cpu,
+				   unsigned int new_level, unsigned long rate,
+				   struct regmap *base)
 {
 	unsigned int cur_level;
 
-	if (rate < 1000 * 1000 * 1000)
-		return;
-
 	regmap_read(base, ARMADA_37XX_NB_CPU_LOAD, &cur_level);
 	cur_level &= ARMADA_37XX_NB_CPU_LOAD_MASK;
-	if (cur_level <= ARMADA_37XX_DVFS_LOAD_1)
+
+	if (cur_level == new_level)
+		return;
+
+	/*
+	 * System wants to go to L1 on its own. If we are going from L2/L3,
+	 * remember when 20ms will expire. If from L0, set the value so that
+	 * next switch to L0 won't have to wait.
+	 */
+	if (new_level == ARMADA_37XX_DVFS_LOAD_1) {
+		if (cur_level == ARMADA_37XX_DVFS_LOAD_0)
+			pm_cpu->l1_expiration = jiffies;
+		else
+			pm_cpu->l1_expiration = jiffies + msecs_to_jiffies(20);
 		return;
+	}
+
+	/*
+	 * If we are setting to L2/L3, just invalidate L1 expiration time,
+	 * sleeping is not needed.
+	 */
+	if (rate < 1000*1000*1000)
+		goto invalidate_l1_exp;
+
+	/*
+	 * We are going to L0 with rate >= 1GHz. Check whether we have been at
+	 * L1 for long enough time. If not, go to L1 for 20ms.
+	 */
+	if (pm_cpu->l1_expiration && jiffies >= pm_cpu->l1_expiration)
+		goto invalidate_l1_exp;
 
 	regmap_update_bits(base, ARMADA_37XX_NB_CPU_LOAD,
 			   ARMADA_37XX_NB_CPU_LOAD_MASK,
 			   ARMADA_37XX_DVFS_LOAD_1);
 	msleep(20);
+
+invalidate_l1_exp:
+	pm_cpu->l1_expiration = 0;
 }
 
 static int clk_pm_cpu_set_rate(struct clk_hw *hw, unsigned long rate,
@@ -553,7 +584,9 @@ static int clk_pm_cpu_set_rate(struct clk_hw *hw, unsigned long rate,
 			reg = ARMADA_37XX_NB_CPU_LOAD;
 			mask = ARMADA_37XX_NB_CPU_LOAD_MASK;
 
-			clk_pm_cpu_set_rate_wa(rate, base);
+			/* Apply workaround when base CPU frequency is 1000 or 1200 MHz */
+			if (parent_rate >= 1000*1000*1000)
+				clk_pm_cpu_set_rate_wa(pm_cpu, load_level, rate, base);
 
 			regmap_update_bits(base, reg, mask, load_level);
 
-- 
2.20.1


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

  parent reply	other threads:[~2021-01-14 12:42 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-14 12:40 [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz Pali Rohár
2021-01-14 12:40 ` Pali Rohár
2021-01-14 12:40 ` [PATCH mvebu v2 01/10] arm64: dts: marvell: armada-37xx: add syscon compatible to NB clk node Pali Rohár
2021-01-14 12:40   ` Pali Rohár
2021-04-02 19:50   ` Gregory CLEMENT
2021-04-02 19:50     ` Gregory CLEMENT
2021-01-14 12:40 ` [PATCH mvebu v2 02/10] cpufreq: armada-37xx: Fix setting TBG parent for load levels Pali Rohár
2021-01-14 12:40   ` Pali Rohár
2021-01-14 12:40 ` [PATCH mvebu v2 03/10] clk: mvebu: armada-37xx-periph: remove .set_parent method for CPU PM clock Pali Rohár
2021-01-14 12:40   ` Pali Rohár
2021-02-10  1:58   ` Stephen Boyd
2021-02-10  1:58     ` Stephen Boyd
2021-01-14 12:40 ` [PATCH mvebu v2 04/10] cpufreq: armada-37xx: Fix the AVS value for loads L0 and L1 Pali Rohár
2021-01-14 12:40   ` Pali Rohár
2021-01-14 12:40 ` [PATCH mvebu v2 05/10] clk: mvebu: armada-37xx-periph: Fix switching CPU freq from 250 Mhz to 1 GHz Pali Rohár
2021-01-14 12:40   ` Pali Rohár
2021-02-10  1:58   ` Stephen Boyd
2021-02-10  1:58     ` Stephen Boyd
2021-01-14 12:40 ` Pali Rohár [this message]
2021-01-14 12:40   ` [PATCH mvebu v2 06/10] clk: mvebu: armada-37xx-periph: Fix workaround for switching from L1 to L0 Pali Rohár
2021-02-10  1:58   ` Stephen Boyd
2021-02-10  1:58     ` Stephen Boyd
2021-01-14 12:40 ` [PATCH mvebu v2 07/10] cpufreq: armada-37xx: Fix driver cleanup when registration failed Pali Rohár
2021-01-14 12:40   ` Pali Rohár
2021-01-14 12:40 ` [PATCH mvebu v2 08/10] cpufreq: armada-37xx: Fix determining base CPU frequency Pali Rohár
2021-01-14 12:40   ` Pali Rohár
2021-01-14 12:40 ` [PATCH mvebu v2 09/10] cpufreq: armada-37xx: Remove cur_frequency variable Pali Rohár
2021-01-14 12:40   ` Pali Rohár
2021-03-29 15:00   ` Gregory CLEMENT
2021-03-29 15:00     ` Gregory CLEMENT
2021-03-29 21:44     ` Marek Behún
2021-03-29 21:44       ` Marek Behún
2021-01-14 12:40 ` [PATCH mvebu v2 10/10] cpufreq: armada-37xx: Fix module unloading Pali Rohár
2021-01-14 12:40   ` Pali Rohár
2021-02-01 14:35 ` [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz Tomasz Maciej Nowak
2021-02-01 14:35   ` Tomasz Maciej Nowak
2021-02-03 19:29 ` Anders Trier Olesen
2021-02-03 19:29   ` Anders Trier Olesen
2021-02-22 19:41 ` [PATCH mvebu v3 " Pali Rohár
2021-02-22 19:41   ` Pali Rohár
2021-02-22 19:41   ` [PATCH mvebu v3 01/10] arm64: dts: marvell: armada-37xx: add syscon compatible to NB clk node Pali Rohár
2021-02-22 19:41     ` Pali Rohár
2021-02-22 19:41   ` [PATCH mvebu v3 02/10] cpufreq: armada-37xx: Fix setting TBG parent for load levels Pali Rohár
2021-02-22 19:41     ` Pali Rohár
2021-03-29 14:45     ` Gregory CLEMENT
2021-03-29 14:45       ` Gregory CLEMENT
2021-02-22 19:41   ` [PATCH mvebu v3 03/10] clk: mvebu: armada-37xx-periph: remove .set_parent method for CPU PM clock Pali Rohár
2021-02-22 19:41     ` Pali Rohár
2021-03-29 14:46     ` Gregory CLEMENT
2021-03-29 14:46       ` Gregory CLEMENT
2021-02-22 19:41   ` [PATCH mvebu v3 04/10] cpufreq: armada-37xx: Fix the AVS value for load L1 Pali Rohár
2021-02-22 19:41     ` Pali Rohár
2021-03-29 14:47     ` Gregory CLEMENT
2021-03-29 14:47       ` Gregory CLEMENT
2021-02-22 19:41   ` [PATCH mvebu v3 05/10] clk: mvebu: armada-37xx-periph: Fix switching CPU freq from 250 Mhz to 1 GHz Pali Rohár
2021-02-22 19:41     ` Pali Rohár
2021-03-29 14:48     ` Gregory CLEMENT
2021-03-29 14:48       ` Gregory CLEMENT
2021-02-22 19:41   ` [PATCH mvebu v3 06/10] clk: mvebu: armada-37xx-periph: Fix workaround for switching from L1 to L0 Pali Rohár
2021-02-22 19:41     ` Pali Rohár
2021-03-29 14:49     ` Gregory CLEMENT
2021-03-29 14:49       ` Gregory CLEMENT
2021-02-22 19:41   ` [PATCH mvebu v3 07/10] cpufreq: armada-37xx: Fix driver cleanup when registration failed Pali Rohár
2021-02-22 19:41     ` Pali Rohár
2021-03-29 14:58     ` Gregory CLEMENT
2021-03-29 14:58       ` Gregory CLEMENT
2021-02-22 19:41   ` [PATCH mvebu v3 08/10] cpufreq: armada-37xx: Fix determining base CPU frequency Pali Rohár
2021-02-22 19:41     ` Pali Rohár
2021-03-29 14:59     ` Gregory CLEMENT
2021-03-29 14:59       ` Gregory CLEMENT
2021-02-22 19:41   ` [PATCH mvebu v3 09/10] cpufreq: armada-37xx: Remove cur_frequency variable Pali Rohár
2021-02-22 19:41     ` Pali Rohár
2021-02-22 19:41   ` [PATCH mvebu v3 10/10] cpufreq: armada-37xx: Fix module unloading Pali Rohár
2021-02-22 19:41     ` Pali Rohár
2021-03-01 19:20   ` [PATCH mvebu v3 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz Pali Rohár
2021-03-01 19:20     ` Pali Rohár
2021-03-12  9:12     ` Gregory CLEMENT
2021-03-12  9:12       ` Gregory CLEMENT
2021-03-12  9:27       ` Marek Behún
2021-03-12  9:27         ` Marek Behún
2021-03-28 11:31       ` Pali Rohár
2021-03-28 11:31         ` Pali Rohár
2021-04-08  0:38         ` Stephen Boyd
2021-04-08  0:38           ` Stephen Boyd

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=20210114124032.12765-7-pali@kernel.org \
    --to=pali@kernel.org \
    --cc=a.heider@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=gerald@gk2.net \
    --cc=gregory.clement@bootlin.com \
    --cc=kabel@kernel.org \
    --cc=kostap@marvell.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luka.perkov@sartura.hr \
    --cc=miquel.raynal@bootlin.com \
    --cc=mturquette@baylibre.com \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=sboyd@kernel.org \
    --cc=tmn505@gmail.com \
    --cc=vladimir.vid@sartura.hr \
    /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.