TI Jacinto/TDA平台实现离散同步YUV422输出的硬件旁路与TDM方案

1. 项目概述与核心挑战

在汽车电子领域，尤其是高级驾驶辅助系统（ADAS）和环视系统（SRV）的开发中，视频信号的格式兼容性往往是一个容易被忽视但至关重要的环节。我最近在基于TI Jacinto/TDA平台进行一个SRV项目时，就遇到了一个典型的“历史包袱”问题：我们的SRV系统需要将处理后的全景视频输出到车机信息娱乐系统，而车机端为了兼容原有的后视摄像头（RVC），其视频解串器通常只支持YUV422格式。然而，翻开Jacinto/TDA系列芯片的显示子系统（DSS）技术参考手册，你会发现一个令人头疼的限制——其原生视频输出接口要么是RGB格式，要么是一种非标准的、水平消隐期不满足BT.656/1120规范的嵌入式同步YUV422输出。

这意味着，如果你直接使用DSS的YUV422输出模式，市面上绝大多数标准的视频解码芯片或显示屏控制器都无法正确识别你的信号，画面会出现撕裂、错位或者干脆无显示。这个技术壁垒迫使许多方案商在车机端不得不为SRV和RVC准备两套不同的解串器，增加了系统复杂度、布板面积和整体BOM成本。我们的目标很明确：打破这个限制，让基于Jacinto/TDA的SRV系统能够输出标准的、带离散同步信号（HSYNC, VSYNC, DE）的YUV422视频流，从而与RVC共用同一套YUV422解串链路，实现设计的简化和成本的优化。这不仅仅是改个配置那么简单，它需要深入理解DSS的硬件流水线架构，并巧妙地利用其现有功能进行“曲线救国”。

2. 技术原理深度解析：为何DSS原生不支持离散同步YUV422？

要解决问题，首先得理解问题的根源。TI Jacinto/TDA系列的DSS在设计上是一个高度集成且功能强大的显示控制器，但其视频输出接口的格式支持有其特定的硬件考量。

2.1 嵌入式同步 vs. 离散同步

视频输出接口主要分为两种同步方式：

• 嵌入式同步：如BT.656/BT.1120标准。这种模式下，同步信号（SAV, EAV）和消隐信息被编码到数据流中，与像素数据一起传输。物理接口只需要像素时钟（PCLK）和数据线（如YUV的8位或10位接口）。接收端需要从数据流中实时解码出同步信息。这种方式节省了引脚，但对编码/解码时序有严格标准。
• 离散同步：这是更通用、更直观的方式。除了PCLK和数据线，还会提供独立的行同步（HSYNC）、场同步（VSYNC）和数据使能（DE）信号。时序完全由这些同步信号的电平跳变来定义，配置灵活，易于对接各种LCD屏或通用视频接收器。

DSS硬件对这两种模式的支持是“分而治之”的。对于YUV422格式，其硬件编码器是为嵌入式同步场景优化的，其水平消隐期的寄存器位宽被限制在了8位，最大只能表示256个像素时钟的消隐期。而标准的BT.656（PAL制式要求280字节，NTSC要求268字节）和BT.1120要求的消隐期都超过了这个限制。这就导致了DSS产生的嵌入式同步YUV422信号是一个“非标”信号，与大多数标准解码器不兼容。

2.2 硬件流水线的“思维定势”

DSS内部的视频处理流水线（VID Pipeline）包含色彩空间转换（CSC）、缩放、叠加（Overlay）等模块。这里存在一个关键的硬件逻辑：为了支持带透明通道的图层叠加，流水线内部默认要求所有参与混合的图层数据都是RGB格式。因此，当你将视频输入格式配置为YUV422时，流水线会强制启动CSC模块，将其转换为RGB再进行后续处理。最终输出时，如果配置为YUV格式，又会再转换一次。这导致我们无法获得“原汁原味”的YUV422比特流输出。

理解了这两个核心限制，我们的解决思路就清晰了：

