All of lore.kernel.org
 help / color / mirror / Atom feed
From: Drew Fustini <fustini@kernel.org>
To: Yao Zi <ziyao@disroot.org>
Cc: Guo Ren <guoren@kernel.org>, Fu Wei <wefu@redhat.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Jisheng Zhang <jszhang@kernel.org>,
	Yangtao Li <frank.li@vivo.com>,
	linux-riscv@lists.infradead.org, linux-clk@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] clk: thead: th1520-ap: Correctly refer the parent for c910 and osc_12m
Date: Sat, 5 Jul 2025 21:31:29 -0700	[thread overview]
Message-ID: <aGn8IVkWQJjHMfCT@x1> (raw)
In-Reply-To: <aGnaZjMoWbW_FZfj@pie>

On Sun, Jul 06, 2025 at 02:07:51AM +0000, Yao Zi wrote:
> On Sat, Jul 05, 2025 at 05:08:09PM -0700, Drew Fustini wrote:
> > On Sat, Jul 05, 2025 at 05:20:28AM +0000, Yao Zi wrote:
> > > clk_orphan_dump shows two suspicious orphan clocks on TH1520 when
> > > booting the kernel with mainline U-Boot,
> > > 
> > > 	$ cat /sys/kernel/debug/clk/clk_orphan_dump | jq 'keys'
> > > 	[
> > > 	  "c910",
> > > 	  "osc_12m"
> > > 	]
> > > 
> > > where the correct parents should be c910-i0 for c910, and osc_24m for
> > > osc_12m.
> > 
> > Thanks for sending this patch. However, I only see "osc_12m" listed in
> > clk_orphan_dump. I tried the current next, torvalds master and v6.15 but
> > I didn't ever see "c910" appear [1]. What branch are you using?
> 
> I think it has something to do with the bootloader: as you could see in
> your clk_orphan_dump, the c910 clock is reparented to cpu-pll1, the
> second possible parent which could be correctly resolved by the CCF,
> thus c910 doesn't appear in the clk_orphan_dump.
> 
> But with the mainline U-Boot which doesn't reparent or reclock c910 on
> startup, c910 should remain the reset state and take c910-i0 as parent,
> and appear in the clk_orphan_dump.

Ah, thanks for the explanation. I'm on an old build:

U-Boot SPL 2020.01-g55b713fa (Jan 12 2024 - 02:17:34 +0000)
FM[1] lpddr4x dualrank freq=3733 64bit dbi_off=n sdram init
U-Boot 2020.01-g55b713fa (Jan 12 2024 - 02:17:34 +0000)

I would like to run mainline but I have the 8GB RAM LPi4a. Does mainline
only work for the 16GB version right now?

> Another way to confirm the bug is to examine
> /sys/kernel/debug/clk/c910/clk_possible_parents: without the patch, it
> should be something like
> 
> 	osc_24m cpu-pll1
> 
> c910's parents are defined as
> 
> 	static const struct clk_parent_data c910_parents[] = {
> 		{ .hw = &c910_i0_clk.common.hw },
> 		{ .hw = &cpu_pll1_clk.common.hw }
> 	};
> 
> and the debugfs output looks obviously wrong.

Thanks, yeah, without the patch I also see:

==> c910-i0/clk_possible_parents <==
cpu-pll0 osc_24m

> 
> There's another bug in CCF[1] which causes unresolvable parents are
> shown as the clock-output-names of the clock controller's first parent
> in debugfs, explaining the output.

Thanks for that fix. I now see '(missing)' for c910 too when I apply
that patch:

root@lpi4amain:/sys/kernel/debug/clk# head c910/clk_possible_parents
(missing) cpu-pll1

> 
> > I think it would be best for this patch to be split into separate
> > patches for osc_12m and c910.
> 
> Okay, I originally thought these are relatively small fixes targeting
> a single driver, hence put them together. I'll split it into two patches
> in v2.

I think the osc_12m is good as-is but I'm not sure what Stephen will
think about using the string "c910-i0" in c910_parents[]. I think
splitting it up will make discussion go faster.

Thanks,
Drew

WARNING: multiple messages have this Message-ID (diff)
From: Drew Fustini <fustini@kernel.org>
To: Yao Zi <ziyao@disroot.org>
Cc: Guo Ren <guoren@kernel.org>, Fu Wei <wefu@redhat.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Jisheng Zhang <jszhang@kernel.org>,
	Yangtao Li <frank.li@vivo.com>,
	linux-riscv@lists.infradead.org, linux-clk@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] clk: thead: th1520-ap: Correctly refer the parent for c910 and osc_12m
