Lingbulei的博客

但是随着时代的发展，相机硬件模块越发复杂，所以用于直接控制硬件的驱动层也需要承担更为复杂的控制任务，通过上面的分析，我们可以看到，高通重新设计了一套优秀的KMD框架，在其中加入了更多复杂的控制逻辑，以达到精细化控制底层硬件模块的目的，其中比较重要的是CRM对于子设备的横向控制，这样的好处很明显，降低了UMD控制驱动的难度，UMD只需要将请求通过V4L2框架中的设备节点下发至KMD中，之后便由KMD中的CRM来统一管理，适时地将请求下发给各个子设备，进而控制着底层硬件模块。发生在哪一个阶段呢？

相机驱动层位于HAL Module与硬件层之间，借助linux内核驱动框架，以文件节点的方式暴露接口给用户空间，让HAL Module通过标准的文件访问接口，从而能够将请求顺利地下发到内核中，而在内核中，为了更好的支持视频流的操作，早先提出了v4l(video for linux)视频处理框架，但是由于操作复杂，并且代码无法进行较好的重构，难以维护等原因，之后便衍生出了v4l2框架。按照v4l2标准，它将一个数据流设备抽象成一个videoX节点，从属的子设备都对应着各自的v4l2_subdev实现，并且通过

但是人无完人，框架也是一样，该框架异步化处理太多，加大了定位问题以及解决问题的难度，给开发者带来了不小的压力。注：Camera3Device 其实重定义了camera3_device_t，其中HwDevice对应于camera3_device_t中的hw_device_t，Camera3DeviceOps对应于camera3_device_ops_t，而在HALDevice的初始化过程中，会将CamX实现的HAL3接口的结构体g_camera3DeviceOps赋值给Camera3DeviceOps中。

/此结构体中有open方法//此结构体中有close方法//拓展接口，**Camera HAL3定义的标准接口**void *priv;由定义不难发现，camera_module_t包含了hw_module_t，主要用于表示Camera模块，其中定义了诸如get_number_of_cameras以及set_callbacks等扩展方法；而。

在相机进行专业拍照的时候，状态机进行了改变，走的是非zsl模式，点击拍照会停止预览，然后进行非zsl拍照，可是在停止预览操作到彻底关闭通道和流数据之前查看log发现还会有帧数据进行了上传，这时候状态机是为4的状态下，callback函数那边的playshutter会进行判断，这时候状态机已经为非zsl模式，又有了帧数据，就会进行playshutter。最后，发现原先为了节省硬件成本，将sensor的两个电压相同的模拟电和数字电由同一芯片输出供给，导致两者之间互相干扰，影响了sensor的正常工作。