Hi,
We have created a driver for TX2 in order to capture images from an FGPA that is constantly sending the data through 2-lane MIPI channel.
This is generic driver that creates and enables a video device for the capture. We have tested the driver using 2 different sensors and it’s working good. However with the FGPA it doesn’t.
We have verified that the MIPI signals from the FPGA reach the TX2, but we are not able to capture with v4l2. We get the typical PXL_SOF error:
[ 1232.297150] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 1233.301288] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 1234.305468] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 1235.309392] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 1236.313445] tegra-vi4 15700000.vi: ATOMP_FE syncpt timeout!
We enabled debug traer, but we don’t get information from it:
kworker/0:1-115 [000] ...1 333.915376: rtos_queue_peek_from_isr_failed: tstamp:10545290832 queue:0x0b4a3c58
kworker/0:1-115 [000] ...1 334.071376: rtos_queue_peek_from_isr_failed: tstamp:10550291333 queue:0x0b4a3c58
kworker/0:1-115 [000] ...1 334.227399: rtos_queue_peek_from_isr_failed: tstamp:10555291837 queue:0x0b4a3c58
kworker/0:1-115 [000] ...1 334.331449: rtos_queue_peek_from_isr_failed: tstamp:10559098194 queue:0x0b4a3c58
kworker/0:1-115 [000] ...1 372.043659: rtos_queue_peek_from_isr_failed: tstamp:11737003392 queue:0x0b4a3c58
We have configured and tested the driver/FGPA setting 2 modes, but neither of them work. So, we wonder if there is an issue with our the mode’s configuration for 2 lanes.
Is there a limitation in the Per-Lane-Bandwidth or framerate used?
See the modes and calculations below:
Mode 1
Horizontal: 640 (data) + 160 (blank) = 800
Vertical: 480 (data) + 75 (blank) = 525
Framerate: 128.57143 FPS
Format: RAW8
- Pixel Clock * = 800x525x128.57143 = 54.00 MHz
- Total bandwidth * = 54,00 x 8 = 432.00 Mbps
- Per-Lane-Bandwidth * = 432.00 / 2 = 216.00 Mbps
- MIPI Clock * (half rate) = 216.00 / 2 = 108.00 MHz
Mode 2
Horizontal: 640 (data) + 560 (blank) = 1200
Vertical: 512 (data) + 488 (blank) = 1000
Framerate: 45 FPS
Format: RAW8
- Pixel Clock * = 1200x1000x45 = 54.00 MHz
- Total bandwidth * = 54,00 x 8 = 432.00 Mbps
- Per-Lane-Bandwidth * = 432.00 / 2 = 216.00 Mbps
- MIPI Clock * (half rate) = 216.00 / 2 = 108.00 MHz
We are discarting hardware issues, but it will be very helpful if you can give us information about bandwidth or framerate limitation for the CSI/VI or if you see something wrong in those mode configurations.
Thank you.
If you have bandwidth you can boot the VI/CSI clocks to try.
However from the trace log VI/CSI didn’t get any validate package from MIPI bus maybe the signal problem.
sudo su
echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked
cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate
cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate
cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate
echo {$max_rate} > /sys/kernel/debug/bpmp/debug/clk/vi/rate
echo {$max_rate} > /sys/kernel/debug/bpmp/debug/clk/isp/rate
echo {$max_rate} > /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate
Shane,
What does writing a 1 to the mrq_rate_locked file do? My guess would be that it fixes the clock rate so that when the drivers attempt to change the clock nothing happens. If that’s the case then shouldn’t the rate be set prior to locking the clock rate?
Thanks,
Greg
Hi Shane/Greg,
Thank you for your answers.
Greg,
The commands worked without problems. If the mrq_rate_locked is disabled, rate value is modified when capturing from a device. When mrq_rate_locked is enabled, rate values are not modified when capture is activated.
Shane,
I did some testing using the commands provided with a sensor from which the TX2 is able to capture and tried to get a bandwidth error in order to see if we get similar output when capturing from FPGA:
First I performed a normal V4l2 capture without issues, then I decreased the NVCSI rate to the minimum and I got a capture error (as expected) and I verified the debug tracer output:
kworker/0:3-2881 [000] ...1 2336.857263: rtcpu_vinotify_handle_msg: tstamp:73134787822 tag:ATOMP_FS channel:0x00 frame:1 vi_tstamp:120343093 data:0x00000000
kworker/0:3-2881 [000] ...1 2336.857264: rtcpu_vinotify_handle_msg: tstamp:73134790057 tag:CHANSEL_LOAD_FRAMED channel:0x01 frame:1 vi_tstamp:120345612 data:0x08000000
kworker/0:3-2881 [000] ...1 2336.909270: rtcpu_vinotify_handle_msg: tstamp:73135308271 tag:CHANSEL_FAULT channel:0x00 frame:1 vi_tstamp:120863802 data:0x00120200
kworker/0:3-2881 [000] ...1 2336.909274: rtcpu_vinotify_handle_msg: tstamp:73135309198 tag:CHANSEL_LOAD_FRAMED channel:0x01 frame:1 vi_tstamp:120864383 data:0x08000000
kworker/0:3-2881 [000] ...1 2336.909275: rtcpu_vinotify_handle_msg: tstamp:73135309330 tag:CHANSEL_FAULT_FE channel:0x01 frame:1 vi_tstamp:120864388 data:0x00000001
kworker/0:3-2881 [000] ...1 2336.909277: rtcpu_vinotify_handle_msg: tstamp:73135309492 tag:ATOMP_FE channel:0x00 frame:1 vi_tstamp:120864392 data:0x00000000
I got CHANSEL_FAULT and CHANSEL_FAULT_FE messages. However, this output is different from the obtained by capturing from the FPGA in which the tracer doesn’t gives us messages.
I have some questions:
- Is there a way to know whether there is a signal problem using any TX2 sys log or debug?
- What are common signal problems that may cause the PIX_SOF timeout issue?
From our experience, we have identified that PIX_SOF timeout appears in the following cases:
- Non-existent signal: When the streaming is not enabled, we see this error.
- Data lane polarity inversion: If the hardware has an issue like an polarity inversion of a data-lane.
- Wrong Data Format: If the format is incorrect we get this error, but in this case the debug tracer give us information about the error (CHANSEL_SHORT_FRAME)
Thanks,
PIX_SOF timeout case by VI can’t finish capture a full frame to the buffer that could be lots of case.
For the signal it must follow the MIPI spec may need to probe it.