All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tero Kristo <t-kristo@ti.com>
To: <sboyd@codeaurora.org>, <mturquette@baylibre.com>
Cc: <linux-clk@vger.kernel.org>, <linux-omap@vger.kernel.org>,
	<tony@atomide.com>
Subject: [PATCHv2 04/28] clk: ti: clkctrl: use fallback udelay approach if timekeeping is suspended
Date: Thu, 9 Nov 2017 11:15:14 +0200	[thread overview]
Message-ID: <1510218917-1725-2-git-send-email-t-kristo@ti.com> (raw)
In-Reply-To: <1510218917-1725-1-git-send-email-t-kristo@ti.com>

In certain cases it is possible that the timekeeping has been suspended
already when attempting to disable/enable a clkctrl clock. This will
happen at least on am43xx platform when attempting to enable / disable
the clockevent source itself, burping out a warning from timekeeping core.

The sequence of events leading to this:
-> timekeeping_suspend()
 -> clockevents_suspend()
  -> omap_clkevt_idle()
   -> omap_hwmod_idle()
    -> _omap4_clkctrl_clk_disable()
     -> _omap4_is_timeout()

Avoid the issue by checking if the timekeeping is suspended and using
the fallback udelay approach for checking timeouts.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 drivers/clk/ti/clkctrl.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/ti/clkctrl.c b/drivers/clk/ti/clkctrl.c
index 284ba449..38dbcc1 100644
--- a/drivers/clk/ti/clkctrl.c
+++ b/drivers/clk/ti/clkctrl.c
@@ -21,6 +21,7 @@
 #include <linux/of_address.h>
 #include <linux/clk/ti.h>
 #include <linux/delay.h>
+#include <linux/timekeeping.h>
 #include "clock.h"
 
 #define NO_IDLEST			0x1
@@ -90,7 +91,18 @@ static bool _omap4_is_ready(u32 val)
 
 static bool _omap4_is_timeout(union omap4_timeout *time, u32 timeout)
 {
-	if (unlikely(_early_timeout)) {
+	/*
+	 * There are two special cases where ktime_to_ns() can't be
+	 * used to track the timeouts. First one is during early boot
+	 * when the timers haven't been initialized yet. The second
+	 * one is during suspend-resume cycle while timekeeping is
+	 * being suspended / resumed. Clocksource for the system
+	 * can be from a timer that requires pm_runtime access, which
+	 * will eventually bring us here with timekeeping_suspended,
+	 * during both suspend entry and resume paths. This happens
+	 * at least on am43xx platform.
+	 */
+	if (unlikely(_early_timeout || timekeeping_suspended)) {
 		if (time->cycles++ < timeout) {
 			udelay(1);
 			return false;
-- 
1.9.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

WARNING: multiple messages have this Message-ID (diff)
From: Tero Kristo <t-kristo@ti.com>
To: sboyd@codeaurora.org, mturquette@baylibre.com
Cc: linux-clk@vger.kernel.org, linux-omap@vger.kernel.org, tony@atomide.com
Subject: [PATCHv2 04/28] clk: ti: clkctrl: use fallback udelay approach if timekeeping is suspended
Date: Thu, 9 Nov 2017 11:15:14 +0200	[thread overview]
Message-ID: <1510218917-1725-2-git-send-email-t-kristo@ti.com> (raw)
In-Reply-To: <1510218917-1725-1-git-send-email-t-kristo@ti.com>

In certain cases it is possible that the timekeeping has been suspended
already when attempting to disable/enable a clkctrl clock. This will
happen at least on am43xx platform when attempting to enable / disable
the clockevent source itself, burping out a warning from timekeeping core.

The sequence of events leading to this:
-> timekeeping_suspend()
 -> clockevents_suspend()
  -> omap_clkevt_idle()
   -> omap_hwmod_idle()
    -> _omap4_clkctrl_clk_disable()
     -> _omap4_is_timeout()

Avoid the issue by checking if the timekeeping is suspended and using
the fallback udelay approach for checking timeouts.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 drivers/clk/ti/clkctrl.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/ti/clkctrl.c b/drivers/clk/ti/clkctrl.c
index 284ba449..38dbcc1 100644
--- a/drivers/clk/ti/clkctrl.c
+++ b/drivers/clk/ti/clkctrl.c
@@ -21,6 +21,7 @@
 #include <linux/of_address.h>
 #include <linux/clk/ti.h>
 #include <linux/delay.h>
+#include <linux/timekeeping.h>
 #include "clock.h"
 
 #define NO_IDLEST			0x1
@@ -90,7 +91,18 @@ static bool _omap4_is_ready(u32 val)
 
 static bool _omap4_is_timeout(union omap4_timeout *time, u32 timeout)
 {
-	if (unlikely(_early_timeout)) {
+	/*
+	 * There are two special cases where ktime_to_ns() can't be
+	 * used to track the timeouts. First one is during early boot
+	 * when the timers haven't been initialized yet. The second
+	 * one is during suspend-resume cycle while timekeeping is
+	 * being suspended / resumed. Clocksource for the system
+	 * can be from a timer that requires pm_runtime access, which
+	 * will eventually bring us here with timekeeping_suspended,
+	 * during both suspend entry and resume paths. This happens
+	 * at least on am43xx platform.
+	 */
+	if (unlikely(_early_timeout || timekeeping_suspended)) {
 		if (time->cycles++ < timeout) {
 			udelay(1);
 			return false;
-- 
1.9.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

  reply	other threads:[~2017-11-09  9:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-09  9:15 [PATCHv2 00/28] clk: ti: clkctrl fixes + support for new SoCs Tero Kristo
2017-11-09  9:15 ` Tero Kristo
2017-11-09  9:15 ` Tero Kristo [this message]
2017-11-09  9:15   ` [PATCHv2 04/28] clk: ti: clkctrl: use fallback udelay approach if timekeeping is suspended Tero Kristo
2017-11-14  2:06   ` Stephen Boyd
2017-11-09  9:15 ` [PATCHv2 05/28] clk: ti: convert retry_init param to use void data type Tero Kristo
2017-11-09  9:15   ` Tero Kristo
2017-11-14  2:07   ` Stephen Boyd
2017-11-09  9:15 ` [PATCHv2 06/28] clk: ti: clkctrl: add support for retrying failed init Tero Kristo
2017-11-09  9:15   ` Tero Kristo
2017-11-14  2:07   ` Stephen Boyd
2017-11-09  9:15 ` [PATCHv2 23/28] clk: ti: am43xx: add clkctrl clock data Tero Kristo
2017-11-09  9:15   ` Tero Kristo
2017-11-14  2:07   ` 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=1510218917-1725-2-git-send-email-t-kristo@ti.com \
    --to=t-kristo@ti.com \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=sboyd@codeaurora.org \
    --cc=tony@atomide.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.