Qualcomm Platform Camera porting

Reprinted from Http://www.cnblogs.com/thjfk/p/4086001.html

Camera Basic code Architecture

Camera principle: After the external light through the lens, after the color filter filtered to the sensor surface, sensor will be uploaded from the lens to come from the light converted into electrical signals, and then through the internal ad conversion to digital signal, if sensor does not have integrated DSP, It is transferred to baseband via DVP, where the data format is raw. Must be handled through the platform's ISP. If the DSP is integrated, this raw data is output in YUV or RGB format after Awb,color matrix,lens shading,gamma,sharpness,ae and de-noise processing. Finally, the CPU is sent to the framebuffer for display.

1, first control the schematic diagram, check the camera module PIN PIN connection is correct.

2, with the scope of the camera MCLK pin, see if it is correct, if mclk normal, usually pclk should also have waveforms;

(1) The MCLK provides the camera with a clock that is used for the PLL inside the module. The Qualcomm platform is 24MHZ. The Broadcom platform is 26MHZ.

3, using a multimeter to measure the camera's power pin, to see if the camera power supply is normal;

(2) AVDD Analog circuit power supply 2.8V, under normal circumstances, AVDD need separate power supply, power ripple <=30mv.

Iovdd/dovdd/vif:power support for IO circuits 1.8V

DVDD Digital Circuit power supply 1.2V, if IOVDD is 1.8V, it is recommended to use sensor internal DVDD. Don't do external DVDD on hardware, or it will cause vertical stripe problems.

If the IOVDD is using 2.8V, the power-up sequence will change with the external DVDD.

3, check the camera's spec document, check PWDN and reset pin trigger is normal, check the code in the camera power up timing is consistent with datasheet.

(3) RESET/XSHUTDOWN/XCLR: Used to reset Sensor;reset is generally low-effective when the pulse is low, reset sensor, while normal operation, should be high. Note the time required for reset

(4) Pwdn/standby:power down pin to cut off power. When the Powerdown is active, the camera is in a non-working mode. PWDN is generally high effective, when the pulse is high, into the power-saving mode, while normal operation is low. , Powe rdown effective polarity. PWDN High effective means that the PWDN is high when entering power down mode, so when entering the preview interface, the PWDN will be lowered. So the camera can get into normal working condition.

(5) XCLR is reset input signal and power OFF of the internal core, camera become standby situation. (Low Active)

Xclr= "H": usually situation xclr= "L": Reset situation

(6) Xshutdown:reset and power down (active low with internal pulling down resistor) hardware reset

(7) Sony sensor has the "build in power" on reset function. It automatically initializes the internal circuit by itself when XCLR pin was open and the power supplies are brought up.i n addition,if xclr pin is set to low and the power supplies be bring up. The sensor would skip executing the power on reset function.

4, in the datasheet of the camera to find the I²c address of the device, check that the i²c configuration is correct; usually the I²c ID number on the spec of the camera sensor contains the last read-write direction bit. And this one in the definition of the I²c bus, strictly speaking, is not part of the ID, so the Linux I²c driver API in the call parameters of the ID number, usually do not consider this bit, read and write direction bit in the specific read and write operation, in the register set.

5, check if the communication is normal, whether it can read and write normally, with the oscilloscope to measure the SCL and SDA waveform is normal, not communication is high level, the communication SCL is the I²C clock signal, SDA is an i²c data path signal;

6, let the sensor FAE check the camera register list is configured correctly.

The Qualcomm platform for the camera's code organization, generally follow the Android framework: the upper application and the HAL layer interaction, Qualcomm platform in the HAL layer to implement their own set of management strategy, in the kernel to implement the sensor's underlying driver. The underlying settings for the most core sensor end, the ISP effect-related code are separately extracted and placed in a daemon process for management.

For example, the camera in the kernel layer of the main file is MSM.C, responsible for the specific registration of equipment and related methods of filling; In the msm_sensor.c file, the main maintenance of Qualcomm own a sensor-related structural body-msm_sensor_ctrl_t, At the same time, the configuration information in the DTS file is read out, the kernel layer for the different sensor corresponding to a driver file-xxsensor.c, mainly to the power setting settings to fill the msm_sensor_ctrl_t.

