- 博客(6)
- 收藏
- 关注
RSS订阅原创 isphidl basic flow
处理平台的MFNR算法（主要由MF@CapPipe这个线程来做），以及经过MDPNode去做裁剪、旋转等操作（主要由MDP@CapPipe这个线程来做），属于camera delay。流程图中的虚线以上所包含的stage与app的处理强相关，可认为是app delay，这些阶段的耗时异常需要客户app进行分析。app收到单张yuv buffer后，可以再过三方算法，完成后继续下发isp request给hal层做jpeg encode。主要由CAM@Jpeg这个线程来做，属于camera delay。
2024-08-22 10:08:01
1402
原创 MTK 死机问题快速分析/Phone hang analysis
大概的讲，可以分成空间数据和时间数据。空间数据，即当时现场环境，如有哪些process 在运行，CPU 的执行情况，memory 的利用情况，以及具体的process 的memory 数据等。需要注意的是, 通常情况下抓取core dump会导致现场破坏, 需要明确确认问题是由这个进程引发的, 以免造成现场破坏后无法再分析. 另外因为core dump 是我们手工抓取的, 直接的crash 分析是没有必要的, 这个时候更多的是结合coredump 来分析进程的上下文, 观察各个线程以及变量的状态.
2024-08-21 17:02:22
1888
原创 mfnr shot2jpeg ISP7
在ISP7以后的平台，MFNR capture request大致可以分为11个stage，相较于ISP6S少了一个MDPNode处理的stage，此外，callback部分的核心模块也由AppStreamMgr改为CallbackCore（这体现在callback stream buffer阶段trace中打印出的线程名是由有差异的，具体请看Break down Instroduction小节），用户点击拍照键到app下发request到hal层的耗时，属于app delay，需要app端分析耗时差异。
2024-08-21 09:28:29
796
原创 mfnr shot2jpeg ISP6S
在ISP6S平台，MFNR capture request大致可以分为12个stage，其中S0与S11分别涉及到request的下发和callback，需要app端更多去分析耗时异常的原因。Stage9: P2:DispatchFrame结束点 --> onProcessRequest结束点。Stage4: onDispatchFrame结束点 --> P2_Capture:enque结束点。Stage8: mf:process结束点 --> P2:DispatchFrame结束点。
2024-08-20 16:03:07
1725
原创 MTK Camera Launch and Switch Flow
本篇主要解释相机启动及切换的流程拆解。其中，App Delay部分耗时需要从Camera APP角度分析，Camera Delay部分耗时需要CameraHal平台部分分析。
2024-08-20 08:54:02
457
原创 Mtk 自带充电IC CHG_ILIM限制的是VBUS还是VBAT的电流呢？
MT6360的CHG_ILIM需要选择合适的下拉电阻比如698欧(限制到508ma)MT6375则只需要把CHG_ILIM接地即可(限制到500ma)是限制VBUS的电流。
2024-08-19 09:24:36
176
UMS9620射频方框图
2024-08-21
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人