From: Marek Szyprowski <m.szyprowski@samsung.com> To: Maxime Ripard <maxime@cerno.tech> Cc: Mike Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, linux-clk@vger.kernel.org, Dmitry Osipenko <dmitry.osipenko@collabora.com>, 'Linux Samsung SOC' <linux-samsung-soc@vger.kernel.org>, linux-amlogic@lists.infradead.org Subject: Re: [PATCH v2 3/3] clk: Drop the rate range on clk_put Date: Thu, 31 Mar 2022 11:56:51 +0200 [thread overview] Message-ID: <7465a7dc-c45e-2612-4c39-d15eceb9b75c@samsung.com> (raw) In-Reply-To: <20220330084710.3r6b5pjspz5hdmy6@houat> Hi, On 30.03.2022 10:47, Maxime Ripard wrote: > On Wed, Mar 30, 2022 at 10:06:13AM +0200, Marek Szyprowski wrote: >> On 25.03.2022 17:11, Maxime Ripard wrote: >>> While the current code will trigger a new clk_set_rate call whenever the >>> rate boundaries are changed through clk_set_rate_range, this doesn't >>> occur when clk_put() is called. >>> >>> However, this is essentially equivalent since, after clk_put() >>> completes, those boundaries won't be enforced anymore. >>> >>> Let's add a call to clk_set_rate_range in clk_put to make sure those >>> rate boundaries are dropped and the clock drivers can react. >>> >>> Let's also add a few tests to make sure this case is covered. >>> >>> Fixes: c80ac50cbb37 ("clk: Always set the rate on clk_set_range_rate") >>> Signed-off-by: Maxime Ripard <maxime@cerno.tech> >> This patch landed recently in linux-next 20220328 as commit 7dabfa2bc480 >> ("clk: Drop the rate range on clk_put()"). Sadly it breaks booting of >> the few of my test systems: Samsung ARM 32bit Exynos3250 based Rinato >> board and all Amlogic Meson G12B/SM1 based boards (Odroid C4, N2, Khadas >> VIM3/VIM3l). Rinato hangs always with the following oops: >> >> --->8--- >> >> Kernel panic - not syncing: MCT hangs after writing 4 (offset:0x420) >> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.17.0-rc1-00014-g7dabfa2bc480 >> #11551 >> Hardware name: Samsung Exynos (Flattened Device Tree) >> unwind_backtrace from show_stack+0x10/0x14 >> show_stack from dump_stack_lvl+0x58/0x70 >> dump_stack_lvl from panic+0x10c/0x328 >> panic from exynos4_mct_tick_stop+0x0/0x2c >> ---[ end Kernel panic - not syncing: MCT hangs after writing 4 >> (offset:0x420) ]--- >> >> --->8--- >> >> Amlogic boards hang randomly during early userspace init, usually just >> after loading the driver modules. >> >> Reverting $subject on top of linux-next fixes all those problems. >> >> I will try to analyze it a bit more and if possible provide some more >> useful/meaning full logs later. > I'm not sure what could go wrong there, but if you can figure out the > clock, if it tries to set a new rate and what rate it is, it would be > awesome :) So far I've noticed that the problem is caused by setting rate of some clocks to zero. The following patch fixes my issues: diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index 32a9eaf35c6b..39cab08dbecb 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -2201,6 +2201,9 @@ static int clk_core_set_rate_nolock(struct clk_core *core, if (!core) return 0; + if (req_rate == 0) + return 0; + rate = clk_core_req_round_rate_nolock(core, req_rate); /* bail early if nothing to do */ -- I will soon grab the call stack and relevant clock topology show how the rate is set to zero. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
WARNING: multiple messages have this Message-ID (diff)
From: Marek Szyprowski <m.szyprowski@samsung.com> To: Maxime Ripard <maxime@cerno.tech> Cc: Mike Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, linux-clk@vger.kernel.org, Dmitry Osipenko <dmitry.osipenko@collabora.com>, 'Linux Samsung SOC' <linux-samsung-soc@vger.kernel.org>, linux-amlogic@lists.infradead.org Subject: Re: [PATCH v2 3/3] clk: Drop the rate range on clk_put Date: Thu, 31 Mar 2022 11:56:51 +0200 [thread overview] Message-ID: <7465a7dc-c45e-2612-4c39-d15eceb9b75c@samsung.com> (raw) In-Reply-To: <20220330084710.3r6b5pjspz5hdmy6@houat> Hi, On 30.03.2022 10:47, Maxime Ripard wrote: > On Wed, Mar 30, 2022 at 10:06:13AM +0200, Marek Szyprowski wrote: >> On 25.03.2022 17:11, Maxime Ripard wrote: >>> While the current code will trigger a new clk_set_rate call whenever the >>> rate boundaries are changed through clk_set_rate_range, this doesn't >>> occur when clk_put() is called. >>> >>> However, this is essentially equivalent since, after clk_put() >>> completes, those boundaries won't be enforced anymore. >>> >>> Let's add a call to clk_set_rate_range in clk_put to make sure those >>> rate boundaries are dropped and the clock drivers can react. >>> >>> Let's also add a few tests to make sure this case is covered. >>> >>> Fixes: c80ac50cbb37 ("clk: Always set the rate on clk_set_range_rate") >>> Signed-off-by: Maxime Ripard <maxime@cerno.tech> >> This patch landed recently in linux-next 20220328 as commit 7dabfa2bc480 >> ("clk: Drop the rate range on clk_put()"). Sadly it breaks booting of >> the few of my test systems: Samsung ARM 32bit Exynos3250 based Rinato >> board and all Amlogic Meson G12B/SM1 based boards (Odroid C4, N2, Khadas >> VIM3/VIM3l). Rinato hangs always with the following oops: >> >> --->8--- >> >> Kernel panic - not syncing: MCT hangs after writing 4 (offset:0x420) >> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.17.0-rc1-00014-g7dabfa2bc480 >> #11551 >> Hardware name: Samsung Exynos (Flattened Device Tree) >> unwind_backtrace from show_stack+0x10/0x14 >> show_stack from dump_stack_lvl+0x58/0x70 >> dump_stack_lvl from panic+0x10c/0x328 >> panic from exynos4_mct_tick_stop+0x0/0x2c >> ---[ end Kernel panic - not syncing: MCT hangs after writing 4 >> (offset:0x420) ]--- >> >> --->8--- >> >> Amlogic boards hang randomly during early userspace init, usually just >> after loading the driver modules. >> >> Reverting $subject on top of linux-next fixes all those problems. >> >> I will try to analyze it a bit more and if possible provide some more >> useful/meaning full logs later. > I'm not sure what could go wrong there, but if you can figure out the > clock, if it tries to set a new rate and what rate it is, it would be > awesome :) So far I've noticed that the problem is caused by setting rate of some clocks to zero. The following patch fixes my issues: diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index 32a9eaf35c6b..39cab08dbecb 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -2201,6 +2201,9 @@ static int clk_core_set_rate_nolock(struct clk_core *core, if (!core) return 0; + if (req_rate == 0) + return 0; + rate = clk_core_req_round_rate_nolock(core, req_rate); /* bail early if nothing to do */ -- I will soon grab the call stack and relevant clock topology show how the rate is set to zero. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic
next prev parent reply other threads:[~2022-03-31 9:57 UTC|newest] Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-25 16:11 [PATCH v2 0/3] clk: Some Clock Range Fixes Maxime Ripard 2022-03-25 16:11 ` [PATCH v2 1/3] clk: Initialize orphan req_rate Maxime Ripard 2022-03-29 18:36 ` Stephen Boyd 2022-03-25 16:11 ` [PATCH v2 2/3] clk: test: Test clk_set_rate_range on orphan mux Maxime Ripard 2022-03-29 18:36 ` Stephen Boyd 2022-03-25 16:11 ` [PATCH v2 3/3] clk: Drop the rate range on clk_put Maxime Ripard 2022-03-29 18:36 ` Stephen Boyd [not found] ` <CGME20220330080612eucas1p195caaf35d900412de762a27ae02b7b9e@eucas1p1.samsung.com> 2022-03-30 8:06 ` Marek Szyprowski 2022-03-30 8:06 ` Marek Szyprowski 2022-03-30 8:47 ` Maxime Ripard 2022-03-30 8:47 ` Maxime Ripard 2022-03-31 9:42 ` Tony Lindgren 2022-03-31 9:42 ` Tony Lindgren 2022-03-31 9:42 ` Tony Lindgren 2022-03-31 9:54 ` Maxime Ripard 2022-03-31 9:54 ` Maxime Ripard 2022-03-31 9:54 ` Maxime Ripard 2022-03-31 15:00 ` Tony Lindgren 2022-03-31 15:00 ` Tony Lindgren 2022-03-31 15:00 ` Tony Lindgren 2022-03-31 15:31 ` Maxime Ripard 2022-03-31 15:31 ` Maxime Ripard 2022-03-31 15:31 ` Maxime Ripard 2022-03-31 17:00 ` Tony Lindgren 2022-03-31 17:00 ` Tony Lindgren 2022-03-31 17:00 ` Tony Lindgren 2022-03-31 21:58 ` Stephen Boyd 2022-03-31 21:58 ` Stephen Boyd 2022-03-31 21:58 ` Stephen Boyd 2022-04-01 12:28 ` Maxime Ripard 2022-04-01 12:28 ` Maxime Ripard 2022-04-01 12:28 ` Maxime Ripard 2022-04-03 2:14 ` Stephen Boyd 2022-04-03 2:14 ` Stephen Boyd 2022-04-03 2:14 ` Stephen Boyd 2022-04-01 11:55 ` (EXT) " Alexander Stein 2022-04-01 11:55 ` Alexander Stein 2022-04-01 11:55 ` Alexander Stein 2022-04-01 12:27 ` Maxime Ripard 2022-04-01 12:27 ` Maxime Ripard 2022-04-01 12:27 ` Maxime Ripard 2022-04-01 12:59 ` (EXT) " Alexander Stein 2022-04-01 12:59 ` Alexander Stein 2022-04-01 12:59 ` Alexander Stein 2022-04-01 13:04 ` Maxime Ripard 2022-04-01 13:04 ` Maxime Ripard 2022-04-01 13:04 ` Maxime Ripard 2022-04-01 13:07 ` (EXT) " Alexander Stein 2022-04-01 13:07 ` Alexander Stein 2022-04-01 13:07 ` Alexander Stein 2022-04-01 13:34 ` Maxime Ripard 2022-04-01 13:34 ` Maxime Ripard 2022-04-01 13:34 ` Maxime Ripard 2022-04-01 13:49 ` (EXT) " Alexander Stein 2022-04-01 13:49 ` Alexander Stein 2022-04-01 13:49 ` Alexander Stein 2022-04-01 14:55 ` Maxime Ripard 2022-04-01 14:55 ` Maxime Ripard 2022-04-01 14:55 ` Maxime Ripard 2022-04-04 7:06 ` (EXT) " Alexander Stein 2022-04-04 7:06 ` Alexander Stein 2022-04-04 7:06 ` Alexander Stein 2022-04-04 7:27 ` Maxime Ripard 2022-04-04 7:27 ` Maxime Ripard 2022-04-04 7:27 ` Maxime Ripard 2022-04-04 10:54 ` (EXT) " Alexander Stein 2022-04-04 10:54 ` Alexander Stein 2022-04-04 10:54 ` Alexander Stein 2022-04-07 8:09 ` Maxime Ripard 2022-04-07 8:09 ` Maxime Ripard 2022-04-07 8:09 ` Maxime Ripard 2022-04-02 17:01 ` Maxime Ripard 2022-04-02 17:01 ` Maxime Ripard 2022-04-02 17:01 ` Maxime Ripard 2022-04-07 7:53 ` Maxime Ripard 2022-04-07 7:53 ` Maxime Ripard 2022-04-07 7:53 ` Maxime Ripard 2022-04-07 8:03 ` Tony Lindgren 2022-04-07 8:03 ` Tony Lindgren 2022-04-07 8:03 ` Tony Lindgren 2022-04-07 11:08 ` Tony Lindgren 2022-04-07 11:08 ` Tony Lindgren 2022-04-07 11:08 ` Tony Lindgren 2022-04-07 13:45 ` Maxime Ripard 2022-04-07 13:45 ` Maxime Ripard 2022-04-07 13:45 ` Maxime Ripard 2022-04-08 5:03 ` Tony Lindgren 2022-04-08 5:03 ` Tony Lindgren 2022-04-08 5:03 ` Tony Lindgren 2022-03-31 9:56 ` Marek Szyprowski [this message] 2022-03-31 9:56 ` Marek Szyprowski 2022-03-31 10:19 ` Maxime Ripard 2022-03-31 10:19 ` Maxime Ripard
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=7465a7dc-c45e-2612-4c39-d15eceb9b75c@samsung.com \ --to=m.szyprowski@samsung.com \ --cc=dmitry.osipenko@collabora.com \ --cc=linux-amlogic@lists.infradead.org \ --cc=linux-clk@vger.kernel.org \ --cc=linux-samsung-soc@vger.kernel.org \ --cc=maxime@cerno.tech \ --cc=mturquette@baylibre.com \ --cc=sboyd@kernel.org \ /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: linkBe 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.