企业官网建设流程全解析

简介：本资源是一套面向嵌入式Linux驱动开发工程师与视觉系统集成者的TC358743 HDMI转MIPI CSI-2桥接芯片I2C主控驱动实现方案，聚焦于高可靠寄存器配置、视频流同步机制构建及低功耗模式初始化等核心难点。资源包共7个文件（22KB），含核心驱动源码tc358743.c、寄存器定义头文件tc358743.h与tc358743_regs.h、关键配置说明txt文档及备份文件，结构精炼，便于快速集成到Yocto/Buildroot等嵌入式构建体系中。已有93人学习下载，适用于1080p车载影像采集、工业相机模组移植等实际项目场景。读者可直接复用I2C通信框架、帧同步时序配置逻辑与音频提取使能流程，并参考README中的典型寄存器写入序列与静电防护布线提示，显著降低硬件适配调试周期。 做嵌入式视觉这几年，我经常被问到同一个问题：手头有个HDMI信号源，想把画面送进只带MIPI CSI-2接口的主控，怎么接？如果只是把引脚连起来，得到的只会是一堆信号错误和永远黑屏的驱动日志。答案其实不复杂——在中间加一颗HDMI转MIPI CSI-2桥接芯片，比如TC358743，然后通过I2C主控驱动把它的寄存器配好，让HDMI接收端和CSI-2发送端都工作在正确状态。这篇文章就从实际项目角度，把TC358743的I2C通信链路、寄存器初始化、驱动实现和调试经验完整梳理一遍，适合正在调板子、写驱动或者准备选型的人参考。

我要先说清楚一个容易被忽略的事：TC358743不是一颗“万能转换器”，它是一颗需要被主控“管理”的复杂从设备。芯片本身不主动做任何事，所有输入输出行为都依赖I2C寄存器配置。你把它焊到板子上，上电，信号不会自己通。只有I2C主控驱动把系统控制、HDMI接收、EDID、CSI-2发送这几个模块全部配置正确，画面才可能从HDMI口流到CSI-2口。所以整个项目的核心，其实就是写好这颗芯片的“管理逻辑”。

1. 为什么需要TC358743这类桥接芯片：HDMI与MIPI CSI-2之间的天然鸿沟

1.1 两类接口的协议差异，不是简单“焊线”就能解决的

HDMI和MIPI CSI-2都是高速串行接口，但它们的底层协议几乎完全不同。HDMI使用TMDS差分信号传输音视频，物理上包含4对差分数据线、1对差分时钟线，还带一条独立的DDC通道（本质是I2C总线，用于读取显示器的EDID）和热插拔检测引脚。MIPI CSI-2则是摄像头专用接口，物理上使用D-PHY差分信号，以“数据通道+时钟通道”的方式传输，每个通道单独传输，方向是单向从摄像头到主控。

从协议栈上看，HDMI传递的是“视频流+音频流+辅助数据”，CSI-2传递的是“图像数据包（帧起始、行有效、像素数据、帧结束）”。两者之间没有一个引脚能直接对上的。即便你把HDMI的TMDS差分对强行接到CSI-2的差分对，主控的CSI控制器也完全无法解析HDMI的信号结构，因为TMDS编码、通道拓扑、包格式统统不一样。

所以必须有一颗桥接芯片完成“协议翻译”。TC358743内部做了三件事：接收HDMI的TMDS信号并解码成并行视频数据；把视频数据做色彩空间转换、裁剪、缩放（部分型号支持）后重新打包成MIPI CSI-2协议格式；最后通过D-PHY发送给主控SoC的CSI控制器。主控侧看到的就是一颗“标准MIPI CSI-2摄像头传感器”。

1.2 TC358743在系统中的位置与典型应用场景

TC358743（Toshiba/Kioxia出品）是这类方案里非常典型的一颗芯片。它的输入是HDMI，输出是MIPI CSI-2，支持1/2/4 lane的D-PHY配置，最大分辨率一般能做到1080p60左右，部分配置下支持更高时序。它的控制接口就是I2C从接口，主控通过I2C读写它内部几百个寄存器，完成整个初始化过程。

我在实际项目中用的最多的地方是这几种：树莓派计算模块做HDMI采集卡、瑞芯微平台接HDMI内窥镜/工业相机、全志平台做视频输入预处理。所有这些场景都有一个共同点：主控SoC没有HDMI输入控制器，但CSI-2接口是现成的。加一颗TC358743，硬件成本不高，驱动调试难度主要集中I2C配置和CSI时序匹配上。

