s3c6410与TVP5150视频采集驱动移植：从I2C调试到DMA丢帧的完整排错指南

简介：基于s3c6410平台与WinCE6.0环境的TVP5150驱动源代码，面向嵌入式BSP开发工程师与视频采集驱动学习者，可有效解决模拟视频（AVIN）输入驱动的移植、编译与调试问题。整个rar压缩包内共7个文件，包括驱动头文件、C++实现源码、makefile构建脚本、sources配置及宏定义文件等，整体仅17KB，结构精简，便于直接阅读、编译集成或按项目裁剪移植。驱动内部可直接修改TVP5150寄存器，对图像饱和度、色度、对比度和亮度进行灵活调节，同时支持设定图像输出尺寸，以及将彩色图像转为灰度图像等常用功能；代码还能适配友坚AVIN模块，缩短外设接入的二次开发周期。目前已有244人学习下载，非常适合具备WinCE6.0基础、需要在s3c6410上快速实现视频输入或参考TVP5150寄存器配置的工程师使用，是一份轻量且实用的驱动参考源码。 去年秋天接了个老项目的维护活儿，客户把一批当年用 s3c6410 做的板卡又翻了出来，要求接入模拟摄像头做视频采集，解码芯片用的是德州仪器的 tvp5150。这活儿本身不算新，但麻烦就麻烦在：这套组合的驱动源代码在网上磨了三天也没找到一份能直接编译的，BSP 里自带的 camera 驱动和 tvp5150 驱动又各自为政，拼起来各种对不上。这篇文章就是我把整套驱动重新梳理、移植、调通之后的一次完整记录，适合正在做 s3c6410 视频采集、或者在其它 ARM 平台上移植 tvp5150 驱动源代码的工程师参考。

1. 先别急着写代码，把视频信号链路走一遍

很多人在这种项目上栽跟头，不是因为代码难写，而是因为没搞明白模拟视频信号从进来那根线到内存里那帧数据，中间到底经过了哪些环节。s3c6410 和 tvp5150 这套组合，链路其实非常清晰，但我还是建议先把信号路径画出来再动键盘。

1.1 TVP5150 在这条链路里扮演什么角色

TVP5150 是德州仪器一款非常经典的模拟视频解码芯片，输入可以是 CVBS 复合视频，也可以是 S-Video 的 Y/C 分量，输出则是 8 位 YUV 4:2:2 格式的 BT.656 数字流。所谓 BT.656，就是数字视频流里把行场同步信息以 SAV/EAV 码的形式嵌入到数据流中，而不是像 BT.601 那样用独立的 VSYNC/HREF 引脚去传。这意味着数据线上除了像素时钟 PCLK 和 8 位数据线以外，不需要额外的同步线，硬件连接会干净很多。

芯片的控制接口是 I2C，默认从设备地址是 0xBA（8 位写地址），换算成 7 位地址就是 0x5D。这句话在后面调试时特别重要，因为 i2c_board_info 里填的是 7 位地址，而很多人习惯按 8 位地址去扫总线，结果自然是扫不到设备。

1.2 S3C6410 的 Camera 接口和 BT.656 的匹配度

S3C6410 内部自带一个 Camera Interface 控制器，支持 ITU-R BT.601/656 协议，8 位 YUV 4:2:2 输入，数据进来之后 DMA 直接把帧写入 DDR。设计上它本来就是为了接 CMOS 摄像头或者解码器输出的数字 YUV 流，所以和 TVP5150 的输出格式是天然匹配的，中间不需要加 FPGA、CPLD 或者额外的电平转换芯片。

典型接线关系大概是这样的：

这里有一个容易踩的点：TVP5150 需要外部参考时钟，绝大多数参考电路用的是 27MHz 晶振。有人想从 s3c6410 的 CAM_MCLK 输出直接引过去，但这个时钟是给 CMOS 传感器用的，频率是否配得出 27MHz 要看具体 BSP 的时钟树，我建议直接外挂无源晶振或者有源晶振，省得在时钟分频上浪费时间。

2. 驱动源代码的骨架：v4l2_subdev 和 Platform Camera 接口如何分层

