Linux Camera Debugging Guide...Added storing 3A metadata in JPEG, actuator debugging, Android specs reference, Section 2.3.6, Section 5.3.6, and Chapter 13 . D : March 2015 . Edited

Qualcomm Technologies, Inc.

Confidential and Proprietary – Qualcomm Technologies, Inc.

NO PUBLIC DISCLOSURE PERMITTED: Please report postings of this document on public servers or websites to: [email protected].

Restricted Distribution: Not to be distributed to anyone who is not an employee of either Qualcomm Technologies, Inc. or its affiliated companies without the express approval of Qualcomm Configuration Management.

Not to be used, copied, reproduced, or modified in whole or in part, nor its contents revealed in any manner to others without the express written permission of Qualcomm Technologies, Inc.

Chromatix and MSM are products of Qualcomm Technologies, Inc. Other Qualcomm products referenced herein are products of Qualcomm Technologies, Inc. or its subsidiaries

Qualcomm, Chromatix, and MSM are trademarks of Qualcomm Incorporated, registered in the United States and other countries. Other product and brand names may be trademarks or registered trademarks of their respective owners.

This technical data may be subject to U.S. and international export, re-export, or transfer (“export”) laws. Diversion contrary to U.S. and international law is strictly prohibited.

Qualcomm Technologies, Inc. 5775 Morehouse Drive San Diego, CA 92121

U.S.A.

© 2014-2016 Qualcomm Technologies, Inc. All rights reserved.

Linux Camera Debugging Guide

80-NL239-33 F

October 7, 2016

mailto:%[email protected]

80-NL239-33 F Confidential and Proprietary – Qualcomm Technologies, Inc. 2 MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION

Revision history

Revision Date Description

A May 2014 Initial release B July 2014 Added Chinese translation; updated Section 3.3.3 and Section 5.3.2 C October 2014 Added storing 3A metadata in JPEG, actuator debugging, Android specs

reference, Section 2.3.6, Section 5.3.6, and Chapter 13 D March 2015 Edited for translation E April 2016 Added Chapter 4 and 12, Section 9.3, and other miscellaneous edits F October 2016 Updated the Section 1.1 and added Chapter 16


Contents

1 Introduction ...................................................................................................... 7 1.1 Purpose.......................................................................................................................... 7 1.2 Conventions .................................................................................................................. 7 1.3 Technical assistance ...................................................................................................... 7

2 Camera front end ............................................................................................. 8 2.1 Capture log information in camera HAL layer ............................................................. 8 2.2 Monitor KPI (KPI Perf) ................................................................................................ 8 2.3 Troubleshooting ............................................................................................................ 9

2.3.1 Thermal mitigation ............................................................................................ 9 2.3.2 fps profiling ..................................................................................................... 11 2.3.3 Dump buffers ................................................................................................... 11 2.3.4 Dump metadata ................................................................................................ 12 2.3.5 Enable full size live snapshot........................................................................... 12 2.3.6 Store 3A debug information in JPEG .............................................................. 13

3 Kernel module ................................................................................................ 15 3.1 Get kernel logs ............................................................................................................ 15 3.2 Debug calls from HAL................................................................................................ 16 3.3 Open device node ........................................................................................................ 20 3.4 Handle custom event via V4L2 ................................................................................... 21

4 General camera module logging .................................................................. 23 4.1 Logging levels ............................................................................................................. 23 4.2 Log module definitions ............................................................................................... 23

5 Media controller ............................................................................................. 25 5.1 Capture logs from the Media Controller module ........................................................ 25 5.2 Troubleshooting .......................................................................................................... 25

5.2.1 Media controller hangs during start/stop session ............................................. 25 5.2.2 Track stream information ................................................................................ 26

6 Sensor module ............................................................................................... 28 6.1 Validate GPIO, clock, and regulator settings in power-up/down sequence ............... 28

6.1.1 Validate register settings in CCI ...................................................................... 28 6.1.2 Validate CSIPHY settings ............................................................................... 28

6.2 CSID ........................................................................................................................... 30 6.3 Troubleshooting .......................................................................................................... 31

6.3.1 Unexecuted probe function .............................................................................. 31

Linux Camera Debugging Guide Contents


6.3.2 Probe failure..................................................................................................... 31 6.3.3 I2C error using CCI ......................................................................................... 32 6.3.4 No frames ........................................................................................................ 32 6.3.5 Dark preview ................................................................................................... 32 6.3.6 AF actuator ...................................................................................................... 33

7 ISP ISPIF module ........................................................................................... 35 7.1 Capture logs for the ISP module ................................................................................. 35 7.2 Troubleshooting .......................................................................................................... 35

7.2.1 Verify frame type ............................................................................................. 35 7.2.2 Verify VFE hardware configuration ................................................................ 36 7.2.3 Tap Raw Dump Interface (RDI) stream .......................................................... 37

8 Stats module .................................................................................................. 38 8.1 Capture logs from the Stats module ............................................................................ 38 8.2 Exposure ..................................................................................................................... 38 8.3 Flicker ......................................................................................................................... 41 8.4 Processing does not initiate ......................................................................................... 42 8.5 Examine events in Stats module ................................................................................. 42

9 Imaging library module ................................................................................. 43 9.1 Capture logs from the Imaging Library module ......................................................... 43 9.2 Capture logs related to FaceProc ................................................................................ 43 9.3 Imglib module level logging ....................................................................................... 44 9.4 Troubleshooting .......................................................................................................... 45

9.4.1 Image Quality (IQ) does not improve .............................................................. 45 9.4.2 Face detection configuration ............................................................................ 45

10 PProc module .............................................................................................. 46 10.1 Capture logs from the PProc module ........................................................................ 46 10.2 Profile hardware performance ................................................................................... 46 10.3 Troubleshoot deadlocks with mutex track logs ......................................................... 47 10.4 Troubleshooting ........................................................................................................ 47

10.4.1 Buffer underrun ............................................................................................. 47

11 Imaging codec layer .................................................................................... 49 11.1 Dump input buffers ................................................................................................... 49 11.2 Enable logs for mm-jpeg-interface ........................................................................... 50 11.3 Enable logs for OMX layer ....................................................................................... 51 11.4 ExIF issues ................................................................................................................ 52 11.5 Write new mm-jpeg-interface ................................................................................... 53 11.6 Cache invalidation .................................................................................................... 53

12 Encode JPEG ............................................................................................... 54 12.1 Dump YUV input to the JPEG encoder .................................................................... 54

13 Bus overflow ................................................................................................ 55



13.1 Identify VFE bus overflow error messages............................................................... 55 13.2 Select the right VFE clock frequency ....................................................................... 55 13.3 Check bus clocks related to VFE bus overflow ........................................................ 56 13.4 Set bus clock to its maximum frequency .................................................................. 57 13.5 Check AB/IB voting bandwidth from VFE .............................................................. 59 13.6 Identify AXI configuration ....................................................................................... 60 13.7 Increase AB/IB ......................................................................................................... 62 13.8 VFE burst length change ........................................................................................... 63 13.9 Dump SurfaceFlinger information ............................................................................ 63 13.10 Reduce CPU/memory-intensive operations ............................................................ 65 13.11 Guideline for bus profiling preparation (only if it is needed) ................................. 65

14 Stability debugging ..................................................................................... 66 14.1 User space stability debug without symbols in stack ................................................ 66 14.2 User space stability debug with stack symbols ......................................................... 67

15 Common Android specification violations ................................................ 69 15.1 Invalid camera ID in camera open ............................................................................ 69 15.2 Access same camera hardware from multiple camera clients ................................... 70

16 Customer configurable parameters ........................................................... 71

A References ..................................................................................................... 74 A.1 Related documents ..................................................................................................... 74 A.2 Acronyms and terms .................................................................................................. 75



Tables

Table 13-1 Bus frequencies ....................................................................................................................... 57 Table 13-2 Possible BIMC clock frequencies for MSM8916 .................................................................... 57


1 Introduction

1.1 Purpose This document provides debug tips for the Qualcomm Technologies, Inc. (QTI) Linux camera solutions. This document also provides information regarding customer configurable parameters.

Information in this document is generic to Linux camera code on MSM8916 and later chipsets, for example, MSM8939/MSM8909/MSM8952/MSM8976 and so on. However, a few examples in the document use the MSM8916 chipset code base.

1.2 Conventions Function declarations, function names, type declarations, attributes, and code samples appear in a different font, for example, #include.

Code variables appear in angle brackets, for example, <number>.

Commands to be entered appear in a different font, for example, copy a:*.* b:.

Button and key names appear in bold font, for example, click Save or press Enter.

If you are viewing this document using a color monitor, or if you print this document to a color printer, red boldface indicates code that is to be added, and blue strikethrough indicates code that is to be replaced or removed.

Shading indicates content that has been added or changed in this revision of the document.

1.3 Technical assistance For assistance or clarification on information in this document, submit a case to QTI at https://createpoint.qti.qualcomm.com/.

If you do not have access to the CDMATech Support website, register for access or send email to [email protected].

https://createpoint.qti.qualcomm.com/

mailto:[email protected]


2 Camera front end

The Camera front end interfaces with the Android camera stack and the camera driver in the kernel to enable various camera features. The source code is located in the HAL and the mm-camera-interface layers. The Camera front end code is located in the vendor/qcom/ hardware/qcom/camera/QCamera2 folder.

The Camera front end software is organized under the following subdirectories:

HAL – Contains core camera HAL source code

Stack – Contains interface source code for mm-camera and mm-jpeg

Util – Contains source code for utilities used by HAL

2.1 Capture log information in camera HAL layer 1. Open the vendor/qcom/hardware/qcom/camera/QCamera2/stack/

mm-camera-interface/inc folder.

2. In the mm_camera_dbg.h file, set LOG_DEBUG to 1 to enable logging.

#define LOG_DEBUG 1

2.2 Monitor KPI (KPI Perf) The KPI Perf log entry is inserted in many files to calculate the performance of different features and scenarios in the Camera module.

To view KPI log data, search for the keyword [KPI Perf] in the logcat output.

Sample log message from user space In the following example, PROFILE_OPEN_CAMERA and PROFILE_FIRST_PREVIEW_FRAME logs show the camera launch delay from the HAL perspective.

01:36:49.859 219 937 E QCamera2HWI: [KPI Perf] int qcamera::QCamera2HardwareInterface::openCamera(hw_device_t**): E PROFILE_OPEN_CAMERA camera id 0 01:36:50.919 219 937 E QCamera2HWI: [KPI Perf] static int qcamera::QCamera2HardwareInterface::start_preview(camera_device*): E PROFILE_START_PREVIEW

Linux Camera Debugging Guide Camera front end


01:36:52.129 219 937 D QCamera2HWI: [KPI Perf] static int qcamera::QCamera2HardwareInterface::start_preview(camera_device*): X

01:36:52.129 219 2918 E QCameraParameters: [KPI Perf] int32_t qcamera::QCameraParameters::setFaceDetection(bool): PROFILE_FACE_DETECTION_VALUE = 1 num_fd = 5

01:36:53.849 219 2978 D QCamera2HWI: [KPI Perf] static void qcamera::QCamera2HardwareInterface::preview_stream_cb_routine(mm_camera_super_buf_t*, qcamera::QCameraStream*, void*) : BEGIN 01:36:53.849 219 2978 E QCamera2HWI: [KPI Perf] static void qcamera::QCamera2HardwareInterface::preview_stream_cb_routine(mm_camera_super_buf_t*, qcamera::QCameraStream*, void*) : PROFILE_FIRST_PREVIEW_FRAME 01:36:53.849 219 2978 D QCamera2HWI: [KPI Perf] static void qcamera::QCamera2HardwareInterface::preview_stream_cb_routine(mm_camera_super_buf_t*, qcamera::QCameraStream*, void*) : END

2.3 Troubleshooting

2.3.1 Thermal mitigation The fps of a stream could slow down due to an event from the thermal adapter. This section describes how to use the debugging logs to identify such an event.

The thermal mitigation process:

1. Based on an event received from the thermal adapter, HAL calculates the frame to be skipped or the fps using the value specified for the persist.camera.thermal.mode property.

2. Once the calculation is completed, HAL calls the ISP module to lower the fps or skip the frames.

Thermal adapter events The levels of thermal events received from the thermal adapter are specified in qcamera_thermal_level_enum_t.

File: vendor/qcom/hardware/qcom/camera/QCamera2/HAL/QCameraThermalAdapter.h

typedef enum {

QCAMERA_THERMAL_NO_ADJUSTMENT = 0, QCAMERA_THERMAL_SLIGHT_ADJUSTMENT,

QCAMERA_THERMAL_BIG_ADJUSTMENT, QCAMERA_THERMAL_SHUTDOWN

} qcamera_thermal_level_enum_t;



Thermal mode The thermal modes are specified in qcamera_thermal_mode.

File: vendor/qcom/hardware/qcom/camera/QCamera2/HAL/QCameraThermalAdapter.h

typedef enum { QCAMERA_THERMAL_ADJUST_FPS,

QCAMERA_THERMAL_ADJUST_FRAMESKIP, } qcamera_thermal_mode;

Printing logs The following code is used to print logs showing input parameters, output parameters, and before and after thermal calculations.

File: vendor/qcom/hardware/qcom/camera/QCamera2/HAL/QCamera2HWI.cpp

ALOGE(“%s: level: %d, preview minfps %d, preview maxfpS %d”

“video minfps %d, video maxfpS %d”, __func__, level, minFPS, maxFPS, minVideoFps, maxVideoFps);

. . .

ALOGE(“%s: Thermal level %d, FPS [%3.2f,%3.2f, %3.2f,%3.2f], frameskip %d”, __func__, level, adjustedRange.min_fps, adjustedRange.max_fps,

adjustedRange.video_min_fps, adjustedRange.video_max_fps,skipPattern);

