Android Camera 高通驱动KMD框架_camera request managerfunctionality(1)

weixin-Vip1104z

于 2024-05-13 02:21:23 发布

阅读量1k

点赞数 21

分类专栏：程序员文章标签： android 前端人工智能

本文链接：https://blog.csdn.net/m0_75279794/article/details/138776345

版权

程序员专栏收录该内容

261 篇文章 0 订阅

订阅专栏

一、概览

利用了V4L2可扩展这一特性，高通在相机驱动部分实现了自有的一套KMD框架，该框架通过V4L2标准方法在系统中创建设备节点，将控制接口直接暴露给UMD CSL进行访问，而其内部主要定义了一系列核心模块，包括CRM(Camera Request Manager)，用于管理整个KMD的Session/Link的创建销毁以及Request的在子设备间的流转，该模块创建video0设备节点暴露关键接口给UMD，此外还包括了Sync模块，主要负责了UMD/KMD之间的数据同步与传输，创建video1设备节点暴露接口给UMD进行访问，除此之外，为了更精细化地控制一系列的硬件图像处理模块，包括ISP/IPE/Sensor等硬件模块，高通也分别为各自子模块创建了设备节点，进而暴露控制接口给UMD进行访问。
其中主要目录如下：

cam_core/：关于KMD核心函数的实现都放在这，主要包括了subdev、node、context的一些诸如创建/注册/销毁等标准方法。
cam_req_mgr/: CRM的具体实现，用于创建v4l2_device，用于管理所有的子设备，同时生成video设备节点，暴露控制接口给UMD，主要包括了Session/Link的行为管理以及Request的同步与分发，此外，还创建了media_device，用于暴露枚举接口给UMD来轮询查找整个KMD的子设备。
cam_sync/: 该部分主要实现了用于保持与UMD的图像数据的同步相关业务逻辑，由于该模块的特殊性，高通直接为其创建了一个单独的video设备节点，暴露了用于同步的一些控制接口。
cam_utils/: 一些共有方法的实现，包括debug方法集等
cam_smmu/: 高通自己实现了一套smmu api，供KMD使用
cam_lrme/: 低分辨率运动估计模块的驱动实现
cam_fd/: 人脸识别的驱动程序
cam_isp/: isp的驱动程序
cam_jpeg/: 编码器，可以通过该驱动完成jpeg的编码工作
cam_cdm/: camera data mover，数据移动器的驱动实现，主要用于解析由CSL传入的命令信息，其中包括了寄存器的设置以及图像数据的处理等。
cam_cpas/: 该模块主要用于CSL获取camera 平台驱动信息，IPE/BPS电源控制等
cam_icp/: image control processor ，图像处理控制器驱动实现
cam_sensor_module/: 类传感器的系列硬件模块
cam_actuator/: 对焦马达的驱动实现
cam_cci/: 实现了用于通讯的CCI接口，其中包括了I2C以及gpio的实现
cam_csiphy: 基于MIPI CSI接口的物理层驱动，用于传输图像数据
cam_sensor_io: 使用cam_cci，向上实现了控制sensor的IO接口
cam_sensor: sensor 的驱动实现
cam_sensor_util: sensor相关的公有方法的实现
cam_eeprom: eeprom设备的驱动实现
cam_ois ：光学防抖设备的驱动实现
cam_flash: 闪光灯设备的驱动实现

二、核心模块解析

正如之前介绍的那样，整个框架主要由三个部分组成，CRM/Camera Sync以及子模块，接下来我们以下图为例简单讲解下各自的关系：

在这里插入图片描述

在系统初始化时，CRM内部会创建一个v4l2_device结构体，用于管理所有的子设备，与此同时每一个子设备在注册的时候都会创建各自的v4l2_subdev挂载到该v4l2_device上面。此外，CRM会创建一个video0设备节点提供关键接口给CSL来进行访问，而每个子设备也会在系统中生成各自的v4l2-sbudev设备节点，提供接口给CSL进行更为精细化的控制。而其中的Cam Sync在初始化的过程中，也创建了一个v4l2_device设备，并且生成了video1节点给CSL进行控制。这个框架主要就是围绕这三个部分进行的，CRM用于管理Session/Link的创建，控制Request在各个子设备中的流转，子设备受CSL控制进行配置以及图像处理工作，而一旦图像处理完成便会将结果发送至Cam Sync模块，进上传至CSL中。

