adv7280m error: PXL_SOF syncpt timeout.

Adv7280m error single lane is connected to csi port 2 lane A.
Using command:
v4l2-ctl -d /dev/video1 --set-fmt-video width=720,height=576 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=10 --stream-to=f.raw
I can get 2 correct frames(frame 3/frame7) and the other 8 blank frames.

log:

[ 6314.358567] nvcsi 150c0000.nvcsi: csi4_start_streaming ports index=2, lanes=1

[ 6314.377403] video4linux video1: tegra_channel_capture_frame: vi4 got SOF sync
pt buf[ffffffc1d3eec400]
[ 6315.385566] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 6315.392017] video4linux video1: tegra_channel_capture_frame: vi4 got SOF sync
pt buf[ffffffc1d3eec000]
[ 6316.397560] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 6316.403985] video4linux video1: tegra_channel_capture_frame: vi4 got SOF sync
pt buf[ffffffc1d3eed400]
<[ 6317.409543] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 6317.415975] video4linux video1: tegra_channel_capture_frame: vi4 got SOF sync
pt buf[ffffffc1d3eec800]
< 0.99 fps
[ 6318.421570] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 6318.428014] video4linux video1: tegra_channel_capture_frame: vi4 got SOF sync
pt buf[ffffffc1d3eec400]
< 0.99 fps
[ 6319.433584] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 6319.440027] video4linux video1: tegra_channel_capture_frame: vi4 got SOF sync
pt buf[ffffffc1d3eec000]
< 0.99 fps
[ 6320.445565] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 6320.452001] video4linux video1: tegra_channel_capture_frame: vi4 got SOF sync
pt buf[ffffffc1d3eed400]
< 0.99 fps
[ 6321.457572] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 6321.464008] video4linux video1: tegra_channel_capture_frame: vi4 got SOF sync
pt buf[ffffffc1d3eec800]
< 0.99 fps
[ 6322.469567] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 6322.476002] video4linux video1: tegra_channel_capture_frame: vi4 got SOF sync
pt buf[ffffffc1d3eec400]

root@tegra-ubuntu:/home/nvidia# cat /sys/kernel/debug/tracing/trace

tracer: nop

entries-in-buffer/entries-written: 749/749 #P:4

_-----=> irqs-off

/ _----=> need-resched

| / _—=> hardirq/softirq

|| / _–=> preempt-depth

||| / delay

TASK-PID CPU# |||| TIMESTAMP FUNCTION

