We’re trying to figure how sensitive the MIPI subsystem is to LP transition sequence.
Should the timing be bound by specific strict range?
Below are screenshots taken from a MIPI analyzer scope:
Even though the transmitter (and device tree) are configured for discontinuous clock operation (only for debugging purposes) at 162MHz, we still get the error codes in the previous post, stating a clock problem.
according to Property-Value Pairs, there’s device tree property, cil_settletime, it’s by default setting to 0 for auto-calibrate. you may give it a try to adjust the THS settle time of the MIPI lane for your use-case.
you may see-also Xavier TRM for NVCSI_PHY_0_NVCSI_CIL_A_CONTROL_0 register description. for example, here’s THS_SETTLE to configure the settle time for data lane when moving from LP to HS.
Thank you very much for the comment.
In that case, would you suggest to modify the registers in the csi core and generate a new kernel image?
Or there is more robust way to do so in runtime?
Regarding the mclk_khz field, how closely connected is it to the mipi source frequency (clock channel, say part of csi0)?
Just making sure it was properly understood, since we noticed with other drivers (ov5693, imx219) a significantly lower value compared to us (24 MHz for commercial products, as opposed to 324 MHz on our FPGA).
Resolution and framerate are very modest though (~VGA, 30 fps).
Looks like we’re nailing down around the problem with the LP sequence.
But still under investigation.
Testing with a working ov5693 sensor, it is apparent that the camera engine is able to process mipi signals even when clock configurations are slightly off (might not assemble a frame though, but the physical layer reports valid signals at least).
One subtle question in our case, is the LP sequence considered to be an atomic operation?
Can we identify through some register status if it fails on a particular transition? (such as an intermediate LP01->LP00 or so).
We suspect that a short duration of 27ns in LP00 might be causing trouble, but unsure yet.