jiangchaobing_2017的博客

总大小： Y 分量 + UV 分量 = （1280 * 720 + 1280 * 720 * （1/2） ） / 1024 / 1024 = 1.32。/vendor/mediatek/proprietary/hardware/mtkcam3/3rdparty/mtk/hdr/ – Yuv 多帧算法。/vendor/mediatek/proprietary/hardware/mtkcam3/3rdparty/mtk/fb/ – Yuv 单帧算法。setRepeatingRequest() 是重复请求。

设备描述符是USB主机枚举USB设备申请的第1个描述符，每个设备有且仅有一个设备描述符，也就是大家以后看到的任何的USB设备都只有一个设备描述符数组，设备描述符的长度是18字节，下面我们来学习设备描述符数据结构，看看USB设备具有哪些特征，它的结构我们可以通过下面的表格来逐一了解。在USB Core中已经向总线注册了三个驱动（USB设备驱动、USB接口驱动、USB hub驱动），根据条件匹配到USB设备驱动，则去调用USB设备驱动的probe函数。所有的USB传输，都是从USB主机这方发起的；

连接后，CC pin相连，DFP的CC pin会检测到UFP的下拉电阻Rd，说明连接上了，DFP就打开Vbus电源开关，输出电源给UFP。最终的目的是在插入后，能检测到CC1或CC2上的电压，进而判断是否翻转以及DFP的电流能力。就靠Rp的值，Rp的值不一样，CC pin检测到的电压就不一样，然后来控制DFP端执行哪种供电模式。含芯片的线缆也不是两根cc线，而是一根cc，一根Vconn，用来给线缆里的芯片供电(3.3V或5V)，这时就cc端没有下拉电阻Rd，而是下拉电阻Ra，800-1200欧。

每个包都由SOP（包起始域）、SYNC（同步域）、Packet Content（包内容）、EOP（包结束域）四部分组成，其中SOP、SYNC、EOP为所有包共有的域，Packet Content最为核心，不同类型的包由不同的Packet Content组成。

控制读传输在初始设置阶段会发起一个SETUP事务，从这个SETUP事务我们可以知道是设备给主机传输数据，并且数据长度是255，这里把先控制传输理解到位，接着在数据阶段完成数据交换（因为是设备给主机传输数据，所以是数据阶段是IN事务），最后在状态信息阶段主机给设备发送一个OUT事务表明自己接收是否异常。在OUT和SETUP事务处理中，紧接在SETUP和OUT包后的是DATA包，DATA0和DATA1包是接替地发送的，在DATA包后面，设备将回应一个握手信号，（如果设备可以接受数据，就回应ACK包；

枚举是从USB设备读取一些信息的过程，这些信息包括设备的类型、如何进行通信等。主机通过获取这些信息，可以识别出设备并加载合适的驱动程序。调试USB设备时，枚举过程是非常重要的一环，只要枚举成功，就意味着设备已经能够被主机正确识别，并且大部分的工作已经完成。当有新设备连接到主机时，主机会发送一系列的请求给设备所挂载的hub。hub会建立起一条连接主机和设备之间的通信通道。然后，主机通过控制传输的方式，使用端点0（Endpoint0）对设备发送各种请求。设备在收到主机的请求后，会回复相应的信息，进行枚举操作

Descriptor即描述符，是一个完整的数据结构，可以通过C语言等编程实现，并存储在USB设备中，用于描述一个USB设备的所有属性，USB主机是通过一系列命令来要求设备发送这些信息的。它的作用就是通过命令来给主机传递信息，从而让主机知道设备具有什么功能、属于哪一类设备、要占用多少带宽、使用哪类传输方式及数据量的大小，只有主机确定了这些信息之后，设备才能真正开始工作，所以**描述符也是十分重要的部分，要好好掌握

USB 2.0 SQ 的测试原理是，设置 USB 控制器的 Test Control 寄存器，使 USB 控制器进入 Test Packet Mode， USB 控制器就会持续产生并发送周期性的 Test Pattern。USB定义了6种眼图模板，其中定义在集线器TP2点或在USB设备（使用非束缚电缆）TP3点处的眼图模板，表示接收高速USB信号时所需的电压分辨力，如图2所示。眼图的测量参数不同于波形的测量参数，更多情况下是一种统计意义的测量，主要关注的测量参数有眼高，眼宽，眼抖动等。

