简介：面向手机、平板等移动设备的OV5645 MIPI YUV驱动，是一份供嵌入式驱动工程师、底层系统开发者以及摄像头模组调试人员参考的传感器驱动源码。这份驱动覆盖了传感器初始化、MIPI接口高速传输链路的建立、YUV图像数据的接收与解析、多缓冲区轮转管理以及同步信号处理等关键环节，并附有寄存器级别的参数配置内容，能帮助读者理解CMOS摄像头在不同平台上的适配过程，也为排查图像异常、帧率不稳等问题提供了可借鉴的思路。压缩包为RAR格式，大小仅40KB，共4个文件：其中3个.h头文件分别用于声明接口、定义传感器参数和配置寄存器，1个.c源文件实现了驱动的主要控制流程与数据处理逻辑，整体结构清晰，便于快速阅读和移植。该资源在CSDN已有583人学习，对正在研究OV5645或同类MIPI摄像头驱动的开发者而言，是一份小而完整的参考例程，既可以作为入门学习的代码范例，也能作为实际项目中的底层适配工具。

1. 拿到“ov5645_mipi_yu驱动”这个标题时，我首先想到的是：调过这颗传感器的人都在哪个环节卡过

在我调试过的嵌入式视觉项目里，OV5645 这颗 500 万像素传感器出镜率不低，但真正把ov5645_mipi_yu驱动一次跑通的人少。所谓的“yu”不是某家厂商的魔改后缀，而是指传感器工作在 YUV 输出模式——也就是 MIPI CSI-2 接口上传的是 YUV422 数据，不是 RAW 也不是 RGB。调试这个驱动的难点从来不在“把驱动文件编进内核”，而在三件事：MIPI 链路到底有没有数据在跑、YUV 格式和裁剪参数对不对、以及上电时序有没有把传感器送进正常状态。这篇文章适合正在调 MIPI 摄像头、被“打开 /dev/video0 但抓帧全黑”折磨的 Linux 驱动工程师，也适合刚接手 MIPI 摄像头模组的嵌入式 BSP 开发。我会按一条完整的调试链路来写：硬件抽象、寄存器配置、设备树绑定、踩坑记录，最后落到验证手法上。

2. MIPI 链路和寄存器映射先想清楚，再写驱动不迟

很多新手拿到 OV5645 的 datasheet 就直接翻寄存器表，结果连驱动框架都搭错，回头改结构比改寄存器痛苦得多。先把 MIPI 链路和 V4L2 的分层关系理清，后面每一步调试才能有依据。

2.1 从 MIPI CSI-2 到 V4L2：三层链路必须对应上

OV5645 的 MIPI 输出是一个 CSI-2 发射源，SoC 端的 MIPI CSI 控制器是接收端，中间的介质是 D-PHY 物理层。对应到 Linux，这条链路被拆成三个层次：传感器本身在 I2C 总线上挂载，实现 v4l2_subdev；CSI 接收控制器是另一个 subdev；再往上是 video capture 设备节点，也就是我们抓帧用的 /dev/video0。

• 传感器节点：负责 I2C 配置、寄存器序列下发、检测信号输出。
• CSI 控制器节点：负责 MIPI 协议解析、lane 配置、时钟恢复。
• video 节点：负责把接收到的数据排队到内存，也就是 DMA 传输。

实际调试中，最让人翻车的分歧点是：传感器已经 MIPI 输出信号了，但 CSI 控制器没有锁定，或者锁定了但行场参数不一致，导致上层的 v4l2 一直报“no signal”。V4L2 的这个三分层设计不是摆设——每一层都有独立的调试入口，我先看 sensor 的 subdev 是否正常 probe，再看 CSI 的 media 链路状态，最后才查 video 节点格式。

2.2 读 OV5645 数据手册时我重点看的四张表

OV5645 的数据手册大概几百页，不建议从头到尾读。我一般只看四类内容，其余的遇到问题再查：

