094、同一平台多款sensor的驱动框架设计——基于设备树与抽象层的可扩展架构在量产中的实践
发布时间：2026/8/19 15:45:55
094、同一平台多款sensor的驱动框架设计——基于设备树与抽象层的可扩展架构在量产中的实践去年夏天，产线反馈某款机型在老化测试中偶发黑屏，复现概率不到千分之一。拉回主板接上串口，log里只有一条孤零零的“mclk enable failed”，再往前翻，sensor的ID读取正常，电源时序正常，就是MCLK起不来。查了半天，最后发现是驱动里写死了sensor的reset引脚——换了一颗pin-to-pin兼容的sensor，硬件上把reset挪到了另一个GPIO，设备树里也改了，但驱动里还有一处硬编码的gpio_set_value，直接操作了旧引脚。这种问题，量产线上遇到一次就够你喝一壶。今天聊的这套驱动框架，就是当年被这种问题逼出来的。同一平台，三款sensor，两套摄像头模组，一个前置一个后置，加上一颗深度摄像头，总共五套组合。如果每来一颗新sensor就复制一份驱动，改几个寄存器地址，那代码仓库迟早变成垃圾场。更麻烦的是，平台升级——比如从瑞芯微RV1126换到RV1106，或者从高通SM8250换到SM8350——整个驱动层要重写，那这个项目基本就废了。先看设备树怎么设计。别把sensor当成一个孤立的节点，它挂在I2C总线上，有自己的电源域、时钟域、复位逻辑。设备树里要表达的是“这颗sensor在这个板子上怎么接”，而不是“这颗sensor是什么”。所以节点里放的是reg（I2C地址）、reset-gpio、pwdn-gpio、mclk-index、avdd-supply、dovdd-supply、dvdd-supply这些物理连接信息。至于sensor内部寄存器序列、曝光增益映射表、HDR模式切换逻辑，这些跟硬件连接无关的东西，一律不放设备树。/
)
)
)