1. CRM(Camera Request Manager)

该模块本质上是一个软件模块，主要做了以下几个事情：

接收来自CSL的Session/Link/Request请求，并且维护其在内核的状态。
在不同pipeline delay的子模块间，同步每一个Request状态，并按照需要发送给每一个子设备。
如果出现错误，负责上传至CSL。
负责针对实时子模块的flush操作。

CAM_REQ_MGR_CREATE_SESSION/CAM_REQ_MGR_DESTROY_SESSION：分别表示了Session的创建和销毁，该Session保持着与CamX-CHI的一一对应关系。
CAM_REQ_MGR_LINK/CAM_REQ_MGR_UNLINK：分别表示了Link的创建和销毁动作，每一个Session可以包含多条Link，而每一个Link都连接着此次图像采集过程中所需要的子设备，CRM也是通过该Link来管理Request同步与分发的操作。
CAM_REQ_MGR_SCHED_REQ：一旦CSL开始下发Request的时候，便可以通过该命令告知KMD，而在KMD中，CRM会将此次Request存入Link中的in_q数组中，当子设备告知准备好了此次Request的处理后，便通知子设备进行配置并处理Request。
CAM_REQ_MGR_ALLOC_BUF/CAM_REQ_MGR_RELEASE_BUF: 图像缓冲区的申请与释放，CRM中使用cam_mem_table结构体来管理着申请的缓冲区。

一旦CRM接收了来自CSL的请求，便会在内部进行处理，而其中的一系列业务处理便会通过接下来的几个结构体来完成：

首先在初始化过程中，会去创建一个cam_req_mgr_device。
该结构体有以下几个主要的成员：

video: 存储着对应的video_device。
v4l2_dev: 保存着初始化过程中创建的v4l2_device。
subdev_nodes_created: 标志着从属于v4l2_device的子设备是否都成功创建了设备节点。
cam_eventq： v4l2文件描述结构体，其中维护着event事件队列。
之后会去创建一个cam_req_mgr_core_device，该结构体比较简单主要用于维护一个Session链表，在CSL下发创建Session的动作后，会将创建好的Session放入该量表中，同时通过crm_lock保持着业务处理中的同步。

一个Session可以包含很多条Link，其中变量num_links存储了Link数量，数组links存储着所有link，entry变量作为当前session的实体可以嵌入cam_req_mgr_core_device中的session链表中进行统一管理。

在CSL下发CAM_REQ_MGR_LINK命令的时候，会去创建cam_req_mgr_core_link。
该结构体比较复杂，接下来我们主要介绍下几个主要的变量：

link_hdl：作为该Link的句柄，区别于其它Link。
num_devs：表示了该条Link上连接了多少个子设备。
max_delay：表示了从属于该Link上的所有子设备具有的最大的Pipeline delay值。
l_dev：存储着所有从属于该Link上的子设备，后续对于子设备的控制都是通过该数组来进行的。
req：该成员主要用于管理下发的request。
state: 标志着该Link的状态，而Link状态主要包括了CAM_CRM_LINK_STATE_AVAILABLE/CAM_CRM_LINK_STATE_IDLE/CAM_CRM_LINK_STATE_READY/CAM_CRM_LINK_STATE_ERR几种状态。
创建完Link之后，会将其存入一个存储cam_req_mgr_core_link的全局变量g_links中进行统一管理。

而当下发CAM_REQ_MGR_SCHED_REQ命令的时候，会在内部进行解析，并且将其存入cam_req_mgr_core_link中的cam_req_mgr_req_data中等待后续的流转。
其中in_q变量主要用于存储request，而l_tbl用于记录pipeline delay的相关信息，而apply_data数组用于存储所有的等待处理的request信息。

2. Cam Sync

该模块本质上是一个软件模块，用于保持与UMD的图像数据的同步，主要利用了V4L2框架的event机制，由CSL进行事件的等待，一旦数据处理完毕，该模块便可以向上层发送事件，进而，通知CSL取出数据进行下一步处理，其中包括了几个主要ioctl的命令：

