https://blog.csdn.net/huilin9960/article/details/80802560
https://blog.csdn.net/alimingh/article/details/101383160
QMI概述
QMI是高通提供的一种多处理器进程间通信的功能接口，用于AP和BP侧的交互，通俗说法就是让终端设备TE（可以是手机，PDA，计算机）对高通BP侧的AMSS系统进行操作，如调用函数，读取数据，设置其中的NV项等。
其具有的特点如下：
具有同步和异步接口；
支持在在多个处理器之间进行通信；
良好的可扩展性；
支持多客户端并发运行；
支持多个服务端并发运行，且每个服务端还对应多个客户端；
每个服务端还支持版本信息；
QMI的消息路由通过IPC Router来完成，IPC路由器是一个面向消息(message-oriented)的路由器，用于支持Qualcomm commo client interface(QCCI)以及Qualcomm common service interface(QCSI)。
QCCI是一套用于客户端从服务器接收信息或者发送消息到服务器的API集合。
QCSI则是与QMI IDL(interface definition language)自动编译生成的代码一起使用，用于接收客户端的请求及对其作出响应。另外，它也用来发送指示消息(indication message)以及对消息进行编解码(encode/decode)，这个消息由server端主动发出。
每一个服务都对应于一个service.idl的文件定义。.idl文件定义了每一个massage相关的常量，枚举类型以及和消息相关的数据结构。消息的类型有如下三种：
Request message ——一条request消息由客户端发往服务端，并由服务端进行处理。
Reponse message——每一个request的消息都会有一个reponse消息与之对应，类似于一个函数的返回值。如果请求消息等效于调用函数，则响应消息等效于返回给调用方的结果。
Indiction message——这类消息是由服务端发给客户端的异步消息。sensor1 API的规范要求：在任何indication message发送之前，客户端首先需要通过request message与服务端建立连接。indication消息可以在任何时候发送。
客户端与服务端的消息发送形式如下：
请求QMI消息
每一个server都应该支持如下的消息请求，每一条消息都有固定的消息ID，当每一个服务定义了以后，都需要在第一条定义一个cancel的消息类型，第二条为version 的消息。
service {
//! @ID <service-name>_CANCEL
sns_common_cancel_req_msg <service-name>_CANCEL_REQ,
sns_common_cancel_resp_msg <service-name>_CANCEL_RESP
= 0x00; // msg ID 0
//! @ID <service-name>_VERSION
sns_common_version_req_msg <service-name>_VERSION_REQ,
sns_common_version_resp_msg <service-name>_VERSION_RESP
= 0x01; // msg ID 1
… <other service messages go here> …
} = <service-name>_SERVICE_ID;
取消所有的请求cancel msg(message id = 0)
该条消息类型用于取消该客户端与指定服务端的所有消息请求。当该消息请求发送到服务端，服务端将会deregister所有未完成的请求，并且停止向客户端发送indication message。
该消息体可以为null，且reponse消息会携带成功码。
获取版本get version(message id = 1)
该条消息类型用于获取服务端的版本。
QMI消息编码标准
1. 不使用浮点型数据，而是使用Q16类型的固定点数，即提供16位2位补码整数部分和16位小数部分的定点实现。
2. 命名约定
为了使所有消息实现保持一致，service端需要固定的独有的前缀
结构体以_type结尾
枚举以_enum结尾
请求消息以_req_msg结尾，类型以_REQ结尾
消息回应以_resp_msg结尾，类型以_RESP结尾
指示消息以_ind_msg结尾，类型以_IND结尾