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.
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?
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?
@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!!