Re: [PATCH RESEND v2 1/2] clk: core: Honor CLK_OPS_PARENT_ENABLE for clk gate ops

[Marcel Ziswiler]

Hi there

On Wed, 2022-08-31 at 09:40 +0200, Alexander Stein wrote:
> Am Dienstag, 30. August 2022, 15:40:53 CEST schrieb Chen-Yu Tsai:

[snip]

> > Thanks. So the part of the clock tree that's problematic is this:
> > 
> >  osc_24m (fixed)
> >     sys_pll1_ref_sel (mux)
> >        sys_pll1 (imx pll14xx)
> >           sys_pll1_bypass (mux)
> >              sys_pll1_out (gate)
> >                 sys_pll1_800m (fixed factor)
> >                    main_axi (composite CLK_IS_CRITICAL)
> > 
> > Would it be possible for you to produce a stack dump as well? And also
> > enable lock debugging? This likely still won't catch anything if it's
> > a spinlock deadlock though.
> 
> Sure thing, I added a dump_stack() call to all of the above debug outputs as 
> well as the name of the parent clock, just to be sure, and here is the result 
> output:
> [    1.142386] io scheduler mq-deadline registered
> [    1.146902] io scheduler kyber registered
> [    1.177345] clk_core_prepare: clk: main_axi CLK_OPS_PARENT_ENABLE
> [    1.180713] clk_core_prepare: clk->parent: sys_pll1_800m
> [    1.186025] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc3-
> next-20220831+ #619 9c82e5b9075d735fa07e2c558603ffb720d72983
> [    1.197274] Hardware name: TQ-Systems i.MX8MPlus TQMa8MPxL on MBa8MPxL (DT)
> [    1.204275] Call trace:
> [    1.206723]  dump_backtrace+0xd8/0x120
> [    1.210485]  show_stack+0x14/0x50
> [    1.213811]  dump_stack_lvl+0x88/0xb0
> [    1.217486]  dump_stack+0x14/0x2c
> [    1.220811]  clk_core_prepare+0x1fc/0x240
> [    1.224834]  __clk_core_init+0x208/0x4dc
> [    1.228772]  __clk_register+0x160/0x240
> [    1.232622]  clk_hw_register+0x1c/0x5c
> [    1.236384]  __clk_hw_register_composite+0x1e8/0x2d0
> [    1.241372]  clk_hw_register_composite+0x40/0x50
> [    1.246009]  __imx8m_clk_hw_composite+0x130/0x210
> [    1.250734]  imx8mp_clocks_probe+0x13ac/0x3750
> [    1.255199]  platform_probe+0x64/0x100
> [    1.258959]  call_driver_probe+0x28/0x140
> [    1.262984]  really_probe+0xc0/0x334
> [    1.266572]  __driver_probe_device+0x84/0x144
> [    1.270947]  driver_probe_device+0x38/0x130
> [    1.275147]  __driver_attach+0xd4/0x240
> [    1.278997]  bus_for_each_dev+0x6c/0xbc
> [    1.282847]  driver_attach+0x20/0x30
> [    1.286436]  bus_add_driver+0x178/0x250
> [    1.290284]  driver_register+0x74/0x120
> [    1.294134]  __platform_driver_register+0x24/0x30
> [    1.298859]  imx8mp_clk_driver_init+0x18/0x20
> [    1.303234]  do_one_initcall+0x48/0x180
> [    1.307084]  do_initcalls+0x164/0x19c
> [    1.310759]  kernel_init_freeable+0xf4/0x138
> [    1.315047]  kernel_init+0x2c/0x140
> [    1.318549]  ret_from_fork+0x10/0x20
> 
> Enabling lock debugging results in no additional output.

I also just bi-sected this to cause a similar hard lock-up on Verdin iMX8M Mini and Verdin iMX8M Plus running
next-20220831. Let me know if you need any further information.

Thanks!

> Best regards,
> Alexander

Cheers

Marcel