企业官网建设流程全解析

简介：这是一份面向嵌入式驱动开发者的OV5645 MIPI YUV摄像头驱动源码，基于MIPI接口与YUV色彩空间，适用于手机、平板等移动设备的相机模块适配与调试，也可作为学习MIPI摄像头驱动的入门参考。该驱动负责传感器识别、初始化、数据传输、缓冲管理及同步信号处理，是摄像头正常成像的关键软件层。资源包共4个文件，由3个头文件与1个C源文件组成：头文件分别对应传感器寄存器参数、平台采集参数及定制化接口配置，C文件则实现了传感器初始化、MIPI数据接收、图像格式解析与电源管理逻辑，整体约40KB，代码量小巧精炼，便于阅读和移植到不同平台。已有583人学习下载。通过学习该驱动，开发者可以快速理解OV5645在MIPI YUV模式下的工作流程，掌握分辨率、帧率、曝光时间等关键参数的配置方法，并参考其缓冲管理与同步信号处理思路，用于相机驱动开发、项目调试或作为自有代码的移植蓝本；同时可借鉴其中的错误处理与电源管理设计，优化系统运行时的稳定性与功耗表现。

1. ov5645_mipi_yu驱动：为什么先查 MIPI 信号而不是先查驱动代码

调试 ov5645 这颗 sensor 的 mipi_yu 驱动时，我见过太多人把时间耗在翻驱动源码上，最后发现是设备树里一个 clock-frequency 配错、MIPI 时钟 lane 没拉起来，导致 camera 根本不出图。ov5645 是 OmniVision 的 500 万像素 sensor，mipi_yu 指的是通过 MIPI CSI-2 接口输出 YUV422 格式数据，这类驱动在内核里通常对应ov5645.c，配合 V4L2 框架和 media controller 使用，常见于 i.MX6ULL、RK3288、全志 V3s 这类带 ISP 或直接采集 YUV 的嵌入式平台。

这篇笔记直接解决三个问题：驱动是怎么把 ov5645 的 MIPI YUV 数据送进内核的、设备树该怎么配才能让ov5645节点被正确 probe、以及出图失败时排查的先后顺序。内容面向正在调 Linux camera 驱动、手里有板子和 sensor 模块、需要尽快出图的工程师，不聊 RGB 和 BT656 那些旧接口。先记住一个结论：MIPI 物理层不通，驱动写得再对也是黑匣子。

2. 从 ov5645 到 mipi_yu：先理解 sensor 为什么默认走 YUV 输出

2.1 YUV422 输出路径：sensor 内部 ISP 与 MIPI 打包

ov5645 的 datasheet 里有一个关键信息：它把片上 ISP 处理后的数据直接通过 MIPI CSI-2 发出去，不需要 SoC 端做复杂的 ISP 处理。常见的输出格式是 YUV422 8-bit，也就是UYVY或YUYV，对应内核里的MEDIA_BUS_FMT_UYVY8_2X8。这个格式在 MIPI 链路上是按「Y0 U0 Y1 V0」的顺序逐像素打包的，每个像素 2 字节，一条 lane 上跑 8-bit 数据。

选 YUV 输出而不是 RAW Bayer，核心原因是 SoC 端省事。RAW 数据需要 SoC 的 ISP 做去马赛克、白平衡、降噪，这要求驱动里额外实现 media pipeline 的实体绑定和 format 协商。而 YUV 输出直接把 sensor 当成一个「数据源」，V4L2 子设备注册后，get_fmt返回的就是可直接显示的格式，采集端拿到的 buffer 不用再做格式转换就能喂给显示或编码器。所以很多工业视觉项目里用 ov5645 而不是 ov5640，就是看重这颗 sensor 的 YUV 输出稳定性和 500 万像素的清晰度。

2.2 驱动里最重要的三个回调：s_power、s_stream、set_fmt

ov5645.c这个驱动属于 V4L2 subdev 驱动，核心就是实现v4l2_subdev_ops里的三个回调：

