mfnr shot2jpeg ISP7

Title:MFNR shot2jpeg ISP7

Platform: ISP7/ISP7S/ISP7SP

Key words: MFNR、shot2jpeg

1. Overview

在ISP7以后的平台，MFNR capture request大致可以分为11个stage，相较于ISP6S少了一个MDPNode处理的stage，此外，callback部分的核心模块也由AppStreamMgr改为CallbackCore（这体现在callback stream buffer阶段trace中打印出的线程名是由有差异的，具体请看Break down Instroduction小节），其他步骤基本类似。

其中S0与S10分别涉及到request的下发和callback，需要app端更多去分析耗时异常的原因。其他的9个stage可以看作是camera delay，可以咨询MTK共同分析。

下图将11个stage在capture flow中大致所处的位置用红色字体标出，并在本文后续的Break down Instroduction小节中详细进行拆解分析。

更多关于MFNR的信息，可以参考QS: QSS06250。

2.Break down Instroduction

S0: Touch Up起始点 --> submitRequestList结束点

用户点击拍照键到app下发request到hal层的耗时，属于app delay，需要app端分析耗时差异。

1. 1. Please find the "P2_Capture:enque()".
   2. Pleas find "Touch Up" which is closest to "P2_Capture:enque()".

S1: submitRequestList结束点 --> zsl process起始点

hal层接收到request到准备开始zsl选帧操作的时间，会有featuresetting相关的处理。

S2: zsl process起始点 --> zsl process结束点

此阶段camerahal在进行zsl选帧，属于camera delay，起点和终点tag可以搜索submitZslRequest 和 queue；

此部分耗时异常可以通过抓取log进一步分析zsl选帧pending的原因，可以参考如下QS：QSS06246, QSS06404

目录

1. Overview

2.Break down Instroduction

3.Debug sop

---

 

S3: zsl process结束点 --> onDispatchFrame结束点

一般MFNR capture都是走zsl flow，P1并没有实际收图的行为，此阶段是将pipeline frame dispatch到P2；

 

S4: onDispatchFrame结束点 --> P2_Capture:enque结束点

因为是多帧request，此阶段搜索关键词P2_Capture:enque会出现多个，结束点位置应该选择最后一帧的末端；

 

S5: P2_Capture:enque结束点 --> doBss结束点

RootNode做BSS算法，挑选基准帧，并reorder；

 

S6: p2a:process起始点 -->p2a:finish结束点

P2ANode主要作用是raw2yuv，并过一些P2 ISP tuning模块；

 

S7: mf:process起始点 --> mf:finish结束点

MFNR挂在MultiframeNode中，耗时长短主要受帧数的影响；

 

S8: onProcessRequest起始点 --> onProcessRequest结束点

JpegNode处理encode process；

 

S9: onProcessRequest结束点-->performCallback结束点

stream buffer通过CallbackCore callback给app，通过convertToHidlStreamBuffer:convertImage关键字，可以找到对应mfnr request callback的节点；

此处处理线程的名称与ISP6S (AppMgr-ResCBH)有区别：ACbdp-ResCB;

 

S10: performCallback结束点->APP Receive Jpeg

途径fwk，app最终获得jpeg buffer的阶段，耗时异常需要客户做分析；

3.Debug sop

step1：选取合适对比机，一些准则可以参考DCC文档012_相机性能优化.docx中的Comparing CPU Loading章节；

step2：确保测试机对比机 capture size相近，MFNR帧数保持一致；

step3：参考break down introduction，对测试机对比机进行拆解，输出类似如下格式的表格；

step4：对表格测试机耗时超出预期范围的stage做进一步分析，如为app delay，请客户自行处理，如为camera delay则继续分析；

	S0	S1	S2	S3	S4	S5	S6	S7	total
	app delay	camera delay	camera delay	camera delay	app delay	camera delay	app delay	camera delay	----------
测试机
对比机
diff

step5：对camera delay，客户可以寻求MTK协助，step5作为进阶分析，不做强制要求，只作为分析手法的参考；

             若可以定位到某个函数/阶段耗时过久，进一步拆解是running、runnable、sleeping还是usleep存在差异

• running 差异需对比测试机与对比机cpu频率，是否有压频等，参考QS：QSS06151
• runnable，需分析cpu loading，参考QS：QSS06151
• sleeping，需要分析流程上是否有异常。
• usleep则需要抓出args部分

常见args：

1.memory相关：

{kernel callsite when blocked:: "vm_mmap_pgoff+0xa4/0xf0"},

{kernel callsite when blocked:: "ion_client_create+0x128/0x340"},

{kernel callsite when blocked:: "wait_on_page_bit_killable+0xd4/0xf8"}

{kernel callsite when blocked:: "filemap_fault+0x36c/0x778"}: file map fault是mmap系统调用的缺页异常处理接口，是memory相关模块。

{kernel callsite when blocked:: "generic_file_read_iter+0x1c8/0x7dc"}：跟memory和io相关。 

2.sensor drv相关:

{kernel callsite when blocked:: "__mt_i2c_transfer.llvm.14780016619013500509+0x16ec/0x2e94"}

{kernel callsite when blocked:: "msleep+0x34/0x44"}