高通android QMI机制
原文（有删改）：https://blog.csdn.net/u012439416/category_7004974
概论
Qualcomm MSM Interface,作用用于AP和BP侧的交互，通俗说法就是让设备终端TE（可以是手机，PDA，计算机）
对高通BP侧的AMSS系统进行操作，如调用函数，读取数据，设置其中的NV项等。
QMI的核心称之为QMI框架（QMI Framework），其主要功能包括以下3点：
-
连接MSM模块和设备终端，提供一个正交的控制和数据通道。在QMI的消息用有两种定义，一种是QMIControl Message；另一种是QMI DataMessage，支持这两种消息并发，不会互相干扰导致出错。
-
列举一系列的枚举逻辑设备，提供给连接使用。QMI机制类似于一个服务器机制，有相应的client端和services端，对应于QMI的control point和service。在AP向BP发送请求时，AP作为client端，当AP接收BP侧返回的响应时，AP作为services端。QMI包含了一系列的QMI Service，例如nas,voice,wds等，这些不同的services相当于不同逻辑设备，给不同的app调用。
-
QMI有相应的消息和消息的协议，设备终端就是通过这些消息来访问AMSS。对于不同的qmi消息，消息长度不一样，可自己定义消息长度，不同的qmi消息，消息格式是相同的。
上图是QMIFramework的一个软件结构图。
从图中可以看出，上层控制点打包对应类型的QMI消息或通过其他操作系统的框架，将要发出的数据传到AP侧底层的逻辑设备，最后逻辑设备通过内联的总线接口，传到BP侧的AMSS。在代码中可以找到从控制点发送到逻辑设备的函数。
rrno_enum_type qcril_qmi_client_send_msg_sync {
qcril_qmi_client_e_type svctype,
unsigned long msg id,
*void req_c struct,
int reg_c_struct_len,
void *resp_c_struct,
int resp_c_struct_ len
}
这个是控制点向BP侧发送同步消息的函数，参数包括走的QMI_Service类型，Service里面消息的名称，请求消息的初始地址，长度，返回相应的初始地址和长度。逻辑设备和BP侧内联的总线也可以分很多种：
USB,SDIO，共享内存，无线协议802.11等都可以作为总线连接AP和BP。
咱们现在开发的MSM平台用的是共享内存。代码中qmi_port_defs.h中的枚举qmi_connection_id_type定义了AP侧QMI和BP侧的连接通道，包括集成modem的MSM平台和独立modem的MDM。
QMI_CONN_ID_RMNET_O = QMI_CONN_ID_FIRST,//Correspond
QMI_cONN_ID_RMNET_1, //corresponds to SMD DAT,
QMI_cONN_ID_RMNET_2; //Corresponds to SMD DAT,
QMI_cONN_ID_RMNET_3,
QMI_cONN_IDLRMNET_4,
QMI_cONN_ID_RMNET_6,
QMI_cONN_ID__RMNET_7,
在代码中的vendor\qcom\proprietary\qmi\platform目录，linux_qmi_qmux_if_client.c，定义了和BP侧通信的逻辑设备种类。
static linux_qmi_qmux_if_conn_sock_info_t linux_qmi_qmux_if_client_conn_socks[]=
#ifdef FEATURE_QMI_ANDROID
/*Radio Group Client Process */
{ "radio", QMI_QMUX_IF_RADIO_CLIENT_SOCKET_PATH, QMIL_QMUx_IF_RADIO_CONN_SOCKET_PATH },
/* Audio Group Client Process */
{ "audio", QMI_QMUX_IF_AUD1O_CLIENT_SOCKET_PATH, QMI_QMUX_IF_AUD1O_CONN_SOCKET_PATH },
/* Bluetooth Group Client Process */
{ "bluetooth"，QMil_QMUX_IF_BLLETOOTH_CLIENT_SOCKET_PATH,QMIl_QMUX_IF_BLETOOTH_CON_SOCKET_PATH },
/*GPS Group Client Process */
{ "gps", QMI_QMUX_IF_GPS_CLIENT_SOCKET_PATH, QMI_QMUX_IF_GPS_CONN_SOCKET_PATH }
#endif
目前我们QMI支持的逻辑设备有图中四种，电话系统，音频，蓝牙，GPS。
TE和MSM通信原理图：
两个特点：
1.单一的物理链接总线，必须被多个逻辑设备所复用。
2．不同的逻辑设备要求独立的控制信道和数据信道。
QMI终端原理图如下：
从图中可看出，整个QMI架构中，主要是通过QMUX层完成软件上的TE和MSM的交互。
- 1,一个服务可以对应多个控制点，一个控制点只能对应一个服务。
- 2,控制点与服务的关系就好比C/S模型中的客户端与服务器关系。
- 3,如果某程序使用几种QMI服务，那么它就要为每种服务构建一个控制点。
可以看出QMI并不是一个简单的一对一传输通信方式，而是一个服务可以同时接受几个控制点发出的消息，
其实现的原理也是对传输信道的复用。
复用协议QMUX
QMI Multiplexing Protocol（QMUX）：QMI的复用协议
消息从控制点经过类似socket的线程传到QMI接口后，QMI负责对数据进行封装，加上QMUX消息的头，发送到QMUX层，再通过QMUX层传到共享内存到BP侧。
QMUX消息的格式
整个QMUX控制信道的结构如上图，
- I/FType：QMI将控制点数据封装后，发送到QMUX前，加的消息头，长度为一个byte，值通常为0x01，表示这个消息为QMUX消息，如果是其他值，则为其他消息。
- Length： QMUX消息的长度，不包括I/F Type。
- ControlFlags:控制位，表示消息传输的方向。长度为1个byte，只有第7个bit是标志位，其他位为0，bit7=1说明QMUX消息由服务端发送，bit7=0由控制点发送。
- Clien ID: 控制点的标识，在控制点和服务端都需要赋值，当在服务端发出的消息Client ID的值为0xFF，表示该消息为广播消息，由服务端主动发出，被所有控制点搜到。
QMUX SDU和TLV结构：
在整个控制信道的消息中，出去消息标识头I/F Type，和QMUX消息头，数据传输在QMUXSDU中完成，QMUX SDU里面的数据需要支持Type Length Value(TLV)的格式。
TLV格式的数据存放在QMI Service Message里面的Value中。
Control Flags：表示消息是请求、响应还是指示。Datasheet见文档。
TLV结构图：
QMUX消息类型
1、请求：请求消息用于设置参数、查询参数值或配置指示的产生。请求消息由控制点产生，一个有效的请求通常会产生来自服务的应答。
2、响应：响应由服务产生，为回应接收到的请求。每个响应至少包含指示请求成功或失败的结果参数以及错误状态。
3、指示：指示由服务端主动发出，为了让控制点知道底层状态的变更，类似于信号强度，掉网Out of Service都是服务端主动发出给控制点的指示。
Qcril初始化流程
rild守护进程的rild.c文件中main方法有关加载动态库代码如下：
dlHandle = dlopen(rilLibPath, RTLD_NOW);//加载库
// ...
funcs = rilInit(&s_rilEnv, argc, rilArgv);//初始化 实际调用的是RIL_Init方法
s_rilEnv结构体定义如下：也就是qcril.c可以回调ril的方法：
static struct RIL_Env s_rilEnv = {
RIL_onRequestComplete,
RIL_onUnsolicitedResponse,
RIL_requestTimedCallback
};
Android平台不同厂商的AP侧可以相同，但是Modem侧肯定会有很大的差异，RIL层要解决一个问题：就是适配不同厂商的Modem，为了达到兼容性要求，android在AP与Modem之间搭建了RILC的框架，由不同的Modem厂商将自己的协议连接到AP侧。
对于高通平台来说，RILC就是QCRIL。
qcril.c的RIL_Init方法主要步骤如下：
//设置线程的名字
qmi_ril_set_thread_name( pthread_self() , QMI_RIL_QMI_RILD_THREAD_NAME);
//初始化接收Modem消息的EventLoop
qcril_event_init();
// 初始化QCRIL各个模块
qcril_init(c_argc, c_argv);
// 启动线程
qcril_event_start();
//其他初始化
qmi_ril_initiate_bootup();
//返回接口函数
return &qcril_request_api[ QCRIL_DEFAULT_INSTANCE_ID ];
初始化流程图如下：
初始化EventLoop过程
在Qcril中搭建了EventLoop循环用于检测Modem上报的消息，而EventLoop机制的初始化工作是在 qcril_event_init()中完成的。
qcril_event.c的qcril_event_init方法主要部分如下：
//创建线程,入口方法为qcril_event_main
ret = pthread_create(&qcril_event.tid, &attr, qcril_event_main, NULL);
// ...
//设置线程的名字为event
qmi_ril_set_thread_name(qcril_event.tid, QMI_RIL_EVENT_THREAD_NAME);
在初始化过程中，通过pthread_create()函数创建了EventLoop线程，并且指出该线程的入口方法为qcril_event_main(),主要逻辑如下：
qcril_event_init_list(&qcril_event.list); //初始化qcril_event.list链表
// ...
ret = pipe(filedes); //创建管道
// ...
while (qcril_event.started < 2) //阻塞等待qcril初始化
{
QCRIL_LOG_VERBOSE("Event thread waiting for started == 2 (%d)", qcril_event.started );
pthread_cond_wait(&qcril_event_startupCond, &qcril_event.startup_mutex);
}
// ...
for (;;) // for循环读取qmi底层发送的请求
{
// ...
//阻塞等待接收内容
n = select(qcril_event.fdWakeupRead + 1, &rfds, NULL, NULL, NULL);
// ...
do //读取qmi内容
{
ret = read(qcril_event.fdWakeupRead, &buff, sizeof(buff));
// ...
//处理qmi发送的请求
err_no = qcril_process_event( ev->instance_id, ev->modem_id, ev->event_id,
ev->data, ev->datalen, ev->t );
// ...
在以上过程中，完成qcril_event.list链表的初始化，然后通过pthread_cond_wait进入阻塞状态，当被解锁后以及进入EventLoop循环，检测到事件后，通过qcril_process_event处理。
初始化qcril各个模块
Qcril在接到RILC的请求后，需要根据请求的类型将消息派发给不同的负责模块，而qcril_init()就是完成各个模块的初始化工作。
qcril_init方法部分代码如下：
qcril_arb_init();
qcril_init_state();
qmi_ril_oem_hook_init();
qcril_db_init();
qcril_init_hash_table();//初始化Event table
qcril_reqlist_init();
// ...
在这里对qcril的各个模块进行初始化。其中完成了很重要的一步就是将qcril_event_table表拷贝给qcril_hash_table，用于onRequest时对各种请求进行处理, qcril_init_hash_table方法如下：
for (reg_index = 0; reg_index < QCRIL_ARR_SIZE( qcril_event_table ); reg_index++)
// ...
qcril_hash_table[hash_index] = &qcril_event_table[reg_index];
// ...
qcril_event_table是一个静态表单, 里面保存了所有RILC中下发请求的ID以及相应的处理函数，表单部分内容如下：
{ QCRIL_REG_ALL_STATES( QCRIL_EVT_UIM_QMI_COMMAND_CALLBACK,
qcril_uim_process_qmi_callback ) },
里面每一项都包含两个元素：事件ID和处理函数，在处理这些消息时将会根据事件的ID查找并执行相应的处理函数。
? 比如，对于得到当前SIM卡状态这个请求，对应的ID为RIL_REQUEST_GET_SIM_STATUS，而其处理方法为qcril_uim_request_get_sim_status。
启动EventLoop线程
初始化EventLoop时，在完成其链表的初始化过程后，通过pthread_cond_wait()将其阻塞，而现在要做的就是取消其阻塞状态，使其进入消息检测循环。
这是在qcril_event_start方法中完成的：
void qcril_event_start( void )
{
QCRIL_MUTEX_LOCK( &qcril_event.startup_mutex, "[Main Thread]
qcril_event.startup_mutex" );
qcril_event.started = 2; //更新状态
pthread_cond_broadcast(&qcril_event_startupCond);
//释放EventLoop锁
QCRIL_MUTEX_UNLOCK( &qcril_event.startup_mutex, "[Main Thread]
qcril_event.startup_mutex" );
}
由于EventLoop被初始化后一直处于阻塞状态，所以在这里将started状态置为2后，对qcril_event_startupCond进行解锁，从而使EventLoop进入循环。
3.4其他初始化过程
在qmi_ril_initiate_bootup方法如下：
qcril_setup_timed_callback( QCRIL_DEFAULT_INSTANCE_ID,
QCRIL_DEFAULT_MODEM_ID, qmi_ril_bootup_perform_core_or_start_polling, NULL,
NULL );
qmi_ril_bootup_perform_core_or_start_polling方法部分代码如下：
init_res = qmi_ril_core_init();//qmi初始化
qmi_ril_core_init方法调用qcril_qmi_client_init方法完成qcril客户端的初始化。
res = qcril_qmi_client_init();
将回调函数注册给RILC
在Qcril的初始化完毕后，将自己的函数列表返回给RilC，也就是qcril_request_api:
static const RIL_RadioFunctions qcril_request_api[] = {
{ RIL_VERSION, onRequest_rid, currentState_rid, onSupports_rid, onCancel_rid, getVersion_rid }
};
这样的话，在RIL中调用的接口就会进入该函数列表中进行处理。
这样准备工作就完成了
QCRIL消息发送
当ril有请求过来时，就会调用ril库的onRequest()方法，此时就会根据当前Qcril注册的函数列表进入到qcril_request_api的onRequest_rid方法中,因此, onRequest_rid方法是QCRIL中的入口方法。调用的流程如如下：
qcril_execute_event首先调用qcril_hash_table_lookup方法从表中查找当前的Event，如果没有找到当前的Request，就认为非法，找到之后，进入qcril_dispatch_event()中派发该Event
(entry_ptr->handler)(params_ptr, &ret);
ret是返回的结果,通过entry_ptr->handler调用当前Event的处理函数。这里的handler对应qcril_hash_table中的某一项。第一章中将qcril_event_table表中的数据拷贝给了qcril_hash_table，所以这里的handler可以理解为qcril_event_table中的某一项。
之后的流程就会进入到某个具体请求的处理函数中，比如打电话是对应的请求是RIL_REQUEST_DIAL，其处理函数为：qcril_qmi_voice_request_dial;挂断电话对应的请求是RIL_REQUEST_HANGUP, 其处理函数为qcril_qmi_voice_request_hangup;
qcril_qmi_voice_request_hangup方法进一步调用qcril_qmi_client_send_msg_async发送到QMI层。
当然, qcril_qmi_client_send_msg_async是异步处理的, qcril_qmi_client_send_msg_sync是同步处理的。
最后,这2个方法都会调用qmi_client_send_msg_sync完成发送。
一些其他的处理方法或者会调用这两个方法发送到QMI层,或者直接调用qmi_client_send_msg_sync发送。
2.1 QMI层消息处理
调用流程图如下：
ril_err = qcril_qmi_client_send_msg_async ( QCRIL_QMI_CLIENT_VOICE,
QMI_VOICE_ANSWER_CALL_REQ_V02,
&ans_call_req_msg,
sizeof(ans_call_req_msg),
ans_call_resp_msg_ptr,
sizeof(*ans_call_resp_msg_ptr),
(void*)(uintptr_t)user_data);
这里选择的qmi_service是voice。之所以选择voice作为发送通道，是因为第二个参数QMI_VOICE_GET_CONFIG_REQ_V02。
qcril_qmi_client_send_msg_async方法主要逻辑如下：
if (NULL != client_info.qmi_svc_clients[svc_type])
{
qmi_error = qmi_client_send_msg_async_with_shm(client_info.qmi_svc_clients[svc_type],
// ...
}
这个函数首先会去判断我们调用的这个voice的服务类型是否存在于QMI定义的服务列表中，如果不存在，还需要自己添加该service,如果存在，执行QMI client端发送消息的接口函数qmi_client_send_msg_async_with_shm。
该方法直接调用qmi_client_send_msg_sync方法，
rc = qmi_client_send_msg_sync(user_handle,
msg_id,
req_c_struct,
req_c_struct_len,
resp_c_struct,
resp_c_struct_len,
timeout_msecs);
同步消息在QMUX层发送到BP侧后，会一直等待BP的响应所以函数的最后一个参数是一个timeout，而异步消息不需要。
qmi_client_send_msg_sync方法首先计算请求消息的长度和设定返回消息的最大长度，然后对请求消息按QMUX格式进行编码通过函数qmi_service_send_msg_sync_millisec()发送出去，最后等待BP侧返回的响应，将返回的response进行解码。
2.2 QMUX层消息处理
QMUX消息处理流程图如下：
qmi_service_send_msg_sync_millisec方法首先去获取一些QMUX层所需要的消息，发送通道的conn_id。
QMUX消息格式用到的client_id
conn_id = QMI_SRVC_CLIENT_HANDLE_TO_CONN_ID (user_handle);
client_id = QMI_SRVC_CLIENT_HANDLE_TO_CLIENT_ID (user_handle);
然后打包到一个传输消息的结构体 qmi_service_txn_info_type *txn，这个txn在稍后跟进代码中会发现，就是QMUX消息中的tranciationID
/* Initialize Id fields */
txn->conn_id = conn_id;
txn->service_id = service_id;
txn->client_id = client_id;
txn->msg_id = msg_id;
txn->api_flag = api_flag;
/* Initialize fields */
txn->srvc_txn_info.txn_type = QMI_TXN_SYNC;
txn->srvc_txn_info.sync_async.sync.user_reply_buf = NULL;
txn->srvc_txn_info.sync_async.sync.user_reply_buf_size = 0;
txn->srvc_txn_info.sync_async.sync.rsp_rc = QMI_NO_ERR;
txn->srvc_txn_info.sync_async.sync.qmi_err_code = QMI_SERVICE_ERR_NONE;
这些完成之后，调用qmi_service_send_msg方法发送,该方法会判断服务ID和通道的conn_id是否有效：
if ((int)conn_id >= (int)QMI_MAX_CONN_IDS)
{
return QMI_INTERNAL_ERR;
}
if ( qmi_qcci_internal_public_service_id_to_bookkeeping_service_id ( service_id ) >=
QMI_MAX_SERVICES)
{
return QMI_INTERNAL_ERR;
}
首先调用qmi_service_write_std_srvc_msg_hdr,方法给发送过来的消息加上message ID和Length，
if (qmi_service_write_std_srvc_msg_hdr (&msg_buf,
&msg_buf_size,
msg_id,
msg_buf_size) < 0)
所以不难猜测，在QMI发送端的接口函数qmi_client_send_msg_sync（）中编解码的原理是按照QMUX消息中的TLV格式进行编解码。
再走到这步加上message ID和Length，整个QMUX SDU中的QMI service message已完成。
qmi_service_write_std_srvc_msg_hdr方法如下：
static
int qmi_service_write_std_srvc_msg_hdr (unsigned char **msg_buf,
int *msg_buf_size, unsigned long msg_id, int length)
{
unsigned char *tmp_msg_buf;
/* Back pointer up by 4 bytes */
*msg_buf -= QMI_SRVC_STD_MSG_HDR_SIZE;
*msg_buf_size += QMI_SRVC_STD_MSG_HDR_SIZE;
tmp_msg_buf = *msg_buf;
/* Write the message ID field (16 bits) */
WRITE_16_BIT_VAL (tmp_msg_buf,msg_id);
/* Write the length field */
WRITE_16_BIT_VAL (tmp_msg_buf,length);
return 0;
}
加message ID和Length的方法：消息指针的偏移。指针向前偏移，消息长度增加。
随后用类似方法，通过函数qmi_service_write_std_txn_hdr_and_inc_txn_id （）将control flags和tranciation ID加上，完成整个QMUX SDU。
最后通过函数qmi_qmux_if_send_qmi_msg（）发送到QMUX层，到这里，整个QMI interface的流程走完。
- 主要作用：获取上层发送的请求，选择相应的serviceid,conn_id,client id，对消息完成整个QMUX SDU的封装，发送到QMUX。
函数qmi_qmux_if_send_qmi_msg（）的工作是：
- 对上层发过来打包好的QMUX SDU完成加QMUX HEADER的工作。添加QMUX header的方法同样是指针偏移。
qmi_qmux_if_send_qmi_msg方法直接调用qmi_qmux_if_send_to_qmux方法进行处理,首先将QMUX header里面的控制位，QMI服务ID，QMI客户端ID打包到结构体hdr，再通过Memcpy完成：
/* Set up message for sending */
memset(&hdr, 0, sizeof(qmi_qmux_if_msg_hdr_type));
hdr.msg_id = msg_id;
hdr.qmux_client_id = qmux_client_id;
hdr.qmux_txn_id = qmux_txn_id;
hdr.qmi_conn_id = qmi_conn_id;
hdr.qmi_service_id = qmi_service_id;
hdr.qmi_client_id = qmi_client_id;
hdr.control_flags = 0; // Unused for TX to QMUX, only valid for RX
/* Decrement msg pointer and increment msg_len */
msg -= QMI_QMUX_IF_HDR_SIZE;
msg_len += (int)QMI_QMUX_IF_HDR_SIZE;
/* Copy header into message buffer */
memcpy ((void *)msg, (void *)&hdr, QMI_QMUX_IF_HDR_SIZE);
到这里整个QMUXMessage完成封装。然后会把封装好的QMUXmessage发到下层，通过调用宏QMI_QMUX_IF_PLATFORM_TX_MSG（）。
这个宏定义了函数linux_qmi_qmux_if_client_tx_msg（）。
qmi_platform_qmux_if.h中宏QMI_QMUX_IF_PLATFORM_TX_MSG定义如下：
#define QMI_QMUX_IF_PLATFORM_TX_MSG(client,msg,msg_len) linux_qmi_qmux_if_client_tx_msg (client,msg,msg_len)
因此,调用宏QMI_QMUX_IF_PLATFORM_TX_MSG就是调用linux_qmi_qmux_if_client_tx_msg方法，该方法通过socket，将消息发到linux_qmi_qmux_if_server的接口。
if ((rc = send (client_fd,
(void *) msg,
(size_t) msg_len,
MSG_DONTWAIT | MSG_NOSIGNAL)) < 0)
底层消息发送
在linux_qmi_qmux_if_server.c文件的入口main（）函数，通过一个select来监听所有从linux_qmi_client端发出的socket，通过for循环调用linux_qmi_qmux_if_server_process_client_msg（）处理这些监听的消息。进入到函数linux_qmi_qmux_if_server_process_client_msg（）后，
通过recv函数将监听的socket的消息写入buf_size这个buffer里面。调用流程图如下：
if ((buf_size = recv (fd, (void*)&platform_msg_hdr,
QMI_QMUX_IF_PLATFORM_SPECIFIC_HDR_SIZE,0))<= 0)
recv方法在接收socket时，并没有全部接收。而且只接收了platform_msg_hdr。这个platform_msg_hdr是在linux_qmi_qmux_client里面定义的，server接收到后，首先会判断从client端发过来的这个消息是否正常，包括client_id和消息长度。
remaining_bytes = (size_t) platform_msg_hdr.total_msg_size - QMI_QMUX_IF_PLATFORM_SPECIFIC_HDR_SIZE;
if ((buf_size = recv (fd, (void *)linux_qmi_qmux_if_rx_buf, remaining_bytes, 0)) <= 0)
如果client_id匹配不上 或时消息长度溢出，都会将消息丢弃，不会发送。如果判断消息没问题，就会将其余的消息（除去platform_msg_hdr）再次通过recv()函数从socket中接受，放到remaining_bytes这个buffer中，用qmi_qmux_tx_msg方法继续处理。
在qmi_qmux_tx_msg（）函数中，又会对之前打包好的QMUX消息进行去头，拆分。
判断QMUX header中的message_id,如果是QMI_MSG，则会调用函数qmi_qmux_tx_to_modem（），将拆分后的service_id,client_id等发送到下层。
{
rc = qmi_qmux_tx_to_modem( msg_hdr.qmi_conn_id,
msg_hdr.qmi_service_id,
msg_hdr.qmi_client_id,
msg,
msg_len );
}
接下来在函数qmi_qmux_tx_to_modem（），对QMUX整个控制信道消息的头进行一个重组，包括I/F Type。
完成QMI整个control channel message的构建。
/* I/F type is 1 for a QMUX message */
WRITE_8_BIT_VAL (tmp_msg_ptr, 1);
/* Length is length of message to send which includes the QMUX header, but since
** QMI_QMUX_HDR_SIZE includes the I/F byte and the length field in a QMUX
** message doesn‘t include this, we need to subtract 1
*/
WRITE_16_BIT_VAL (tmp_msg_ptr, (msg_len - 1));
/* Control flags byte should be set to 0 for control point */
WRITE_8_BIT_VAL (tmp_msg_ptr, 0);
/* Now put in service type and client ID */
WRITE_8_BIT_VAL (tmp_msg_ptr, service_id);
WRITE_8_BIT_VAL (tmp_msg_ptr, client_id);
然后通过宏QMI_QMUX_IO_PLATFORM_SEND_QMI_MSG调用ARM侧进入共享内存和BP侧交互的IO口函数linux_qmi_qmux_io_send_qmi_msg（），
qmi_platform_qmux_io.h中的宏定义如下：
#define QMI_QMUX_IO_PLATFORM_SEND_QMI_MSG(conn_id,msg_buf,len) linux_qmi_qmux_io_send_qmi_msg (conn_id,msg_buf,len)
在这个linux_qmi_qmux_io_send_qmi_msg读写函数中，判断如果当前AP侧和BP侧的连接通道是激活状态的话，就通过write函数，将打包好的QMI消息，写入连接通道信息里面的f_desc参数,
ret = write(conn_info->f_desc, (void*) msg_ptr, (size_t)msg_len);
到此，整个ARM流程结束。以上主要介绍AP侧要发送一个请求到BP侧，QMI是怎么对请求进行编码成QMUX消息，怎么将编码后的QMUX消息加头组合成一种AP和BP可共同识别的消息格式，最后是怎么发送到BP侧的。
Modem消息接收
消息初始化
初始化：qmi_modem_taskàqmii_init()àqmux_init()。qmux_init方法完成对控制通道的初始化后，
通过函数qmuxi_process_rx_sig方法开始从共享内存接收数据。调用流程如如下：
(void)qmi_set_sig_handler(QMI_QMUX_RX_SIGNAL, qmuxi_process_rx_sig, NULL);
在qmuxi_process_rx_sig方法中，首先通过dsm_dequeue（）读取在队列中等待的QMUX消息，赋值给指针qmux_pdu表示QMUX消息的首地址。
qmux_pdu = dsm_dequeue( &qmux_s->io.rx_wm );
然后调用qmuxi_process_msg方法开始对AP侧发过来的QMUX消息解包。
qmuxi_process_msg( qmux_s, qmux_pdu );
qmuxi_process_msg方法首先拆分IF Type，通过函数dsm_pull8（）进行解包。然后判断IF Type类型，然后把QMUX Message通过qmuxi_input()继续处理。
在qmuxi_input()中，会拆分QMUX的消息头，将消息头大卸八块,包括length,control_flags,client_id,service_id，然后调用qmi_framework_svc_recv方法将剩下的QMUX SDU从拆分出来的QMUX消息头中，找到BP侧相对应的service处理。
if((svci == NULL) || (!(svci->registered)))
{
status = qmi_framework_svc_recv( qmi_instance_by_qmux_state(qmux_s),
(qmux_service_e_type) qmux_hdr.svc_type, qmux_hdr.clid, *qmux_pdu );
*qmux_pdu = NULL;
return status;
}
在qmi_framework_svc_recv方法中，并不会马上根据service_id等对QMUX消息进行处理，这里也是一个接口，将消息打包成BP侧的QMI_framework的一个command，发送出去。
qmi_framework_msg_hdr_type msg_hdr;
qmi_framework_svc_info_type * svc_info;
// ...
svc_info = qmi_framework_svc_state[service];
定义一个qmi_framework_svc_info_type的指针变量，对svc_info的操作就等于对qmi_framework_svc_state的操作。
打包到msg_hdr
msg_hdr.common_hdr.service = service;
msg_hdr.common_hdr.client_id = client_id;
msg_hdr.common_hdr.qmi_instance = (int32)qmi_instance;
msg_hdr.common_hdr.transaction_id = msg_x_id;
msg_hdr.msg_ctl_flag = msg_ctl;
msg_hdr.msg_len = remaining_bytes;
最后
svc_info->cfg.cbs.cmd_hdlr(&msg_hdr,&sdu_in);
这个机制是怎么样呢？以phone相关的qmi_voice.c为例。
消息分类处理
qmi_voice.c在qmi_voice_init方法进行初始化时，
qmi_mmode_set_cmd_handler(QMI_MMODE_CMD_VOICE_FW_CB, qmi_voice_handle_fw_cmd);
// ...
qmi_voicei_cfg.cmn_svc_cfg.fw_cfg.cbs.alloc_clid = qmi_voice_fw_alloc_clid_cback;
qmi_voicei_cfg.cmn_svc_cfg.fw_cfg.cbs.dealloc_clid = qmi_voice_fw_dealloc_clid_cback;
qmi_voicei_cfg.cmn_svc_cfg.fw_cfg.cbs.init_cback = qmi_voice_fw_init_cback;
qmi_voicei_cfg.cmn_svc_cfg.fw_cfg.cbs.cmd_hdlr = qmi_voice_fw_req_cback;
qmi_voicei_cfg.cmn_svc_cfg.cmd_hdlr_array = qmi_voicei_cmd_callbacks;
qmi_voicei_cfg.cmn_svc_cfg.cmd_num_entries = VOICEI_CMD_MAX;
qmi_voicei_cfg.cmn_svc_cfg.service_id = QMUX_SERVICE_VOICE;
/*-----------------------------------------------------------------------
step 2: calling QMI Framework API to register the service.
----------------------------------------------------------------------*/
errval= qmi_framework_reg_service(QMUX_SERVICE_VOICE,
&qmi_voicei_cfg.cmn_svc_cfg.fw_cfg);
初始化的时候，用结构体指针&qmi_voicei _cfg，到qmi_framework里面注册服务，获取AP测发送过来的qmux，可以关注给cmd_hdlr赋值的函数qmi_voice_fw_req_cback，这是从qmi_framework返回的回调函数。
因此，对于phone消息， qmi_framework_svc_recv都是回调qmi_voice_fw_req_cback进行处理,qmi_voice_fw_req_cback方法读取QMUX消息的头指针，和QMUX SDU的首地址。发送到voice服务里面专门的command_handle。
qmi_mmode_send_cmd(QMI_MMODE_CMD_VOICE_FW_CB, cmd_ptr);
在voice初始化可找到QMI_MMODE_CMD_VOICE_FW_CB对应的方法为qmi_voice_handle_fw_cmd。
qmi_mmode_send_cmd方法会调用qmi_voice_handle_fw_cmd方法,该方法根据不同的消息类型调用不同的方法进行处理,
switch(qmi_info->id)
{
case QMI_MMODE_FW_INIT_CB:
qmi_voicei_fw_init_cback_hdlr(qmi_info->data.qmi_fw_info.init_cb.num_instances);
break;
case QMI_MMODE_FW_ALLOC_CLID_CB:
qmi_voicei_fw_alloc_clid_hdlr(&qmi_info->data.qmi_fw_info.alloc_clid.msg_hdr);
break;
case QMI_MMODE_FW_DEALLOC_CLID_CB:
qmi_voicei_fw_dealloc_clid_hdlr(&qmi_info->data.qmi_fw_info.dealloc_clid.msg_hdr);
break;
case QMI_MMODE_FW_REQ_CB:
qmi_voicei_fw_req_hdlr(&qmi_info->data.qmi_fw_info.req_cb.msg_hdr,
qmi_info->data.qmi_fw_info.req_cb.sdu_in);
break;
default:
QM_MSG_ERROR("Unsupported qmi-voice fw cmd");
break;
}
qmi_voicei_fw_req_hdlr并不会马上对获取的消息进行处理，而是判断头消息中的client_id是否符合，符合则通过函数qmi_mmode_svc_req_hdlr发送到request_handler中，
if( msg_hdr->common_hdr.client_id > 0 )
{
cl_sp = (qmi_voicei_client_state_type *)
qmi_voice_state.client[msg_hdr->common_hdr.client_id - 1];
ASSERT(cl_sp);
/*-------------------------------------------------------------------------
Invoke the common svc request handler
-------------------------------------------------------------------------*/
qmi_mmode_svc_req_hdlr(&qmi_voicei_cfg.cmn_svc_cfg, msg_hdr, &cl_sp->common,
sdu_in);
到此,几乎所有的消息类型最后都会调用qmi_mmode_svc_req_hdlr方法发送到request_handler中。
消息分发
在qmi_mmode_svc_req_hdlr函数中，真正对QMUX消息进行处理。首先拆分头消息中的service_id,control_flag等。
svc_id = svc_cfg->service_id;
然后通过一个while循环开始对QMUX SDU进行解包。
while (sdu_in)
{
/*-----------------------------------------------------------------------
Extract service message header
-----------------------------------------------------------------------*/
temp = dsm_pull16( &sdu_in );
}
解包函数dsm_pull16（）作用，按照一定的大小，从&sdu_in这个地址中获取数据。获取完后，跳出while循环，调用qmi_mmode_svci_dispatch_transaction方法进行处理。
qmi_mmode_svci_dispatch_transaction(&msg_hdr->common_hdr,svc_cfg,x_p);
其中参数x_p是解包后的qmux_sdu存放的buffer。
qmi_mmode_svci_input方法会通过request_handler对消息进行处理分发。
response_ptr = cmd_hdlr->request_hdlr( svc_cfg->svc_sp, cmd_buf_p, cl_sp, sdu_in );
request_hdlr方法是被封装了的，没法继续跟进，BP侧的接收处理到此结束。
modem消息发送
一般BP侧处理完请求后，都会回应一个响应给AP，一般是用宏QMI_SVC_PKT_PUSH将要作为响应的消息发送出去。qmi_svc_utils.h中QMI_SVC_PKT_PUSH定义如下：
#define QMI_SVC_PKT_PUSH(pkt,val,len) ( len == dsm_pushdown_packed(pkt, val,\ len,\ DSM_DS_SMALL_ITEM_POOL ) )
将val里面的数据，传len个长度到pkt的buffer里面，然后发送出去。Val和len是我们要作为响应的数据和数据包大小。QMI_SVC_PKT_PUSH（）只能传单一的参数，根据上文说明的QMUX消息中TLV格式的原理，可以用多个QMI_SVC_PKT_PUSH连着用，这样可以将多个数据或参数打包到同一条消息中发送。
例如,在voice服务中，用多个QMI_SVC_PKT_PUSH回传消息。
QMI_SVC_PKT_PUSH(&response, (void*)&info->call_id, sizeof(info->call_id))) )
// ...
QMI_SVC_PKT_PUSH(&response, (void *)&tag, VOICEI_TLV_TAG_SIZE)
// ...
最后还要记得写上TLV的总长度，和标志位。标志位必须和AP侧发出的请求相对应，如AP侧发出请求为0x21，返回的标志位rec_tag也必须为0x21，方便返回AP后查表处理。将TLV消息放入response这个buffer后，会继续打包QMUX的消息头，然后通过函数qmi_mmode_svc_send_response（）发送出去。
调用流程图如下：
/* Send the response */
status = qmi_mmode_svc_send_response( &common_hdr,cmd_buf_p, msg_ptr);
回传的消息也是需要严格按照QMUX消息的格式的， qmi_mmode_svc_send_response方法中按照格式对QMUX消息进行重组,
msg_hdr.common_hdr.client_id = common_hdr->client_id;
msg_hdr.common_hdr.qmi_instance = common_hdr->qmi_instance;
msg_hdr.common_hdr.service = common_hdr->service;
msg_hdr.common_hdr.transaction_id = x_p->x_id;
msg_hdr.msg_ctl_flag = QMI_FLAG_MSGTYPE_RESP;
if( x_p->n_cmds > 1 )
{
msg_hdr.msg_ctl_flag |= QMI_FLAG_MASK_COMPOUND;
}
msg_hdr.msg_len = (uint16) dsm_length_packet(msg_ptr);
qmi_framework_svc_send_response( &msg_hdr, msg_ptr );
指针msg_ptr读取x_p->resp_list[]中的响应消息，msg_hdr为qmux消息的头。
通过函数qmi_framework_svc_send_respnse（）发到qmi_framework，这只是qmi_framework的一个接口，会调用qmi_frameworki_svc_send方法,直接调用qmi_frameworki_svc_send方法，
status = qmi_frameworki_svc_send( msg_hdr,
QMI_CMD_FRAMEWORK_SEND_RESPONSE,
msg_ptr );
qmi_frameworki_svc_send方法首先对接收到QMUX消息进行处理，将消息头和内容放到结构体qmi_framework_msg_buf的成员变量中,
memscpy( &qmi_framework_msg_buf->msg_hdr, sizeof (*msg_hdr), msg_hdr,
sizeof (*msg_hdr) );
qmi_framework_msg_buf->dsm_item = msg_ptr;
然后调用qmi_framework_process_svc_send方法,
return qmi_framework_process_svc_send((void *)qmi_framework_msg_buf, qmi_cmd );
qmi_framework_process_svc_send方法首先校验QMI服务给qmi_framework发出的command，判断这次从BP侧发出的消息是一个响应AP侧请求的response还是主动发给AP的一个indicated。
if((qmi_cmd_id_e_type)qmi_cmd == QMI_CMD_FRAMEWORK_SEND_RESPONSE )
{
msg_type = QMI_FLAG_MSGTYPE_RESP;
}
else if((qmi_cmd_id_e_type)qmi_cmd == QMI_CMD_FRAMEWORK_SEND_IND)
{
msg_type = QMI_FLAG_MSGTYPE_IND;
然后判断消息头的有效性，最后通过函数qmi_frameworki_qmux_send（）发送到BP侧QMI的接口,
if (FALSE == qmi_frameworki_validate_msg_hdr(msg_hdr, msg_type ))
{
LOG_MSG_ERROR_1 ("Msg header validation failed - unable to send Response for cmd %d",
msg_hdr->msg_ctl_flag);
goto func_end;
}
return qmi_frameworki_qmux_send(msg_buf, msg_type, ind_cmd_id, msg_ptr);
qmi_frameworki_qmux_send方法首先会对QMUX消息进行一个过滤，如果消息异常，则丢弃。
if ( qmi_svc_filter_message( (qmi_instance_e_type)
msg_buf->msg_hdr.common_hdr.qmi_instance, msg_buf->msg_hdr.common_hdr.service,
msg_type, int_cmd_id) )
{
// ...
然后调用QMUX层的接口qmux_sio_send方法进行处理,
qmux_sio_send ( (qmi_instance_e_type)msg_buf->msg_hdr.common_hdr.qmi_instance,
msg_buf->msg_hdr.common_hdr.service,
msg_buf->msg_hdr.common_hdr.client_id,
msg_ptr);
qmux_sio_send方法首先调用dsm_length_packet方法对消息进行组装,
if( dsm_length_packet(qmux_sdu) == 0)
然后组合上IF Type完成整个消息重组,
iftype = (byte)qmux_state[ qmi_instance ].io.port_info.frame_mode;
最后通过IO口的传输函数发送到AP侧，
if( QMUX_DEVSTREAM_CONTROL != qmux_state[qmi_instance].io.port_info.qmi_stream )
{
sio_transmit( qmux_state[qmi_instance].io.sio_handle, qmux_sdu );
}
else
{
sio_control_transmit( qmux_state[qmi_instance].io.sio_handle, qmux_sdu );
}
这样,消息就从modem侧发出来了。
8 QCRLC消息接收
在qmi_qmux.c的qmi_qmux_pwr_up_init方法中,
QMI_QMUX_IO_PLATFORM_PWR_UP_INIT(qmi_qmux_rx_msg,qmi_qmux_event_cb);
qmi_qmux_rx_msg会接收处理BP侧回发的消息, 主要是对从BP侧接收到的消息进行解包，判断BP侧的消息类型是响应还是指示，转发给上层client端处理。根据QMUX消息结构的长度，选择是用1个字节的方式读取还是2个字节的方式读取，
/* Read the I/F byte, make sure it is a 1 */
READ_8_BIT_VAL(msg_ptr,i_f_byte);
if (i_f_byte != 1)
{
QMI_ERR_MSG_1 ("qmi_qmux: Received invalid I/F byte = %d\n",i_f_byte);
return;
}
/* Read the message length */
READ_16_BIT_VAL(msg_ptr, length);
判断消息类型是BP侧群发的广播，还是专门针对某个client端的响应。
if (client_id == QMI_QMUX_INVALID_QMI_CLIENT_ID)
{
qmi_qmux_rx_client_broadcast (conn_id, service_id, client_id, control_flags,
msg_ptr, msg_len);
}
else
{
qmi_qmux_rx_client_msg (conn_id, service_id, client_id, control_flags,
msg_ptr, msg_len);
}
接下去的流程，和之前AP发送的流程相似，不详细介绍。