All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacky Bai <ping.bai@nxp.com>
To: Lucas Stach <l.stach@pengutronix.de>, Fabio Estevam <festevam@gmail.com>
Cc: "Bough Chen" <haibo.chen@nxp.com>,
	"Angus Ainslie" <angus@akkea.ca>,
	"Leonard Crestez" <leonard.crestez@nxp.com>,
	"Peng Fan" <peng.fan@nxp.com>, "Abel Vesa" <abel.vesa@nxp.com>,
	"Stephen Boyd" <sboyd@kernel.org>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Ulf Hansson" <ulf.hansson@linaro.org>,
	"Guido Günther" <agx@sigxcpu.org>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	"Adrian Hunter" <adrian.hunter@intel.com>,
	dl-linux-imx <linux-imx@nxp.com>,
	"Sascha Hauer" <kernel@pengutronix.de>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
	<linux-arm-kernel@lists.infradead.org>
Subject: RE: sdhci timeout on imx8mq
Date: Fri, 8 Jan 2021 01:27:41 +0000	[thread overview]
Message-ID: <DBBPR04MB79303EBE9EC378C3C74E16B387AE0@DBBPR04MB7930.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <f7e3cdd37d425d2df96112258dcaf0bc6565f3cf.camel@pengutronix.de>

> Subject: Re: sdhci timeout on imx8mq
> 
> Hi Jacky,
> 
> Am Donnerstag, dem 07.01.2021 um 01:30 +0000 schrieb Jacky Bai:
> > > -----Original Message-----
> > > From: Fabio Estevam [mailto:festevam@gmail.com]
> > > Sent: Thursday, January 7, 2021 2:57 AM
> > > To: Lucas Stach <l.stach@pengutronix.de>
> > > Cc: Bough Chen <haibo.chen@nxp.com>; Angus Ainslie
> <angus@akkea.ca>;
> > > Leonard Crestez <leonard.crestez@nxp.com>; Peng Fan
> > > <peng.fan@nxp.com>; Abel Vesa <abel.vesa@nxp.com>; Stephen Boyd
> > > <sboyd@kernel.org>; Michael Turquette <mturquette@baylibre.com>; Ulf
> > > Hansson <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>;
> > > linux-mmc <linux-mmc@vger.kernel.org>; Adrian Hunter
> > > <adrian.hunter@intel.com>; dl-linux-imx <linux-imx@nxp.com>; Sascha
> > > Hauer <kernel@pengutronix.de>; moderated list:ARM/FREESCALE IMX /
> > > MXC ARM ARCHITECTURE <linux-arm-kernel@lists.infradead.org>
> > > Subject: Re: sdhci timeout on imx8mq
> > >
> > > Hi Lucas,
> > >
> > > On Tue, Jan 5, 2021 at 12:06 PM Lucas Stach <l.stach@pengutronix.de>
> > > wrote:
> > >
> > > > The reference manual states about this situation: "For any clock,
> > > > its source must be left on when it is kept on. Behavior is
> > > > undefined if this rule is violated."
> > > > And it seems this is exactly what's happening here: some kind of
> > > > glitch is introduced in the nand_usdhc_bus clock, which prevents
> > > > the SDHCI controller from working, even though the clock branch is
> > > > properly enabled later on. On my system the SDHCI timeout and
> > > > following runtime suspend/resume cycle on the nand_usdhc_bus clock
> > > > seem to get it back into a working state.
> > >
> > > I think your analysis is correct and I recall helping a customer
> > > with a similar
> > > issue:
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fco
> > > mm
> > > unity.nxp.com%2Ft5%2Fi-MX-Processors%2FExternal-clock-that-provide-
> > > root
> > >
> -clock-for-SAI3-and-SPDIF%2Fm-p%2F1019834&amp;data=04%7C01%7Cping
> > > .bai%40nxp.com%7C8d250a158cce469c378308d8b274d6d1%7C686ea1d
> 3bc
> > >
> 2b4c6fa92cd99c5c301635%7C0%7C0%7C637455562183497049%7CUnknow
> > >
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> > >
> WwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=VkxuhmhDifzOxxfIgFz9PR5gKC1
> > > SyQhGeSHYysX1Co4%3D&amp;reserved=0
> > >
> >
> > For the customer case, it seem not the same issue. the customer issue
> > is caused by clock source change while parent has no clock output.
> > This is inherit limitation for the CCM clock slice when using the
> > smart interface to change the clock parent.
> >
> > For current mmc timeout issue, I think we can have a try with
> > nand_usdhc_bus clock gated at the beginning of kernel boot, directly
> > modify the nand_usdhc_bus Clock's HW register gate bit in
> > clock-imx8mq.c.
> 
> While this might be an option to fix this specific issue, I would hope we can
> come up with something more generic, as the current clock framework
> behavior allows to violate the system specification constraint that parent
> clocks must not be disabled when any of the children are active. This seems
> like a fundamental issue and might hurt us also with other clocks than this
> specific nand_usdhc_bus clock.