| | | |||| | |

 kworker/0:2-1954  [000] ...1  5874.768382: rtos_queue_peek_from_isr_failed: tstamp:183893146656 queue:0x0b4a3c58
 kworker/0:2-1954  [000] ...1  5874.768390: rtcpu_start: tstamp:183893148007
 kworker/0:2-1954  [000] ...1  5874.768392: rtcpu_vinotify_handle_msg: tstamp:183893684462 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3505057581 data:0x00000100
 kworker/0:2-1954  [000] ...1  5874.820431: rtcpu_vinotify_handle_msg: tstamp:183894116571 tag:CHANSEL_PXL_SOF channel:0x00 frame:2 vi_tstamp:3505489579 data:0x00000001
 kworker/0:2-1954  [000] ...1  5874.820438: rtcpu_vinotify_handle_msg: tstamp:183894116758 tag:ATOMP_FS channel:0x00 frame:2 vi_tstamp:3505489609 data:0x00000000
 kworker/0:2-1954  [000] ...1  5874.820440: rtcpu_vinotify_handle_msg: tstamp:183894408942 tag:CHANSEL_LOAD_FRAMED channel:0x04 frame:2 vi_tstamp:3505782081 data:0x08000000
 kworker/0:2-1954  [000] ...1  5874.820443: rtcpu_vinotify_handle_msg: tstamp:183894692458 tag:CHANSEL_PXL_EOF channel:0x00 frame:2 vi_tstamp:3506065401 data:0x023f0002
 kworker/0:2-1954  [000] ...1  5874.820446: rtcpu_vinotify_handle_msg: tstamp:183894692598 tag:ATOMP_FE channel:0x00 frame:2 vi_tstamp:3506065448 data:0x00000000
 kworker/0:2-1954  [000] ...1  5874.820448: rtcpu_vinotify_handle_msg: tstamp:183894701430 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3506074571 data:0x00000100
 kworker/0:2-1954  [000] ...1  5874.820451: rtcpu_vinotify_handle_msg: tstamp:183895326440 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3506699568 data:0x00000100
 kworker/0:2-1954  [000] ...1  5874.872411: rtcpu_vinotify_handle_msg: tstamp:183895951434 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3507324565 data:0x00000100
 kworker/0:2-1954  [000] ...1  5874.872415: rtcpu_vinotify_handle_msg: tstamp:183896576431 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3507949562 data:0x00000100
 kworker/0:2-1954  [000] ...1  5874.924407: rtcpu_vinotify_handle_msg: tstamp:183897201428 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3508574559 data:0x00000100
 kworker/0:2-1954  [000] ...1  5874.924412: rtcpu_vinotify_handle_msg: tstamp:183897826429 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3509199556 data:0x00000100
 kworker/0:2-1954  [000] ...1  5874.924416: rtos_queue_peek_from_isr_failed: tstamp:183898147560 queue:0x0b4a3c58
 kworker/0:2-1954  [000] ...1  5874.924419: rtcpu_vinotify_handle_msg: tstamp:183898451422 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3509824552 data:0x00000100
 kworker/0:2-1954  [000] ...1  5874.976402: rtcpu_vinotify_handle_msg: tstamp:183899076419 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3510449549 data:0x00000100
 kworker/0:2-1954  [000] ...1  5874.976406: rtcpu_vinotify_handle_msg: tstamp:183899701415 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3511074546 data:0x00000100
 kworker/0:2-1954  [000] ...1  5875.028411: rtcpu_vinotify_handle_msg: tstamp:183900326412 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3511699543 data:0x00000100
 kworker/0:2-1954  [000] ...1  5875.028415: rtcpu_vinotify_handle_msg: tstamp:183900951410 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3512324540 data:0x00000100
 kworker/0:2-1954  [000] ...1  5875.028418: rtcpu_vinotify_handle_msg: tstamp:183901576407 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3512949537 data:0x00000100
 kworker/0:2-1954  [000] ...1  5875.080436: rtcpu_vinotify_handle_msg: tstamp:183902201401 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3513574533 data:0x00000100
 kworker/0:2-1954  [000] ...1  5875.080442: rtcpu_vinotify_handle_msg: tstamp:183902826401 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3514199530 data:0x00000100
 kworker/0:2-1954  [000] ...1  5875.080446: rtos_queue_peek_from_isr_failed: tstamp:183903148052 queue:0x0b4a3c58
 kworker/0:2-1954  [000] ...1  5875.080448: rtcpu_vinotify_handle_msg: tstamp:183903451411 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3514824527 data:0x00000100
 kworker/0:2-1954  [000] ...1  5875.132412: rtcpu_vinotify_handle_msg: tstamp:183904076396 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3515449524 data:0x00000100
 kworker/0:2-1954  [000] ...1  5875.132416: rtcpu_vinotify_handle_msg: tstamp:183904701392 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3516074521 data:0x00000100
 kworker/0:2-1954  [000] ...1  5875.184422: rtcpu_vinotify_handle_msg: tstamp:183905326387 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3516699518 data:0x00000100
 kworker/0:2-1954  [000] ...1  5875.184429: rtcpu_vinotify_handle_msg: tstamp:183905951384 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3517324514 data:0x00000100
 kworker/0:2-1954  [000] ...1  5875.184431: rtcpu_vinotify_handle_msg: tstamp:183906576383 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3517949511 data:0x00000100
 kworker/0:2-1954  [000] ...1  5875.236392: rtcpu_vinotify_handle_msg: tstamp:183907201445 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3518574509 data:0x00000100
 kworker/0:2-1954  [000] ...1  5875.236395: rtcpu_vinotify_handle_msg: tstamp:183907826374 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3519199505 data:0x00000100
 kworker/0:2-1954  [000] ...1  5875.236400: rtos_queue_peek_from_isr_failed: tstamp:183908148544 queue:0x0b4a3c58
 kworker/0:2-1954  [000] ...1  5875.288426: rtcpu_vinotify_handle_msg: tstamp:183908451370 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3519824502 data:0x00000100
 kworker/0:2-1954  [000] ...1  5875.288431: rtcpu_vinotify_handle_msg: tstamp:183909076366 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3520449499 data:0x00000100
 kworker/0:2-1954  [000] ...1  5875.288433: rtcpu_vinotify_handle_msg: tstamp:183909701364 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3521074495 data:0x00000100
 kworker/0:2-1954  [000] ...1  5875.340410: rtcpu_vinotify_handle_msg: tstamp:183910326366 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3521699492 data:0x00000100
 kworker/0:2-1954  [000] ...1  5875.340415: rtcpu_vinotify_handle_msg: tstamp:183910951360 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3522324490 data:0x00000100
 kworker/0:2-1954  [000] ...1  5875.340418: rtcpu_vinotify_handle_msg: tstamp:183911576356 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3522949486 data:0x00000100
 kworker/0:2-1954  [000] ...1  5875.392419: rtcpu_vinotify_handle_msg: tstamp:183912201354 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3523574483 data:0x00000100
 kworker/0:2-1954  [000] ...1  5875.392424: rtcpu_vinotify_handle_msg: tstamp:183912826347 tag:CSIMUX_STREAM channel:0xff frame:0 vi_tstamp:3524199480 data:0x00000100

