QMI » History » Version 2
laforge, 12/17/2016 11:35 AM
1 | 2 | laforge | {{>toc}} |
---|---|---|---|
2 | |||
3 | 1 | laforge | h1. QMI |
4 | 2 | laforge | |
5 | |||
6 | h2. QMI (Qualcomm MSM Interface) |
||
7 | |||
8 | This is the general term for all related messaging between processors |
||
9 | and their software stacks on Qualcomm cellular processors. |
||
10 | |||
11 | h2. IDL |
||
12 | |||
13 | * @int32_t qmi_idl_get_service_id(service_obj, service_id)@ |
||
14 | get service ID for a given service object |
||
15 | |||
16 | * @qmi_idl_message_decode()@ |
||
17 | Decode from TLV to C structure |
||
18 | |||
19 | * @qmi_idl_message_encode()@ |
||
20 | Encode from C structure to wire format TLV |
||
21 | |||
22 | h3. IDL Structures |
||
23 | |||
24 | Individual services are implemented in a data-driven manner by data |
||
25 | structures describing the type of messsages and the message TLV |
||
26 | structure. |
||
27 | |||
28 | In the end, a service describes itself using the master structure |
||
29 | qmi_idl_service_object, consisting of |
||
30 | * library version (0x04) |
||
31 | * idl version |
||
32 | * service ID |
||
33 | * maximum message length |
||
34 | * number of command/response/indication messges in tables |
||
35 | * tables describing messages (@qmi_idl_service_message_table_entry@) |
||
36 | * tables describing types (@qmi_idl_type_table_object@) |
||
37 | |||
38 | The data structures describing a given service are generated by an IDL |
||
39 | compiler. |
||
40 | |||
41 | |||
42 | h2. CSI (Common Service Interface) |
||
43 | |||
44 | Data model (see @qmi_csi_common.h@ for more info): |
||
45 | |||
46 | * each service list has a list of active services |
||
47 | * each service has a table of transports associated with it |
||
48 | * each service also has a list of connected clients |
||
49 | * each client has a pointer to the transport it connected from |
||
50 | * each client also has a list of outstanding transactions |
||
51 | |||
52 | CSI has only a single transport on Linux, using te AF_MSM_IPC type |
||
53 | sockets as a basis. |
||
54 | |||
55 | |||
56 | h2. SAP (Service Access Proxy) |
||
57 | |||
58 | Intended to export a service off-chip using QMUX daemon. |
||
59 | |||
60 | Encodes/Decodes messages for registering services: |
||
61 | * register_service request/response |
||
62 | * deregister_service request/response |
||
63 | * client_connect indication |
||
64 | * client_disconnect indication |
||
65 | |||
66 | |||
67 | h2. QMUX (QMI Multiplex) |
||
68 | |||
69 | The related code can either talk directly to the shared-memory devices |
||
70 | on Linux and thus the hardware (see @qmi_platform_qmux_io.c@). |
||
71 | |||
72 | It can however also establish a connection via a multiplex daemon. |
||
73 | This connection utilizes unix domain STREAM type sockets in |
||
74 | /dev/socket, specifically: |
||
75 | * @/dev/socket/qmux_audio/qmux_{client,connect}_socket@ |
||
76 | * @/dev/socket/qmux_bluetooth/qmux_{client,connect}_socket@ |
||
77 | * @/dev/socket/qmux_radio/qmux_{client,connect}_socket@ |
||
78 | * @/dev/socket/qmux_gps/qmux_{client,connect}_socket@ |
||
79 | * @/var/qmux_{client,connect}_socket@ on non-android devices |
||
80 | |||
81 | h2. QCCI (QMI Common Client Interface) |
||
82 | |||
83 | The QCCI layer wraps QMI into the respective transport. The |
||
84 | transports supported are: |
||
85 | |||
86 | * IPC router (linux kernel socket family) |
||
87 | * QMUXD (using qmi_qmux_... API, via unix domain sockets) |
||
88 | * UDP packets (base port 10000) |
||
89 | |||
90 | The CCI API is what QMI clients normally would call to initiate a |
||
91 | client connection to a service. The CCI functions would then normally |
||
92 | be wrapped by some service specific code that wraps the IDL |
||
93 | definitions for message encoding/decoding and provides |
||
94 | service-specific API to the client. |
||
95 | |||
96 | |||
97 | h2. IPC (Inter Process Communications) |
||
98 | |||
99 | Qualcomm implements a socket-based inter process communication on |
||
100 | Linux. It is implemented usinga new address family, @AF_MSM_IPC@ (27). |
||
101 | |||
102 | The socket is used as datagram type socket (SOCK_DGRAM). |
||
103 | |||
104 | The socket address of a related socket consists of: |
||
105 | |||
106 | * the socket family (AF_MSM_IPC) |
||
107 | * a @struct msm_ipc_addr@, consisting of |
||
108 | ** a single address type byte |
||
109 | ** a port address (node_id, port_id) |
||
110 | ** a port name (service, instance) |
||
111 | |||
112 | h2. IRSC (IPC Router Security Control) |
||
113 | |||
114 | FIXME |
||
115 | |||
116 | h2. Shared Memory based Logging |
||
117 | |||
118 | There's a @/dev/smem_log@ which can be opened and read from. It |
||
119 | supports some specific ioctl() to set binary mode. |
||
120 | |||
121 | More information in @smem_log.h@ |
||
122 | |||
123 | |||
124 | h2. AT command implementation (QMI ATCOP service layer) |
||
125 | |||
126 | This is used by client programs to register AT command call-backs |
||
127 | within the modems AT command interpreter. |
||
128 | |||
129 | The QMI ATCOP service layer seems to be pre-IDL, as it doesn't have |
||
130 | the usual IDL compiler code structure. |
||
131 | |||
132 | h3. qmi_atcop_fwd_at_urc_req() |
||
133 | |||
134 | used to send unsolicited response codes to modem |
||
135 | |||
136 | h3. qmi_atcop_fwd_at_cmd_resp() |
||
137 | |||
138 | used by clien to send response to an AT command previously forwarded |
||
139 | to the client from the modem |
||
140 | |||
141 | h3. qmi_atcop_reg_at_command_fwd_req() |
||
142 | |||
143 | used by client to registre any AT commands that need to be forwarded |
||
144 | to it from the modem |
||
145 | |||
146 | h3. qmi_atcop_srvc_init_client() |
||
147 | |||
148 | intialization |
||
149 | |||
150 | h3. qmi_atcop_srvc_release_client() |
||
151 | |||
152 | cleanup |
||
153 | |||
154 | h2. QMI Services (via IDL) |
||
155 | |||
156 | h3. Test Service |
||
157 | |||
158 | Part of qmi-framework. IDL descriptions for |
||
159 | |||
160 | * ping req/resp |
||
161 | * test_ind |
||
162 | * data req/resp |
||
163 | * large_data req/resp |
||
164 | * data_ind_reg req/resp |
||
165 | * test_data_ind |
||
166 | * get_service_name req/resp |
||
167 | |||
168 | h3. common_v01 |
||
169 | |||
170 | * get_supported_msgs req/resp |
||
171 | * get_supported_fields req/resp |
||
172 | |||
173 | h3. application_traffic_pairing_v01 |
||
174 | |||
175 | h3. card_application_toolkit_v02 |
||
176 | |||
177 | SIM/USIM toolkint related |
||
178 | |||
179 | h3. circuit_switched_video_telephony_v01 |
||
180 | |||
181 | h3. coexistence_manager_v01 |
||
182 | |||
183 | bt/wifi coexistance? |
||
184 | |||
185 | h3. control_service_v01 |
||
186 | |||
187 | h3. data_system_determination_v01 |
||
188 | |||
189 | check for availability of wlan/modem/... data bearers and set related |
||
190 | policy |
||
191 | |||
192 | h3. device_management_service_v01 |
||
193 | |||
194 | * inquiry about device maker/model/version |
||
195 | * MSISDN, ICCID, IMSI, MAC address inquiry |
||
196 | * PIN entry/management |
||
197 | * locking |
||
198 | |||
199 | h3. ip_multimedia_subsystem_application_v01 |
||
200 | |||
201 | h3. ip_multimedia_subsystem_dcm_v01 |
||
202 | |||
203 | h3. ip_multimedia_subsystem_presence_v01 |
||
204 | |||
205 | h3. ip_multimedia_subsystem_rtp_v01 |
||
206 | |||
207 | h3. ip_multimedia_subsystem_settings_v01 |
||
208 | |||
209 | h3. ip_multimedia_subsystem_video_telephony_v01 |
||
210 | |||
211 | h3. network_access_service_common_v01 |
||
212 | |||
213 | h3. network_access_service_v01 |
||
214 | |||
215 | * network scan / registration |
||
216 | * network preference |
||
217 | * forbidden networks |
||
218 | * rf band information |
||
219 | * operator name |
||
220 | * rx diversity |
||
221 | |||
222 | h3. persistent_device_configuration_v01 |
||
223 | |||
224 | h3. phonebook_manager_service_v01 |
||
225 | |||
226 | h3. qmi_adc_service_v01 |
||
227 | |||
228 | * ADC conversion/calibration |
||
229 | |||
230 | h3. qmi_ims_vt_v01 |
||
231 | |||
232 | h3. qualcomm_mobile_access_point_msgr_v01 |
||
233 | |||
234 | h3. qualcomm_mobile_access_point_v01 |
||
235 | |||
236 | h3. radio_frequency_radiated_performance_enhancement_v01 |
||
237 | |||
238 | h3. sar_vs_service_v01 |
||
239 | |||
240 | h3. specific_absorption_rate_v01 |
||
241 | |||
242 | h3. user_identity_module_remote_v01 |
||
243 | |||
244 | APDU forwarding of SIM/USIM to remote location? |
||
245 | |||
246 | Probably more te opposite: A way how a modem can export a CCID device |
||
247 | towards a PC and then map the APDUs in something that the modem can |
||
248 | digest? |
||
249 | |||
250 | h3. user_identity_module_v01 |
||
251 | |||
252 | SIM/USIM card access |
||
253 | |||
254 | * read/write transparent / record EF |
||
255 | * verify / unblock / change pin |
||
256 | * card power up/down |
||
257 | * authenticate |
||
258 | * raw APDU |
||
259 | * SAP |
||
260 | * logicla channels |
||
261 | * ATR |
||
262 | * multi sim (slot) management |
||
263 | |||
264 | h3. voice_service_common_v02 |
||
265 | |||
266 | h3. voice_service_v02 |
||
267 | |||
268 | call control |
||
269 | |||
270 | h3. wireless_data_administrative_service_v01 |
||
271 | h3. wireless_data_service_v01 |
||
272 | |||
273 | cellular data |
||
274 | |||
275 | h3. wireless_messaging_service_v01 |
||
276 | |||
277 | SMS-PP, SMS-CB |