Setting the thermal mitigation method (frameskip or fps) Use ADB to set the persist.camera.thermal.mode property to enable thermal mitigation for frameskip or fps.

Syntax – adb shell setprop persist.camera.thermal.mode <value>

The following example sets the value to fps:

adb shell setprop persist.camera.thermal.mode fps

Value Description

frameskip Value set for frame skip fps Value set for lowering fps; this value is set by default



2.3.2 fps profiling Use ADB to set the persist.debug.sf.showfps property to enable fps profiling for preview or snapshot.

Syntax – persist.debug.sf.showfps <value>

The following example enables fps profiling:

adb shell setprop persist.debug.sf.showfps 1

Value Description

0 Disables profiling log 1 Enables profiling log; this value is set by default

To monitor fps profiling information, search for the following keywords in the logcat output:

PROFILE_PREVIEW_FRAMES_PER_SECOND Video Frames Per Second

2.3.3 Dump buffers To dump frame buffers from any stream to the file system, set the persist.camera.dumping property with the appropriate 32-bit value.

Bits Description

31:16 Default number of frames to be dumped is 10 frames. Maximum value of setting is 65,535. The maximum number of frames that get dumped is 256. Beyond 256, the existing dump files are overwritten in a circular buffer fashion. Value n indicates the setting n+1.

15:8 Number of frames to skip between each successive frame dump; default is no frame skip. Maximum value is 255. Value n indicates the setting n+1.

7:0 Type of frame to dump; for guidelines on which bits to set, refer to the definitions in vendor/qcom/hardware/qcom/camera/QCamera2/HAL/QCamera2HWI.h #define QCAMERA_DUMP_FRM_PREVIEW 1 #define QCAMERA_DUMP_FRM_VIDEO (1<<1) #define QCAMERA_DUMP_FRM_SNAPSHOT (1<<2) #define QCAMERA_DUMP_FRM_THUMBNAIL (1<<3) #define QCAMERA_DUMP_FRM_RAW (1<<4) #define QCAMERA_DUMP_FRM_JPEG (1<<5) #define QCAMERA_DUMP_FRM_MASK_ALL 0x000000ff

The feature works only if the QCAMERA_DUMP_FRM_LOCATION (/data/misc/camera) folder has write permissions.



The following commands enable frame dump setting before launching the camera application.

adb root adb shell chmod 777 /data/misc/camera

adb shell setprop persist.camera.dumpimg 655615

In this example, 655615 (0xA00FF in hexadecimal) refers to any preview, video, snapshot, thumbnail, raw, or JPEG frames, which are dumped to the /data/misc/camera folder for 10 successive frames, based on the operation mode of the camera application.

Function QCamera2HardwareInterface::dumpFrameToFile() from file /vendor/qcom/hardware/qcom/camera/QCamera2/HAL/QCamera2HWICallbacks.cpp is used to dump the files under the /data folder. For file naming conventions used for each frame type, refer to the dumpFrameToFile() function in source.

2.3.4 Dump metadata To dump metadata to a file, use ADB to set the persist.camera.dumpmetadata property with the applicable value.

Syntax – persist.camera.dumpmetadata <value>

Value Description

0 Disables dumping metadata; this value is set by default 1 Enables dumping metadata

This feature works only if the /data folder has write permissions. Issue the following commands to enable the frame dump setting before launching the camera application.

adb root

adb shell chmod 777 /data adb shell setprop persist.camera.dumpmetadata 1

2.3.5 Enable full size live snapshot To test full size live snapshot, run the following commands before launching the camcorder:

adb root

adb shell setprop persist.camera.opt.livepic 0

By default, persist.camera.opt.livepic is set to 1. When set to 0, resolution of the captured live snapshot is same as the camera sensor’s output resolution for the given operation mode of camcorder.



To achieve a snapshot of the same size as the maximum camera output dimension,

Configure the aspect ratio of the preview/video to be the same as the maximum camera output dimension. For example, consider a 13 MP camera with a 4:3 aspect ratio.

The camcorder preview/video resolution should have a 4:3 aspect ratio.

Set persist.camera.opt.livepic to 0 to configure the camera sensor to full size Output mode.

The 13 MP live snapshot image is captured.

However, if the preview/video aspect ratio is 16:9 and the sensor driver has a 16:9 aspect ratio setting in its sensor_out_info array, the sensor operates in that 16:9 resolution.

Therefore the live snapshot captures the same resolution. It is smaller than 13 MP.

This mode consumes more power due to its full size camera operation, and impacts the maximum possible frame rate due to maximum VFE clock capacity.

When persist.camera.opt.livepic is not set, or set to 1, the camera operates in a smaller size (video size or QTR size). It is based on the preview/video aspect ratio and the dimension settings present in the camera driver’s sensor_out_info array. When a live snapshot is captured, its dimensions are the same as the dimensions of the recorded video file.

2.3.6 Store 3A debug information in JPEG To store 3A-related metadata in a custom app segment of a JPEG image, set the persist.camera.mobicat property to 1 from the ADB shell with root access. This feature provides information about the 3A state when debugging complex IQ issues in the field. Captured data is viewed using the Chromatix™ color optimization tool version 6. See 3A Debug Information Visualization Feature section in Presentation: Chromatix 6 Camera Tuning for MSM8994/APQ8084 (80-NK872-4) for more details on this viewer interface. This is a debug-only feature and should not be enabled in production builds.

The following function shows where Camera HAL retrieves the property that decides whether to store 3A debug information in JPEG.

File: hardware/qcom/camera/QCamera2/HAL/QCameraParameters.cpp Function: setMobicat() ... property_get("persist.camera.mobicat", value, "0");

bool enableMobi = atoi(value) > 0 ? true : false; ...

3A modules in mm-camera share 3A-related debug metadata with Camera HAL through the metadata channel. Camera HAL extracts this metadata data from the metadata channel and passes it to JPEG layers. To check the validity of 3A metadata before passing it to JPEG layers, use the following code:



File: hardware/qcom/camera/QCamera2/HAL/QCameraPostProc.cpp Function: encodeData() ... if (NULL != jpg_job.encode_job.p_metadata && m_parent->mParameters.isMobicatEnabled() && jpeg_job_data->metadata != NULL) { memcpy(jpg_job.encode_job.p_metadata->

chromatix_mobicat_af_data.private_mobicat_af_data, jpg_job.encode_job.cam_exif_params.af_mobicat_params,

sizeof(jpg_job.encode_job.cam_exif_params.af_mobicat_params));

/* Save a copy of 3A debug params */ jpg_job.encode_job.p_metadata->is_mobicat_ae_params_valid =

jpg_job.encode_job.cam_exif_params.ae_debug_params_valid; jpg_job.encode_job.p_metadata->is_mobicat_awb_params_valid =

jpg_job.encode_job.cam_exif_params.awb_debug_params_valid; jpg_job.encode_job.p_metadata->is_mobicat_af_params_valid =

jpg_job.encode_job.cam_exif_params.af_debug_params_valid; jpg_job.encode_job.p_metadata->is_mobicat_asd_params_valid =

jpg_job.encode_job.cam_exif_params.asd_debug_params_valid; jpg_job.encode_job.p_metadata->is_mobicat_stats_params_valid =

jpg_job.encode_job.cam_exif_params.stats_debug_params_valid;

if (jpg_job.encode_job.cam_exif_params.ae_debug_params_valid) { jpg_job.encode_job.p_metadata->mobicat_ae_data =

jpg_job.encode_job.cam_exif_params.ae_debug_params; }

if (jpg_job.encode_job.cam_exif_params.awb_debug_params_valid) { jpg_job.encode_job.p_metadata->mobicat_awb_data =

jpg_job.encode_job.cam_exif_params.awb_debug_params; }

if (jpg_job.encode_job.cam_exif_params.af_debug_params_valid) { jpg_job.encode_job.p_metadata->mobicat_af_data =

jpg_job.encode_job.cam_exif_params.af_debug_params; }

if (jpg_job.encode_job.cam_exif_params.asd_debug_params_valid) { jpg_job.encode_job.p_metadata->mobicat_asd_data =

jpg_job.encode_job.cam_exif_params.asd_debug_params; }

if (jpg_job.encode_job.cam_exif_params.stats_debug_params_valid) { jpg_job.encode_job.p_metadata->mobicat_stats_buffer_data =

jpg_job.encode_job.cam_exif_params.stats_debug_params; }

}


3 Kernel module

This chapter provides debug information for the camera driver located in the kernel, and is responsible for the following operations:

Create V4L2 devices

Service V4L2 system calls

Create session/stream creation

Buffer management for various streams

3.1 Get kernel logs To collect kernel logs, run the following commands:

adb root

adb shell cat /proc/ksmg > <filename>

There are two main files in camera kernel drivers. As needed, more logs can be added to these for debugging.

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

Creates MSM chipsets configuration node

Sets up session queue

Posts events to the mm-camera backend and waits for the reply

Manages V4L2 streams and buffers

kernel/drivers/media/platform/msm/camera_v2/camera/camera.c

Creates video device node at bootup time

Contains functions to service V4L2 IOCTLs and file operations

Creates session and stream

Linux Camera Debugging Guide Kernel module


3.2 Debug calls from HAL The command, status, and arg_value are helpful to understand the type of call from the HAL layer.

The msm_v4l2_event_data is a structure defined in kernel/include/media/msmb_camera.h, which contains various fields from the user data. Valuable information about the command, stream, and session can be extracted using the following code changes.

To debug calls from the HAL:

1. Move to the Kernel/drivers/media/platform/msm/camera_v2/ folder.

2. In the msm.c file, make the following changes to the msm_post_event() function

If you are viewing this document using a color monitor, or if you print this document to a color printer, red boldface indicates code that is to be added, and blue strikethrough indicates code that is to be replaced or removed.

int msm_post_event(struct v4l2_event *event, int timeout)

{ ...

...

cmd = msm_dequeue(&cmd_ack->command_q, struct msm_command, list);

if (!cmd) { mutex_unlock(&session->lock);

pr_err("%s : cmd dequeue failed Line %d\n", __func__, __LINE__);

return -EINVAL; }

event_data = (struct msm_v4l2_event_data *)cmd->event.u.data;

pr_err("__debug__: %s: cmd:0x%x (%u) status:%d sessionID:%d streamID:%d arg_value:%u ret_value:%u\n", __func__, event_data->command, (event_data->command >= V4L2_CID_PRIVATE_BASE) ? (event_data->command - V4L2_CID_PRIVATE_BASE) : event_data->command, event_data->status, event_data->session_id, event_data->stream_id, event_data->arg_value, event_data->ret_value);

/* compare cmd_ret and event */ ...

... }



The cmd is an IOCTL command sent by the user space. Examples of some frequently seen cmd values are as follows:

For cmd value 1 to 13, refer to kernel/include/media/msmb_camera.h. /* data.command */

#define MSM_CAMERA_PRIV_S_CROP (V4L2_CID_PRIVATE_BASE + 1) #define MSM_CAMERA_PRIV_G_CROP (V4L2_CID_PRIVATE_BASE + 2)

#define MSM_CAMERA_PRIV_G_FMT (V4L2_CID_PRIVATE_BASE + 3) #define MSM_CAMERA_PRIV_S_FMT (V4L2_CID_PRIVATE_BASE + 4)

#define MSM_CAMERA_PRIV_TRY_FMT (V4L2_CID_PRIVATE_BASE + 5) #define MSM_CAMERA_PRIV_METADATA (V4L2_CID_PRIVATE_BASE + 6)

#define MSM_CAMERA_PRIV_QUERY_CAP (V4L2_CID_PRIVATE_BASE + 7) #define MSM_CAMERA_PRIV_STREAM_ON (V4L2_CID_PRIVATE_BASE + 8)

#define MSM_CAMERA_PRIV_STREAM_OFF (V4L2_CID_PRIVATE_BASE + 9) #define MSM_CAMERA_PRIV_NEW_STREAM (V4L2_CID_PRIVATE_BASE + 10)

#define MSM_CAMERA_PRIV_DEL_STREAM (V4L2_CID_PRIVATE_BASE + 11) #define MSM_CAMERA_PRIV_SHUTDOWN (V4L2_CID_PRIVATE_BASE + 12)

#define MSM_CAMERA_PRIV_STREAM_INFO_SYNC \ (V4L2_CID_PRIVATE_BASE + 13)

For cmd value 14 onward, refer to hardware/qcom/camera/QCamera2/stack/common /cam_intf.h #define CAM_PRIV_IOCTL_BASE (V4L2_CID_PRIVATE_BASE + 14)

typedef enum { /* session based parameters */

CAM_PRIV_PARM = CAM_PRIV_IOCTL_BASE, /* session based action: do auto focus.*/

CAM_PRIV_DO_AUTO_FOCUS, /* session based action: cancel auto focus.*/

CAM_PRIV_CANCEL_AUTO_FOCUS, /* session based action: prepare for snapshot.*/

CAM_PRIV_PREPARE_SNAPSHOT, /* sync stream info.*/

CAM_PRIV_STREAM_INFO_SYNC, /* stream based parameters*/

CAM_PRIV_STREAM_PARM, /* start ZSL snapshot.*/

CAM_PRIV_START_ZSL_SNAPSHOT, /* stop ZSL snapshot.*/

CAM_PRIV_STOP_ZSL_SNAPSHOT, } cam_private_ioctl_enum_t;



Status indicates the status of the command after the IOCTL execution completes

/* data.status - success */ #define MSM_CAMERA_CMD_SUCESS 0x00000001

#define MSM_CAMERA_BUF_MAP_SUCESS 0x00000002

/* data.status - error */ #define MSM_CAMERA_ERR_EVT_BASE 0x00010000

