本文主要介紹QCOM camera調試的重要參數(shù)；

（1）Lane_assign 和lane_mask

• 現(xiàn)在攝像頭基本都是mipi接口類型，因為前后攝都對應到平臺這邊不同的mipi接口，相應的數(shù)據(jù)lane需要一一對應；

• lane assign：

• lane_mask：

比如：

101 ? ? ? <LaneMask>0x1F</LaneMask> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 102 ? ? ? <LaneAssign>0x4320</LaneAssign>

• 0x1F：只有0~4表示有效，對應bit位置為1表示該位的lane或者clock有效，0x1F即表示該mipi接口上的4條data線和clk線都有效；

• 0x4320：表示sensor這邊幾條data線對應到平臺這邊mipi接口的第幾路接口端口映射；bit0~3表示lane0對應平臺這邊mipi的第0接口，bit12~15表示lane 3對應平臺這邊mipi的第4接口，那第1個接口就是為時鐘clk對接的；

（2）combo_mode

• 如該平臺這邊只有一個mipi phy設備，有時候就需要前后攝共用這個phy，此時combo_mode就要設為1，或者在雙攝的情況下：主副攝會與前攝共用，這個值也會設為1，下面是兩個camera分配情況：

• 比如只有一個PHY interface 的msm8909平臺就可以這樣配置：

//前攝配置
151 static struct csi_lane_params_t csi_lane_params = {
152 ? .csi_lane_assign = 0x004,
153 ? .csi_lane_mask = 0x18,
154 ? .csi_if = 1, // not used
155 ? .csid_core = {0},
156 ? .csi_phy_sel = 0,
157 };

432 ? .csiphy_params = {
433 ? ? .lane_cnt = 1,
434 ? ? .settle_cnt = 0x1b,//0x1b, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
436 ? ? .combo_mode = 1,
438 ? },

//后攝配置
198 static struct csi_lane_params_t csi_lane_params = {
199 ? .csi_lane_assign = 0x4320,
200 ? .csi_lane_mask = 0x7,
201 ? .csi_if = 1, // not used
202 ? .csid_core = {0},
203 ? .csi_phy_sel = 0,
204 };

334 ? .csiphy_params = {
335 ? ? .lane_cnt = 2, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
336 ? ? .settle_cnt = 0x18,
338 ? ? .combo_mode = 1,
340 ? },

（3）pixel_clk

• 像素時鐘（pixel clk）: 是經過主時鐘MCLK（EXTCLK） 經過PLL得到的，決定了該sensor突出數(shù)據(jù)的速度；相關PLL設定需要查看sensor 寄存器的data sheet，以s5k2ya為例：

• 如下為一個sensor的clk相關的配置：

static struct sensor_lib_out_info_t sensor_out_info[] = {
{
/* full size @ 24 fps*/
.x_output = 4208, 
.y_output = 3120,
.line_length_pclk = 4572,
.frame_length_lines = 3142,
.vt_pixel_clk = 360000000,
.op_pixel_clk = 360000000,
.binning_factor = 1,
.max_fps = 24.01,
.min_fps = 7.5,
.mode = SENSOR_DEFAULT_MODE,
},

vt_pixel_clk(video timing clk value) – Virtual clock value used for calculating shutter time,and used by?

AEC for correcting banding artifacts?

vt_pixel_clk = line_length_pclk * frame_length_lines * frame rate

• 平臺根據(jù)寫入不同的曝光行來控制幀率，比如在暗處希望犧牲一點幀率，讓Gain值更高，就用這個公式來計算，最后計算的 frame_length_lines 寫入相應寄存器；

• 注意一點的是不同的平臺需要一個最小的blanking time，所以frame_length_lines是要大于真是有效數(shù)據(jù)行y_output，而且差值一般16對齊；

op_pixel_clk – Represents how much data comes out of the camera over MIPI lanes to set the VFE clock op_pixel_clk = (total data rate from sensor)/bits-per-pixel if the MIPI DDR clock value (speed of the clock lane of the MIPI camera sensor) is 300 MHz, and the sensor transmits on 4 lanes, each lane has a 600 MHz data rate.Thus, the total data rate is 2400 MHz. For 10 bits per pixel Bayer data, this translates to the op_pixel_clk value of 2400/10 = 240 MHz. These values must be filled in accordance with the sensor specifications.

• 這個時鐘決定了sensor mipi data lane 吐出數(shù)據(jù)的帶寬；不同的平臺的處理能力不一樣，所以這個值不能超過平臺規(guī)范定義的值；

【文章福利】小編推薦自己的Linux內核技術交流群:【891587639】整理了一些個人覺得比較好的學習書籍、視頻資料共享在群文件里面，有需要的可以自行添加哦?。?！前100名進群領取，額外贈送一份價值699的內核資料包（含視頻教程、電子書、實戰(zhàn)項目及代碼)? ??

