AuvKaixin的博客

印象中是因为和屏幕共电了，导致闪屏，所以不下电需要查询下邮件K7T的做法和M7的做法M7在安卓S上的做法当时采用regular的做法（wl2866d）K7T是另一种还有就是gpio26 开机gpio26-bp-control<1/1>https://gerrit.odm.mioffice.cn/c/vendor/qcom/non-hlos-mid-2020-spf20/+/256331/2/zprojects/HMI_M7_COMMON/BOOT.XF.4.1/boot_ima

persist 写属性占用资源多 改成vendor因为persist.xxx类型的属性是可持久化的属性，这些属性被初始化之后，会被写入到文件进行持久化存储存储在： /data/property/persistent_properties。

根因分析：此时因为手电筒开关是开着的，不会再去调用init，直接下发CSLPacketOpcodesFlashSetNonRealTime;然后手动将sys/class/leds/torch中的节点flash_thermal_protect置0，模拟手机温度降低，关闭温控保护。手动将sys/class/leds/torch中的节点flash_thermal_protect置1，模拟手机温度过高，触发温控保护。这个时候手电筒是不亮的，同时保持状态栏torch enable的状态，可以回到桌面。

在实际应用中，马达的震动频率可能会受到多种因素的影响，包括马达的驱动方式、控制算法、以及马达与摄像头模块的集成方式等。一阶震动频率通常是指马达在正常工作时可能产生的基本振动频率，而二阶震动频率则可能是一阶频率的倍频或者是由于马达内部结构的复杂性而产生的其他振动频率。当手机马达的震动频率和摄像头AF马达的一二阶震动频率处于共振频段的时候，手机马达震动时候有很大概率会干扰到后置摄像头的对焦马达正常工作，可能出现的影响有出现滋滋杂音，相机预览画面水波纹或抖动导致的成像质量问题。

FAQ34432]

相机启动时间（camera lunch time）一般使用高速相机来测量。起点：用户点击相机图标后，手指离开的时刻终点：看到相机预览画面出来的时刻注意：不同的客户对相机预览画面有不同的要求 1 .有些是看到预览画面就可以 2 .有些需要等到AF/AE 稳定下来的画面。

LQ-JEYAN00-M:/sys/devices/platform/camera_af_hw_node # lsdriver_override modalias of_node power subsystem ueventLQ-JEYAN00-M:/sys/devices/platform/camera_af_hw_node #

sensor及平台特性导致，亮度越大 linecount调节一个单位的亮度变化越明显导致平台来回调整亮度出现闪烁问题。

2M OV02A10/OVO2B sensor规格书中要求为VDDI(1V8)->VDDA(2V8)->VDDD(1V8),因为VDDI和VDDD我们采用同一路供电，同厂家确认，可以按照先VDDI/VDDD ->VDDA顺序，与上述归一化设置保持一致。2、再开机识别16M过程中，不同厂家Cam识别前后，AVDD出现半高电平，AVDD的半高电平导致和16M共用AVDD的2M器件Sensor内部出现异常，Sensor拉死IIC总线，由于2M景深和16M器件共用一路IIC,导致16M器件不识别。

在感光芯片中，crosstalk（串扰）现象是指相邻像素之间的信号互相影响导致的一种干扰。当一个像素受到光照并转换成电信号时，其附近的像素可能会因为光电效应或其他物理机制而感应到部分光强，这不属于它们自身的光学响应，而是由于彼此之间产生的非线性相互作用。这种串扰可能导致图像质量下降，尤其是在高密度像素阵列如CMOS传感器中更为明显，因为它增加了错误信息的传播机会。为了减少crosstalk，设计者通常会采用各种技术，比如优化像素布局、增加隔离层等措施。解决办法：crosstalk（串扰）校准。

正确的分配完内存，可顺利打开相机拍照。FlashRegisterRead申请的内存池组的flag，有概率被异步的TFE修改会导致分配内存失败。可以通过添加标志位bNeedDedicatedBuffers=TRUE,来设置专属内存组。

通过hal3接口set_torch_mode()接口，调用，先进行初始化，然后再进行操作。下拉菜单手电筒是systemUi下面的一个功能，调用的是camera接口。初始化完毕，然后就是torch on。

flush会在所有的buffer都得以释放，所有request都成功返回后才真正返回，该方法需要在100ms内返回，最长不能超过1000ms。并未开始进行流转的request会直接返回，并携带错误信息。任何无法进行打断的硬件操作会在当前状态下进行休眠。所有的还在流转的request会尽可能快的返回。任何可以打断的硬件操作会立即被停止。关闭相机的时候，也会调用这个方法。

增加CAM_REQ_MGR_EVENT_MAX值，本例是60 修改为 120。相机老化出现20/7万比例的老化异常重启，具体报错log入下。

测试项目GC50EOV50CHs-trail时间73 ns80.66 nsHs-prepare时间86.9 ns66.36 nsHs-zero时间137 ns132 ns由上，发现出现预览黑屏的GC50E的Hs-prepare时间明显比 OV50C长很多。于是FAE调整寄存器0X01A9 从0x0d改小为0x0a，就可以点亮了。

FPS = vt_pix_clk/framelength/linelengthoutputpixelclock = mipi_output_speed*lanecounts/bits-per-pixel其中settleTimeNs，这个值在高通文档80-P9301-97中的解释如下：Specifies the settle time in nanoseconds. The value is configured,based on the output characteristics of the se

CAMX sc202cs 景深老化

IN-flight机制：相机app中的IN-flight机制是指在相机操作过程中，已经发出但尚未完成的请求（request）所携带的缓冲区（buffer）的管理方式。在Android Camera2 API和HAL3架构中，当应用程序发出拍照或录像的请求时，这些请求会进入一个队列，称为IN-flight队列。每个请求都会关联一个或多个缓冲区，用于存储图像数据。这些机制对于相机app来说至关重要，因为它们确保了相机操作的流畅性和效率，特别是在高负载或需要连续拍照的场景下。

我们只需要保证最后传入的参数min_uV 和 max_uV是需要的就可以。这就需要在上电前的准备工作：解析并填充电源启动设置中的电压调节器参数（Parse and fill vreg params for powerup settings）最后的设置电压的函数static int jlq_wl2866d_regulator_set_voltage(）是对linux的regulator的ops接口中set_voltage方法的实现。本文以regulator供电方式来说明如何配置。我们只需要修改如下两处即可。

25.chxadvancedcamerausecase.cpp: 主要做如下两件事\n1.ConfigureStream(pCameraInfo, pStreamConfig);//chxusecaseutils.cpp :1.enum class UsecaseId{\nNoMatch= 0,\nDefault= 1,\nPreview= 2,\n…//chxusecaseutils.cpp : 获取usecaseId, 返回selectedUsecaseId。