Qualcomm Camera基础

高通将android的camera模块从新修改了一下，与原生的方式存在一些差别。这里将前段时间学习的一些零散知识进行一下总结，便于之后查阅。

1.整个模块主要巡行三个主线程：control、config及frame，control用来执行总的控制，是上层控制接口（这个线程还未去了 解）？config主要进行一些配置，这个线程里面主要进行3A的工做，另外还有一些跟效果有关的设置；至于frame线程好像主要用来作预览吧。目前还 只是大体了解config线程。

2.在Qualcomm执行初始化时就会调用到mm_camera_exec（）函数来创建config线程 launch_cam_conf_thread（）；阅读此线程函数体会发现里面使用了select机制来检测配置指令并进行分发（调用不一样的分支函 数）。后面就是一连串的function call了。 关于select机制还有很多疑点须要进一步学习：指令的来源？如何对文件进行控制的？

好比下面这一段LOG就能够看到对AE、AWB及HIS设置的过程（只贴了部分）：

E/CAM_FD  (  194): ...... entering config duty loop ......
E/CAM_FD  (  194): cam_conf: MSM_CAM_IOCTL_GET_STATS: resptype=1 ctrl_cmd.type=4
E/mm-camera(  194): +++++++++++++ config_proc_vfe_event_message type 0                 // event类型
E/mm-camera(  194): camconfig_proc_vfe_event_message received msgId = 9               
E/mm-camera(  194): vfe_process_msg_evt msg_id = 9
E/mm-camera(  194): vfe_process_VFE_ID_COMMON, vfe common message = 0x4a000           // AE、AWB、IHIS
E/mm-camera(  194): received AEC stats: buf = 0x40821000, fd = 52
E/mm-camera(  194): VFE_ID_STATS_AE numReg 256, opt_mode 4
E/mm-camera(  194): vfe_util_do_aec: numReg = 256, num_pixels_per_region_aec = 30856
E/CAM_FD  (  194): isp3a_execute stats_type: 0                              // 执行AEC
E/mm-camera(  194): vfe_util_do_aec: no pendingPrepSnapCtrlCmd
......

看过Qualcomm摄像头部分代码的都知道，里面充斥了一些全局及静态变量，在未彻底理清楚前看起来很费劲，好比我如今就处于这种状态。下面就将一些已发现的变量总结一下写在这里，方便之后查阅。在海量代码中查阅一些数据结构真是一件使人头痛的事情。

1.config线程相关：

        config线程主要负责摄像头的配置工做，由它完成模块的大部分工做，调试的重点也在这部分。

        首先定义了一个全局的变量config_ctrl_t cfgctrl，全部的config相关的 数据都跟这个变量相关，好比调试过程当中经常使用到的isp3a_ctrl_t及sensor_ctrl_t等，都挂在这里。从这个结构体层层往下找就能慢慢理 清Qualcomm中的数据结构。在config线程里面发生的ctrl command和vfe event message都将传入cfgctrl地址及须要刷新的值，进行后续的操做并保持一些状态到cfgctrl中。因此若是须要了解某个状态，只要读取cfgctrl中的相关字段便可。ctrl command主要是一些菜单的设置，而vfe event message主要是vfe一些event的反馈处理。

        Qualcomm提供了一些接口来设置，但获取状态的接口基本没有，只能本身编写。

2.AWB相关（Bayer格式）：

        在AWB的处理过程当中，除了上面提到的isp3a_ctrl_t结构体用于对外交互外，AWB模块内部还定义了一个静态变量awb_algo_ctrl_t*awbCtrl用于保存AWB相关的数据及状态。这里面最重要的一个结构体awb_advanced_grey_world_t就是为加强的灰度世界法算法服务的。

Android高通平台调试Camera驱动全纪录

项目比较紧，3周内把一个带有外置ISP，MIPI数据通讯，800万像素的camera从无驱动到实现客户所有需求。

1日 搭平台，建环境，编译内核，烧写代码。

我是一直在Window下搭个虚拟机登服务器搞开发的，对Linux系统环境实在无爱，往往一到项目刚开始要搭环境了，心里总有点排斥，过程就比较纠结，看来之后仍是要搞个linux真机玩玩。

