Re: [PATCH v2 0/2] clk: ti: mux: resolve parent clocks by DT index, not by name

[Andreas Kemnade <andreas@kemnade.info>]

On Fri, 04 Sep 2026 09:50:17 +0200
"Mathieu Dubois-Briand" <mathieu.dubois-briand@bootlin.com> wrote:

> On Thu Sep 3, 2026 at 11:53 AM CEST, Andreas Kemnade wrote:
> > We have:
> > localhost:/sys/kernel/debug/clk# grep '(' */clk_possible_parents 
> > clkout2_src_ck/clk_possible_parents:(missing) (missing) (missing) (missing)
> > gpt10_fck/clk_possible_parents:(missing) (missing)
> > gpt11_fck/clk_possible_parents:(missing) (missing)
> > gpt2_fck/clk_possible_parents:(missing) (missing)
> > gpt3_fck/clk_possible_parents:(missing) (missing)
> > gpt4_fck/clk_possible_parents:(missing) (missing)
> > gpt5_fck/clk_possible_parents:(missing) (missing)
> > gpt6_fck/clk_possible_parents:(missing) (missing)
> > gpt7_fck/clk_possible_parents:(missing) (missing)
> > gpt8_fck/clk_possible_parents:(missing) (missing)
> > gpt9_fck/clk_possible_parents:(missing) (missing)
> > mcbsp1_fck/clk_possible_parents:(missing) (missing)
> > mcbsp2_fck/clk_possible_parents:(missing) (missing)
> > mcbsp3_fck/clk_possible_parents:(missing) (missing)
> > mcbsp4_fck/clk_possible_parents:(missing) (missing)
> > mcbsp5_fck/clk_possible_parents:(missing) (missing)
> > sgx_fck/clk_possible_parents:(missing) (missing) (missing) (missing) (missing) (missing) (missing) (missing)
> > usim_fck/clk_possible_parents:(missing) (missing) (missing) (missing) (missing) (missing) (missing) (missing) (missing) (missing)
> > localhost:/sys/kernel/debug/clk# 
> >
> > All these clocks are composite clocks.
> >
> > so the early-registration of timer-ti-dm-systimer seems not to be
> > the main issue here. Looking around what might be affected,
> > mux clocks build into composite clocks:
> > :~/linux/arch/arm/boot/dts/ti/omap$ grep -l ti,composite-mux *.dts*
> > omap2420-clocks.dtsi
> > omap2430-clocks.dtsi
> > omap24xx-clocks.dtsi
> > omap36xx-am35xx-omap3430es2plus-clocks.dtsi
> > omap36xx-omap3430es2plus-clocks.dtsi
> > omap3xxx-clocks.dtsi
> > omap44xx-clocks.dtsi
> > omap54xx-clocks.dtsi
> >
> > So havoc all over the place, just worst in omap3 because more critical
> > clocks are affected.
> >
> > So I think we need either a revert of these patches or a some
> > kind of quirk in clk_hw_register_composite_pdata to pass throuch something
> > between the mux component and the composite.
> >
> > Regrads,
> > Andreas  
> 
> Hi Andreas,
> 
> Thanks for taking the time to investigate this issue.
> 
> I believe I won't have much time to dive into it in the coming days, so
> I fear you are right and we will have to revert this patch for now.
> Except if someone else want to have a look at this.
> 
I looked once more: I will try with just the composite patch reverted.
The composite patch looks more independent than I thought initially.

The composite one does not affect anything else than OMAP2/3/4/5, so
your AM3 problem will still get solved.

Regards,
Andreas