OpenHarmony南向之Camera简述

Camera驱动框架

该驱动框架模型内部分为三层，依次为HDI实现层、框架层和设备适配层：

HDI实现层：实现OHOS（OpenHarmony Operation System）相机标准南向接口。
框架层：对接HDI实现层的控制、流的转发，实现数据通路的搭建，管理相机各个硬件设备等功能。
设备适配层：屏蔽底层芯片和OS（Operation System）差异，支持多平台适配。

Camera模块主要包含服务、设备的初始化，数据通路的搭建，流的配置、创建、下发、捕获等。
基于HDF驱动框架的Camera驱动模型

目前，Camera驱动框架主要提供了两种适配方式：V4L2和MPP。

MPP方式主要是针对海思系列的芯片，MPP是海思自己实现的多媒体框架，之前有介绍，具体可参见：Linux之摄像头简述
V4L2方式主要是针对Camera驱动是基于V4L2接口实现的芯片平台，比如Rockchip，展锐等

如果其他芯片平台想适配OH的Camera驱动框架，如果是V4L2实现可参考Rockchip的适配方式，如果是私有实现（比如ioctl方式）则需要自己重新添加新的适配层。

下面是展锐SL8541E平台在OH下的Camera适配框图，更详细，参考Rockchip方案适配的，都是基于V4L2，所以很类似：

Camera 驱动框架所在源码目录为：drivers/peripheral/camera

由上可以看出，Camera 驱动框架最核心的3部分：

pipeline
device_manager
driver_adapter

pipeline控制管理各个硬件模块，首先要获取对应设备的manager，通过manager获取其对应的controller，controller和对应的驱动进行交互

V4L2的适配

这里我们主要看下基于V4L2的适配，以rk3568为例，主要涉及到如下几块：

platform平台通用公共代码: drivers/peripheral/camera/hal/adapter/platform/v4l2
chipset定制化代码: device/board/hihope/rk3568/camera/
hcs配置文件: vendor/hihope/rk3568/hdf_config/uhdf/camera

platform公共代码

platform为平台性公共代码，如linux标准v4l2适配接口定义，为v4l2框架适配的通用node.以及为v4l2框架适配的通用device_manager等
目录结构如下：

drivers/peripheral/camera/hal/adapter/platform/v4l2/src/
├── device_manager
│   ├── enumerator_manager.cpp
│   ├── flash_controller.cpp
│   ├── flash_manager.cpp
│   ├── idevice_manager.cpp
│   ├── isp_controller.cpp
│   ├── isp_manager.cpp
│   ├── sensor_controller.cpp
│   ├── sensor_manager.cpp
│   └── v4l2_device_manager.cpp
├── driver_adapter
│   └── src
│       ├── v4l2_buffer.cpp
│       ├── v4l2_control.cpp
│       ├── v4l2_dev.cpp
│       ├── v4l2_fileformat.cpp
│       ├── v4l2_stream.cpp
│       └── v4l2_uvc.cpp
└── pipeline_core
    └── nodes
        ├── uvc_node
        │   ├── uvc_node.cpp
        │   └── uvc_node.h
        └── v4l2_source_node
            ├── v4l2_source_node.cpp
            └── v4l2_source_node.h

device_manager
device_manager 目录存放着向北与pipeline向南与v4l2 adapter交互的代码。
driver_adapter
driver_adapter 目录中存放着v4l2协议相关代码。可通过它们实现与v4l2底层驱动交互。
pipeline_core
Pipeline_core 目录与 drivers/peripheral/camera/hal/pipeline_core中代码组合为pipeline框架。v4l2_source_node 和 uvc_node为v4l2框架适配的通用node。

chipset定制化代码

chipset为具体某芯片平台相关代码。
目录结构如下：

device/board/hihope/rk3568/camera/
├── demo
│   └── include
│       └── project_camera_demo.h
├── device_manager
│   ├── include
│   │   ├── imx600.h
│   │   ├── project_hardware.h
│   │   └── rkispv5.h
│   └── src
│       ├── imx600.cpp
│       └── rkispv5.cpp
├── driver_adapter
│   └── test
│       ├── unittest
│       │   ├── include
│       │   │   └── utest_v4l2_dev.h
│       │   └── src
│       │       └── utest_v4l2_dev.cpp
│       └── v4l2_test
│           └── include
│               └── project_v4l2_main.h
└── pipeline_core
    └── src
        ├── ipp_algo_example
        │   └── ipp_algo_example.c
        └── node
            ├── rk_codec_node.cpp
            ├── rk_codec_node.h
            ├── rk_exif_node.cpp
            ├── rk_exif_node.h
            ├── rk_face_node.cpp
            └── rk_face_node.h

device_manager目录下存放了rk3568适配过的sensor的相关配置文件，适配的camera sensor 读取设备能力的代码及相关配置文件，其中 project_hardware.h 比较关键，存放了device_manager支持当前chipset的设备列表
pipeline_core路径下存放了由chipset开发者为满足特点需求增加的pipeline node等。

hcs配置文件

device_info
vendor/hihope/rk3568/hdf_config/uhdf/device_info.hcs

...
hdi_server :: host {
    hostName = "camera_host";
    priority = 50;
    gid = ["camera_host", "uhdf_driver", "vendor_mpp_driver"];
    camera_device :: device {
        device0 :: deviceNode {
            policy = 2;
            priority = 100;
            moduleName = "libcamera_host_service_1.0.z.so";
            serviceName = "camera_service";
        }
    }
    ...
}
...

config
vendor/hihope/rk3568/hdf_config/uhdf/camera

vendor/hihope/rk3568/hdf_config/uhdf/camera
├── hdi_impl
│   └── camera_host_config.hcs
└── pipeline_core
    ├── config.hcs
    ├── ipp_algo_config.hcs
    └── params.hcs

hdi_impl下的 camera_host_config.hcs为物理/逻辑Camera配置、能力配置，此处的物理/逻辑Camera配置，需要在hal内部使用，逻辑Camera及能力配置需要上报给上层，需按照所适配的芯片产品添加其能力配置。
pipeline_core下的 config.hcs为pipeline的连接方式，按场景划分每一路流由哪些Node组成，其连接方式是怎样的。使用或新增的node需要在代码中注册。
param.hcs为场景、流类型名及其id定义，pipeline内部是以流id区分流类型的，所以此处需要添加定义。

因config配置文件里面内容比较多，这里就举例了，具体可自行看源码