2日 编写camera驱动大体框架，配置GPIO,I2C,MIPI,电压,时钟等。
不多能碰到FAE只给硬件手册，没有Linux和Android驱动的。由于是camerasensor外接ISP芯片，杯具就发生了。整个系统是这样， 高通平台的开发板，本身写驱动来控制ISP芯片，ISP芯片与camerasensor封装在一块儿，ISP控制sensor，实质就是sensor写寄存 器。

      
 开始写驱动了，说好听的那是站在巨人的肩膀上借鉴别的驱动，说难听的就是照葫芦画瓢，反正再改下Kconfig,Makefile，这驱动框架就算是有了。
 对驱动开发而言，前期的主要工做应该就是配置GPIO口和芯片上电时序了。

每一个特定平台在操做GPIO，电压，时钟上都会有本身的一套内核API封装实现，只要能看懂会用这些API便可。配置完后，须在驱动初始化函数里，正确设置芯片的上电时序，确保芯片硬件上能正常工做起来。

 

3日 编写I2C通讯的封装函数，调试CPU与ISP间的I2C通讯

对于一些成熟方案，上面的工做完成顺利的话，驱动就差很少了。。很惋惜，这块ISP芯片在提高800万camera性能的同时，并无给我带来足够多的技术支持，只能说，成也ISP，败也ISP，解决方案全都本身来吧。万里长征第一道坎即是I2C。

I2C通讯自己要注意两点，

1) SDA第9位ACK位为低时说明从设备有响应。

2) Slave address

芯片手册对这个从设备地址没有统一的写法，有的给出8位地址，有的给出7位地址，一开始容易混淆。若是给出的是8位地址，那第8位是指Write- 0或者Read-1，实际的I2C芯片地址是7位的。Linux源码里structi2c_board_info的板基信息应填写7位I2C地址，另 外，I2C芯片地址能够经过开发板shell环境下$ ls/sys/bus/i2c/devices/ 查看。举个例子，

static struct i2c_board_info msm_camera_boardinfo[] __initdata ={
 {
  I2C_BOARD_INFO("ov8820", 0x78>> 1),
 },

 

4日 FAE现场支持

FAE过来了，就确认了一件事，没有现成驱动了，我完全死心了。后来还发现一个规律，只要FAE来现场那就意味着啥都搞不出来了。。几我的汇聚思想还不如一我的静下心来研究。不过他们此行至少留下一份重要的资料-ISP芯片指令序列，camera全部功能的实现就靠它了。

 

5日 调通I2C

I2C的调通具备里程碑式的意义，它不只标志着硬件性能正常开启，更为后来璀璨绚烂的camera世界奠基了坚实的基础。。

有段时间卡在I2C 通讯上，给ISP芯片0x3c写入开启芯片命令0xf0成功，可是再发送其余命令所有失败。

分析现象，I2C总线已经能够通讯了，问题只能是在ISP芯片上，因而，查电路图，抄家伙起来把电路板上的电和时钟所有再量一遍。。

结果发现，有一路来自自动对焦马达的电压只有1.7V，没有达到要求，驱动里没有把它的GPIO拉高，致使芯片没法正常开启工做。

 

6日 编写预览驱动，测量MIPI数据

根据葵花宝典里的ISP指令序列，在Linux驱动里和Android高通抽象层里填写相关代码，即可实现预览功能。不过很不幸，光靠那两下子预览 仍是出不来的。开启预览程序时，用示波器量MIPI总线上的图像数据，可以获得理想的MIPI波形，说明底层驱动的预览功能OK，问题在于高通平台的 CAMIFVFE上，因而，翻阅高通的技术资料，学习添加VFE的一些配置。

 

7日 配置VFE，点亮预览

预览的成功具备划时代的意义，它不只标志着camera模块在整个Android系统架构中的成型，更为后来的拍照，录像，图像效果等功能奠基了坚 实的基础。预览的出现，意味着我不用再回答那些相似像“camera亮没”之类的只注重表面现象的问题，从那一刻起，我仿佛站上了另外一个高度，有种梦回汉 唐的感受。。      

 

 

8日 健壮代码，编写拍照功能，对焦功能

至此，整个camera模块从上层应用到底层驱动已所有打通，接下来就能够见神杀神，见佛杀佛了。。

 

 

9日 编写白平衡，色彩效果，场景模式，ISO，防震，闪光灯等功能

这年头码农伤不起啊！就按葵花宝典上的ISP指令序列往里使劲填充。

 

10日 登录服务器提交代码

高通Android平台

最近负责一个项目（手机）上camera的功能，其 中有要求作zoom这个功能（项目上要求对全部的分辨率均可以支持4X的zoom），因此把这个部分比较全面的学习了一下，本文对高通在android平 台上zoom的实现原理作一个深刻的分析，包括的部分主要有zoom功能所涉及高通HW模块的原理架构、高通在android软件中 digitalzoom的实现流程以及具体的相关接口参数介绍，旨在让读者可以对高通android平台下digitalzoom的实现原理及架构有一个 清楚的了解。

1.Digital zoom原理介绍

这里提到的digitalzoom，即数码变焦，是相机变焦的一种；另一种为光学变焦，主要是在数码相机中有所应用，它经过相机镜头的移动来放大与缩小须要拍摄的景物，光学变焦倍数越大，能拍摄的景物就越远，并且不会影响画质。本章节重点介绍数码变焦部分，这种变焦在手机中应该较为普遍。

手机上的数码变焦是经过手机内的处理器，把图片内的每一个象素面积增大，从而达到放大目 的。这种手法如同用图像处理软件把图片的面积改大，不过程序在手机内进行，把原来sensor上的一部份像素使用"插值"处理手段作放大,将sensor 上的像素用插值算法将画面放大到整个画面。经过数码变焦，拍摄的景物放大了，但它的清晰度会有必定程度的降低，因此数码变焦并无太大的实际意义。

下图是数码变焦和光学变焦的效果对比，一目了然。

数码变焦通常分为分为2个步骤，crop和插值放大。另外，数码变焦有2种情况：一种是用户须要拍照画面的尺寸和sensor输出画面的尺寸是一致的；另外一种则是用户须要拍照画面的尺寸×zoom等级后比sensor输出画面的尺寸小。在第二种状况下只须要crop就能够了（具体要根据zoom等级计算）

