深入理解Android相机体系结构之六

该系列文章总目录链接: https://blog.csdn.net/u012596975/article/details/107135938
本篇是《深入理解Android相机体系结构》连载文章的第六篇。

相机硬件抽象层实现

一、概览

回顾高通平台Camera HAL历史,之前高通采用的是QCamera & MM-Camera架构,但是为了更精细化控制底层硬件(Sensor/ISP等关键硬件),同时方便手机厂商自定义一些功能,现在提出了CamX-CHI架构,由于在CamX-CHI中完全看不到之前老架构的影子,所以它完全是一个全新的架构,它将一些高度统一的功能性接口抽离出来放到CamX中,将可定制化的部分放在CHI中供不同厂商进行修改,实现各自独有的特色功能,这样设计的好处显而易见,那便是即便开发者对于CamX并不是很了解,但是依然可以很方便的加入自定义的功能,从而降低了开发者在高通平台的开发门槛。

接下来我们以最直观的目录结构入手对该架构做一个简单的认识,以下便是CamX-CHI基本目录结构:

该部分代码主要位于 vendor/qcom/proprietary/ 目录下:

其中 camx 代表了通用功能性接口的代码实现集合(CamX),chi-cdk代表了可定制化需求的代码实现集合(CHI),从图中可以看出Camx部分对上作为HAL3接口的实现,对下

通过v4l2框架与Kernel保持通讯,中间通过互相dlopen so库并获取对方操作接口的方式保持着与CHI的交互。

camx/中有如下几个主要目录:

  • core/ : 用于存放camx的核心实现模块,其中还包含了主要用于实现hal3接口的hal/目录,以及负责与CHI进行交互的chi/目录
  • csl/: 用于存放主要负责camx与camera driver的通讯模块,为camx提供了统一的Camera driver控制接口
  • hwl/: 用于存放自身具有独立运算能力的硬件node,该部分node受csl管理
  • swl/: 用于存放自身并不具有独立运算能力,必须依靠CPU才能实现的node

chi-cdk/中有如下几个主要目录:

  • chioverride/: 用于存放CHI实现的核心模块,负责与camx进行交互并且实现了CHI的总体框架以及具体的业务处理。
  • bin/: 用于存放平台相关的配置项
  • topology/: 用于存放用户自定的Usecase xml配置文件
  • node/: 用于存放用户自定义功能的node
  • module/: 用于存放不同sensor的配置文件,该部分在初始化sensor的时候需要用到
  • tuning/: 用于存放不同场景下的效果参数的配置文件
  • sensor/: 用于存放不同sensor的私有信息以及寄存器配置参数
  • actuator/: 用于存放不同对焦模块的配置信息
  • ois/: 用于存放防抖模块的配置信息
  • flash/: 存放着闪光灯模块的配置信息
  • eeprom/: 存放着eeprom外部存储模块的配置信息
  • fd/: 存放了人脸识别模块的配置信息

二、基本组件概念

1. Usecase

作为CamX-CHI中最大的抽象概念,其中包含了多条实现特定功能的Pipeline,具体实现是在CHI中通过Usecase类完成的,该类主要负责了其中的业务处理以及资源的管理。

Usecase类,提供了一系列通用接口,作为现有的所有Usecase的基类,其中,AdvancedCameraUsecase又继承于CameraUsecaseBase,相机中绝大部分场景会通过实例化AdvancedCameraUsecase来完成,它包括了几个主要接口:

  • Create(): 该方法是静态方法,用于创建一个AdvancedCameraUsecase实例,在其构造方法中会去获取XML中的相应的Usecase配置信息。
  • ExecuteCaptureRequest(): 该方法用于下发一次Request请求。
  • ProcessResultCb(): 该方法会在创建Session的过程中,作为回调方法注册到其中,一旦Session数据处理完成的时候便会调用该方法将结果发送到AdvancedCameraUsecase中。
  • ProcessDriverPartialCaptureResult(): 该方法会在创建Session的过程中,作为回调方法注册到其中,一旦Session中产生了partial meta data的时候,便会调用该方法将其发送至AdvancedCameraUsecase中。
  • ProcessMessageCb(): 该方法会在创建Session的过程中,作为回调方法注册到其中,一旦Session产生任何事件,便会调用该方法通知到AdvancedCameraUsecase中。
  • ExecuteFlush(): 该方法用于刷新AdvancedCameraUsecase。
  • Destroy(): 该方法用于安全销毁AdvancedCameraUsecase。

