📒 笔记文档

sensor：mos → ADC → csi → DPHY-TX

SOC：DCPHY-RX → MIPI-CSI → RKCIF → ISP → DRM

硬件层

	MIPI CSI-2 Sensor传感器						  MIPI协议	控制lane发送
感光传感器--> ADC转换 --> Bayer RAW像素(RAW/RGB) --> CSI2协议封装 --> DPHY --> MIPI线 -->SOC

SOC层

		   接收lane
MIPI线 -->  DPHY --> 各种转换 --> CSI2 HOST --> VICAP / CIF --> 各种方式 --> ISP

DPHY：对应设备树 csi2_dphy0，csi2_dphy1，csi2_dphy2

CSI2 HOST：对应设备树 mipi1_csi2，mipi2_csi2

VICAP / CIF：对应设备树 rkcif_mipi_lvds1

v4l2驱动

	V4L2框架		videobuf2内存管理		video设备节点
DMA中断通知 --> 缓冲队列入队/出队 --> /dev/videoX节点 --> 用户空间系统调用

用户层

	系统调用API		应用框架		业务场景
open/ioctl/mmap --> GStreamer/FFmpeg --> 显示画面/编码存储/RTSP推流/AI推理

第一部分：图1（端到端数据流全景图）逐级详解

这张图展示了从“光信号”到“应用画面”的物理与逻辑路径。

1. 摄像头硬件端（Sensor Board）

• 光信号 -> CMOS感光阵列 & ADC：外界光线打到CMOS传感器上，每个像素点根据接收光强产生模拟电压信号。**ADC（模数转换器）**立即将这些模拟信号转换为数字电平，形成原始的Bayer格式数字数据（每个像素点只包含R/G/B中的一种颜色分量）。
• RAW Bayer 像素数据：这是ISP（图像信号处理器）处理的“原材料”，也是最原始的无损数据，体积较大。
• MIPI CSI-2 打包器：传感器内部的逻辑电路按照MIPI联盟定义的CSI-2协议，将RAW数据封装成数据包。具体分为**长包（Long Packet）承载像素负载，和短包（Short Packet）**承载帧起始（FS）、帧结束（FE）、行起始（LS）等同步信号。
• D-PHY 发送器：将打包好的并行数据转换为高速差分串行信号（一般包含1对时钟线和多对数据线，如2-lane或4-lane），通过FPC排线传输给主控SoC。

2. SoC硬件端（接收与路由）

• D-PHY 接收器：SoC端对应的物理层接口，负责锁定时钟信号，并将高速串行数据重新解串为并行数据。这一步骤如果出现信号完整性（SI）问题，会导致数据错位或丢失。
• CSI-2 Host 解包器：解析MIPI协议，剥离包头，将有效的像素负载提取出来，并根据虚拟通道（Virtual Channel）ID将数据分发到不同的缓冲区。
• VICAP（视频捕获控制器）：这是RK平台承上启下的核心硬件模块。它负责将Host解包后的数据进行格式重整（如数据对齐、位宽调整），并且内置路由逻辑。它决定了数据是直接通过DMA搬运到内存（Bypass模式），还是送入ISP进行图像增强（ISP路径）。
• 数据路由选择（关键分叉点）：
  • 直通路径（Bypass）：适用于AI识别或深度感知场景。VICAP直接将RAW数据或Sensor输出的YUV数据通过**DMA（直接内存访问）**搬运到DDR内存中，应用程序直接拿原始数据做推理。此路径延时最低。
  • ISP处理路径：VICAP将数据流转发给ISP（图像信号处理器）。ISP硬件依次执行**黑电平校正（BLC）、镜头阴影校正（LSC）、去马赛克（Demosaic，将Bayer插值为全彩）、自动白平衡（AWB）、色彩转换（CCM）、Gamma校正、锐化、降噪（NR）以及宽动态（WDR）**等复杂运算。
• DMA 写入内存：无论是否经过ISP，最终处理完的数据帧都会由DMA控制器写入预先在内存中申请好的物理地址（即videobuf2的缓冲区）。写入完成后，DMA会触发硬件中断通知CPU。

3. Linux内核 V4L2 驱动层（软件调度）