把硬件链路搞清楚之后，再看软件框架就会顺很多。Linux 下这类视频采集驱动内核里管得非常明白：一条链路分成三块，用户空间的 /dev/videoX 由 camera host driver 提供，tvp5150 作为一个 I2C 从设备，以 v4l2_subdev 身份挂载，host 和 subdev 之间通过 V4L2 框架完成格式协商和控制信令的传递。

2.1 老 BSP 和新内核的框架分歧点

s3c6410 最活跃的年代，Linux 内核还停留在 2.6.28、2.6.35 左右，那时候三星官方 BSP 里的 camera 驱动多数走的是一套私有接口，类似 v4l2-int-device 或者 soc_camera 框架。如果你现在拿着那个年代的驱动源代码直接往新内核上编译，大概率会碰到接口已经面目全非的问题。

如果你手头的内核是 3.x 以上，我强烈建议直接走标准 v4l2_subdev + platform_driver 的路线，不要再去适配那套老接口。我在移植时选的就是这条路径，整个驱动源代码结构清晰，调试起来也方便。

2.2 TVP5150 侧的 subdev 注册骨架

TVP5150 驱动的核心，说到底就是三件事：I2C probe 出芯片、注册 v4l2_subdev 操作集、在 s_stream 时把寄存器配好。代码骨架大致是这样：

static const struct v4l2_subdev_ops tvp5150_ops = { .core = &tvp5150_core_ops, .video = &tvp5150_video_ops, .pad = &tvp5150_pad_ops, }; static int tvp5150_probe(struct i2c_client *client) { struct v4l2_subdev *sd; sd = devm_kzalloc(&client->dev, sizeof(*sd), GFP_KERNEL); if (!sd) return -ENOMEM; v4l2_i2c_subdev_init(sd, client, &tvp5150_ops); tvp5150_reset(sd); return 0; } static const struct i2c_device_id tvp5150_id[] = { { "tvp5150", 0 }, { } }; MODULE_DEVICE_TABLE(i2c, tvp5150_id); static struct i2c_driver tvp5150_i2c_driver = { .driver = { .name = "tvp5150", }, .probe = tvp5150_probe, .id_table = tvp5150_id, }; module_i2c_driver(tvp5150_i2c_driver);

视频操作集里最核心的是 s_stream，一个 0 参数代表停止采集，1 参数代表启动采集。TVP5150 的寄存器初始化最好放在这里做，因为有人可能先把 video device open 了但不立刻采集，过早配置没有意义。

2.3 S3C6410 CAMIF 侧的 platform 驱动骨架

Camera host 这边的驱动，本质是一个 platform_driver，负责手机控制器的寄存器、时钟、DMA，并注册一个 video_device。s3c6410 没有设备树，所以设备注册都在板级代码里完成。

static struct platform_driver s3c_camif_driver = { .probe = s3c_camif_probe, .remove = s3c_camif_remove, .driver = { .name = "s3c-camif", }, }; module_platform_driver(s3c_camif_driver);

板级文件里要么用 platform_device_register_simple，要么在初始化数组里填好 resource，把 CAMIF 的寄存器基地址、中断号、时钟名称一次性传给驱动。很多人在这一步卡住，是因为不知道 CAMIF 的时钟名字在时钟驱动里不叫 camera，而叫 camif，或者是别的变体，导致 clk_get 失败，DMA 从未启动。

3. 初始化寄存器与格式协商：看起来简单，实际决定成败

TVP5150 的寄存器初始化，网上一搜能搜到一大堆初始化表，有的写了几十行。但我的经验是：TVP5150 出厂默认配置就能工作，真正需要改的寄存器非常少，初始化表越长，反而越容易因为某个位写错导致出各种奇奇怪怪的图像问题。

3.1 I2C 地址的 7 位 / 8 位陷阱

我在调试时先用 i2cdetect 扫描 I2C 总线，在地址 0x5D 处发现了一个设备，当时判断应该就是 TVP5150。但用 i2cset 直接读写时却始终失败，后来才反应过来，i2c-tools 的 i2cset 操作的是 8 位地址，而内核 i2c_board_info 填的是 7 位地址，两个体系经常把人绕晕。