#define MSM_CAMERA_ERR_CMD_FAIL (MSM_CAMERA_ERR_EVT_BASE + 1) #define MSM_CAMERA_ERR_MAPPING (MSM_CAMERA_ERR_EVT_BASE + 2)

The arg_value presents additional argument/payload sent along with the IOCTL. It could either be an integer value, output structure, or pointer to it, and can be referred based on the use case.

The ret_value presents additional argument/payload sent along with the function call return from kernel to user space after the IOCTL execution completes. It could either be an integer value, output structure, or pointer to it, and can be referred based on the use case.

Log example – Non-ZSL snapshot with flash on Each stream-specific log is shown only once, for any one of the streams.

[ 176.392026] __debug__: msm_post_event: cmd:0x8000007(7) status:1 sessionID:1 streamID:0 arg_value:4294967295 ret_value:3222278380

>> Query cap (cmd = 7)

[ 176.993840] __debug__: msm_post_event: cmd:0x800000a(10) status:1 sessionID:1 streamID:1 arg_value:4294967295 ret_value:3276704796

>> New stream creation logs (e.g. preview/metadata; cmd = 10)

[ 177.079512] __debug__: msm_post_event: cmd:0x8000008(8) status:1 sessionID:1 streamID:1 arg_value:4294967295 ret_value:0 >> Stream_on for all created streams (e.g. preview/metadata; cmd = 8)

[ 185.034507] __debug__: msm_post_event: cmd:0x800000f(15) status:1 sessionID:1 streamID:0 arg_value:0 ret_value:3222278380

>> Auto focus (cmd = 15)


>> Prepare snapshot (cmd = 17)

[ 186.246369] __debug__: msm_post_event: cmd:0x8000009(9) status:1 sessionID:1 streamID:2 arg_value:4294967295 ret_value:3222278380 >> Stream_off for all created streams (e.g. preview/metadata; cmd = 9)

>> This turns off the preview, to prepare for snapshot event.

[ 186.274678] __debug__: msm_post_event: cmd:0x800000b(11) status:1 sessionID:1 streamID:1 arg_value:4294967295 ret_value:4073324252



>> Detete the streams (e.g. preview/metadata; cmd = 11)


>> Create new streams for snapshot (e.g. snapshot/postview/metadata; cmd = 10)


>> Stream_on for all created streams (e.g. snapshot/postview/metadata; cmd = 8)

[ 186.894840] __debug__: msm_post_event: cmd:0x8000009(9) status:1 sessionID:1 streamID:6 arg_value:4294967295 ret_value:3222278380 >> Stream_off for all created streams (e.g. snapshot/postview/metadata; cmd = 9) >> This turns off the snapshot related streams, to prepare for resuming preview.

[ 186.908452] __debug__: msm_post_event: cmd:0x800000b(11) status:1 sessionID:1 streamID:6 arg_value:4294967295 ret_value:4073299676

>> Detete the streams (e.g. snapshot/postview/metadata; cmd = 11)


>> New stream creation logs (e.g. preview/metadata; cmd = 10)

[ 187.210204] __debug__: msm_post_event: cmd:0x8000008(8) status:1 sessionID:1 streamID:7 arg_value:4294967295 ret_value:0 >> Stream_on for all created streams (e.g. preview/metadata; cmd = 8)

>> Non-ZSL preview resumes



3.3 Open device node To debug issues related to opening the device node, add logs in camera_v4l2_open() of kernel/drivers/media/platform/msm/camera_v2/camera/camera.c. Also add logs in msm_post_event() as follows:

int msm_post_event(struct v4l2_event *event, int timeout) {

...

...

cmd = msm_dequeue(&cmd_ack->command_q,

struct msm_command, list); if (!cmd) {

mutex_unlock(&session->lock); pr_err("%s : cmd dequeue failed Line %d\n",

__func__, __LINE__); return -EINVAL;

}

event_data = (struct msm_v4l2_event_data *)cmd->event.u.data;

pr_err("__debug__: %s: cmd:0x%x (%u), requested event = %d, executed event = %d, status:%d sessionID:%d streamID:%d arg_value:%u ret_value:%u\n", __func__, event_data->command, (event_data->command >= V4L2_CID_PRIVATE_BASE) ? (event_data->command - V4L2_CID_PRIVATE_BASE) : event_data->command, event->id, cmd->event.id, event_data->status, event_data->session_id, event_data->stream_id, event_data->arg_value, event_data->ret_value);

/* compare cmd_ret and event */ ... ... }

The requested_event and executed_event must be the same for the error-free case. For event ID, refer to kernel/include/media/msmb_camera.h.

/* event id */ #define MSM_CAMERA_EVENT_MIN 0

#define MSM_CAMERA_NEW_SESSION (MSM_CAMERA_EVENT_MIN + 1)



Log example For camera launch, a new_session is created.

[ 176.379306] __debug__: msm_post_event: cmd:0x0(0), requested_event = 1, executed_event = 1, status:1 sessionID:1 streamID:0 arg_value:4294967295 ret_value:4080909716 >> New session created upon launching camera (requested_event = 1)

3.4 Handle custom event via V4L2 User space drivers for various camera hardware blocks, for example, ISP, CPP, interact with their kernel space counterpart drivers via custom V4L2 events. When user or kernel logs indicate hardware error, or drivers for a specific hardware block behave incorrectly, more logs are added in the custom event handlings to get more debug information.

Suscbription_function(...)

{ int rc = 0;

struct v4l2_event_subscription sub;

memset(&sub, 0, sizeof(sub)); sub.type = event_type; //Type of the event to suscribe if (isp_hw->fd < 0) {

CDBG_ERROR("%s: error, isp_hw->fd is incorrect", __func__); }

if (subscribe)

rc = ioctl(isp_hw->fd, VIDIOC_SUBSCRIBE_EVENT, &sub); //fd points to the subdevice for a given hardware, e.g. ISP/CPP etc.

For example, for ISP events, refer to kernel/include/media/msmb_isp.h.

#define ISP_EVENT_SOF (ISP_SOF_EVENT_BASE) #define ISP_EVENT_EOF (ISP_EOF_EVENT_BASE)

#define ISP_EVENT_BUF_DONE (ISP_EVENT_BASE + ISP_BUF_DONE) #define ISP_EVENT_BUF_DIVERT (ISP_BUF_EVENT_BASE)

#define ISP_EVENT_STATS_NOTIFY (ISP_STATS_EVENT_BASE)

User space drivers can then get the event by polling the subdevice, followed by dequeuing the event; for example, in the case of an ISP module:

