Hi,
I’m trying to capture the PD data at the end of a sensor frame, the information should flow as follows:
Currently we are able to receive the embedded data lines at the beginning of the frame properly , but no so with the PD data and the STATS data. In order to receive the PD data we are trying to set the PD data and the STATS data as pixel data information, then increase the size of the expected buffer to “fool” the VI driver to read the PD data as pixel information. The idea to have both , STATS_data and PD_data on the frame marked as effective pixel line, Since the FE comes at the end of both frames the data should be able to pass as it as such. In order to change the the headers of the PD data and the Stats data we change the header using the following registers
And setting the header as as 6’h2B, afterwards the height for resolution of the frame is increased by two and we try to capture the frame. However when I try to do this I get the following error :
[ 34.555368] imx298 30-0010: imx298_s_stream: s_stream finished
[ 35.582528] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 36.586549] tegra-vi4 15700000.vi: ATOMP_FE syncpt timeout!
[ 36.592697] imx298 30-0010: imx298_s_stream++ enable 0 mode 0
Has anybody try to do this on the past? Any recommendations will be gladly appreciated.
Does the PD data and the STATS data the same as frame line(4656)? This could be a problem.
Hi Shane,
According to the sensor documentation under our current settings they do. Any recommendations?
Thanks in advance.
I think it should be no problem. If the embedded can fake as pixel data correctly.
Please enable the trace and using v4l2-ctl to get raw data to debug.
Hi Shane,
Yes it seems that the embedded can modify header to be the same as pixel data, we are going to enable the trace and use v4l2-ctl to get raw data and debug.
Additionally I was wondering if the system has some limitation with frame height? the current video sensor is able to enable/disable data lines, this means that frame height can be configured to be an odd number and also an even number, for example: 1512x1136, 1512x1137, 1512x1138, etc.
Thank you.
Hi ShaneCCC,
Thanks for you reply, the following is a message after changing the header type of the PD data to pixel data and increasing the size of the frame by one line. Let me know if you have any recommendation:
root@tegra-ubuntu:/home/nvidia# cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 27/27 #P:4
#
# _-----=> irqs-off
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / delay
# TASK-PID CPU# |||| TIMESTAMP FUNCTION
# | | | |||| | |
kworker/3:3-788 [003] ...1 234.538593: rtos_queue_peek_from_isr_failed: tstamp:7676397284 queue:0x0b4a3c58
kworker/3:3-788 [003] ...1 234.538605: rtcpu_start: tstamp:7676398207
kworker/3:3-788 [003] ...1 234.694599: rtos_queue_peek_from_isr_failed: tstamp:7681398208 queue:0x0b4a3c58
kworker/3:3-788 [003] ...1 234.850594: rtos_queue_peek_from_isr_failed: tstamp:7686398691 queue:0x0b4a3c58
kworker/3:3-788 [003] ...1 235.006590: rtos_queue_peek_from_isr_failed: tstamp:7691399196 queue:0x0b4a3c58
kworker/3:3-788 [003] ...1 235.174554: rtos_queue_peek_from_isr_failed: tstamp:7696399674 queue:0x0b4a3c58
kworker/3:3-788 [003] ...1 235.330591: rtos_queue_peek_from_isr_failed: tstamp:7701400209 queue:0x0b4a3c58
kworker/3:3-788 [003] ...1 235.486586: rtos_queue_peek_from_isr_failed: tstamp:7706400714 queue:0x0b4a3c58
kworker/3:3-788 [003] ...1 235.642596: rtos_queue_peek_from_isr_failed: tstamp:7711401222 queue:0x0b4a3c58
kworker/3:3-788 [003] ...1 235.642608: rtcpu_vinotify_handle_msg: tstamp:7711755818 tag:ATOMP_FS channel:0x00 frame:1 vi_tstamp:3416788050 data:0x00000000
kworker/3:3-788 [003] ...1 235.642612: rtcpu_vinotify_handle_msg: tstamp:7711763497 tag:CHANSEL_PXL_SOF channel:0x00 frame:1 vi_tstamp:3416795747 data:0x00000001
kworker/3:3-788 [003] ...1 235.642615: rtcpu_vinotify_handle_msg: tstamp:7711771661 tag:CHANSEL_LOAD_FRAMED channel:0x10 frame:1 vi_tstamp:3416803917 data:0x08000000
kworker/3:3-788 [003] ...1 235.694577: rtcpu_vinotify_handle_msg: tstamp:7712772199 tag:CHANSEL_SHORT_FRAME channel:0x10 frame:1 vi_tstamp:3417804273 data:0x00000001
kworker/3:3-788 [003] ...1 235.694584: rtcpu_vinotify_handle_msg: tstamp:7712772480 tag:ATOMP_FE channel:0x00 frame:1 vi_tstamp:3417804276 data:0x00000000
kworker/3:3-788 [003] ...1 235.798581: rtos_queue_peek_from_isr_failed: tstamp:7716401760 queue:0x0b4a3c58
kworker/3:3-788 [003] ...1 235.954575: rtos_queue_peek_from_isr_failed: tstamp:7721402236 queue:0x0b4a3c58
kworker/3:3-788 [003] ...1 236.110575: rtos_queue_peek_from_isr_failed: tstamp:7726402740 queue:0x0b4a3c58
kworker/3:3-788 [003] ...1 236.266564: rtos_queue_peek_from_isr_failed: tstamp:7731403252 queue:0x0b4a3c58
kworker/3:3-788 [003] ...1 236.422592: rtos_queue_peek_from_isr_failed: tstamp:7736403734 queue:0x0b4a3c58
kworker/3:3-788 [003] ...1 236.578577: rtos_queue_peek_from_isr_failed: tstamp:7741404264 queue:0x0b4a3c58
kworker/3:3-788 [003] ...1 236.734565: rtos_queue_peek_from_isr_failed: tstamp:7746404768 queue:0x0b4a3c58
kworker/3:3-788 [003] ...1 236.890564: rtos_queue_peek_from_isr_failed: tstamp:7751405274 queue:0x0b4a3c58
kworker/3:3-788 [003] ...1 237.098566: rtos_queue_peek_from_isr_failed: tstamp:7756405787 queue:0x0b4a3c58
kworker/3:3-788 [003] ...1 237.254557: rtos_queue_peek_from_isr_failed: tstamp:7761406291 queue:0x0b4a3c58
kworker/3:3-788 [003] ...1 237.410542: rtos_queue_peek_from_isr_failed: tstamp:7766406795 queue:0x0b4a3c58
kworker/3:3-788 [003] ...1 237.566559: rtos_queue_peek_from_isr_failed: tstamp:7771407304 queue:0x0b4a3c58
kworker/3:3-788 [003] ...1 237.670544: rtos_queue_peek_from_isr_failed: tstamp:7774473110 queue:0x0b4a3c58
Thanks in advance,
JJ
The trace show CHANSEL_SHORT_FRAME looks like the high of resolution is incorrect.
BTW odd and even both can support for vi mode.