芯片在系统里的连接方式很清晰：HDMI连接器进来，经过TC358743，输出几对MIPI差分线接到SoC的CSI输入；另外一条I2C总线从SoC连到TC358743的SCL/SDA，用于配置寄存器。这颗芯片的“角色”是一个I2C从设备，地址可以通过引脚配置成多种值，默认地址是0x0f（7位地址）。后面我会详细说硬件和地址的问题。

2. I2C总线搭建与设备识别：动手配置前先确认链路是通的

2.1 引脚连接、电平匹配与上拉电阻选择

很多人在TC358743上栽的第一个跟头，不是驱动代码，而是I2C物理链路压根不通。TC358743的I2C引脚SCL和SDA是开漏结构，需要外部上拉电阻。这个上拉电阻的电源域必须和芯片的I/O电源一致。TC358743的I2C接口通常在1.8V或3.3V电源域工作，具体看数据手册中的VDDIO引脚接法。如果主控I2C是3.3V，而TC358743的I2C电源域是1.8V，就需要加电平转换，比如TXS0102或分立MOSFET电路。我之前遇到过一块板子，芯片画在1.8V域，主控直接拉3.3V I2C过去，上拉电阻也接了3.3V，结果I2C读出来的数据全都是0xff，排查了半天才发现是电平不匹配把芯片I2C脚灌穿了。

上拉电阻的阻值选择也不能拍脑袋。I2C标准模式下上拉电阻典型值4.7kΩ到10kΩ，400kHz快速模式下建议用2.2kΩ到4.7kΩ。阻值太大，上升沿太慢，高速通信容易出错；阻值太小，拉低时电流过大。PCB走线如果比较长，还需要考虑总线电容，总线上挂的设备越多，上拉电阻就要适当减小。我一般先用10kΩ跑100kHz确认链路，再改成4.7kΩ跑400kHz。

另外要检查I2C总线上是否已经挂了其他设备，地址冲突要提前避免。TC358743的I2C地址不是固定死的，它通常有地址选择引脚（如I2C_AD0/AD1，具体要看封装和手册），可以配置成多个地址。默认7位地址0x0f，对应8位写地址0x1E、读地址0x1F。如果你板子上已经有一颗设备占了0x0f，就得通过引脚把它改到其他地址。

2.2 用i2cdetect确认芯片在线，把链路问题一次暴露出来

硬件连接完，先不要急着写寄存器配置，直接做一次设备扫描，确认I2C链路是通的。Linux下最方便的工具是i2c-tools，用i2cdetect扫描总线：

i2cdetect -y 0

如果TC358743在线，应该能在0x0f位置看到0f。如果扫描不到，按照下面的顺序排查：

• 供电：确认VDD、VDDIO、PLL电源都正确，用万用表实测芯片引脚电压。
• 复位：确认/RESET引脚不是一直被拉低，正常工作时应该为高电平。
• 上拉：用示波器或逻辑分析仪看SCL/SDA波形，确认空闲时是高电平。
• 地址：确认地址选择引脚的电平，和手册里的地址表对应。
• 引脚定义：确认SCL/SDA没有接反。

这里有一个常见误操作：很多人对着芯片封装图，把SCL和SDA看成一样的，结果飞线接反了。如果i2cdetect完全无输出，优先怀疑这个问题。

扫描到地址后，用i2cdetect的快速读验证一下：

i2cdetect -y -r 0

如果显示0f，说明读链路也通。此时I2C主控驱动开发就可以正式开始了。

2.3 复位、中断和参考时钟：三个容易被忽略的“隐形”引脚

TC358743除了I2C引脚，还有几个引脚对驱动行为影响很大。第一个是复位引脚。芯片上电后必须给一个可靠的低电平复位脉冲，一般要求至少几百微秒，然后释放到高电平，芯片内部才能完成初始化和时钟锁定。如果复位时序不满足，I2C可能能访问，但HDMI接收端状态异常，后面怎么配都不出图。

第二个是中断引脚INT。这个引脚可以配置成输出，当HDMI热插拔检测、HDMI信号失锁、CSI-2错误等事件发生时，Int脚拉低（或拉高）通知主控。Linux内核驱动里，中断引脚通常注册为GPIO中断，用来触发HDMI输入事件的检测。如果只是想验证寄存器配置，不接INT脚也可以，但做产品级驱动时建议接上，轮询事件远不如中断可靠。