在内核里注册 tvp5150 时，board_info 应该这么写：

static struct i2c_board_info __initdata xxx_i2c_devs[] = { { I2C_BOARD_INFO("tvp5150", 0x5d) }, }; i2c_register_board_info(1, xxx_i2c_devs, ARRAY_SIZE(xxx_i2c_devs));

注意这里第二个参数是 0x5d，不是 0xba。如果你拿到的 BSP 里写的是 0xba，要么那个驱动在寄存器读写时做了移位，要么你遇到的就是一个 8 位地址和 7 位地址混用的历史遗留 bug。

3.2 寄存器初始化策略，不是越多越好

TVP5150 的寄存器 0x00 控制输入源选择，默认是 CVBS 输入。如果你的摄像头接的是 AIP1A 口，低两位保持默认即可；如果是 AIP1B，才需要改这个寄存器的值。另外一个需要针对性设置的是制式：PAL 制式输出 720x576，NTSC 输出 720x480，如果摄像头是 PAL 而代码里写死 720x480，画面会滚动或者下半屏是花屏。

我建议的初始化流程是：

• 上电后先读回几个关键寄存器，确认 I2C 通信正常；
• 保持默认寄存器配置，先试采一帧；
• 根据采集到的图像现象，再针对性修改输入源寄存器和制式相关寄存器。

不要一上来就把网上那份几十行的初始化表整个灌进去，问题会变得很难定位，因为你不知道是哪一行配置引入的异常。

3.3 格式协商里最容易漏掉的对齐

TVP5150 输出的是 YUYV，即 V4L2_PIX_FMT_YUYV，每个像素两个字节，宽度方向必须保证 16 字节对齐，这也是很多摄像头 buffer 申请失败、DMA 写入异常的原因之一。在 s32c6410 的 CAMIF 驱动里，如果用户空间请求的分辨率宽度不是 4 的倍数，最好在 try_fmt 回调里做一次向上对齐，别把这个问题丢给 DMA 层。

4. 排错实战：从 i2cdetect 到 DMA 丢帧的完整排查链路

驱动第一次完整编译通过不代表链路就正常，接下来的调试才是大头。我把自己在这套组合上踩过的坑按排查顺序列出来，这个过程比最终解决方案本身更有价值。

4.1 I2C 扫不到设备，先把供电和复位管脚查一遍

如果 i2cdetect -y 1 里看不到 0x5D，首先要查的其实不是驱动代码，而是硬件。TVP5150 的 PWDN 引脚如果被拉高，芯片直接进入掉电模式，I2C 自然没有任何回应。很多评估板的原理图里 PWDN 是由 GPIO 控制复位的，板级初始化里必须先把对应 GPIO 拉到低电平。

其次检查参考时钟是否起振。用示波器点 TVP5150 的 XTI 引脚，如果没有 27MHz 波形，I2C 也是扫不到的，因为芯片内部完全没有时钟逻辑在跑。建议在板级代码里单独加一个初始化函数，上电后先延迟几十毫秒，再释放复位，这个时序问题容易被人忽略。

4.2 能出图但花屏、绿屏，多半是制式和极性没有对齐

我在第一次采到图时，画面全是绿色和灰色条纹，第一反应是寄存器配错了。后来发现 tvp5150 默认自动检测制式其实不太可靠，信号不好的时候经常误判。解决方法是显式地锁定制式：PAL 的摄像头就固定配置 PAL 相关寄存器，NTSC 就固定 NTSC。

另外注意 s3c6410 CAMIF 的 PCLK、VSYNC、HREF 极性配置。TVP5150 输出的像素时钟默认是上升沿有效数据，如果 BSP 板级配置里把 pclk 极性设成了下降沿，图像会产生明显的横纹和错位。这个参数在CAMIF 的板级 platform_data 结构体里：

struct s3c_platform_camera { unsigned int default_width; unsigned int default_height; unsigned int pclk_polarity; /* 0: 上升沿 1: 下降沿 */ unsigned int vsync_polarity; unsigned int href_polarity; };

4.3 颜色偏色或者完全没有颜色，检查 YUV 和 RGB 转换链

