RK Camera 驱动调试实战：从DTS配置到图像抓取（以OV426为例）

1. 摄像头接口选型与硬件准备

第一次接触RK平台的摄像头驱动开发时，最让我头疼的就是各种接口类型的选择。OV426这类摄像头模组通常支持多种接口协议，选对接口是成功的第一步。目前主流的有三种接口：MIPI、DVP和LVDS，每种都有其适用场景。

MIPI接口就像高速公路上的八车道，传输速度快、抗干扰能力强，是当前高清摄像头的主流选择。我在调试OV426时发现，它的MIPI CSI-2接口可以轻松支持1080p@60fps的视频传输。但要注意的是，MIPI对PCB布线要求较高，差分信号线需要严格等长，阻抗控制在100欧姆，这对硬件设计是个考验。

DVP接口更像是乡间小路，虽然带宽有限（通常支持到500万像素），但布线简单，调试方便。我在一个低功耗项目中使用DVP接口的OV426时，只需要24根信号线就能完成连接。这种接口特别适合对成本敏感、分辨率要求不高的场景。

LVDS接口则像是专门为工业环境设计的装甲车，抗干扰能力极强。记得有一次在电机控制设备中，MIPI接口受到严重干扰，换成LVDS接口的OV426后画面立即稳定了。不过LVDS的电路设计更复杂，需要专用的串行器/解串器芯片。

硬件连接时我总结了几点经验：

• 电源设计要留足余量，OV426通常需要1.8V、2.8V和3.3V三种电压
• I2C上拉电阻建议用4.7kΩ，确保信号质量
• MIPI接口的差分对要严格等长，长度差控制在5mil以内
• 预留测试点，特别是时钟线和同步信号线

2. 设备树(DTS)配置详解

设备树配置是驱动开发的关键环节，我花了整整两周时间才摸清OV426的所有配置项。下面这个配置模板是我调试过数十个摄像头后总结出来的精华：

dts复制ov426@36 {
    status = "okay";
    compatible = "ovti,ov426";
    reg = <0x36>;
    clocks = <&cru CLK_CIF_OUT>;
    clock-names = "xvclk";
    avdd-supply = <&vcc_avdd>;
    dovdd-supply = <&vcc_dovdd>; 
    dvdd-supply = <&vcc_dvdd>;
    power-domains = <&power RV1126_PD_VI>;
    pwdn-gpios = <&gpio3 RK_PA5 GPIO_ACTIVE_LOW>;
    reset-gpios = <&gpio0 RK_PB7 GPIO_ACTIVE_HIGH>;
    pinctrl-names = "default";
    pinctrl-0 = <&cifm0_dvp_ctl>;
    rockchip,camera-module-index = <0>;
    rockchip,camera-module-facing = "back";
    rockchip,camera-module-name = "default";
    rockchip,camera-module-lens-name = "default";
    port {
        cam_para_out1: endpoint {
            remote-endpoint = <&cif_para_in>;
            bus-width = <10>;
            hsync-active = <1>;
            vsync-active = <0>;
        };
    };
};

这个配置有几个关键点需要注意：

1. I2C地址：reg参数必须与硬件设计一致，OV426默认是0x36
2. 电源管理：三个电源域(avdd/dovdd/dvdd)的上电时序很关键
3. GPIO控制：pwdn和reset引脚的电平配置要参考datasheet
4. 数据总线：bus-width要根据实际使用的数据线数量配置

我遇到过最棘手的问题是电源时序。OV426要求先给DOVDD供电，然后是AVDD，最后是DVDD。如果顺序不对，摄像头可能无法正常工作。解决方法是在驱动代码中添加电源序列控制：

c复制static int ov426_power_on(struct ov426 *ov426)
{
    /* 电源上电序列 */
    regulator_enable(ov426->dovdd);
    udelay(2);
    regulator_enable(ov426->avdd);
    udelay(2);
    regulator_enable(ov426->dvdd);
    udelay(5);
    
    /* 复位序列 */
    gpiod_set_value(ov426->reset_gpio, 1);
    udelay(10);
    gpiod_set_value(ov426->reset_gpio, 0);
    udelay(20);
    
    return 0;
}

3. 驱动开发关键点

驱动开发是整个项目中最具挑战性的部分。OV426的驱动主要包含三大模块：模式配置、ID识别和probe函数。让我分享一些实际调试中的经验。