In the vendor directory, Qualcomm places the actual code of each sensor into this. Part of the code is the framework code for communication between the daemon process and the kernel layer and the HAL layer, and the other is the Chromatix effect code associated with the sensor and the sensor Lib section code (init setting, lens info, Output info).

For example, the Qualcomm platform manages sensor-related components through a function pointer array sub_module_init, of which the Sensor_sub_module_init and Chromatix_sub_module_init modules are important, The sensor module needs to correspond to the interface under the filler sensor_lib_t, and for the Chromatix module is generated by the high-pass Chromatix tool.

From a higher level, the sensor part of the code is only part of the camera subsystem. Open Qualcomm Vendor The following about the camera source code can also be seen,/mm-camera2/media-controller/modules directory below, sensors is just modules file one of the sub-directories below.

2 main transplant steps 2.1 Kernel layer code porting

1. New camera node in./kernel/arch/arm/boot/dts/msm8226-camera-sensor-qrd.dtsi, focusing on the IIC address in the node, SENSRO ID information, voltage setting information:

Qcom,[email protected] {//21 is the i²c slave Id of the imx214

 compatible = "qcom,imx214"; Same as the sensor name used in the project

Reg = <0x21>;
Qcom,slave-id = <0x20 0x0016 0x0214>; Sensor ID
Qcom,csiphy-sd-index = <0>;
Qcom,csid-sd-index = <0>;
QCOM,ACTUATOR-SRC = <&actuator1>;
QCOM,LED-FLASH-SRC = <&led_flash0>;
QCOM,EEPROM-SRC = <&eeprom4>;
Qcom,mount-angle = <90>; Rear camera and front camera
Qcom,sensor-name = "imx214";// unique sensor name to differentiate from the other sensor

cam_vdig-supply = <&pm8226_l5>;//defined in./kernel/arch/arm/boot/dts/msm8226-regulator.dtsi
Cam_vana-supply = <&pm8226_l15>;
Cam_vio-supply = <&pm8226_lvs1>;
Cam_vaf-supply = <&pm8226_l18>;
Qcom,cam-vreg-name = "Cam_vdig", "Cam_vio", "Cam_vana", "CAM_VAF";
Qcom,cam-vreg-type = <0 1 0 0>; 0 for LDOs and 1 for LVS
Qcom,cam-vreg-min-voltage = <1100000 1800000 2800000 2950000>;
Qcom,cam-vreg-max-voltage = <1100000 1800000 2800000 2950000>;
Qcom,cam-vreg-op-mode = <120000 0 200000 600000>;
Qcom,gpio-no-mux = <0>;
Gpios = <&msmgpio-0>
<&msmgpio Notoginseng 0>
<&msmgpio-0>
<&msmgpio 0>;
Qcom,gpio-reset = <1>;
Qcom,gpio-standby = <2>;
QCOM,GPIO-AF-PWDM = <3>;
Qcom,gpio-req-tbl-num = <0 1 2 3>;
Qcom,gpio-req-tbl-flags = <1 0 0 0>;
Qcom,gpio-req-tbl-label = "CAMIF_MCLK",
"Cam_reset1",
"Cam_standby",
"CAM_AF_PWDM";
Qcom,csi-lane-assign = <0x4320>;
Qcom,csi-lane-mask = <0x1f>;
Qcom,sensor-position = <0>; 0 for rear Camea and 1 for front camera
Qcom,sensor-mode = <0>; 0 for Bayer format and 1 for YUV format
Qcom,cci-master = <0>;
Status = "OK";
};

Please refer to the./kernel/documentation/devicetree/bindings/media/video/directory for detailed documentation.

2. Add the following files./kernel/drivers/media/platform/msm/camera_v2/sensor/imx214.c