第一张是包装引脚定义表，确认 MIPI 引脚、I2C 引脚、复位引脚和电源引脚的对应关系。第二张是 SCCB（类似 I2C）时序参数表，决定 I2C 控制器时钟频率上限。第三张是寄存器 default 值表，可以对比驱动初始化后寄存器值是否异常。第四张是 timing 表，包含 HTS、VTS、PLL 分频系数等关键参数，分辨率切换时最值得参考。

常见做法是先把 datasheet 中的 MIPI 相关寄存器摘出来整理成一个清单，比如 0x3017 MIPI 模式、0x4800 MIPI 时钟分频、0x4814 MIPI PLL 等。这些寄存器的配置值往往不是只改位数就行，而是和传感器的输出格式、分辨率绑定，后面会详细讲。

2.3 I2C 地址与寄存器映射：SCCB 细节决定能不能读到芯片

OV5645 是 OmniVision 的传感器，SCCB 接口兼容 I2C 时序，地址是 8 位右移一位，常见写地址是 0x3c、0x30、0x40 等，取决于引脚电平。很多项目里 I2C 探测不到传感器，不是代码写错，是地址选错了。读 datasheet 的 SCCB slave address 表格，确认 8 位地址和 7 位地址的换算方式。

另外注意一个细节：OV5645 的寄存器是 16 位寻址，也就是说 I2C 写寄存器时要先发高 8 位地址，再发低 8 位地址，然后是数据。这个跟常见的 8 位寻址传感器完全不同。有些驱动照着别的传感器改，写寄存器时序不对，导致读回来全是 0xff，或者寄存器写不进去。

/* 16-bit register address write pattern */ static int ov5645_write_reg(struct i2c_client *client, u16 reg, u8 val) { u8 buf[3]; struct i2c_msg msg; buf[0] = (u8)(reg >> 8); buf[1] = (u8)(reg & 0xff); buf[2] = val; msg.addr = client->addr; msg.flags = 0; msg.len = 3; msg.buf = buf; return i2c_transfer(client->adapter, &msg, 1); }

这个函数是传感器驱动最底层的公共接口，写寄存器、读寄存器、批量写序列都基于它。参数buf[0]和buf[1]用来拼接寄存器高 8 位和低 8 位，buf[2]是写入值。注意消息长度是 3，i2c_transfer 返回的不是字节数而是消息数，判断返回值时别弄混。如果读操作，那么要先发两个寄存器地址字节，然后重新发起一次读交易，数据长度是 1。

3. YUV 模式的寄存器序列：从哪里取、怎么改、分辨率切换的坑在哪

OV5645 的寄存器序列在网上能找到很多版本，但大多是 RAW RGB 模式的初始化代码。如果你的项目就是要 MIPI YUV 输出，照着 RAW 模式的序列套用，出来的图多半偏色或者格式报错。这一章讲清楚 YUV 模式的配置逻辑。

3.1 YUV 模式与 RAW 模式的选型差异

OV5645 内部 CIS（CMOS Image Sensor）采集到的是 Bayer RAW 数据，输出前经过 ISP 处理。选择 YUV 模式时，ISP 会把 RAW 转换为 YUV422，然后再经 MIPI 发送。选择 RAW 模式时，ISP 的处理路径被旁路，输出的是原始 Bayer 数据。这对驱动的直接影响是：

• YUV 模式对 MIPI 带宽要求更高，同样的分辨率下 lane 速率更大。
• YUV 模式需要设置 ISP 相关的寄存器，比如 0x503d 和 0x503e 的 YUV 格式开关。
• 颜色矩阵和增益寄存器只在 YUV 模式下有意义，RAW 模式下这些值不生效。

MIPI 屏调试没信号和 MIPI 摄像头调试没信号是同一个底层问题，都在于 D-PHY 物理层没对上，只不过传感器端还多了一个 ISP 管线。调试 YUV 模式时，如果偏色，先检查 YUV 顺序是 UYVY 还是 YUYV，而不是急着调白平衡。

