Orin camera

What’s the serdes_pix_clk_hz?

serdes_pix_clk_hz = “375000000”;

可以截取,其实我们也只改了probe里面函数,在初始化配置了SER/DESER,剩下的框架都没有动

Please modify the serdes_pix_clk_hz to 374999999 to check if the still have the below error.
Please attached your source code here.

     kworker/1:2-123     [001] ....    83.353218: rtcpu_nvcsi_intr: tstamp:3297724785 class:GLOBAL type:PHY_INTR0 phy:2 cil:1 st:0 vc:0 status:0x06000000

我们修改了serdes_pix_clk_hz ,但是还是有这个错误,初始化的源码我们放在了附件
0231.c (9.1 KB)

Does the status value the same?
Please share whole source code if able.

Thanks

1、今天下午的测试无论serdes_pix_clk_hz 是否修改,都没有这PHY的错误出现了,但是单独运行timeout的问题还是存在;
2、源码重新上传到附件了,另外我们使用的相机都是带isp的,所以源码里面很多函数回调直接return 0
0231.c (25.6 KB)

Looks like your driver do nothing in the start/stop streaming. Suppose all of the start streaming after probe()?

What’s the sensor output clocks(continuous/non-continuous clocks)??

What’s this code for? Why hard code the addr to 0x40?

	priv->i2c_client->addr=0x40;
	ar0231_write_reg(priv->s_data,0x4,0x47);
	msleep(10);
	
	ar0231_write_reg(priv->s_data,0x7,0x84);
	msleep(100);
	

1、是的,初始化完成后 SER/DESER gmsl link建立连接后,数据就开始发送了,我们没有在start/stop做任何事
2、我们目前了解的是non-continuous clocks
3、这个地址是SER的默认地址,7位地址默认为0x80,对应6位就是0x40,这段代码用于设置SER,让SER/DESER gmsl link上

Does any REG able to start/stop the streaming of sensor and DESER?
If yes, please add it to the start_streaming()/stop_streaming() to try.

Does the trace log are the same?

我们以前就尝试过start_streaming里面打开gmsl link enable,stop_streaming 里面disabled gmsl link ,现象是一样的,还是会同样的错误;另外前面也提到过,即使video8-video11拔掉相机sensor(这个时候无论start_streaming()/stop_streaming()都没有mipi数据),也必须video8和video4同时运行,video4才能出来图像,我们一直怀疑是rtcpu什么原因没有通知vi5-fops有数据到达队列

Is it possible connect video8 -11 to CSI-GH to try?

Thanks

我们定制的底板没有使用到csi-gh,我只能将video的device-tree绑定到csi-GH试试,实际上没有物理连接

Well, how about the experiment for modify the device tree to CSI-GH?

我们解决了这个问题,问题的起因是因为layout的时候,csi2和csi3的对应max96712的mipi交叉了,即csi2-max96712_3 ,csi3-max96712_2,当时就通过修改devie-tree的port绑定关系来解决layout的反接的问题,然后就产生了现在这个问题,现在我们将device-tree的绑定关系修改回来之后,这个问题不再产生

Good to know the problem fixed.

Thanks

sorry,这个问题依然存在,当时修改回来device-tree只测了video7和video11之间是否互相影响,以为解决了问题,video7数据是没有问题,但是当我们测试video4的时候,出现了下面的错误:

kworker/7:0-3702 [007] … 574.233672: rtcpu_vinotify_error: tstamp:18693932075 cch:-1 vi:1 tag:CHANSEL_NOMATCH channel:0xc4 frame:0 vi_tstamp:598205699104 data:0x00000000000003c9
kworker/7:0-3702 [007] … 574.289669: rtcpu_vinotify_event: tstamp:18694358671 cch:-1 vi:1 tag:FS channel:0x03 frame:0 vi_tstamp:598205213152 data:0x0000000000000012
kworker/7:0-3702 [007] … 574.289671: rtcpu_vinotify_event: tstamp:18694358806 cch:-1 vi:1 tag:CHANSEL_NOMATCH channel:0xc4 frame:0 vi_tstamp:598205699104 data:0x00000000000003c9
kworker/7:0-3702 [007] … 574.289671: rtcpu_vinotify_event: tstamp:18695443762 cch:-1 vi:1 tag:FE channel:0x03 frame:0 vi_tstamp:598237675136 data:0x0000000000000022

