點(diǎn)擊打開鏈接

本系列導(dǎo)航：

linux驅(qū)動由淺入深系列：高通sensor架構(gòu)實例分析之一(整體概覽+AP側(cè)代碼分析)

linux驅(qū)動由淺入深系列：高通sensor架構(gòu)實例分析之二(adsp驅(qū)動代碼結(jié)構(gòu))
Linux驅(qū)動由淺入深系列：高通sensor架構(gòu)實例分析之三(adsp上報數(shù)據(jù)詳解、校準(zhǔn)流程詳解)

最初的時候芯片廠家對sensor的處理和對待其它外設(shè)一樣都是直接掛在processor上，sensor的驅(qū)動也和其他linux或android的驅(qū)動一樣，生成對應(yīng)的設(shè)備節(jié)點(diǎn)給上層提供數(shù)據(jù)（關(guān)于此類linux基礎(chǔ)驅(qū)動的知識，可以參考本博客其他博文）。但后來這一切發(fā)生了變化，最主要的原因就是功耗。Sensor希望自己能夠一直處于工作狀態(tài)下，如計步器等應(yīng)用場景。這樣如果sensor還掛在主processor上（這時候處理器就分多核啦）勢必影響待機(jī)功耗。因此各個芯片廠推出了各自的方案，如sensor-hub等等。高通在MSM8960之后就將sensor的處理塞到了一個單獨(dú)的音頻dsp中了（MSM8953中這個dsp叫作aDSP），這樣待機(jī)時主處理器休眠降低功耗，由這個aDSP在處理音頻數(shù)據(jù)的間隙捎帶著就能把sensor的數(shù)據(jù)處理了^^。下面以MSM8953為例分析一下其結(jié)構(gòu)。

?

高通sensor軟件架構(gòu)

首先來看一下高通sensor處理的軟件框圖：

1，? 框圖上半部分是應(yīng)用處理器，下半部分是aDSP。

2，? aDSP中包含了log接口，電源管理，sensor算法庫，sensor校準(zhǔn)，各個sensor的管理模塊。最后一個是直接掛載各個傳感器的（Prox、Press、Mag、Gyro、Acc），軟件中的主要部分叫作SMGR。[上圖文字怎么亂了，補(bǔ)充一張^-^]

3，? 在應(yīng)用處理器中，軟件接口中不再有每個sensor的設(shè)備節(jié)點(diǎn)了。那有的是什么呢，只有Sensor1 API Socket Remoting Layer層對應(yīng)的API接口。這個接口是本文的重點(diǎn)，下文詳細(xì)解釋。

4，? 那么aDSP與應(yīng)用處理器之間用什么機(jī)制進(jìn)行通信呢？圖中可以看到一個叫QMI的東西，就是它了，這個高通基于共享內(nèi)存機(jī)制開發(fā)的多核間通信技術(shù)，在應(yīng)用處理器側(cè)和aDSP側(cè)都有相應(yīng)的庫已經(jīng)完成了底層實現(xiàn)。之后有機(jī)會分析一下這種號稱最為有效的多核間通信技術(shù)。

5，? 應(yīng)用處理器側(cè)還有些亂七八糟的藍(lán)色框，這部分是運(yùn)行在應(yīng)用處理器側(cè)的sensor算法、校準(zhǔn)相關(guān)的東西。這是些只會在非待機(jī)模式運(yùn)行的算法，就適合放在這個地方了。

?

android中sensor架構(gòu)

在android中sensor的架構(gòu)圖如下：

在Sensor1 API Socket Remoting Layer層的基礎(chǔ)上轉(zhuǎn)換成了android的Framwork層就可以被APP調(diào)用了，目前我們先以linux 應(yīng)用程序的直接調(diào)用Sensor1 API Socket Remoting Layer層接口為例進(jìn)行演示。

高通sensor測試工具

高通為sensor的測試提供了默認(rèn)的工具，代碼位于：