My problem:Why drop 3 frames in every 4 frames? Is this related to Frame ID?

From the trace log get one CHANSEL_PXL_SOF and CHANSEL_PXL_EOF that means only have one validate frame receive from CSI.

Hi ShaneCCC.
That’s only part of the trace. In most times, I can get one frame out of four frames.But sometimes I can get consecutive frames.
No matter can I get consecutive frames or not, the PXL_SOF syncpt timeout warning always exists.
I use Jetpack 28.2. Camera hardware works fine when it is used with Jetson TX1.
When I browse notifier related code, I found in the function
nvhost_vi_notify_set_syncpts in file host_vi_notify.c, there may be an error.
Pointer incrs is not initialized. I don’t know if it has anything with the PXL_SOF timeout error or not.
Can you check it?

static int nvhost_vi_notify_set_syncpts(struct device *dev, u8 ch,
const u32 ids[3])
{
struct platform_device *pdev = to_platform_device(dev);
struct nvhost_master *master = nvhost_get_host(pdev);
struct nvhost_vi_dev *vi = nvhost_get_private_data(pdev);
struct nvhost_vi_notify_dev *hvnd = vi->hvnd;
struct nvhost_vi_ch_incrs *incrs;
int err;
int i;

for (i = 0; i < ARRAY_SIZE(incrs->syncpt_ids); i++)
	if (ids[i] != 0xffffffff &&
		!nvhost_syncpt_is_valid_pt(&master->syncpt, ids[i]))
		return -EINVAL;

if (ch >= ARRAY_SIZE(hvnd->incr))
	return -EOPNOTSUPP;

err = nvhost_vi_notify_set_mask(pdev,
		hvnd->mask | (1u << VI_NOTIFY_TAG_CHANSEL_PIXEL_SOF));
if (err)
	return err;

incrs = &hvnd->incr[ch];

for (i = 0; i < ARRAY_SIZE(incrs->syncpt_ids); i++)
	atomic_set(&incrs->syncpt_ids[i], ids[i]);

return 0;

}

I think there’s no problem for this code. This point will point to the struct define in the head of this file.

struct nvhost_vi_ch_incrs {
	atomic_t syncpt_ids[3];
  };

incrs is a local pointer and not be initialized, then in below code, what’s the value of “incrs->syncpt_ids”?
for (i = 0; i < ARRAY_SIZE(incrs->syncpt_ids); i++)

I initialized it with: incrs = &hvnd->incr[ch]; but result is same, I lost too many frames.

This code check it size not the content. So it could be 3 no matter initialize or not. I think the frame lost is cause by the incomplete packages.

ARRAY_SIZE(incrs->syncpt_ids)

  Thank you, ShaneCCC.
  From your point view, what's the error-prone part? CSI or VI?
  From correctly captured YUV 422 frame, everything is ok(width/height/color...).
  The problem is 75% frames have lost.
  I have dumped csi and vi registers when stop streaming