1. 规避嵌入式同步的限制：放弃使用DSS原生的YUV422输出模式，转而使用其完全支持的RGB离散同步输出接口。
2. 欺骗流水线，实现比特精确透传：想办法让YUV422数据“伪装”成RGB数据通过VID Pipeline，并且确保流水线中的所有处理模块都被旁路掉，让数据无损地穿过。
3. 解决位宽匹配问题：RGB离散同步接口是24位（RGB888）或16位（RGB565），而YUV422是16位/像素。我们需要一种机制，将16位的像素数据通过可能是8位宽的数据接口传输出去。

3. 核心方案：离散同步YUV422输出的实现机制

基于上述分析，我们设计了一套组合拳，核心是“旁路+Bypass”和“时分复用+TDM”。

3.1 第一阶段：VID Pipeline的“隐身术”

目标是让YUV422数据以RGB565的“身份”安全通过VID Pipeline，且不被任何处理模块修改。这里的关键在于利用VID Pipeline为RGB565格式提供的特殊“优待”。

操作原理与寄存器配置：我们选择一个VID Pipeline（例如VID1）作为最终的输出通道。需要进行如下关键配置：

1. 格式伪装：将DISPC_VID1_ATTRIBUTES.FORMAT寄存器设置为0x6，即RGB16-565模式。这相当于告诉DSS硬件：“接下来送进来的是RGB565数据”。由于RGB565是16位/像素，与YUV422的16位/像素位宽一致，这为数据透传提供了物理基础。
2. 关闭色彩转换：当输入格式被声明为RGB565时，DSS会默认旁路掉VC-1范围映射和色彩空间转换（CSC）模块。这是我们实现比特精确透传的第一步，确保了YUV数据不会被当作YUV进行RGB转换。
3. 关闭缩放：将DISPC_VID1_ATTRIBUTES.RESIZEENABLE设为0，并确保DISPC_VID1_SIZE（输出尺寸）与DISPC_VID1_PICTURE_SIZE（内存中帧缓冲区尺寸）的宽高完全一致。这样，缩放器（Scaler）模块也会被旁路。
4. 关闭其他处理：根据应用需要，关闭透明色键（DISPC_CONFIG1.TCKLCDENABLE = 0）和色彩相位旋转（DISPC_CONFIG1.CPR = 0）等功能，确保数据路径最简洁。

完成这些配置后，VID1 Pipeline就变成了一个“透明通道”。你从DMA写入内存的YUV422数据（但以RGB565的格式描述符提交），会原封不动地到达叠加混合器，并在混合后准备输出。

关键细节：这里的内存缓冲区数据排列必须是YUV422交织格式（例如YUYV或UYVY），但在提交给DSS驱动时，需要将其描述为一个RGB565格式的缓冲区。这通常需要在驱动层或应用层进行“欺骗”，告诉框架这是一个RGB565的buffer，尽管其内容实质是YUV422。

3.2 第二阶段：TDM时分复用输出

现在，我们有了无损的16位YUV422数据流，准备从DSS的物理接口输出。但我们的目标接口可能是8位的FPD-Link III串行器（如TI的UB933）。如何用8位数据线传输16位像素？答案就是TDM。

TDM工作原理：DSS支持将单个像素的数据分拆到多个像素时钟周期内输出。对于16位像素通过8位接口的情况，我们配置为2周期模式。

• 周期1：输出16位数据的高8位（例如Y分量）。
• 周期2：输出16位数据的低8位（例如Cb/Cr分量，具体顺序取决于YUV422的打包格式，如UYVY或YUYV）。

寄存器配置：

1. 启用TDM：DISPC_VP1_CONTROL.TDMENABLE = 0x1
2. 设置接口宽度：DISPC_VP1_CONTROL.TDMPARALLELMODE = 0x0(选择8位并行接口)
3. 设置每像素周期数：DISPC_VP1_CONTROL.TDMCYCLEFORMAT = 0x2(2个周期输出1个像素)
4. 配置数据循环顺序：DISPC_DATA1_CYCLE1 = 0x8,DISPC_DATA1_CYCLE2 = 0x8。这里的0x8是一个关键值，它指示DSS在每个周期输出数据的哪个字节。0x8通常对应数据总线的高8位（D[15:8]），0x0对应低8位（D[7:0]）。设置两个周期都为0x8，意味着DSS会在第一个周期将16位数据的D[15:8]放到8位数据线上输出，第二个周期再将D[7:0]放到同8位数据线上输出。这里需要特别注意：你必须根据你内存中YUV422数据的实际字节序（Endianness）和打包顺序，来调整DISPC_DATA1_CYCLEx的配置，以确保输出的字节顺序符合接收端（解串器或显示屏）的预期。这是一个常见的调试坑点。