Usecase的可定制化部分被抽象出来放在了common_usecase.xml文件中,这里简单介绍其中的几个主要的标签含义:
Usecase

  • UsecaseName: 代表了该Usecase的名字,后期根据这个名字找到这个Usecase的定义。
  • Targets: 用于表示用于输出的数据流的集合,其中包括了数据流的格式,输出Size的范围等。
  • Pipeline: 用于定义该Usecase可以是使用的所有Pipeline,这里必须至少定义一条Pipeline。
2. Feature

代表了一个特定的功能,该功能需要多条Pipeline组合起来实现,受Usecase统一管理,在CHI中通过Feature类进行实现,在XML中没有对应的定义,具体的Feature选取工作是在Usecase中完成的,通过在创建Feature的时候,传入Usecase的实例的方式,来和Usecase进行相互访问各自的资源。

以下是现有的Feature,其中Feature作为基类存在,定义了一系列通用方法。

几个常用的Feature:

  • FeatureHDR: 用于实现HDR功能,它负责管理内部的一条或者几条pipeline的资源以及它们的流转,最终输出具有HDR效果的图像。
  • FeatureMFNR: 用于实现MFNR功能,内部分为几个大的流程,分别包括Prefiltering、Blending、Postfilter以及最终的OfflineNoiseReproces(这一个是可选择使能的),每一个小功能中包含了各自的pipeline。
  • FeatureASD: 用于AI功能的实现,在预览的时候,接收每一帧数据,并且进行分析当前场景的AI识别输出结果,并其通过诸如到metadata方式给到上层,进行后续的处理。
3. Session

用于管理pipeline的抽象控制单元,一个Session中至少拥有一个pipeine,并且控制着所有的硬件资源,管控着每一个内部pipeline的request的流转以及数据的输入输出,它没有可定制化的部分,所以在CHI中的XML文件中并没有将Session作为一个独立的单元进行定义。

Session的实现主要通过CamX中的Session类,其主要接口如下:

  • Initialize(): 根据传入的参数SessionCreateData进行Session的初始化工作。
  • NotifyResult(): 内部的Pipeline通过该接口将结果发送到Session中。
  • ProcessCaptureRequest(): 该方法用于用户决定发送一个Request到Session中的时候调用。
  • StreamOn(): 通过传入的Pipeline句柄,开始硬件的数据传输。
  • StreamOff(): 通过传入的Pipeline句柄,停止硬件的数据传输。
4. Pipeline

作为提供单一特定功能的所有资源的集合,维护着所有硬件资源以及数据的流转,每一个Pipeline包括了其中的Node/Link,在CamX中通过Pipeline类进行实现,负责整条Pipeline的软硬件资源的维护以及业务逻辑的处理,接下来我们简单看下该类的几个主要接口:

  • Create(): 该方法是一个静态方法,根据传入的PipelineCreateInputData信息来实例化一个Pipeline对象。
  • StreamOn(): 通知Pipeline开始硬件的数据传输
  • StreamOff(): 通知Pipeline停止硬件的数据传输
  • FinalizePipeline(): 用于完成Pipeline的设置工作
  • OpenRequest(): open一个CSL用于流转的Request
  • ProcessRequest(): 开始下发Request
  • NotifyNodeMetadataDone(): 该方法是Pipeline提供给Node,当Node内部生成了metadata,便会调用该方法来通知metadata已经完成,最后当所有Node都通知Pipeline metadata已经完成,Pipeline 便会调用ProcessMetadataRequestIdDone通知Session。
  • NotifyNodePartialMetadataDone(): 该方法是Pipeline提供给Node,当Node内部生成了partial metadata,便会调用该方法来通知metadata已经完成,最后当所有Node都通知Pipeline metadata已经完成,Pipeline 便会调用ProcessPartialMetadataRequestIdDone通知Session。
  • SinkPortFenceSignaled(): 用来通知Session 某个sink port的fence处于被触发的状态。
  • NonSinkPortFenceSignaled(): 用来通知Session 某个non sink port的fence处于被触发的状态
  • 116
    点赞
  • 307
    收藏
    觉得还不错? 一键收藏
  • 29
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 29
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值