Kernel Panic on Boot Due to Delay Functions in imx8 platform Driver on i.MX8MP

[adnan_dst]

Hi,

We are using an i.MX8MP SoM with a custom Linux OS
Kernel version: lf-5.15.71-2.2.2

We're in the process of integrating the AR1335 camera driver (originally from the i.MX8MP Verdin platform) into our own i.MX8MP SoM setup.

However, when the AR1335 platform driver is loaded at boot time, the system encounters a kernel panic immediately after the driver's probe() function completes. If we do not load the device tree overlay for this driver, the system boots without issues.

One key observation is that the driver contains several calls to msleep() (with delays like 500ms or 1000ms). When these calls are commented out, the system boots successfully without crashing.

We attempted to replace msleep() with alternatives such as mdelay(), usleep_range(), and fsleep(), but all still result in a kernel panic during boot.

Since we do need delays in the driver for certain hardware initialization steps, we are looking for a safe and reliable method to introduce those delays without triggering a crash during boot.

What is the recommended way to handle such delays safely in a camera driver during probe?

Regards,
Adnan

[joanxie]

do you mind sharing detailed code or patch you are talking about? it's hard to understand your issue if you didn't share any code, and do you use ISI or ISP? I'm not sure what ar1335 driver you mean, 

[adnan_dst]

Hi,

We have applied the patch files provided by e-con Systems for the Toradex i.MX8MP Verdin module, targeting the kernel version toradex_5.15-2.2.x-imx.

Our goal is to integrate the e-CAM131_CUiMX8 camera module from e-con Systems into our platform.

Regards,
Adnan

[joanxie]

since you use the third party company SW and HW, I suggest that you can contact them for further support, their engineer should be more familiar with their own SW, and I even don't know what e-CAM131_CUiMX8 camera module is

[adnan_dst]

Hi,

One approach I tried that seems to work without causing a kernel panic is to create a kernel thread from the probe() function and move the initialization code (which includes delays) into that thread.

Is there a better or more appropriate method for handling this?

Reagrds,
Adnan