+static struct msm_sensor_power_setting imx214_power_setting[] = {
+{
+.seq_type = Sensor_vreg,
+.seq_val = Cam_vio,
+.config_val = 0,
+.delay = 1,
+},
+{
+.seq_type = Sensor_vreg,
+.seq_val = Cam_vana,
+.config_val = 0,
+.delay = 1,
+},
+{
+.seq_type = Sensor_vreg,
+.seq_val = Cam_vdig,
+.config_val = 0,
+.delay = 1,
+},
+{
+.seq_type = Sensor_vreg,
+.seq_val = CAM_VAF,
+.config_val = 0,
+.delay = 5,
+},
+{
+.seq_type = Sensor_gpio,
+.seq_val = Sensor_gpio_standby,
+.config_val = Gpio_out_low,
+.delay = 1,
+},
+{
+.seq_type = Sensor_gpio,
+.seq_val = Sensor_gpio_reset,
+.config_val = Gpio_out_low,
+.delay = 5,
+},
+{
+.seq_type = Sensor_gpio,
+.seq_val = SENSOR_GPIO_AF_PWDM,
+.config_val = Gpio_out_low,
+.delay = 5,
+},
+{
+.seq_type = Sensor_gpio,
+.seq_val = Sensor_gpio_standby,
+.config_val = Gpio_out_high,
+.delay = 5,
+},
+{
+.seq_type = Sensor_gpio,
+.seq_val = Sensor_gpio_reset,
+.config_val = Gpio_out_high,
+.delay = 10,
+},
+{
+.seq_type = Sensor_gpio,
+.seq_val = SENSOR_GPIO_AF_PWDM,
+.config_val = Gpio_out_high,
+.delay = 5,
+},
+{
+.seq_type = SENSOR_CLK,
+.seq_val = SENSOR_CAM_MCLK,
+.config_val = 24000000,
+.delay = 10,
+},
+{
+.seq_type = Sensor_i2c_mux,
+.seq_val = 0,
+.config_val = 0,
+.delay = 0,
+},
+};

3. Add support for imx214 in the following file

./kernel/arch/arm/configs/msm8226_defconfig

+config_imx214=y

4./kernel/drivers/media/platform/msm/camera_v2/kconfig

+config IMX214
+bool "Sensor IMX214 (BAYER 13M)"
+depends on Msmb_camera
+---help---
+sony MP Bayer Sensor with auto Focus, uses
+4 MIPI lanes, preview config = 2104 x 1560 at + fps,
+snapshot config = 4208 x 3120 at + fps,
+video HDR Support.

5,./kernel/drivers/media/platform/msm/camera_v2/sensor/makefile

+obj-$ (config_imx214) + = IMX214.O

6, register the clock./kernel/arch/arm/mach-msm/clock-8226.c

