Qcom_Sensor(七)--- 之 DSPS架构分析

原文链接: https://blog.csdn.net/huilin9960/article/details/80882346

Qcom_Sensor(七)--- 之 DSPS架构分析

    • 一、Dedicated Sensors Processor Subsystem(DSPS)
      • 1.1 Device Driver Framework(DDF)
      • 1.2 Sensor Manager(SMGR)
      • 1.3 Sensors Algorithm Manager (SAM)
      • 1.4 Sensor Message Router(SMR)
      • 1.5 Qualcomm Messaging Interface(QMI)
      • 1.6 Client Manager(CM)


前面的博文中,我们已经接触并分析了Sensors HAL Library,sensor1 remoting layer(libsensor1)以及SensorDaemon的相关流程,这里先串一下各个部分的主要功能。
  1. Sensor HAL Library
    android的通用HAL接口,高通实现了自己的部分,相关文件为sensors_hal.cpp

  2. sensor1 remoting layer(libsensor1)
    这是一个通信库,通过该库函数提供的API可以允许客户端向SensorDaemon服务端请求消息或者接收来自服务端的消息。

  3. SensorDaemon
    用户空间的一个后台守护进程,用于监听sensor客户端的请求以及通过共享内存与DSPS通信。

这三部分的代码结构如下:
Qcom_Sensor(七)--- 之 DSPS架构分析_第1张图片
那么DSPS是什么呢? 今天我们主要了解下DSPS架构和重要组成部分,
有些知识点会涉及QMI的相关技术QCCI以及QCSI,之前的博客我们也讲解了相关的接口定义,请点击复习

一、Dedicated Sensors Processor Subsystem(DSPS)

如标题所述,DSPS即Dedicated Sensors Processor Subsystem,专用传感器处理器子系统。
下面这张图完整的展示了整个Sensor模块DSPS相关的架构图,包括我们的DSPS部分。

Qcom_Sensor(七)--- 之 DSPS架构分析_第2张图片

我们重点从图中标注的6部分来看,各个部分主要功能是什么。

1.1 Device Driver Framework(DDF)

首先第一部分即Device Driver Framework板块。
这部分即高通的设备驱动框架,而sensor相关的代码则在adsp_proc/Sensors/ddf/下,而驱动代码则在dd路径下,

DDF的主要功能如下:

  1. 完成所有的环境配置
  2. 支持一个驱动控制多个设备
  3. 支持同一设备或类似设备的同一驱动程序的多个实例
  4. 同步异步数据检索
  5. 支持NV参数设定
  6. 驱动属性的运行时配置,如分辨率,范围及功率状态
  7. 访问系统时间以便对于延时代码的执行
  8. 抽象的通信接口以便于扩展
  9. memhandler,内存管理对象,用于分配释放内存

在DDF中有一个非常重要的接口我们已经在之前的相关文章中见过,即sns_ddf_driver_if_s:

