下载文档原格式
log抓取一．准备；1. 测试前打开adb端口在Settings->Applications->Development->USB debugging设置为enable抓取log顺序，先抓dumpstate等使用adb抓的LOG，然后抓dump，最后取出sd卡取log；备注※在X501等部分机型打开adb端口存在按键接口（在触摸屏没有响应，通过正常方式无法打开时，机器并没有死掉的情况）按键操作流程（整个操作要求USB数据线连接手机和pc机）：①按下power键；②按下包括音量加减键(keypad键)中的任意一个按键，保持5-15秒时间；③ keypad按键弹起；④ power按键弹起。
要求与使用条件：①power键和keypad键同时被按下保证5-15秒之间；②整个操作要求手机通过USB数据线与PC机连接2. 设置NV905、NV见下面二、抓取各log非死机情况抓dumpstate log测试前打开adb端口，出现问题后PC进入到log保存目录,使用下面的命令进行抓取adb shell dumpstate > dumpstate.log抓kernel和logcat的log到sd卡主要针对不能插USB线抓LOG的情况；打开拨号,输入”*#983564#”,弹出以下画面:选择”SDCard Settings”,弹出以下界面:选择”log path”,弹出:选择”/data/log’’,产生的log在/data/log/中，选择“/sdcard/log”，产生log在sdcrad 中，然后选择上一个界面中的“Log Redirect”,如下图:此时将抓取kenel和logcat产生的log，当测试完毕后需要关闭log抓取功能，关闭方法是在刚才界面中同样再次点击“Log Redirect”后，log抓取停止，此时可以取出log。
抓logcat和实时内核log使用下面的命令：adb shell cat /proc/kmsg > 文件名来抓取实时内核LOG（需要eng模式）adb shell logcat > 文件名来抓取logcat log；死机情况抓USB dump死机重启使用，可以提供给高通恢复栈以及其他LOG，研发也使用进行分析，尤其针对几率问题；首先设置NV项，NV905设置为0（发生Err_Fatal 时进入下载模式），NV4399设置为1（可在异常重启时进入下载模式）；设置NV步骤如截图：⑴打开QXDM，并切换到NV界面⑵修改NV905、NV4399样机出问题后，连接USB 到PC，运行QPST 的Memory Debug App:确认已进入下载模式点击“Get Regions”，然后再点击“SaveTo?…”，将dump 数据保存到指定目录中。
MTK 平台 CAMERA 驱动浅析Camera Driver analysis in the platform of MTKDocument Number:Preliminary (Released) InformationRevision:0.1Release Date:Ghong Confidential Revision 0.1-Feb.14 2012- 1 -Ⓒ2012 Ghong inc.Revision HistoryRevision Date (dd/mm/yyyy)Author Comments0.114/02/2012Guoqing Zhang Draft VersionGhong Confidential Revision 0.1-Feb.14 2012- 2 -Ⓒ2012 Ghong inc.Contents一、.-二、.-三、.-四、.-五、.-、.-、.-、.-、.-六、.-七、.-、.-、.-、.-、.-、.-、.-八、.-).-).-).-九、.-十、.-Ghong Confidential Revision 0.1-Feb.14 2012- 3 -Ⓒ2012 Ghong inc.一、手机Camera的物理结构：FPC: Flexible Printed Circuit 可挠性印刷电路板Sensor:图象传感器IR:红外滤波片Holder:基座Lens:镜头二、Camera的成像原理：景物通过镜头（LENS）生成的光学图像投射到图像传感器(Sensor)表面上，然后转为模拟的电信号，经过 A/D（模数转换）转换后变为数字图像信号，再送到数字信号处理芯片（DSP）中加工处理，再通过 IO 接口传输到 CPU 中处理，通过 LCD 就可以看到图像了。
Ghong Confidential Revision 0.1-Feb.14 2012- 4 -百度文库 - 让每个人平等地提升自我Ⓒ2012 Ghong inc.图像传感器（SENSOR）是一种半导体芯片，其表面包含有几十万到几百万的光电二极管。
基于MTK平台Camera驱动简介软件开发部：John.WangCamera的硬件架构ARM Image signalCMOS Sensorprocessor& resizerMemoryImage encodeLCD软件开发部：John.WangCamera模块硬件在手机上的基本架构有三种(一)Baseband控制LCD+Sensor.Baseband控制LCD，在Camera模式下Backend IC控制LCD进行各种操作。
Camera模块硬件在手机上的基本架构有三种(二)Baseband控制LCD+Backend IC，Backend IC控制Sensor。
Camera模块硬件在手机上的基本架构有三种(三)Baseband控制Backend IC，并且在非Camera模式下Baseband控制LCD，在Camera模式下Backend IC控制LCD进行各种操作。
Camera 接口信号sensor MTK cameraVCAMA, VCAMDCMDAT0~7CMVREFCMHREFCMMCLKCMPCLKCMPDNCMRSTSCLKSDACamera 接口信号signal descriptionCMVREF CMOS sensor vertical reference signal input CMHREF CMOS sensor horizontal reference signal input SCLK IIC interface clock signalSDA IIC interface data signalCMMCLK CMOS sensor master clock output CMPCLK CMOS sensor pixel clock intputCMPDN CMOS sensor power down control CMRST CMOS sensor reset signal outputVCAMA Camera module analog powerVCAMD Camera module digital powerCMDAT0~7Camera data busIIC时序控制Camera interface时序控制Camera程序架构软件开发部：John.WangCamera程序架构MMI taskCamera APP：控制应用程序逻辑,Camera的状态机，包括了preview，capture，exit等各种状态控制。
1Android Camera HAL3 分析本文均属自己阅读源码的点滴总结，转账请注明出处谢谢。
欢迎和大家交流。
qq:1037701636 email:gzzaigcn2009@Software ：系统源码Android 5.1Camera3研读前沿：当初在研读Camera1.0相关的内容时，主要围绕着CameraClient 、CameraHardwareInterface 等方面进行工作的开展，无论是数据流还是控制流看起来都很简单、明了，一系列的流程化操作使得整个框架学起来特别的容易。
因为没有Camera2.0相关的基础，所以这次直接看3.0相关的源码时，显得十分的吃紧，再加上底层高通HAL3.0实现的过程也是相当的复杂，都给整个研读过程带来了很多的困难。
可以说，自身目前对Camera3.0框架的熟悉度也大概只有70%左右，希望通过总结来进一步梳理他的工作原理与整个框架，并进一步熟悉与加深理解。
1.Camera3下的整体架构图。
整个CameraService 建立起一个可用操作底层Camera device 大致需要经过Camera2Client 、Camera3Device 以及HAL 层的camera3_device_t 三个部分。
2从上图中可以发现Camera3架构看上去明显比camera1来的复杂，但他更加的模块化。
对比起Android4.2.2 Camer 系统架构图（HAL 和回调处理）一文中描述的单顺序执行流程，Camera3将更多的工作集中在了Framework 去完成，将更多的控制权掌握在自己的手里，从而与HAL 的交互的数据信息更少，也进一步减轻了一些在旧版本中HAL 层所需要做的事情。
2. Camera2Client 的建立与初始化过程在建立好Camera2Client 后会进行initialize 操作，完成各个处理模块的创建： ?123 .... mStreamingProcessor = new StreamingProcessor(this);//preview 和recorder threadName = String8::format(C2-%d-StreamProc,mCameraId);4 5 6 7 8 910111213141516171819202122232425 mStreamingProcessor->run(threadName.string());//预览与录像mFrameProcessor = new FrameProcessor(mDevice, this);// 3AthreadName = String8::format(C2-%d-FrameProc,mCameraId);mFrameProcessor->run(threadName.string()); //3AmCaptureSequencer = new CaptureSequencer(this);threadName = String8::format(C2-%d-CaptureSeq,mCameraId);mCaptureSequencer->run(threadName.string());//录像，拍照mJpegProcessor = new JpegProcessor(this, mCaptureSequencer); threadName = String8::format(C2-%d-JpegProc,mCameraId);mJpegProcessor->run(threadName.string());....mCallbackProcessor = new CallbackProcessor(this);//回调处理threadName = String8::format(C2-%d-CallbkProc,mCameraId);mCallbackProcessor->run(threadName.string());依次分别创建了：StreamingProcessor并启动一个他所属的thread，该模块主要负责处理previews 与record两种视频流的处理，用于从hal层获取原始的视频数据FrameProcessor并启动一个thread，该模块专门用于处理回调回来的每一帧的3A等信息，即每一帧视频除去原始视频数据外，还应该有其他附加的数据信息，如3A值。
HY004,HY005,HY007CPU内部温度测试总结目录HY004,HY005,HY007CPU内部温度测试总结 (1)目录 (1)总结： (1)一．HY004 测试结果图表 (2)二．HY007 测试结果图表 (3)三．HY005 测试结果图表 (4)3.1 case_thermal 阈值为55-50度 (4)3.2 case_thermal 阈值为44-41度 (5)总结：多次重复实验，HY004和HY007的CPU温度实验结果基本基本相同，依然是HY004 CPU温度偏高，HY007较低。
重复实验时，使用了tsens_logging工具记录了实验过程中CPU中各种温度sensor以及相应核心频率的变化数据。
本文中所作的实验可以为手机外壳温升调节做参考，但是单纯的纠结CPU内部温度的高低意义不大。
在HY004的Thermal-engine 配置中，case_thermal温度上升到45度以上时，CPU核心频率就会下降到533MHz，以达到降温的目的。
而在HY007的配置中，case_thermal温度上升到45度以上时，CPU核心频率就会下降到960MHz。
但是同样的实验步骤，HY004的case_thermal很快的上升到45度以上并一直保持，然后实验过程中CPU频率绝大部分时间被限制到533M，此时CPU发热应该已经被限制的最低了。
HY007与HY004不同，HY007实验过程中case_thermal的温度从始到终，一直保持在40度一下。
所以thermal-engine反而没有没有限制CPU频率。
这应该和CPU本身的架构有一定关系，除此之外也从硬件组了解到HY007的样机是贴有散热膜的。
另外测试发现HY005的测试结果中，HY005的CPU内部温度是最高的，但是查看代码发现原因，我们修改MSM8937中四颗大核心同步工作，高通代码默认的只有两颗大核心同时工作。
除此外我们还讲case_thermal调控CPU_voltage(CPU降频率)的阈值由44-41提高到了55-50。
AndroidCamera原理之cameraHAL底层数据结构与类总结camera HAL层数据结构非常多，看代码的时候常常为了了解这些数据结构找半天，为了方便大家学习，特地总结了一些数据结构以及这些数据结构的位置：1.hardware/libhardware/include/hardware/camera_common. h：1.1 camera_info_t : camera_info1.2 camera_device_status_t : camera_device_status1.3 torch_mode_status_t : torch_mode_status1.4 camera_module_callbacks_t : camera_module_callbacks1.5 camera_module_t : camera_module2.hardware/libhardware/include/hardware/hardware.h：2.1 hw_module_t : hw_module_t2.2 hw_module_methods_t : hw_module_methods_t, 其中hw_module_methods_t 结构如下：这个结构体里面有一个函数指针，什么地方明确了函数指针的指向了？在hardware/libhardware/modules/camera/3_0/CameraHAL.cpp中的167行明确了函数指针指向。
指向其中的open_dev函数。
2.3 hw_device_t : hw_device_t3.hardware/libhardware/include/hardware/camera3.h3.1 camera3_device_t : camera3_device3.2 camera3_device_ops_t : camera3_device_opscamera3_device_ops_t 映射函数指针操作：hardware/libhardware/modules/camera/3_0/Camera.cpp上面的函数指针映射只是抽象层提供一个默认映射方法，实际上芯片中都会复写这个指针函数的映射关系。
Android 5.0 Camera系统源码分析(1)：CameraService启动流程1. 前言本文将分析Android系统源码，从frameworks层到hal层，暂不涉及app层和kernel层。
由于某些函数比较复杂，在贴出代码时会适当对其进行简化。
本文属于自己对源码的总结，仅仅是贯穿代码流程，不会深入分析各个细节。
分析android系统源码，需要对android系统的某些知识点有所了解2. frameworks层Android的各个子模块的启动都是从它们的Service的启动开始的，所以我们将从CameraService的启动开始分析。
CameraService的启动就在MediaServer的main函数中，代码路径在：frameworks/av/media/mediaserver/main_mediaserver.cpp[cpp] view plain copyint main(int argc __unused, char** argv){......CameraService::instantiate();......}CameraService类定义如下：[cpp] view plain copyclass CameraService :public BinderService<CameraService>,public BnCameraService,public IBinder::DeathRecipient,public camera_module_callbacks_t{static char const* getServiceName() { return "media.camera"; }......}mediaserver的main函数中调用了CameraService的instantiate函数来创建实例，该函数的实现在其父类BinderService中实现[cpp] view plain copytemplate<typename SERVICE>class BinderService{static status_t publish(bool allowIsolated = false) {sp<IServiceManager> sm(defaultServiceManager());return sm->addService(String16(SERVICE::getServiceName()),new SERVICE(), allowIsolated);}static void instantiate() { publish(); }}1. instantiate函数只是简单的调用了publish函数2. publish函数先构造CameraService，再通过addService函数将它注册到ServiceManager当中，而getServiceName函数获取到的值为“media camera”。
高通平台测试工具使用说明更改记录日期作者说明2010.2.25 研发三部贺伟创建目录1.工具使用 (3)1.2．QPST安装 (4)1.3．QXDM安装 (5)2.工具使用 (6)2.1.QXDM工具使用 (6)2.2.1. 手机log抓取和查看 (6)1.工具使用1.1．驱动安装先将驱动程序拷贝到PC上，然后将手机和PC相连，如果提示无法识别设备，点击安装usb驱动。
Win XP 以及Win2000建议安装下面驱动：\USB Host Driver Release 2.0.16(USB_WIN2K2016)\Exe\HK11-V3865-15_2.0.16\Win2K\checked.驱动安装成功后请检查驱动程序的信息：1.2．QPST安装驱动安装好以后,点击qpst工具setup后安装。
安装完成后需要添加手机，在开始菜单下点击QPST Configuration，如图：点击Add New Port…,如下图：选择左侧手机串口，如上图所示，然后点击OK，手机就完成了在高通log工具中的添加。
1.3．QXDM安装QXDM为高通平台抓取log的工具。
安装方式和QPST安装方式类似，QXDM也是点击Setup安装。
因为高通原始版本的license有时间要求, 如果点击QXDM后运行后出现时间过期的提示，请联系研发三部的工程师，提供破解的license文件覆盖原来的即可。
安装后的运行界面如下所示：2.工具使用2.1. QXDM工具使用QXDM工具功能非常强大，我们这里主要介绍外场常用的抓取以及分析手机log、修改手机NV值、观察手机运行状态三个功能。
手机连接PC后，点击运行，首先进行手机通讯的设置，选择Options中的Communications 如图：弹出设置窗口，点击Target Port中对应的手机Com口后，选择OK，完成手机的通信。
2.2.1. 手机log抓取和查看我们敲击F3或者在下拉的框中选择Message View<F3>，就打开了Message View窗口如果要保持log，在窗口上点击鼠标右键，选择Copy All Items…,在弹出的窗口中填写文件名即可保存log。
一，下载分析步骤：高通软件分为烧录部分（ARM9）和下载部分（ARM11），MEMORY在贴片前要先烧录ARM9部分。
高通7227平台为例，当软件只有AMR9部分时开机电流会跑到150mA左右才正常（其它平台电流不一定一样）。
正常下载方式夹具需要VBAT（电池电压，设置为通道1）和VCHG（充电电压，设置为通道2）两路电压同时设置为3.8V供电。
当电脑设备管理器能找到ADB interface(fastboot mode)端口就能下载ARM11软件。
正常下载时手机不能找到ADB端口时，故障分析步骤如下：（1）小电流（70mA以下）和大电流（200mA以上）请考虑贴片或物料问题，参考原理图分析问题。
（2）固定不动电流（70mA）较大可能是MEMORY里没有ARM9软件或软件不能运行造成。
正常的板子拆下MEMORY，开机电流就是固定在70mA。
固定不动电流（100 mA）可能是ARM9软件错误或CPU不能正常工作造成。
（3）电流在70至150 mA间跳动，但连接到PC不能找到ADB端口。
此时需要加LCD看板子的状态，正常是开机后进入fastboot mode（LCD显示纯黑色背景，有三行英文字符）；不正常的大多是开机白屏，多是CPU或软件问题。
备注：当一块板子在下载位不能下载时，要清楚知道板子的状态。
以上描述针对从未下载过ARM11软件的板子。
当下载ARM11失败的（开机白屏或定在开机LOGO不动的），要重新下载软件只能通过强行进入下载模式去下载软件，因为用正常下载方式只能进入关机充电模式；如果强行进入下载模式无效则只能拆下MEMORY重新烧录。
二，校准分析（BT1）：->A00001 Serial Connect:开机后，PC识别手机端口。
如果PC在设备管理器上识别端口，但测试程序还是不能连接端口，此时要检查QPST有没有把端口加入。
->A00002 Change Mode to FTM:转化模式进入工程测试模式（BT1时是在FTM模式下运作）->A00003 SWVersion1201-151-286-562-M76XX-TFNCKNLYM-60301->A00004 CheckSW: 1.00 1.00 1.00软件版本检查，每一个ARM11软件会有一个版本号，如果一款机子在生产过程中有软件升级，那么测试时需要在配置文件中将软件版本号修改对应起来->W11000 BC1_Range0_MaxPower 10.89 7.50 ->W11001 BC1_Range1_MaxPower 19.82 10.00->W11003 BC1_Range3_MaxPower 27.85 24.00BC1（WCDMA2100频段）的功率检查，此项测试BC1频段在一个指定的频点上Range0、1、3功率是否达标（下限值分别是7.5dbm、10.0 dbm、24.0 dbm）。
高通BMP1.0平台调试5M CMOS camera总结摘要：本文着重解决BMP1.0平台上的RAW data 输出数据的500万camera sensor的调试。
包括驱动层，应用层代码和camera镜头的色彩校准。
我们按照调试的先后顺序进行步骤说明：我们先说OEM层。
OEM层继承了ICAMERA的所有功能，ICAMERA只是一个壳，实现会转到OEMCAMERA。
AEE层介于两者之间，公开的代码只是让我们参考，修改无效。
在我们需要使用camera时候，调用CreateCamera，在Create Instance获得句柄后，我们得到一个应用的壳，然后得到具体的与camera应用相关的函数注册。
然后通过OEMCamera_SetParm开始启动ACM相关资源，ACM简单的理解，就是图片和相关分支调用函数。
详情看OEMCamera_ACMTransaction ()相关函数，这里不是重点，因此点到即止。
因为高通在双camera的资源应用上还没有完善，日后和应用在ACM上可能遇上问题，因此才在这里顺带说一下。
各位有兴趣可以和应用的多交流。
现在，我们可以从OEMCamera_New（）开始，对驱动设计工程师而言，可以理解为camera代码应用的开始。
OEMCamera_New（）中，camera_get_sensors所用到的变量，在代码启动的时候已经赋值，因此，并不是为空，这点需要注意，另外，这里还没有开始分配camera提供显示的内存空间，主要是对camera硬件相关进行初始化（想深入了解，看graph_task中的camera_init，这是在service层注册过的函数，再往下说，我怕会开始跑火车，就在这里点到即止，很多东西我们可以从代码中看到更多。
我这里提点一下就好）经常，我们需要trace看sensorInfo里面的信息。
我们最关心的是sensor_width和sensor_height，这个是从底层获取的camera输出图像的尺寸。
从代码的设计上看，AEECLSID_CAMERA1固定的表示主摄像头，AEECLSID_CAMERA2表示从摄像头(现在手机一般都是双camera，因此单camera的流程就不说了)现在我们非常关心sevice层的camera应用，在这里涵盖了camera绝大多数的基础代码（指公共服务的接口，）这个文件里的函数，需要认真研究。
首先，我们研究preview的部分：camera_malloc_preview_buffers()，可以看到camera_preview_buffers.buffers[current_buffer].buf_ptr表示preview的buffer的指针，共5块，前3块是给VFE用的，后2块是显示overlay用的。
VFE处理video数据流，图像效果处理，raw数据解析(包括rolloff,gamma,ASF，AWB 相关)，YCBCR格式拍照解析显示overlay用途，包括录像buffer的缓冲，屏幕显示的重载。
在raw data buffer中，会带上buffer头标志"QCAMRAW "，只有带这个标志的raw buffer,才是合法的，可以参看qcamrawIsHeader()这个函数判断，具体头里面有多少内容，看qcamrawSetHeader()这个函数，很直观的就能解析，这里就不在赘述。
想看preview关于buffer的指针定义，有一个函数camera_set_preview_buffers()很方便，这里面还包括recoding部分的buffer指针定义。
这里提供一个函数camera_calculate_output1_framerate(),可以看到如何用软件的方式看camera preview的帧率，我用过，和实际用示波器查看的结果非常接近，考虑帧率的动态变化，实际用软件的方式比示波器更好。
如果我们想对camera的数据进行一些深入的修改，建议从两个函数入手去追溯：camera_process_qdsp_output1_msg和camera_process_qdsp_output2_msg，这里面有很多图像处理。
Output1进行preview；output2进行snapshot。
Snapshot的thumbnail放在output1处理。
图像的旋转，camera_svcs_blt_ex(0这个函数是需要的，注意Y 和CbCr是分开存放的。
若是还想向上追溯，可以参看camera_svcs_process_func()，这里是camera一些主要公共功能的消息派发点。
具体看函数内部就明白，我就不多说了。
const camera_bestshot_config_type camera_bestshot_table[] = {#include "camera_bestshot_config.h"}; 这个是场景模式的入口，从camera_svcs_bestshot_get_config这里开始，将场景的索引赋值给cam3a_awb_state.bestshot_config，从这个关键词，我们能搜索到后面所有的功能。
关于ZOOM的相关流程，这里说明一下：camera_svcs_set_dimensions()可以看到zoom 的放大倍率的计算。
ui_picture_width=FLOOR16(camsensor_static_params[camera_asi].full_size_width- pad_pixels);ui_picture_height=FLOOR16(camsensor_static_params[camera_asi].full_size_height- pad_lines);如果是raw data 格式的数据：pad_pixels = 12;pad_lines = 8;这是预留的边框，防止后面计算出错，然后我们看到处理了ui_picture_width和ui_picture_height后，其值一定是偶数。
resize_factor=(camsensor_static_params[camera_asi].full_size_height*Q12/ max_crop_height (或者max_crop_width，哪个数小取哪个，这样保证放大能填充整个屏幕)); 这里计算能够放大的倍率因子if (camera_min_decimation < camera_zoom_table[i+1] && !found_min){camera_parm_zoom_table.minimum_value = (int32)i;found_min = TRUE;}if (resize_factor < camera_zoom_table[i+1]){camera_parm_zoom_table.maximum_value = (int32)i;break;}通过camera_min_decimation 和camera_zoom_table[]的比较，确定最小的ZOOM起始位置，这个位置其实是zoom的最大值，一般我们得到的是0值，告诉VFE按照camera的原始尺寸处理图像。
而camera_parm_zoom_table.maximum_value所表示的是zoom缩小的最大比例。
从上边的解释，我们看到，ZOOM所能放大，缩小的比率，和我们camera sensor能输出的最大尺寸，UI能设定的最大尺寸，还有屏幕能表现的尺寸有关系，通过改变这些值，我们能够按照需要放大，缩小图像。
通过上面的计算，我们得到camera_parm_zoom.minimum_value和camera_parm_zoom.maximum_value和camera_parm_zoom.step_value，这是我们最后能利用的zoom范围和每一步zoom的步长。
接下来如何zoom，就不多说了，因为出错的可能性很小。
以上属于部分camera的应用，后面在色彩校准部分还会介绍3a方面的应用。
下面我们来讨论一下camera sensor驱动代码我们按照函数调用顺序进行说明：1.camsensor_xxx_init():顾名思义，其代表的功能定义就不用再说了，这里只需要解释一下里面的一个变量camsensor_preview_resolution，它可以赋值CAMSENSOR_QTR_SIZE 和CAMSENSOR_FULL_SIZE，QTR是预览尺寸，FULL是拍照尺寸。
我们在调试的时候，要是怀疑拍照相关参数问题，可以在预览流程中看拍照的图片进行debug。
发布出来给客户的，就只需要QTR的设置。
2.camsensor_xxx_start()：这个函数太太太太太太重要了(我有点蛋疼了)，这个函数是驱动的灵魂，因为可以说的问题太多，一时之间都不知道怎么说（这话说的有点招臭鸡蛋）。
这样，望文生义的地方我就不说了，讲讲容易犯错的地方。
○1camif_config相关配置，其实已经没有用了，但是我们还是保留其设置(谁知道以后会不会又需要用上)。
○2camsensor_params->chromatix_parms = &camsensor_chromatix_xxx_struct; 这是tuning图像的所有参数的集合文件头。
Tuning后面我们会说.○3camsensor_params->raw_output_option = CAMSENSOR_8_BIT_DIRECT; 虽然还有CAMSENSOR_10_BIT_DIRECT这个参数可以选择，但由于后端数据的存储都是按照8Bit来处理，因此这个参数没有什么太大的意义（这个最终解释权在我这里，以后高通会不会将其区别开来，这要用发展的眼光来看）.○4在这个函数里，有判断camsensor_preview_resolution变量，这是为了调试全尺寸的需要而设置的，在正常流程中使用，我们只需要CAMSENSOR_QTR_SIZE这个分支，在实际的调试中，我发现，利用好CAMSENSOR_FULL_SIZE这个参数能方便解决拍照相关的很多问题。
至于怎么利用，说起来头疼，简单的说，在第一点使用camsensor_preview_resolution = CAMSENSOR_FULL_SIZE即可，至于这样做会有什么问题，就要看驱动代码的健壮否了。
这里无法做太多预测。
○5preview_dx_decimation：这个是VFE处理bayer格式数据给显示屏用的，这个是太太太重要了(我真无聊)。
