高通平臺對於camera的程式碼組織，大體上還是遵循Android的框架：即上層應用和HAL層互動，高通平臺在HAL層裡面實現自己的一套管理策略；在kernel中實現sensor的底層驅動。但是，對於最核心的sensor端的底層設定、ISP效果相關等程式碼則是單獨進行了抽離，放在了一個daemon程序中進行管理：

圖1 Qualcomm平臺camera程式碼架構簡圖

    由於高通把大部分具體的設定及引數放到了daemon程序中，所以在kernel部分只是進行了V4L2的設備註冊、IIC設備註冊等簡單的動作：

圖2 kernel層camera主要程式碼簡圖

如上圖，camera在kernel層的主檔案為msm.c，負責裝置的具體註冊及相關方法的填充；在msm_sensor.c檔案中，主要維護高通自己的一個sensor相關結構體—msm_sensor_ctrl_t，同時把dts檔案中的配置資訊讀取出來；kernel層對於不同的sensor對應自己的一個驅動檔案— xxsensor.c，主要是把power setting的設定填充到msm_sensor_ctrl_t中。    

    在vendor目錄下，高通把各個sensor實質性的程式碼放置在此。一部分程式碼是高通自己實現的daemon程序和kernel層及HAL層進行通訊的框架程式碼；另一部分則是和sensor相關的chromatix效果程式碼和sensor lib部分程式碼(init setting、lens info、output info)。

圖3 vendor下主要camera程式碼簡圖

如上圖，高通平臺通過一個函式指標陣列sub_module_init來管理sensor相關的元件；其中重要的是sensor_sub_module_init和chromatix_sub_module_init模組，對於sensor模組需要對應填充sensor_lib_t下的介面，對於chromatix模組則是通過高通的chromatix工具生成。

    從更高的層次來看，sensor部分的程式碼只是camera子系統的一部分。開啟高通vendor下面關於camera的原始碼也可以看到，/mm-camera2/media-controller/modules目錄下面，sensors只是modules檔案下面其中的一個子目錄。

圖4  高通camera子系統模組草圖

2  主要移植步驟

2.1  kernel層程式碼移植

    對於kernel層的程式碼移植，實際上對dts檔案的移植。因為kernel層驅動程式碼基本已經被高通的框架以及vendor下程式碼架空，只剩下一個上電的列表。具體步驟為：

1.  在目錄kernel/arch/arm/boot/dts/下的對應

圖5 dtsi中camera中的節點資訊截選

2．在目錄kernel/drivers/media/platform/msm/camera_v2/sensor/目錄新增xxsensor.c檔案，主要填充msm_sensor_power_setting結構體：sensor上電的包含的引腳設定和電壓設定，具體格式可以參考同目錄下的其他檔案。

3.  kernel下面的相關mk檔案：

圖6 kernel目錄下camera相關配置檔案

其他：如果sensor中帶有eeprom，需要在dts檔案中增加eeprom的節點資訊；同樣，sensor帶有對焦功能，需要在dts檔案中增加actuator節點資訊；對於帶eeprom的sensor，還需要配置eeprom的時鐘控制程式碼(有待研究)。

2.2  vendor下程式碼移植

    Vendor下面的程式碼主要是兩部分，一個是sensor_libs目錄下的sensor具體設定、配置檔案，另一個是chromatix下面的ISP效果檔案。具體為：

1. sensor_libs目錄下檔案：包括一個Android.mk檔案和一個.c檔案。其中Android.mk檔案參考同目錄下其他.mk檔案修改和對應sensor有關設定即可；.c檔案中需要填充的為一個sensor_lib_t型別的結構體：

圖7 sensor_lib_t成員截選圖

2.  chromatix目錄下相關檔案，在對應sensor目錄下包含4個目錄和一個Android檔案，總共13個檔案，這些檔案都會由chromatix除錯工具生成。下面為IMX179檔案例項：

圖8  vendor下chromatix相關檔案示例圖

3. vendor下還有eeprom檔案，模組自帶的eeprom資料處理相關；AF相關檔案，除錯工具生成的關於AF的效果檔案；配置檔案，把需要編譯的模組填進配置檔案中。

圖9  vendor下其他camera檔案

3  除錯常見問題

3.1  kernel和vendor下命名匹配

    對於不是高通釋放的標準驅動來說，在參考其他程式碼移植除錯一個新sensor的過程中，要注意在對應的dts檔案中給sensor配置節點資訊的過程中，“qcom,sensor-name”欄位的配置要和vendor下面的sensor lib程式碼中的“xxx_open_lib”函式名以及對應的Android.mk中的“LOCAL_MODULE”名稱匹配，否則相應sensor的vendor下庫檔案無法呼叫，這時開啟camera會出現閃退現象。具體可參考平臺程式碼sensor.c中的sensor_load_library()函式。

圖10  camera name匹配詳圖

3.2  sensor lib中的sensor_lib_out_info_t填充

    一般來說，每個sensor可以配置輸出不同大小的影象。此時，除了進行對應的sensor setting來改變sensor自身的輸出及相關配置外；還需要將相關的輸出大小、幀率等資訊通知平臺端，即填充struct sensor_lib_out_info_t結構體。

圖11 高通平臺獲取sensor資訊框圖

填充的這個sensor_lib_out_info_t中的成員，最終會作為sensor基本資訊的一部分被HAL層獲取到，上圖為高通平臺獲取sensor資訊的一個簡單框圖。

    在除錯過程中，需要注意的是這個結構體的成員max_fps需要填寫至少大於等於30；否則會因為在獲取capability時無法得到有效的previewsize、video size而無法進入預覽。具體可參考平臺程式碼mct_pipeline.c中的mct_pipeline_populate_query_cap_buffer()函式。

3.3  sensorlib中的exposure_table_size填寫

    對於sensor端輸出RAW資料，平臺端進行ISP處理的情形來說，sensor端除了基本的init配置外，另外一個就是根據平臺端AEC計算出來的資料來對應調整sensor的曝光。在高通平臺上將平臺端的AEC和具體的sensor曝光設定聯絡起來的是chromatix檔案中的一個Exposure Table和sensor lib檔案中的exposure對應介面。

    這裡的exposure_table_size對應著sensor lib中sensor_fill_exposure_array()介面寫入的sensor暫存器的個數，平臺程式碼中需要根據這個exposure_table_size來動態分配記憶體大小。如果這個值的填寫和sensor_fill_exposure_array()中實際寫入的值大小不一致，就會造成記憶體方面的crash。具體可參考平臺程式碼sensor.c中的sensor_apply_exposure()函式。

3.4  kernel 層非常規設定

    一般情況下，一個新sensor的移植和除錯需要在kernel層進行的工作基本上沒有問題。但是對於一些sensor來說，對於電壓的設定或是MCLK的設定有非常規要求的時候，可能就需要修改平臺上相關的預設設定。

    對於sensor的幾路工作電壓 (AVDD、DVDD、IOVDD)，平臺端一般都是通過PMIC的相應regulator供電，而硬體上regulator的輸出能力一般都有限制，程式碼上也會有體現。如果有sensor需要的電壓超過程式碼上相應regulator的限制值，可以檢視PMIC上的說明，如果程式碼上的限制值並不是硬體的真正極限，可以修改平臺程式碼解決。

    對於MCLK的設定，高通平臺有一些常規的值設定。如果sensor有特殊要求，而這個MCLK不能被平臺識別，這時候可以在平臺的clock相關程式碼中，通過配置平臺的PLL引數來生成特定的MCLK時鐘給sensor使用。

圖12 kernel非常規設定程式碼片段

------------------------------------------------------------

------------------------------------------------------------