Hello @JerryChang,
We want to provide a status update and ask a few questions.
Earlier you referred us to [Topic 318537](Understanding err_data 0 in tegra-camrtc-capture-vi: corr_err Logs - #4 by JerryChang)
We have reviewed settings for Sensor Pixel Clock
We computed the value using frame size and frame rate: 1312 x 814 x 30fps = 32039040
1. Does our calculated value for pix_clk_hz look correct?
Since our system uses GMSL we also reviewed settings for SerDes Pixel Clock
Our deserializer output bitrate is 800 MHz
serdes_pix_clk_hz = (800,000,000) * (4) / (16) = 200000000
2. Does our calculated value for serdes_pix_clk_hz look correct?
One device tree setting of note that we changed was cil_settletime.
After looking at Topic 60565 and Topic 283225 we understood that the ui term wants the duration for a single bit period on the MIPI bus. Following are our calculations to determine the value for cil_settletime.
// cil_settletime: The settle time of the MIPI lane, in nanoseconds
// 85 ns + 6×ui < (cil_settletime+6) × (lp_clock_period) < 145 ns + 10×ui
// lp_clock_period is 1/(204 MHz)
// ui is the unit interval, the bit period based on the MIPI bus clock rate (800MHz)
// ui = 1/800,000,000 = 0.000000001 s = 1 ns
// 85 ns + 6×1 < (cil_settletime+6) × (lp_clock_period) < 145 ns + 10×1
// 91 ns < (cil_settletime+6) × (lp_clock_period) < 155 ns
// 91 ns < (cil_settletime+6) × (4.902 ns) < 155 ns
// cil_settletime [12.87 ns, 26.13 ns]
// we choose average = 19.5 ns > round up to 20 ns
//cil_settletime = "20"; <-- Did not work for Good Cam
cil_settletime = "0";
However when we used this value for cil_settletime we could not acquire an image on deserializer 0 MIPI port 0.
So we changed the value of cil_settletime to 0.
3. Why does a correctly computed cil_settletime have adverse affects? Or is there something wrong with our calculations?
We also reviewed all camera related device tree settings.
We removed several optional and non-applicable to our system entries.
camDevTree-04Feb2025.txt (6.7 KB)
4. Do our revised camera device tree nodes look correct?
We also reviewed Camera Driver Porting Tips and found no anomalies.
We reviewed the Debugging Tips page found no changes to our system are necessary.
We successfully tested these changes with deserializer 0 connected to Orin MIPI port 0.
However when we switched over to deserialzier 2 connected to Orin MIPI port 4 we were still unable to obtain an image. We still receive the 131072 error.
[ 162.677780] ov10635 0-0009: Setting format
[ 162.678581] ov10635 0-0009: Setting format
[ 162.678745] ov10635 0-0009: Setting format
[ 162.681610] ov10635 0-0009: Power on
[ 162.720503] bwmgr API not supported
[ 162.732195] ov10635 0-0009: Setting stream to 1
[ 162.733343] ov10635 0-0009: Write sensor in addr=0x9 reg=0x100 val=0x1
[ 162.791839] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 131072
[ 162.824996] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 131072
[ 162.891829] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 131072
[ 162.892175] ov10635 0-0009: Setting stream to 0
[ 162.893239] ov10635 0-0009: Write sensor in addr=0x9 reg=0x100 val=0x0
[ 162.897259] bwmgr API not supported
[ 162.906888] ov10635 0-0009: Power off
During the failed capture attempt on deserializer 2 connected to Orin MIPI port 4, we also captured the debug trace and attached it as well
camDevTree-04Feb2025.txt (6.7 KB)
In summary, even though we have learned more about a number of the device tree cammera properties as well as became more confident of the settings we are using the problem still persists.
Do you have any further suggestions to debug this problem with Orin MIPI port 4?