TVP5150 输出的本来就是 YUV 4:2:2，用户空间如果直接用 RGB 格式打开 /dev/videoX，颜色必然不对。正确做法是设置 pixelformat 为 V4L2_PIX_FMT_YUYV，拿到原始 YUV 数据后，再由上层库转成 RGB 去显示。这个坑在屏幕预览阶段特别常见，因为大部分人第一反应是驱动写错了，实际上驱动已经在老老实实地输出 YUYV，是上层没有正确解释数据格式。

另一个偏色来源是 CAMIF 的 YCbCr 色空间配置，有的三星 BSP 提供 BT.601 和 BT.709 色域切换，默认值不对会导致红色偏橙、蓝色偏紫。

4.4 DMA 丢帧的问题，急救办法是多给缓冲

s3c6410 CAMIF 的 DMA 是直接用描述符把帧数据写到指定内存的，如果用户空间只申请了 2 个 buffer，而应用层消费速度跟不上，硬件就会丢弃新的中断或覆盖旧的帧。在调试阶段，我的建议是至少申请 4 个 buffer 进行 mmap 采集，同时把 VIDIOC_REQBUFS 的数量提到 8，可以解决绝大多数丢帧问题。

如果已经申请了很多 buffer 还是周期性丢帧，就要怀疑 camif 中断处理里耗时过长。帧完成中断里尽量不要做耗时的操作，比如寄存器回读、打印日志，只做 buffer 状态迁移和 wake_up 就好。

5. 验证手段：从裸流 YUV 到一张能看清的画面

驱动移植完后，验证效果也是门学问。尤其在这种老平台上，图形环境未必完整，最可靠的办法还是抓裸数据流到本地，然后拿到 PC 上去看。

5.1 板端抓帧，v4l2-ctl 是最趁手的工具

在 s3c6410 上跑 v4l2-ctl 需要交叉编译，但值得做，因为它的调试能力很强。采集 10 帧裸数据到文件的命令大概是这样：

v4l2-ctl -d /dev/video0 --set-fmt-video=width=720,height=576,pixelformat=YUYV \ --stream-mmap --stream-count=10 --stream-to=tvp5150.yuv

如果板子上实在放不下 v4l2-ctl，也可以自己写一个几十行的采集小程序，核心就是 open 设备、 VIDIOC_S_FMT、VIDIOC_REQBUFS、VIDIOC_QBUF、VIDIOC_DQBUF 这一套标准流程。

5.2 PC 端查看裸 YUV 文件

拿到 tvp5150.yuv 后，在 PC 上用 mplayer 可以直接看：

mplayer -demuxer rawvideo -rawvideo w=720:h=576:format=yuy2 tvp5150.yuv

能看到画面，说明从 TVP5150 到 CAMIF 到内存的链路完全通了。如果画面有横纹，说明制式或者极性还有问题；如果画面正常但颜色怪，说明上层解释或色空间设置有偏差。这两种现象能帮你快速把问题定位到驱动还是应用层。

5.3 运行时用 i2cset 做临时寄存器实验

调试过程中我习惯在板端用 i2cset 直接修改寄存器来做 A/B 测试，避免反复编译驱动。比如想确认输入源到底有没有选对，就在运行时把寄存器 0x00 的输入源位改一改，观察输出是否变化。确认寄存器的具体位定义以手册为准，别凭记忆写值。

手工改寄存器定位问题是一个很有效的手段，但改完之后一定要记得把最终确认的值回写到驱动源代码的初始化表里，否则重新上电后问题复现，你会以为驱动没改对。

如果你现在准备复刻这套 s3c6410 + tvp5150 的方案，我的建议是第一步先别埋在代码细节里，上电后老老实实把 I2C 地址扫出来，然后用最少的寄存器配置去采一帧原始 YUV 数据，链路通了，再去逐步叠加功能。驱动调试最怕的不是寄存器没配好，而是链路理解错了，后面所有努力都是在错误前提上打转。这套 subdev 框架不止适用于 s3c6410，换到 i.MX、全志、瑞芯微的平台，也基本是同样套路，核心代码可以平移，这就是为什么值得花时间把驱动源代码骨架和排错链路真正吃透。

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