（4）settle_cnt

• settle_cnt(即穩(wěn)定計數(shù))–表示mipi開始切換到高速模式的一個穩(wěn)定時間，必須根據(jù)傳感器輸出特性配置該值,以確保傳感器的 PHY 發(fā)送器與 MSM 的 PHY 接收器無障礙同步；

• settle_cnt – For CSI_Tx (the sensor) and CRI_Rx (the device) to work properly, a period for syncing between them is required. This time is set here as number of timer clock ticks. It has to be between the MIN and MAX values calculated by the formulas:

1. MIN [Settle count * T(Timer clock)] > T(HS_SETTLE)_MIN

2. MAX [Settle count * T(Timer clock)] < T(HS-PREPARE)+T(HS_ZERO) - 4*T(Timer clock)

• settle_cnt(即穩(wěn)定計數(shù))– 必須根據(jù)sensor傳感器輸出特性配置該值,以確保傳感器的 PHY 發(fā)送器與 MSM 的 PHY 接收器無障礙同步；對于 28 nm 以及更小的 MSM 芯片,使用以下公式計算穩(wěn)定計數(shù):

1. settle_cnt = T(HS_SETTLE)_avg /T(TIMER_CLK),

2. 其中 T(HS_SETTLE)_avg = (T(HS_SETTLE)_min + T(HS_SETTLE)_max) / 2,如傳感器數(shù)據(jù)表所指示：

• 其中 T(HS_SETTLE)_avg = (T(HS_SETTLE)_min + T(HS_SETTLE)_max) / 2,如傳感器數(shù)據(jù)表所指示。

• TIMER_CLK 指攝像頭傳感器所連接的 PHY 接口的工作頻率。(例如,PHY0 的CAMSS_PHY0_CSI0PHYTIMER_CLK)。該值在 kernel/arch/arm/boot/dts/msm/msmXXXX-camera.dtsi 文件中設置,其中 XXXX 指正在使用 MSM 芯片組。另外,也可在攝像頭數(shù)據(jù)流傳輸期間確認,方法是通過 adb shell 檢查相應的時鐘信息。

• 例如,可通過命令提示窗口發(fā)出以下命令以確認 PHY0 定時器時鐘值:

adb root adb remount adb shell cd /sys/kernel/debug/clk/gcc_camss_csi0phytimer_clk cat measure 200000146

• 對于 45 nm MSM 芯片,使用與 28 nm MSM 芯片相似的公式,其中的 T(TIMER_CLK)替換為 T(DDR_CLK)。

• – DDR_CLK 指攝像頭傳感器的 MIPI CLK 通道的工作頻率,該值由通過傳感器攝像頭驅動程序設置的攝像頭傳感器 PLL 配置確定。

• – T(DDR_CLK) 為工作頻率等于 DDR_CLK 時的時鐘周期持續(xù)時間,以納秒為單位表示。例如,DDR_CLK 200 MHz 的 T(DDR_CLK) 為 (1 * (10^9)) / (200 * (10^6)) =5 ns。