void isp_hw_proc_subdev_event(isp_hw_t *isp_hw, isp_thread_t *thread_data) {

...



memset(&v4l2_event, 0, sizeof(v4l2_event)); rc = ioctl(isp_hw->fd, VIDIOC_DQEVENT, &v4l2_event);

if (rc >= 0) {

isp_event_data = (struct msm_isp_event_data *)v4l2_event.u.data;

if ((v4l2_event.type & 0xFFFFFF00) >= ISP_EVENT_BUF_DIVERT) { input_src = v4l2_event.type & 0xFF;

v4l2_event.type &= ~input_src; }

switch(v4l2_event.type) {

case ISP_EVENT_STATS_NOTIFY:{


4 General camera module logging

The centralized camera logging API enables all camera submodules to issue log messages to trace execution, camera states, and any camera subsystem information in a uniform fashion. This increases the readability of camera subsystem logs.

4.1 Logging levels Run the following commands to enable the global debugging log.

adb shell setprop persist.camera.global.debug <global_debug_level>

The logging level definitions are at hardware/qcom/camera/QCamera2/ stack/common/cam_types.h

typedef enum {

CAM_GLBL_DBG_NONE = 0, CAM_GLBL_DBG_ERR = 1,

CAM_GLBL_DBG_WARN = 2, CAM_GLBL_DBG_HIGH = 3,

CAM_GLBL_DBG_DEBUG = 4, CAM_GLBL_DBG_LOW = 5,

CAM_GLBL_DBG_INFO = 6 } cam_global_debug_level_t;

4.2 Log module definitions Set global and module properties to the required logging levels from the command line. For example:

adb shell setprop persist.camera.global.debug 3

adb shell setprop persist.camera.sensor.debug 2

The following table lists the debug property names.

Debug property name Description

persist.camera.global.debug CAM_NO_MODULE (global debugging level property) persist.camera.mct.debug CAM_MCT_MODULE persist.camera.sensor.debug CAM_SENSOR_MODULE persist.camera.iface.logs CAM_IFACE_MODULE persist.camera.isp.debug CAM_ISP_MODULE persist.camera.stats.debug CAM_STATS_MODULE

Linux Camera Debugging Guide General camera module logging


Debug property name Description

persist.camera.stats.af.debug CAM_STATS_AF_MODULE persist.camera.stats.aec.debug CAM_STATS_AEC_MODULE persist.camera.stats.awb.debug CAM_STATS_AWB_MODULE persist.camera.stats.asd.debug CAM_STATS_ASD_MODULE persist.camera.stats.afd.debug CAM_STATS_AFD_MODULE persist.camera.stats.q3a.debug CAM_STATS_Q3A_MODULE persist.camera.stats.is.debug CAM_STATS_IS_MODULE persist.camera.stats.haf.debug CAM_STATS_HAF_MODULE persist.camera.pproc.debug.mask CAM_PPROC_MODULE persist.camera.imglib.logs CAM_IMGLIB_MODULE persist.camera.cpp.debug.mask CAM_CPP_MODULE persist.camera.hal.debug CAM_HAL_MODULE persist.camera.mmstill.logs CAM_JPEG_MODULE persist.camera.c2d.debug.mask CAM_C2D_MODULE persist.camera.debug.logfile When set to 1, write the log messages to

/data/misc/camera/cam_dbg_log.txt persist.camera.debug.assert When set to 1, will cause assert macros to issue a soft break

The default logging level is CAM_GLBL_DBG_ERROR for all modules. To log selected camera modules, suppress logging for the entire camera subsystem, except for the required.

For example:

Turn off all camera logging – adb shell setprop persist.camera.global.debug 0

Turn off logging for a single module – adb shell setprop persist.camera.isp. debug 0

The effective logging level for a module is determined by the higher value between the global and each module level (that is, max (global, module)) level, as long as the logging level for neither module is set to 0.

Global logging level takes precedence when higher than module logging level. For example, setting the following property causes all modules, including isp, to log error, high, and warning messages:

adb shell setprop persist.camera.global.debug 3 adb shell setprop persist.camera.isp.debug 1

Module logging level takes precedence when higher than global logging level but causes the ISP module to log error, high, and warning messages whereas all other modules are restricted to error logs only.

adb shell setprop persist.camera.global.debug 1

adb shell setprop persist.camera.isp.debug 3


5 Media controller

The media controller in the QTI camera framework is responsible for controlling the other camera’s modules. It is a service that runs in the background and is started from the init process. It is also known as camera daemon.

5.1 Capture logs from the Media Controller module 1. Move to the vendor/qcom/proprietary/mm-camera/mm-camera2/ folder. 2. In the camera_dbg.h file, set LOG_DEBUG to 1 to enable logging.

#define LOG_DEBUG 1

5.2 Troubleshooting

5.2.1 Media controller hangs during start/stop session Possible cause The media controller calls the start and stop session for each of the Camera modules. During these processes, the modules may hang due to an internal issue, which causes the Media Controller to hang. This event prevents the Media Controller from starting a session.

Debugging 1. Observe the log messages related to entering and exiting the start/stop session. 2. Add logs at the end of the xxxx_start_session and xxxx_stop_session functions for

each of the following modules to track start/stop session processing for each module: vendor/qcom/proprietary/mm-camera/mm-camera2/media-

controller/modules/sensors/module/module_sensor.c

vendor/qcom/proprietary/mm-camera/mm-camera2/media-controller/modules/sensors/module/isp/module_isp.c

vendor/qcom/proprietary/mm-camera/mm-camera2/media-controller/modules/sensors/module/pproc-new/ pproc_module.c

vendor/qcom/proprietary/mm-camera/mm-camera2/media-controller/modules/sensors/module/stats/stats_module.c

vendor/qcom/proprietary/mm-camera/mm-camera2/media-controller/modules/sensors/modules /imglib/modules/module_imglib.c

3. Analyze the last command sent from HAL to determine which command causes a module to hang.

Linux Camera Debugging Guide Media controller


5.2.2 Track stream information Tracking stream information is used to identify the stream type and command in which the stream fails.

Search for the following keywords in the user space log message:

stream_type – Used to observe the stream type of the currently running stream

command= – Used to observe the command type sent to the Media Controller module from HAL

To track stream information:

1. Move to the vendor/qcom/proprietary/mm-camera/mm-camera2/media-controller/mct/pipeline folder.

2. Add the following code to mct_pipeline.c: static boolean mct_pipeline_process_set(struct msm_v4l2_event_data *data,

mct_pipeline_t *pipeline) {

... ALOGE("%s:command=%x", __func__, data->command);

. . . case MSM_CAMERA_PRIV_STREAM_ON:

case MSM_CAMERA_PRIV_STREAM_OFF:{ . . .

ALOGE("%s: stream_type = %d\n", __func__, stream->streaminfo.stream_type);

Sample log The following snippet shows log messages that output command and stream type. In this example, the command is MSM_CAMERA_PRIV_STREAM_ON (8000008) and stream types are

CAM_STREAM_TYPE_METADATA(7) and CAM_STREAM_TYPE_PREVIEW (1).

E mm-camera: mct_pipeline_process_set:command=8000004

E mm-camera-intf: mm_stream_request_buf: buf_num = 7, stream type = 7 E mm-camera: mct_pipeline_process_set:command=8000008

E mm-camera: mct_pipeline_process_set: stream_type = 7 E mm-camera-intf: mm_stream_request_buf: buf_num = 8, stream type = 1

E mm-camera: mct_pipeline_process_set:command=8000008 E mm-camera: mct_pipeline_process_set: stream_type = 1

Linux Camera Debugging Guide Media controller


Stream types are defined in hardware/qcom/camera/QCamera2/stack/common/cam_types.h.

typedef enum {

/* applies to HAL 1 */ CAM_STREAM_TYPE_DEFAULT, /* default stream type */

CAM_STREAM_TYPE_PREVIEW, /* preview */ CAM_STREAM_TYPE_POSTVIEW, /* postview */

CAM_STREAM_TYPE_SNAPSHOT, /* snapshot */ CAM_STREAM_TYPE_VIDEO, /* video */

/* applies to HAL 3 */

CAM_STREAM_TYPE_CALLBACK, /* app requested callback */ CAM_STREAM_TYPE_IMPL_DEFINED, /* opaque format: could be display, video enc, ZSL YUV */

/* applies to both HAL 1 and HAL 3 */

CAM_STREAM_TYPE_METADATA, /* meta data */ CAM_STREAM_TYPE_RAW, /* raw dump from camif */

CAM_STREAM_TYPE_OFFLINE_PROC, /* offline process */ CAM_STREAM_TYPE_MAX,

} cam_stream_type_t;


6 Sensor module

The Sensor module is part of the QTI camera subsystem. The Sensor module incorporates the image sensor, and its responsibility is to capture the image, package the data, and pass the data to its neighbor module, ISPIF. This chapter describes debugging Sensor module.

6.1 Validate GPIO, clock, and regulator settings in power-up/down sequence

1. Move to the kernel/drivers/media/platform/msm/camera_v2/sensor/io folder.

2. In the msm_camera_dt_util.c file, add the following define to enable logging during the power-up/down sequence:

#define CONFIG_MSM_CAMERA_DT_DEBUG

6.1.1 Validate register settings in CCI The Camera Control Interface (CCI) is a dedicated hardware that performs I2C operation for camera slave devices. Enable logging in CCI release source files to validate register settings.

1. Move to the kernel/drivers/media/platform/msm/camera_v2/sensor/cci/ folder.

2. In the msm_cci.c file, add the following define to enable logging:

#define CONFIG_MSMB_CAMERA_DEBUG

6.1.2 Validate CSIPHY settings 1. Locate kernel/drivers/media/platform/msm/camera_v2/sensor/csiphy folder.

2. In the msm_csiphy.c file, run the following commands to enable logging:


#define DBG_CSIPHY 1

3. Run the following to enable CSIPHY register dump:

#if DBG_CSIPHY static void msm_csiphy_io_dump(void __iomem *addr, int size)

{ char line_str[128], *p_str;

int i; u32 *p = (u32 *) addr;

u32 data; pr_err("%s: %p %d\n", __func__, addr, size);

Linux Camera Debugging Guide Sensor module


line_str[0] = '\0';

p_str = line_str; for (i = 0; i < size/4; i++) {

if (i % 4 == 0) { snprintf(p_str, 12, "%p: ", p);

p_str += 10; }

data = readl_relaxed(p++); snprintf(p_str, 12, "%08x ", data);

p_str += 9; if ((i + 1) % 4 == 0) {

pr_err("%s\n", line_str); line_str[0] = '\0';

p_str = line_str; }

} if (line_str[0] != '\0')

pr_err("%s\n", line_str); }

. . . static long msm_csiphy_cmd(struct csiphy_device *csiphy_dev, void *arg)

{ . . .

case CSIPHY_CFG: if (copy_from_user(&csiphy_params,

sizeof(struct msm_camera_csiphy_params))) { pr_err("%s: %d failed\n", __func__, __LINE__);

rc = -EFAULT; break;

} rc = msm_csiphy_lane_config(csiphy_dev, &csiphy_params);

pr_err("CSIPHY register dump\n"); msm_csiphy_io_dump(csiphy_dev->base, (int)resource_size(csiphy_dev->mem))

break;

Sample log From the kernel space log:

msm_csiphy_init:289 called csiphy_dev->hw_version 1

msm_csiphy_lane_config csiphy_params, mask = 3 cnt = 2 settle cnt = 7 csid 0



6.2 CSID Enable logging in CSID-related source files to validate CSID settings.

File location 1. Move to the kernel/drivers/media/platform/msm/camera_v2/sensor/csid folder.

2. In the msm_csid.c file, define the log macro.


#define DBG_CSID 1

3. Run the following to enable CSID register dump.

#if DBG_CSID

static void msm_csid_io_dump(void __iomem *addr, int size)

{

static long msm_csid_cmd(struct csid_device *csid_dev, void *arg) {

. . . case CSID_CFG: {

. . . rc = msm_csid_config(csid_dev, &csid_params);

for (i--; i >= 0; i--) kfree(csid_params.lut_params.vc_cfg[i]);

pr_err("CSID register dump\n"); msm_csid_io_dump(csid_dev->base, (int)resource_size(csid_dev->mem));

break; }

case CSID_RELEASE:


msm_csid_init:329 called csid_dev->hw_version 2001000 msm_csid_config csid_params, lane_cnt = 2, lane_assign = e4, phy sel = 0

msm_csid_cid_lut lut params num_cid = 2, cid = 0, dt = 2b, df = 2 msm_csid_cid_lut lut params num_cid = 2, cid = 1, dt = 12, df = 1



6.3 Troubleshooting

6.3.1 Unexecuted probe function An unexecuted probe function during the bootup process prevents the creation of the video node and V4L2 subdev nodes.

Possible cause The node for the corresponding hardware may be missing or incorrectly configured in the .dtsi file.

Debugging 1. Locate to the kernel/arch/arm/boot/dts folder.

2. Verify that the hardware node in the corresponding .dtsi file is configured correctly.

See usage-model.txt file for more information on how to create or modify a node in the .dtsi file. The usage-model.txt file is found in the kernel/Documentation/ devicetree folder.

6.3.2 Probe failure A failure in the probe function prevents the creation of video node.

Possible cause Wrong hardware is connected

Connection issue

Failure in power-up sequence

Mismatch between the chip ID from the hardware and the corresponding node in the .dtsi file

Debugging

NOTE: File a case at https://createpoint.qti.qualcomm.com/ if the debugging case is a hardware issue.

From the possible causes, debugging can be done as follows:

1. Move to the kernel/drivers/media/platform/msm/camera_V2/sensor/io folder.

2. In the msm_camera_dt_util.c file, define the macro

#define CONFIG_MSM_CAMERA_DT_DEBUG

3. In the kernel log, search for the keyword (function name) msm_camera_power_up. The log identifies the sequence type that fails.

4. Verify that the corresponding hardware kernel driver is implemented.

https://createpoint.qti.qualcomm.com/



5. Move to the kernel/arch/arm/boot/dts/ folder. In the msm8975-camera-sensor-cdp.dtsi file, ensure that the correct chip ID is specified in the hardware node.

qcom,camera@20 {

qcom,slave-id = <0x20 0x0016 0x0135>;

In this example, the imx135 is used. The driver for imx135 is located in kernel/drivers/media/platform/msm/camera_v2/sensor/imx135.c.

6.3.3 I2C error using CCI The error is caused from an I2C connection.

Possible cause The GPIO for the I2C data or clock is not correctly configured due to issues with the hardware pin layout.

Debugging 1. Verify and validate I2C data and clock configuration.

2. Ensure that the hardware pin layout is connected correctly.

3. Extract a CCI log to get more details about the configuration. See Section 6.1.1 for information on how to obtain the CCI log.

6.3.4 No frames There are no frames even after the start of stream.

Possible cause The sensor hardware may not be streaming.

The QTI hardware module cannot receive the incoming stream.

Debugging 1. Add logs in submodules (CSIPHY, CSID) and check whether they receive any packets.

2. Probe the pin to check if there is any activity in the data lane.

3. Verify whether register settings are configured properly for the problematic sensor.

4. Verify stop setting and settle count for the modules.

6.3.5 Dark preview The sensor transmits a stream and there is no problem in the CSID module receiving it. However, it contains dark frames.

Possible cause Incorrect calculation of exposure settings in the user space driver can cause a dark preview issue.



Debugging 1. Enable the AEC log using ADB.

adb shell setprop persist.camera.stats.debug.mask 1

The AEC log will be output through user space log messages.

2. Check the AEC log to verify that the exposure settings calculation is configured correctly.

6.3.6 AF actuator When the autofocus does not respond at all or behaves abnormally, check the AF actuator IOCTL.

Possible cause Incorrect AF driver configuration

Broken AF actuator software call flow

Debugging 1. Enable the sensor module SLOW logging from the following location to debug the VCM

submodule.

FILE: vendor/qcom/proprietary/mm-camera/mm-camera2$ vi media-controller/modules/sensors/module/sensor_dbg.h

... /* Enable SLOG_LOW to print all log levels - SERR, SLOW and SHIGH */

//#define SLOG_LOW ...

2. Check the following logs to debug actuator lens movement-related issues. These logs show

the lens movement step size and direction before issuing the IOCTL command from the user space actuator driver.

FILE: mm-camera/mm-camera2/media-controller/modules/sensors/actuators/actuator.c FUNCTION: af_actuator_move_focus()

...

SLOW("dir:%d, steps:%d", cfg.cfg.move.dir, cfg.cfg.move.num_steps);

/* Invoke the IOCTL to move the focus */

rc = ioctl(af_actuator_ptr->fd, VIDIOC_MSM_ACTUATOR_CFG, &cfg); if (rc < 0) {

SERR("failed rc %d", rc); }

af_actuator_ptr->curr_step_pos = dest_step_pos; af_actuator_ptr->curr_lens_pos = cfg.cfg.move.curr_lens_pos;



SLOW("Exit");

return rc; }


7 ISP ISPIF module

The ISP, also known as the VFE in the Camera2 architecture, is responsible for processing the raw data stream from the sensor module and generating ISP output. This chapter describes troubleshooting tips for the ISP module.

7.1 Capture logs for the ISP module 1. Move to the kernel/drivers/media/platform/msm/camera_v2/isp folder.

2. In the msm_isp_util.h file, add the following define to enable logging for the ISP module: #define CONFIG_MSM_ISP_DBG

7.2 Troubleshooting

7.2.1 Verify frame type To verify the frame type, tap into an ISP output stream. Output files use the extension .yuv and consist of 10 frames from the ISP output stream.

1. Set the persist.camera.isp.dump <value> property with one of the following values:

Value Description

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

In the following example, the snapshot frames are output from the ISP stream:

adb root

adb shell setprop persist.camera.isp.dump 8 adb shell chmod 777 /data

Linux Camera Debugging Guide ISP ISPIF module


The device must be rooted and the /data folder must have full (777) access permission in order for this property to be set.

2. Move to the vendor/qcom/proprietary/mm-camera/mm-camera2/media-controller/ modules/isp folder.

3. In the isp_channel_util.c file, add the following command:

#define ISP_IMG_DUMP_ENABLE

7.2.2 Verify VFE hardware configuration To verify the VFE hardware configuration, dump the entire VFE register values to the kernel log. To do this:

1. Move to the kernel/drivers/media/platform/msm/camera_v2/isp/ folder.

2. In the msm_isp_util.h file, run the following command

#define CONFIG_MSM_ISP_DBG 1

3. 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:

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


[82.529842]msm_camera_io_dump_2: c9108000 2304 [82.534390]c9108000: 0003050a 00000000 00000000 07ffffff

[82.539779]c9108010: 03ffff77 00000002 00000001 01200025 [82.545278]c9108020: 1cffffff ffffffff 1fffffff 00000000

[82.550721]c9108030: 00000000 00000003 00000000 00000009 [82.556224]c9108040: 00000200 00000000 00000000 00000000

[82.561651]c9108050: 001b0000 00230000 000000c1 002701df [82.567183]c9108060: 00501df2 00000000 001fb000 0027b000

[82.572627]c9108070: 00c200c1 002700ef 00500ef2 00000000 [82.578058]c9108080: 00000000 00000000 018400c1 00000000

Linux Camera Debugging Guide ISP ISPIF module


7.2.3 Tap Raw Dump Interface (RDI) stream To tap into an RDI stream in the ISP module, a log statement must be added in the function below which processes ISP output frames. In case of video HDR (for sensors capable of generating HDR, such as IMX135), RDI AXI output is used with native buffers from the IFACE (ISPIF+ISP) module. These are special metadata buffers managed by session and designated as CAM_STREAM_TYPE_METADATA. If a regular RDI stream is added and designated as CAM_STREAM_TYPE_RAW, it should also be able to dump in the following function.

File location 1. Move to the vendor/qcom/proprietary/mm-camera/mm-camera2/media-controller/

modules/isp folder.

2. In the isp_channel_util.c file: static void isp_ch_util_dump_frame(int ion_fd, mct_stream_info_t *stream_info, isp_frame_buffer_t *image_buf, uint32_t frame_idx)

{ ...

int w, h; int file_fd;

w = stream_info->dim.width; h = stream_info->dim.height;

... case CAM_STREAM_TYPE_RAW:

case CAM_STREAM_TYPE_METADATA: /* You can insert debugging code in here.

In this example, we assume the above stream_info structure has correct RDI frame width and height information.

Please define them approprietary to your need. */ snprintf(buf, sizeof(buf), "/data/isp_dump_%d_rdiframe_%d_%d.raw", frame_idx, w, h); file_fd = open(buf, O_RDWR | O_CREAT, 0777); break; case CAM_STREAM_TYPE_DEFAULT:

…


8 Stats module

The Stats module interfaces with the core 3A algorithm. In addition, it also interfaces with others submodules:

Image Stabilization (IS) with gyro

AF Region of Interest (RoI)

Auto Scene Detection (ASD)

Auto Flicker Detection (AFD)

8.1 Capture logs from the Stats module The newer builds with recent chipsets, such as MSM8996, MSM8998, and MSM89x7 may have to use the new global module logging system mentioned in section 4.1 instead of the following instructions.

Old debug method: 1. Move to the vendor/qcom/proprietary/mm-camera/mm-camera2/includes/ folder.

2. In the camera_dbg.h file, set LOG_DEBUG to 1 to enable detailed logging from the Stats module.

#define LOG_DEBUG 1

8.2 Exposure Enable the following debug log to set the property using a value:

adb root

adb shell setprop persist.camera.stats.debug.mask <value>

These values are defined in the following enum:

typedef enum {

STATS_DEBUG_MASK_AEC_LOG = (1 << 0), //<value> 1 STATS_DEBUG_MASK_AWB_LOG = (1 << 1), //2

STATS_DEBUG_MASK_AF_LOG = (1 << 2), //4 STATS_DEBUG_MASK_ASD_LOG = (1 << 3), //8

STATS_DEBUG_MASK_AFD_LOG = (1 << 4), //16 } stats_debug_mask_type;

Linux Camera Debugging Guide Stats module


AEC log sample

Line 1341: 01-02 01:36:51.229 288 2972 E mm-camera-CORE: AEC stats_debug_mask 1 Line 1345: 01-02 01:36:51.229 288 2972 E mm-camera-CORE: aec_set_parameters: param=0xb8f93888 aec_obj =0xb53f3008, type =2 Line 1347: 01-02 01:36:51.229 288 2972 E mm-camera-CORE: aec_set_exposure_compensation: parmCurDen =6, parmCurNum=0,

Line 1349: 01-02 01:36:51.229 288 2972 E mm-camera-CORE: aec_set_parameters: param=0xb8f93950 aec_obj =0xb53f3008, type =35 Line 1351: 01-02 01:36:51.229 288 2972 E mm-camera-CORE: aec_set_parameters: param=0xb8f93a18 aec_obj =0xb53f3008, type =16 Line 1353: 01-02 01:36:51.229 288 2972 E mm-camera-CORE: aec_set_exposure_compensation: parmCurDen =6, parmCurNum=0,

Line 1355: 01-02 01:36:51.229 288 2972 E mm-camera-CORE: aec_set_parameters: param=0xb8f93408 aec_obj =0xb53f3008, type =20 Line 1357: 01-02 01:36:51.229 288 2972 E mm-camera-CORE: aec_set_iso_mode: iso = 0

Using the aec_set_parameter_type enum, identify which parameter the AEC algorithm is trying to set. The typedef is defined in /vendor/qcom/proprietary/mm-camera/mm-camera2/media-controller/modules/stats/q3a/aec/aec.h.

typedef enum {

AEC_SET_PARAM_INIT_CHROMATIX_SENSOR = 1,

AEC_SET_PARAM_EXP_COMPENSATION , AEC_SET_PARAM_BRIGHTNESS_LVL ,

AEC_SET_PARAM_HJR_AF , AEC_SET_PARAM_HJR ,

AEC_SET_PARAM_REDEYE_REDUCTION_MODE , AEC_SET_PARAM_METERING_MODE ,

AEC_SET_PARAM_ISO_MODE , AEC_SET_PARAM_MOTION_ISO ,

AEC_SET_PARAM_ANTIBANDING , /* 10 */ AEC_SET_PARAM_ANTIBANDING_STATUS ,

AEC_SET_PARAM_FPS_MODE , AEC_SET_PARAM_LED_RESET ,

AEC_SET_PARAM_PREPARE_FOR_SNAPSHOT , AEC_SET_PARAM_STROBE_MODE ,

AEC_SET_PARAM_FPS , AEC_SET_PARAM_ROI ,

AEC_SET_PARAM_MTR_AREA , AEC_SET_PARAM_SOF ,

AEC_SET_PARAM_BESTSHOT , /* 20 */ AEC_SET_PARAM_FD_ROI ,

AEC_SET_PARAM_STROBE_CFG_ST , AEC_SET_PARAM_EZ_DISABLE ,

AEC_SET_PARAM_EZ_LOCK_OUTPUT ,



AEC_SET_PARAM_EZ_FORCE_EXP ,

AEC_SET_PARAM_EZ_FORCE_LINECOUNT , AEC_SET_PARAM_EZ_FORCE_GAIN ,

AEC_SET_PARAM_EZ_TEST_ENABLE , AEC_SET_PARAM_EZ_TEST_ROI ,

AEC_SET_PARAM_EZ_TEST_MOTION , /* 30 */ AEC_SET_PARAM_EZ_FORCE_SNAP_EXP ,

AEC_SET_PARAM_EZ_FORCE_SNAP_LINECOUNT , AEC_SET_PARAM_EZ_FORCE_SNAP_GAIN ,

AEC_SET_PARAM_EZ_TUNE_RUNNING , AEC_SET_PARAM_LOCK ,

AEC_SET_PARAM_SENSITIVITY_RATIO , AEC_SET_PARAM_LED_EST ,

AEC_SET_PARAM_ASD_PARM , AEC_SET_PARAM_AFD_PARM ,

AEC_SET_PARAM_INIT_SENSOR_INFO , /* 40 */ AEC_SET_PARAM_ENABLE ,

AEC_SET_PARAM_AWB_PARM , AEC_SET_PARAM_GYRO_INFO ,

AEC_SET_PARAM_LED_MODE , AEC_SET_PARAM_BRACKET ,

AEC_SET_PARAM_FLASH_BRACKET , AEC_SET_PARAM_UI_FRAME_DIM ,

AEC_SET_PARAM_CROP_INFO , AEC_SET_PARAM_ZSL_OP ,

AEC_SET_PARAM_VIDEO_HDR , AEC_SET_PARAM_RESET_STREAM_INFO ,

AEC_SET_PARAM_STATS_DEBUG_MASK , /* 50 */ AEC_SET_PARAM_ON_OFF ,

AEC_SET_PARAM_CTRL_MODE , AEC_SET_PARAM_MANUAL_EXP_TIME ,

AEC_SET_PARAM_MANUAL_GAIN , AEC_SET_PACK_OUTPUT ,

AEC_SET_PARAM_SUPER_EVT , AEC_SET_PARAM_CAPTURE_MODE ,

AEC_SET_PARAM_SENSOR_ROI , /* the roi is based on sensor output coordinate */ AEC_SET_PARAM_DO_LED_EST_FOR_AF ,

AEC_SET_PARAM_PREP_FOR_SNAPSHOT_NOTIFY, /* 60 */ AEC_SET_PARAM_PREP_FOR_SNAPSHOT_LEGACY,

AEC_SET_PARAM_RESET_LED_EST, AEC_SET_PARAM_EXP_TIME ,

AEC_SET_PARAM_MAX } aec_set_parameter_type;



8.3 Flicker To obtain the logs relating to AFD, enable the log and search for AFD.

Line 669: 01-02 01:36:51.129 288 2974 E mm-camera: afd_set_parameters: param=0xb8f6c714 afd_obj =0xb8f29a10, type =3

Line 681: 01-02 01:36:51.219 288 2974 E mm-camera: afd_set_parameters: param=0xb8f6c754 afd_obj =0xb8f29a10, type =1

Line 693: 01-02 01:36:51.219 288 2974 E mm-camera: afd_set_parameters: param=0xb8f6c72c afd_obj =0xb8f29a10, type =5 Line 695: 01-02 01:36:51.219 288 2974 E mm-camera-CORE: afd_process_pack_output: afd_enable 0, monitor 0, flicker 0, freq 0, afd_state 0, afd_atb 0 Line 705: 01-02 01:36:51.219 288 2974 E mm-camera: afd_set_parameters: param=0xb8f92624 afd_obj =0xb8f29a10, type =0

Line 713: 01-02 01:36:51.219 288 2974 E mm-camera: afd_set_parameters: param=0xb8f926c4 afd_obj =0xb8f29a10, type =0 The type is defined in

typedef enum { AFD_SET_PARAM_INIT_CHROMATIX = 1,

AFD_SET_AEC_PARAM, AFD_SET_SENSOR_PARAM, //3

AFD_SET_AF_PARAM, AFD_SET_ENABLE, //5

AFD_SET_RESET, AFD_SET_STATS_DEBUG_MASK,

AFD_SET_PARAM_MAX } afd_set_parameter_type;



8.4 Processing does not initiate 1. Add custom logs in module_init and port event using the following command:

CDBG("%s:%d <desired string and corresponding format specifiers>\n", __func__, __LINE__);

For example, to debug an AEC module, add the above custom logs in the following modules:

aec_module_init aec_port_event

These modules are found in vendor/qcom/proprietary/mm-camera/mm-camera2/media-controller/modules/stats/q3a/aec folder.

2. Verify that the above custom logs in the module_init function are correctly called and the required module is initialized.

8.5 Examine events in Stats module To track the direction and type of events exchanged between Stats/3A and other upstream/downstream modules, custom logs are added in function: stats_port_event() of vendor/qcom/proprietary/mm-camera/mm-

camera2/media-controller/modules/stats/stats_port.c

Or q3a_port_event of vendor/qcom/proprietary/mm-camera/mm-camera2/media-

controller/modules/stats/q3a/q3a_port.c


9 Imaging library module

9.1 Capture logs from the Imaging Library module To debug image quality, the following information is needed:

Frame before and after the processing

Input parameters that were used by Camera module algorithms

This information is written to the log when the log level is set to 4.

1. Move to the vendor/qcom/proprietary/mm-camera/mm-camera2/media-controller/modules/ imglib/components/include folder.

2. In the img_dbg.h file, set the applicable log level:

#ifndef IDBG_LOG_LEVEL #define IDBG_LOG_LEVEL 2

#endif

In the above example, the log level has been set to 2. Supported log levels are:

Value Description

1 Displays critical error messages IDBG_ERROR 2 Shows IDBG_ERROR and IDBG_HIGH 3 Shows IDBG_ERROR, IDBG_HIGH, and IDBG_MED 4 Captures full detailed log (IDBG_ERROR, IDBG_HIGH, IDBG_MED, and

IDBG_LOW)

9.2 Capture logs related to FaceProc 1. Move to the vendor/qcom/proprietary/mm-camera/mm-camera2/media-

controller/modules/imglib/modules/common/ folder.

2. In the module_imglib_common.h file, set MODULE_FACEPROC_DEBUG to enable detailed logging.

#define MODULE_FACEPROC_DEBUG 1

Linux Camera Debugging Guide Imaging library module


9.3 Imglib module level logging Imglib module is added with support for granular logging at submodule level. This allows for enabling logs for individual modules of Imglib and thus prevent the problem of missing logs. The individual logs are enabled by setting the corresponding bit and adding the debug level in the setprop value. The 28 MSB bits are for enabling logs for individual modules and the remaining 4 bits are for the debug level.

adb shell setprop persist.camera.imglib.log <set_prop_value>

Setprop Values:

Value Description

FACEPROC = 16 + (debug_level) DENOISE = 32 + (debug_level) WNR = 64 + (debug_level) BASE = 128 + (debug_level) CAC = 256 + (debug_level) COMMON = 512 + (debug_level) AFS = 1024 + (debug_level) HDR = 2048 + (debug_level)

Add the corresponding debug_level value (1, 2, 3, 4) for:

Value Description

1 Only error logs 2 Error and high 3 Error, high, medium 4 Error, high, medium, and low

For example: adb shell setprop persist.camera.imglib.logs 20

The above command enables faceproc logs at level 4 (20 = 16 + debug_level of 4). To enable multiple logs, add the corresponding mask values and then add the debug level to it only once to get the final setprop value. For example, the setprop value to enable faceproc and HDR modules' logs is obtained by adding the mask values 16 and 2048 and then adding the debug_level (1, 2, 3, 4) just once. This gives a final setprop value of 2068 (2048 + 16 + 4) if the debug_level of choice is 4 for instance. To enable all logs at level 4: adb shell setprop persist.camera.imglib.logs 4084

The actual file that contains the relevant information is located in: vendor/qcom/proprietary/mm-camera/mm-camera2/media-

controller/modules/imglib/components/include/img_dbg.h

Linux Camera Debugging Guide Imaging library module


9.4 Troubleshooting

9.4.1 Image Quality (IQ) does not improve 1. Move to the vendor/qcom/proprietary/mm-camera/mm-camera2/media-

controller/modules/imglib/modules/common/ folder.

2. In the module_imglib_common.c file, add the following define to enable logging:

#define MOD_IMGLIB_DUMP_FRAME

3. To dump pre- and postprocessing dump frames, set the property for persist.camera.dumpmetadata. See Section 2.3.4 for information on setting this property.

When this property is set, the following files will be created in the /data/ folder: ##TIMESTAMP##_Pre_WNR.yuv

##TIMESTAMP##_Post_WNR.yuv

9.4.2 Face detection configuration For face detection, there is a configuration file that can be modified to experiment with and debug.

1. If the face detection feature is not working, move to the vendor/qcom/proprietary/ mm-camera/mm-camera2/media-controller/modules/imglib/modules/common folder.

2. In the fd_chromatix_detect_qc.h file, verify that the applicable parameter is set correctly. . . .

1, /* enable_smile_detection */

1, /* enable_blink_detection */

1, . . .


10 PProc module

The PProc module is responsible for postprocessing the frames, directly from VFE or from memory, and interacts with hardware like CPP, C2D, via its submodules. Its counterpart code hardware/qcom/camera/QCamera2/HAL/QCameraPostProc.cpp at the HAL layer also interfaces with the mm-jpeg-interface client to perform JPEG codec-related operations to the OMX layer.

10.1 Capture logs from the PProc module The following instructions show how to enable PProc logs at various levels.

File location 1. Locate qcom/proprietary/mm-camera2/media-controller/modules/pproc-new/cpp

folder.

2. In the cpp_log.h file, set the macro CPP_LOG_LEVEL with the applicable log level value.

#define CPP_LOG_SILENT 0 #define CPP_LOG_NORMAL 1

#define CPP_LOG_DEBUG 2 #define CPP_LOG_VERBOSE 3 /* full detailed log */

#define CPP_LOG_LEVEL CPP_LOG_VERBOSE

10.2 Profile hardware performance 1. Move to the qcom/proprietary/mm-camera2/media-controller/modules/pproc-

new/cpp folder.

2. In the cpp_log.h file, enable the following macro to profile PProc performance:

#define CPP_LOG_SILENT 1

Linux Camera Debugging Guide PProc module


The following performance-related log shows for how much time the CPP module holds the buffer.

01-04 01:28:42.359 E/mm-camera( 477): cpp_module_do_ack:623, in_time=264522.358970 us, out_time=264522.364071 us,

01-04 01:28:42.359 E/mm-camera( 477): cpp_module_do_ack:626, holding time = 5101 us,

10.3 Troubleshoot deadlocks with mutex track logs 1. Move to the qcom/proprietary/mm-camera2/media-controller/modules/pproc-

new/cpp folder.

2. In the cpp_log.h file, enable the following macro to examine mutex lock and deadlock: #define CPP_DEBUG_MUTEX 1

10.4 Troubleshooting

10.4.1 Buffer underrun When VFE and PProc modules are connected in a stream, VFE output buffers are diverted to PProc and ultimately to CPP hardware. In absence of enough buffers in the kernel vb2 queue for a given stream, CPP will not have new buffers to process, and get_buf will fail. Logs print the following errors, which are not fatal, and indicate the frame drop. As soon as the vb2 queue has more buffers, for example, user space queued back the buffers, these errors stop showing. Continuous errors indicate a streaming issue and that some module is not releasing the buffers back to CPP.

mm-camera cpp_hardware_process_frame:702, v4l2 ioctl() failed. rc:-1, trans_code:-11

mm-camera cpp_hardware_process_frame:704] drop this frame mm-camera cpp_thread_handle_process_buf_event:218] get buffer fail. drop frame id:142446 identity:0x10002

Such issues can be investigated by tracking buffer enqueue/dequeue from user space.

File location 1. Move to the vendor/qcom/hardware/acom/camera/QCamera2/stack/mm-camera-

interface/src folder.

2. In the mm_stream_qbuf function in mm_camera_stream.c, add extra logging to print a timestamp for a successful queue operation. This identifies the interval that a buffer is queued back to the Kernel. int32_t mm_stream_qbuf(mm_stream_t *my_obj, mm_camera_buf_def_t *buf)

{ . . .

rc = ioctl(my_obj->fd, VIDIOC_QBUF, &buffer);

Linux Camera Debugging Guide PProc module


CDBG("%s: qbuf idx:%d, rc:%d", __func__, buffer.index, rc);

3. Add timestamp logging to the mm_stream_read_msm_frame function to find out the interval that a buffer was dequeued.

int32_t mm_stream_read_msm_frame(mm_stream_t * my_obj, mm_camera_buf_info_t* buf_info,

uint8_t num_planes) {

. . . rc = ioctl(my_obj->fd, VIDIOC_DQBUF, &vb);

Placing timestamped logs based on stream ID can help confirm how long the user space holds successive buffers for a given stream that might seem stuck.


11 Imaging codec layer

The Imaging Codec Layer (ICL) stack in the Linux camera code base consists of various software modules that by working together offer handling of image codecs. One of the main use cases is JPEG handling, and ICL has software to handle encoding, decoding, and ExIF composition for it. ICL also offers OMX interface for JPEG encoding and decoding. This chapter focuses mainly on debugging the JPEG software.

11.1 Dump input buffers The YUV frame is dumped before the data is encrypted by the JPEG encoder.

1. Create the /data/jpeg directory adb root

adb shell mkdir /data/jpeg adb shell chmod 777 /data/jpeg

2. Add the following define in jpeg.c to start dumping the images to the /data/jpeg/ folder. Images have the format mm_jpeg_int****.yuv.

#define MM_JPEG_DUMP_INPUT

3. Ensure that the device is in Fastboot mode.

4. Set the applicable values for dumping the raw images:

adb shell chmod 777 /data setprop persist.camera.raw_yuv <value>

setprop persist.camera.zsl_raw <value> setprop persist.camera.dumpimg <value>

Where supported values for each property are:

Property Value

persist.camera.raw_yuv 0 – Disables raw image dump 1 – Enables raw image dump

persist.camera.zsl_raw 0 – Disables ZSL raw capture 1 – Enables ZSL raw capture

persist.camera.dumping 0 – Disables dump image 28 – Enables raw dump image

Linux Camera Debugging Guide Imaging codec layer


5. For image dumping in mm_jpeg.c, use API MM_JPEG_DUMP_INPUT.mm_jpeg.c located in the hardware/qcom/camera/QCamera2/stack/mm-jpeg-interface/src/ folder.

#ifdef MM_JPEG_DUMP_INPUT char filename[256];

snprintf(filename, 255, "/data/jpeg/mm_jpeg_int%d.yuv", p_session->ebd_count);

DUMP_TO_FILE(filename, p_session->p_in_omx_buf[p_jobparams->src_index]->pBuffer,

(int)p_session->p_in_omx_buf[p_jobparams->src_index]->nAllocLen); #endif

11.2 Enable logs for mm-jpeg-interface 1. Move to the /hardware/qcom/camera/QCamera2/stack/mm-jpeg-interface/inc/

folder.

2. In the mm_jpeg_dbg.h, define LOG_DEBUG to enable logs in the mm jpeg interface.

#define LOG_DEBUG 1

Sample log showing JPEG encoding latency Line 13259: 01-02 00:05:17.619 236 3835 D QCameraPostProc: [KPI Perf] int32_t qcamera::QCameraPostProcessor::encodeData(qcamera::qcamera_jpeg_data_t*, uint8_t&) : call jpeg create_session Line 13281: 01-02 00:05:17.629 236 3835 E mm-jpeg-intf: mm_jpeg_create_session:1768] session id 1000000 Line 13293: 01-02 00:05:17.629 236 3835 E QCameraPostProc: [KPI Perf] int32_t qcamera::QCameraPostProcessor::encodeData(qcamera::qcamera_jpeg_data_t*, uint8_t&) : PROFILE_JPEG_JOB_START >> Main image JPEG encoding started

Line 13711: 01-02 00:05:17.659 236 3834 E mm-still: OMX_ERRORTYPE OMXJpegEncoder::startThumbnailEncode():772] Started Thumbnail encoding

>> Thumbnail encoding started



Line 13713: 01-02 00:05:17.659 236 3834 E mm-jpeg-intf: mm_jpeg_session_encode:1210] X

Line 13715: 01-02 00:05:17.659 236 3834 E mm-jpeg-intf: mm_jpeg_process_encoding_job:1258] Success X Line 13721: 01-02 00:05:17.679 236 3914 E mm-still: virtual int OMXJpegEncoder::EncodeComplete(QImage*):428] Line 13723: 01-02 00:05:17.679 236 3914 E mm-still: virtual int OMXJpegEncoder::EncodeComplete(QImage*):436] Thumbnail Encoding complete.

>> Thumbnail encoding complete

Line 13725: 01-02 00:05:17.679 236 3914 E mm-still: virtual void OMXJpegEncoder::WriteComplete(QIBuffer&):584]

Line 13869: 01-02 00:05:17.769 236 3813 D QCameraPostProc: int32_t qcamera::QCameraPostProcessor::processJpegEvt(qcamera::qcamera_jpeg_evt_payload_t*): Dump jpeg_size=2392878

Line 13895: 01-02 00:05:17.789 236 3813 E QCameraPostProc: [KPI Perf] int32_t qcamera::QCameraPostProcessor::processJpegEvt(qcamera::qcamera_jpeg_evt_payload_t*): PROFILE_JPEG_CB >> Main image JPEG encoding complete

Line 13911: 01-02 00:05:17.799 236 3835 E mm-jpeg-intf: mm_jpeg_get_session:55] client_idx 0 session_idx 0 Line 13913: 01-02 00:05:17.799 236 3835 E mm-jpeg-intf: mm_jpeg_destroy_session:1836] abort todo jobs Line 13915: 01-02 00:05:17.799 236 3835 E mm-jpeg-intf: mm_jpeg_destroy_session:1844] abort ongoing jobs

11.3 Enable logs for OMX layer 1. Move to the /vendor/qcom/proprietary/mm-still/codec_v1/common folder.

2. In the QIDbg.h file, set QIDBG_LOG_LEVEL to define the log level.

/** QIDBG_LOG_LEVEL: *

* defines the loglevel * 0 - Logs are disabled

* 1 - only error logs are enabled * 2 - error logs and high priority logs are enabled

* 3 - medium, high priority and error logs are enabled * 4 - all logs are enabled

**/ #define QIDBG_LOG_LEVEL 3 //this enables medium level logs



11.4 ExIF issues ExIF entries are added from HAL or mm-jpeg-interface layers. Use this point to extract the data and debug issues related to ExIF accuracy, or to increase/decrease the number of Standard ExIF tags added in the captured JPEG image.

ExIF update at HAL File: /hardware/qcom/camera/QCamera2/HAL/QCamera2HWI.cpp

The following function shows how ExIF tags are populated. Most items populated here are provided by the application, for example, GPS info, date time, device model, and so on.

QCameraExif *QCamera2HardwareInterface::getExifData() {... ...

rc = mParameters.getExifDateTime(dateTime, count); if(rc == NO_ERROR) {

exif->addEntry(EXIFTAGID_EXIF_DATE_TIME_ORIGINAL, EXIF_ASCII,

count, (void *)dateTime);

} else { ALOGE("%s: getExifDateTime failed", __func__);

}

rat_t focalLength; rc = mParameters.getExifFocalLength(&focalLength);

if (rc == NO_ERROR) { exif->addEntry(EXIFTAGID_FOCAL_LENGTH,

EXIF_RATIONAL, 1,

(void *)&(focalLength)); } else {

ALOGE("%s: getExifFocalLength failed", __func__); }



ExIF update at mm-jpeg-interface File: hardware/qcom/camera/QCamera2/stack/mm-jpeg-interface/src/mm_jpeg_exif.c

Information passed from the mm-camera proprietary backend (via metadata stream) is populated to ExIF via the following function in the mm-jpeg-interface layer:

int process_meta_data(cam_metadata_info_t *p_meta, QOMX_EXIF_INFO *exif_info,

mm_jpeg_exif_params_t *p_cam_exif_params) {... ...

/*Exposure time*/ if (p_ae_params->exp_time == 0) {

val_rat.num = 0; val_rat.denom = 0;

} else { val_rat.num = 1;

val_rat.denom = ROUND(1.0/p_ae_params->exp_time); }

ALOGD("%s: numer %d denom %d", __func__, val_rat.num, val_rat.denom );

rc = addExifEntry(exif_info, EXIFTAGID_EXPOSURE_TIME, EXIF_RATIONAL, (sizeof(val_rat)/(8)), &val_rat);

if (rc) { ALOGE("%s:%d]: Error adding Exif Entry Exposure time",

__func__, __LINE__); }

11.5 Write new mm-jpeg-interface While creating a new mm-jpeg-interface-like layer to access OMX layer APIs, it is important to comply with the OMX standard to avoid tricky synchronization issues. Always handle output buffers in a separate callback thread to have better performance and to avoid deadlocks.

11.6 Cache invalidation In case abnormal line-noise like artifacts are observed in JPEG images, when there is no obvious hardware error reported by blocks like VFE or CPP, try invalidating the buffers to see if it helps. Refer to the function QCameraMemory::cacheOpsInternal() of hardware/qcom/camera/ QCamera2/HAL/QCameraMem.cpp for more information.


12 Encode JPEG

12.1 Dump YUV input to the JPEG encoder 1. Define MM_JPEG_DUMP_INPUT in QCamera2/stack/mm-jpeg-interface/src/mm_jpeg.c

2. From an ADB shell, issue the following command: chmod 777 /data

3. Take a picture after compilation and update the device binary.

4. Store YUV frames for full image and thumbnail at /data/jpeg.


13 Bus overflow

13.1 Identify VFE bus overflow error messages ISP (VFE) bus overflow error logs can be checked from kernel log messages. Look for a bus overflow string.

<3>[ 500.841017 / 01-01 14:31:30.619] msm_vfe32_process_error_status: image master 2 bus overflow <3>[ 501.698149 / 01-01 14:31:31.479] msm_vfe32_process_error_status: image master 2 bus overflow <3>[ 501.710956 / 01-01 14:31:31.489] msm_vfe32_process_error_status: image master 2 bus overflow <3>[ 505.045197 / 01-01 14:31:34.819] msm_vfe32_process_error_status: image master 2 bus overflow <3>[ 505.058033 / 01-01 14:31:34.839] msm_vfe32_process_error_status: image master 2 bus overflow

To interactively see the kernel message from the Windows Command Prompt (CMD) application:

adb shell cat /proc/kmsg|find "bus overflow"

From a Linux console, use the command:

adb shell cat /proc/kmsg|grep "bus overflow"

13.2 Select the right VFE clock frequency It is important to choose the right VFE clock. The VFE clock frequency should be sufficiently high enough to match the incoming data rate from sensor output, that is, sensor output frame * frame per second, otherwise it may cause an ISPIF overflow issue.

However, it should not be set to an unnecessarily high frequency. Setting the VFE clock frequency too high can cause two problems:

The chance of bus overflow is increased because it is more likely to fill the internal VFE output buffer known as Unified Buffer.

High VFE clock frequency results in increased power consumption.

Linux Camera Debugging Guide Bus overflow


13.3 Check bus clocks related to VFE bus overflow VFE bus overflow error occurs when too much VFE data traffic is generated at a rate that exceeds the available bus bandwidth. One possible way to resolve this problem is to check if the total bus bandwidth can be increased by setting a higher bus clock frequency.

In the MSM8916 chipset, for example, the VFE generates the processed output frames to the System NoC (SNoC) bus. The data stream is then forwarded to the Bus Integrated Memory Controller (BIMC) bus to be saved temporarily in the DDR memory. The data traffic stream generated by the VFE follows a path formed by these two buses. Therefore, both SNoC and BMIC buses must be checked.

ADB shell scripts dump SNoC and BIMC clock frequency in 1-sec intervals.

adb shell "while true; do cat /d/clk/snoc_clk/measure; sleep 1; done"

adb shell "while true; do cat /d/clk/bimc_clk/measure; sleep 1; done"

Alternatively, both bus clock frequency results can be combined as one chunk in 1-sec intervals.

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

If the last ADB command (SNoC and BIMC combined) is issued, the following pattern of SNoC and BIMC clock information is shown in the console:

133333687 400002014

----- 133334273

400000842 -----

133334126 400000329

----- 133332661

400000769 -----

133333614 400001940

----- 133334273

400001574 -----

133332588 399999963

-----



13.4 Set bus clock to its maximum frequency The first step for VFE bus overflow triage is to examine whether the available bus bandwidth can be increased by setting higher bus clock frequency. Increase the total bus bandwidth to check if a VFE bus overflow issue is resolved.

adb root

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"

sleep 1

The script above attempts to set all the buses in the path from the MDP (the display hardware block) to DDR memory. By requesting a huge bandwidth from the MDP display side (ID 22 means MDP), regardless of camera operation, the buses always remain at maximum clock frequencies. The reason for choosing display (MDP) over camera ISP (VFE) is that the display is always on, whereas camera voting can be overwritten by the camera driver when the camera driver is started and stopped. Furthermore, any fluctuation issues can be eliminated with this much simpler test scenario.

With the above test, check bus clock frequency again to see if the bus clock has increased its maximum frequency. With settings described above, the SNoC clock and the BIMC clock frequencies should be 266 MHz and 533 MHz respectively.

NOTE: The bus frequencies are only changed within a discrete set of values as shown in Table 13-1 and Table 13-2 for MSM8916.

Table 13-1 Bus frequencies

Performance level Frequency (MHz)

0 19.200 1 50.000 2 100.000 3 133.333 4 160.000 5 200.000 6 266.667

Table 13-2 Possible BIMC clock frequencies for MSM8916


0 9.600 1 50.000 2 100.000




3 200.000 4 400.000 5 533.000

For different MSM/APQ chipsets, the maximum bus frequency is different in general and bus architecture could be different, therefore, customers must file a case to work together with the QTI customer engineering team.

If no improvement is observed, try the following steps to run the system in CPU performance mode as well as setting the max bus clock frequency:

adb root sleep 4

adb shell stop thermal-engine adb shell stop thermald

adb shell stop mpdecision sleep 1

adb shell "echo 1 > /sys/devices/system/cpu/cpu1/online" adb shell "echo 1 > /sys/devices/system/cpu/cpu2/online"

adb shell "echo 1 > /sys/devices/system/cpu/cpu3/online" sleep 1

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

adb shell "echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor"

adb shell "echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor" 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"

sleep 1

It is important to thoroughly verify if the above tests show any improvement in terms of frequency to reproduce the issue, type of symptom seen, etc., even if the issue does not get resolved completely. Such information is often very valuable and time saving for further debugging and troubleshooting help.



13.5 Check AB/IB voting bandwidth from VFE If the preceding debugging methods do not help, submit the following information along with the bus clock frequency information via a new Salesforce case:

1. To check the total AB and IB bandwidth requested by the VFE side, ensure that the camera has been started.

2. Run the following command:

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

This command prints output similar to the following:

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

351.706326427 curr : 1

masters: 29 slaves : 512

ab : 930000000 ib : 1620000000

352.207469187

curr : 2 masters: 29

slaves : 512 ab : 930000000

ib : 1620000000

In the above example, log history shows that the VFE AB/IB request was requested twice.

The number 351.706326427 in the first line of the output represents the kernel timestamp when the request is made. The line curr can be ignored since it is not relevant in this discussion. Master(s) 29 means that the bus traffic is sourced from VFE, and Slave(s) 512 means the destination of the bus traffic is set to memory.



The final bandwidth request from VFE of AB/IB values is 930 MBps/1.62 GBps, respectively.

More information on the IDs for Master and Slave can be found in the kernel/include/linux/msm-bus-board.h file.

enum msm_bus_fabric_master_type { ... MSM_BUS_MASTER_VFE, // 29 ...

}; enum msm_bus_fabric_slave_type {

MSM_BUS_SLAVE_FIRST = SLAVE_ID_KEY, MSM_BUS_SLAVE_EBI_CH0 = SLAVE_ID_KEY, // 512 MSM_BUS_SLAVE_EBI_CH1, ...

};

13.6 Identify AXI configuration VFE bus overflow logs often start indicating the overflow in a specific write master, so it is important to have the kernel logs showing the first instance of the overflow, which helps identify the source of the overflow.

During the VFE bus overflow analysis (especially in a ZSL preview scenario), it is often required to find the mapping between a particular image write master and preview/snapshot output frame planes to determine which stream needs to be optimized. For example, after bus overflow is identified at the preview stream, only the preview stream can be focused on.

Add the following debug log message in the kernel and share the log in the Salesforce case system.

File: msm_isp_axi_util.c

Function: msm_isp_axi_stream_enable_cfg

static void msm_isp_axi_stream_enable_cfg(

struct vfe_device *vfe_dev, struct msm_vfe_axi_stream *stream_info)

{ int i;

struct msm_vfe_axi_shared_data *axi_data = &vfe_dev->axi_data; if (stream_info->state == INACTIVE)

return; for (i = 0; i < stream_info->num_planes; i++) {

if (stream_info->state == START_PENDING || stream_info->state == RESUME_PENDING) { // DO NOT FORGET ADD THIS LINE pr_err("__debug__: WM[%d] ENABLE, src = %d, max_width = %u\n",



stream_info->wm[i], stream_info->stream_src, stream_info->max_width); vfe_dev->hw_info->vfe_ops.axi_ops. enable_wm(vfe_dev, stream_info->wm[i], 1); } // DO NOT FORGET ADD THIS LINE else { pr_err("__debug__: WM[%d] DISABLE, src = %d, max_width = %u\n", stream_info->wm[i], stream_info->stream_src, stream_info->max_width); vfe_dev->hw_info->vfe_ops.axi_ops. enable_wm(vfe_dev, stream_info->wm[i], 0);

/* Issue a reg update for Raw Snapshot Case * since we dont have reg update ack

*/ if (stream_info->stream_src == CAMIF_RAW ||

stream_info->stream_src == IDEAL_RAW) { vfe_dev->hw_info->vfe_ops.core_ops.

reg_update(vfe_dev); }

} }

if (stream_info->state == START_PENDING)

axi_data->num_active_stream++; else if (stream_info->state == STOP_PENDING)

axi_data->num_active_stream--; }

With the above debug log messages in each scenario, the specific image WM number will be printed out with max_width information. This will help identify which WM is used for each stream, that is, preview or snapshot.



ZSL preview scenario // *** preview stream: Y and CbCr planes ***

<3>[ 61.159689] __debug__: WM[0] ENABLE, src = 1, max_width = 640 <3>[ 61.164401] __debug__: WM[1] ENABLE, src = 1, max_width = 640

// *** snapshot stream: Y and CbCr planes *** <3>[ 61.170261] __debug__: WM[2] ENABLE, src = 0, max_width = 4000

<3>[ 61.176017] __debug__: WM[3] ENABLE, src = 0, max_width = 4000 ...

// *** Stop ZSL preview *** ...

<3>[ 89.910656] __debug__: WM[0] DISABLE, src = 1, max_width = 640 <3>[ 89.915453] __debug__: WM[1] DISABLE, src = 1, max_width = 640

<3>[ 89.921306] __debug__: WM[2] DISABLE, src = 0, max_width = 4000 <3>[ 89.927173] __debug__: WM[3] DISABLE, src = 0, max_width = 4000

Video record preview scenario <3>[ 99.047257] __debug__: WM[2] ENABLE, src = 0, max_width = 352

<3>[ 99.051992] __debug__: WM[3] ENABLE, src = 0, max_width = 352 ...

*** Stop recording *** ... <3>[ 105.951042] __debug__: WM[2] DISABLE, src = 0, max_width = 352

<3>[ 105.955881] __debug__: WM[3] DISABLE, src = 0, max_width = 352

13.7 Increase AB/IB If increasing the overall bus clock frequency was effective by the methods described in Section 13.4, the solution can be incorporated into the camera driver. This increases the bus clock frequency only during camera operation.

1. Move to the kernel/drivers/media/platform/msm/camera_v2/isp folder.

2. In the msm_isp_util.c file, increase the minimum AB and IB values: #define MSM_ISP_MIN_AB 450000000 // INCREASE THIS NUMBER #define MSM_ISP_MIN_IB 900000000 // INCREASE THIS NUMBER

3. Gradually increase or multiply the original number by 2, or gradually reduce to find out the optimum number.



13.8 VFE burst length change Although there is no clear answer to the optimum VFE burst length, sometimes changing VFE burst length can help in reducing a VFE bus overflow issue.

1. Move to the kernel/drivers/media/platform/msm/camera_v2/isp folder.

2. In the msm_isp40.c file, set the length of the burst using the applicable value. #define VFE40_BURST_LEN 1 // CHANGE IT TO 0, 1, 2 or 3 #define VFE40_STATS_BURST_LEN 1 // CHANGE IT TO 0, 1, 2 or 3 ...

Value Description

0 Burst length 2 1 Burst length 4 2 Burst length 8 3 Burst length 16

This global constant takes effect when the function msm_vfe40_axi_cfg_wm_reg for image, STATS for msm_vfe40_stats_cfg_ub, is executed.

13.9 Dump SurfaceFlinger information Often a VFE bus overflow issue may be due to a high bus traffic generated by the camera VFE side alone, but it may also be caused by other multimedia subsystem components, such as display or graphics. It may be necessary to examine the Surface type and dimension information.

Run the following command for SurfaceFlinger information.

adb shell dumpsys SurfaceFlinger > sf_out.txt

It is important to issue this command while the camera application is running in the same exact scenario that the VFE bus overflow issue is observed.



Sample log ...

h/w composer state:

h/w composer present and enabled Hardware Composer state (version 1020000):

mDebugForceFakeVSync=0 Display[0] : 720x1280, xdpi=309.966003, ydpi=312.614990, refresh=16666667

numHwLayers=3, flags=00000000 type | handle | hints | flags | tr | blend | format | source crop | frame name

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

HWC | b8ae7c38 | 00000002 | 00000000 | 00 | 00100 | 00000002 | [ 0, 0, 720, 1280] | [ 0, 0, 720, 1280] SurfaceView HWC | b8ae63e0 | 00000002 | 00000000 | 00 | 00105 | 00000001 | [ 0, 0, 720, 1280] | [ 0, 0, 720, 1280] com.google.android.gallery3d/com.android.camera.CameraLauncher FB TARGET | b8aee5d0 | 00000000 | 00000000 | 00 | 00105 | 00000001 | [ 0, 0, 720, 1280] | [ 0, 0, 720, 1280] HWC_FRAMEBUFFER_TARGET

...

Overlay State

Ctrl id=8 z=1 fg=0 alpha=255 mask=-1 flags=0x60000 H.Deci=0,V.Deci=0

src w=736 h=1280 format=13 MDP_RGBA_8888 src_rect x=0 y=0 w=720 h=1280

dst_rect x=0 y=0 w=720 h=1280 Data id=8

data offset=0 memid=32 id=0 flags=0x0 priv=0 Display=0

Ctrl id=64 z=0 fg=0 alpha=255 mask=-1 flags=0x44000 H.Deci=0,V.Deci=0

src w=736 h=1280 format=15 MDP_RGBX_8888 src_rect x=0 y=0 w=720 h=1280

dst_rect x=0 y=0 w=720 h=1280 Data id=64

data offset=0 memid=80 id=0 flags=0x0 priv=0 Display=0

Pipes=2



13.10 Reduce CPU/memory-intensive operations A bus overflow can be caused by heavy CPU and memory IO operations, or it could be due to an enhanced camera application UI that requires much more graphics or composition layers.

1. To troubleshoot, use the default QTI Android camera application to verify if it has the same bus overflow issue.

2. If a bus overflow is still observed, turn off some postprocessing modules, such as Face Detection, to reduce the bandwidth.

3. Note if there has been any improvement.

13.11 Guideline for bus profiling preparation (only if it is needed)

If you are requested to provide a bus profiling process:

1. See Enabling Bus Profiling on Customer Devices Using Android (80-NJ799-1) to enable bus profiling.

2. Ensure that msm-buspm-dev.ko is generated on a customer’s build.

NOTE: Customers are expected to share two or three devices with JTAG connector port for bus profiling purposes. This helps avoid any last-minute surprises in case one of the devices does not work or show the issue as expected, or is somehow damaged.


14 Stability debugging

This chapter describes the basic process for stability debugging for camera. The same process can be applied to any subsystem. The following use cases are described:

Stack without the symbol

Stack with symbol in the crash stack

The stack traces or tombstone traces should be provided to QTI via a Salesforce case.

14.1 User space stability debug without symbols in stack This section describes the stability debug mechanism for the crash stack without symbols in the logs. In this example, the stack information of xyz_library.so is decoded. This is a typical example of user space stack after a crash.

logcat.log:11-25 23:28:20.339 I/DEBUG ( 439): ........ ........

logcat.log:11-25 23:28:20.339 I/DEBUG ( 439): #01 45332ad8 40911ba0

logcat.log:11-25 23:28:20.339 I/DEBUG ( 439): 45332adc 44b252ac

logcat.log:11-25 23:28:20.339 I/DEBUG ( 439): 45332ae0 00000000

logcat.log:11-25 23:28:20.339 I/DEBUG ( 439): 45332ae4 44b25710

logcat.log:11-25 23:28:20.339 I/DEBUG ( 439): 45332ae8 fffdc2a4

logcat.log:11-25 23:28:20.339 I/DEBUG ( 439): 45332aec 40071084 /system/lib/libc.so (__aeabi_ldiv0+12)

logcat.log:11-25 23:28:20.339 I/DEBUG ( 439): 45332af0 00000000


logcat.log:11-25 23:28:20.339 I/DEBUG ( 439): 45332af4 4014abbb xyz_library.so


logcat.log:11-25 23:28:20.339 I/DEBUG ( 439): 45332afc 00000000

logcat.log:11-25 23:28:20.339 I/DEBUG ( 439): 45332b00 00000000



logcat.log:11-25 23:28:20.339 I/DEBUG ( 439): 45332b0c 00000000



Linux Camera Debugging Guide Stability debugging


To debug without symbols 1. Get the PID of the suspected daemon.

PID=$(adb shell ps | grep <suspected ldaemon> | awk '{print $2}')

2. Get the maps of the daemon. adb pull /proc/$PID/maps .

3. In the maps file, look for the base address of the xyz_library.so (the library information is in the stack trace).

4532a000-453a8000 r-xp 00000000 b3:11 4525 xyz_library.so

4. Compute the address offset.

Base of the xyz_library.so library is 4532a000

Error is at address 45332af4

Delta is 8af4

5. Use the addr2line tool to decode the address from the symbol.

arm-eabi-addr2line -f -e xyz_library.so 8af4

The output is:

/path/to/file/error_file.c:2956

6. Start debug in error_file.c at line number 2956.

14.2 User space stability debug with stack symbols In this example, the stack information of xyz_library.so is decoded. It is relatively easier to debug a stack with symbols in the crash stack.

This is a sample crash stack, where the library information is present. In this case, a generic library called xyz_library.so is used.

main2:5307:01-24 14:04:05.422 386 386 I DEBUG : #04 pc 00004c9d xyz_library.so (<symbol_name> +<offset>)

Linux Camera Debugging Guide Stability debugging


To debug with symbols 1. Find the base address of the symbol (<symbol_name>).

readelf -Ws xyz_library.so | grep <symbol_name> )

