lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1419276708-28294-1-git-send-email-dianders@chromium.org>
Date:	Mon, 22 Dec 2014 11:31:48 -0800
From:	Doug Anderson <dianders@...omium.org>
To:	Heiko Stuebner <heiko@...ech.de>, Chris Zhong <zyw@...k-chips.com>,
	Mike Turquette <mturquette@...aro.org>
Cc:	linux-rockchip@...ts.infradead.org,
	linux-arm-kernel@...ts.infradead.org,
	Doug Anderson <dianders@...omium.org>, sboyd@...eaurora.org,
	linux-kernel@...r.kernel.org
Subject: [PATCH] clk: rockchip: rk3288: Make s2r reliable by switching PLLs to slow mode

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@...omium.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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