模式寄存器配置是图像质量的基础。OV426支持多种工作模式，每种模式都有对应的寄存器配置：

c复制static const struct ov426_mode supported_modes[] = {
    {
        .width = 400,
        .height = 400,
        .max_fps = {
            .numerator = 10000,
            .denominator = 300000,
        },
        .exp_def = 0x01a0,
        .hts_def = 0x0240, 
        .vts_def = 0x01ce,
        .reg_list = ov426_linear10bit_400x400_regs,
        .hdr_mode = NO_HDR,
    },
    // 更多模式...
};

调试时我发现几个常见问题：

• 曝光时间设置不当会导致图像过亮或过暗
• HTS/VTS值影响帧率，需要根据实际需求调整
• 寄存器写入顺序很关键，必须严格按照datasheet要求

ID识别是驱动加载的第一道关卡。有次调试花了三天时间，最后发现是ID读取函数有问题：

c复制#define OV426_CHIP_ID 0x694F
#define OV426_REG_CHIP_ID 0x300A

static int ov426_check_sensor_id(struct ov426 *ov426)
{
    u32 id = 0;
    int ret;
    
    ret = ov426_read_reg(ov426->client, OV426_REG_CHIP_ID,
                        OV426_REG_VALUE_16BIT, &id);
    if (id != OV426_CHIP_ID) {
        dev_err(dev, "Unexpected sensor ID %04x\n", id);
        return -ENODEV;
    }
    
    dev_info(dev, "Detected OV426 sensor ID %04x\n", id);
    return 0;
}

Probe函数是驱动的核心，需要处理各种初始化工作。我总结了一个可靠的probe流程：

1. 分配和初始化数据结构
2. 解析设备树配置
3. 获取时钟和GPIO资源
4. 初始化电源管理
5. 设置V4L2子设备
6. 注册媒体设备
7. 启动传感器

一个常见的坑是忘记检查返回值。有次因为没检查regulator_enable的返回值，导致摄像头无法正常工作，调试了很久才发现。

4. 调试与图像抓取

驱动开发完成后，真正的挑战才开始。RK平台提供了一套完整的调试工具链，掌握这些工具能事半功倍。

media-ctl是查看媒体链路的神器。第一次使用时，我被复杂的媒体链路搞晕了：

bash复制media-ctl -p -d /dev/media0

这条命令会显示完整的媒体设备拓扑，包括各个实体(entities)和连接(links)。OV426通常的连接路径是：

code复制sensor -> CSI-2接收器 -> 视频输入捕获 -> ISP -> ISPP

调试时我经常遇到链路不完整的问题，解决方法是通过media-ctl手动建立连接：

bash复制media-ctl -d /dev/media0 -l "'ov426 1-0036':0 -> 'rockchip-sy-mipi-dphy':0 [1]"

图像抓取是验证驱动的最终步骤。RK平台支持两种格式的图像抓取：

1. RAW图像抓取（直接从传感器输出）：

bash复制v4l2-ctl -d /dev/video0 \
    --set-fmt-video=width=400,height=400,pixelformat=BG10 \
    --stream-mmap=4 \
    --stream-count=1 \
    --stream-to=/data/BG10.raw \
    --stream-skip=2

2. YUV图像抓取（经过ISP处理）：

bash复制v4l2-ctl -d /dev/video18 \
    --set-fmt-video=width=400,height=400,pixelformat=NV12 \
    --stream-mmap=4 \
    --stream-count=1 \
    --stream-to=/data/NV12.out \
    --stream-skip=2

在实际项目中，我发现几个实用技巧：

• 使用--stream-skip跳过前几帧，避免获取不稳定的图像
• 通过v4l2-ctl --list-formats查看设备支持的格式
• 使用ioctl(VIDIOC_G_FMT)验证格式是否设置成功

有一次调试YUV输出时，图像总是偏色。经过仔细排查，发现是ISP的Bayer模式配置错误。解决方法是在media-ctl中正确设置sensor的输出格式：

bash复制media-ctl -d /dev/media0 --set-v4l2 '"ov426 1-0036":0[fmt:SBGGR10_1X10/400x400]'

调试过程中，日志分析也很重要。我通常会启用以下调试选项：

bash复制echo 7 > /proc/sys/kernel/printk
dmesg -w

这样可以实时查看内核日志，及时发现驱动中的问题。