[ 2884.484959] ===============vi4_dump csi_port:2================
[ 2884.491793] NOTIFY_ERROR:0x0
[ 2884.494767] NOTIFY_TAG_CLASSIFY_0:0xe38c08c3
[ 2884.499103] CFG_INTERRUPT_STATUS:0x3f000000
[ 2884.503351] ATOMP_EMB_SURFACE_OFFSET0[0]:0x0
[ 2884.507670] ATOMP_EMB_SURFACE_OFFSET0_H[0]:0x0
[ 2884.512177] ATOMP_EMB_SURFACE_STRIDE0[0]:0x0
[ 2884.516500] ATOMP_SURFACE_OFFSET0[0]:0x60100000
[ 2884.521115] ATOMP_SURFACE_STRIDE0[0]:0x600
[ 2884.525337] ATOMP_SURFACE_OFFSET0_H[0]:0x0
[ 2884.529455] ATOMP_SURFACE_OFFSET1[0]:0x0
[ 2884.533395] ATOMP_SURFACE_OFFSET1_H[0]:0x0
[ 2884.537528] ATOMP_SURFACE_STRIDE1[0]:0x0
[ 2884.541481] ATOMP_SURFACE_OFFSET2[0]:0x0
[ 2884.545432] ATOMP_SURFACE_OFFSET2_H[0]:0x0
[ 2884.549567] ATOMP_SURFACE_STRIDE2[0]:0x0
[ 2884.553515] CSIMUX_CONFIG_STREAM[0]:0x2000003
[ 2884.557904] MATCH[0]:0xfffff
[ 2884.560796] MATCH_DATATYPE[0]:0xfff
[ 2884.564311] DT_OVERRIDE[0]:0x0
[ 2884.567401] MATCH_FRAMEID[0]:0xffffffff
[ 2884.571243] FRAME_X[0]:0x2d0
[ 2884.574118] FRAME_Y[0]:0x240
[ 2884.577017] SKIP_X[0]:0x0
[ 2884.579645] CROP_X[0]:0x2d0
[ 2884.582439] OUT_X[0]:0x2d0
[ 2884.585178] SKIP_Y[0]:0x0
[ 2884.587862] CROP_Y[0]:0x240
[ 2884.590700] OUT_Y[0]:0x240
[ 2884.593439] PIXFMT_ENABLE[0]:0x0
[ 2884.596708] PIXFMT_WIDE[0]:0x0
[ 2884.599778] PIXFMT_FORMAT[0]:0xcb
[ 2884.603101] DPCM_STRIP[0]:0x0
[ 2884.606063] ATOMP_DPCM_CHUNK[0]:0x0
[ 2884.609556] ISPBUFA[0]:0x0
[ 2884.612270] LINE_TIMER[0]:0x1000000
[ 2884.615762] EMBED_X[0]:0x0
[ 2884.618463] EMBED_Y[0]:0x0
[ 2884.621176] ATOMP_RESERVE[0]:0x0
[ 2884.624409] CHANNEL_COMMAND[0]:0x0
[ 2884.627816] CONTROL[0]:0x3
[ 2884.630518] NOTIFY_MASK_XCPT[0]:0x0
[ 2884.634011] NOTIFY_MASK[0]:0x0

[ 2886.505595] =======port:2 lanes:1=========
[ 2886.509983] CIL_INTR_STATUS:0x144
[ 2886.513557] CIL_ERR_INTR_STATUS:0x144
[ 2886.517312] CIL_INTR_MASK:0x0
[ 2886.520536] CIL_ERR_INTR_MASK:0x0
[ 2886.523975] INTR_STATUS:0x0
[ 2886.526899] ERR_INTR_STATUS:0x0
[ 2886.530127] ERROR_STATUS2VI_MASK:0x0
[ 2886.533756] INTR_MASK:0x0
[ 2886.536429] ERR_INTR_MASK:0x0
[ 2886.539450] PPFSM_TIMEOUT_CTRL:0x0
[ 2886.542902] PH_CHK_CTRL:0x3
[ 2886.545732] VC0_DPCM_CTRL:0x0
[ 2886.548750] VC0_DT_OVERRIDE:0x0
[ 2886.551935] NVCSI_CIL_PHY_CTRL:0x0
[ 2886.555354] NVCSI_CIL_CONFIG:0x1
[ 2886.558582] NVCSI_CIL_A_SW_RESET:0x0
[ 2886.562191] NVCSI_CIL_A_PAD_CONFIG:0x700000
[ 2886.566406] NVCSI_CIL_PAD_CONFIG:0x0
[ 2886.570029] NVCSI_CIL_A_CONTROL:0x462199
[ 2886.573981] PP_EN_CTRL:0x1

The two registers show some error but i can not know which is root cause(csi or vi).
CSIMUX_CONFIG_STREAM[0]:0x2000003
CIL_INTR_STATUS:0x144

In csi calibration, lane0 and lane 1 are all calibrated. 
Adv7280m is connected to CSI port 2 lane 0,could this mean anything? 
Can I disable lane 1 explicitly ?