Sample Output of above command: <base_address>> --- <<symbol_name>

2. Calculate the address of the crash.

Base address – base_address

Add the offset – <offset>

Add base + offset = <base_address> + <offset>

3. Decode the address with the addr2line tool. arm-eabi-addr2line -f -e xyz_library.so 2f49

The output is:

/path/to/file/error_file.c: 689

4. Start debug in error_file.c at line number 689.


15 Common Android specification violations

This chapter describes common Android specification violations that OEMs and third-party application developers may perform while writing camera applications using Camera APIs.

See http://developer.android.com/reference/android/hardware/Camera.html for more details on Camera APIs.

15.1 Invalid camera ID in camera open On a device that supports multiple cameras, the camera application should not assume that the back camera is Camera Id =0 and front camera is Camera Id =1. The camera application must request the getCameraInfo() API to obtain information for a specific camera. The following command returns information about a particular camera:

public static void getCameraInfo (int cameraId, Camera.CameraInfo cameraInfo)

If getNumberOfCameras() returns N, the valid ID is 0 to N-1

Camera.CameraInfo class has a member called facing that provides information about the position of a specific camera. Based on this information, camera applications use the appropriate Camera ID when opening a specific camera.

See http://developer.android.com/reference/android/hardware/Camera.CameraInfo.html for more information.