Yes, my proposal is for debug purpose. We will do further debug on our EVK board too.

> 
> Can you tell us if there were other issues found with the PLL1/2 gating patch?
> The fact that, according to Bough, it's reverted in your tree seems to suggest
> this.

It is mainly because that the PLL1/2 derived clocks are shared between Cortex-A domain & Cortex-M domain.
M4 domain may also need some of these clocks enabled even A core domain does not use it. There is no
well-defined HW mechanism like CCM CCGR domain control to manage the PLL divider's gate based on each domain's request.
So I reverted that patch in our internal tree before we find other more solid solution for shared clock management.


BR
Jacky Bai
> 
> Regards,
> Lucas


WARNING: multiple messages have this Message-ID
From: Jacky Bai <ping.bai@nxp.com>
To: Lucas Stach <l.stach@pengutronix.de>, Fabio Estevam <festevam@gmail.com>
Cc: "Peng Fan" <peng.fan@nxp.com>, "Abel Vesa" <abel.vesa@nxp.com>,
	"Stephen Boyd" <sboyd@kernel.org>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Angus Ainslie" <angus@akkea.ca>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	"Ulf Hansson" <ulf.hansson@linaro.org>,
	"Bough Chen" <haibo.chen@nxp.com>,
	"Adrian Hunter" <adrian.hunter@intel.com>,
	dl-linux-imx <linux-imx@nxp.com>,
	"Sascha Hauer" <kernel@pengutronix.de>,
	"Leonard Crestez" <leonard.crestez@nxp.com>,
	"Guido Günther" <agx@sigxcpu.org>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
	<linux-arm-kernel@lists.infradead.org>
Subject: RE: sdhci timeout on imx8mq
Date: Fri, 8 Jan 2021 01:27:41 +0000	[thread overview]
Message-ID: <DBBPR04MB79303EBE9EC378C3C74E16B387AE0@DBBPR04MB7930.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <f7e3cdd37d425d2df96112258dcaf0bc6565f3cf.camel@pengutronix.de>

> Subject: Re: sdhci timeout on imx8mq
> 
> Hi Jacky,
> 
> Am Donnerstag, dem 07.01.2021 um 01:30 +0000 schrieb Jacky Bai:
> > > -----Original Message-----
> > > From: Fabio Estevam [mailto:festevam@gmail.com]
> > > Sent: Thursday, January 7, 2021 2:57 AM
> > > To: Lucas Stach <l.stach@pengutronix.de>
> > > Cc: Bough Chen <haibo.chen@nxp.com>; Angus Ainslie
> <angus@akkea.ca>;
> > > Leonard Crestez <leonard.crestez@nxp.com>; Peng Fan
> > > <peng.fan@nxp.com>; Abel Vesa <abel.vesa@nxp.com>; Stephen Boyd
> > > <sboyd@kernel.org>; Michael Turquette <mturquette@baylibre.com>; Ulf
> > > Hansson <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>;
> > > linux-mmc <linux-mmc@vger.kernel.org>; Adrian Hunter
> > > <adrian.hunter@intel.com>; dl-linux-imx <linux-imx@nxp.com>; Sascha
> > > Hauer <kernel@pengutronix.de>; moderated list:ARM/FREESCALE IMX /
> > > MXC ARM ARCHITECTURE <linux-arm-kernel@lists.infradead.org>
> > > Subject: Re: sdhci timeout on imx8mq
> > >
> > > Hi Lucas,
> > >
> > > On Tue, Jan 5, 2021 at 12:06 PM Lucas Stach <l.stach@pengutronix.de>
> > > wrote:
> > >
> > > > The reference manual states about this situation: "For any clock,
> > > > its source must be left on when it is kept on. Behavior is
> > > > undefined if this rule is violated."
> > > > And it seems this is exactly what's happening here: some kind of
> > > > glitch is introduced in the nand_usdhc_bus clock, which prevents
> > > > the SDHCI controller from working, even though the clock branch is
> > > > properly enabled later on. On my system the SDHCI timeout and
> > > > following runtime suspend/resume cycle on the nand_usdhc_bus clock
> > > > seem to get it back into a working state.
> > >
> > > I think your analysis is correct and I recall helping a customer
> > > with a similar
> > > issue:
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fco
> > > mm
> > > unity.nxp.com%2Ft5%2Fi-MX-Processors%2FExternal-clock-that-provide-
> > > root
> > >
> -clock-for-SAI3-and-SPDIF%2Fm-p%2F1019834&amp;data=04%7C01%7Cping
> > > .bai%40nxp.com%7C8d250a158cce469c378308d8b274d6d1%7C686ea1d
> 3bc
> > >
> 2b4c6fa92cd99c5c301635%7C0%7C0%7C637455562183497049%7CUnknow
> > >
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> > >
> WwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=VkxuhmhDifzOxxfIgFz9PR5gKC1
> > > SyQhGeSHYysX1Co4%3D&amp;reserved=0
> > >
> >
> > For the customer case, it seem not the same issue. the customer issue
> > is caused by clock source change while parent has no clock output.
> > This is inherit limitation for the CCM clock slice when using the
> > smart interface to change the clock parent.
> >
> > For current mmc timeout issue, I think we can have a try with
> > nand_usdhc_bus clock gated at the beginning of kernel boot, directly
> > modify the nand_usdhc_bus Clock's HW register gate bit in
> > clock-imx8mq.c.
> 
> While this might be an option to fix this specific issue, I would hope we can
> come up with something more generic, as the current clock framework
> behavior allows to violate the system specification constraint that parent
> clocks must not be disabled when any of the children are active. This seems
> like a fundamental issue and might hurt us also with other clocks than this
> specific nand_usdhc_bus clock.

