From: Stanislaw Pal <kuncy7@gmail.com>
To: Jie Luo <jie.luo@oss.qualcomm.com>
Cc: Bjorn Andersson <andersson@kernel.org>,
Stephen Boyd <sboyd@kernel.org>,
Michael Turquette <mturquette@baylibre.com>,
Mieczyslaw Nalewaj <namiltd@yahoo.com>,
Brian Masney <bmasney@redhat.com>,
linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] clk: qcom: ipq-cmn-pll: keep the CMN block bus clocks enabled
Date: Wed, 5 Aug 2026 10:12:40 +0200 [thread overview]
Message-ID: <20260805081240.11497-1-kuncy7@gmail.com> (raw)
In-Reply-To: <1dc44e5e-7787-47f7-938f-1ac0676d96d2@oss.qualcomm.com>
On 8/5/2026 Jie Luo wrote:
> Is there any use case that requires accessing the CMN PLL registers when
> no downstream consumer is active? If not, I don't think a fix is needed
> here. As you may have observed, debugfs clk_summary can still display
> the clock rate correctly even when there is no downstream consumer and
> the AHB and SYS clocks are disabled.
The clk_summary observation does not show what it seems to show, and I
have to correct my own previous mail on the same point: this driver does
not set CLK_GET_RATE_NOCACHE, and clk_core_get_rate_recalc() only calls
.recalc_rate for clocks that have that flag. So clk_summary (and
clk_get_rate()) return the rate cached at registration time, when probe
still held the bus clocks enabled - no register access happens at all.
It displaying correct rates with the clocks gated is exactly the cached
value; it says nothing about whether an actual access would survive.
As for the use case: on IPQ5018 it is booting the SoC. With the clocks
gated after probe, boards hang within milliseconds - 100% reproducible
on some builds, before userspace exists, with no consumer anywhere - and
the only variable that changes the outcome is holding this reference.
That is also why I do not think moving runtime PM references into the
clk ops would help this platform: by your own argument nothing calls the
ops at that point, yet the SoC still dies. Whatever the fatal access is
- a CCF path we have not pinned down, or something else in the same
clock domain - the platform demonstrably does not survive the gate
itself.
One more general point: the CCF gives no guarantee that clk API calls
only happen while some consumer device is runtime-active. The DT device
link keeps the supplier active while the consumer *device* is active,
but a consumer is free to call clk_set_rate()/clk_round_rate() at any
time, including while itself runtime-suspended - and on IPQ5018 there is
no link at all. So "registers are only accessed while a consumer is
active" is not an invariant anything enforces; it just happens to hold
on the platforms where the DT wiring exists.
If there is an alternative fix you would prefer - a different clock
handoff from the bootloader state, describing the in-silicon consumers
in DT, anything else - I am happy to test it on this hardware. But as it
stands, a mainline kernel cannot boot reliably on IPQ5018 without this
change, which is why I believe a fix is needed and Cc'd stable.
Thanks,
Stanislaw
next prev parent reply other threads:[~2026-08-05 8:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-30 19:13 [PATCH] clk: qcom: ipq-cmn-pll: keep the CMN block bus clocks enabled Stanislaw Pal
2026-08-02 20:53 ` Mieczyslaw Nalewaj
2026-08-03 7:14 ` Jie Luo
2026-08-03 9:10 ` Stanislaw Pal
2026-08-04 11:03 ` Jie Luo
2026-08-04 11:58 ` Stanislaw Pal
2026-08-05 4:52 ` Jie Luo
2026-08-05 8:12 ` Stanislaw Pal [this message]
2026-08-06 2:33 ` Jie Luo
2026-08-08 21:45 ` Mieczyslaw Nalewaj
2026-08-09 16:10 ` Stanislaw Pal
2026-08-11 12:54 ` Jie Luo
2026-08-11 19:53 ` Stanislaw Pal
2026-08-04 11:53 ` [PATCH v2] " Stanislaw Pal
2026-08-05 18:53 ` Mieczyslaw Nalewaj
2026-08-05 19:36 ` [PATCH v3] " Stanislaw Pal
2026-08-11 11:48 ` Stanislaw Pal
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=20260805081240.11497-1-kuncy7@gmail.com \
--to=kuncy7@gmail.com \
--cc=andersson@kernel.org \
--cc=bmasney@redhat.com \
--cc=jie.luo@oss.qualcomm.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=namiltd@yahoo.com \
--cc=sboyd@kernel.org \
--cc=stable@vger.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 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.