CAM_SYNC_CREATE: 一旦CSL部分需要创建一个用于同步的实体的时候便下发该命令，而在Cam Sync中，会将传入的信息存入内部的sync_table_row数组中进行管理，并且将生成的sync_obj传入上层。
CAM_SYNC_DESTROY：销毁用于同步的sync实体。
CAM_SYNC_REGISTER_PAYLOAD：通过该命令将一些同步的回调方法注册到Cam Sync中，这样一当数据处理完成，Cam Sync便可以由之前创建的sync_obj来找到相应的回调方法，进而调用该回调方法进行后续处理。
CAM_SYNC_DEREGISTER_PAYLOAD：释放之前注册的相关同步实体的信息，包括其回调方法。
CAM_SYNC_SIGNAL：该命令主要用于CamX-CHI中软件Node处理完数据之后，通知Cam Sync进行后续处理的目的。
其中包括了几个比较重要的结构体，首先在初始化过程中会去创建sync_device结构体，其主要的几个变量如下：

vdev: 创建的video_device。
v4l2_dev: 创建的v4l2_device设备。
sync_table: 用于存储sync_table_row的数组。
cam_sync_eventq: v4l2设备描述符结构体，其中维护着event事件队列。
其中最重要的时sync_table中存储的sync_table_row结构体，它代表了整个对应于CSL中的sync object，其中比较重要的变量含义如下：

sync_id：该sync object的唯一标识，同时该标识于CSL保持同步。
state: 代表了当前sync object的状态。
user_payload_list：存储着该sync object所对应的来自UMD的payload，该payload在KMD中并没有被使用，仅仅存储与KMD中，一旦当前sync object被触发，便直接将其再次传入UMD中。

三、模块初始化

在系统启动初期，整个相机驱动中的各个模块都开始进行加载了，接下来我们依次介绍下：

首先是CRM的初始化，按照linux驱动模块的标准方法，会走到module_init宏声明的驱动结构体中的probe方法，这里是cam_req_mgr_probe方法，在该方法中主要做了以下几个事情：

调用cam_v4l2_device_setup方法，创建并向系统注册用于管理所有子设备的v4l2_device。
调用cam_media_device_setup方法，创建并向系统注册media_device，并且创建了media设备节点，用于CSL枚举KMD中所有设备。
调用cam_video_device_setup方法，创建video_device，并将v4l2_device嵌入到该结构体中，紧接着，使用标准的video注册方法，创建了video0设备节点，其中将g_cam_ioctl_ops方法集作为了video0的扩展方法，CSL下发的有关Session/Link/Request的诸多操作都是通过该方法集来进行分发的，最后将video0 media_entity中的function赋值CAM_VNODE_DEVICE_TYPE，这样CSL便可以通过该function判断出该节点便是CRM了。
调用cam_req_mgr_util_init方法，其中初始化了一个cam_req_mgr_util_hdl_tbl，该结构体中存在一个handle数组，而每一个handle主要用于存储Session、Link以及各个子设备的相关信息，后期在整个图像采集的过程中，都是通过该结构体来找对应的操作实体，进而采取相应的动作。
调用cam_req_mgr_core_device_init方法，该方法中，会去创建并初始化一个cam_req_mgr_core_device结构体，作为全局变量g_crm_core_dev存在于整个框架中，而该结构体中主要包含了用于存储创建的Session的session_head链表，以及用于保护Session临界资源的crm_lock。
其次，是Cam Sync的初始化，整个流程最终会走到驱动结构体中的probe方法中，这里是cam_sync_probe方法，在该方法中主要做了以下几个事情：

创建sync_dev结构体，该结构中通过一个sync_table_row数组来维护着所有的sync objects。
调用cam_sync_media_controller_init方法，用于创建media_deivce设备，并且创建了media设备节点，提供给CSL枚举子设备的能力。
调用v4l2_device_register方法，创建并像系统注册一个v4l2_device结构体，其中用于ioctl的方法集是指向的g_cam_sync_ioctl_ops，一旦CSL有创建/注册sync objects需求的时候，便会最终走到该方法中，从而实现相应的功能。
调用video_register_device方法，生成video1设备节点，暴露控制接口给CSL。
调用cam_sync_init_entity方法，将video1中的meida_entity中function字段赋值CAM_SYNC_DEVICE_TYPE，这样在UMD就可以通过相应的media节点枚举出该模块。
以上两个模块都是具有独立的video设备节点的，但是对于子设备而言，由于代表着相应的硬件设备，同时需要嵌入到整个框架中才能正常运行，所以高通将其抽象成了v4l2_subdev来进行管理，这里主要还是介绍两个比较有代表性的子模块，ISP以及Sensor。