vendor\qcom\proprietary\sensors\dsps\test\src\sns_dsps_tc0001.c

vendor\qcom\proprietary\sensors\dsps\test\src\sns_cm_test.cpp

編譯后生成對應(yīng)的bin文件：

1，sns_dsps_tc0001用來查看當(dāng)前系統(tǒng)掛載的sensor的相關(guān)信息：

2，sns_cm_test用來獲取對應(yīng)sensor_id的傳感器數(shù)據(jù)：

Sensor的API接口：

1,

sensor1_error_e?sensor1_open(sensor1_handle_s**hndl,?sensor1_notify_data_cb_t?data_cbf, ?intptr_t cb_data );

←	hndl	Opaque handle used to identify this client
→	data_cbf	Pointer to the client’s callback function to process received data
→	cb_data	This data is set by the client and will be passed unmodified as a parameter to the callback function

2，

typedef void (*sensor1_notify_data_cb_t) (uint32 cb_data,?sensor1_msg_header_s* msg_hdr, ?sensor1_msg_type_e?msg_type,?void *msg_ptr);

→	cb_data	Unmodified value passed in when the callback was registered in sensor1_open()
→	msg_hdr	Message header defining the message
→	msg_type	Type of message
→	msg_ptr	Pointer to the QMI-based message; these messages are defined in their respective service header files; client shall free this pointer via sensor1_free_msg_buf()

3，

sensor1_error_e sensor1_close(sensor1_handle_s* hndl );

→

hndl

Opaque handle used to identify this client

4，

sensor1_error_e?sensor1_write(sensor1_handle_s* hndl,?sensor1_msg_header_s* msg_hdr,?void *msg_ptr);

→	hndl	Opaque handle to identify this client
→	msg_hdr	Message header defining the message
→	msg_ptr	Pointer to the QMI-based request message; these messages are defined in their respective service header files; memory pointed to shall be allocated by?sensor1_alloc_msg_buf()

5，

sensor1_error_e?sensor1_writeable(sensor1_handle_s* hndl,?sensor1_write_cb_t?cbf,?intptr_t cb_data,?uint32_t service_number );

→	hndl	Opaque handle to identify this client
→	cbf	Pointer to the client’s callback function
→	cb_data	This data is set by the client and will be passed unmodified as a parameter to the callback function
→	service_number	Client callback function will be called when it is possible that this Service ID can accept new requests via?sensor1_write

6，

typedef void (*sensor1_write_cb_t) (intptr_t cb_data,?uint32_t service_number);

→	cb_data	Unmodified value passed in when the callback was registered in sensor1_writable()
→	service_number	Service ID to which this callback refers

7，

sensor1_error_e sensor1_alloc_msg_buf(sensor1_handle_s* hndl,??uint16_t size,??void **buffer );

→	hndl	Opaque handle to identify this client
→	size	Size of the message structure
←	buffer	Address of a pointer to the memory address where the message should be placed

8，

sensor1_error_e sensor1_free_msg_buf(sensor1_handle_s* hndl,??void* msg_buf );

→	hndl	Opaque handle to identify this client
→	msg_buf	Buffer to free

sns_cm_test.cpp代碼實例

有了上面的api接口介紹，來看一下sns_cm_test.cpp中對其使用就比較清晰了：

[objc]?view plaincopy

好吧，為了避免麻煩，刪除了高通私有代碼演示，有代碼的去上面指出的文件分析即可。相信沒有代碼的也不會看這篇文章^^?本文僅做學(xué)習(xí)交流目的，如有侵權(quán)請聯(lián)系博主。??

版權(quán)聲明：本文為博主原創(chuàng)文章，未經(jīng)博主允許不得轉(zhuǎn)載。如本文對您有幫助，歡迎點(diǎn)贊評論。 https://blog.csdn.net/RadianceBlau/article/details/73468700

總結(jié)

以上是生活随笔為你收集整理的linux驱动由浅入深系列：高通sensor架构实例分析之一的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。