hello @JerryChang,
this is exactly what I have done:
1080p: (1920x1080x30) => pixel_clk_hz = 2200 * 1125 * 30 = 74,250,000
576i: (720x576x25) => pixel_clk_hz = 864* 625 * 25 = 13,500,000
Regards.
hello igal.kroyter,
there’s patch to resolve some frame-drop issue, suggest you have a try to apply this patch for testing,
Hello @JerryChang,
I have already applied the removal of the SINGLESHOT flag in the vi4_fops.c file, did not help.
Regards.
what’s the results if you disable preview and shows frame-rate only.
for example,
gst-launch-1.0 v4l2src device=/dev/video1 ! "video/x-raw, format=(string)UYVY, width=(int)1920, height=(int)1080" ! fpsdisplaysink text-overlay=0 video-sink=fakesink sync=0 -v
Hello @JerryChang
I’ll be near the machine in a few hours (only then I’ll be able to run the requested command), but if you recall my initial request was during running the v432-ctl and there I saw the missing fields:
or you actually need me to test the gstreamer with the fpsdisplaysink element?
Note: Though I recall that I tried it and it was refusing to play it as a result of some reason so I left it and concentrated on the v4l2-ctl tool as a framerate reference.
BTW I have on the same Jetson two other 1080p channels which do provide 30fps, simultaneously - that is I play both 1080p channels.
hello igal.kroyter,
just have some alternative ways try to narrow down the issue,
v4l2src with fpsdisplaysink to disable preview and shows frame-rate only is really the same test as v4l2-ctl.
this is a really good information, are you able to configure interlaced for 1920x1080 sensor mode?
according to your VI tracing logs (in the very beginning) it looks you’re having correct sequence of FS/FE.
now, I doubt the output steaming of your FPGA device.
hello @JerryChang,
I can configure Jetson the 1080i, BUT, The FPGA is only capable to provide 1080p and 576i(PAL).
now, I doubt the output steaming of your FPGA device.
The VI tracing looks too good to indicate what is wrong with the FPGA, I was hoping that the rtos_queue_peek_from_isr_failed indication will help figuring out the problem, but I saw that you’ve replied - in one of the posts - to ignore it …so I’m still ignoring it :).
Are there any more debug notification that can be turned on to provide more information?
currently I use the following:
echo 1 > /sys/kernel/debug/tracing/tracing_on
echo 30720 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/tegra_rtcpu/enable
echo 1 > /sys/kernel/debug/tracing/events/freertos/enable
echo 3 > /sys/kernel/debug/camrtc/log-level
echo 1 > /sys/kernel/debug/tracing/events/camera_common/enable
hello igal.kroyter,
please gather VI tracing logs again since you had revise the actual height to 288 instead of 576.
besides,
please also have a try as following to boost the clock for testing.
for example,
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 |tee /sys/kernel/debug/bpmp/debug/clk/vi/rate
cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/isp/rate
cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate
hello @JerryChang,
I have configured the DT and the driver to accept the 720x288 resolution but it only received the first field. vi log is attached.720x288Dump.txt (271.2 KB)
w/wo the clock acceleration.
Regards.
hi igal.kroyter,
there’s CHANSEL_FAULT, the line number is 288, and the error report shows PIXEL_RUNAWAY failure.
rtcpu_vinotify_event: tstamp:2922185767 tag:CHANSEL_FAULT channel:0x00 frame:2 vi_tstamp:2922185394 data:0x01200040
rtcpu_vinotify_event: tstamp:2922186591 tag:CHANSEL_LOAD_FRAMED channel:0x01 frame:2 vi_tstamp:2922185900 data:0x08000000
rtcpu_vinotify_event: tstamp:2922186698 tag:CHANSEL_FAULT_FE channel:0x01 frame:2 vi_tstamp:2922185913 data:0x00000001
could you please look into below kernel sources,
$L4T_Sources/r32.6.1/Linux_for_Tegra/source/public/kernel/nvidia/drivers/media/platform/tegra/camera/vi/channel.c
$L4T_Sources/r32.6.1/Linux_for_Tegra/source/public/kernel/nvidia/drivers/media/platform/tegra/camera/vi/vi4_fops.c
the driver should handle the stream as interlaced,
please add some debugs messages to double check the code flow is correct.
thanks
Hello @JerryChang,
Just to make sure that there are no patches that might affect the code, but I’m using r32.5.1 and not r32.6.1?
hello igal.kroyter,
it should be related to interlaced since you had verified 1080p without failures.
BTW, there’s an external page to list all r32.5.1 known bug fixes: Jetson/L4T/r32.5.x patches - eLinux.org,
thanks
hello @JerryChang,
I’ve attached the modified files and the dmesg dump with the relevant debug messages, please let me know if you that I should more debug messages.
On line 1124 in the dump I’ve activated the v4l2-ctl command
channel.c (66.4 KB)
vi4_fops.c (34.7 KB)
dmesg.txt (90.1 KB)
Regards.
hello igal.kroyter,
you’re using an incorrect command-line, --set-fmt-video=width=720,height=288.
for the interlaced captures, you’ve define the image size in the device tree for the field size; however, you’ll still doing capture with its actual image size. i.e. 720x576
for example,
$ v4l2-ctl --device /dev/video2 --set-fmt-video=width=720,height=576,pixelformat=UYVY,field=interlaced --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100
hello @JerryChang,
I was under the impression that you’ve asked me to change the the height of the image to 288. wasn’t it?
So I’ve modified the driver and the DT and provided the kernel log with my debug printouts.
Please elaborate what do you mean?
hello igal.kroyter,
you should have device tree settings, for example, active_w=720, and active_h=288, for interlaced captures. I assume you’d already complete update the device tree to have report the image height.
so,
when issue a command, please do assign the actual frame-size, 720x576 from user-space.
hello @JerryChang,
I have attached the log for running the
4l2-ctl --device /dev/video2 --set-fmt-video=width=720,height=576,pixelformat=UYVY,field=interlaced --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100
and the driver (just in case), as I see no behaviour change.
dmesg720x576.txt (95.6 KB)
ov23850.c (21.8 KB)
Regards.
hello igal.kroyter,
do you see any abnormal capture frames? or, you mean only the fps still half of expectation?
according to below,
it looks VI driver code-flow works correctly that calling capture thread twice for interlaced.
[ 33.034433] (NULL device *): tegra_channel_capture_frame chan->low_latency 0
[ 33.041751] (NULL device *): tegra_channel_capture_frame_single_thread chan->interlace_type 1 j 0 chan->bfirst_fstart 0
[ 33.052889] (NULL device *): tegra_channel_surface_setup
[ 33.077854] (NULL device *): tegra_channel_capture_frame_single_thread chan->interlace_type 1 j 1 chan->bfirst_fstart 0
[ 33.088822] (NULL device *): tegra_channel_surface_setup
furthermore, I did not realize that ov23850 still use V4L2 Kernel Driver (Version 1.0),
it’s now the implementation moving to V4L2 Kernel Driver (Version 2.0) to load camera device properties via device tree, please check int tegracam_device_register(); the reference driver is imx185.c.
hello @JerryChang,
- when I set the height to 288, no frames are captured as there is a failure, I guess the failre is during capturing the seoncd field.
- Per the kernel log it seems OK, but the VI log fails samplig the frame?
- I was trying to implement the imx185 but I saw no utilization of the dv_timings which I thought at the time that are required for the interlaced video ( my current ov23850 driver implementation, is not using the dv_timing params too as it works without them - I do not understand how).
Regards.
hello igal.kroyter,
back to your original questions, did the output frames looks correct when you got half fps?
what’s the modification you had done to output half frames.