All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jie Luo <jie.luo@oss.qualcomm.com>
To: Mieczyslaw Nalewaj <namiltd@yahoo.com>,
	Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>,
	Stanislaw Pal <kuncy7@gmail.com>
Cc: Bjorn Andersson <andersson@kernel.org>,
	Stephen Boyd <sboyd@kernel.org>,
	Michael Turquette <mturquette@baylibre.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: Mon, 24 Aug 2026 18:28:40 +0800	[thread overview]
Message-ID: <f8b9192f-fe88-4a8e-86f0-6e2c33ed3f31@oss.qualcomm.com> (raw)
In-Reply-To: <8286b42e-0314-477b-ac2e-4b410a97d833@yahoo.com>



On 8/22/2026 7:19 PM, Mieczyslaw Nalewaj wrote:
> On Thu, Aug 20, 2026 at 01:39:52PM +0800, Jie Luo wrote:
>> The CMN PLL output clocks do not depend on the AHB or SYS clocks. They
>> continue to operate correctly at the fixed rates even when the AHB
>> and SYS clocks are disabled.
> 
> The PLL outputs keep running, but the AHB register interface does not.
> Once autosuspend gates AHB/SYS, any later register access to the CMN
> block hangs the bus. That is the bug we are fixing.

As far as I understand, there is no expectation that the CMN PLL
registers need to be accessed after the CMN PLL driver has finished
loading on IPQ5018.

Could we identify which module is blocked after the CMN PLL driver probe
completes?

> 
>> On IPQ5018, the CMN PLL provides a 50 MHz output clock that is used as
>> the reference clock for the connected Ethernet device.
> 
> Correct, and that consumer is hardwired in silicon — the internal GE
> PHY and uniphy blocks take proxied this clock without any Linux driver
> calling clk_get() on it. Therefore no device link exists to keep the
> provider active, and CCF rightfully gates the bus clocks after probe.

The UNIPHY block is the consumer of this 50 MHz clock. It divides and
gates the 50 MHz clock, then routes it to the connected PHY or switch
on the IPQ5018 platform.

Would you be able to try this approach in your code workspace? Since the
UNIPHY driver is not currently available in the upstream kernel, this
may be a practical way to validate whether keeping the relevant clock
path active through the UNIPHY side resolves the issue.

UNIPHY register offset: 0x74

Bit 1: Clock divider control
0: no divide-by-2
1: divide by 2 enabled

Bit 0: Clock gate control
0: clock disabled
1: clock enabled

> 
> Adding DT consumers would require touching PHY and datapath drivers
> across multiple subsystems just to create artificial clk references.
> That is not a stable material. The v4 driver fix is minimal, correct,
> and self-contained.
> 
> Reviewed-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
> 


  reply	other threads:[~2026-08-24 10:28 UTC|newest]

Thread overview: 24+ 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
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-19 13:00       ` Konrad Dybcio
2026-08-20  5:39         ` Jie Luo
2026-08-22 11:19           ` Mieczyslaw Nalewaj
2026-08-24 10:28             ` Jie Luo [this message]
2026-08-24 19:06               ` Mieczyslaw Nalewaj
2026-08-24 20:23               ` 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
2026-08-13  9:33     ` [PATCH v4] " 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=f8b9192f-fe88-4a8e-86f0-6e2c33ed3f31@oss.qualcomm.com \
    --to=jie.luo@oss.qualcomm.com \
    --cc=andersson@kernel.org \
    --cc=bmasney@redhat.com \
    --cc=konrad.dybcio@oss.qualcomm.com \
    --cc=kuncy7@gmail.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.