From: Lucas Stach <[email protected]>
[ Upstream commit c33c585f1b3a99d53920bdac614aca461d8db06f ]
If software running before the OCOTP driver is loaded left the
controller with the error status pending, the driver will never
be able to complete the read timing setup. Reset the error status
on probe to make sure the controller is in usable state.
Signed-off-by: Lucas Stach <[email protected]>
Signed-off-by: Srinivas Kandagatla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/nvmem/imx-ocotp.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c
index afb429a417fe0..926d9cc080cf4 100644
--- a/drivers/nvmem/imx-ocotp.c
+++ b/drivers/nvmem/imx-ocotp.c
@@ -466,6 +466,10 @@ static int imx_ocotp_probe(struct platform_device *pdev)
if (IS_ERR(priv->clk))
return PTR_ERR(priv->clk);
+ clk_prepare_enable(priv->clk);
+ imx_ocotp_clr_err_if_set(priv->base);
+ clk_disable_unprepare(priv->clk);
+
priv->params = of_device_get_match_data(&pdev->dev);
imx_ocotp_nvmem_config.size = 4 * priv->params->nregs;
imx_ocotp_nvmem_config.dev = dev;
--
2.20.1
On 12/10/19 10:31 PM, Sasha Levin wrote:
> From: Lucas Stach <[email protected]>
>
> [ Upstream commit c33c585f1b3a99d53920bdac614aca461d8db06f ]
>
> If software running before the OCOTP driver is loaded left the
> controller with the error status pending, the driver will never
> be able to complete the read timing setup. Reset the error status
> on probe to make sure the controller is in usable state.
>
> Signed-off-by: Lucas Stach <[email protected]>
> Signed-off-by: Srinivas Kandagatla <[email protected]>
> Link: https://lore.kernel.org/r/[email protected]
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Sasha Levin <[email protected]>
> ---
> drivers/nvmem/imx-ocotp.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c
> index afb429a417fe0..926d9cc080cf4 100644
> --- a/drivers/nvmem/imx-ocotp.c
> +++ b/drivers/nvmem/imx-ocotp.c
> @@ -466,6 +466,10 @@ static int imx_ocotp_probe(struct platform_device *pdev)
> if (IS_ERR(priv->clk))
> return PTR_ERR(priv->clk);
>
> + clk_prepare_enable(priv->clk);
> + imx_ocotp_clr_err_if_set(priv->base);
> + clk_disable_unprepare(priv->clk);
> +
> priv->params = of_device_get_match_data(&pdev->dev);
> imx_ocotp_nvmem_config.size = 4 * priv->params->nregs;
> imx_ocotp_nvmem_config.dev = dev;
>
Hi,
This patch makes kernel 4.19.{92,93} hang at boot on my i.MX6ULL based
board. It hanks at
[ 3.730078] cpu cpu0: Linked as a consumer to regulator.2
[ 3.737760] cpu cpu0: Linked as a consumer to regulator.3
Full boot log is here: https://pastebin.com/TS8EFxkr
The config is imx_v6_v7_defconfig.
Reverting it makes the kernels boot again.
Regards,
--
Sébastien Szymanski, Armadeus Systems
Software engineer
On Tue, Jan 07, 2020 at 03:50:59PM +0100, S?bastien Szymanski wrote:
> On 12/10/19 10:31 PM, Sasha Levin wrote:
> > From: Lucas Stach <[email protected]>
> >
> > [ Upstream commit c33c585f1b3a99d53920bdac614aca461d8db06f ]
> >
> > If software running before the OCOTP driver is loaded left the
> > controller with the error status pending, the driver will never
> > be able to complete the read timing setup. Reset the error status
> > on probe to make sure the controller is in usable state.
> >
> > Signed-off-by: Lucas Stach <[email protected]>
> > Signed-off-by: Srinivas Kandagatla <[email protected]>
> > Link: https://lore.kernel.org/r/[email protected]
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > Signed-off-by: Sasha Levin <[email protected]>
> > ---
> > drivers/nvmem/imx-ocotp.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c
> > index afb429a417fe0..926d9cc080cf4 100644
> > --- a/drivers/nvmem/imx-ocotp.c
> > +++ b/drivers/nvmem/imx-ocotp.c
> > @@ -466,6 +466,10 @@ static int imx_ocotp_probe(struct platform_device *pdev)
> > if (IS_ERR(priv->clk))
> > return PTR_ERR(priv->clk);
> >
> > + clk_prepare_enable(priv->clk);
> > + imx_ocotp_clr_err_if_set(priv->base);
> > + clk_disable_unprepare(priv->clk);
> > +
> > priv->params = of_device_get_match_data(&pdev->dev);
> > imx_ocotp_nvmem_config.size = 4 * priv->params->nregs;
> > imx_ocotp_nvmem_config.dev = dev;
> >
>
> Hi,
>
> This patch makes kernel 4.19.{92,93} hang at boot on my i.MX6ULL based
> board. It hanks at
>
> [ 3.730078] cpu cpu0: Linked as a consumer to regulator.2
> [ 3.737760] cpu cpu0: Linked as a consumer to regulator.3
>
> Full boot log is here: https://pastebin.com/TS8EFxkr
>
> The config is imx_v6_v7_defconfig.
>
> Reverting it makes the kernels boot again.
Does this also cause problems in 5.4.7 and newer?
thanks,
greg k-h
Hi Sébastien,
On Di, 2020-01-07 at 15:50 +0100, Sébastien Szymanski wrote:
> On 12/10/19 10:31 PM, Sasha Levin wrote:
> > From: Lucas Stach <[email protected]>
> >
> > [ Upstream commit c33c585f1b3a99d53920bdac614aca461d8db06f ]
> >
> > If software running before the OCOTP driver is loaded left the
> > controller with the error status pending, the driver will never
> > be able to complete the read timing setup. Reset the error status
> > on probe to make sure the controller is in usable state.
> >
> > Signed-off-by: Lucas Stach <[email protected]>
> > Signed-off-by: Srinivas Kandagatla <[email protected]>
> > Link: https://lore.kernel.org/r/[email protected]
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > Signed-off-by: Sasha Levin <[email protected]>
> > ---
> > drivers/nvmem/imx-ocotp.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c
> > index afb429a417fe0..926d9cc080cf4 100644
> > --- a/drivers/nvmem/imx-ocotp.c
> > +++ b/drivers/nvmem/imx-ocotp.c
> > @@ -466,6 +466,10 @@ static int imx_ocotp_probe(struct platform_device *pdev)
> > if (IS_ERR(priv->clk))
> > return PTR_ERR(priv->clk);
> >
> > + clk_prepare_enable(priv->clk);
> > + imx_ocotp_clr_err_if_set(priv->base);
> > + clk_disable_unprepare(priv->clk);
> > +
> > priv->params = of_device_get_match_data(&pdev->dev);
> > imx_ocotp_nvmem_config.size = 4 * priv->params->nregs;
> > imx_ocotp_nvmem_config.dev = dev;
> >
>
> Hi,
>
> This patch makes kernel 4.19.{92,93} hang at boot on my i.MX6ULL based
> board. It hanks at
>
> [ 3.730078] cpu cpu0: Linked as a consumer to regulator.2
> [ 3.737760] cpu cpu0: Linked as a consumer to regulator.3
>
> Full boot log is here: https://pastebin.com/TS8EFxkr
>
> The config is imx_v6_v7_defconfig.
>
> Reverting it makes the kernels boot again.
Can you check if it actually hangs in imx_ocotp_clr_err_if_set(), or if
the clk_disable_unprepare() is the culprit?
If the clock disable hangs the system there is a missing clock
reference somewhere else that we need to track down.
Regards,
Lucas
Hi Lucas,
> On 7 Jan 2020, at 18:53, Lucas Stach <[email protected]> wrote:
>
> Hi Sébastien,
>
> On Di, 2020-01-07 at 15:50 +0100, Sébastien Szymanski wrote:
>> On 12/10/19 10:31 PM, Sasha Levin wrote:
>>> From: Lucas Stach <[email protected]>
>>>
>>> [ Upstream commit c33c585f1b3a99d53920bdac614aca461d8db06f ]
>>>
>>> If software running before the OCOTP driver is loaded left the
>>> controller with the error status pending, the driver will never
>>> be able to complete the read timing setup. Reset the error status
>>> on probe to make sure the controller is in usable state.
>>>
>>> Signed-off-by: Lucas Stach <[email protected]>
>>> Signed-off-by: Srinivas Kandagatla <[email protected]>
>>> Link: https://lore.kernel.org/r/[email protected]
>>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>>> Signed-off-by: Sasha Levin <[email protected]>
>>> ---
>>> drivers/nvmem/imx-ocotp.c | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c
>>> index afb429a417fe0..926d9cc080cf4 100644
>>> --- a/drivers/nvmem/imx-ocotp.c
>>> +++ b/drivers/nvmem/imx-ocotp.c
>>> @@ -466,6 +466,10 @@ static int imx_ocotp_probe(struct platform_device *pdev)
>>> if (IS_ERR(priv->clk))
>>> return PTR_ERR(priv->clk);
>>>
>>> + clk_prepare_enable(priv->clk);
>>> + imx_ocotp_clr_err_if_set(priv->base);
>>> + clk_disable_unprepare(priv->clk);
>>> +
>>> priv->params = of_device_get_match_data(&pdev->dev);
>>> imx_ocotp_nvmem_config.size = 4 * priv->params->nregs;
>>> imx_ocotp_nvmem_config.dev = dev;
>>>
>>
>> Hi,
>>
>> This patch makes kernel 4.19.{92,93} hang at boot on my i.MX6ULL based
>> board. It hanks at
>>
>> [ 3.730078] cpu cpu0: Linked as a consumer to regulator.2
>> [ 3.737760] cpu cpu0: Linked as a consumer to regulator.3
>>
>> Full boot log is here: https://pastebin.com/TS8EFxkr
>>
>> The config is imx_v6_v7_defconfig.
>>
>> Reverting it makes the kernels boot again.
>
> Can you check if it actually hangs in imx_ocotp_clr_err_if_set(), or if
> the clk_disable_unprepare() is the culprit?
>
> If the clock disable hangs the system there is a missing clock
> reference somewhere else that we need to track down.
Yes, the system hangs in the imx6q-cpufreq driver, here:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/cpufreq/imx6q-cpufreq.c?h=v4.19.93#n322
Kernel 5.4.8 works thanks to commits:
2733fb0d0699 (“cpufreq: imx6q: read OCOTP through nvmem for imx6ul/imx6ull”)
92f0eb08c66a ("ARM: dts: imx6ul: use nvmem-cells for cpu speed grading”)
Regards,
--
Sébastien Szymanski, Armadeus Systems
Software engineer
>
> Regards,
> Lucas
>
On Tue, Jan 07, 2020 at 08:29:12PM +0100, Sébastien Szymanski wrote:
> Hi Lucas,
>
> > On 7 Jan 2020, at 18:53, Lucas Stach <[email protected]> wrote:
> >
> > Hi Sébastien,
> >
> > On Di, 2020-01-07 at 15:50 +0100, Sébastien Szymanski wrote:
> >> On 12/10/19 10:31 PM, Sasha Levin wrote:
> >>> From: Lucas Stach <[email protected]>
> >>>
> >>> [ Upstream commit c33c585f1b3a99d53920bdac614aca461d8db06f ]
> >>>
> >>> If software running before the OCOTP driver is loaded left the
> >>> controller with the error status pending, the driver will never
> >>> be able to complete the read timing setup. Reset the error status
> >>> on probe to make sure the controller is in usable state.
> >>>
> >>> Signed-off-by: Lucas Stach <[email protected]>
> >>> Signed-off-by: Srinivas Kandagatla <[email protected]>
> >>> Link: https://lore.kernel.org/r/[email protected]
> >>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> >>> Signed-off-by: Sasha Levin <[email protected]>
> >>> ---
> >>> drivers/nvmem/imx-ocotp.c | 4 ++++
> >>> 1 file changed, 4 insertions(+)
> >>>
> >>> diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c
> >>> index afb429a417fe0..926d9cc080cf4 100644
> >>> --- a/drivers/nvmem/imx-ocotp.c
> >>> +++ b/drivers/nvmem/imx-ocotp.c
> >>> @@ -466,6 +466,10 @@ static int imx_ocotp_probe(struct platform_device *pdev)
> >>> if (IS_ERR(priv->clk))
> >>> return PTR_ERR(priv->clk);
> >>>
> >>> + clk_prepare_enable(priv->clk);
> >>> + imx_ocotp_clr_err_if_set(priv->base);
> >>> + clk_disable_unprepare(priv->clk);
> >>> +
> >>> priv->params = of_device_get_match_data(&pdev->dev);
> >>> imx_ocotp_nvmem_config.size = 4 * priv->params->nregs;
> >>> imx_ocotp_nvmem_config.dev = dev;
> >>>
> >>
> >> Hi,
> >>
> >> This patch makes kernel 4.19.{92,93} hang at boot on my i.MX6ULL based
> >> board. It hanks at
> >>
> >> [ 3.730078] cpu cpu0: Linked as a consumer to regulator.2
> >> [ 3.737760] cpu cpu0: Linked as a consumer to regulator.3
> >>
> >> Full boot log is here: https://pastebin.com/TS8EFxkr
> >>
> >> The config is imx_v6_v7_defconfig.
> >>
> >> Reverting it makes the kernels boot again.
> >
> > Can you check if it actually hangs in imx_ocotp_clr_err_if_set(), or if
> > the clk_disable_unprepare() is the culprit?
> >
> > If the clock disable hangs the system there is a missing clock
> > reference somewhere else that we need to track down.
>
> Yes, the system hangs in the imx6q-cpufreq driver, here:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/cpufreq/imx6q-cpufreq.c?h=v4.19.93#n322
>
> Kernel 5.4.8 works thanks to commits:
>
> 2733fb0d0699 (“cpufreq: imx6q: read OCOTP through nvmem for imx6ul/imx6ull”)
> 92f0eb08c66a ("ARM: dts: imx6ul: use nvmem-cells for cpu speed grading”)
I've now queued both of these up for 4.19, hopefully that should resolve
this issue, thanks!
greg k-h