       关于zoom的等级，倍数越高，crop的像素就越少，以拍照3M（2048×1536，sensor输出的原始照片为3M）的照片为例，若是作2X的zoom，那么须要从原始照片中crop出1024×768的画面，而后再插值放大成2048×1536；若是是4X的zoom，那么须要从原始照片中crop出512×384的画面，而后再插值放大成2048×1536，以此类推。倍数是指宽和高的倍数，而非面积。

下面结合图片来讲明一下数码变焦的原理：

       1、当用户须要拍照画面的尺寸和sensor输出画面的尺寸一致

原始照片，红色部分为zoom后须要crop的部分

Zoom后的照片，crop后并插值放大

能够发现，zoom先后照片大小是一致的，但照片的范围变小了，感受是镜头拉近了，其实就是经过crop后再插值放大来完成，zoom的倍数越高，须要插值的像素就越多，zoom后的照片就会越模糊。

Note：这里的插值放大是指软件算法，和图像处理软件中那种线性放大是不一样的，关于算法的实现这里很少介绍了。

 

2、用户须要拍照画面的尺寸×zoom等级后比sensor输出画面的尺寸小

下图是sensor输出的原始照片，1600×1200。须要拍照的分辨率为800×600，便可以做2X的digitalzoom

在这种情况下是不须要插值放大的，图片的质量并无下降；但若是zoom的等级比较大，好比要4x的zoom，那么光靠crop是不行的，仍是得再经过插值放大来完成。一般说来，若是拍照的分辨率比较小，zoom大均可以只经过crop的方式来完成。在上章节中介绍了digitalzoom的效果以及基本的实现原理，本章将着重介绍高通平台上实现digitalzoom所涉及的相关模块架构，由于digitalzoom是camera中的一个feature，分别须要在preview和snapshot中完成，

所涉及的相关模块也都是和camera相关的，以下所示：

上图是preview的时候，digitalzoom所涉及的相关模块，各个模块的用途以下（这里主要介绍sensor、VFE和MDP）：

一、 Sensor