public int facing specifies the direction that the camera faces.

This should return CAMERA_FACING_BACK or CAMERA_FACING_FRONT.

Camera.CameraInfo facing information can be one of the following:

public static final int CAMERA_FACING_BACK

The camera is facing the opposite the screen.

– Constant value − 0 (0x00000000)

public static final int CAMERA_FACING_FRONT

The camera is facing the same direction as the screen.

– Constant value − 1 (0x00000001)

Failure to comply with this Android specification may cause the wrong camera to open in a given use case, for example, open back camera for a front camera use case.

http://developer.android.com/reference/android/hardware/Camera.html

http://developer.android.com/reference/android/hardware/Camera.CameraInfo.html

Linux Camera Debugging Guide Common Android specification violations


15.2 Access same camera hardware from multiple camera clients Trying to access the same camera hardware from different applications at the same time violates Android camera specifications.

When simultaneous camera clients attempt to access the same camera hardware, the following code in Camera Services throws an error:

File: frameworks/av/services/camera/libcameraservice/CameraService.cpp bool CameraService::canConnectUnsafe(int cameraId,

const String16& clientPackageName,

const sp<IBinder>& remoteCallback,

sp<BasicClient> &client) {

...

/*

mBusy is set to false as the last step of the Client destructor,

after which it is guaranteed that the Client destructor has finished (

including any inherited destructors)

We only need this for a Client subclasses since we do not allow

multiple Clients to be opened concurrently, but multiple BasicClient

would be fine

*/

if (mBusy[cameraId]) {

ALOGW("CameraService::connect X (pid %d, \"%s\") rejected"

" (camera %d is still busy).", callingPid,

clientName8.string(), cameraId);

return false;

}

return true;

}