• 有關 T(HS_SETTLE) 的定義,可參見針對 D-PHY(版本 1.1)的 MIPI(R)聯(lián)盟規(guī)范。為了防止上述系數(shù)在傳感器工作時所處的不同數(shù)據(jù)流傳輸模式間發(fā)生變化,必須為攝像頭傳感器驅動程序中每個唯一的數(shù)據(jù)流傳輸模式單獨配置 settle_cnt。

（5）Binning Mode

• Camera Binning Mode：像素合并模式，將相鄰的像素單元電荷通過物理的方法疊加在一起作為一個像素輸出信號；

935 ? ? ? ? .binning_factor = 1,? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 936 ? ? ? ? .binning_method = 0,

1. 水平方向Binning: 同列相鄰行的電荷疊加；

2. 垂直方向Binning: 同行相鄰列的電荷疊加；

3. Binning Mode 優(yōu)勢：增加感光面積，提高暗處對光感應的靈敏度；應用：增加物理感光像素單元，采用像素合并模式，提升暗處對光感應的靈敏度；

4. Binning Mode 劣勢：降低輸出分辨率；

額外補充：

1. sensor 開窗的不同模式：ROI, BIN,SKIP；

2. ROI ：Region of interes在相機傳感器分辨范圍內定義一個或多個感興趣的窗口區(qū)域，僅對這些窗口內的圖像信息進行讀出，只獲取該局部區(qū)域的圖像；

3. BIN ：這種模式就是按照一定的規(guī)律，把想要的數(shù)據(jù)采集上來，把其余的數(shù)據(jù)扔掉；

4. SKIP：就是把相鄰的像素合成一個像素，然后再輸出。

（6）I2C CLK

• The available I2C frequency modes are defined in kernel/include/media/msm_cam_sensor.h:standard (100 kHz), fast (400 kHz), and Custom mode.

enum i2c_freq_mode_t {

I2C_STANDARD_MODE,

I2C_FAST_MODE,

I2C_CUSTOM_MODE,

I2C_MAX_MODES,

};

• 高通平臺上兩條Camera I2C設備總線是專門為Camera用的，配置不同的i2c頻率的參數(shù)值定義在dtsi里面；
  

479 &i2c_freq_100Khz {
480 ? ? qcom,hw-thigh = <78>;
481 ? ? qcom,hw-tlow = <114>;
482 ? ? qcom,hw-tsu-sto = <28>;
483 ? ? qcom,hw-tsu-sta = <28>;
484 ? ? qcom,hw-thd-dat = <10>;
485 ? ? qcom,hw-thd-sta = <77>;
486 ? ? qcom,hw-tbuf = <118>;
487 ? ? qcom,hw-scl-stretch-en = <0>;
488 ? ? qcom,hw-trdhld = <6>;
489 ? ? qcom,hw-tsp = <1>;
490 };

• CCI clock = (src clock) / (hw_thigh + hw_tlow) //src clock 19.2MHZ

解釋如下：

qcom,hw-thigh : should contain high period of the SCL clock in terms of CCI clock cycle qcom,hw-tlow : should contain high period of the SCL clock in terms of CCI clock cycle qcom,hw-tsu-sto : should contain setup time for STOP condition?

qcom,hw-tsu-sta : should contain setup time for Repeated START condition?

qcom,hw-thd-dat : should contain hold time for the data?

qcom,hw-thd-sta : should contain hold time for START condition?

qcom,hw-tbuf : should contain free time between a STOP and a START condition qcom,hw-scl-stretch-en : should contain enable or disable clock stretching?

qcom,hw-trdhld : should contain internal hold time for SDA?

qcom,hw-tsp : should contain filtering of glitches i2c burst mode:?

+-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-

（一）bus overflow