Date: Sat, 5 Jul 2025 21:31:29 -0700	[thread overview]
Message-ID: <aGn8IVkWQJjHMfCT@x1> (raw)
In-Reply-To: <aGnaZjMoWbW_FZfj@pie>

On Sun, Jul 06, 2025 at 02:07:51AM +0000, Yao Zi wrote:
> On Sat, Jul 05, 2025 at 05:08:09PM -0700, Drew Fustini wrote:
> > On Sat, Jul 05, 2025 at 05:20:28AM +0000, Yao Zi wrote:
> > > clk_orphan_dump shows two suspicious orphan clocks on TH1520 when
> > > booting the kernel with mainline U-Boot,
> > > 
> > > 	$ cat /sys/kernel/debug/clk/clk_orphan_dump | jq 'keys'
> > > 	[
> > > 	  "c910",
> > > 	  "osc_12m"
> > > 	]
> > > 
> > > where the correct parents should be c910-i0 for c910, and osc_24m for
> > > osc_12m.
> > 
> > Thanks for sending this patch. However, I only see "osc_12m" listed in
> > clk_orphan_dump. I tried the current next, torvalds master and v6.15 but
> > I didn't ever see "c910" appear [1]. What branch are you using?
> 
> I think it has something to do with the bootloader: as you could see in
> your clk_orphan_dump, the c910 clock is reparented to cpu-pll1, the
> second possible parent which could be correctly resolved by the CCF,
> thus c910 doesn't appear in the clk_orphan_dump.
> 
> But with the mainline U-Boot which doesn't reparent or reclock c910 on
> startup, c910 should remain the reset state and take c910-i0 as parent,
> and appear in the clk_orphan_dump.

Ah, thanks for the explanation. I'm on an old build:

U-Boot SPL 2020.01-g55b713fa (Jan 12 2024 - 02:17:34 +0000)
FM[1] lpddr4x dualrank freq=3733 64bit dbi_off=n sdram init
U-Boot 2020.01-g55b713fa (Jan 12 2024 - 02:17:34 +0000)

I would like to run mainline but I have the 8GB RAM LPi4a. Does mainline
only work for the 16GB version right now?

> Another way to confirm the bug is to examine
> /sys/kernel/debug/clk/c910/clk_possible_parents: without the patch, it
> should be something like
> 
> 	osc_24m cpu-pll1
> 
> c910's parents are defined as
> 
> 	static const struct clk_parent_data c910_parents[] = {
> 		{ .hw = &c910_i0_clk.common.hw },
> 		{ .hw = &cpu_pll1_clk.common.hw }
> 	};
> 
> and the debugfs output looks obviously wrong.

Thanks, yeah, without the patch I also see:

==> c910-i0/clk_possible_parents <==
cpu-pll0 osc_24m

> 
> There's another bug in CCF[1] which causes unresolvable parents are
> shown as the clock-output-names of the clock controller's first parent
> in debugfs, explaining the output.

Thanks for that fix. I now see '(missing)' for c910 too when I apply
that patch:

root@lpi4amain:/sys/kernel/debug/clk# head c910/clk_possible_parents
(missing) cpu-pll1

> 
> > I think it would be best for this patch to be split into separate
> > patches for osc_12m and c910.
> 
> Okay, I originally thought these are relatively small fixes targeting
> a single driver, hence put them together. I'll split it into two patches
> in v2.

I think the osc_12m is good as-is but I'm not sure what Stephen will
think about using the string "c910-i0" in c910_parents[]. I think
splitting it up will make discussion go faster.

Thanks,
Drew

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2025-07-06  4:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-05  5:20 [PATCH] clk: thead: th1520-ap: Correctly refer the parent for c910 and osc_12m Yao Zi
2025-07-05  5:20 ` Yao Zi
2025-07-06  0:08 ` Drew Fustini
2025-07-06  0:08   ` Drew Fustini
2025-07-06  2:07   ` Yao Zi
2025-07-06  2:07     ` Yao Zi
2025-07-06  4:31     ` Drew Fustini [this message]
2025-07-06  4:31       ` Drew Fustini
2025-07-07  1:43       ` Yao Zi
2025-07-07  1:43         ` Yao Zi
2025-07-09  5:07 ` kernel test robot
2025-07-09  5:07   ` kernel test robot

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=aGn8IVkWQJjHMfCT@x1 \
    --to=fustini@kernel.org \
    --cc=frank.li@vivo.com \
    --cc=guoren@kernel.org \
    --cc=jszhang@kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mturquette@baylibre.com \
    --cc=sboyd@kernel.org \
    --cc=wefu@redhat.com \
    --cc=ziyao@disroot.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.