Messages in this thread | | | From | Marcel Ziswiler <> | Subject | Re: [PATCH RESEND v2 1/2] clk: core: Honor CLK_OPS_PARENT_ENABLE for clk gate ops | Date | Wed, 31 Aug 2022 13:51:30 +0000 |
| |
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
| |