3.2 先放出可跑的初始化序列：960x540 MIPI YUV 最小配置

我给出一个最小化的寄存器序列框架，这些值能跑到 960x540@30fps。这个尺寸不是随便选的，960x540 是 MIPI 传感器调试时比较常用的验证分辨率，寄存器算起来比 1080p 简单，带宽压力也小。

static const struct reg_value ov5645_yuv_960x540_regs[] = { {0x3103, 0x11}, /* 系统复位，解除之后才能访问其他寄存器 */ {0x3008, 0x82}, /* 关闭输出，配置完成后再打开,防止花屏 */ {0x3017, 0x7f}, /* MIPI 引脚使能 */ {0x3018, 0x00}, /* MIPI 接口模式选择 */ {0x4800, 0x24}, /* MIPI 时钟分频配置，决定 lane 速率 */ {0x4801, 0x0f}, /* MIPI 模式位宽配置 */ {0x4814, 0x2a}, /* MIPI PLL 配置高字节 */ {0x4815, 0x4a}, /* MIPI PLL 配置低字节 */ {0x4817, 0x60}, /* MIPI 输出时序控制 */ {0x3800, 0x00}, /* 水平起始高字节 */ {0x3801, 0x00}, {0x3802, 0x00}, /* 垂直起始高字节 */ {0x3803, 0x00}, {0x3804, 0x03}, /* 水平结束，即输出宽度 960 */ {0x3805, 0xbf}, {0x3806, 0x02}, /* 垂直结束，即输出高度 540 */ {0x3807, 0x1b}, {0x3808, 0x03}, /* ISP 输出宽度 960 */ {0x3809, 0xc0}, {0x380a, 0x02}, /* ISP 输出高度 540 */ {0x380b, 0x1c}, {0x380c, 0x07}, /* HTS 总宽度 */ {0x380d, 0xa0}, {0x380e, 0x04}, /* VTS 总高度 */ {0x380f, 0x48}, {0x501f, 0x01}, /* 选择图像格式，此处对应 YUV */ {0x503d, 0x00}, /* YUV 模式开关 */ {0x503e, 0x00}, {0x3008, 0x42}, /* 重新开启输出 */ };

这段序列的逻辑是先把传感器复位，关闭输出，配置 MIPI 参数，再配裁剪窗口和输出尺寸，最后打开输出。参数说明：0x3017=0x7f把 MIPI 引脚全部使能，0x3018=0x00选择 MIPI 模式；0x3804/0x3805和0x3806/0x3807决定裁剪窗口右下角坐标，0x3808~0x380b决定最终输出分辨率。这里有一个易错点：裁剪窗口的结束值是宽高减一的十六进制表达，960 对应0x03bf，540 对应0x021b，新手容易直接写0x03c0导致边界越界。

HTS 和 VTS 直接影响帧率。默认 960x540 配置里 HTS 设成了 0x07a0（即 1952），VTS 设成了 0x0448（即 1096）。帧率由模组时钟、PLL 分频和这两个参数共同决定。想调帧率，优先改 VTS，其次是 HTS，但 HTS 改动会影响行消隐时间，改太小容易出现行数据错乱。

3.3 分辨率切换时改参数的三处易错点

从 960x540 切到 1280x720 时，很多人只改了输出宽高寄存器，结果图像错位或者偏色。实际需要同步修改三类参数：

第一类是裁剪窗口结束坐标，0x3804/0x3805和0x3806/0x3807要随分辨率一起改。第二类是 ISP 输出尺寸，0x3808~0x380b。第三类是 HTS/VTS，因为不同分辨率下时序要求不同，HTS 不能小于输出宽度加上最小消隐值。

经验做法是先用 datasheet 里的 timing 计算表格算一遍 HTS/VTS，而不是直接照抄网络上的寄存器表。不同模组厂商的 OV5645 模组，镜头和传感器基板略有差异，寄存器序列也会有细微出入，如果效果不对，优先找模组厂要初始化代码，而不是自己从零开始试。