第三个是参考时钟RefClk。TC358743需要一颗外部参考时钟，常见值是24MHz或27MHz，必须是低抖动时钟源。它和芯片内部的PLL配合生成HDMI接收端像素时钟以及CSI-2参考时钟。如果参考时钟频率不对或抖动过大，HDMI接收端会锁不住信号，CSI-2输出也会不停报错。我在调试时用示波器专门抓过RefClk，发现晶振起振时间有问题，导致开机后前几百毫秒芯片没工作。后来换成有源晶振并加长复位时间，问题就消失了。这三个“隐形”引脚如果都正常，I2C注册配置才算有一个稳定基础。

3. 16位寄存器地址的配置链：从系统控制到CSI-2发送

3.1 先搞懂TC358743的寄存器访问方式，避免一上来就踩坑

TC358743的寄存器地址是16位的，不是普通I2C芯片那种8位寄存器地址。这意味着每次访问，I2C主控要先发送“寄存器地址高字节”和“寄存器地址低字节”，然后再发送数据。很多只写过8位寄存器的人第一次接触这颗芯片，会用i2cset硬写，结果发现写进去的寄存器完全不对，或者读回来的数据全乱。

正确的写寄存器序列是：

START -> 0x1E（写地址） -> reg_addr[15:8] -> reg_addr[7:0] -> data[15:8] -> data[7:0] -> STOP

TC358743不少寄存器的数据宽度是16位，但也有一些是8位，具体要看手册中的寄存器说明。写的时候如果只写8位数据，寄存器高位可能保持默认值，导致整个配置不对。为了统一，我通常自己封装一个支持16位寄存器地址、16位数据的读写函数，遇到8位寄存器时高位填0并单独确认数据位。

使用Linux用户态工具时，普通的i2cget/i2cset因为默认只处理8位寄存器地址，用起来很别扭。推荐用i2ctransfer：

# 读寄存器0x0000 i2ctransfer -y 0 w3@0x0f 0x00 0x00 0x00 r2 # 写寄存器0x0000为0x0001 i2ctransfer -y 0 w4@0x0f 0x00 0x00 0x00 0x01

w3表示发送3个字节，r2表示读2个字节，@0x0f指定7位I2C地址。这个命令是调试TC358743最顺手的工具，建议收藏。

3.2 初始化流程：先系统复位，再配置HDMI接收端，最后让EDID生效

TC358743的寄存器数量很多，但初始化步骤是有固定逻辑的，基本遵循“系统控制 -> HDMI接收 -> EDID -> CSI-2发送”的顺序。我一般按照下面这个流程来配：

第一步是系统控制。芯片上电后，先通过SYSCTL（系统控制）寄存器做软复位，等待复位完成。这一步是为了确保芯片处于已知状态。不同版本的数据手册对软复位寄存器位定义可能不同，但通常是在系统控制寄存器写入复位位，然后再写0清掉。复位后，需要等待至少几毫秒，可以通过读回状态寄存器确认。

第二步是配置系统时钟。TC358743内部有PLL，需要根据参考时钟频率配置相应的分频和倍频寄存器。这一步如果配错，后面HDMI和CSI-2全部异常。我的经验是先把参考时钟频率确认清楚，再对照手册中的PLL配置表填值。不要自己想当然去改分频系数，除非你完全理解了PLL的环路结构。

第三步是HDMI接收端配置。包括使能HDMI接收功能、配置输入信号检测、设置HDMI音频/视频相关的控制位。这些寄存器一般在HDMI控制块中。TC358743会在HDMI输入端检测TMDS时钟和数据，锁定后产生中断事件。驱动可以通过中断或轮询确认输入信号是否有效。

第四步是EDID配置。这步很关键，很多黑屏问题都出在它身上。HDMI源设备（比如电脑、机顶盒）上电后会通过DDC通道读取显示端的EDID，如果读不到或者读到错误数据，源设备可能不输出HDMI信号。TC358743内部有EDID RAM，主控需要把EDID数据通过I2C写入芯片，芯片再在DDC通道上响应HDMI源的读取。驱动里一般会准备一份标准的1080p60 EDID数据，写入到EDID RAM中，然后设置HPD（热插拔检测）引脚为有效状态，告诉HDMI源“这边已经有显示器准备好了”。