typedef struct
{
    /** 
     * 初始化驱动并且开启sensor设备
     * 主要工作: 1. 分配一个驱动实例句柄 2. 打开相关设备的通信端口
     *           3. 配置驱动和设备,将设备设到默认的电源状态
     */
    sns_ddf_status_e (*init)(
        sns_ddf_handle_t*        dd_handle_ptr,
        sns_ddf_handle_t         smgr_handle,
        sns_ddf_nv_params_s*     nv_params,
        sns_ddf_device_access_s  device_info[],
        uint32_t                 num_devices,
        sns_ddf_memhandler_s*    memhandler,
        sns_ddf_sensor_e**       sensors,
        uint32_t*                num_sensors);
        
    /** 
     * 向每一个特定的sensor请求单个数据样本
     * 数据有如下两种方式返回:
     *    (1) 当读到数据的序号相匹配后立即返回
     *    (2) 在sensor需要读取几个步骤的情形下,
     *        以SNS_DDF_PENDING状态通过sns_ddf_smgr_data_notify携带数据异步返回
     */
    sns_ddf_status_e (*get_data)(
        sns_ddf_handle_t         dd_handle,
        sns_ddf_sensor_e         sensors[],
        uint32_t                 num_sensors,
        sns_ddf_memhandler_s*    memhandler,
        sns_ddf_sensor_data_s**  data);
 
    /**
     * 设置sensor指定的属性值
     */
    sns_ddf_status_e (*set_attrib)(
        sns_ddf_handle_t     dd_handle,
        sns_ddf_sensor_e     sensor,
        sns_ddf_attribute_e  attrib,
        void*                value);
 
    /**
     * 获取sensor指定的属性值
     */
    sns_ddf_status_e (*get_attrib)(
        sns_ddf_handle_t       dd_handle,
        sns_ddf_sensor_e       sensor,
        sns_ddf_attribute_e    attrib,
        sns_ddf_memhandler_s*  memhandler,
        void**                 value,
        uint32_t*              num_elems);
      
   /**
    * timer回调,初始化timer时要指定回调方法
    */
    void (*handle_timer)(sns_ddf_handle_t dd_handle, void* arg);
 
   /** 
    * 处理驱动中断
    */
    void (*handle_irq)(
        sns_ddf_handle_t  dd_handle,
        uint32_t          gpio_num,
        sns_ddf_time_t    timestamp);
 
   /**
    * 重置驱动及设备回到init状态
    */
    sns_ddf_status_e (*reset)(sns_ddf_handle_t dd_handle);
 
    /**
     * 运行一个指定的工厂测试,流式数据不能调用该方法
     */
    sns_ddf_status_e (*run_test)(
        sns_ddf_handle_t  dd_handle,
        sns_ddf_sensor_e  sensor,
        sns_ddf_test_e    test,
        uint32_t*         err);
 
    /**
     * 启动设备调度采样,通过DRI使能通知功能
     * 数据就绪后,handle_irq被调用
     */
    sns_ddf_status_e (*enable_sched_data)(
        sns_ddf_handle_t  handle,
        sns_ddf_sensor_e  sensor,
        bool              enable);
 
    /**
     * 根据给定的配置探测设备
     */
    sns_ddf_status_e(*probe)(
        sns_ddf_device_access_s* device_info,
        sns_ddf_memhandler_s*    memhandler,
        uint32_t*                num_sensors,
        sns_ddf_sensor_e**       sensors );
        
    /**
     * 从指定的sensor中检索一组传感器数据,异步API
     * 使用sns_ddf_data_notify_data上报数据
     */
    sns_ddf_status_e (*trigger_fifo_data)(
        sns_ddf_handle_t         dd_handle,
        sns_ddf_sensor_e         sensor,
        uint16_t                 num_samples,
        bool                     trigger_now);
 
    /**
     * 发送一个DAF消息到驱动,异步/同步API
     */
     sns_ddf_status_e (*process_daf_req)(
         sns_ddf_handle_t       dd_handle,
         uint32_t               req_id,
         const void*            req_msg,
         uint32_t               req_size,
         sns_ddf_memhandler_s*  memhandler,
         void**                 resp_msg,
         uint32_t*              resp_size,
         const uint8_t*         trans_id_ptr,
         void*                  conn_handle);
 
    /**
     * 为提供的connect handle取消所有驱动当前的DAF异步事务
     */
     void (*cancel_daf_trans)(
         sns_ddf_handle_t       dd_handle,
         void*                  conn_handle);
} sns_ddf_driver_if_s;

所有的传感器驱动程序都要实现上面的接口,并将其对应的结构体在sns_dd.h中进行声明,如:

extern sns_ddf_driver_if_s sns_dd_mpu6515_if;
extern sns_ddf_driver_if_s sns_accel_driver_fn_list;
extern sns_ddf_driver_if_s sns_accel_adxl350_driver_fn_list;
extern sns_ddf_driver_if_s sns_gyro_driver_fn_list;
extern sns_ddf_driver_if_s sns_mag_driver_fn_list;
………………

1.2 Sensor Manager(SMGR)

