MIPI driver probing not initiated for ov5693

[moti4]

Hi,

Following my previous post (MIPI driver probing), the kernel module was modified accordingly for JetPack 4.6.0.
With the original OV5693 sensor, the driver can be (un)loaded and communicates with the kernel (as seen through dmesg), even with i2c completely disabled.

However, with our custom MIPI board, the driver probing process doesn’t even initiate (insmod, but dmesg has no driver related output).
Is it related to HW/pin-out configuration that needs to be available on our board? (something mandatory?)
What causes the probe sequence to start in the first place? (from a HW perspective)
Through an external scope we are able to see signals over the MIPI connector that goes until the connector.

Switching back the original ov5693 board, the driver behaves as expected and follows the probing step.

Thanks,
Moti.

[moti4]

After further investigation, this comes down to the module registration function at the bottom using the macro: module_i2c_driver, which relies on the i2c subsystem to trigger driver functionality.

A simple bypass to just use null i2c device handle didn’t work, as tegracam_device_register needs a handle to some device to connect with.
What is a suggested approach to overcome this?

Moti.

[ShaneCCC]

You can remove all of the i2c REG access code from the sensor driver to avoid i2c access cause probe failed.

[moti4]

Hi Shane,

Thanks, the problem I’m facing is that without a physical i2c bus/reg binding, the driver doesn’t even go into the probe sequence.

Taking into consideration that the ov5693 driver registers itself with the kernel as a i2c device, the involved kernel macros perform a i2c binding test to trigger the probe function.
Without the correct i2c bus/reg combination available on the system, the driver will not even load.

Is there a simple manner to overcome the initialization stage and registration with tegracam_device_register in case no i2c device exists?
Or a way to mimic that behavior with a pseudo device?

Thanks,
Moti.

[ShaneCCC]

You can just use the device tree of ov5693 for the probe involve and remove the i2c REG access code in the sensor kernel cause the probe failed.

[moti4]

Thanks Shane, I’ll give it a try.
There might be something subtle I’m probably missing.

[moti4]

The remedy I was “missing”, but helped a lot was to force addition of the i2c device from user-space.
As documented here (Method 4): How to instantiate I2C devices — The Linux Kernel documentation.

A quick command can cause the i2c subsystem start probing and initialize the driver sequence.
Something I wasn’t familiar with before.

For the case of Xavier AGX and ov5693 through MIPI, this command can force probing the driver (under su permission of course):

# echo ov5693 0x36 > /sys/bus/i2c/devices/i2c-2/new_device

Whereas this one forces removal:

# echo 0x36 > /sys/bus/i2c/devices/i2c-2/delete_device

Moti.

[moti4]

@ShaneCCC apparently my bad, the dtb that was flashed so far to the system was the incorrect one, so I2C had to be enforced externally.
After using the correct dtb, indeed the driver loads automatically, thanks!!