• videobuf2 缓冲池管理：这是V4L2框架的内存管理核心。它在内核空间维护一个缓冲区队列，通过mmap（内存映射）、DMABUF（跨设备共享）或Userptr（用户指针）三种模式与用户空间交互。DMA将数据写入后，缓冲区状态会从VB2_BUF_STATE_DONE流转为VB2_BUF_STATE_QUEUED，等待用户取走。
• video_device 设备节点：最终生成用户空间可见的 /dev/videoX 节点。应用程序通过open()打开该节点，通过ioctl（如VIDIOC_QBUF入队、VIDIOC_DQBUF出队）来获得图像帧。
• Media Controller & v4l2_subdev（控制面）：图中虚线表示控制流。v4l2_subdev代表Sensor、ISP等子设备，驱动通过I2C总线下发寄存器配置给Sensor（如修改曝光值、帧率）。Media Controller则负责动态建立Pipeline（如Sensor -> CSI -> ISP -> videoX），确保数据流打通。

4. 用户应用程序层（最终使用）

• 系统调用（ioctl / mmap / poll）：应用通过标准Linux系统调用与 /dev/videoX 交互。poll或epoll用于等待帧就绪事件，避免CPU空转。
• 上层应用框架：实际开发中很少直接写ioctl，而是调用V4L2 Userpace API封装库，或者使用 GStreamer 的 v4l2src 插件、FFmpeg 的 avdevice 模块。在Android系统中则对接Camera HAL。
• 显示/编码/推流：拿到内存中的图像数据后，应用将其送去显示（DRM）、硬件编码（如H.264/H.265）或通过网络协议（RTSP/WebRTC）推流。

第二部分：图2（软件分层架构图）逐层详解

这张图侧重于操作系统内部“代码模块”的层级依赖，适合开发驱动或调试内核问题时查阅。

1. 用户空间（User Space）

• 应用/算法库：包括跑在ARM上的OpenCV推理程序、Qt显示界面等，它们不直接操作寄存器，只调用标准API。
• Android Camera HAL / RkAiq库：特指Rockchip提供的3A（AE/AWB/AF）算法动态库。该库在用户空间运行，通过私有的/dev/isp_params节点将3A计算出的参数（如曝光时间、增益、白平衡色温）实时下发给内核驱动，形成闭环控制。

2. 内核空间 - V4L2框架层（Kernel Space）

• 字符设备层：Linux将硬件抽象为文件，即 /dev/videoX 和 /dev/v4l-subdevX。应用的所有操作入口都在这里。
• V4L2核心层：这是标准Linux内核提供的通用框架代码。它负责解析ioctl命令码，并路由到对应的驱动回调函数（如.vidioc_streamon、.vidioc_s_fmt），同时管理poll事件通知机制。
• Media Controller（媒体控制器）：属于V4L2框架的进阶特性。它不允许应用随意使能硬件模块，必须严格按拓扑图绑定。例如，使用命令 media-ctl -l "'rkisp-isp':0 -> 'rkisp-resizer':0 [1]" 来强制指定数据流下一跳。
• videobuf2（VB2）：独立于V4L2核心的内存管理层。它适配不同的内存类型（连续物理内存或不连续内存），并提供ops回调给驱动，用于通知驱动“该给这块缓冲区填数据了”。

3. 内核空间 - RK平台子设备驱动（Platform Driver）

• Sensor驱动：通常遵循 v4l2_subdev 标准。核心工作是实现 .s_power（上电时序）、.s_fmt（设置输出分辨率/帧率）以及 s_ctrl（通过I2C写Sensor寄存器）。
• RK CIF（Camera Interface）驱动：负责管理CSI-2 Host和VICAP硬件。它申请DMA通道，配置MIPI数据通道映射（lane映射），并处理MIPI错误中断（如ECC/CRC校验失败）。
• RK ISP驱动：管理ISP硬件流水线。它不仅要配置硬件寄存器，还要处理ISP产生的中断（如帧结束中断、3A统计信息Ready中断），并将统计结果（Histogram/AE统计）通过特定的v4l2_event上报给用户空间的RkAiq库。

4. 硬件寄存器层（Hardware Layer）

• 这是物理上的硬件单元。驱动层通过 writel() / readl() 函数向这些硬件单元的寄存器地址写入控制值（如启动传输、配置DMA地址）。注意：ISP驱动的参数配置和CIF驱动的启动时机必须严格配合，否则会出现“DMA写到错误地址”导致系统内存被踩坏（Memory Corruption）的严重问题。

🔗 数据流关键节点对照总结（排查宝典）

为了帮你更好地将图文对照用于实际Debug，我把关键节点做了串联描述：