第二部分则是Sensor的管理器服务SMGR,其主要功能如下

  1. 首先它在自己的DSPS线程中运行

  2. 可移植到其他目标并可扩展到其他传感器类型

  3. 传感器原始值使用SI单位,二进制缩放Q16,(例外:磁感应器MAG使用高斯(不是SI单位))

  4. 跟踪多个自主客户端请求的所有传感器需求

  5. 维护所有传感器设备驱动程序
    列出所有可用的传感器
    列出每个传感器的属性

  6. 支持客户端自定义的report可操作选择
    每个客户端可以指定不同的报告速率(在传感器支持的最小值和最大值以内)。
    每个报告可以组合任何可用传感器的组合。
    利用硬件滤波实现报告率和数据处理


1.3 Sensors Algorithm Manager (SAM)

第三部分则是sensor algorithm manager,sensor算法管理器,其主要功能如下:

  1. 提供客户端和算法之间的抽象
    只要算法符合简单的SAM接口集,就提供可移植性和重用性
    被许可者可以通过做极小的修改将自己的算法插入-使用到SAM架构中

  2. 是一个控制模块,管理由算法提供的服务
    管理算法和提供算法服务的外部客户端之间的所有交互

  3. 管理所有算法间的交互,例如 算法X 请求 算法Y 的数据

  4. 可以服务运行在不同的处理器上的客户机
    AP
    DSPS
    CP(modem)

  5. 管理算法实例的实例化和销毁
    通过下列方式进行最小内存分配:
    允许多个客户端共享相同的算法实例
    允许多个算法实例共享相同的传感器数据批处理


1.4 Sensor Message Router(SMR)

第四部分则是Sensor Message Router,光从名字就能知道他是负责消息传递用的。
事实上也是这样的,SMR是一个集中在应用程序处理器(ap)、调制解调器处理器(cp/modem)上的消息传递实用程序,

其主要的功能如下:

  1. 支持一个互操作协议,通过该协议将编码的QMI消息打包并发送到接收处理器上的对等实体。

  2. 支持处理器内部的软件协议,其中处理器内部的软件模块在没有QMI编码的情况下进行通信。

  3. 在处理器和模块分区中提供模块位置透明性
    模块可以在与其他模块透明的处理器之间迁移,例如保持相同的接口

  4. 通过部署两个优先级级别来支持消息优先级排序(现在禁用,但是当需要消息优先级时可以启用)

  5. 提供流量控制——SMR保证将消息传递到目的队列,或通知源模块失败。


1.5 Qualcomm Messaging Interface(QMI)

第五部分就是我们已经提到的QMI了。之所以选择QMI作为AP与BP侧的通信协议,高通给出的理由如下:

  1. QMI提供了标准的消息编解码机制
  2. QMI提供的版本支持机制,sensor框架层可以更新消息,添加新的服务且提供向后兼容
  3. QMI不会编码参数块中无用的可选部分,节约IPC通信共享内存
  4. 同一个处理器间的通信不需要进行QMI编解码
  5. Sensors的接口消息都定义在IDL,这遵循命名和转换规则,并将其转换成C类型数据

1.6 Client Manager(CM)

客户端管理器主要用于向客户端提供请求接口,其内部有一个Receive thread,
当有消息从SMR发过来,receive thread查找回调函数,并将该消息通过对应的cb分发至对应的客户端。

其架构图如下:
Qcom_Sensor(七)--- 之 DSPS架构分析_第3张图片
特性如下:

  1. API设计是模块化的,引入新特性时不需要做太多修改;
  2. API依赖于高层操作系统;
  3. 允许内部及外部客户端;
  4. 支持模块化框架设计,用以实现路由消息到当地服务以及DSPS中的服务器;
  5. 提供灵活的线程模型;
  6. 为客户端提供不同优先级服务;

在上面的DSPS架构图中,我们还看到一个模块,叫Sensor Calibration Manager,这个模块主要用于sensor数据校验等,比如出厂设置时的校验等,后面分析数据校验的时候再重点关注这部分。

好了,介绍完DSPS的架构及相关的重要模块,后续的文章我们将重点分析SensoDaemon是怎样通过QCCI, QCSI通信API与DSPS端通信的,欢迎关注。

你可能感兴趣的:(11--Android,Sensor)