EDID写入完成后，HDMI源应该开始输出信号。此时可以查TC358743的中断状态寄存器，看有没有检测到HDMI信号锁定。

3.3 CSI-2发送端配置：通道数、虚拟通道、数据类型和时钟计算

HDMI接收端就绪后，就要配置CSI-2发送端了。这一步决定主控的CSI控制器能收到什么格式的图像数据。需要配置的参数主要有下面几个。

第一，数据通道数。TC358743可以输出1/2/4 lane，具体取决于PCB设计时走了几对差分线，以及主控CSI控制器支持几lane。lane数配置错了，主控侧解出来的数据完全错乱，最常见的就是花屏或者只能看到半幅画面。

第二，虚拟通道ID。CSI-2协议里，数据包可以带虚拟通道号，方便多个传感器共享同一总线。一般设成虚拟通道0，主控侧对应v4l2-subdev的pad配置也要一致。

第三，数据类型。TC358743可以把HDMI输入的RGB/YUV信号打包成CSI-2的多种数据类型，常见的是RGB888（0x24）和YUV422-8bit（0x1E）。主控CSI控制器必须配置成相同的数据类型，否则无法正确解析。我在树莓派平台用的比较多的是RGB888，但在带宽有限的场景下会选择YUV422。

第四，CSI-2时钟和像素时钟的关系。这是整个配置里最容易出问题的地方。CSI-2发送端需要产生一个与图像数据量匹配的传输时钟，它的频率必须足够大，能在帧周期内把所有图像数据传完。简单来说，byte clock至少等于：

byte_clock = pixel_clock × bits_per_pixel / (8 × lane_count)

比如1080p60的像素时钟是148.5MHz，RGB888每像素24bit，4 lane传输，那么byte_clock = 148.5 × 24 / (8 × 4) = 111.375MHz。实际配置时还要留余量，所以TC358743的PLL配置会根据目标CSI-2时钟来计算分频倍频系数。如果在调试中发现数据断流或者图像有撕裂感，优先检查这个时钟是否配够。

通常TC358743驱动里会有一套根据当前视频时序自动计算CSI-2配置的逻辑，不需要手动算。但如果你是在没有现成驱动的平台上移植，就必须自己实现这套计算逻辑。我建议先固定一个分辨率（比如720p60）调通，再扩展自适应。

3.4 一份可参考的初始化序列示例

下面是我在一个项目里用过的简化初始化序列，寄存器名和值不完全代表所有版本，但流程可以对照。实际应用时一定要参考你拿到的那颗芯片对应版本的数据手册。

这里我特别强调一下写入EDID的过程。EDID不是随便填的，它是一份128字节的标准结构，包含厂商信息、分辨率列表、像素时钟等。TC358743的EDID RAM可以通过特殊寄存器窗口访问，主控写完后还要设置“EDID有效”标志位。如果你用现成Linux内核驱动，驱动内部已经内置了一份默认EDID，但如果是自己写驱动，需要手工构造或从论坛/参考设计中提取。最简单的办法是先用128字节标准edid数据，分辨率设成源端最常输出的格式，比如1920x1080@60。

4. 主控侧驱动实现：用户态命令和内核V4L2两种路线

4.1 用户态i2c-dev驱动：最快验证寄存器配置的捷径

调试阶段我强烈建议先在Linux用户态用i2c-dev把整个初始化流程跑通。好处是编译快、改参数方便、不需要反复烧内核。操作流程很简单：打开/dev/i2c-N，用ioctl设置从机地址，然后通过write/read完成寄存器读写。

下面是一个最小可用的C语言读写函数：

#include <stdio.h> #include <stdlib.h> #include <fcntl.h> #include <unistd.h> #include <sys/ioctl.h> #include <linux/i2c-dev.h> #include <linux/i2c.h> int i2c_open(const char *bus, int addr) { int fd = open(bus, O_RDWR); if (fd < 0) { perror("open"); return -1; } if (ioctl(fd, I2C_SLAVE_FORCE, addr) < 0) { perror("ioctl I2C_SLAVE_FORCE"); close(fd); return -1; } return fd; } int i2c_write_reg(int fd, unsigned short reg, unsigned short val) { unsigned char buf[4]; buf[0] = (reg >> 8) & 0xff; buf[1] = reg & 0xff; buf[2] = (val >> 8) & 0xff; buf[3] = val & 0xff; if (write(fd, buf, 4) != 4) { perror("write"); return -1; } return 0; } int i2c_read_reg(int fd, unsigned short reg, unsigned short *val) { unsigned char reg_buf[2]; unsigned char data_buf[2]; reg_buf[0] = (reg >> 8) & 0xff; reg_buf[1] = reg & 0xff; if (write(fd, reg_buf, 2) != 2) { perror("write reg"); return -1; } if (read(fd, data_buf, 2) != 2) { perror("read"); return -1; } *val = (data_buf[0] << 8) | data_buf[1]; return 0; }

