Continuing the discussion from Interpreting NVCSI registers on MIPI error:
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?
you may try updating the device tree property,
cil_settletime to configure THS settle time of the MIPI lane for your use-case.
Thanks @JerryChang, so I’ll do.
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).
please see-also Sensor Pixel Clock for reference,
this 324 Mhz should be pixel clock instead of mclk.