16 Customer configurable parameters

NOTE: This chapter was added to this document revision.

The following table lists the parameters customers can configure, based on their requirements.

NOTE: The syntax of the following setprops is adb shell setprop <setprop name> <value>.

Setprop Description

persist.camera.eztune.enable Use to perform live tuning using the Chromatix 6 tool in debug variant builds. Set the property to: 1 to enable 0 to disable

persist.camera.eztune.sticky Use to retain tuning between camera launches and device reboots. Set the property to: 1 to enable 0 to disable

persist.camera.imglib.bsgc Use to enable blink, smile, and gaze (BSG), which is a subset of the Face Detection (FD) feature. FD configuration is used from the appropriate fd*chromatix_bsgc.h file. Set the property to: 1 to enable 0 to disable Note: Enabling this feature uses up more power.

Linux Camera Debugging Guide Customer configurable parameters


Setprop Description persist.camera.stats.debugexif persist.camera.mobicat persist.camera.stats.debug.mask

Use to enable stats respective to specific submodule debug data. For MSM8952/MSM8976/MSM8953/MSM8937/ MSM8996/MSM8998 and later chipsets, 3A ExIF debug data can be enabled for each component using persist.camera.stats.debugexif. To enable 3A ExIF debug data, type the following commands: adb root adb remount adb shell setprop persist.camera.mobicat 2 adb shell setprop persist.camera.stats.debugexif <3A ExIF debug mask>