注意这里面用了I2C_SLAVE_FORCE而不是I2C_SLAVE，因为有些内核版本会在/dev/i2c-N上检查设备是否已经被驱动占用。调试期用FORCE可以跳过检查，但产品驱动不应该长期这样用。

还有一种更快的验证方式是用Python加上smbus2库，在交互式环境里快速读写寄存器，特别适合看配置序列逐条执行的效果。对纯寄存器调试来说，Python脚本比编译C更灵活。

4.2 内核V4L2子设备驱动路线：让系统真正“认识”这颗芯片

用户态验证通过后，下一步就应该移植到内核驱动里，用V4L2框架管理TC358743。Linux mainline里已经有tc358743.c驱动，位置在drivers/media/i2c/tc358743.c。如果你的内核版本较老，直接拉最新内核的该文件回来移植即可，工作量不大。

这个驱动注册为I2C子设备，同时挂到media controller框架下，作为V4L2 subdev。它实现了s_dv_timings、get_dv_timings、set_rx、set_frame_interval等接口，上层可以通过media-ctl或v4l2-ctl控制。驱动内部会在s_stream(1)时执行完整的寄存器初始化序列，包括配置EDID等。使用mainline驱动的好处是无需自己处理PLL、lane数、数据类型等细节，它已经根据v4l2_subdev的format配置自动计算。

内核驱动下配置TC358743的典型流程是：

# 查看media拓扑 media-ctl -p # 设置TC358743输出格式，比如1920x1080 RGB888 media-ctl -V "\"tc358743 0-000f\":0[fmt:RGB888_1X24/1920x1080]" # 设置接收端CSI接口格式 media-ctl -V "\"csi2\":0[fmt:RGB888_1X24/1920x1080]" # 打开视频流 v4l2-ctl --stream-mmap --stream-count=1

这里有一个很容易踩的坑：media-ctl设置格式时，TC358743子设备的pad格式必须和CSI接收控制器的pad格式保持一致，包括分辨率、像素格式、field、colorspace。只要有一项不一致，流就无法建立，或者建立后采集到的全是绿屏/花屏。我遇到过好几次，反复检查驱动没有问题，最后发现是media-ctl命令里的格式字符串和实际驱动枚举出来的格式名字差了一个大小写。

4.3 自己的驱动写在哪一层？

如果你用的芯片版本比较老，或者厂家没有提供mainline驱动，也可以自己写一个简单的I2C驱动。不要一上来就写完整V4L2驱动，可以先写一个misc设备驱动，暴露ioctl给用户态，让用户态来触发寄存器初始化。这样做的好处是驱动代码量小，调试方便，等寄存器配置稳定后再迁移到V4L2子设备里。

自己写内核驱动时，I2C读写用i2c_transfer结构体或者regmap都可以。TC358743寄存器是16位地址，用regmap的话需要设置regmap配置中的reg_bits = 16和val_bits = 16，然后很多寄存器操作就自动统一了。不过要注意有些寄存器是只读的，写入会出错，regmap默认不做只读保护，需要在read_only_regs回调里明确指出哪些寄存器不能写。

内核中断处理方面，TC358743的INT引脚可以接到SoC的一个GPIO，注册为devm_request_threaded_irq。中断触发后，在中断线程里读取芯片的中断状态寄存器，判断是什么事件，然后清除对应位，再向上层上报事件。很多新手会漏掉“清除中断位”这一步，结果中断持续触发，系统卡死。所有中断驱动型芯片都是这个套路，TC358743也不例外。

5. 踩坑记录：从黑屏到稳定出图的关键细节

5.1 常见症状与根因对照表

我总结了TC358743调试中最高频的几个症状和根因：

这里的排查顺序非常重要：先确认硬件，再确认I2C，再确认HDMI源，最后才怀疑CSI-2配置。我见过太多人一上来就改CSI-2寄存器，结果问题其实是EDID根本没写进去。

5.2 用逻辑分析仪和i2ctransfer把问题“看”出来