USB设备是热插拔，因此在hub_probe函数中调用hub_configure函数来配置hub，在这个函数中主要是利用函数usb_alloc_urb函数来分配一个urb，利用usb_fill_int_urb来初始化这个urb结构，包括hub的中断服务程序hub_irq的，查询的周期等。第二件事是调度工作队列处理hub事件。通过usb_device_match匹配设备驱动，即usb_device_type类型，最终会调用到内核提供的通用的USB设备驱动usb_generic_driver_probe。

此时的dev 代表着一个interface, 而drv 就代表了我们自己的usb 驱动. 但是我们应当看到drv是device_driver 类型, 而我们写的usb 驱动的类型一般是usb_driver, 因此这里的probe 和我们自己写的probe 显然不是同一个. 实际上这里的drv 是我们的驱动对象里内嵌的一个子对象( 因为linux 下所以的驱动都必须用device_driver 来代表,). 那这个子对象的probe 函数是在哪里赋值的呢?主要是找到对应的客户驱动程序和该USB设备挂钩。

USB Class Driver和USB设备接口、USB设备和USB Core(USB Driver)的匹配工作由usb_bus_type中的usb_device_match函数完成，该函数会进一步调用usb_match_id进行匹配。在执行device_add后导致总线的匹配函数usb_device_match再次被调用，这次由于是接口设备，设备类型为usb_if_device_type，那么匹配的一定是接口驱动，于是会执行usb_device_match的else分支，去匹配接口驱动。

在这里对速度的检测是双向的，比如高速的hub需要检测所挂上来的设备是高速、全速还是低速，高速的设备需要检测所连上的hub是USB2.0的还是1.x的，如果是前者，就进行一系列动作切到高速模式工作，如果是后者，就以全速模式工作。3.1 由于低速设备D-接有1.5K上拉电阻，当设备接入Hub时，Hub的D-会被拉高，此时Hub会检测到有低速设备接入，而全速和高速设备D+接有1.5K上拉电阻，当USB设备接入USB Hub时，Hub的D+会被拉高，此时Hub会检测到有全速或高速设备接入。

自动为所要复制到alps/vendor/mediatek/proprietary/modem/${modem} 下的文件重命名，并生成一个Android.mk文件，alps/vendor/mediatek/proprietary/该路径下是没有modem这个文件夹的，需要自己创建。SIM掉卡后，首先会有三次fast recovery捡卡机制，若这三次recovery，能将卡找回来，表明受到的是IO干扰，通过reset卡，避开了信号受干扰的时刻，然后能将SIM卡找回来。1.8V的SIM更容易受到这种干扰。

定位过程中最重要的辅助资讯包括时间、位置、星历。 FULL start：没有任何的辅助资讯。相当于end user第一次买到手机后使用定位应用的场景。 COLD start：有时间辅助资讯，end user不会遇到该场景。 WARM start：有时间、位置辅助资讯，end user此次定位距离上次定位超过2～4个小时。 HOT start：有所有的辅助资讯，end user此次定位距离上次定位小于2～4小时。

thermal.conf设计CPU、PMIC、BATTERY等的温度参数，其路径一般在device/目录下，但是这是个加密文件，直接打开的话就是一堆看不懂的字符，需要使用对应的工具来解密，即thermal_config_tool。4、SOC_BY_SW_FG与SOC_BY_HW_FG的区别在于放电电量的获取方式，一个由软件计算获得，一个由硬件模数转换获得。也就是说，在这个项目中，thermal中bcct与abcct都是使能的，但是mtktsAP中使用的是abcct才是我们需要的。

MTK框架可以分为两部分，AP和SCP。AP是主芯片，SCP是协处理器，他们一起工作来处理sensor数据。SCP 是用来处理sensor和audio相关功能和其他客制化需求的一个协处理理器，MTK SCP选择freeRTOS作为操作系统，CHRE是处理传感器相关操作的专门任务。kernel层负责汇总处理sensor传输上来的数据，以及处理应用层传递下来的指令。

processCaptureResult这个接口其实是在ICameraDeviceCallback这个类当中定义的，在openCamera这一节有提及过，在openSession()时，有将ICameraDeviceCallback这个Class传给Hal，更具体地说是Camera3Device，因为Camera3Device有从ICameraDeviceCallback继承，是它的子类。返回的顺序与提交请求的顺序相同。根据camera HAL设备的pipeline深度，可以同时处理多个request。

kernel层负责汇总处理sensor传输上来的数据，以及处理应用层传递下来的指令。