MTK 平台sensor arch 介绍-hal
一：整体框架
如上图所示：MTK 的senor 架构从大框架上分为 AP侧 与SCP 侧AP 侧 由mtk-Hal 层和 kernel 组成，其主要思想在于实现了一个HfManager 完成了对多个sensor 的control 处理由一个.cpp 处理。这个也是arch 2 区别于arch 1 的一大改变， （注：arch 1 为每一个sensor 的实现由单独的cpp 在kernrl 有单独的.c）
SCP 侧可以理解为 qcom 平台的slpi侧：SCP（Tinysys）协处理器负责传感器和音频相关功能以及其他定制功能。MTK SCP选择FreeRTOS作为操作系统，CHRE是处理传感器相关操作的专门任务FreeRTOS。
二：具体流程简介
AP-HAL:
（1）init & control flow
init flow 函数调用图
- 路径：vendor/mediatek/proprietary/hardware/sensor
- 进入到2.0
hal 层的最主要的实现就在 core 和 hal 两个folder 下 - 进入hal
这一层就是MTK 的hal，入口就在：sensors.cpp
native 通过sensors.cpp 提供的方法 调用如下：
在context 中 对不同的sensor type 分成了如上三个通道：（对比arch 1 在context 这里 的下一步直接是每个不同的senor，为每一个sensor type 提供了一个cpp去实现）
根据MTK hal层的这三个channel 划分规则我觉得不够明显，因为基本上项目囊括的大部分sensortype 都在OriginChannel ，基本思路就是如字面解释，mag 相关的fusion sensor 放在fusion channel，wakeup 的目前只有step_detector
以任意channle 的active 流程继续追下去：
这时候就可以看到mtk 在hal层封装的hfManager 我们进入相关文件中 - 进入core
文件下的HfManager.cpp 主要是实现上层channel 的cmd，然后下发到kernel 对应的hfmanager
而HfManagerWapper.cpp 主要是提供一个C 的api 接口供调用，这个接口就是我们sensor-cali 校准工具与MTK hal的重要接口
我们以前文的originchannel 的 active 为例子，梳理下：
- 在hfmanager 的构造函数中：
我们可以看到hal层的hfmanager 通过打开 kernrl的hf_manager节点，保存fd - active
通过构造函数的的mfd ，使用cmd 为HF_MANAGER_SENSOR_DISABLE/HF_MANAGER_SENSOR_ENABLE 用IO control的方式将 上层的active 下发到kernel 对应节点
（2）data flow
与上面的control flow 一样可以参照这个这个图：
- sensors.cpp
hal层入口提供的sensoes_module_methods 中的open 函数内实现了init_sensors
可以看到将poll_poll的实现赋给了hw_device_t.poll
其调用mSensorManager→pollEvent - sensorsmanager.cpp
紧接着调用 mSensorContext→pollEvent - sensorcontext.cpp – originchannel.cpp
到这里通过区分不同不同channel 调用readevent
在这里我们可以看到一个对象Hflooper 这个就是hfmanager 为上报数据而封装的 - HfManager.cpp
走到hal层的最后一步，可以看到这里通过read 节点的方式，从kernel 获取到event 进行处理
处理流程首先根据不同的event_type 和sensortype 做区分，这里通过switch case 列出了所有的sensortype，比较长。
最重要的是，在这个处理流程把从kernel read 的hf_manager_evet 数据转换填充到android 标准的data sensors_event_t
control_flow&data_flow函数调用图
至此 mtk 平台的hal层 sensor 流程结束