[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20210914155607.14122-2-semen.protsenko@linaro.org>
Date: Tue, 14 Sep 2021 18:56:02 +0300
From: Sam Protsenko <semen.protsenko@...aro.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
Sylwester Nawrocki <s.nawrocki@...sung.com>,
Paweł Chmiel <pawel.mikolaj.chmiel@...il.com>,
Chanwoo Choi <cw00.choi@...sung.com>,
Tomasz Figa <tomasz.figa@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Stephen Boyd <sboyd@...nel.org>,
Michael Turquette <mturquette@...libre.com>
Cc: Ryu Euiyoul <ryu.real@...sung.com>, Tom Gall <tom.gall@...aro.org>,
Sumit Semwal <sumit.semwal@...aro.org>,
John Stultz <john.stultz@...aro.org>,
Amit Pundir <amit.pundir@...aro.org>,
devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-samsung-soc@...r.kernel.org
Subject: [PATCH 1/6] clk: samsung: Enable bus clock on init
By default if bus clock has no users its "enable count" value is 0. It
might be actually running if it's already enabled in bootloader, but
then in some cases it can be disabled by mistake. For example, such case
was observed when dw_mci_probe() enabled bus clock, then failed to do
something and disabled that bus clock on error path. After that even
attempt to read the 'clk_summary' file in DebugFS freezed forever, as
CMU bus clock ended up being disabled and it wasn't possible to access
CMU registers anymore.
To avoid such cases, CMU driver must increment the ref count for that
bus clock by running clk_prepare_enable(). There is already existing
'.clk_name' field in struct samsung_cmu_info, exactly for that reason.
It was added in commit 523d3de41f02 ("clk: samsung: exynos5433: Add
support for runtime PM"). But the clock is actually enabled only in
Exynos5433 clock driver. Let's mimic what is done there in generic
samsung_cmu_register_one() function, so other drivers can benefit from
that `.clk_name' field. As was described above, it might be helpful not
only for PM reasons, but also to prevent possible erroneous clock gating
on error paths.
Another way to workaround that issue would be to use CLOCK_IS_CRITICAL
flag for corresponding gate clocks. But that might be not very good
design decision, as we might still want to disable that bus clock, e.g.
on PM suspend.
Signed-off-by: Sam Protsenko <semen.protsenko@...aro.org>
---
drivers/clk/samsung/clk.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c
index 1949ae7851b2..da65149fa502 100644
--- a/drivers/clk/samsung/clk.c
+++ b/drivers/clk/samsung/clk.c
@@ -357,6 +357,19 @@ struct samsung_clk_provider * __init samsung_cmu_register_one(
ctx = samsung_clk_init(np, reg_base, cmu->nr_clk_ids);
+ /* Keep bus clock running, so it's possible to access CMU registers */
+ if (cmu->clk_name) {
+ struct clk *bus_clk;
+
+ bus_clk = __clk_lookup(cmu->clk_name);
+ if (bus_clk) {
+ clk_prepare_enable(bus_clk);
+ } else {
+ pr_err("%s: could not find bus clock %s\n", __func__,
+ cmu->clk_name);
+ }
+ }
+
if (cmu->pll_clks)
samsung_clk_register_pll(ctx, cmu->pll_clks, cmu->nr_pll_clks,
reg_base);
--
2.30.2
Powered by blists - more mailing lists