[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <9f61678e008815ed011a61472cf909445448cb2b.camel@toradex.com>
Date: Wed, 31 Aug 2022 13:51:30 +0000
From: Marcel Ziswiler <marcel.ziswiler@...adex.com>
To: "alexander.stein@...tq-group.com" <alexander.stein@...tq-group.com>,
"wenst@...omium.org" <wenst@...omium.org>
CC: "nfraprado@...labora.com" <nfraprado@...labora.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"angelogioacchino.delregno@...labora.com"
<angelogioacchino.delregno@...labora.com>,
"linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"mturquette@...libre.com" <mturquette@...libre.com>,
"sboyd@...nel.org" <sboyd@...nel.org>
Subject: Re: [PATCH RESEND v2 1/2] clk: core: Honor CLK_OPS_PARENT_ENABLE for
clk gate ops
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
Powered by blists - more mailing lists