[参考译文] J722SXH01EVM：FIFO 溢出后的多个 VC ID 期间的 CSI0 失真

尊敬的 Evan Williams：

您使用的内核版本是什么？ 当前是否应用此修补程序： https://lore.kernel.org/all/20250811-probe_fixes-v4-6-aae22290f1d0@ideasonboard.com/ 

该补丁修复了此常见问题解答：  【常见问题解答】AM6X：如何修复具有 NUM_Pixels 的 CSI2RX Linux 驱动程序中的流 FIFO 溢出错误？  

是否有解决方案： TDA4VM：从 Lontium LT7911D 捕获 CSI 的 TDA4VM 问题

此致、
Jared

我还想指出的是、这不能解决 CSI 驱动程序的潜在问题。 对于多个数据流、FIFO 错误可能会导致此问题。 因此、我的解决方法修复了常见情况、但仍然存在漏洞。
作为测试、我更改了 GMSL 芯片上的调优以触发 FIFO/CRC 故障、并且仍然能够重现损坏的竖线。
这也会对 BCI 抗扰性测试产生影响、因为活动流可能无法正确恢复。  现在可以关闭机票、但当我们开始测试 BCI 时、我可能会打开另一张。

“stram0"的“的 CSI_rx_if_CSI_rx_if0_public 寄存器似乎对 VC ID 0 和 1 都有影响。 我还发现设置 SOFT_RST 可能会使偏移明显更糟或将其修复。 但是、我无法让 VC id 1 的起始值显示在我的 VC id 0 流中、因此似乎有些东西几乎是正确的。 也许这是两个帧如何结束的一个伪影

尊敬的 Evan Williams：

我在将虚拟通道与我们的 FPD link 串行器/解串器配合使用时没有看到 FIFO 错误。 您用于摄像头和 CSI 控制器的参数是什么（数据速率，像素频率，分辨率，数据类型，帧速率， 等）？

执行 软复位来清除 FIFO 似乎是 TRM 中建议的解决方案：

12.6.1.4.8.5 使用软复位进行错误控制

CSI_RX_IF 将对软复位进行控制、以用于错误事件恢复或清除流 FIFO 或
内部状态机。

• 如果 DPHY_RX 无响应并且控制器希望保持其配置、则可以对前块进行软复位。 在这种情况下、可以应用 DPHY_RX 复位并启用 DPHY_RX 以 再次开始传输。
• 如果需要前部软复位且协议未处于空闲 状态、则可对协议块进行软复位。
• 流软复位 (CSI_RX_IF_VBUS2APB_STREAM0_CTRL - CSI_RX_IF_VBUS2APB_STREAM3_CTRL)[4] SOFT_RST 可用于将流清除为停止状态 并复位所有流状态机和 FIFO。 如果系统发生故障并希望清除流 FIFO 并在像素接口上返回到安全状态、则应使流软复位生效。

尽管如此、它还指出不应发生您的问题：

12.6.1.4.6.2 由于 FIFO 溢出而导致的 PSI_L DMA 错误处理

DMA 错误处理也称为 PSI_L 协议执行器。 它旨在防止 PSILSS0 挂起。  不自然的数据包大小不应导致挂起、因此只实施 SOP/SOL/EOL/EOP 组帧。 以下列表 重点介绍了错误处理机制：

• 对于上下文清理、协议执行器：
  • 循环检查每个上下文索引、检查上下文是在 MOL 还是 MOP 中
  •  使用 EOP 关闭 MOP、使用 EOL&EOP 关闭 MOL&MOP
• dropOnFloor SOP（如果当前处于 MOPstate）
• dropOnFloor EOP（如果当前未处于 MOPstate）
• dropOnFloor FIFO 数据
• EOP 和 MOLstate 时的 EOL 上下文
• 关闭所有打开的上下文后、PSILSS0 逻辑将等待每个虚拟通道的帧结束。 新帧启动后、它将开始从该新帧发送数据

此致、
Jared

您好 Jared、

谢谢您的提问。 我还收到了 isl79987 芯片的这个故障、该芯片完全位于 PCB 上。
故障不会立即发生、只会在运行几个小时后发生。


在器件树中、我们使用：

数据通路=<1 2>；
时钟通道=<0>；
链路频率=/bits/64 <800000000>；

模拟摄像机的分辨率为 720x480。
我们以每秒 60 帧的速度对其计时。

这也是此芯片的故障：

v4l2-ctl --log-status -d /dev/v4l-subdev1

状态日志：

cdns_csi2rx.30121000.csi-bridge：================ START STATUS =================
cdns-csi2rx 30121000.csi-bridge：已接收到保留或无效的短数据包事件：33
cdns-csi2rx 30121000.csi-bridge：报头数据包中的数据 ID 错误事件：33
cdns-csi2rx 30121000.csi-bridge:检测到 ECC 错误、已纠正事件：579.
cdns-csi2rx 30121000.csi-bridge:不可恢复的 ECC 错误事件:608.
cdns-csi2rx 30121000.csi-bridge：CRC 错误事件：22
cdns_csi2rx.30121000.csi-bridge：================= END STATUS ==================

它也以同样的方式禁止腐败。 也许这发生在任何 CRC 或标头数据包错误的情况下呢？ 这仅在多个流同时发生的情况下发生。

media-ctl -p -d /dev/media1
媒体控制器 API 版本 6.12.43

媒体设备信息
----------------------------
驱动器 j721e-csi2rx
模型 TI-CSI2RX
串行
总线信息平台：30122000.ticsi2rx
硬件修订版本 0x1
驱动程序版本 6.12.43

器件拓扑
-实体 1: 30122000.ticsi2rx（5 个电极,5 个链路,4 条路由）
键入 V4L2 subdev 子类型未知标志 0
器件节点名称/dev/v4l-subdev0
路线：
0/0 ->1/0【活动】
0/1 ->2/0【正在供货】
0/2 -> 3/0【活动】
0/3 -> 4/0【有效】
pad0：水槽
[stream：0 fmt：UYVY8_1x16/720x480 字段：无色空间：sRGB xfer：sRGB YCbCr：601 量化：lim-range]
[stream：1 fmt：UYVY8_1x16/720x480 字段：无色空间：sRGB xfer：sRGB YCbCr：601 量化：lim-range]
[stream：2 fmt：UYVY8_1x16/720x480 字段：无色空间：sRGB xfer：sRGB YCbCr：601 量化：lim-range]
[stream：3 fmt：UYVY8_1x16/720x480 字段：无色空间：sRGB xfer：sRGB YCbCr：601 量化：lim-range]
<-“cdns_csi2rx.30121000.csi-bridge"：“：1【已启用，不可更改】
pad1：来源
[stream：0 fmt：UYVY8_1x16/720x480 字段：无色空间：sRGB xfer：sRGB YCbCr：601 量化：lim-range]
->“30122000.ticsi2rx 上下文 1“：0【已启用，不可更改】
pad2：来源
[stream：0 fmt：UYVY8_1x16/720x480 字段：无色空间：sRGB xfer：sRGB YCbCr：601 量化：lim-range]
->“30122000.ticsi2rx 上下文 2“：0【已启用，不可更改】
pad3：来源
[stream：0 fmt：UYVY8_1x16/720x480 字段：无色空间：sRGB xfer：sRGB YCbCr：601 量化：lim-range]
->“30122000.ticsi2rx 上下文 3“：0【已启用，不可更改】
pad4：来源
[stream：0 fmt：UYVY8_1x16/720x480 字段：无色空间：sRGB xfer：sRGB YCbCr：601 量化：lim-range]
->“30122000.ticsi2rx 上下文 4“:0【已启用，不可更改】

-实体 7：cdns_csi2rx.30121000.csi-bridge（5 个电极、2 个链路、4 条路由）
键入 V4L2 subdev 子类型未知标志 0
器件节点名称/dev/v4l-subdev1
路线：
0/0 ->1/0【活动】
0/1 ->1/1【正在供货】
0/2 -> 1/2【有效】
0/3 -> 1/3【活动】
pad0：水槽
[stream：0 fmt：UYVY8_1x16/720x480 字段：无色空间：sRGB xfer：sRGB YCbCr：601 量化：lim-range]
[stream：1 fmt：UYVY8_1x16/720x480 字段：无色空间：sRGB xfer：sRGB YCbCr：601 量化：lim-range]
[stream：2 fmt：UYVY8_1x16/720x480 字段：无色空间：sRGB xfer：sRGB YCbCr：601 量化：lim-range]
[stream：3 fmt：UYVY8_1x16/720x480 字段：无色空间：sRGB xfer：sRGB YCbCr：601 量化：lim-range]
<-“isl7998x 4-003c“：0【已启用，不可更改】
pad1：来源
[stream：0 fmt：UYVY8_1x16/720x480 字段：无色空间：sRGB xfer：sRGB YCbCr：601 量化：lim-range]
[stream：1 fmt：UYVY8_1x16/720x480 字段：无色空间：sRGB xfer：sRGB YCbCr：601 量化：lim-range]
[stream：2 fmt：UYVY8_1x16/720x480 字段：无色空间：sRGB xfer：sRGB YCbCr：601 量化：lim-range]
[stream：3 fmt：UYVY8_1x16/720x480 字段：无色空间：sRGB xfer：sRGB YCbCr：601 量化：lim-range]
->“30122000.ticsi2rx"：“：0【已启用，不可更改】
pad2：来源
pad3：来源
pad4：来源

-实体 13：isl7998x 4-003c（5 个电极、1 个链路、4 条线路）
键入 V4L2 subdev 子类型未知标志 0
器件节点名称/dev/v4l-subdev2
路线：
1/0 -> 0/0【活动】
2/0 -> 0/1【有效位】
3/0 -> 0/2【活动】
4/0 -> 0/3【有效】
pad0：来源
[stream：0 fmt：UYVY8_1x16/720x480 字段：seq-Bt]
[流：1 fmt：UYVY8_1x16/720x480 字段：seq-Bt]
[流：2 fmt：UYVY8_1x16/720x480 字段：seq-Bt]
[流：3 fmt：UYVY8_1x16/720x480 字段：seq-Bt]
->“Cdns_csi2rx.30121000.csi-bridge"：“：0【已启用，不可更改】
pad1：水槽
[stream：0 fmt：UYVY8_1x16/720x480 字段：seq-Bt]
pad2：水槽
[stream：0 fmt：UYVY8_1x16/720x480 字段：seq-Bt]
pad3：水槽
[stream：0 fmt：UYVY8_1x16/720x480 字段：seq-Bt]
pad4：水槽
[stream：0 fmt：UYVY8_1x16/720x480 字段：seq-Bt]

-实体 23: 30122000.ticsi2rx 上下文 1（1 个 pad, 1 个链接）
键入节点子类型 V4L 标志 0
器件节点名称/dev/video2
pad0：水槽
<-“30122000.ticsi2rx"：“：1【已启用，不可更改】

-实体 29: 30122000.ticsi2rx 上下文 2（1 个 pad, 1 个链接）
键入节点子类型 V4L 标志 0
器件节点名称/dev/video3
pad0：水槽
<-“30122000.ticsi2rx"：“：2【已启用，不可更改】

-实体 35: 30122000.ticsi2rx 上下文 3（1 个 pad, 1 个链接）
键入节点子类型 V4L 标志 0
器件节点名称/dev/video4
pad0：水槽
<-“30122000.ticsi2rx"：“：3【已启用，不可更改】

-实体 41: 30122000.ticsi2rx 上下文 4（1 个 pad, 1 个链接）
键入节点子类型 V4L 标志 0
器件节点名称/dev/video5
pad0：水槽
<-“30122000.ticsi2rx"：“：4【已启用，不可更改】

尊敬的 Evan Williams：

在数据表中、我看到：  

• MIPI 输出
• 符合 MIPI CSI-2 版本 1.1 标准的单向输出
• 标准虚拟识别通道支持
• 非标准伪虚拟通道支持
• 一个或两个数据信道
• YUV422 或 RGB565 输出格式

也许它正在使用“非标准虚拟通道支持“？

此致、
Jared

您好 Jared、

感谢您查看这个。
我清除了非标准位、因此它在正常标准虚拟 ID 通道下运行。
例如、如果我设置该位、则只流式传输 0 时钟数据、并且两个摄像头相互叠加、每帧一个摄像头。
 i2cset -y -f 4 0x3c 0x06 0x01

我发现如果我设置了 8BHDR 位、然后清除它、两个视频源会像看到 CRC 错误一样移位。
这会导致馈电暂时偏斜约 45 度、直到我清除该位。

“1 =在 MIPI 输出中添加 8 字节标头（长数据包有效载荷中为 1448 字节）“

因此：
i2cset -y -f 4 0x3c 0x06 0x20
i2cset -y -f 4 0x3c 0x06 0x00

我想添加一个图像、但这对我来说目前不起作用。

尊敬的 Evan Williams：

我应该说,我看的是“数据短“。 我无法访问整个数据表。

会发生很多标头错误、ECC 错误和 CRC 错误。 在测试 CSI 摄像头和 FPD-link 摄像头/串行器/解串器时、我不观察到这些情况。

是否有任何其他寄存器会将数据更改为非标准数据？  

此致、
Jared

您好 Jared、

我注意到、即使没有右移、它也会随着时间的推移在 csi1 外设上累积 CRC 错误。
我想象一个损坏的数据包最终会将视频源向右移动 4 像素。
我不确定是否还有一个模式。

可能需要调整 CSI 设置、或者出现硬件问题？
我认为我在 2 秒突发中看到错误、可能每~500 秒发生一次？

在以下位置发生错误：
238 秒
239.
280
281.
729
730
771.
1219
1220
1262
1263
1710.
1711.
1752
1753
2200
2201.

它是每 500 秒、然后是 40 秒？

在数据移动超过 4 个像素后,我可以看到每秒被移动一条线的损坏的数据“嘀嗒“,所以这很可能匹配大约行数,大约 480 行? 那么、两个数据流之间可能会出现某种时钟偏差？

尊敬的 Evan Williams：

数据速率高于 1.5Gbps（您看来是这样）时、需要 进行偏移校准。

在 DS90UB960 中、有以下寄存器：

您的器件可能有类似的响应。

此致、
Jared