工具/软件：
您好、
我们面临着一个类似的问题、即我们使用 DSI83-Q1 进行 MIPI 至 LVDS 转换。 我们使用 DSI REFCLK 作为参考时钟。 连接的波形为启动序列。 
我们看到、有时屏幕会随机出现空白。
我们正在尝试在实验中重现该问题、我们认为应通过短接抖动来将抖动随机引入 DSI CLK。 我们看到的是,在短时间内,有时屏幕自动恢复,而有时它根本不会恢复。 我们已验证同步时间、DSI 和 LVDS 同步时间相同、并且在启动中没有发现问题。
我们希望详细了解这一点-
1.为避免 PLL 解锁、可以采取哪些措施来避免此类问题（均衡，LVDS 端接）等。
2.为什么问题会自动恢复,而不是其他时间 — 可以调整什么（如果有 PLL 锁定时间等限制）使其自动恢复?
尊敬的 Ikram：
当我们使用测试模式生成时 — 问题未自行重现，但如果我们缩短时钟线，问题会重现，即它不会自动恢复。 这意味着 DSI 侧本身的时钟恢复肯定存在问题、因为 LVDS 侧看起来非常稳定。
我们也尝试更新 CSR 寄存器、但仍然看到空白屏幕不会自动恢复、这意味着 PLL 锁定肯定有问题。 我将在此处附加 CSR 寄存器列表以及面板信息
生成的 CSR 工具
e2e.ti.com/.../CSR-edited-tool-w-TP.txt
面板信息-
此外、我们无法找出一种有效的方法来使用完整反馈、因为寄存器 0xE5 也会在工作场景中出现错误。 像即使屏幕运行良好一样、0xE5 寄存器也不为零、因此我们无法 针对何时运行 PLL_EN 和 SOFT_RST 实现反馈环路。
您能让我们了解一下我们应该如何实施这个错误检查回路、以便更好地理解真正的失效情况吗？并且可以实现 PLL 锁定状态吗？
尊敬的 Ikram：
此外、
DSI 工具会生成一些不在数据表中的额外寄存器集 (0x13、0x26、0x27、0x2A、0x2B、 0x2E、0x2F、0x32、0x33、0x35、 0x37、0x39、0x3B、0x3D、0x3E)-因此我们已将其删除。
附件是对我们有效的寄存器和设置列表、并为面临相同问题的人提供了一个通用指南。
e2e.ti.com/.../CSR-edited-tool.txt
这已经清除了 CONFIG 寄存器上的所有错误、但我们仍然可以看到、如果引入了故障、则不会发生自动恢复。 在 SN65DSI83-Q1 用例中、此功能是否正常？