我们发现数据正常的情况下rtcpu log 中 channel 为0x23,这个channel有什么影响吗,根据哪个地方决定的?
kworker/2:2-116 [002] … 117.063498: rtcpu_vinotify_event: tstamp:4405904077 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:140972429344 data:0x0000000031000058
kworker/2:2-116 [002] … 117.063500: rtcpu_vinotify_event: tstamp:4406446713 cch:0 vi:0 tag:CHANSEL_PXL_EOF channel:0x23 frame:0 vi_tstamp:141004013696 data:0x0000000004370002
kworker/2:2-116 [002] … 117.063501: rtcpu_vinotify_event: tstamp:4406446868 cch:0 vi:0 tag:FE channel:0x00 frame:0 vi_tstamp:141004014240 data:0x0000000000000020
kworker/2:2-116 [002] … 117.063501: rtcpu_vinotify_event: tstamp:4406447005 cch:0 vi:0 tag:ATOMP_FE channel:0x00 frame:0 vi_tstamp:141004014336 data:0x0000000800000000
kworker/2:2-116 [002] … 117.063502: rtcpu_vinotify_event: tstamp:4406447159 cch:0 vi:0 tag:ATOMP_FRAME_DONE channel:0x23 frame:0 vi_tstamp:141004014656 data:0x0000000000000000
kworker/2:2-116 [002] … 117.063502: rtcpu_vinotify_event: tstamp:4406447293 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:0 vi_tstamp:141004066976 data:0x0000000002020057
kworker/2:2-116 [002] … 117.063503: rtcpu_vinotify_event: tstamp:4406447446 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:0 vi_tstamp:141004083392 data:0x0000000000020057
kworker/2:2-116 [002] … 117.063504: rtcpu_vinotify_event: tstamp:4406989265 cch:0 vi:0 tag:FS channel:0x00 frame:0 vi_tstamp:141021551392 data:0x0000000000000010
kworker/2:2-116 [002] … 117.063505: rtcpu_vinotify_event: tstamp:4406989422 cch:0 vi:0 tag:ATOMP_FS channel:0x00 frame:0 vi_tstamp:141021551488 data:0x0000000800000000
kworker/2:2-116 [002] … 117.063505: rtcpu_vinotify_event: tstamp:4406989554 cch:0 vi:0 tag:CHANSEL_PXL_SOF channel:0x23 frame:0 vi_tstamp:141022037344 data:0x0000000000000001
kworker/2:2-116 [002] … 117.063506: rtcpu_vinotify_event: tstamp:4406989711 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:0 vi_tstamp:141022048224 data:0x0000000008020058
kworker/2:2-116 [002] … 117.063507: rtcpu_vinotify_event: tstamp:4406989845 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:141022294784 data:0x399d580010000000
kworker/2:2-116 [002] … 117.063507: rtcpu_vinotify_event: tstamp:4406989999 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:141022338112 data:0x0000000031000059

This log tell the channel of video7 was closed but still receive data from it. Due to your design always output data after system start that could be know message for that.

BTW, 0x23 shouldn’t key point of the problem.

我们重新完整测试了修改设备树之后的情况,现在的现象是上电初始化后video4 -video8 tegracam_v4l2subdev_register注册成功后,video4和video8都能正常输出数据,而如果video4或者video8在初始化过程中发现相机未连接后执行tegracam_v4l2subdev_unregister后,video4和video8都不能正常输出数据;同样的现象出现在video5-video9、video6-video10和video7-video11,