From: Jerome Brunet <jbrunet@baylibre.com>
To: Chuan Liu <chuan.liu@amlogic.com>
Cc: Stephen Boyd <sboyd@kernel.org>,
Neil Armstrong <neil.armstrong@linaro.org>,
Kevin Hilman <khilman@baylibre.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-amlogic@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH] clk: core: refine disable unused clocks
Date: Fri, 08 Nov 2024 10:59:12 +0100 [thread overview]
Message-ID: <1jcyj62gi7.fsf@starbuckisacylon.baylibre.com> (raw)
In-Reply-To: <85aae140-5c9b-4ff9-a522-549009f62601@amlogic.com> (Chuan Liu's message of "Fri, 8 Nov 2024 17:23:53 +0800")
On Fri 08 Nov 2024 at 17:23, Chuan Liu <chuan.liu@amlogic.com> wrote:
>>>> - if (core->flags & CLK_IGNORE_UNUSED)
>>>> + /*
>>>> + * If the parent is disabled but the gate is open, we should sanitize
>>>> + * the situation. This will avoid an unexpected enable of the clock as
>>>> + * soon as the parent is enabled, without control of CCF.
>>>> + *
>>>> + * Doing so is not possible with a CLK_OPS_PARENT_ENABLE clock without
>>>> + * forcefully enabling a whole part of the subtree. Just let the
>>>> + * situation resolve it self on the first enable of the clock
>>>> + */
>>>> + if (!parent_enabled && (core->flags & CLK_OPS_PARENT_ENABLE))
>
> At first, I couldn't grasp the logic behind the 'return' here. Now it's
> clear. This approach is equivalent to completely giving up on
> handling clocks with CLK_OPS_PARENT_ENABLE feature in
> clk_disable_unused_subtree().
>
No. It's handled correctly as long as the tree is in coherent state.
What is not done anymore is fixing up an inconsistent tree, by this I
mean: A clock with CLK_OPS_PARENT_ENABLE, which report enabled from its
own registers but has its parent disabled.
In that particular case, clk_disable_unused_subtree() won't be turning on
everything to properly disable that one clock. That is the root cause of
the problem you reported initially. The clock is disabled anyway.
Every other case are properly handled (at least I think).
>>>> goto unlock_out;
>>>>
>>>> /*
>>>> @@ -1516,8 +1545,7 @@ static void __init clk_disable_unused_subtree(struct clk_core *core)
>>>>
>>>> unlock_out:
>>>> clk_enable_unlock(flags);
>>>> - if (core->flags & CLK_OPS_PARENT_ENABLE)
>>>> - clk_core_disable_unprepare(core->parent);
>>>> + return (core->flags & CLK_IGNORE_UNUSED) && enabled;
>>>> }
>>>>
>>>> static bool clk_ignore_unused __initdata;
>>>> @@ -1550,16 +1578,16 @@ static int __init clk_disable_unused(void)
>>>> clk_prepare_lock();
>>>>
>>>> hlist_for_each_entry(core, &clk_root_list, child_node)
>>>> - clk_disable_unused_subtree(core);
>>>> + clk_disable_unused_subtree(core, true);
>>>>
>>>> hlist_for_each_entry(core, &clk_orphan_list, child_node)
>>>> - clk_disable_unused_subtree(core);
>>>> + clk_disable_unused_subtree(core, true);
>>>>
>>>> hlist_for_each_entry(core, &clk_root_list, child_node)
>>>> - clk_unprepare_unused_subtree(core);
>>>> + clk_unprepare_unused_subtree(core, true);
>>>>
>>>> hlist_for_each_entry(core, &clk_orphan_list, child_node)
>>>> - clk_unprepare_unused_subtree(core);
>>>> + clk_unprepare_unused_subtree(core, true);
>>>>
>>>> clk_prepare_unlock();
>>>>
>>>> --
>>>> 2.45.2
>>>>
>> --
>> Jerome
--
Jerome
next prev parent reply other threads:[~2024-11-08 9:59 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-29 6:10 [PATCH 0/2] clk: Fix issues related to CLK_IGNORE_UNUSED failures and amlogic glitch free mux Chuan Liu via B4 Relay
2024-09-29 6:10 ` [PATCH 1/2] clk: Fix the CLK_IGNORE_UNUSED failure issue Chuan Liu via B4 Relay
2024-09-30 12:27 ` Jerome Brunet
2024-11-08 13:02 ` Chuan Liu
2024-09-29 6:10 ` [PATCH 2/2] clk: meson: Fix glitch free mux related issues Chuan Liu via B4 Relay
2024-09-30 12:36 ` Jerome Brunet
2024-09-30 20:08 ` Martin Blumenstingl
2024-10-08 5:44 ` Chuan Liu
2024-10-08 6:02 ` Jerome Brunet
2025-09-28 6:05 ` Chuan Liu
2025-09-28 6:40 ` Chuan Liu
2025-09-28 20:55 ` Martin Blumenstingl
2025-09-29 3:15 ` Chuan Liu
2025-09-29 12:36 ` Jerome Brunet
2025-09-30 2:07 ` Chuan Liu
2025-09-29 8:48 ` Jerome Brunet
2025-09-29 9:31 ` Chuan Liu
2025-09-29 12:55 ` Jerome Brunet
2025-09-30 2:04 ` Chuan Liu
2024-09-30 12:33 ` [PATCH 0/2] clk: Fix issues related to CLK_IGNORE_UNUSED failures and amlogic glitch free mux Jerome Brunet
2024-10-04 13:39 ` [RFC PATCH] clk: core: refine disable unused clocks Jerome Brunet
2024-11-08 7:59 ` Chuan Liu
2024-11-08 8:38 ` Jerome Brunet
2024-11-08 9:23 ` Chuan Liu
2024-11-08 9:59 ` Jerome Brunet [this message]
2024-11-08 11:49 ` Chuan Liu
2024-11-12 8:36 ` Jerome Brunet
2024-11-12 10:05 ` Chuan Liu
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=1jcyj62gi7.fsf@starbuckisacylon.baylibre.com \
--to=jbrunet@baylibre.com \
--cc=chuan.liu@amlogic.com \
--cc=khilman@baylibre.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=neil.armstrong@linaro.org \
--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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox