We are implementing a multi-channel composite video capture board, with 4 CSI
inputs to a TX2 module. We are to the point where we believe we have properly
formatted CSI data being fed into the CSI inputs, and on the kernel/dtb side
we have a driver modeled on the ov5693 driver that seems to integrate properly
with the media control layer (media-ctl -p looks correct) and the v4l2 driver
(we have /dev/video0 - /dev/video3).
Based on what I can see in rtcpu/vi-notify.h, this is a CHANSEL_SHORT_FRAME error.
We have adjusted the line_length in the device tree but it hasn’t changed anything.
Is there a good way to figure out why the video data isn’t getting transferred? I’ve
printed out the csi and vi register configuration steps if that would help.
@cobrien
CHANSEL_SHORT_FRAME is the output active_h didn’t as expect. Make the the output size to modify the height in the kernel driver and active_h in DT.
Jerry, yes we can run a test pattern or captured video.
Note we have a digital (BT.656) loopback in the FPGA and a D/A output so
we can monitor the captured video at that level. I tried with the test pattern
and still get the Status 7 error from the vi subsystem.
Shane, this is a composite video in, so the video is interlaced, so each frame
has half the resolution. Checking… Changing to 240 didn’t seem to help. same error 7.
I actually reduced the active_h to 140 and still it returns error 7 which I believe is
CHANSEL_SHORT_FRAME.
It does seems as if reducing the active_w below 720 changes the error message so that
in vi4_fops.c:tegra_channel_notify_status_callback none of the ports are valid??.
Jerry, yes we can run a test pattern or captured video.
Note we have a digital (BT.656) loopback in the FPGA and a D/A output so
we can monitor the captured video at that level. I tried with the test pattern
and still get the Status 7 error from the vi subsystem.
Shane, this is a composite video in, so the video is interlaced, so each frame
has half the resolution. Checking… Changing to 240 didn’t seem to help. same error 7.
I actually reduced the active_h to 140 and still it returns error 7 which I believe is
CHANSEL_SHORT_FRAME.
It does seems as if reducing the active_w below 720 changes the error message so that
in vi4_fops.c:tegra_channel_notify_status_callback none of the ports are valid??.
I spent time going over the errors we got from different resolutions trying
to understand what is going on. The input is 720x480 interlaced, so each
frame is 720x240.
Depending on the mumber of lines, from the vi system I get either a Status 7 (short frame) or
a Status 4 (error). In the Parker TRM section 27.7.1 it talks about ‘notifications’ from
the RTCPU handling the transfer (?). Status 7 seems to be SHORT_FRAME, which makes sense,
If I set the vertical resolution for more than 254 I get status 7, short frame. If I set
the vertical resolution for 254 or less I get Status 4, FAULT which is less clear.
From the TRM it seems as if there are additional error flags for the FAULT status,
things like overrun or underrun in a line, or incompatible format, but it is unclear how
this information could be extracted.
Unfortunately there was no vertical resolution setting that would transfer data.
Is there any way to get the additional status information that could explain what
the fault is?
The colorbar generator from the CSI converter is non-interlaced, we are
able to frame-capture that. The problem that the video source is an interlaced
ntsc composite camera. De-interlacting outside of the TX2 would require a hardware
change. If we could capture the fields we could possibly deinterlace in gstreamer.