• 攝像頭傳感器時鐘通道(即 MIPI DDR 時鐘)的工作頻率與激活的數(shù)據(jù)通道數(shù)決定攝像頭傳感器在指定操作模式下的總數(shù)據(jù)傳輸速率(吞吐量)。每個通道的數(shù)據(jù)傳輸速率是 MIPI DDR 時鐘速度的兩倍。例如,工作在 200 MHz MIPI DDR 時鐘頻率和 4 個激活通道下的攝像頭傳感器的總數(shù)據(jù)傳輸速率為 1600 Mbps(每個通道的數(shù)據(jù)傳輸速率為 200 * 2 = 400 Mbps)。

• 每個幀的分辨率、額外/虛擬像素/線數(shù)、水平消隱、垂直消隱、MIPI 包開銷、每像素位數(shù)、數(shù)據(jù)格式、內部是否存在多個交錯數(shù)據(jù)流以及每個流的數(shù)據(jù)傳輸速率/開銷等,都會影響數(shù)據(jù)傳輸速率。指定工作模式下初步攝像頭調通,計算:X = 幀寬 * (幀高垂直消隱) 每像素位數(shù) * 每秒幀數(shù) * (MIPI 協(xié)議和其他數(shù)據(jù)流的開銷)在 VFE 時鐘優(yōu)化中為給定的 MSM 找到大于 X 的最接近的值作為 VFE 時鐘的初始值。

• 在標稱時鐘模式下,比如MSM8909的VFE最大速度為266MHz每條MIPI通道的PHY限制為1.5 Gbps (1.5 * 109 bps),由于存在MIPI/空白開銷(約15-25%,各傳感器的具體數(shù)值有所不同),實際幀數(shù)據(jù)吞吐量略少于預期原圖拍攝接口數(shù)據(jù)傳輸速率與VFE時鐘無關在4通道PHY接口上,每條通道的最大數(shù)據(jù)為(266 x bpp)/通道數(shù);bpp → 每像素的傳感器輸出位數(shù)對于每通道10位數(shù)據(jù)傳輸速率 - (266*10)/4 - 665 Mbps；

