[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6ef3e9a3-77e7-48b7-cbcd-c13db50d0cd9@canonical.com>
Date: Wed, 15 Sep 2021 10:21:24 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
To: Sam Protsenko <semen.protsenko@...aro.org>,
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: Re: [PATCH 1/6] clk: samsung: Enable bus clock on init
On 14/09/2021 17:56, Sam Protsenko wrote:
> 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);
> + }
> + }
> +
Solving this problem in generic way makes sense but your solution is
insufficient. You skipped suspend/resume paths and in such case you
should remove the Exynos5433-specific code.
Best regards,
Krzysztof
Powered by blists - more mailing lists