The following list details 3A ExIF debug data components and the corresponding masks: AEC – 0x10000 (65536 in decimal) AWB – 0x10000 << 1 (131072 in decimal) AF – 0x10000 << 2 (262144 in decimal) ASD – 0x10000 << 3 (524288 in decimal) AFD – 0x10000 << 4 (1048576 in decimal) Stats – 0x10000 << 5 (2097152 in decimal) BHist – 0x10000 << 6 (4194304 in decimal) BE Stats – 0x10000 << 7 (8388608 in decimal) AEC|AWB|AF|Stats – 0x270000 (2555904 in decimal) BE Stats|BG Stats – 0xA00000 (10485760 in decimal) All of the above – 0xFF0000 (16711680 in decimal) For MSM8909/MSM8939 and earlier chipsets, 3A ExIF debug data can be enabled for each component using persist.camera.stats.debug.mask. To enable 3A ExIF debug data, type the following commands: adb root adb remount adb shell setprop persist.camera.mobicat 2 adb shell setprop persist.camera.stats.debug.mask <3A ExIF debug mask> The following list details 3A ExIF debug data components and the corresponding masks: AEC – 0x10000 (65536 in decimal) AWB – 0x10000 << 1 (131072 in decimal) AF – 0x10000 << 2 (262144 in decimal) ASD – 0x10000 << 3 (524288 in decimal) AFD – 0x10000 << 4 (1048576 in decimal) Stats – 0x10000 << 5 (2097152 in decimal) AEC|AWB|AF|Stats – 0x270000 (2555904 in decimal) All of the above – 0x2F0000 (3080192 in decimal)

Linux Camera Debugging Guide Customer configurable parameters


Setprop Description persist.camera.batchcount <value>

Use to enable HFR batch mode. This is available for MSM8952 and later chipsets. Set the value to specify the number of frames that must be sent in one batch. Set the property to: 1 to enable 0 to disable

camera.lowpower.record.enable Use to enable low-power recording mode. By enabling this, live snapshot is limited to video size. Set the property to: 1 to enable 0 to disable

persist.camera.isp.dump Use to enable frame dumps in ISP. To enable dumps: Preview – adb shell setprop persist.camera.isp.dump 2

Snapshot – adb shell setprop persist.camera.isp.dump 8

Video – adb shell setprop persist.camera.isp.dump 16

persist.camera.isp.dump_cnt <value>

Use to specify the number of frames to be dumped using persist.camera.isp.dump for a given stream.

persist.debug.set.fixedfps <value>

Use to set fixed fps mode. A fixed fps value that is supported by the sensor can be set using this parameter.

persist.camera.raw_yuv persist.camera.zsl_raw persist.camera.zsl_yuv persist.camera.dumpimg <value>

Use to enable RAW capture in ZSL mode. adb shell setprop persist.camera.raw_yuv –

Use to add the RAW channel to ZSL or Capture channel. Set a value of 1 to enable.

adb shell setprop persist.camera.zsl_raw – Use to dump the RAW frame in ZSL channel CB. Set a value of 1 to enable.

adb shell setprop persist.camera.zsl_yuv – Use to dump ZSL YUV before reprocessing. Set a value of 1 to enable.

adb shell setprop persist.camera.dumpimg – Use to dump QCAMERA_DUMP_FRM_RAW. Value should be set to the enum value of QCAMERA_DUMP_FRM_RAW, which is 16.

persist.capture.burst.exposures <values>

Use to enable burst exposure levels. Frames are captured with the exposure levels mentioned in the setprop. Note: Each exposure level value should be separated by a comma, for example, “12, 0, 6”.


A References

A.1 Related documents

Title Number

Qualcomm Technologies, Inc.

MSM8974/APQ8074/MSM8x26/APQ8084 Linux Camera Overview 80-NA157-22 MSM8974/APQ8074/MSM8x26/APQ8084 Linux Camera Overview VD80-NA157-22 ISP/ISPIF Code Walk-Through for Linux Camera Software 80-NF499-11 ISP/ISPIF Code Walk-Through for MSM8974/APQ8074/MSM8x26 Linux Camera Software

VD80-NF499-11

JPEG Code Walkthrough for MSM8994/MSM8084/MSM8974/APQ8074/MSM8x26 Linux Camera Software

80-NF499-10

JPEG Code Walkthrough for MSM8974/APQ8074/MSM8x26 Linux Camera Software

VD80-NF499-10

Pproc Module Code Walkthrough for MSM8994/MSM8084/MSM8974/APQ8074/MSM8x26 Linux Camera Software

80-NF499-9

Pproc Module Code Walkthrough for MSM8974/APQ8074/MSM8x26 Linux Camera Software

VD80-NF499-9

Imaging Library Module Code Walkthrough for Linux Camera Software 80-NF499-8 Imaging Library Module Code Walkthrough for MSM8974/APQ8074/MSM8x26 Linux Camera Software

VD80-NF499-8

Stats Module Code Walkthrough for Linux Camera Software 80-NF499-7 Stats Module Code Walkthrough for MSM8974/APQ8074/MSM8x26 Linux Camera Software

VD80-NF499-7

Enabling Bus Profiling on Customer Devices Using Android 80-NJ799-1 Camera Front End Code Walkthrough for Linux Camera Software 80-NF499-2 Camera Front End Code Walkthrough for MSM8974/APQ8074/MSM8x26 Linux Camera Software

VD80-NF499-2

Kernel Code Walkthrough for Linux Camera Software 80-NF499-3 Kernel Code Walkthrough for MSM8974/APQ8074/MSM8x26 Linux Camera Software

VD80-NF499-3

Camera Server and MCTL Code Walkthrough for MSM8974/APQ8074/MSM8x26 Linux Camera Software

80-NF499-4

Camera Server and MCTL Code Walkthrough for MSM8974/APQ8074/MSM8x26 Linux Camera Software

VD80-NF499-4

Sensor Module Code Walkthrough for MSM8994/MSM8974/APQ8074/MSM8x26 Linux Camera Software

80-NF499-5

Sensor Module Code Walkthrough for MSM8974/APQ8074/MSM8x26 Linux Camera Software

VD80-NF499-5

Linux Camera Debugging Guide References


Title Number

Chromatix 6 Camera Tuning for MSM8994/MSM8992/APQ8084 80-NK872-4

Resources

http://developer.android.com/reference/android/hardware/Camera.html Camera http://developer.android.com/reference/android/hardware/Camera.CameraInfo.html

Camera.CameraInfo

A.2 Acronyms and terms

Acronym or term Definition

AFD Auto Flicker Detection ASD Auto Scene Detection BIMC Bus Integrated Memory Controller CCI Camera Control Interface ICL Imaging Codec Layer IQ Image Quality IS Image Stabilization RDI Raw Dump Interface RoI AF Region of Interest SNoC System NoC

http://developer.android.com/reference/android/hardware/Camera.html



Documents

Linux Camera Debugging Guide...Added storing 3A metadata in JPEG, actuator debugging, Android specs reference, Section 2.3.6, Section 5.3.6, and Chapter 13 . D : March 2015 . Edited