通过TDM，DSS的物理8位数据接口在时序上“变宽”了，成功输出了16位/像素的YUV422流，同时伴随着标准的HSYNC、VSYNC和DE离散同步信号。

4. 系统级迁移：从RGB888 SRV到YUV422 SRV的完整链路

理解了核心机制后，我们需要将其融入一个真实的SRV应用场景。假设原系统是一个标准的RGB888输出SRV，其数据流通常是：DSP算法生成YUV422的泊车辅助线 -> GPU渲染生成RGB888的3D环视拼接图 -> CPU（如A15）生成RGB888的UI界面（如菜单、图标） -> 三者在DSS的叠加管理器（Overlay Manager）中混合 -> 最终以RGB888 24位格式输出。

要迁移到YUV422输出，数据流需要增加一个“格式转换与回注”的环节。因为叠加混合后的最终帧是RGB888格式，而我们的VID1通道期望的是YUV422（伪装成RGB565）输入。

4.1 VISION SDK环境下的实现

在TI的VISION SDK（通常用于裸机或RTOS环境）中，显示链路是通过M4核心上的显示控制器任务来管理的。迁移相对直接：

1. 重构显示链路：在原RGB888显示链路之后，增加一个回写捕获链路。具体来说，就是将原本直接输出到LCD的链路，改为先输出到DSS的回写（Writeback）模块。
2. 格式转换：配置回写模块的CSC，将RGB888转换为YUV422，并写入一块新的内存缓冲区。
3. 调度与回注：编写一个应用任务，负责调度这块新的YUV422缓冲区。将该缓冲区作为新的视频帧，提交给我们已经配置好的VID1 Pipeline（即那个伪装成RGB565、启用TDM的通道）。
4. 输出：VID1 Pipeline将YUV422数据通过TDM模式，以离散同步方式输出。

在VISION SDK的链路图工具中，这表现为在原有的Display链后面，串联了一个Capture_dsswb（回写捕获）节点，然后连接到一个新的Display_YUV422节点。整个流程在M4的显示驱动框架内可以比较流畅地完成配置。

4.2 PSDKLA (Linux) 环境下的实现

在基于Linux的PSDKLA环境中，事情变得更具挑战性，因为显示系统由DRM/KMS框架管理。我们不能直接“劫持”硬件流水线，必须遵循DRM的架构。

1. 创建虚拟显示平面：由于最终的YUV422输出需要独占一个VID Pipeline（如VID1），而原来的RGB888输出可能已经占用了其他Pipeline（如VID2, VID3, GFX）。我们需要创建一个虚拟的CRTC/Encoder/Connector（例如图9中的CRTC34）。将DSP的YUV422图层、GPU的RGB888图层、GUI的RGB888图层都绑定到这个虚拟CRTC对应的各个Plane上。这个虚拟CRTC负责完成图层叠加，但其输出不连接到任何物理端口。
2. 启用回写设备：将虚拟CRTC的输出连接到DSS的硬件回写（Writeback）设备。在Linux中，这会暴露为一个V4L2捕获设备，例如/dev/video11。
3. 用户空间转换与回注：
   • 编写一个Linux用户空间服务程序，使用V4L2 API从/dev/video11捕获帧。
   • 在程序中，可以配置V4L2捕获格式为YUV422，或者捕获RGB888后再用软件转换为YUV422（前者效率更高，如果硬件支持）。
   • 将得到的YUV422帧缓冲区，通过DRM的API（如libdrm）提交给代表物理输出端口（如VOUT1）的真实CRTC（如图9中的CRTC38）及其对应的Plane（如Plane37，绑定VID1 Pipeline）。
4. 物理输出配置：这个真实的CRTC（CRTC38）及其Encoder/Connector，需要按照3.1和3.2节的描述进行配置，即VID1 Pipeline配置为RGB565格式（用于透传YUV422）并启用TDM 8位输出。

