3. Sensor驱动与RAW图采集
Sensor驱动，说白了就是让摄像头芯片听话的那层软件。我刚开始做ISP时，总觉得驱动是硬件工程师的事，直到有一次RAW图死活采不到正确数据，才发现驱动和ISP的配合有多关键。
这一章，我们聊聊Sensor驱动的框架、RAW图的格式，还有DMA传输和帧缓存管理。嗯，都是实战中绕不开的硬骨头。
3.1 Sensor驱动框架
Sensor驱动一般分三层：硬件抽象层（HAL）、内核驱动层和设备接口层。我习惯把这三层想象成「翻译官」——把Sensor的硬件信号翻译成系统能理解的数据。
| 层级 | 职责 | 常见接口 |
|---|---|---|
| HAL层 | 封装Sensor配置、曝光、增益控制 | V4L2、I2C |
| 内核驱动层 | 管理寄存器读写、中断处理 | I2C、SPI、GPIO |
| 设备接口层 | 提供MIPI CSI-2或LVDS物理连接 | MIPI D-PHY、LVDS |
我在项目中遇到过最坑的事：Sensor驱动里I2C时序没调好，导致曝光参数写进去，Sensor根本不响应。查了两天才发现是时钟频率设高了，Sensor跟不上。
注意：Sensor驱动初始化时，一定要先读Sensor的ID寄存器确认通信正常，再往下走配置流程。跳过这一步，后面所有调试都是白费。
3.2 RAW图格式解析
RAW图是什么？就是Sensor直接输出的原始数据，没经过任何ISP处理。每个像素点只记录一个颜色通道的亮度值，通过Bayer阵列排列。
常见的Bayer模式有四种：
- RGGB：第一行R、G，第二行G、B
- BGGR：第一行B、G，第二行G、R
- GRBG：第一行G、R，第二行B、G
- GBRG：第一行G、B，第二行R、G
你想想看，如果ISP的demosaic模块不知道当前Sensor用的是哪种Bayer模式，出来的颜色就全乱了。我见过有人把RGGB的Sensor当成BGGR处理，结果画面偏紫得一塌糊涂。
关键点：RAW图的位深通常是10bit、12bit或14bit。存储时要注意对齐方式——10bit数据常用5字节存4个像素，12bit数据用3字节存2个像素。别搞错了。
3.3 DMA传输与帧缓存管理
Sensor采集的RAW图数据量很大。以1080p、12bit为例，一帧数据大约是：1920×1080×12/8 ≈ 3.1MB。如果每秒30帧，就是93MB/s的数据流。CPU根本扛不住，必须用DMA。
DMA传输的核心是帧缓存管理。我一般用双缓冲或环形缓冲方案：
- 双缓冲：两个缓存区，一个给DMA写，一个给ISP读，交替使用。简单可靠，适合低延迟场景。
- 环形缓冲：多个缓存区组成环，DMA按顺序写，ISP按顺序读。吞吐量高，但要注意读写指针不能撞车。
我曾经在一个项目中用了环形缓冲，但没处理好指针同步，结果DMA写满了缓存，ISP还没读完，直接覆盖了未处理的数据。画面出现撕裂，查了三天才发现是缓存深度不够。
我的建议：帧缓存大小要按最大分辨率+对齐要求来分配。比如Sensor输出1920×1080，但DMA可能要求每行对齐到32字节，那实际每行就是1920×2字节（16bit）对齐到32的倍数，算清楚再分配内存。
3.4 知识结构图
下面这张图概括了Sensor驱动到RAW图采集的完整流程：
3.5 实战避坑指南
做Sensor驱动和RAW图采集，有几个坑我踩过，分享给你：
- Sensor上电时序：不同Sensor对上电顺序有严格要求。先供电、再给时钟、最后拉复位。顺序错了，Sensor可能不工作或输出异常。
- MIPI Lane速率匹配：Sensor输出的MIPI Lane速率要和SoC接收端匹配。我遇到过Sensor输出1.2Gbps/Lane，但SoC只支持1Gbps，结果画面全是噪点。
- 帧同步信号：VSYNC和HSYNC的极性要配置正确。搞反了，DMA采集的帧起始位置就错了，画面会偏移。
- 缓存对齐：DMA传输的起始地址和每行字节数，通常要求对齐到32字节或64字节。不对齐，DMA会报错或传输乱序。
血的教训：我曾经在调试时，Sensor输出正常，DMA也正常，但ISP就是收不到完整帧。最后发现是帧缓存地址没对齐到Cache Line，导致DMA写完后Cache没刷新，ISP读到了旧数据。加个Cache Flush就好了。