       虽然自己也有zoom的功能，但在这里并未使用。Preview时若是作digitalzoom，只是正常的输出frame而已，好比输出30fps的VGA数据（YUV）。

二、 VFE

DSP的一部分，功能主要都是和图像处理相关，在zoom的时候，它的用途主要就是Crop（剪裁），它会把sensor输出的VGA数据crop成preview时所须要大小的数据，如CIF（352×288），这样的话至关于已经作了一部分zoom（640/352）,大概是1.8X，若是不够，剩余的zoom将由后面的MDP来完成。

Note：VFE只有crop的功能，没有upscale（放大）的能力，因此VFE最多只能完成有限的zoom。

三、 MDP

这是一个专门处理显示数据的处理器，功能比较齐全，在zoom的时候主要的用处就是crop＋upscale。由于VFE的zoom能力有限，因此当VFE不能知足要求的时候，MDP则继续完成剩余的zoom，好比：若是要求preview画面的大小为QVGA，如今要作4X的zoom，那么VFE会从原始的VGA数据中crop出QVGA大小的数据，至关于已经作了2X的zoom，那么剩下的2Xzoom怎么作呢？MDP会从VFE输出的QVGA（320×240）数据中crop出160×120大小的数据（从中间截取），而后再upscale成QVGA大小的数据送到LCD显示，这样至关于又作了2X的zoom，因此加起来一共作了4X的zoom。

Note：MDP最大能够进行4X的upscale。

 

      上面介绍了preview时zoom的实现，下面来看一下拍照时zoom是如何实现的？

Note：为了知足所拍为所看，即拍下来照片的景物范围和preview时所看到的景物范围要保持一致，preview时和snapshot时的zoomlevel必须保持一致。

 

一、             Sensor

输出拍照须要的原始数据。在当前应用中，无论设置的拍照分辨率是多少，咱们要求sensor输出的拍照数据是固定的，即最大3M(2048*1536,以ICE为例)。

二、             VFE

功能和preview时候是一致的，只不过在拍照的时候，VFE会根据zoom的等级以及须要拍照的分辨率来自动crop出合适大小的数据。

例如选择拍照的分辨率为2048×1536，zoom的level为4X，那么VFE将从原始的2048×1536的数据中crop出512×384大小的数据，后面的zoom由Videocore中的jpegencoder完成。

还有一种情况，若是拍照的分辨率较小，那么有可能只经过VFE的crop就能够完成zoom功能，好比拍照的分辨率为1024×768，这个时候若是作2X的zoom，那么VFE只须要从原始的2048×1536的数据中间直接crop出1024×768的数据便可，后面就不须要再用jpegencoder来zoom了。但若是zoom的等级比较高，后面的2Xzoom仍是要经过jpegencoder来作了。

三、             Video core

               负责把VFE输出的数据encoder成jpeg文件，这里的jpegencoder还有一个比较重要的功能，那就是upscale，经过这个功能，再搭配以前VFE的crop功能，zoom就能够完成了。

       Note：Jpeg encoder的upscale功能是有限的，最大能够进行4X的放大，目前能够知足ICE上的需求。

