★ FEATURED ARTICLE 板子从贴片厂回来第一次上电串口停在一堆error日志面前另一个同事敲了一下午寄存器结果sensor ID还是读不到。这种场面我经历过太多次了。高通的camera sensor bring up说穿了就是把一个感光芯片从物理上焊在板子上变成软件里能出图的过程。它不性感甚至有点枯燥但它是整个camera项目的地基地基层面只要有一个坑没填平后面上层的效果调试、算法调试全是空中楼阁。这篇东西我想按自己这些年做高通平台sensor bring up的实际流程来写重点放在我自己会怎么做、为什么这么做上而不是把高通文档翻译一遍。无论你是刚接手camera驱动的新人还是被vendor灌了一堆代码、不知道怎么下手的集成工程师这篇应该都能对得上号。1. sensor bring up到底在链路的哪一环先搞懂全流程再动手1.1 一条数据从镜头到内存中间经过什么很多人上来就盯着驱动代码看我觉得这是错的。bring up的第一步不是看代码是理解数据通路。一个sensor输出的图像数据在高通平台上大致走这么一条路sensor感光 - MIPID-PHY或C-PHY- CSIDCamera Serial Interface Decoder- IFEImage Front End- DDR内存 - 后续的ISP处理、显示或编码。在camx架构高通从SM8250往后主推的camera框架里用户空间是camx内核空间是camera kernel driver两者通过v4l2子设备的方式对接。sensor本身在内核里体现为一个i2c client通过v4l2 subdev的方式注册进camera框架。所以Bring up这个阶段你实际上是在做三件事让sensor正常上电、时钟起振I2C能通。让sensor的ID能读到寄存器初始化序列能写进去。让sensor输出MIPI数据CSID能解析IFE能收下来最后在内存里形成一帧图像。这三件事是严格递进的。第一件不通后面全是白搭。我见过很多人卡在第二步就乱了阵脚开始怀疑EEPROM、怀疑AF、怀疑ISP tuning。其实都不用把链路这两个字记在心里按顺序排查80%的bring up问题都能很快定位。1.2 你手上必须有的三份资料做bring up之前先把手头的资料备齐。没有资料就开干等于闭着眼睛过雷区。第一份是sensor的datasheet。不是那种宣传用的brief是真正的register level的技术手册。重点看这几个章节上电时序图power on sequence、I2C地址配置、芯片ID寄存器地址和默认值、sensor输出分辨率与MIPI lane配置、推荐的初始化序列init sequence、PWDN/RESET引脚极性。第二份是高通的camera驱动文档内核里一般叫camera_kernel高通的文档库里会有对应的sensor bring up guide。需要重点理解的是msm_sensor驱动框架里subdev的注册流程以及dtsi里每个节点的含义。别急着全看先看懂sensor节点和eeprom节点就够了。第三份是你们自己板子的原理图。sensor部分要确认供电脚接了哪几路LDOGPIO的PWDN/RESET分别挂在哪个号上MCLK从哪来的I2C挂在哪条总线上有没有电平转换sensor的I2C地址有没有被硬件上下拉电阻改过。这三份资料齐了再开始碰代码。这一步省不掉省掉的后果就是后面反复看原理图确认引脚拉低效率。1.3 需要掌握的软件框架知识高通camera的驱动结构对新手来说确实不太友好但你要知道最终还是v4l2那一套。sensor子设备实现了一堆v4l2_subdev_ops核心是core里的s_power、s_streamvideo里的g_mbus_format等回调。你不需要从零写这些回调因为高通的msm_sensor驱动框架已经封装好了你只需要填好msm_sensor_subdev_info结构体。写好msm_sensor_v4l2_ctrl_ops里的power、sensor_init等操作。把sensor的初始化序列整理成i2c_conf_array数组。在dtsi里把电压、GPIO、I2C频率、lane数配齐。这套流程在高通平台上是高度模板化的。正因如此很多人的bring up其实是抄作业把别的sensor的驱动复制一份改改名字、改改地址、改改初始化序列就交差了。能用但一旦出了问题就抓瞎。我建议你至少把msm_sensor_power这个函数的调用链从头跟一遍搞清楚它控制电源和GPIO的顺序这样遇到上电时序引发的问题你能第一时间想到是不是这里跟datasheet矛盾。2. 点亮前的硬件核对原理图、电压和GPIO一个都不能猜2.1 从原理图开始核对供电和地拿到原理图先把sensor相关的电路圈出来。一般sensor有AVDD模拟供电、DOVDD数字IO供电、DVDD数字核心供电、AFVDDVCM马达供电如果有AF。我强调一遍供电电压必须精确匹配datasheet。比如IMX系列很多sensor的AVDD是2.8VDVDD是1.05V或1.2VDOVDD是1.8V。如果你把DVDD给了1.8V有些sensor会直接不工作有些会工作但发热异常、暗电流大出图一片噪点。别偷懒逐个量一下LDO的实际输出。另外注意有没有LDO的power-down pin没拉或者拉反了导致看似配了电压实际输出为0。这个用万用表就能测别跳过。DOVDD这里有个技术上的隐性依赖它决定了I2C的上拉电平。如果sensor的DOVDD是1.8VI2C上拉就必须接1.8V接了3.3V上拉会导致I2C电平不匹配轻则读ID偶尔失败重则长期工作损坏sensor。选型时一定要看sensor支持不支持1.8V的IO。2.2 GPIO分配表PWDN和RESET的极性最容易翻车然后是GPIO。原理图上找到sensor的PWDNpower down也叫XSHUTDOWN、RESET脚分别连到SoC的哪个GPIO记下GPIO编号。这两根线的极性一定要对照datasheet确认。我踩过的坑某些sensor的PWDN极性是0有效低电平进入power down而驱动或dts里默认却给了拉低为正常上电的逻辑。结果就是电都上了I2C却一直不通因为sensor根本不在工作状态。查这种问题最笨也最有效的方法就是拿示波器/万用表去量PWDN引脚的实际电压同时对比dts里配的gpio状态。如果量出来和预期相反就说明不是代码问题就是原理图接反了或极性搞反了。DTSI里需要注意高通的camera dtsi里GPIO通常用qcom,gpio-no-mux加gpios属性或者通过gpio-parent的pinctrl来配置默认状态。在配置pinctrl的时候除了功能选择还得注意把引脚配置成合适的上下拉和驱动电流特别是MCLK、I2C、MIPI差分对这些高速信号。I2C的SDA/SCL一般要配上拉MCLK要看sensor的时钟输入要求。2.3 I2C地址这里有个7位和8位的经典陷阱I2C地址是bring up里最经典的一个坑。sensor datasheet里通常写的是8位地址比如0x20左移一位变成0x40但驱动的代码里i2c_addr字段一般要求填7位地址。也就是说datasheet里看到0x408位代码里可能该填0x207位有的高通平台驱动框架会自动移位有的不会具体要看你用的内核版本和驱动写法。怎么确认很简单看驱动里访问sensor时的msm_camera_i2c_write函数最终通过i2c_transfer发出的地址到底是什么。用I2C工具比如i2cdetect扫描一下总线上sensor在哪个7位地址上有ACK响应两边一对齐就知道该填多少了。2.4 MCLK频率在dts里先按推荐值配MCLK一般24MHz、19.2MHz、13Mhz几种具体看平台和sensor搭配。高通老平台常见19.2MHz新一些的sensor用24MHz也很多。查datasheet里MCLK的工作频率范围以及推荐值然后在dts的sensor节点里把qcom,mclk频率配好。MCLK这块有个比较容易忽略的点sensor对MCLK的上升沿/下降沿触发方式可能不是默认的有的sensor要求配置时钟边沿qcom,clock-rates和clk的相位如果配错sensor也能工作但可能出图下面有一半是花屏排查起来很费劲。所以遇到怪异现象别急着怀疑初始化序列先查时钟沿。3. 点亮感光芯片从PWDN拉低到ID成功读回3.1 先把最小驱动骨架搭起来在这个阶段先不追求完整功能只求能读ID。从高通camera kernel的msm_sensor框架里找一份和你这颗sensor最接近的代码同型号系列的、或者相同封装的复制一份改这几处sensor_info里的sensor_name要和dtsi里的节点名匹配。sensor_i2c_addr按2.3节确认过的地址填。sensor_id_info里的sensor_id_reg_addr和sensor_id务必对照datasheet注意有些sensor有多个ID寄存器module ID、chip ID要全对上。初始化序列先用datasheet里的recommended setting后面再按实际效果微调。供电、GPIO配置按dtsi里你配好的来驱动里的power_setting要跟dtsi一致或者选择只通过dtsi控制。把这几样改好编译进内核在串口里观察驱动probe的日志。这里有两条路如果驱动初始化时就会读ID日志里直接能看到ID是否匹配如果平台是延迟探测camx在open时再创建sensor设备那你得用camx侧的测试工具触发。3.2 串口日志和I2C工具双管齐下如果串口里没有报ID相关的错误或者压根没进到你写的驱动逻辑里先用内核的I2C工具直接验证硬件通不通。Android系统上常用i2cdetect -y -r bus扫一下sensor挂载的总线。如果sensor的地址能被扫到说明I2C物理层面是通的。扫不到怎么办按这个顺序排查供电电压是否到位——用万用表量sensor各供电引脚的电压。PWDN/RESET电平是否让sensor处于工作状态——对照datasheet量电平。MCLK有没有波形——示波器看频率是否正常、幅度够不够。I2C地址是不是被硬件改了——看原理图上有没有把地址线拉高拉低。I2C总线本身通不通——换别的设备地址扫一下排除总线挂死的可能。这五步走完99%的完全无应答问题都能定位。记住硬件问题的排查要拿仪器不要靠猜。3.3 ID能读到但初始化和probe报错ID能读出来说明I2C通路没问题了。这时候如果probe还是报错大概率在供电时序或PWDN/RESET时序上。看sensor datasheet的上电时序图它一般会标这几个时间参数t0AVDD、DOVDD、DVDD上电之间的间隔。t1各路电源稳定的时间。t2reset释放到I2C可访问的时间。t3MCLK起振和reset释放的先后顺序。高通的msm_sensor_power函数里会按你配置的power_setting数组依次执行操作。你要做的就是对照datasheet的时序图核对你dts或驱动里配置的每一步的电压和延时是否满足要求。有些sensor要求MCLK先起再释放reset有些要求reset释放100ms后才能读写寄存器。如果配置顺序反了ID读取可能不稳定或者能读但后面出图异常。示波器在这个阶段是最好的朋友。抓MCLK、RESET、PWDN、I2C SCL/SDA几路信号对照datasheet的时序图逐项核对。3.4 一个真实的ID读取失败排查过程讲一个我自己的case。某项目的OV系列sensorI2C地址扫描能扫到但驱动读ID一直失败。我拿示波器量了MCLK频率正常量了RESET拉高PWDN拉低。看起来都没问题。后来仔细看datasheet发现这颗sensor的PWDN带内部下拉外部没有上拉时即使驱动没配置它也是低电平。而驱动代码里PWDN配的是拉高进入工作模式所以看起来没问题。但真正的问题在别处RESET引脚虽然拉高了但是dtsi里pinctrl把RESET引脚配置成了无上拉而外部也没有加上拉电阻导致RESET实际电平浮空不稳定的高电平导致sensor偶尔能响应、偶尔不能。处理方式在pinctrl里给RESET引脚加上拉并把RESET的初始状态强制拉低一段时间再拉高问题就消失了。这个坑很典型说明看起来对不等于电学上对浮空引脚的万恶之源。4. 驱动初始化序列与MIPI参数对齐把数据流跑通4.1 初始化序列什么时候全量灌进去ID读到了probe通过了接下来sensor需要被初始化才能出图。初始化序列是sensor厂商在datasheet里提供的一长串寄存器配置一般从几百行到上千行不等。它设定sensor的输出分辨率、帧率、增益、曝光范围、MIPI lane数、数据速率、图像翻转等等。要注意不同vendor给初始化序列的习惯不一样。有的给的是stream on前必须写入的有的给的是上电后马上写入的一组基础配置stream on时再写切换分辨率相关配置。在高通camx架构下sensor驱动里有init和stream_on两个阶段的寄存器操作。你拿到厂商给的序列要分清哪些属于init阶段哪些属于stream_on阶段。我自己采用的方法把初始化序列按寄存器地址值的格式整理好生成一个group设置先在测试工具里手动灌一遍确认sensor能正常输出MIPI信号再固化到驱动里。这样如果后面出问题方便单步调试而不是在整包序列里大海捞针。4.2 MIPI lane数和速率怎么算初始化序列里有一组关键参数决定MIPI输出是否正常输出的分辨率width×height、帧率fps、bits per pixel、lane数。这些参数直接决定MIPI的差分信号速率。MIPI data rate的计算公式data_rate width × height × fps × bpp / lane数举例1080P1920×1080、30fps、10bit RAW、4 lane。1920 × 1080 × 30 × 10 / 4 155.52 Mbps per lane。注意这只是像素数据的净速率MIPI还有协议开销每行有帧头帧尾所以实际传输速率要比这个高一些一般乘以1.1~1.2的系数。sensor datasheet里一般会直接给出推荐的MIPI速率你不一定能自己算但要能校验厂商提供的值是否合理。在CSID侧高通的驱动会根据dts里配的lane数和数据速率来设置接收端的时钟参数。如果lane数或速率配错了常见现象就是I2C正常、驱动probe正常、init序列正常但就是没有数据帧进内存或者有中断但图像一半花、满屏横条纹。4.3 MIPI差分信号的物理检查如果初始化序列和参数都对还没有数据用示波器看MIPI数据lane的差分波形。两个关键点第一差分幅度够不够。MIPI D-PHY的HS模式差分摆幅典型值是约200mV具体看接收端要求如果PCB走线太长或匹配电阻有问题幅度会衰减到接收端阈值以下直接收不到。用示波器看差分信号的峰峰值低于sensor spec就要查硬件。第二clk lane的连续时钟波形。MIPI有一对时钟lane在LP模式会间歇性工作进入HS模式后是连续时钟。如果clk lane上没有连续时钟输出说明sensor侧根本没进入HS模式问题在初始化序列没生效或者sensor没被正确触发stream。4.4 CSID与IFE侧的状态确认到CSID这一层高通驱动里会有寄存器计数中断。串口日志里搜CSID、 IFE相关的关键词看有没有错误中断比如csid_irq报错、IFE reset等。如果CSID这边有持续的错误中断除了检查MIPI物理信号还要检查dts里CSID的时钟频率配置qcom,cam-csi相关的时钟开销MIPI速率太高而CSID时钟不够会导致解析不过来。数据从CSID进IFE后IFE要把数据落到内存。这个阶段如果报错常见的是带宽不足或内存对齐问题。高通平台里这个和camnoc、qos带宽配置有关如果出问题观察串口里的带宽bw相关报错同时检查camera dtsi里的qcom,cam-bw配置。5. 出图后的验证与排错分辨率、格式、数据正确性5.1 先出图别管画质数据流跑到内存里已经成功了一大半。这时候把图像数据导出来看一下。平台不同取图的方式不同有的可以在camx的测试工具里dump raw图有的是走vendor的test app。重要的是先别管画质好不好先确认图像内容是对的那一帧画面而不是满屏雪花或整屏偏色。出一个纯色场景的图然后慢速摆动镜头看画面内容是否相应变化。如果内容跟着动恭喜链路全通了。5.2 图像异常的第一轮分类排查我归纳一下最常见的几类图像问题见到现象直接对号入座现象大概率原因排查方向全黑/全灰没有细节sensor未正确曝光/增益为0或数据全为0检查stream on时增益、曝光寄存器满屏雪花噪点MIPI信号质量差或速率不匹配量MIPI差分幅度、检查lane数配置图像有条纹/斜纹MIPI速率与CSID时钟不匹配核对dts里的时钟配置和lane速率画面一半暗一半亮曝光读取时序错位或sensor内部配置错误检查同步寄存器、帧率配置颜色明显不对bayer格式/位深不对或白平衡初始值问题核对bayer order、位深参数画面倒置/镜像sensor寄存器方向配置错误查datasheet的mirror/flip寄存器这里强调bayer order的坑RAW图里RGGB、BGGR、GRBG、GBRG是四种不同的排布。高通CAMIF侧内核或者camx侧有配置项搞反了之后图片在软件里做demosaic后颜色会偏得离谱但仔细看还是能看出物体轮廓。如果你看到颜色异常但能辨认画面先怀疑bayer order、RGBIR配置而不是直接怀疑ISP tuning。5.3 曝光、增益、帧率的验证方法出图正常后验证sensor的基本控制能力。在调试工具里手动改曝光时间观察图像亮度是否变化手动改增益观察是否变亮且伴随噪点增加。这两项验证通过才说明sensor处于完全可控状态。另外验证一下帧率用tools或者perf统计sensor的实际输出帧率和初始化的目标fps对比。如果实际帧率明显低于目标值最常见的是MIPI速率不足或者sensor内部输出时间过长。如果实际帧率高于目标值可能就是分辨率/lane配置没生效。5.4 和tuning/效果团队的交接从你们团队分工来看bring up做完后下一步是给效果调试tuning团队交一个干净的环境。你需要确认不同分辨率切换正常预览分辨率、拍照分辨率、视频分辨率。出图的帧率稳定。曝光、增益、白平衡基础控制可以正常手动调节。数据格式和平台期望一致导出golden raw方便后续离线tuning。这几个点确认完bring up这件事才算真正画上句号。后面再有画质问题那是tuning的事不归你管了。6. 我踩过的三个最隐蔽的坑以及怎么避免6.1 看起来配置了但没生效的gpio初始状态高通的sensor子设备链路上GPIO的控制存在配置和状态两件事pinctrl配置管复用关系和上下拉v4l2的power回调管实际电平。如果你在pinctrl里把某个GPIO配成output-low但在驱动的power on逻辑里没有显式拉高那sensor可能就一直处于异常状态。更隐蔽的是有的高通平台里pinctrl的default状态初始化和camx的sensor power on时序不在同一个阶段执行中间有一个GPIO默认态窗口。如果某些sensor上电时序要求RESET初始保持低电平并延时而pinctrl默认把它拉高了一上电sensor就进入未定义状态后面怎么拉都没用。我的经验别只依赖pinctrl在sensor驱动的power_setting里显式地把RESET/PWDN的每一步都写清楚包括电平状态和延时时间不要偷懒省略。6.2 同一颗sensor在平台A可以、平台B不行同样一颗sensor之前在一个高通平台比如SM8250上没问题拿到新平台比如SM8550上就出图异常。这种情况非常常见。原因往往不是sensor变了而是新平台的底层驱动框架变了比如camx版本不同、sensor驱动接口不同、时钟策略不同。遇到这种情况别照抄旧代码去新平台的参考驱动里找同类的sensor驱动作为模板把旧驱动里的关键参数初始化序列、供电电压、lane数、速率迁过去但框架逻辑要跟着新平台走。高通从老内核4.x到新内核5.x/6.x的camera驱动变化很大接口要重对。6.3 日志是定位问题最锋利的刀排查bring up问题的时候别急着改代码猜原因先把日志抓全。串口日志有几个关键字需要特别关注msm_sensor、CAM-SENSOR、cam_sensor、csid、ife、i2c、CCI。每条报错都贴到源码里跟一下找到真正报错的代码路径。我印象很深的是一次莫名其妙的I2C fail日志里报CCI write fail代码查了半天没问题最后发现是I2C总线被别的器件拉死了sensor地址永远NAK。这种问题靠日志定位到发生在哪条总线还不够还得顺着总线往下查。I2C总线上的每个设备都可能有嫌疑用示波器量SCL/SDA的波形看到SDA一直被拉低问题就锁定了。7. 从bring up到量产你还缺哪些功课7.1 EEPROM和Actuator的联动确认现在的sensor模组特别是手机摄像头基本都带EEPROM里面存了AF校准数据、镜头 shading 校准数据等。bring up阶段你只点亮了sensor本体但如果EEPROM没调通后续拍照对焦和画质校准会有大问题。EEPROM一般挂在同一条I2C总线上有一个独立的从设备地址。点亮sensor之后紧接着就是把EEPROM也读通确认能从里面读出有效的校准参数。如果EEPROM的驱动加载失败camera整体打不开也是很常见的。注意EEPROM的地址有时会跟sensor的地址冲突要看模组厂给的地址分配。另外EEPROM一般有两种接入方式一种由sensor的I2C透传一种直连主控。前者需要在sensor初始化序列里把透传模式打开后者则没有这个负担。这块务必看原理图确认别默认为直连。7.2 多sensor场景下的资源冲突平板、多摄项目会遇到两个sensor共用一组MCLK/GPIO的情况或者两个sensor挂在同一条I2C总线上但地址冲突。bring up完单个sensor之后要花时间验证共存场景两个sensor同时上电或者快速切换是否会出现GPIO被占用、I2C干扰的问题。高通平台对多摄有专门的资源管理机制sensor驱动里也有sensor_share的逻辑。但说实话真正稳的方案还是从硬件上规避——每颗sensor的供电和GPIO尽量独立I2C地址不要冲突。如果硬件已经定了没法改那就在驱动里确保每次上电前先释放前一颗sensor的全部资源GPIO释放成高阻、电源断开切换后再初始化新的。7.3 量产前必做的压力验证Bring up通过只是起点量产前的验证更重要。我建议至少做三轮第一轮长时间老练测试连续开camera超过8小时观察是否出现I2C无响应、sensor挂死、内存泄漏。高通的camera框架里偶尔有人反映用着用着camera打不开多半是sensor或eeprom的驱动在某次切换时没做干净导致的老练测试能把这些隐患逼出来。第二轮分辨率切换压力测试预览和拍照来回切换几千次检查是否每次都能正常出图。重点看切换后有没有偶发的高帧率、卡顿、黑帧。这个阶段出现的问题定位起来最花时间因为它需要概率复现。第三轮功耗验证关注sensor待机电流和预览电流和竞品对比或者和规格书对比。如果功耗明显偏高检查sensor有没有进入正确的standby模式、MCLK在stream off之后有没有正常关闭、GPIO在suspend状态下的电平是否正确。这些细节直接影响整机续航表现很多项目到量产前才追功耗那时再改sensor驱动往往牵一发动全身。好了整个过程就是这么走下来的。回过头看bring up最大的挑战不是哪一步有多难而是你要一直保持链路思维永远知道现在卡在哪个环节、下一个环节是什么然后拿示波器、拿日志、拿datasheet去锚定真相而不是靠猜。把上面这些流程走完一遍你对高通camera驱动的理解会扎实很多后面再看camx、再碰ISP tuning都会有个很好的底子在。
阅读完成 · 觉得有帮助？