4. 把驱动挂到 Linux 下：设备树节点、电源时序与 subdev 注册

寄存器序列只是驱动的一部分，真正让内核管理这颗传感器，还需要设备树、电源管理和 V4L2 subdev 框架。这一章把这些串起来，给出可以直接参考的写法。

4.1 设备树节点：时钟、GPIO、MIPI 端口的绑定方式

设备树是 MIPI 摄像头驱动最先排查的地方。OV5645 挂在哪条 I2C 总线上、MCLK 从哪个时钟源来、复位和掉电引脚接在哪里、MIPI 数据通道怎么接，全部由设备树决定。

&i2c2 { ov5645: ov5645@3c { compatible = "ovti,ov5645"; reg = <0x3c>; pinctrl-names = "default"; clock-frequency = <24000000>; clocks = <&clk IMX8MM_CLK_CLKOUT1>; clock-names = "xclk"; assigned-clocks = <&clk IMX8MM_CLK_CLKOUT1>; assigned-clock-rates = <24000000>; reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>; pwdn-gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>; port { ov5645_mipi_ep: endpoint { remote-endpoint = <&mipi_csi_ep>; >static int ov5645_power_on(struct ov5645 *ov5645) { gpiod_set_value_cansleep(ov5645->pwdn_gpio, 1); usleep_range(5000, 10000); clk_prepare_enable(ov5645->xclk); gpiod_set_value_cansleep(ov5645->reset_gpio, 1); usleep_range(20000, 50000); return 0; }

这段代码先给掉电脚拉高使能供电，再使能 MCLK，最后拉高复位脚结束复位。注意pwdn_gpio的语义是掉电引脚，通常高电平进入掉电状态，所以 1 在这里代表解除掉电，具体要看硬件定义。延时参数不是随手的，5ms是为了等电源稳定，20ms是为了等传感器内部振荡器起振。如果板子上的电源纹波比较大，可以考虑把第一步的延时加到 20ms。

另一个容易踩的坑是 MCLK 频率漂移。如果设备树里配的 assigned-clock-rates 是 24MHz，实际示波器测出来却是 23.5MHz，MIPI 输出频率会跟着偏，CSI 控制器可能无法正确采样。遇到这种情况，先查 SoC 的时钟树有没有在别处复用同一个时钟源导致分频改变，而不是急着怀疑寄存器。

4.3 V4L2 subdev 注册：s_stream 回调里做什么

OV5645 驱动在 Linux 中是一个标准的 v4l2_subdev，核心回调是s_stream。传感器驱动的工作流程是：probe 时读取设备树参数，初始化 subdev 并提供操作函数；上层调用s_stream(1)时配置 MIPI 输出并启动流；s_stream(0)时进入 standby 或关闭 MIPI 输出。

static int ov5645_s_stream(struct v4l2_subdev *sd, int enable) { struct ov5645 *ov5645 = v4l2_get_subdevdata(sd); int ret; if (enable) { ret = ov5645_power_on(ov5645); if (ret < 0) return ret; ret = ov5645_write_array(ov5645, ov5645_yuv_960x540_regs); if (ret < 0) return ret; ret = ov5645_write_reg(ov5645, 0x0100, 0x01); /* 开始输出 */ if (ret < 0) return ret; } else { ov5645_write_reg(ov5645, 0x0100, 0x00); /* 停止输出 */ ov5645_power_off(ov5645); } return 0; }

s_stream 里的逻辑顺序是固定的：先上电再配寄存器，然后写0x0100=0x01让传感器开始输出数据。停止流时先写0x0100=0x00，再做掉电。注意0x0100这个寄存器是传感器主控开关，MIPI 输出是否发送数据由它决定，和之前 0x3008 的输出开关是两个层级。如果s_stream里直接写 0x3008 而不动 0x0100，数据流可能不会输出。

5. OV5645 MIPI YUV 调试中的五个翻车现场：现象、原因、解决

这一章我把调试过程中最常遇见的五个问题列出来。每个都按现象、原因、解决的顺序写，方便遇到类似情况时直接对照排查。

5.1 现象一：v4l2-ctl 抓帧全绿或全灰，MIPI 没数据上来

抓帧出来的图像不是黑就是满屏绿，先确认这是传感器没输出还是 CSI 控制器没收到。检查方法是通过 CSI 控制器驱动里的错误中断寄存器，一般会有 lock error、sync error 计数。如果错误计数在递增，说明 MIPI 物理层没锁定；如果错误计数为 0 但图像全灰，说明 CSI 锁定了但收到的全是空数据。

原因通常有两个：MCLK 频率不对导致 MIPI bit clock 超出接收范围；或者 data lanes 配置不一致。解决方法是先用示波器测 MCLK 频率，再核对设备树里 CSI 端的>media-ctl -d /dev/media0 -r media-ctl -d /dev/media0 -l "'ov5645 2-003c':0->'csi2':0[1]" media-ctl -d /dev/media0 -V "'ov5645 2-003c':0[fmt:UYVY8_2X8/960x540@1/30]"

第一条命令重置 media 拓扑，避免上次残留的配置干扰。第二条命令建立传感器 subdev 到 CSI 控制器的数据流链接，[1]表示启用该链接。第三条命令配置传感器的输出格式为 UYVY8_2X8，分辨率 960x540，帧率 30。UYVY8_2X8是 MIPI CSI-2 传输的 V4L2 介质总线格式描述，表示每像素两个字节的 UYVY 数据。

设置完成后用media-ctl -p查看链路状态，确认传感器到 CSI 的方向和格式项都显示正确。如果这里少了格式或方向是反的，回到设备树检查端点配置。

6.2 用 v4l2-ctl 抓帧验证

v4l2-ctl -d /dev/video0 --set-fmt-video=width=960,height=540,pixelformat='UYVY' v4l2-ctl -d /dev/video0 --stream-mmap --stream-count=5

第一条命令设置 video 节点的输出格式，必须和 media-ctl 里设置的介质总线格式兼容。第二条命令用 mmap 方式连续抓取 5 帧到用户空间。如果抓帧成功，说明 sensor、CSI、video 节点整条链路是通的。如果提示缓冲队列超时，回到 5.1 节的检查点，确认 MIPI 物理层是否锁定。

V4L2 的验证技巧是先抓单帧原始文件，不要直接显示。比如抓成 raw 文件，在 PC 端用 Python 解析出像素数据，能更清楚看到图像内容。如果有 YUV 顺序问题，也能直接看出来，因为 RGB 转换后颜色顺序明显不对。

6.3 看 MIPI 错误计数：驱动该主动报告而不是藏起来

一个合格的传感器驱动不应该只做“上电 + 写寄存器”，还要在流启动后用读取寄存器的方式回报 MIPI 错误状态。OV5645 有一个状态寄存器区域，记录了 MIPI 的 lane 错误、同步信号错误等信息。驱动里可以在s_stream开启时读一次，在流停止时再读一次，把两次的差值打印出来。

# 读取 CSI 控制器错误计数（以 imx8 CSI2 为例） cat /sys/kernel/debug/csi2/pool_status

这种方式比在用户态用抓帧来猜问题更快。CSI 控制器的 debugfs 节点通常包含 sync_pool、data_pool 等计数，配合传感器侧 error 寄存器能精确定位问题在发送端还是接收端。我一般把这条验证路径固化在每个 OV5645 项目的文档里，配合上面的 media-ctl 命令，十分钟内就能判断链路是否可交付。

调试 MIPI 摄像头驱动的习惯多年来我一直保持一个原则：先把链路状态和错误计数作为调试的第一依据，而不是凭图像猜问题。图像带偏色的原因可能有十几种，但 MIPI 错误计数会精确告诉你链路在哪一层断掉。希望这一套从硬件链路、寄存器序列、设备树到验证命令的流程，能让你在拿到类似 MIPI 摄像头驱动任务时少走一些弯路。

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