               能够看出，从HW架构来讲，preview和snapshot只是在后面的upscale部分有所区别，前者是经过MDP来完成，后者则是经过jpegencoder（DSP）来完成。

3.高通 Android平台软件架构分析（digitalzoom相关）

本章将从软件角度来分析一下高通Android平台下digitalzoom的架构以及实现流程，下面先来看一下Android中camera部分的软件架构。

Note:目前以Androiddonut版本为例，高通在androidéclair版本上尚未导入

先来看一下Preview的流程：
一、VFEdriver会把从sensor传送来的frame数据crop成上层须要的大小（具体若是crop要根据zoom的level），而后连同crop信息一块儿把数据传送到HAL。
二、HAL层不会对preview数据作任何处理，它会这些数据原封不动的callback到camera service，一样包含cropinfo（下章节会详细介绍crop info）。
三、Camera service在一开始的时候会在surfaceflinger中建立一个surface。当cameraservice收到preview数据的时候，2个主要接口会被调用：
1)     zoomUpScale_callback
经过调用mSurface->updateCropRect接口把crop相关信息通知给surfaceflinger
2)     previewCallback
经过调用mSurface->postBuffer接口把preview的数据传递给surfaceflinger。
四、Surfaceflinger收到数据和crop信息后会调用copybit的接口来驱动MDP去作相关的动做（crop&upscale），而后就去画屏了。
再来看一下snapshot时的流程：
一、VFEdriver把从sensor传递来的原始拍照数据（最大分辨率：2048×1536）crop成zoom须要大小的数据，连同crop信息一块儿传递给HAL。
二、HAL层收到snapshot的数据后会先去检查crop info，判断是否须要jpegencoder去作upscale的动做。若是不须要就直接encode成jpeg数据；若是须要，填好upscale的参数再作encode。
三、Jpeg encoder后的数据会从HAL callback到camera service，cameraservice会在通知上层去把数据写成文件。
因而可知，在snapshot的时候，整个zoom在HAL就能够完成了，而不像preview的时候，须要在surfaceflinger中配置MDP协助完成。具体的原理在第二章节中有详细的叙述，这里就不重复了。

 

4.Zoom相关接口及参数介绍

本章将从代码的层次来分析一下zoom的实现原理及流程。

Note：基于高通5110 release的code

首先来看一些配置参数（基于HAL）：

#define MAX_ZOOM_LEVEL5//对于user来讲能够zoom的等级

static const int ZOOM_STEP =6;//每次zoom时的幅度，能够修改

另外须要说明高通VFE中zoom的最大值为60（和分辨率无关）。所在在ICE上咱们应该让MAX_ZOOM_LEVEL×ZOOM_STEP＝60。要么增大MAX_ZOOM_LEVEL，要么增大ZOOM_STEP。

下面再来看一下zoom等级的对应关系（高通能够作到最大的就是zoom4X，这个是HW（MDP和jpegencoder）的限制）：

 

下面看一下HAL层zoom的接口

HAL层的接口比较简单，就是setZoom，上层传递一个zoom的level便可，执行时会判断参数，若是没有超出则通知VFE进行crop，以下：

 

       因此surfaceflinger在更新画面的时候就会根据这些参数来配置MDP，完成后续的操做了。
       拍照的时候一样也是这样的原理，差异在于crop中的信息不须要传递给上层，而是直接传递给jpegencoder便可（写到mDimension这个结构体中），以下（HAL中的receiveRawPicture函数）：

Jpegencoder完成后，HAL只须要把zoom好的jpegdata callback给上层就OK了，因此拍照部分的zoom不须要上层额外的处理。

 

下面看看Camera service里面是怎么处理的？
       Cameraservice收到callback后会把crop相关信息及标志更新到preview所申请的surface中.

 

下面看一下VFE输出数据的格式：

在Preview的时候，经过MSM_CAM_IOCTL_GETFRAME系统命令从底层获得preview的数据，格式以下：

  buffer为数据地址，y_off和cbcr_off分辨为Y的偏移和CBCR的偏移，经过y_off=0,cbcr_off=w*h,这里和zoom相关的是cropinfo，比较重要，以下：

 

  能够看出有2个buffer的参数，其中1是preview的，2是snapshot的。若是没有开启zoom功能，这些参数都是空的；若是zoom的level比较低，VFE足以处理，那么这些参数也是空的。
只有当VFE不足以处理所须要的zoom level时，这些参数的值才有意义。具体含义以下：
out的值表明上层须要数据的宽和高，好比说上层设置的preview大小为480×320，那么out1_w=480;out1_h=320；而in的值则表明后端的MDP或是jpegencoder须要crop的大小，举例来讲明：
    Sensor输出VGApreview画面，MMI设置HVGApreview大小，若是要作2X的zoom，VFE能力有限，只能作 640/480=1.3X,这个时候VFE输出数据是crop后的HVGA数据，crop信息中的in1_w=320;out1_w=216,意思是后面 的MDP须要从HVGA的数据中crop出320×216大小的数据，而后在scale成HVGA，这样总体算起来就是zoom2X了。
   因此HAL只须要将preview数据以及crop info传递给上层便可，这里是经过callback进行的.