Android Camera 驱动 读取摄像头ID失败问题、低温下Camera打开花屏或者读不到id、概率性读取不到id

• 底层驱动读不到摄像头的ID，可以从以下几个方面做检查

• 首先检查硬件方面，多拿几个摄像头模组来做试验。因为会存在打样模组有问题的情况，在原理图上对清摄像头的各个脚是否都对应上了、模组是否都扣好等。这个是硬件层面上的。

• 第二检查I2C地址是否正确，如MTK平台的基本都是以7位地址的方式操作的。既是偏移一位的。最后是要看看模组的规格书，确认器件的I2C地址

• 第三就要看摄像头的上、下电时序这一块。如MTK平台的，它在这个文件里实现：mt6737_65_a_n_mp1\kernel-3.18\drivers\misc\mediatek\imgsensor\src\mt6735\camera_hw\kd_camera_hw.c。不同厂家的模组它的上下电时序是有所差别的，其实在你为系统添加摄像头的时候这个上下电时序就加进来了。上电时序也要参考模组规格书去写

• 如果以上的都检查完了，都没问题，那么开始检查CMMCLK，一般会有两路CMMCLK。前后摄像头各走一路，我们需要看一下前后摄分开走mclk的还是共用一路的。我们在kd_camera_hw.c这文件里的
  kdCISModulePowerOn 和 else { /* power OFF */ 里，可以看到了有类似于如下的函数调用：

这里就是根据pinSetIdx来打开或关闭MCLK1 或者 MCLK2。需要注意两个点

mt6737_65_a_n_mp1\vendor\mediatek\proprietary\custom\mt6735\hal\D1\imgsensor_src\cfg_setting_imgsensor.cpp
。在这个文件里有个 MINT32 getSensorMclkConnection(EDevId const eDevId)
这个函数，要看看这里有没有被写成前后摄共用MCLK了。最好是用示波器去量过，确定它是有信号输出。

还有就是要用示波器量一下MIPI信号，看看主控有没有输入信号，以防万一。

如以上都检查完了，都没问题。但还是读ID失败的话，那我们就要看一下I2C的通道是否配置正确。因为主控一般都会有好几路I2C，完成了这6项的检查基本都会找到问题了，一定要配合抓串口log去调试、解决问题。

低温下Camera打开花屏或读不到id

问题模组：三星s5k4h7模组

模组厂：光阵

现象：低温-10°存储1个小时，开机后，第一次打开摄像头，多个模组出现花屏问题以及Camera读不到id问题，

花屏问题的机器，第二次或者第三次打开后就好了，

读不到id的机器，第二次重启系统，就正常了

现象截图

 

问题如下：

低温下Camera花屏问题，，针对低温花屏问题：第二次或者第三次打开后预览画面正常

低温下Caemra读不到id问题，，针对低温读不到id问题：第二次或者第三次打开，或者再次重启就好了

低温下有问题，正常温度下，没有这种现象，和硬件有关系。低温下供电不稳定，在不稳定的低温下，某些器件没法正常工作

排查方向

软件检查，对比软件最近是否有与相机相关的改动，回退旧版本进行验证

版本回退 看以前版本是否出现问题，增加实验数量，统计概率

验证发现，新旧版本出现问题比例差不多

去除Isc补偿

软件编译了一版去掉加载后摄OTP的程序，验证一台花屏的机器好了

固定绿屏问题，烧回工程样机程序没问题，与工程样机程序相比，批量程序增加了OTP LSC，临时编译一版关闭LSC程序验证绿屏问题消失

将关闭LSC的版本烧入低温花屏的机器，验证没问题，但是打不开摄像头的机器烧入该版本无效

取消后摄摄像头BTB上的泡棉验证，无效

由于打不开的是前摄，所以更换前摄验证，无效

时序检查，确认是否低温下时序发生变化

电源检查，确认是否低温下电源发生变化

• 总结

低温情况下，LDO工作不稳定，导致给DVDD的供电不足1.2V，因此造成花屏或者读不到ID问题

LDO即low dropout regulator，是一种低压差线性稳压器，我们用的是1.2V的LDO。

pm8916_s3提高在启动camera时，拉高到1.5v，（原先是1.4v），在低温下不稳定！拉高后，低温下的供电如下：

kernel/arch/arm/boot/dts/qcom/项目.dtsi

kernel/arch/arm/boot/dts/qcom/msm8916-regulator.dtsi

rpm_proc/core/systemdrivers/pmic/config/msm8909/pm8916

– {300, 0, PM_ACCESS_ALLOWED, PM_ALWAYS_ON, PM_NPA_SW_MODE_SMPS__NPM, PM_CLK_1p6_MHz, PM_CLK_1p6_MHz,
PM_DROOP_DETECT_DIS, 1250, 1413, 0, PM_SETTLING_ERR_DIS,
PM_SETTLING_EN, 0}, //ULT BUCK CTL1

++ {300, 0, PM_ACCESS_ALLOWED, PM_ALWAYS_ON, PM_NPA_SW_MODE_SMPS__NPM, PM_CLK_1p6_MHz, PM_CLK_1p6_MHz,
PM_DROOP_DETECT_DIS, 1250, 1500, 0, PM_SETTLING_ERR_DIS,
PM_SETTLING_EN, 0}, //ULT BUCK CTL1

硬件方面：更换了更加稳定的LDO！

• 概率性读不到id

• 顺序影响

• 平台：qcom-429

• 前后id的读取顺序和otp的加载顺序不一致，导致概率性读不到id的，高通在点亮gc8034时，也遇到概率性读不到id的情况。后来和他们沟通，是两个sensor上电相互影响了。

• ov8856先上电，会影响到gc8034的上电，导致gc8034读不到id！换一下顺序就可以了

• OTP上电影响

• 平台：8909

• 这个平台配OTP上电时序是在kernel的dtsi文件里配置的，高通的文档配置如下：

qcom,cam-power-seq-cfg-val代表了上电时序，1表示拉高或者供电！

dvdd拉高->avdd拉高->io拉高->设置mclk为24M->reset脚拉高->standby脚拉高

下电时序是:

standby脚拉高->reset脚拉高->设置mclk为24M->io拉高->avdd拉高->dvdd拉高，下 电时相应的脚没有被拉低！

以reset脚为例

“sensor_gpio_reset”,->0先拉低 “sensor_gpio_reset”,->1在拉高

因此，qcom,cam-power-seq-cfg-val = <1 1 1 0 1 24000000>;这个配置对应的上电时序：

dvdd拉高->io拉高->reset脚拉低->reset脚拉高->standby脚拉高->设置mclk为24M

下电的时候，是反过来执行的，下电时序是

设置mclk为24M-standby脚拉高->reset脚拉高->reset脚拉低->io拉高->dvdd拉高

最终，reset脚会被拉低，这样reset脚就没问题了！概率性读不到id问题也可能跟这个有关系！

因为我们前后摄供电都是用的同一路供电，挂在相同的i2c总线上。

前摄 OTP下电是时候，如果reset脚还是一直拉高着，i2c总线会觉得前摄还在工作，

这时候代码跑到后摄otp上电了，就可能会导致i2c地址读错或者read_id failed！