如果你手边有逻辑分析仪，调试TC358743效率会高很多。I2C只有两根线，逻辑分析仪抓波形非常轻松。抓一次启动时的I2C通信，能看清楚几个关键点：总线上有没有ACK；寄存器地址是不是16位；写入的数据宽度对不对。有一次我发现芯片在一些寄存器地址上返回NAK，查手册才知道这些寄存器在低功耗模式下不可访问，需要先通过别的寄存器唤醒。这种问题纯看代码很难发现，波形一抓就明白。

另一个非常实用的工具是i2ctransfer的回读验证。写完一个寄存器后，立刻用i2ctransfer读回来，确认芯片内部实际写进去的值。如果读回的值和写的不一致，优先怀疑寄存器地址写错、芯片处于保护模式、或者总线速度太高导致数据错误。

# 写0x0000寄存器为0x0001 i2ctransfer -y 0 w4@0x0f 0x00 0x00 0x00 0x01 # 读回0x0000寄存器 i2ctransfer -y 0 w3@0x0f 0x00 0x00 0x00 r2

如果你的I2C总线上挂了不止一个设备，i2ctransfer输出可能会和其他设备的调试数据混在一起，建议调试时先拔掉不必要的设备，或者在硬件上做跳线隔离。

5.3 稳定性经验：最后会仔细检查的几个细节

调通第一帧图之后，很多项目会继续踩一些“偶发黑屏”“长时间运行后断流”的坑。这些稳定性问题往往不是寄存器配置本身，而是外围细节。

电源纹波是最容易被忽略的。TC358743的HDMI接收端和CSI-2发送端都是高速电路，对电源噪声敏感。如果板子上用了小容量LDO且布局离芯片太远，负载变化时纹波可能到几十毫伏甚至上百毫伏，导致芯片内部PLL失锁。解决方式是保证每个电源引脚都有足够的去耦电容，通常推荐0.1uF瓷片电容就近放置，并配合4.7uF或10uF的大电容。我调试过一块软排线连接的板子，电源走线过长，后来在靠近芯片的位置补了一颗10uF电容，断流问题就消失了。

第二个容易出问题的是参考时钟的精度。TC358743的RefClk如果偏离标称值很多，HDMI接收端的像素时钟也会跟着偏，最终导致图像颜色异常或行场不同步。在项目量产阶段，不要用廉价的陶瓷谐振器，建议用有源晶振，精度至少±50ppm。

第三个是系统级时钟域的匹配。主控CSI控制器的时钟源和TC358743的参考时钟如果是两套独立时钟，即便初始频率标称一致，长期运行也可能因为温度漂移而出现偶发丢帧。这种情况下可以在驱动里做CSI-2错误恢复机制：检测到错误就重新初始化TC358743。不过这种方案是治标，治本还是要从硬件时钟设计上解决。

第四个是I2C总线复用问题。主控的I2C控制器可能同时接了TC358743、触摸屏、电源管理芯片等多个设备。TC358743初始化过程中有大量连续写操作，如果总线被其他设备占用，初始化时间会拉长。更麻烦的是某些SoC在某个采样窗口内会对I2C总线做动态电源门控，导致TC358743的寄存器写到一半就丢失。这类问题通常表现为“有时能出图，有时不能出图”。解决方法是把TC358743挂到一个独立的I2C总线上，如果硬件不支持，至少保证I2C总线时钟在初始化期间不能被关闭。

最后还有一个非常容易被忽略的点：HDMI源设备的热插拔行为。TC358743的HPD机制需要正确响应热插拔事件。在软件里，如果只是上电时做一次HPD，拔线重插后不会自动重新协商。要做完整的驱动，需要监听TC358743的HPD中断，在检测到拔出时停止CSI-2流，检测到插入时重新写EDID并恢复流。如果不做这个处理，很多演示程序第一次运行是好的，一旦HDMI线拔插一次就再也无法恢复。

如果让我给刚接手这颗芯片的人一条最省时间的心得，我会说：先别急着写完整驱动，用i2c-dev把EDID写进去、确认HDMI源有输出，再用i2ctransfer一步步配CSI-2，这一步做扎实了，后面的kern el驱动移植只是体力活。TC358743本身并不复杂，复杂的是它周围那一圈“看起来不重要”的电源、时钟、复位和EDID细节，把这些抠干净，出图就是水到渠成的事。

本文还有配套的精品资源，点击获取