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 v3] clk: thead: th1520-ap: Describe mux clocks with clk_mux
Date: Tue, 22 Jul 2025 17:07:07 -0700	[thread overview]
Message-ID: <aIAnq5jWARhj8XuO@x1> (raw)
In-Reply-To: <20250722080535.60027-2-ziyao@disroot.org>

On Tue, Jul 22, 2025 at 08:05:36AM +0000, Yao Zi wrote:
> Mux clocks are now described with a customized ccu_mux structure
> consisting of ccu_internal and ccu_common substructures, and registered
> later with devm_clk_hw_register_mux_parent_data_table(). As this helper
> always allocates a new clk_hw structure, it's extremely hard to use mux
> clocks as parents statically by clk_hw pointers, since CCF has no
> knowledge about the clk_hw structure embedded in ccu_mux.
> 
> This scheme already causes issues for clock c910, which takes a mux
> clock, c910-i0, as a possible parent. With mainline U-Boot that
> reparents c910 to c910-i0 at boottime, c910 is considered as an orphan
> by CCF.
> 
> This patch refactors handling of mux clocks, embeds a clk_mux structure
> in ccu_mux directly. Instead of calling devm_clk_hw_register_mux_*(),
> we could register mux clocks on our own without allocating any new
> clk_hw pointer, fixing c910 clock's issue.
> 
> Fixes: ae81b69fd2b1 ("clk: thead: Add support for T-Head TH1520 AP_SUBSYS clocks")
> Signed-off-by: Yao Zi <ziyao@disroot.org>
> ---
> 
> This replaces the second patch in v2 of series "Fix orphan clocks in
> clk-th1520-ap driver".
> 
> Note that the c910's issue cannot be reproduced with vendor U-Boot,
> which always reparents c910 to its second parent, cpu-pll1. Another way
> to confirm the bug is to examine
> /sys/kernel/debug/clk/c910/clk_possible_parents, which obviously doesn't
> match c910's definition. There's another patch[1] explaining and fixing
> the issue that the unknown parent isn't shown as "(missing)" in debugfs.

Reviewed-by: Drew Fustini <dfustini@kernel.org>

Thank you for refactoring the c910_i0 parent fix without using strings
in the parent data.

Before: 

==> /sys/kernel/debug/clk/c910/clk_possible_parents <==
osc_24m cpu-pll1

After:

==> /sys/kernel/debug/clk/c910/clk_possible_parents <==
c910-i0 cpu-pll1

The system still boots okay without clk_ignore_unused and peripherals
like serial, emmc and ethernet are functional.

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 v3] clk: thead: th1520-ap: Describe mux clocks with clk_mux
Date: Tue, 22 Jul 2025 17:07:07 -0700	[thread overview]
Message-ID: <aIAnq5jWARhj8XuO@x1> (raw)
In-Reply-To: <20250722080535.60027-2-ziyao@disroot.org>

On Tue, Jul 22, 2025 at 08:05:36AM +0000, Yao Zi wrote:
> Mux clocks are now described with a customized ccu_mux structure
> consisting of ccu_internal and ccu_common substructures, and registered
> later with devm_clk_hw_register_mux_parent_data_table(). As this helper
> always allocates a new clk_hw structure, it's extremely hard to use mux
> clocks as parents statically by clk_hw pointers, since CCF has no
> knowledge about the clk_hw structure embedded in ccu_mux.
> 
> This scheme already causes issues for clock c910, which takes a mux
> clock, c910-i0, as a possible parent. With mainline U-Boot that
> reparents c910 to c910-i0 at boottime, c910 is considered as an orphan
> by CCF.
> 
> This patch refactors handling of mux clocks, embeds a clk_mux structure
> in ccu_mux directly. Instead of calling devm_clk_hw_register_mux_*(),
> we could register mux clocks on our own without allocating any new
> clk_hw pointer, fixing c910 clock's issue.
> 
> Fixes: ae81b69fd2b1 ("clk: thead: Add support for T-Head TH1520 AP_SUBSYS clocks")
> Signed-off-by: Yao Zi <ziyao@disroot.org>
> ---
> 
> This replaces the second patch in v2 of series "Fix orphan clocks in
> clk-th1520-ap driver".
> 
> Note that the c910's issue cannot be reproduced with vendor U-Boot,
> which always reparents c910 to its second parent, cpu-pll1. Another way
> to confirm the bug is to examine
> /sys/kernel/debug/clk/c910/clk_possible_parents, which obviously doesn't
> match c910's definition. There's another patch[1] explaining and fixing
> the issue that the unknown parent isn't shown as "(missing)" in debugfs.

Reviewed-by: Drew Fustini <dfustini@kernel.org>

Thank you for refactoring the c910_i0 parent fix without using strings
in the parent data.

Before: 

==> /sys/kernel/debug/clk/c910/clk_possible_parents <==
osc_24m cpu-pll1

After:

==> /sys/kernel/debug/clk/c910/clk_possible_parents <==
c910-i0 cpu-pll1

The system still boots okay without clk_ignore_unused and peripherals
like serial, emmc and ethernet are functional.

Thanks,
Drew

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

  reply	other threads:[~2025-07-23  0:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-22  8:05 [PATCH v3] clk: thead: th1520-ap: Describe mux clocks with clk_mux Yao Zi
2025-07-22  8:05 ` Yao Zi
2025-07-23  0:07 ` Drew Fustini [this message]
2025-07-23  0:07   ` Drew Fustini

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=aIAnq5jWARhj8XuO@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.