这种方式相当于在Linux的DRM框架内，构建了一个“内部环出”的路径：虚拟混合 -> 回写捕获 -> 用户空间程序 -> 物理输出。虽然比VISION SDK方案复杂，但完全符合Linux驱动模型，更具通用性和可维护性。

4.3 时钟计算与时序配置

一个具体的例子：输出1280x720@30fps的YUV422视频。

• 像素时钟（PCLK）计算：1280 * 720 * 30 * 2 = 55.296 MHz。
  • 这里乘以2是因为TDM模式下，每个像素需要2个时钟周期。
• 时序配置：需要根据显示屏或接收芯片的数据手册，计算并配置HSYNC、VSYNC、DE信号的前廊（HFP/VFP）、同步脉宽（HSW/VSW）和后廊（HBP/VBP）参数。这些参数通过DSS的DISPC_TIMING_H和DISPC_TIMING_V等寄存器组进行设置。务必注意：这些时序参数是基于像素时钟周期的，在TDM模式下，一个“像素周期”对应两个PCLK周期，但时序参数的计算通常基于“像素时间”概念，即输出一个完整像素所需的时间（2个PCLK周期）。在配置时，需要确保HSYNC等信号的时钟计数值与接收端期望的像素时间对齐，而不是简单的PCLK数。

5. 调试、验证与常见问题排查

实现方案后，验证是关键。这里分享几种验证方法和踩过的坑。

5.1 验证方法

1. 内部环回测试（推荐首选）：将DSS的输出引脚（PCLK, DATA[7:0], HSYNC/DE, VSYNC）连接到同一芯片的VIP（视频输入端口）。在VIP端配置捕获YUV422格式。如果配置正确，VIP应该能捕获到完整、稳定的图像。这种方法无需外部硬件，便于早期调试。建议在此模式下使用DE信号而非HSYNC，因为VIP对DE模式的支持通常更稳定。
2. 外部显示屏测试：连接至支持YUV422输入的LCD屏或使用FPD-Link III解串器（如UB934）+评估板。这是最终的集成测试。在此模式下，通常需要使用HSYNC信号，因为大多数显示屏需要明确的HBlank时序（HFP/HSW/HBP）来控制行扫描。

5.2 常见问题与排查技巧

以下是我在实际项目中遇到的一些典型问题及解决思路，整理成了速查表：

5.3 实操心得与注意事项

• 寄存器配置顺序很重要：在初始化DSS或动态切换模式时，建议遵循“先关闭后配置再开启”的原则。例如，先停止VID Pipeline，再配置FORMAT、TDM、时序等所有参数，最后再使能Pipeline。避免在运行中更改某些关键寄存器导致不可预知的行为。
• 善用芯片勘误表：TI的芯片通常有勘误表（Errata Sheet），其中会列出DSS模块的一些已知硬件问题或限制。在调试诡异问题时，务必查阅。例如，某些芯片型号在特定TDM模式下，DATA线的输出顺序可能有特殊要求。
• 从简单测试开始：不要一开始就上复杂的SRV应用。先写一个最简单的测试程序，输出静态的、色彩简单的YUV422测试图案（如彩条），验证整个硬件通路。通了这个，再接入真实的视频流。
• 性能考量：在PSDKLA方案中，用户空间的格式转换和帧搬运会带来一定的CPU开销。对于高分辨率（如1080p）或高帧率（如60fps）应用，需要评估性能是否满足要求。可以考虑使用硬件加速的色彩转换（如果DSS回写模块支持）或使用零拷贝技术减少内存搬运。
• 信号完整性：当PCLK达到55MHz以上时，PCB布线的信号完整性变得重要。确保时钟和数据线走线等长，做好阻抗控制和端接，避免因信号质量问题导致显示异常。

实现基于TI Jacinto/TDA平台的离散同步YUV422输出，是一个对硬件特性和系统架构理解要求比较高的任务。它没有现成的开关，需要你巧妙地组合使用旁路、TDM、回写这些基础功能。整个过程就像在既定的硬件电路上“编程”，找出那条隐藏的数据通路。一旦调通，带来的系统简化与成本收益是非常显著的。这个方案的成功实施，为我们后续在多个车载项目中选择更灵活的显示接口方案奠定了坚实的技术基础。