All of lore.kernel.org
 help / color / mirror / Atom feed
From: Doug Anderson <dianders@chromium.org>
To: Heiko Stuebner <heiko@sntech.de>,
	Chris Zhong <zyw@rock-chips.com>,
	Mike Turquette <mturquette@linaro.org>
Cc: linux-rockchip@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	Doug Anderson <dianders@chromium.org>,
	sboyd@codeaurora.org, linux-kernel@vger.kernel.org
Subject: [PATCH] clk: rockchip: rk3288: Make s2r reliable by switching PLLs to slow mode
Date: Mon, 22 Dec 2014 11:31:48 -0800	[thread overview]
Message-ID: <1419276708-28294-1-git-send-email-dianders@chromium.org> (raw)

We've been seeing some crashes at resume time on rk3288-based systems.
On some machines they simply never wake up from suspend.  Symptoms
include:

- System clearly got to sleep OK.  Power consumption is low, the PWM
  for the PWM regulator has stopped, and the "global_pwroff" output
  shows that the system is down.

- When system tries to wake up power consumption goes up.

- No kernel resume code (which was left in PMU SRAM) ran.  We added
  some basic logging to this code (write to a location in SRAM right
  at resume time) and didn't see the logging run.

It appears that we can fix the problem by slowing down APLL before we
suspend.  On the system I tested things seemed reliable if I disabled
1.8GHz and 1.7GHz.  The Mask ROM itself tries to slow things down
(which is why PLLs are in slow mode by the time we get to the kernel),
but apparently it is crashing before it even gets there.

We'll be super paranoid and not just go down to 1.6GHz but we'll match
what the Mask ROM seems to be doing and go into slow mode.  We'll also
be safe and put all PLLs (not just APLL) into slow mode (well, except
DPLL which is needed for SDRAM).  We'll even put NPLL into slow mode
which the Mask ROM didn't do (not that it's used for much important
stuff at early resume time).

Note that the old Rockchip reference code did something just like
this, though they jammed it into pm.c instead of putting it in the
syscore ops of the clock driver.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
 drivers/clk/rockchip/clk-rk3288.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/clk/rockchip/clk-rk3288.c b/drivers/clk/rockchip/clk-rk3288.c
index ac6be7c..8cf4210 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -805,6 +805,20 @@ static int rk3288_clk_suspend(void)
 		rk3288_saved_cru_regs[i] =
 				readl_relaxed(rk3288_cru_base + reg_id);
 	}
+
+	/*
+	 * Switch PLLs other than DPLL (for SDRAM) to slow mode to
+	 * avoid crashes on resume. The Mask ROM on the system will
+	 * put APLL, CPLL, and GPLL into slow mode at resume time
+	 * anyway (which is why we restore them), but we might not
+	 * even make it to the Mask ROM if this isn't done at suspend
+	 * time.
+	 *
+	 * NOTE: only APLL truly matters here, but we'll do them all.
+	 */
+
+	writel_relaxed(0xf3030000, rk3288_cru_base + RK3288_MODE_CON);
+
 	return 0;
 }
 
-- 
2.2.0.rc0.207.ga3a616c


WARNING: multiple messages have this Message-ID (diff)
From: dianders@chromium.org (Doug Anderson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] clk: rockchip: rk3288: Make s2r reliable by switching PLLs to slow mode
Date: Mon, 22 Dec 2014 11:31:48 -0800	[thread overview]
Message-ID: <1419276708-28294-1-git-send-email-dianders@chromium.org> (raw)

We've been seeing some crashes at resume time on rk3288-based systems.
On some machines they simply never wake up from suspend.  Symptoms
include:

- System clearly got to sleep OK.  Power consumption is low, the PWM
  for the PWM regulator has stopped, and the "global_pwroff" output
  shows that the system is down.

- When system tries to wake up power consumption goes up.

- No kernel resume code (which was left in PMU SRAM) ran.  We added
  some basic logging to this code (write to a location in SRAM right
  at resume time) and didn't see the logging run.

It appears that we can fix the problem by slowing down APLL before we
suspend.  On the system I tested things seemed reliable if I disabled
1.8GHz and 1.7GHz.  The Mask ROM itself tries to slow things down
(which is why PLLs are in slow mode by the time we get to the kernel),
but apparently it is crashing before it even gets there.

We'll be super paranoid and not just go down to 1.6GHz but we'll match
what the Mask ROM seems to be doing and go into slow mode.  We'll also
be safe and put all PLLs (not just APLL) into slow mode (well, except
DPLL which is needed for SDRAM).  We'll even put NPLL into slow mode
which the Mask ROM didn't do (not that it's used for much important
stuff at early resume time).

Note that the old Rockchip reference code did something just like
this, though they jammed it into pm.c instead of putting it in the
syscore ops of the clock driver.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
 drivers/clk/rockchip/clk-rk3288.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/clk/rockchip/clk-rk3288.c b/drivers/clk/rockchip/clk-rk3288.c
index ac6be7c..8cf4210 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -805,6 +805,20 @@ static int rk3288_clk_suspend(void)
 		rk3288_saved_cru_regs[i] =
 				readl_relaxed(rk3288_cru_base + reg_id);
 	}
+
+	/*
+	 * Switch PLLs other than DPLL (for SDRAM) to slow mode to
+	 * avoid crashes on resume. The Mask ROM on the system will
+	 * put APLL, CPLL, and GPLL into slow mode at resume time
+	 * anyway (which is why we restore them), but we might not
+	 * even make it to the Mask ROM if this isn't done at suspend
+	 * time.
+	 *
+	 * NOTE: only APLL truly matters here, but we'll do them all.
+	 */
+
+	writel_relaxed(0xf3030000, rk3288_cru_base + RK3288_MODE_CON);
+
 	return 0;
 }
 
-- 
2.2.0.rc0.207.ga3a616c

             reply	other threads:[~2014-12-22 19:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-22 19:31 Doug Anderson [this message]
2014-12-22 19:31 ` [PATCH] clk: rockchip: rk3288: Make s2r reliable by switching PLLs to slow mode Doug Anderson
2015-01-02 21:20 ` Heiko Stübner
2015-01-02 21:20   ` Heiko Stübner

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=1419276708-28294-1-git-send-email-dianders@chromium.org \
    --to=dianders@chromium.org \
    --cc=heiko@sntech.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mturquette@linaro.org \
    --cc=sboyd@codeaurora.org \
    --cc=zyw@rock-chips.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.