@@ -3421,6 +3421,11 @@ -3421,6 struct clk_lookup msm_clocks_8226[] = {
Clk_lookup ("Cam_clk", Camss_mclk0_clk.c, "0.qcom,camera"),
Clk_lookup ("Cam_clk", Camss_mclk0_clk.c, "1.qcom,camera"),

+clk_lookup ("Cam_clk", Camss_mclk0_clk.c, "21.qcom,camera"),
+clk_lookup ("Cam_src_clk", MCLK0_CLK_SRC.C, "21.qcom,camera"),

2.2 Vendor Code porting

Vendor The following code is mainly two parts, one is the sensor specific settings in the Sensor_libs directory, the configuration file, and the other is Chromatix the following ISP effect file. The specific:

1../vendor/qcom/proprietary/mm-camera/mm-camera2/media-controller/modules/sensors/sensor_libs/imx214/imx214_ Lib.c

+/*===========================================================================
+ * Function-imx214_open_lib-
+ *
+ * DESCRIPTION:
+ *==========================================================================*/
+void *imx214_open_lib (void)
+{
+ Return &sensor_lib_ptr;
+}

This lib would be loaded if camera deamon process is started, kernel'll find the handle based on the sensor name in DTB (Device tree binary file), so you sure the file name and function name follow the request for your sensor.

<your_sensor_name>/<your_sensor_name>_lib.c
void *<your_sensor_name>_open_lib (void)

Sensor output Settings

static struct sensor_lib_out_info_t sensor_out_info[] = {
{
/* VT_PIXEL_CLK =. line_length_pclk* frame_length_lines*frame Rate */
/* OP_PIXEL_CLK = VFE working CLK */

....

}

2. The relevant files in the Chromatix directory, the corresponding sensor directory contains 4 directories and an Android file, a total of 13 files, these files will be generated by the Chromatix debugging tool.

3. Vendor also has the EEPROM file, the module comes with the EEPROM data processing related; AF related files, the Debug tool generates an effect file on AF, and a configuration file that fills in the configuration file with the module that needs to be compiled.

Acuator porting

./kernel/drivers/media/video/msm/actuators/actuator.c

msm_actuator_ctrl_t contains all the information about the actuator setting related to sensors like
I²c addr, Set_info, focal length, etc. All the info are loaded from the Chromatix file for the sensor.

in AF header file, the driver engineer should take care of the structure of actuator_params_t, which contains the AF drive IC address, Register Patten, etc. It is important for AF working.

3 Debugging FAQs 3.1 kernel and vendor naming matches

In the process of referencing other code porting to debug a new sensor, note that in the process of configuring node information for sensor in the corresponding DTS file, the "Qcom,sensor-name" field is configured with "Xxx_" in the sensor Lib code below vendor. Open_lib "function name and corresponding android.mk in the" Local_module "name match, otherwise the corresponding sensor vendor the library file can not be called, then open camera will appear a flash phenomenon. Refer to the Sensor_load_library () function in platform code SENSOR.C.

sensor_lib_out_info_t padding in 3.2 sensor lib

In general, each sensor can be configured to output images of different sizes. At this point, in addition to the corresponding sensor setting to change the sensor's own output and related configuration, but also the relevant output size, frame rate and other information to inform the platform end, that is, fill the struct sensor_lib_out_info_t structure.

The members of this sensor_lib_out_info_t, which are populated, will eventually be captured by the HAL layer as part of the sensor's basic information, a simple block diagram for obtaining sensor information for the Qualcomm platform.

During debugging, it is important to note that the member of this struct max_fps needs to fill at least 30 or greater, otherwise it will not be able to enter the preview because it cannot get a valid previewsize, video size when acquiring capability. Refer to the Mct_pipeline_populate_query_cap_buffer () function in platform code MCT_PIPELINE.C.

3.3 Sensorlib in Exposure_table_size fill in

For the sensor terminal output raw data, the platform side of the ISP processing, the sensor side in addition to the basic init configuration, the other is based on the platform-side AEC data to adjust the exposure of sensor. Connecting the AEC on the platform side to the specific sensor exposure settings on the Qualcomm platform is a exposure corresponding interface in a exposure table and sensor lib file in the Chromatix file.

The exposure_table_size corresponds to the number of sensor registers written by the Sensor_fill_exposure_array () interface in the sensor lib, which is required in the platform code according to this Exposure_table_ Size to dynamically allocate memory sizes. If this value is filled in the same size as the actual value written in Sensor_fill_exposure_array (), it will cause memory crash. Refer to the Sensor_apply_exposure () function in platform code SENSOR.C.

3.4 Kernel layer non-conventional settings

For some sensor, it may be necessary to modify the relevant default settings on the platform when there are unconventional requirements for voltage setting or MCLK setting.

For the sensor's several operating voltages (AVDD, DVDD, IOVDD), the platform is generally through the corresponding regulator of the pmic power supply, and the hardware regulator output capacity is generally limited, the code will also be reflected. If you have a sensor that requires more voltage than the corresponding regulator on the code, you can view the instructions on the pmic and modify the platform code to resolve if the limit value on the code is not the true limit of the hardware.

For the MCLK setting, the Qualcomm platform has some general value settings. If the sensor has a special requirement and the MCLK cannot be identified by the platform, it can be used in the clock-related code of the platform by configuring the platform's PLL parameters to generate a specific MCLK clock for the sensor.

Qualcomm Platform Camera porting