• s_power：控制 sensor 的上电和断电，包括 reset 引脚、powerdown 引脚、MCLK 时钟的开关。如果这个回调里没把 reset 拉高再拉低，sensor 可能一直处于复位状态，MIPI 无输出。
• s_stream：启动或停止 MIPI 数据流。这个函数里会调用ov5645_s_stream，往 sensor 寄存器写入 0x4202 等值来开始输出。注意，很多平台的 ISP 要在s_stream之前完成初始化，否则会看到「no signal」。
• set_fmt：配置输出格式和分辨率。ov5645 支持的 YUV422 分辨率一般是 1280x960 和 1920x1080，还有 640x480 预览模式。驱动里有一段初始化寄存器序列，按分辨率区分数组，比如ov5645_1920x1080_regs。

我调 rk3288 平台时，习惯先在s_power里加一段 10ms 的延时再拉高 reset，防止 sensor 上电后立刻被复位。这个延时看起来是玄学，但实际是 MCLK 稳定需要时间，写短了真的会偶发无图。

2.3 media controller 与 V4L2 pipeline 的绑定关系

驱动 probe 成功后，会注册一个 v4l2_subdev，并且通过media_entity_pads注册一个 sink pad。这个 pad 要和 SoC 端的 CSI 控制器实体用media_create_pad_link连接起来。这一步不写在 sensor 驱动里，而是写在 SoC 的 camera 驱动里，比如rkisp或mxc_mipi。

常见做法是：先加载 sensor 驱动，生成/dev/v4l-subdev0；再加载 CSI 控制器驱动，把 sensor 的 subdev 挂到它所管理的 pipeline 上。检查这一步是否完成，看media-ctl -p的输出，确认 sensor entity 是否出现在拓扑里。如果 sensor 驱动加载了却看不到 entity，多半是设备树里port的 endpoint 连接写错了，或者remote-endpoint的 phandle 指向了一个不存在的节点。

3. 把 ov5645_mipi_yu 驱动跑起来：设备树、内核配置与加载顺序

3.1 设备树节点：clock、reset、powerdown 三个引脚一个不能少

一个能正常 probe 的 ov5645 设备树节点，最少要有 MCLK 时钟、reset-gpio、powerdown-gpio、I2C 地址和 MIPI endpoint。下面是一个基于 i.MX6ULL 平台的可复现写法：