當我們VFE 時鐘設置為小于傳感器輸出MIPI的數(shù)據(jù)傳輸速率時,將出現(xiàn)溢出bus overflow； 502: ? ? ? ?pr_err_ratelimited("%s: image master 0 bus overflow\n",?

507: ? ? ? ?pr_err_ratelimited("%s: image master 1 bus overflow\n",?

512: ? ? ? ?pr_err_ratelimited("%s: image master 2 bus overflow\n",?

517: ? ? ? ?pr_err_ratelimited("%s: image master 3 bus overflow\n",?

522: ? ? ? ?pr_err_ratelimited("%s: image master 4 bus overflow\n",?

527: ? ? ? ?pr_err_ratelimited("%s: image master 5 bus overflow\n",?

532: ? ? ? ?pr_err_ratelimited("%s: image master 6 bus overflow\n",

• 增大VFE時鐘可防止溢出發(fā)生。要更改VFE時鐘,需打Vendor/qcom/proprietary/mm-camera/mm-camera2/media-controller/modules/sensors/sensor_libs/xxxx/ xxxx_lib.c文并編輯 op_pixel_clk 參數(shù)。

• 選擇正確的 VFE 時鐘非常重要。VFE 時鐘頻率應足夠高以匹配傳感器輸出端的數(shù)據(jù)速率(即傳感器輸出幀 x 幀/s),否則可能會引起 ISPIF 溢出。不過也不應設置過高的頻率。設置過高的 VFE 時鐘頻率會導致兩類問題:

1. 由于可能填充內部 VFE 輸出緩存(也稱為統(tǒng)一緩存),總線溢出的幾率增大。

2. 如果 VFE 時鐘頻率較高,會導致功耗增大。

A. 檢查與 VFE 總線溢出相關的總線時鐘

• 當過多的 VFE 數(shù)據(jù)流量以超過可用總線帶寬的速率產生時,會導致 VFE 總線溢出錯誤。解決該問題的一種可行方法是檢查能否通過設置更高的總線時鐘頻率來增加總線帶寬。例如在 MSM8916 芯片組中,VFE 生成處理后的輸出幀到系統(tǒng) NoC (SNoC) 總線。數(shù)據(jù)流隨后被轉發(fā)到總線集成內存控制器 (BIMC) 總線,暫時保存在 DDR 內存中。VFE 生成的數(shù)據(jù)流將在這兩條總線形成的路徑上運行。因此,SNoC 和 BMIC 總線都必須進行檢查。adb shell 腳本每隔一秒會轉儲 SNoC 和 BIMC 時鐘頻率。

#adb shell "while true; do cat /d/clk/snoc_clk/measure; cat /d/clk/bimc_clk/measure; echo '-----'; sleep 1; done" 200001391 748805675 -----

B. 將時鐘總線設為最大頻率

• VFE 總線溢出分類的第一步是檢查能否通過設置更高總線時鐘頻率來增加可用總線帶寬。增加總線帶寬后,查看 VFE 總線溢出問題是否得以解決。

adb root adb shell sleep 1?

adb shell mount -t debugfs none /d?

adb shell echo "22 > /d/msm-bus-dbg/shell-client/mas"?

adb shell echo "512 > /d/msm-bus-dbg/shell-client/slv"?

adb shell echo "0 > /d/msm-bus-dbg/shell-client/ab"?

adb shell echo "6400000000 > /d/msm-bus-dbg/shell-client/ib"?

adb shell echo "1 > /d/msm-bus-dbg/shell-client/update_request"

• 以上腳本嘗試設置從 MDP(顯示硬件模塊)到 DDR 內存路徑中的所有總線。不管攝像頭如何操作,通過從 MDP 顯示屏側(ID 22 表示 MDP)請求高帶寬,總線會始終保持最大時鐘頻率。選擇顯示屏 (MDP) 而不是攝像頭 ISP (VFE) 的原因是顯示屏 MDP 一直運行,而攝像頭驅動程序在啟動和停止時會覆蓋攝像頭表決。而且這種更簡單的測試場景能解決所有起伏問題。通過以上測試,再次檢查總線時鐘是否增加到最大頻率。應用上述設置后,SNoC 和BIMC 時鐘頻率分別應為 266 MHz 和 533 MHz（不同平臺參數(shù)不一致，對應不同的性能等級）。

• 如果沒有任何改進,可嘗試按以下步驟在 CPU 高性能模式下運行系統(tǒng)并設置最大總線時鐘頻率：

adb shell "echo 1 > /sys/devices/system/cpu/cpu1/online" adb shell "echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor"

C. 從 VFE 檢查 AB/IB 表決帶寬

• 在檢查 VFE 側要求的總 AB 和 IB 帶寬時,確保攝像頭已啟動。

• 運行以下命令:

adb root?

adb shell cat /d/msm-bus-dbg/client-data/msm_camera_isp?

1223.023734896?

curr ? : 1?

masters: 29 ??

slaves : 512 ??

ab ? ? : 100000000 ??

ib ? ? : 100000000 ??

1223.024648282?

curr ? : 2?

masters: 29 ??

slaves : 512 ??

ab ? ? : 200000000 ??

ib ? ? : 200000000 ??

1228.214552238?

curr ? : 1?

masters: 29 ??

slaves : 512 ??

ab ? ? : 921819520 ??

ib ? ? : 921819520

• 輸出第一行中的數(shù)字 351.706326427 表示發(fā)出請求時的內核時間戳。Master(s) 29 表示總線流量來自 VFE,Slave(s) 512 表示總線流量的目的地設為 memory；AB/IB VFE 發(fā)出的最終寬帶請求分別為 930 MBps/1.62 GBps。

D. 識別 AXI 配置

• VFE 總線溢出日志經常始于表明某個具體寫入主控上出現(xiàn)溢出,因此內核日志顯示的首個溢出實例就顯得非常重要,可以幫助確認溢出來源。在 VFE 總線溢出分析(特別是 ZSL 預覽場景)過程中,通常要求找到具體圖像寫入主器件和預覽/快照輸出幀面的映射關系,以確定要優(yōu)化的數(shù)據(jù)流。例如,確定預覽數(shù)據(jù)流的總線溢出后,僅關注預覽數(shù)據(jù)流。在內核中添加以下調試日志消息,并在 Salesforce 用列系統(tǒng)分享該日志。

--- a/drivers/media/platform/msm/camera_v2/isp/msm_isp_axi_util.c
+++ b/drivers/media/platform/msm/camera_v2/isp/msm_isp_axi_util.c
@@ -1384,8 +1384,10 @@ static int ?msm_isp_axi_stream_enable_cfg(
 ? ? ? ?if (stream_info->state == START_PENDING ||
 ? ? ? ? ? ? ? ?stream_info->state == RESUME_PENDING) {
 ? ? ? ? ? ? ? ?enable_wm = 1;
+ ? ? ? ?pr_err("__debug__: WM[%d] ENABLE, src = %d, max_width = %u\n",stream_info->wm[i], stream_info->stream_src, stream_info->max_width);
 ? ? ? ?} else {
 ? ? ? ? ? ? ? ?enable_wm = 0;
+ ? ? ? ?pr_err("__debug__: WM[%d] DISENABLE, src = %d, max_width = %u\n",stream_info->wm[i], stream_info->stream_src, stream_info->max_width);
 ? ? ? ?}

E. 增加 AB/IB

• 如果將時鐘總線設為最大頻率，能夠解決buffer ovflow的問題，可以嘗試增加總體總線時鐘頻率，總線時鐘頻率只會在攝像頭工作時增加,逐漸增加或將原來數(shù)字乘2或逐漸減少來找出最優(yōu)數(shù)量。

//kernel/drivers/media/platform/msm/camera_v2/isp/msm_isp_util.c

62 #define MSM_ISP_MIN_AB 100000000 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 63 #define MSM_ISP_MIN_IB 100000000

F. 提高VFE 突發(fā)長度變化

• 盡管最優(yōu) VFE 突發(fā)長度沒有明確答案,但改變 VFE 突發(fā)長度也能夠減少 VFE 總線溢出問題。

28 #define VFE40_BURST_LEN 1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 29 #define VFE40_BURST_LEN_8916_VERSION 2 30 #define VFE40_BURST_LEN_8952_VERSION 3 33 #define VFE40_STATS_BURST_LEN 1 34 #define VFE40_STATS_BURST_LEN_8916_VERSION 2

（二）sof freeze

• sof freeze（SOF：start of frame）表示ISP這邊沒有收到sensor這邊輸出的圖像幀數(shù)據(jù)，這時必須檢查 CSID/CSIPHY/CAMIF是否出錯。有專門建立了thread來負責SOF的檢測，start_sof_check_thread() -> mct_bus_sof_thread_run()，log當中會有下面的錯誤發(fā)出：

// msm-3.18/drivers/media/platform/msm/camera_v2/msm.c

803 ? ? case MSM_CAM_V4L2_IOCTL_NOTIFY_DEBUG: { 804 ? ? ? ? if (event_data->status) { 805 ? ? ? ? ? ? pr_err("%s:Notifying subdevs about potential sof freeze\n", 806 ? ? ? ? ? ? ? ? __func__);

• 首先看能否dump出現(xiàn)數(shù)據(jù)：

 ?/*
 ? ? ? ?0 Disabled; this value is set by default
 ? ? ? ?2 Dump preview frames
 ? ? ? ?8 Dump snapshot frames
 ? ? ? ?16 Dump video frames
 ? ? ? ?*/

 ? ? ? ?adb root
 ? ? ? ?adb shell setprop persist.camera.isp.dump 8
 ? ? ? ?adb shell chmod 777 /data
Verifying the VFE hardware configuration

 ? ?In the msm_isp_axis_util.c file, locate the following code snippet:

 ? ?if (vfe_dev->dump_reg)
 ? ? msm_camera_io_dump_2(vfe_dev->vfe_base, 0x900);

• Replace it with:

24 if (1) 25 msm_camera_io_dump_2(vfe_dev->vfe_base, 0x900);

• 若聲明的傳感器輸出大小與 VFE 實際接收到的傳感器輸出大小之間不匹配,將發(fā)生 CAMIF錯誤。

//mm-camera/mm-camera2/media-controller/modules/iface2/iface_util.c

//mm-camera/mm-camera2/media-controller/modules/iface2/iface_util.c

8878 static void iface_util_dump_camif_cfg(struct msm_vfe_input_cfg *input_cfg) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 8879 { 8880 ? struct msm_vfe_pix_cfg *pix_cfg = NULL; 8881 8882 ? if (input_cfg == NULL) 8883 ? ? return; 8884 8885 ? pix_cfg = &input_cfg->d.pix_cfg; 8886 ? IFACE_HIGH("=====Camif DUMP cfg for PIX interface====\n"); 8887 ? IFACE_HIGH("camif input type = %d(MIPI=3), op_pix_clk = %d\n", 8888 ? ? pix_cfg->camif_cfg.camif_input, input_cfg->input_pix_clk); 8889 ? IFACE_HIGH("camif pix_pattern(RGRG-0/GRGR-1/BGBG-2/GBGB-3) = %d\n", 8890 ? ? pix_cfg->pixel_pattern); 8891 ? IFACE_HIGH("camif first_pix = %d, last_pix = %d\n", 8892 ? ? pix_cfg->camif_cfg.first_pixel, pix_cfg->camif_cfg.last_pixel); 8893 ? IFACE_HIGH("camif first_line = %d, last_line = %d\n", 8894 ? ? pix_cfg->camif_cfg.first_line, pix_cfg->camif_cfg.last_line); 8895 ? IFACE_HIGH("camif pixels_per_line = %d, lines_per_frame = %d\n", 8896 ? ? pix_cfg->camif_cfg.pixels_per_line, pix_cfg->camif_cfg.lines_per_frame); 8897 ? IFACE_HIGH("camif irq subsample pattern = %x, period = %d sof_step %d\n", 8898 ? ? pix_cfg->camif_cfg.subsample_cfg.irq_subsample_pattern, 8899 ? ? pix_cfg->camif_cfg.subsample_cfg.irq_subsample_period, 8900 ? ? pix_cfg->camif_cfg.subsample_cfg.sof_counter_step); 8901 }

• 將調試消息中指示的幀大小與 ISP 傳感器的幀大小進行比較。在以下 CAMIF 錯誤示例中,錯誤狀態(tài) 0x9a70a00 表示 ISP 接收幀的大小為 2471x2560(0x9a7 = 2471,0xa00 = 2560)。

01-01 08:07:20.175 E/mm-camera( 302): isp_hw_camif_dump_cfg: camif input_format= 0 01-01 08:07:20.175 E/mm-camera( 302): isp_hw_camif_dump_cfg: camif last_pix = 6527 01-01 08:07:20.175 E/mm-camera( 302): isp_hw_camif_dump_cfg: camif last_line = 0 01-01 08:07:20.175 E/mm-camera( 302): isp_hw_camif_dump_cfg: camif lines per frame = 2448 01-01 08:07:24.335 E/klogd (640): [81.563301] msm_vfe40_process_error_status: camif error status: 0x9a70a00

• 如果存在不匹配,則根本原因可能如下:

• 檢查傳感器設置是否正確,是否滿足分辨率大小的要求。例如,傳感器的輸出大小配置為 12 MB,但 ISP 的接收大小卻配置為 8 MB?？赡苡行﹤鞲衅鳠o法確保在新分辨率設置發(fā)送至傳感器后,最初的幀大小能夠滿足要求。在這種情況下,需要與傳感器供應商一起解決此問題。