Qualcomm平臺camera調試移植入門

1  camera基本代碼架構

    高通平臺對於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/下的對應dtsi文件中新增camera節點，主要關注節點中的IIC地址、sensro的ID信息、電壓設定信息：

圖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很是規設定代碼片斷