RE: [PATCH 5/6] clk: imx8mq: Remove CLK_IS_CRITICAL flag for IMX8MQ_CLK_TMU_ROOT

From: Anson Huang <anson.huang@nxp.com>
To: Daniel Baluta <daniel.baluta@gmail.com>
Cc: "Abel Vesa" <abel.vesa@nxp.com>,
	"rui.zhang@intel.com" <rui.zhang@intel.com>,
	"edubezval@gmail.com" <edubezval@gmail.com>,
	"daniel.lezcano@linaro.org" <daniel.lezcano@linaro.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Shawn Guo" <shawnguo@kernel.org>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	"Pengutronix Kernel Team" <kernel@pengutronix.de>,
	"Fabio Estevam" <festevam@gmail.com>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Stephen Boyd" <sboyd@kernel.org>,
	"Lucas Stach" <l.stach@pengutronix.de>,
	"Andrey Smirnov" <andrew.smirnov@gmail.com>,
	"Angus Ainslie (Purism)" <angus@akkea.ca>,
	"Carlo Caione" <ccaione@baylibre.com>,
	"Guido Günther" <agx@sigxcpu.org>,
	"Leonard Crestez" <leonard.crestez@nxp.com>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"Devicetree List" <devicetree@vger.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
	dl-linux-imx <linux-imx@nxp.com>
Subject: RE: [PATCH 5/6] clk: imx8mq: Remove CLK_IS_CRITICAL flag for IMX8MQ_CLK_TMU_ROOT
Date: Mon, 29 Jul 2019 07:14:28 +0000	[thread overview]
Message-ID: <DB3PR0402MB391627F725AA7237BCACBE87F5DD0@DB3PR0402MB3916.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <CAEnQRZB6tmYFA8wwh0Fm49LTTDuCLq-SWVfrcUkRWWBo=0U13w@mail.gmail.com>

Hi, Daniel

> On Mon, Jul 29, 2019 at 4:29 AM Anson Huang <anson.huang@nxp.com>
> wrote:
> >
> > Hi, Abel/Daniel
> >
> > > On 19-07-27 09:33:10, Daniel Baluta wrote:
> > > > On Sat, Jul 27, 2019 at 9:19 AM Anson Huang <anson.huang@nxp.com>
> > > wrote:
> > > > >
> > > > > Hi, Daniel
> > > > >
> > > > > > Subject: Re: [PATCH 5/6] clk: imx8mq: Remove CLK_IS_CRITICAL
> > > > > > flag for IMX8MQ_CLK_TMU_ROOT
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > latest linux-next hangs at boot.
> > > > > >
> > > > > > commit fde50b96be821ac9673a7e00847cc4605bd88f34 (HEAD ->
> > > master, tag:
> > > > > > next-20190726, origin/master, origin/HEAD)
> > > > > > Author: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > > > Date:   Fri Jul 26 15:18:02 2019 +1000
> > > > > >
> > > > > >     Add linux-next specific files for 20190726
> > > > > >
> > > > > >     Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > > >
> > > > > >
> > > > > > I know this is crazy but reverting commit:
> > > > > >
> > > > > > commit 431bdd1df48ee2896ea9980d9153e3aeaf0c81ef
> > > (refs/bisect/bad)
> > > > > > Author: Anson Huang <Anson.Huang@nxp.com>
> > > > > > Date:   Fri Jul 5 12:56:11 2019 +0800
> > > > > >
> > > > > >     clk: imx8mq: Remove CLK_IS_CRITICAL flag for
> > > > > > IMX8MQ_CLK_TMU_ROOT
> > > > > >
> > > > > >     IMX8MQ_CLK_TMU_ROOT is ONLY used for thermal module, the
> > > driver
> > > > > >     should manage this clock, so no need to have CLK_IS_CRITICAL
> flag
> > > > > >     set.
> > > > > >
> > > > > >
> > > > > >
> > > > > > makes the boot work again.
> > > > > >
> > > > > > Any idea?
> > > > >
> > > > > I just found if disabling SDMA1, then kernel can boot up, it
> > > > > does NOT make sense TMU clock is related to SDMA1, I will check
> > > > > with design
> > > and get back to you soon.
> > > > >
> > > >
> > > > Hi Anson,
> > > >
> > > > Applying Abel's patch:
> > > >
> > > > commit 8816c47db6a82f55bb4d64f62fd9dd3af680f0e4 (HEAD -> master)
> > > > Author: Abel Vesa <abel.vesa@nxp.com>
> > > > Date:   Tue Jun 25 12:01:56 2019 +0300
> > > >
> > > >     clk: imx8mq: Mark AHB clock as critical
> > > >
> > > >     Keep the AHB clock always on since there is no driver to control it and
> > > >     all the other clocks that use it as parent rely on it being always
> enabled.
> > > >
> > > >
> > > >
> > > > The kernel boots up again.
> > > >
> > > > It make some sense. I don't understand though why having
> > > > IMX8MQ_CLK_TMU_ROOT as critical also "unhangs" the kernel.
> > > >
> > >
> > > OK, so this is how it works.
> > >
> > > By removing the critical flag from TMU, the AHB doesn't stay always on.
> > > With my patch the AHB is marked as critical and therefore stays on.
> > >
> > > The sdma1_clk has as parent the ipg_root which in turn has as parent
> > > the ahb clock. And I think what happens is some read from the sdma
> > > registers hangs because, for whatever reason, enabling the sdma1_clk
> > > doesn't propagate to enable the ahb clock. I might be wrong though.
> > >
> >
> > I can explain why Abel's patch can fix this issue, the AHB clock is a
> > MUST always ON for system bus, while it does NOT have CLK_IS_CRITICAL
> > flag set for now, when SDMA1 is probed, it will enable its clock, and
> > the clk path is sdma1_clk->ipg_root->ahb, after SDMA1 probed done, it
> > will disable its clock since no one use it, and it will trigger the
> > ahb clock to be OFF, as its usecount is added by 1 when probe and
> > decreased by 1 after
> > SDMA1 probe done, so usecount=0 will trigger AHB clock to be OFF.
> >
> > So I think the best solution should be applying Abel's patch as you
> > mentioned upper, the TMU clock patch is NOT the root cause, it just
> > triggers this issue accidently☹
> >
> > But I saw Abel's AHB patch is still under discussion, so I think we
> > need to speed it up and make kernel boot up work for development.
> AHB/IPG are always critical for i.MX SoCs.
> 
> Thanks Anson,
> 
> Your explanation makes a lot of sense. We will take care today of Abel's
> patch.
> What do you think about Fabio's patch? I also think this is a valid patch:
> 
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcode.b
> ulix.org%2Fpd88jp-
> 812381&amp;data=02%7C01%7Canson.huang%40nxp.com%7C23b4c21e3cbc
> 4fcf2a3c08d713f131a8%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%
> 7C636999798949622961&amp;sdata=Jx9B40rJKpQvakOCfx%2B3v80NTxPqUw
> D4pdGojQxVIoY%3D&amp;reserved=0

Hmm, when did Fabio sent out this patch? I can NOT find it...
I also have a patch in this series (#4/6) doing same thing on July 5th...

https://patchwork.kernel.org/patch/11032783/

Thanks.
Anson