首先来看下ISP的初始化阶段，在其相应的probe方法cam_isp_dev_probe中做了如下几个事情：

调用cam_subdev_probe方法，在该方法中，会去注册一个v4l2_subdev，并且将其挂载到CRM中的v4l2_device上，同时还创建了一个node，并且存入了v4l2_subdev中的token中，方便以后进行读取，另外，将方法集赋值为cam_subdev_ops，最后，创建了该v4l2_subdev内部的media_entity，并且为其function字段赋值为CAM_IFE_DEVICE_TYPE，这样也方便在枚举子设备时分辨出当前节点代表着isp模块。
调用cam_isp_hw_mgr_init方法，该方法用于初始化isp中的硬件模块。
调用cam_isp_context_init方法，该方法中会初始化node，在node内部创建一定数量的context，用于后期的状态维护，并且为每一个context都配置了状态机，以及子状态机来用于管理整个isp模块。
其次来看下Sensor模块的初始化，在其相应的probe方法cam_sensor_driver_i2c_probe中主要做了以下几个事情：

调用cam_sensor_parse_dt方法获取dts中定义的硬件信息。
调用cam_sensor_init_subdev_params方法，该方法中会创建v4l2_subdev，然后挂载到CRM中的v4l2_device中，并且将sensor的私有方法集cam_sensor_internal_ops赋值给v4l2_subdev结构体中的ops，这样一旦操作相应的子设备节点，便最终会走到该方法集中，关于Sensor的一些操作便可以放到这个里面进行处理。最终将创建的v4l2_subdev中的media_entity中functon赋值为CAM_SENSOR_DEVICE_TYPE，方便CSL进行枚举Sensor设备。
通过上面的两个子设备的初始化代码梳理，不难发现，并没有进行设备节点的创建，那关于节点的创建动作发生在哪一个阶段呢？为了解决这个疑问我们不得不先介绍下linux两个宏定义，一个是module_init，另一个便是late_initcall，两者都是为了声明初始化函数，但是执行时间有一个先后顺序，而late_initcall一般在所有module_init定义的方法都运行完成之后才会被运行，而针对所有子设备的节点的创建便是在这里完成的，在该方法中主要做了以下工作：

调用cam_dev_mgr_create_subdev_nodes方法，而在该方法中会去调用v4l2标准方法v4l2_device_register_subdev_nodes来统一创建挂载在CRM中v4l2_device下的子设备节点。
至此，整个KMD框架便初始化完成，现在便静静等待CSL下发请求。
四、处理UMD CSL请求
整个KMD的初始化动作在linux内核启动的时候完成的，要稍早于CamX-CHI整个框架的初始化，所以在CamX-CHI进行初始化的时候，KMD框架的各个资源节点都已准备妥当，接下来我们就以CamX-CHI的初始化开始详细描述下整个KMD处理来自CSL请求的流程。

1. 获取模块资源

在CamX-CHI初始化的时候，并不知道内核驱动部分是个什么状态，所以需要打开所有的media设备节点来枚举查询每一个驱动模块。

首先，打开media0，根据CAM_VNODE_DEVICE_TYPE信枚举并找到KMD框架中的CRM模块，并调用标准open方法来打开该设备，该动作最终会调用到cam_req_mgr_open方法，该方法主要做了以下几个工作：

调用v4l2_fh_open方法，打开v4l2文件。
调用cam_mem_mgr_init方法，初始化了内存管理模块，为之后的缓冲区的申请与释放做好准备。
更新CRM状态为CAM_MEM_MGR_INITIALIZED。
在打开video0之后，会另起一个线程用于监听video的事件，这样就建立了与底层的双向通讯，而在此之前，需要通过ioctl方法将CSL需要监听的事件下发到驱动层，其中包括以下几个事件：

V4L_EVENT_CAM_REQ_MGR_SOF/V4L_EVENT_CAM_REQ_MGR_SOF_BOOT_TS：一旦底层产生的SOF事件，便会向CSL发送该事件。