Camera driver Huaping, split screen, stuck screen, black screen problem analysis

1. Preview blurry screen, split screen, and stuck screen

1. Phenomena

Split Screen

Huaping

Open the smart object recognition app, the bottom sensor output defaults to 1632×1224 (200w) sensor output, which will cause problems such as blurred screen and split screen.
But when choosing full-size 3264×2448 (800w) output, there will be no such problem.
After measuring the DVDD voltage, it was found that the small size 1632×1224 (200w) was abnormal.

DVDD

It can be seen that when using a small size 1632×1224 (200w) output, DVDD directly jumps continuously from 1.2V to 1.4V, resulting in unstable power supply voltage.
But when using a small size full size 3264×2448 (800w) output, this power supply can be fixed to 1.4V, very stable, so there will be no problem with the full size!

Hardware Schematic

So here comes the question?
Why is the full-size 3264×2448 (800w) output, this power supply can be fixed to 1.4V, when using the small-size 1632×1224 (200w) output, DVDD jumps directly from 1.2V to 1.4V.

Reason: This circuit itself supplies power to the system, and we do not control the voltage of pm89l6_S3 on the software.
pm89l6_S3 will dynamically change the voltage according to the system load,
When using full-scale output, the system load is large, so it can be stabilized to 1.4V,
When using 200w size output, the system load is small, and S3 itself will jump to 1.2V.

2. Solution:

  • 1. In terms of hardware, this power supply is switched to a stable power supply voltage!

  • 2. On the software:
    Modify cam_vdig-supply = < & amp;pm8916_s3> voltage, fixed to 1.4V power supply.
    kernel/arch/arm/boot/dts/qcom/msm8909-pm8916-camera-sensor-i18.dtsi

qcom,camera@0 {
···
        cam_vdig-supply = < & pm8916_s3>;
        cam_vio-supply = < &pm8916_l10>;
        cam_vaf-supply = < & pm8916_l11>;
        qcom,cam-vreg-name = "cam_vdig","cam_vio", "cam_vaf";
        qcom,cam-vreg-type = <0 0 0>;
        qcom,cam-vreg-min-voltage = <1400000 1800000 2800000>;
        qcom,cam-vreg-max-voltage = <1400000 1800000 2800000>;
···
}
 

//Modify the maximum value of pm8916_s3 to 1.4V
kernel/arch/arm/boot/dts/qcom/msm8916-regulator.dtsi

 rpm-regulator-smpa3 {
        status = "okay";
        pm8916_s3: regulator-s3 {
            regulator-min-microvolt = <1200000>;
            //Modify the maximum value to 1.4V
            regulator-max-microvolt = <1400000>;
            qcom,init-voltage = <1200000>;
            status = "okay";
        };
    };
 

2. Probabilistic red screen when opening the camera

1. Phenomena

red screen

From the log, the sensor has data output, and it can also be taken by clicking on the photo.
It’s just that the picture taken is the same as the preview picture, all red.

2. Reason

As can be seen from the figure below, AVDD is powered on faster than IO, and if it does not meet the requirements of the power-on sequence, it may cause many inexplicable bugs.

image

image

Sensors from different manufacturers have different requirements on timing. For example, OV5675 has no strict requirements on the timing of three-way power-on, and gc8034 is relatively strict.

also:
ov5675, only XSHUDTN,

gc8034 has PWDN and Reset feet.

XSHUDTN equivalent to ov5675 completes all functions of gc8034 with PWDN and Reset pin.

But when our gc8034 hardware is connected, only PWDN is used,
If the chip is not very good, it may also bring inexplicable bugs, abnormal images, black screen, etc., there are such hidden dangers.

If there is no RST, the timing must be satisfied: GC8034 has power on reset, that is, when AVDD is detected to have a low-level to high-level action, the sensor will reset internally; but it needs to require AVDD to be valid only after DVDD is powered on.

3. Probabilistic black screen when the camera is turned on

1. Phenomena

preview black screen

Analysis from the log:

04-01 17:26:17.536 424 4171 E mm-camera: mct_bus_sof_thread_run: SOF freeze; Sending error message
04-01 17:26:17.539 403 4148 E mm-camera-intf: mm_camera_event_notify: Camera Event DAEMON DIED received
04-01 17:26:17.541 3838 3838 E Camera FW: wzm Error callback 100
 

This is SOF freeze: If the ISP does not receive the SOF IRQ from the kernel, the CSID/CSIPHY/CAMIF must be checked, which means that the ISP does not receive the frame transmitted by the sensor
Generally speaking, troubleshooting this problem is more complicated.

2. Reason

We investigate the problem based on the following three aspects:

  • 1. Timming (power-on sequence)

  • 2.sensor setting (confirm with vendor’s fae)

  • 3. Adjust settle_cnt to see if there is optimization

st**atic struct msm_camera_csi2_params gc8034_csi_params = {
  .csid_params = {
    .lane_cnt = 4,
 
    .lut_params = {
      .num_cid = ARRAY_SIZE(gc8034_cid_cfg),
      .vc_cfg = {
          &gc8034_cid_cfg[0],
          & gc8034_cid_cfg[1],
      },
    },
  },
  .csiphy_params = {
    .lane_cnt = 4,
    .settle_cnt = 0x10, //0x14//120ns
  },
};
 

However, for the problem of sof, the most important thing is that the previous power-on sequence must be consistent, and the reset pin must be connected
We changed the sensor of Samsung s5k4h7, there is no requirement for the power-on sequence, and it has reset function, so it is very stable, and there is no problem of sof freeze.

———————
Author: Study & Notes
Source: CSDN
Original: https://blog.csdn.net/weixin_49303682/article/details/126167934
Copyright statement: This article is the author’s original article, please attach the blog post link for reprinting!
Content analysis By: CSDN, CNBLOG blog post one-click reprint plug-in