Hi, ShaneCCC.
I found an interesting thing that if I record trace(echo 1 > /sys/kernel/debug/tracing/tracing_on), sometimes I can get correct and consecutive frames.
The weird part is that if I add in the function tegra_channel_capture_frame(before calling code vi4_check_status(chan)) these log print below, I can always get correct consecutive frames. But I remove these log print, I can only get one correct frame.

    pr_err("MATCH:0x%x\n",vi4_channel_read(chan, 0, MATCH));
pr_err("MATCH_DATATYPE:0x%x\n",vi4_channel_read(chan, 0, MATCH_DATATYPE));
pr_err("DT_OVERRIDE:0x%x\n",vi4_channel_read(chan, 0, DT_OVERRIDE));
pr_err("MATCH_FRAMEID:0x%x\n",vi4_channel_read(chan, 0, MATCH_FRAMEID));
pr_err("FRAME_X:0x%x\n",vi4_channel_read(chan, 0, FRAME_X));
pr_err("FRAME_Y:0x%x\n",vi4_channel_read(chan, 0, FRAME_Y));
pr_err("OUT_X:0x%x\n",vi4_channel_read(chan, 0, OUT_X));
pr_err("OUT_Y:0x%x\n",vi4_channel_read(chan, 0, OUT_Y));
pr_err("PIXFMT_ENABLE:0x%x\n",vi4_channel_read(chan, 0, PIXFMT_ENABLE));
pr_err("PIXFMT_WIDE:0x%x\n",vi4_channel_read(chan, 0, PIXFMT_WIDE));
pr_err("PIXFMT_FORMAT:0x%x\n",vi4_channel_read(chan, 0, PIXFMT_FORMAT));

These logs consume only little time in capture loop and do not affect any regsiter setting. 
I think that these log can not affect CSI and VI function also.
I tried several value of cil_settletime, but nothing improved.
Can you figure out why I can get smooth and correct streams only after I add these log?

Could you try if ns_sleep() instead of pr_err()?

Hi ShaneCCC.
I have tried with different time delay.
When time delay 5ms, I got nearly half a frame on the player.
When time delay 10ms, I got nearly 3/4 frame on the player.
When time delay 15ms, I got a fall frame on the player.
When time delay 20ms, I got smooth stream with full frame on the player.
But what is the root cause of this?
The input video is PAL(720x576@25fps).

Please apply these two patch to try on 28.2

https://devtalk.nvidia.com/default/topic/1032825/jetson-tx1/camera-outputs-to-1-buffer-only/post/5254771/#5254771

Hi ShaneCCC
After patching the two patches you mentioned above, I can only get the first entire PAL frame.
Is this have anything with fps?
In function nvhost_syncpt_wait_timeout_ext in tegra_channel_release_frame, timeout=250,
is this timeout value not correct for PAL?

[ 39.496032] adv7280m_s_stream
[ 39.502241] tegra-vi4 15700000.vi: ATOMP_FE syncpt timeout! err = -11
===== MSENC blits (mode: 1) into tiled surfaces =====
[ 40.500388] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 41.504603] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 41.511253] tegra-vi4 15700000.vi: ATOMP_FE syncpt timeout! err = -11
[ 42.508562] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 43.512546] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 43.519161] tegra-vi4 15700000.vi: ATOMP_FE syncpt timeout! err = -11
[ 44.516424] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 45.520540] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 45.527148] tegra-vi4 15700000.vi: ATOMP_FE syncpt timeout! err = -11
[ 46.524521] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 47.528532] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 47.535257] tegra-vi4 15700000.vi: ATOMP_FE syncpt timeout! err = -11

@flower
It should doesn’t matter with the fsp and timeout value correct for PAL. I can’t figure out why this patch didn’t work for your case. Could you review the patch to check everything was done. Otherwise you can have 20ms delay for temp solution and check the next release.

Ok. Thank you, ShaneCCC.
I delay sometime in function tegra_channel_capture_frame when capture SD video, now both SD and HD video capture work correctly.

Highly appreciate for your work around ^_^ @ShaneCCC

From another guy save by your patch

Hi everyone.

I’m also in that trouble too. And in order to delay 20ms in tegra_channel_capture_frame, can i use msleep(20)?

Thanks for your help.

@haihoangsoftware
Just got some information for adv7280m support.
You may consult to vendor to modify the “user define data” to null between the FE and FS for this case.