3. RKISP驱动核心数据结构

好，咱们今天来啃一块硬骨头——RKISP驱动里的三个核心数据结构。说实话，我刚接触RKISP驱动时，也被这三个结构体绕得晕头转向。它们就像三兄弟，长得像，但各司其职。搞懂了它们，你就掌握了ISP驱动的半壁江山。

我个人习惯把这三个结构体比作一个摄影团队：rkisp_device是导演，rkisp_pipeline是摄影组，rkisp_stream是具体的摄像机。这样想，是不是清晰多了？

3.1 rkisp_device：整个ISP的“大管家”

先看老大——rkisp_device。它代表一个完整的ISP硬件设备。在RK3399、RK3288这些芯片上，每个ISP硬件单元对应一个这样的结构体。

struct rkisp_device {
    struct device *dev;
    struct v4l2_device v4l2_dev;
    struct media_device media_dev;
    struct rkisp_pipeline pipeline;
    struct rkisp_stream stream[RKISP_MAX_STREAM];
    void __iomem *base_addr;
    int irq;
    struct clk *clks[RKISP_MAX_CLKS];
    struct rkisp_match_data *match_data;
    spinlock_t slock;
    struct mutex lock;
    // ... 还有不少成员
};

这个结构体里，我重点说几个关键字段：

• dev：指向Linux设备模型中的device结构体。说白了，就是告诉内核“嘿，我在这儿呢”。
• v4l2_dev和media_dev：这是V4L2和Media Controller框架的接口。没有它们，用户空间就找不到这个设备。
• pipeline：这个很重要！它管理着ISP内部的数据流管道。
• stream：一个数组，每个元素代表一个视频流。为什么是数组？因为一个ISP可以同时处理多个流，比如主路和子路。
• base_addr：寄存器的基地址。所有硬件操作都通过它来读写。

我记得第一次调试时，发现中断一直不触发。查了半天，原来是irq号没注册对。嗯，这种低级错误，犯过一次就记住了。

3.2 rkisp_pipeline：数据流的“调度中心”

接下来是老二——rkisp_pipeline。它描述的是ISP内部的数据处理流水线。你想想看，图像数据从传感器进来，要经过DPCC（坏点校正）、BLS（黑电平）、LSC（镜头阴影校正）……这一整套流程，就是pipeline来管理的。

struct rkisp_pipeline {
    struct media_pipeline pipe;
    struct rkisp_device *dev;
    struct rkisp_stream *stream;
    struct v4l2_subdev *sensor;
    struct v4l2_subdev *mipi_csi;
    struct rkisp_isp_subdev isp_sd;
    struct rkisp_params_subdev params_sd;
    struct rkisp_stats_subdev stats_sd;
    bool streaming;
    // ...
};

这里有几个关键点：

• sensor、mipi_csi：指向实际的硬件子设备。pipeline负责把它们串联起来。
• isp_sd、params_sd、stats_sd：这三个是ISP内部的核心子设备。分别处理图像数据、参数配置、统计信息。
• streaming：一个布尔值，标记当前是否在推流。我曾经踩过一个坑：在streaming为true时修改了pipeline配置，结果系统直接挂了。所以，改配置前一定要检查这个标志位。

3.3 rkisp_stream：用户看到的“视频流”

最后是小弟——rkisp_stream。这个结构体直接面向用户空间。应用程序通过V4L2接口打开一个video节点，背后就是这个结构体在工作。

struct rkisp_stream {
    struct rkisp_device *dev;
    struct video_device vdev;
    struct vb2_queue buf_queue;
    struct rkisp_buffer *curr_buf;
    struct list_head buf_list;
    enum rkisp_stream_mode mode;
    struct v4l2_pix_format_mplane pixm;
    struct v4l2_rect crop;
    // ...
};

重点字段解析：

• vdev：V4L2视频设备节点。用户空间通过/dev/videoX操作的就是它。
• buf_queue：缓冲区队列。应用程序通过QBUF/DQBUG来管理缓冲区，底层就是操作这个队列。
• curr_buf：当前正在处理的缓冲区。中断处理时，我们会把数据填到这个缓冲区里。
• mode：流模式。是RAW数据还是YUV？是主路还是子路？这个字段决定了后续的处理逻辑。
• crop：裁剪区域。用户可以通过V4L2的S_SELECTION来设置，只输出感兴趣的区域。

3.4 三个结构体的“三角关系”

好了，三个结构体都介绍完了。但它们之间到底怎么配合的？我画了一张图，帮你理清关系。

从这张图可以看出：

1. rkisp_device是顶层容器。它创建并管理pipeline和stream。
2. rkisp_pipeline负责数据流的内部处理。它把sensor、MIPI CSI、ISP子设备串联成一条完整的处理链路。
3. rkisp_stream是用户空间的接口。应用程序通过它来配置参数、获取图像数据。
4. 数据流向是：sensor → pipeline处理 → stream输出给用户。

3.5 实际项目中的“三角关系”

我在一个项目中遇到过这样的场景：客户要求同时输出RAW和YUV两个流。RAW用于算法处理，YUV用于预览显示。

当时我配置了两个rkisp_stream实例：

• stream[0]：模式设为RKISP_STREAM_RAW，输出RAW12数据。
• stream[1]：模式设为RKISP_STREAM_YUV，输出YUV420数据。

但问题来了——两个stream共享同一个pipeline。pipeline里的ISP模块只能以一种配置运行。RAW流需要关闭一些图像增强模块，而YUV流需要开启。怎么办？

我的解决方案是：在pipeline里增加一个mode字段，根据当前活跃的stream动态切换配置。当只有RAW流时，pipeline走“直通”模式；当YUV流加入时，pipeline切换到“完整处理”模式。

3.6 总结一下

这三个结构体，说白了就是ISP驱动的骨架：

结构体	角色	核心职责	关键字段
rkisp_device	导演	管理整个ISP硬件，生命周期控制	dev, v4l2_dev, pipeline, stream[]
rkisp_pipeline	摄影组	数据流调度，子设备串联	sensor, isp_sd, params_sd, streaming
rkisp_stream	摄像机	用户接口，缓冲区管理	vdev, buf_queue, mode, crop

嗯，这三个结构体搞明白了，RKISP驱动的框架你就掌握了七七八八。剩下的就是各个子模块的具体实现了。下次我们聊ISP子设备的时候，你会发现，它们都是在为这三个核心结构体服务的。

可可精品资料库