&i2c2 { ov5645: ov5645@3c { compatible = "ovti,ov5645"; reg = <0x3c>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_csi_0>; clocks = <&clks IMX6UL_CLK_CSI>; clock-names = "xclk"; assigned-clocks = <&clks IMX6UL_CLK_CSI>; assigned-clock-rates = <24000000>; reset-gpios = <&gpio1 18 GPIO_ACTIVE_LOW>; powerdown-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>; csi_id = <0>; mclk = <24000000>; mclk_source = <0>; port { ov5645_ep: endpoint { remote-endpoint = <&csi_ep>; clock-lanes = <0>; >CONFIG_VIDEO_OV5645=y CONFIG_MEDIA_CONTROLLER=y CONFIG_VIDEO_V4L2_SUBDEV_API=y CONFIG_VIDEO_MXCSI=y # 取决于平台，如果是 rk 平台就是 CONFIG_VIDEO_RKISP

驱动源码在drivers/media/i2c/ov5645.c。如果你的内核版本较老，源码里可能没有 compatible 字符串"ovti,ov5645"，需要检查ov5645_of_match表。我看到过有人从新内核把 ov5645.c 整个拷到老内核，结果编译报错，因为结构体v4l2_subdev_ops的成员名在新旧内核里不一样。不要直接跨大版本拷贝驱动文件，用 backport 的方式逐函数移植更稳。

配置保存后重新编译内核，烧录前用menuconfig搜一下OV5645，确认驱动确实编进去了。烧录后启动，插上摄像头模组，用dmesg | grep ov5645看 probe 日志：

ov5645 2-003c: probing... ov5645 2-003c: detected OV5645 sensor ov5645 2-003c: supply vdddo not found

看到supply not found或者reset GPIO not available直接修设备树，别往下查。前面这些 regmap 和 GPIO 都没起来，MIPI 更不可能有信号。

3.3 加载顺序：sensor 先 probe，还是 CSI 先 probe

在多数 Linux BSP 里，sensor 驱动和 CSI 控制器驱动是独立 probe 的，不存在硬性的先后顺序，因为 media link 的建立发生在 CSI 控制器的complete回调，也就是所有 subdev 都 probe 完才执行。但也见过一些平台偷懒，把 link 写在 CSI 驱动的 probe 里，此时 sensor 还没 probe，media link 建立失败，运行时不报错也不出图。

我一般验证加载顺序的方法是：开机后先看/sys/bus/i2c/devices/下有没有2-003c这个目录，再看media-ctl -p里 sensor entity 在不在。如果 sensor 已经 probe 但 entity 没出现在拓扑里，这个 CSI 驱动多半是有问题的，要么改驱动的complete回调，要么用v4l2-compliance去强制触发 subdev 绑定。

还有一种是 sensor 和 CSI 都在驱动里指定了async寄存器流程，例如用v4l2_async_register_subdev和v4l2_async_notifier。这种情况下，通过CONFIG_VIDEO_V4L2_ASYNC调试信息能看到绑定是否成功。如果async绑定失败，日志里会出现failed to bind subdev，先检查 device tree 里 endpoint 的remote-endpoint是否双向都写了，漏一侧就会触发异步框架超时。

4. 运行时验证：确认 MIPI 链路真的在传 YUV 数据

4.1 用 media-ctl 和 v4l2-ctl 抓一帧图，验证链路

设备树和驱动都正常后，出图验证的命令序列是固定的。以 i.MX6ULL + ov5645 为例：

media-ctl -d /dev/media0 -r media-ctl -d /dev/media0 -l "'ov5645 2-003c':0 -> 'mx6s-csi':0[1]" media-ctl -d /dev/media0 -V "'ov5645 2-003c':0 [fmt:UYVY8_2X8/1280x960]" v4l2-ctl -d /dev/video0 --set-fmt-video=width=1280,height=960,pixelformat=UYVY v4l2-ctl -d /dev/video0 --stream-mmap --stream-count=1 --stream-to=/tmp/frame.raw

media-ctl -l那一条是建 link，-V是设置 pad format。这两条不执行，v4l2-ctl即使打开/dev/video0，拿到 buffer 也是全黑或全灰。原因是 V4L2 pipeline 里每个实体之间有独立的 format，必须逐级协商一致。UYVY8_2X8这个格式名称来自media-bus-format.h，在命令行里写成字符串时注意别把2X8写成2x8，大小写敏感。

抓到的/tmp/frame.raw是纯 YUV 数据，没有文件头。用 Python 转成 PNG 验证内容：

import numpy as np from PIL import Image width, height = 1280, 960 raw = np.fromfile('/tmp/frame.raw', dtype=np.uint8) y = raw[0::2].reshape(height, width) u = raw[1::2].reshape(height, width // 2) uv = np.stack([u, u], axis=-1).reshape(height, width) img = np.stack([y, uv, uv], axis=-1).astype(np.uint8) Image.fromarray(img, 'YCbCr').convert('RGB').save('/tmp/frame.png')

说明一点：raw[0::2]取的是偶数位字节，对应 YUV422 里的 Y；raw[1::2]是奇数位，包含 U/V 交替，这里简单地重复 U 分量，颜色并不严格正确，但用来确认图像内容足够。重点观察两点：图像是否全黑或全绿，以及边缘是否有多彩噪点。全黑说明数据没进来，全绿说明 Y 分量全是一个值，大概率是 sensor 没正确初始化。

4.2 看 MIPI 错误计数和 CSI 中断：比看图像更早暴露问题

图像有干扰或不出图时，先别急着改驱动代码。我通常在 CSI 控制器的中断状态和错误计数里找信息：

cat /proc/interrupts | grep csi cat /sys/kernel/debug/mx6s_csi/err_count

不同平台不一样，但思路是通用的。如果 CSI 中断次数为 0，说明 MIPI 物理层根本没收到数据，问题在 sensor 侧的时钟或 lane 配置。如果中断次数增加但err_count里有 CRC 错误或 ECC 错误，说明物理链路不稳定，优先查：

• 模组的 MIPI 排线是否过长或弯折过，MIPI 信号对阻抗敏感，飞线超过 10cm 就容易出 CRC 错误
• >v4l2-ctl -d /dev/v4l-subdev0 --get-fmt

  看输出是不是UYVY8_2X8。如果 sensor 支持多种格式，比如Y8和UYVY，s_stream时驱动会根据set_fmt选择的 mbus code 写不同的寄存器序列，所以media-ctl -V设置的格式必须和 sensor 内部寄存器初始化的格式一致。

  YUV 字节序颠倒（UYVY 和 YUYV）不影响亮度，只影响色度，最容易出现在不同版本的 ov5645 模组上。同一颗 sensor 不同批次，寄存器默认值可能有差异，厂商会在初始化序列里写死输出格式，因此不要只信驱动代码里写的，要实际抓一帧验证。

  5. ov5645_mipi_yu 驱动调试避坑：5 条实战踩坑记录

  5.1 现象：s_stream 之后 no signal，dmesg 里没有错误

  原因排查过程：先看 CSI 的 interrupt 状态，发现中断计数为 0。再看 MCLK，示波器抓xclk引脚，发现没有波形。查驱动s_power回调代码，发现clk_prepare_enable执行了但没检查返回值，进一步查设备树发现assigned-clock-rates和实际 PLL 输出的频率不匹配，clk 框架自动把频率设置成了最近似值 22.5MHz，但 sensor 需要 24MHz，PLL 锁定失败。

  解决：在s_power里加延时，并且用clk_get_rate打印实际时钟频率，确认是 24MHz 再继续。设备树里assigned-clock-parents也要指定正确的父时钟，否则 clk 框架可能选了一个误差超过 5% 的源。

  5.2 现象：图像有横向撕裂，帧率只有预期的一半

  原因分析：ov5645 默认输出帧率可能不是我们想要的。在驱动s_stream里写入的初始化序列里，0x4808和0x4809控制 PLL 分频，这两个值决定了像素时钟。如果 SoC 端的 CSI 接收带宽不足，比如只支持 2 lane @ 500Mbps，而 sensor 按 4 lane @ 800Mbps 输出，图像就会出现撕裂或丢帧，但单帧图像内容是完整的。解决方法是把分辨率降到 640x480，或修改寄存器数组里的0x4808/0x4809让输出降低到匹配带宽。

  5.3 现象：probe 失败，报failed to find reset-gpios

  设备树写的是reset-gpios = <&gpio1 18 GPIO_ACTIVE_LOW>;，但内核报找不到。原因是该 GPIO 已经被别的驱动申请了，或者 pinctrl 配置里没有把gpio1_io18配成 GPIO 功能。解决：先用gpioinfo gpiochip0查这个 pin 是否空闲，再用cat /sys/kernel/debug/gpio看有没有被占用。如果被别的驱动用了，可以给ov5645节点加status = "okay"且确保pinctrl里没有冲突定义。

  5.4 现象：画面全绿，但 interrupt 正常增长

  这个现象最迷惑人。MIPI 数据在中断层面是通的，代表数据确实从 MIPI 进了 CSI。全绿的原因我在 ov5645 模组上查到的是s_stream里寄存器写顺序问题：ov5645 在输出视频数据前需要先写0x4202 = 0x00让 sensor 退出 standby，再等若干帧时间。如果初始化序列里把 standby 位写成了 1，sensor 只会输出同步信号不输出有效像素，采集端看到的数据都是填充值，表现为绿色或灰色。解决：修改ov5645_1920x1080_regs数组里0x4202的值，并且在s_stream启动后加msleep(100)，等 sensor 稳定输出。

  5.5 现象：热拔插后程序崩溃或 ioctl 报EPIPE

  ov5645 这类模组不支持热拔插，但调试时经常带电插拔，导致 I2C 总线锁死或 MIPI 时钟被拉死。发生之后最有效的恢复办法是断电重启，而不是在驱动里加恢复逻辑。有些平台可以在驱动里对s_stream的失败路径做优化，比如超时后usb_reset_device的思路迁移过来：关掉 MIPI 时钟，释放 CSI 的 DMA，再重新初始化。注意不要在中断上下文里做这些，配合 workqueue 延迟执行。

  6. 进阶：用 GPIO 触发来验证每一路 MIPI lane，定位物理层问题

  当你已经把驱动、设备树、寄存器都查过一遍，图像依然白屏或花屏，最后的手段是逐 lane 验证。这个方法我在现场帮人排查过多次，比反复改代码有效：把模组从板子上拆下来，用示波器逐根测 MIPI lane 的差分信号，确认每个 lane 的摆幅是否在 200mV 到 400mV 上下，时钟 lane 的频率是否正确。很多模组厂商的排线焊接问题导致单根 lane 数据断掉，CSI 控制器不会报 fatal error，只会持续收到错误数据，表现为花屏或偶发条纹。

  软件侧也可以做一件事：把style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;" />