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 l.stach@pengutronix.de 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 l.stach@pengutronix.de
[ 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 l.stach@pengutronix.de Signed-off-by: Srinivas Kandagatla srinivas.kandagatla@linaro.org Link: https://lore.kernel.org/r/20191029114240.14905-6-srinivas.kandagatla@linaro.... Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org
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/driver...
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