Yes, my proposal is for debug purpose. We will do further debug on our EVK board too.

> 
> Can you tell us if there were other issues found with the PLL1/2 gating patch?
> The fact that, according to Bough, it's reverted in your tree seems to suggest
> this.

It is mainly because that the PLL1/2 derived clocks are shared between Cortex-A domain & Cortex-M domain.
M4 domain may also need some of these clocks enabled even A core domain does not use it. There is no
well-defined HW mechanism like CCM CCGR domain control to manage the PLL divider's gate based on each domain's request.
So I reverted that patch in our internal tree before we find other more solid solution for shared clock management.


BR
Jacky Bai
> 
> Regards,
> Lucas

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-01-08  1:28 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-03 19:19 Fabio Estevam
2020-02-03 19:19 ` Fabio Estevam
2020-02-05  9:26 ` Guido Günther
2020-02-05  9:26   ` Guido Günther
2020-02-05 13:18   ` Fabio Estevam
2020-02-05 13:18     ` Fabio Estevam
2020-02-07  2:11     ` BOUGH CHEN
2020-02-07  2:11       ` BOUGH CHEN
     [not found]       ` <VI1PR04MB504091C7991353F6092A8D91901A0@VI1PR04MB5040.eurprd04.prod.outlook.com>
2020-02-13 10:53         ` Fabio Estevam
2020-02-13 10:53           ` Fabio Estevam
2020-06-30 19:39           ` Angus Ainslie
2020-06-30 19:39             ` Angus Ainslie
2020-07-07 12:44             ` Fabio Estevam
2020-07-07 12:44               ` Fabio Estevam
2020-07-08  1:32               ` BOUGH CHEN
2020-07-08  1:32                 ` BOUGH CHEN
2020-12-18 20:07                 ` Lucas Stach
2020-12-18 20:07                   ` Lucas Stach
2020-12-18 20:45                   ` Angus Ainslie
2020-12-18 20:45                     ` Angus Ainslie
2020-12-23 21:06                   ` Angus Ainslie
2020-12-23 21:06                     ` Angus Ainslie
2021-01-05 15:06                 ` Lucas Stach
2021-01-05 15:06                   ` Lucas Stach
2021-01-06  9:29                   ` Bough Chen
2021-01-06  9:29                     ` Bough Chen
2021-01-06 15:09                     ` Lucas Stach
2021-01-06 15:09                       ` Lucas Stach
2021-01-07  1:47                       ` Bough Chen
2021-01-07  1:47                         ` Bough Chen
2021-01-06 18:56                   ` Fabio Estevam
2021-01-06 18:56                     ` Fabio Estevam
2021-01-07  1:30                     ` Jacky Bai
2021-01-07  1:30                       ` Jacky Bai
2021-01-07 11:26                       ` Lucas Stach
2021-01-07 11:26                         ` Lucas Stach
2021-01-08  1:27                         ` Jacky Bai [this message]
2021-01-08  1:27                           ` Jacky Bai
2021-03-09  7:35                         ` Heiko Thiery
2021-03-09  7:35                           ` Heiko Thiery
2021-01-19  2:35                   ` Peng Fan
2021-01-19  2:35                     ` Peng Fan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DBBPR04MB79303EBE9EC378C3C74E16B387AE0@DBBPR04MB7930.eurprd04.prod.outlook.com \
    --to=ping.bai@nxp.com \
    --cc=abel.vesa@nxp.com \
    --cc=adrian.hunter@intel.com \
    --cc=agx@sigxcpu.org \
    --cc=angus@akkea.ca \
    --cc=festevam@gmail.com \
    --cc=haibo.chen@nxp.com \
    --cc=kernel@pengutronix.de \
    --cc=l.stach@pengutronix.de \
    --cc=leonard.crestez@nxp.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-mmc@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=peng.fan@nxp.com \
    --cc=sboyd@kernel.org \
    --cc=ulf.hansson@linaro.org \
    --subject='RE: sdhci timeout on imx8mq' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.