Hi,
请允许我用中文表达。
我们定制了一款载板，上面有3个max96724. 每个max96724出4路gmsl， 每个max96724为x4模式
相机参数：isx031+max9295 (1920x1536 30FPS UYVY)
1，每个max96724配置输出频率为1500Mhz/lane, dts中对应的serdes_pix_clk_hz为375000000
（1500000000*4/16=375000000）
这种情况下，能正常打开
2，max96724配置输出频率为2000Mhz/lane，dts中对应的serdes_pix_clk_hz为50000000（2000000000*4/16=500000000），这个情况下，打开相机，绿屏，96724出来的mipi信号是能量到的
kernel_2000Mhz.txt (120.6 KB)
trace.txt (31.8 KB)
附件是kernel log以及trace
帮忙分析下方向，谢谢
hello haihui.pang,
please test 2G/lane with below commands to boost all the VI/CSI/ISP clocks.
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
echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/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
cat /sys/kernel/debug/bpmp/debug/clk/emc/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/emc/rate
hello haihui.pang,
were you able to fetch camera frames after clock boosting?
执行以下这些命令后，现象还是一样，打开相机，绿屏
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
echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/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
cat /sys/kernel/debug/bpmp/debug/clk/emc/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/emc/rate
hello haihui.pang,
may I know what’s your test pipeline?
could you please refer to Applications Using V4L2 IOCTL Directly to verify the basic camera functionality.
我是用下面这个命令打开的相机，是否有问题？
gst-launch-1.0 -v v4l2src device=/dev/video0 ! video/x-raw,format=UYVY,width=1920,height=1536,framerate=30/1 ! videoconvert ! autovideosink
hello haihui.pang,
it should be okay, I assume you’re using the same gst pipeline to capture 1.5G stream.
let’s try to gather VI tracing logs with clocks boosted,
and, using below v4l2 standard IOCTL to fetch the camera stream,
for instance,
$ v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1536,pixelformat=UYVY --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100
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
echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/mrq_rate_locked
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/camera_common/enable
echo > /sys/kernel/debug/tracing/trace
再执行v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1536,pixelformat=UYVY --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100
kernel还是报timeout的错误
附件是trace
trace-2.txt (41.0 KB)
hello haihui.pang,
it looks there’s no validate frames detected by VI engine,
let me share VI tracing logs with a success image capture as an example,
here must be one pair of CHANSEL_PXL_SOF/CHANSEL_PXL_EOF to indicate a frame has detected by VI engine.
afterwards, it’s ATOMP_FRAME_DONE to indicate it’s complete writing a frame to memory.
for instance,
rtcpu_vinotify_event: tstamp:4058867917 cch:-1 vi:0 tag:CSIMUX_STREAM channel:0x00 frame:0 vi_tstamp:129874754944 data:0x0000000000000001
rtcpu_vinotify_event: tstamp:4059206674 cch:0 vi:0 tag:ATOMP_FS channel:0x00 frame:1 vi_tstamp:129891804896 data:0x0000000800000000
rtcpu_vinotify_event: tstamp:4059206818 cch:0 vi:0 tag:CHANSEL_PXL_SOF channel:0x23 frame:1 vi_tstamp:129891808928 data:0x0000000000000001
rtcpu_vinotify_event: tstamp:4059206976 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:1 vi_tstamp:129891815424 data:0x0000000008020001
rtcpu_vinotify_error: tstamp:4060164160 cch:0 vi:0 tag:CSIMUX_FRAME channel:0x00 frame:1 vi_tstamp:129925171392 data:0x00000000000000a0
rtcpu_vinotify_event: tstamp:4060166846 cch:0 vi:0 tag:CHANSEL_PXL_EOF channel:0x23 frame:1 vi_tstamp:129923836800 data:0x0000000004370002
rtcpu_vinotify_event: tstamp:4060167015 cch:0 vi:0 tag:ATOMP_FRAME_DONE channel:0x23 frame:1 vi_tstamp:129923837312 data:0x0000000000000000
did you double check you’ve loading device tree settings correctly?
please execute below commands to dump device tree into dts formats for checking.
for instance,
$ sudo dtc -I fs -O dts /sys/firmware/devicetree/base > /tmp/123.dts
123.dts.txt (374.5 KB)
附件是dts
dts应该是没问题的，把max96724 Dphy data rate/lane 设置成1.5G，且dts里面把serdes_pix_clk_hz设置为375000000是没问题的
现在只接了一个相机，对应123.dts里面的isx031_3_a@1a
serdes_pix_clk_hz=500000000
max96724 Dphy data rate/lane=2.0G
有个疑问，
Skew calibration is required if sensor or deserializer is using DPHY, and the output data rate is > 1.5Gbps.
An initiation deskew signal should be sent by sensor or deserializer to perform the skew calibration. If the deskew signals is not sent, the receiver will stall, and the capture will time out.
You can calculate the output data rate with the following equation:
这里说，如果output data rate大于1.5Gbps，需要Skew calibration
1，
serdes_pix_clk_hz=500000000
max96724 Dphy data rate/lane=2.0G
这种情况是否需要Skew calibration
2，csi.c 的deskew_setup 里面
if (sig_props->serdes_pixel_clock.val != 0ULL)
pix_clk_hz = sig_props->serdes_pixel_clock.val;
else
pix_clk_hz = sig_props->pixel_clock.val;
deskew_enable = sig_props->deskew_initial_enable;
printk(“panghh deskew_setup pix_clk_hz=%llu deskew_enable=%d\n”,pix_clk_hz,deskew_enable); //panghh
if (pix_clk_hz >= CLK_HZ_FOR_DESKEW && deskew_enable) {
为什么是serdes_pixel_clock和CLK_HZ_FOR_DESKEW比较呢，不应该是Output data rate和CLK_HZ_FOR_DESKEW比较吗
hello haihui.pang,
deskew calibration is a must if data-rate > 1.5 Gbps, Else the camera firmware will continue to wait for deskew signal from the sensor side. it’ll enable pixel parser when deskew calibration has completed.
dmesg_20260129_112554.txt (160.6 KB)
trace_20260129.txt (645.3 KB)
更新了debug的camera firmware
deser端打开了deskew，
帮忙看下dmesg和trac log
hello haihui.pang,
let me re-cap the logs..
[ 214.790229] [RCE] nvcsi_stream_enable: enable pixel parser++ Line(3554)
[ 214.790233] [RCE] nvcsi_stream_enable: enable pixel parser-- Line(3591)
[ 214.846213] [RCE] ISR PHY 0 CIL_A 0xe000000
[ 214.846224] [RCE] ISR PHY 0 CIL_B 0x6000000
this is due to DPHY deskew calibration not complete, it happened when the calibration sequence length is not long enough.
please give it a try to configure cil_settletime, and please also review the serdes_pix_clk_hz settings.
关于是否需要deskew calibration
我想确认一下我的理解是否是对的
1，max96724 reg 0x418 写0x34 即，DPHY data rate/lane为2.0Gbps/lane
2，sensor数据格式是YUV422
3，lane width为4
那么serdes_pix_clk_hz=2000000000*4/16=500000000
那么是否需要deskew calibration，是以500000000准，还是2000000000为准
hello haihui.pang,
camera stack parse both of them, once you’ve serdes_pix_clk_hz, it should be larger than pix_clk_hz,
you may dig into below for details.
for instance, $public_sources/kernel_src/kernel/nvidia-oot/drivers/media/platform/tegra/camera/sensor_common.c
static int sensor_common_parse_signal_props{
...
if (signal->serdes_pixel_clock.val != 0ULL) {
if (signal->serdes_pixel_clock.val < signal->pixel_clock.val) {
dev_err(dev,
"%s: serdes_pix_clk_hz is lower than pix_clk_hz!\n",
__func__);
return -EINVAL;
}
rate = signal->serdes_pixel_clock.val;
...
Hi，
你的意思是dts里面的serdes_pix_clk_hz 值大于1500000000，才需要deskew calibration吗？
hello haihui.pang,
that’s correct, camera firmware continue to wait for deskew signal from the sensor side once the data-rate is larger than 1.5Gbps.