remove qmi.txt it has moved to wiki
This commit is contained in:
parent
45d7e599ec
commit
27b3620fa5
276
qmi/qmi.txt
276
qmi/qmi.txt
|
@ -1,276 +0,0 @@
|
|||
= Typicall Client App =
|
||||
|
||||
Typical client program would do:
|
||||
* something like test_get_service_object_v01() to get the service
|
||||
object
|
||||
* qmi_client_notifier_init()
|
||||
* qmi_client_get_service_list() to check if the service is up yet
|
||||
* qmi_client_init(service_info, service_obj, qmi_client_ind_cb, ind_cb_data, os_params, user_handle)
|
||||
to initialize the client
|
||||
* main() loop
|
||||
* qmi_client_release(client)
|
||||
* qmi_client_release(notifier)
|
||||
|
||||
|
||||
* qmi_client_init_instance(service_obj, instance_id, ind_cb, ind_cb_data, os_params, timeout, user_handle)
|
||||
seems to be a convenience wrapper around qmi_client_get_service_list() and qmi_client_init()
|
||||
|
||||
== QMI (Qualcomm MSM Interface)
|
||||
|
||||
This is the general term for all related messaging between processors
|
||||
and their software stacks on Qualcomm cellular processors.
|
||||
|
||||
== IDL
|
||||
|
||||
* int32_t qmi_idl_get_service_id(service_obj, service_id)
|
||||
get service ID for a given service object
|
||||
|
||||
* qmi_idl_message_decode()
|
||||
Decode from TLV to C structure
|
||||
|
||||
* qmi_idl_message_encode()
|
||||
Encode from C structure to wire format TLV
|
||||
|
||||
=== IDL Structures
|
||||
|
||||
Individual services are implemented in a data-driven manner by data
|
||||
structures describing the type of messsages and the message TLV
|
||||
structure.
|
||||
|
||||
In the end, a service describes itself using the master structure
|
||||
qmi_idl_service_object, consisting of
|
||||
* library version (0x04)
|
||||
* idl version
|
||||
* service ID
|
||||
* maximum message length
|
||||
* number of command/response/indication messges in tables
|
||||
* tables describing messages (qmi_idl_service_message_table_entry)
|
||||
* tables describing types (qmi_idl_type_table_object)
|
||||
|
||||
The data structures describing a given service are generated by an IDL
|
||||
compiler.
|
||||
|
||||
|
||||
== CSI (Common Service Interface)
|
||||
|
||||
Data model (see qmi_csi_common.h for more info):
|
||||
|
||||
* each service list has a list of active services
|
||||
* each service has a table of transports associated with it
|
||||
* each service also has a list of connected clients
|
||||
* each client has a pointer to the transport it connected from
|
||||
* each client also has a list of outstanding transactions
|
||||
|
||||
CSI has only a single transport on Linux, using te AF_MSM_IPC type
|
||||
sockets as a basis.
|
||||
|
||||
|
||||
== SAP (Service Access Proxy)
|
||||
|
||||
Intended to export a service off-chip using QMUX daemon.
|
||||
|
||||
Encodes/Decodes messages for registering services:
|
||||
* register_service request/response
|
||||
* deregister_service request/response
|
||||
* client_connect indication
|
||||
* client_disconnect indication
|
||||
|
||||
|
||||
== QMUX (QMI Multiplex)
|
||||
|
||||
The related code can either talk directly to the shared-memory devices
|
||||
on Linux and thus the hardware (see qmi_platform_qmux_io.c).
|
||||
|
||||
It can however also establish a connection via a multiplex daemon.
|
||||
This connection utilizes unix domain STREAM type sockets in
|
||||
/dev/socket, specifically:
|
||||
* /dev/socket/qmux_audio/qmux_{client,connect}_socket
|
||||
* /dev/socket/qmux_bluetooth/qmux_{client,connect}_socket
|
||||
* /dev/socket/qmux_radio/qmux_{client,connect}_socket
|
||||
* /dev/socket/qmux_gps/qmux_{client,connect}_socket
|
||||
* /var/qmux_{client,connect}_socket on non-android devices
|
||||
|
||||
|
||||
== QCCI (QMI Common Client Interface)
|
||||
|
||||
The QCCI layer wraps QMI into the respective transport. The
|
||||
transports supported are:
|
||||
|
||||
* IPC router (linux kernel socket family)
|
||||
* QMUXD (using qmi_qmux_... API, via unix domain sockets)
|
||||
* UDP packets (base port 10000)
|
||||
|
||||
The CCI API is what QMI clients normally would call to initiate a
|
||||
client connection to a service. The CCI functions would then normally
|
||||
be wrapped by some service specific code that wraps the IDL
|
||||
definitions for message encoding/decoding and provides
|
||||
service-specific API to the client.
|
||||
|
||||
|
||||
== IPC (Inter Process Communications)
|
||||
|
||||
Qualcomm implements a socket-based inter process communication on
|
||||
Linux. It is implemented usinga new address family, AF_MSM_IPC (27).
|
||||
|
||||
The socket is used as datagram type socket (SOCK_DGRAM).
|
||||
|
||||
The socket address of a related socket consists of:
|
||||
|
||||
* the socket family (AF_MSM_IPC)
|
||||
* a struct msm_ipc_addr, consisting of
|
||||
** a single address type byte
|
||||
** a port address (node_id, port_id)
|
||||
** a port name (service, instance)
|
||||
|
||||
== IRSC (IPC Router Security Control)
|
||||
|
||||
FIXME
|
||||
|
||||
== Shared Memory based Logging
|
||||
|
||||
There's a /dev/smem_log which can be opened and read from. It
|
||||
supports some specific ioctl() to set binary mode.
|
||||
|
||||
More information in smem_log.h
|
||||
|
||||
|
||||
== AT command implementation (QMI ATCOP service layer)
|
||||
|
||||
This is used by client programs to register AT command call-backs
|
||||
within the modems AT command interpreter.
|
||||
|
||||
The QMI ATCOP service layer seems to be pre-IDL, as it doesn't have
|
||||
the usual IDL compiler code structure.
|
||||
|
||||
=== qmi_atcop_fwd_at_urc_req()
|
||||
|
||||
used to send unsolicited response codes to modem
|
||||
|
||||
=== qmi_atcop_fwd_at_cmd_resp()
|
||||
|
||||
used by clien to send response to an AT command previously forwarded
|
||||
to the client from the modem
|
||||
|
||||
=== qmi_atcop_reg_at_command_fwd_req()
|
||||
|
||||
used by client to registre any AT commands that need to be forwarded
|
||||
to it from the modem
|
||||
|
||||
=== qmi_atcop_srvc_init_client()
|
||||
|
||||
intialization
|
||||
|
||||
=== qmi_atcop_srvc_release_client()
|
||||
|
||||
cleanup
|
||||
|
||||
|
||||
== QMI Services (via IDL)
|
||||
|
||||
=== Test Service
|
||||
|
||||
Part of qmi-framework. IDL descriptions for
|
||||
|
||||
* ping req/resp
|
||||
* test_ind
|
||||
* data req/resp
|
||||
* large_data req/resp
|
||||
* data_ind_reg req/resp
|
||||
* test_data_ind
|
||||
* get_service_name req/resp
|
||||
|
||||
=== common_v01
|
||||
|
||||
* get_supported_msgs req/resp
|
||||
* get_supported_fields req/resp
|
||||
|
||||
=== application_traffic_pairing_v01
|
||||
=== card_application_toolkit_v02
|
||||
|
||||
SIM/USIM toolkint related
|
||||
|
||||
=== circuit_switched_video_telephony_v01
|
||||
|
||||
=== coexistence_manager_v01
|
||||
|
||||
bt/wifi coexistance?
|
||||
|
||||
=== control_service_v01
|
||||
|
||||
=== data_system_determination_v01
|
||||
|
||||
check for availability of wlan/modem/... data bearers and set related
|
||||
policy
|
||||
|
||||
=== device_management_service_v01
|
||||
|
||||
* inquiry about device maker/model/version
|
||||
* MSISDN, ICCID, IMSI, MAC address inquiry
|
||||
* PIN entry/management
|
||||
* locking
|
||||
|
||||
=== ip_multimedia_subsystem_application_v01
|
||||
=== ip_multimedia_subsystem_dcm_v01
|
||||
=== ip_multimedia_subsystem_presence_v01
|
||||
=== ip_multimedia_subsystem_rtp_v01
|
||||
=== ip_multimedia_subsystem_settings_v01
|
||||
=== ip_multimedia_subsystem_video_telephony_v01
|
||||
|
||||
=== network_access_service_common_v01
|
||||
=== network_access_service_v01
|
||||
|
||||
* network scan / registration
|
||||
* network preference
|
||||
* forbidden networks
|
||||
* rf band information
|
||||
* operator name
|
||||
* rx diversity
|
||||
|
||||
=== persistent_device_configuration_v01
|
||||
=== phonebook_manager_service_v01
|
||||
=== qmi_adc_service_v01
|
||||
|
||||
* ADC conversion/calibration
|
||||
|
||||
=== qmi_ims_vt_v01
|
||||
=== qualcomm_mobile_access_point_msgr_v01
|
||||
=== qualcomm_mobile_access_point_v01
|
||||
=== radio_frequency_radiated_performance_enhancement_v01
|
||||
=== sar_vs_service_v01
|
||||
=== specific_absorption_rate_v01
|
||||
|
||||
=== user_identity_module_remote_v01
|
||||
|
||||
APDU forwarding of SIM/USIM to remote location?
|
||||
|
||||
Probably more te opposite: A way how a modem can export a CCID device
|
||||
towards a PC and then map the APDUs in something that the modem can
|
||||
digest?
|
||||
|
||||
=== user_identity_module_v01
|
||||
|
||||
SIM/USIM card access
|
||||
|
||||
* read/write transparent / record EF
|
||||
* verify / unblock / change pin
|
||||
* card power up/down
|
||||
* authenticate
|
||||
* raw APDU
|
||||
* SAP
|
||||
* logicla channels
|
||||
* ATR
|
||||
* multi sim (slot) management
|
||||
|
||||
=== voice_service_common_v02
|
||||
=== voice_service_v02
|
||||
|
||||
call control
|
||||
|
||||
=== wireless_data_administrative_service_v01
|
||||
=== wireless_data_service_v01
|
||||
|
||||
cellular data
|
||||
|
||||
=== wireless_messaging_service_v01
|
||||
|
||||
SMS-PP, SMS-CB
|
Loading…
Reference in New Issue