<4>Qualcomm Camera基础 三线程

时间:2022-09-01 19:41:48

http://blog.csdn.net/qq69696698/article/details/7399518


高通将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的像素就越少,以拍照3M2048×1536sensor输出的原始照片为3M)的照片为例,如果做2Xzoom,那么需要从原始照片中crop1024×768的画面,然后再插值放大成2048×1536;如果是4Xzoom,那么需要从原始照片中crop512×384的画面,然后再插值放大成2048×1536,以此类推。倍数是指宽和高的倍数,而非面积。

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

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


原始照片,红色部分为zoom后需要crop的部分


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

可以发现,zoom前后照片大小是一致的,但照片的范围变小了,感觉是镜头拉近了,其实就是通过crop后再插值放大来完成,zoom的倍数越高,需要插值的像素就越多,zoom后的照片就会越模糊。

Note:这里的插值放大是指软件算法,和图像处理软件中那种线性放大是不同的,关于算法的实现这里不多介绍了。

 

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

下图是sensor输出的原始照片,1600×1200。需要拍照的分辨率为800×600,即可以作2Xdigitalzoom


在这种状况下是不需要插值放大的,图片的质量并没有降低;但如果zoom的等级比较大,比如要4xzoom,那么光靠crop是不行的,还是得再通过插值放大来完成。通常说来,如果拍照的分辨率比较小,zoom大都可以只通过crop的方式来完成。在上章节中介绍了digitalzoom的效果以及基本的实现原理,本章将着重介绍高通平台上实现digitalzoom所涉及的相关模块架构,因为digitalzoomcamera中的一个feature,分别需要在previewsnapshot中完成,


所涉及的相关模块也都是和
camera相关的,如下所示:

上图是preview的时候,digitalzoom所涉及的相关模块,各个模块的用途如下(这里主要介绍sensorVFEMDP):

1、 Sensor

       虽然本身也有zoom的功能,但在这里并未使用。Preview时如果做digitalzoom,只是正常的输出frame而已,比如输出30fpsVGA数据(YUV)。

2、 VFE

DSP的一部分,功能主要都是和图像处理相关,在zoom的时候,它的用途主要就是Crop(剪裁),它会把sensor输出的VGA数据croppreview时所需要大小的数据,如CIF352×288),这样的话相当于已经做了一部分zoom640/352,大概是1.8X,如果不够,剩余的zoom将由后面的MDP来完成。

NoteVFE只有crop的功能,没有upscale(放大)的能力,所以VFE最多只能完成有限的zoom

3、 MDP

这是一个专门处理显示数据的处理器,功能比较齐全,在zoom的时候主要的用处就是cropupscale。因为VFEzoom能力有限,所以当VFE不能满足要求的时候,MDP则继续完成剩余的zoom,比如:如果要求preview画面的大小为QVGA,现在要做4Xzoom,那么VFE会从原始的VGA数据中cropQVGA大小的数据,相当于已经做了2Xzoom,那么剩下的2Xzoom怎么做呢?MDP会从VFE输出的QVGA320×240)数据中crop160×120大小的数据(从中间截取),然后再upscaleQVGA大小的数据送到LCD显示,这样相当于又做了2Xzoom,所以加起来一共做了4Xzoom

NoteMDP最大可以进行4Xupscale

 

      上面介绍了previewzoom的实现,下面来看一下拍照时zoom是如何实现的?

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

 

1、             Sensor

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

2、             VFE

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

例如选择拍照的分辨率为2048×1536zoomlevel4X,那么VFE将从原始的2048×1536的数据中crop512×384大小的数据,后面的zoomVideocore中的jpegencoder完成。

还有一种状况,如果拍照的分辨率较小,那么有可能只通过VFEcrop就可以完成zoom功能,比如拍照的分辨率为1024×768,这个时候如果做2Xzoom,那么VFE只需要从原始的2048×1536的数据中间直接crop1024×768的数据即可,后面就不需要再用jpegencoderzoom了。但如果zoom的等级比较高,后面的2Xzoom还是要通过jpegencoder来做了。

3、             Video core

               负责把VFE输出的数据encoderjpeg文件,这里的jpegencoder还有一个比较重要的功能,那就是upscale,通过这个功能,再搭配之前VFEcrop功能,zoom就可以完成了。

       NoteJpeg encoderupscale功能是有限的,最大可以进行4X的放大,目前可以满足ICE上的需求。

               可以看出,从HW架构来说,previewsnapshot只是在后面的upscale部分有所区别,前者是通过MDP来完成,后者则是通过jpegencoderDSP)来完成。

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

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

Note:目前以Androiddonut版本为例,高通在androidéclair版本上还没有导入

先来看一下Preview的流程:
1、VFEdriver会把从sensor传送来的frame数据crop成上层需要的大小(具体如果crop要根据zoom的level),然后连同crop信息一起把数据传送到HAL。
2、HAL层不会对preview数据做任何处理,它会这些数据原封不动的callback到camera service,同样包含cropinfo(下章节会详细介绍crop info)。
3、Camera service在一开始的时候会在surfaceflinger中创建一个surface。当cameraservice收到preview数据的时候,2个主要接口会被调用:
1)     zoomUpScale_callback
通过调用mSurface->updateCropRect接口把crop相关信息通知给surfaceflinger
2)     previewCallback
通过调用mSurface->postBuffer接口把preview的数据传递给surfaceflinger。
4、Surfaceflinger收到数据和crop信息后会调用copybit的接口来驱动MDP去做相关的动作(crop&upscale),然后就去画屏了。

再来看一下snapshot时的流程:
1、VFEdriver把从sensor传递来的原始拍照数据(最大分辨率:2048×1536)crop成zoom需要大小的数据,连同crop信息一起传递给HAL。
2、HAL层收到snapshot的数据后会先去检查crop info,判断是否需要jpegencoder去做upscale的动作。如果不需要就直接encode成jpeg数据;如果需要,填好upscale的参数再做encode。
3、Jpeg encoder后的数据会从HAL callback到camera service,cameraservice会在通知上层去把数据写成文件。
由此可见,在snapshot的时候,整个zoom在HAL就可以完成了,而不像preview的时候,需要在surfaceflinger中配置MDP协助完成。具体的原理在第二章节中有详细的叙述,这里就不重复了。

 

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

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

Note:基于高通5110 releasecode

首先来看一些配置参数(基于HAL):

#define MAX_ZOOM_LEVEL5//对于user来说可以zoom的等级

static const int ZOOM_STEP =6;//每次zoom时的幅度,可以修改

另外需要说明高通VFEzoom的最大值为60(和分辨率无关)。所在在ICE上我们应该让MAX_ZOOM_LEVEL×ZOOM_STEP60。要么增大MAX_ZOOM_LEVEL,要么增大ZOOM_STEP

下面再来看一下zoom等级的对应关系(高通可以做到最大的就是zoom4X,这个是HWMDPjpegencoder)的限制):


 

下面看一下HALzoom的接口

HAL层的接口比较简单,就是setZoom,上层传递一个zoomlevel即可,执行时会判断参数,如果没有超出则通知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_offcbcr_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进行的.