1 camera基本代码架构

高通平台对于camera的代码组织，大体上还是遵循Android的框架：即上层应用和HAL层交互，高通平台在HAL层里面实现自己的一套管理策略；在kernel中实现sensor的底层驱动。但是，对于最核心的sensor端的底层设置、ISP效果相关等代码则是单独进行了抽离，放在了一个 daemon进程中进行管理：

图1 Qualcomm平台camera代码架构简图

由于高通把大部分具体的设置及参数放到了daemon进程中，所以在kernel部分只是进行了V4L2的设备注册、IIC设备注册等简单的动作：

图2 kernel层camera主要代码简图

如上图，camera在kernel层的主文件为msm.c，负责设备的具体注册及相关方法的填充；在msm_sensor.c文件中，主要维护高通自己的一个sensor相关结构体—msm_sensor_ctrl_t，同时把dts文件中的配置信息读取出来；kernel层对于不同的sensor对应自己的一个驱动文件— xxsensor.c，主要是把power setting的设定填充到msm_sensor_ctrl_t中。

在vendor目录下，高通把各个sensor实质性的代码放置在此。一部分代码是高通自己实现的daemon进程和kernel层及HAL层进行通讯的框架代码；另一部分则是和sensor相关的chromatix效果代码和sensor lib部分代码(init setting、lens info、output info)。

图3 vendor下主要camera代码简图

如上图，高通平台通过一个函数指针数组sub_module_init来管理sensor相关的组件；其中重要的是sensor_sub_module_init和chromatix_sub_module_init模块，对于sensor模块需要对应填充sensor_lib_t下的接口，对于chromatix模块则是通过高通的chromatix工具生成。

从更高的层次来看，sensor部分的代码只是camera子系统的一部分。打开高通vendor下面关于camera的源码也可以看到，/mm- camera2/media-controller/modules目录下面，sensors只是modules文件下面其中的一个子目录。

图4 高通camera子系统模块草图

2 主要移植步骤

2.1 kernel层代码移植

对于kernel层的代码移植，实际上对dts文件的移植。因为kernel层驱动代码基本已经被高通的框架以及vendor下代码架空，只剩下一个上电的列表。具体步骤为：

1. 在目录kernel/arch/arm/boot/dts/下的对应中新增camera节点，主要关注节点中的IIC地址、sensro的ID信息、电压设定信息：

图5 dtsi中camera中的节点信息截选

2．在目录kernel/drivers/media/platform/msm /camera_v2/sensor/目录新增xxsensor.c文件，主要填充msm_sensor_power_setting结构体：sensor上电的包含的引脚设定和电压设定，具体格式可以参考同目录下的其他文件。

3. kernel下面的相关mk文件：

图6 kernel目录下camera相关配置文件

其他：如果sensor中带有eeprom，需要在dts文件中增加eeprom的节点信息；同样，sensor带有对焦功能，需要在dts文件中增加actuator节点信息；对于带eeprom的sensor，还需要配置eeprom的时钟控制代码(有待研究)。

2.2 vendor下代码移植

Vendor下面的代码主要是两部分，一个是sensor_libs目录下的sensor具体设定、配置文件，另一个是chromatix下面的ISP效果文件。具体为：

1. sensor_libs目录下文件：包括一个Android.mk文件和一个.c文件。其中Android.mk文件参考同目录下其他.mk文件修改和对应sensor有关设定即可；.c文件中需要填充的为一个sensor_lib_t类型的结构体：

图7 sensor_lib_t成员截选图

2. chromatix目录下相关文件，在对应sensor目录下包含4个目录和一个Android文件，总共13个文件，这些文件都会由chromatix调试工具生成。下面为IMX179文件实例：

图8 vendor下chromatix相关文件示例图

3. vendor下还有eeprom文件，模组自带的eeprom数据处理相关；AF相关文件，调试工具生成的关于AF的效果文件；配置文件，把需要编译的模块填进配置文件中。

图9 vendor下其他camera文件

3 调试常见问题

3.1 kernel和vendor下命名匹配

对于不是高通释放的标准驱动来说，在参考其他代码移植调试一个新sensor的过程中，要注意在对应的dts文件中给sensor配置节点信息的过程中，“qcom,sensor-name”字段的配置要和vendor下面的sensor lib代码中的“xxx_open_lib”函数名以及对应的Android.mk中的“LOCAL_MODULE”名称匹配，否则相应sensor的 vendor下库文件无法调用，这时打开camera会出现闪退现象。具体可参考平台代码sensor.c中的 sensor_load_library()函数。

图10 camera name匹配详图

3.2 sensor lib中的sensor_lib_out_info_t填充

一般来说，每个sensor可以配置输出不同大小的图像。此时，除了进行对应的sensor setting来改变sensor自身的输出及相关配置外；还需要将相关的输出大小、帧率等信息通知平台端，即填充struct sensor_lib_out_info_t结构体。

图11 高通平台获取sensor信息框图

填充的这个sensor_lib_out_info_t中的成员，最终会作为sensor基本信息的一部分被HAL层获取到，上图为高通平台获取sensor信息的一个简单框图。

在调试过程中，需要注意的是这个结构体的成员max_fps需要填写至少大于等于30；否则会因为在获取capability时无法得到有效的 previewsize、video size而无法进入预览。具体可参考平台代码mct_pipeline.c中的 mct_pipeline_populate_query_cap_buffer()函数。

3.3 sensorlib中的exposure_table_size填写

对于sensor端输出RAW数据，平台端进行ISP处理的情形来说，sensor端除了基本的init配置外，另外一个就是根据平台端AEC计算出来的数据来对应调整sensor的曝光。在高通平台上将平台端的AEC和具体的sensor曝光设置联系起来的是chromatix文件中的一个 Exposure Table和sensor lib文件中的exposure对应接口。

这里的exposure_table_size对应着sensor lib中sensor_fill_exposure_array()接口写入的sensor寄存器的个数，平台代码中需要根据这个 exposure_table_size来动态分配内存大小。如果这个值的填写和sensor_fill_exposure_array()中实际写入的值大小不一致，就会造成内存方面的crash。具体可参考平台代码sensor.c中的sensor_apply_exposure()函数。

3.4 kernel 层非常规设定

一般情况下，一个新sensor的移植和调试需要在kernel层进行的工作基本上没有问题。但是对于一些sensor来说，对于电压的设定或是MCLK的设定有非常规要求的时候，可能就需要修改平台上相关的默认设定。

对于sensor的几路工作电压 (AVDD、DVDD、IOVDD)，平台端一般都是通过PMIC的相应regulator供电，而硬件上regulator的输出能力一般都有限制，代码上也会有体现。如果有sensor需要的电压超过代码上相应regulator的限制值，可以查看PMIC上的说明，如果代码上的限制值并不是硬件的真正极限，可以修改平台代码解决。

对于MCLK的设定，高通平台有一些常规的值设定。如果sensor有特殊要求，而这个MCLK不能被平台识别，这时候可以在平台的clock相关代码中，通过配置平台的PLL参数来生成特定的MCLK时钟给sensor使用。