3A工作原理
AF(Auto Focus)
AE(Auto Exposure)
问题：sensor的曝光时间和gain是N+1帧生效，d gain是N+1帧才生效，这个驱动是怎么做同步的？
一、为什么曝光和 Gain 要"隔帧生效"？
这是 CMOS 传感器的硬件流水线决定的，不是驱动的特殊设计：
| 阶段 | 描述 |
|---|---|
| 曝光阶段 | 像素在某帧的行消隐期开始积分（充电） |
| 读出阶段 | 积分完成后，行数据逐行被读出到模拟前端 |
| 寄存器锁存 | 大多数 sensor 在 VSYNC 上升沿 将影子寄存器（shadow register）锁存到工作寄存器 |
所以，你在 Frame N 期间通过 I2C 写入的值，要到 Frame N+1 的 VSYNC 才会被 latch（锁存） ，进而在 N+1 帧曝光时生效。这是曝光时间（ET）和 Analog Gain（AG）的典型 1 帧延迟。
二、A Gain 和 D Gain 为什么延迟不一样？
这是问题的核心。用一张流水线结构图来说明：
三、驱动层怎么做 AG/DG 同步？
由于 ET+AG 延迟 1 帧，DG 延迟 2 帧，如果 3 个值直接对应同一帧的 AE 计算结果一起写，输出图像亮度会出现 1 帧的"闪烁"或"震荡"（DG 提前生效，但 ET+AG 还没生效）。驱动有两种主流处理策略：
四、驱动代码层面的具体实现
在 Linux/Android Camera HAL 驱动框架（V4L2 / Qualcomm、MTK 等平台）中，同步逻辑通常这样实现：
/* 典型的 sensor 驱动曝光/gain 写入逻辑（伪代码） */
struct sensor_exp_param {
u32 coarse_int_time; // 曝光时间（行数）
u32 analog_gain; // AG 寄存器值
u32 digital_gain; // DG 寄存器值
u32 frame_id; // 本次 AE 结果对应的 frame id
};
/* 驱动维护一个延迟队列 */
struct sensor_exp_param g_pending_params[3]; // 至少 2 帧缓冲
/* VSYNC 中断回调 / SOF（Start of Frame）回调 */
void sensor_sof_isr(u32 frame_id)
{
/* --- 策略一：延迟写入 DG --- */
// 1. 本帧（frame_id）写入 ET + AG（1帧后生效）
sensor_write_reg(ET_REG, g_pending_params[frame_id % 2].coarse_int_time);
sensor_write_reg(AG_REG, g_pending_params[frame_id % 2].analog_gain);
// 2. 写入上一帧的 DG（上帧的 DG 本帧+1 才生效，与上帧 ET/AG 对齐）
sensor_write_reg(DG_REG, g_pending_params[(frame_id - 1) % 2].digital_gain);
/* --- 策略三：group hold（如果 sensor 支持）--- */
// sensor_write_reg(GROUP_HOLD_START, 0x01);
// sensor_write_reg(ET_REG, ...);
// sensor_write_reg(AG_REG, ...);
// sensor_write_reg(DG_REG, ...);
// sensor_write_reg(GROUP_HOLD_END, 0x01);
}关键点：SOF 中断是写入时机的核心。 驱动必须在 VSYNC/SOF 中断触发后、下一行数据读出之前完成 I2C 写入，否则会错过 latch 窗口，延误到下一帧。
五、不同平台/sensor 的差异
| 因素 | 说明 |
|---|---|
| ET/AG 延迟 | 绝大多数 sensor 为 1 帧，少数特殊模式（如 HDR）为 2 帧 |
| DG 延迟 | 通常比 ET/AG 多 1 帧，即 2 帧，但具体看 sensor datasheet |
| Group Hold | Sony IMX、OmniVision OV、Samsung 等主流 sensor 普遍支持 |
| 影子寄存器 | latch 时刻可能是 VSYNC 上升沿或下降沿，也有在帧末 HREF 空闲期 latch 的，需确认 |
| AE 算法补偿 | 高层 AE 算法需知道每个参数的延迟帧数，才能做正确的预测控制（predictor），否则 AE 调节会振荡 |
总结一下：ET 和 AG 通常隔 1 帧生效，DG 通常隔 2 帧生效；驱动的同步处理核心是在 SOF 中断里按帧号管理写入时序，或者利用 sensor 的 group hold 机制由硬件保证原子 latch。
AWB(Auto White Balance)
HDR高动态处理流程
问题：长曝光的帧和短曝光的帧是一行长曝、一行短曝还是一帧长曝、一帧短曝？
MFNR多帧降噪处理流程
问题：MFNR和HDR是不是都是在YUV域的？
不完全是，这是一个很常见的误解。两者处理域各有不同，而且随着算法演进还在变化。
MFNR（多帧降噪）
传统实现：YUV 域
- 早期 MFNR 确实在 YUV 域做帧对齐 + 融合
- 流程：RAW → ISP → YUV → 多帧对齐（ME/MC）→ 加权融合 → 输出
现代主流实现：RAW 域
- 高端手机（Pixel、iPhone、小米等）的 MFNR 已大量转移到 RAW 域
- 原因：RAW 域噪声模型更纯净（泊松 + 高斯），融合前不经过 Demosaic/色调映射等非线性处理，信噪比提升更彻底
- 流程：多帧 RAW → RAW 域对齐 → RAW 域融合 → 一次 ISP → 输出
所以现代 MFNR 更多是 RAW 域，YUV 域 MFNR 属于算力受限时的折中方案。
HDR（高动态范围）
HDR 的情况更复杂，因为它有多种实现路径：
| 实现方式 | 处理域 | 说明 |
|---|---|---|
| 多曝 RAW 融合（Multi-exposure RAW merge） | RAW 域 | 长/短曝 RAW 在进 ISP 前融合，是质量最好的做法 |
| Sensor 内 HDR（SHDR / DOL-HDR） | Sensor 内部 | 同帧内长短曝隔行交织，sensor 内部或 ISP 前端完成融合 |
| 软件 HDR（多张 YUV 融合） | YUV 域 | 低成本方案，质量较差，早期低端机常用 |
| Tone Mapping | YUV / HDR Linear 域 | 严格来说是 HDR → SDR 的映射，通常在 YUV 或 HDR10 线性域 |