isphidl basic flow

1. Overview

如图为mfnr算法在isp hidl框架下处理流程，大致分为13个stage，在图中用红色字体标明每个stage所处位置。

流程图中的虚线以上所包含的stage与app的处理强相关，可认为是app delay，这些阶段的耗时异常需要客户app进行分析。

虚线以下部分的stage与camerahal层的处理强相关，可认为是camera delay。

一般的isp hidl mfnr flow由三个大部分组成，分别是 1.收多张raw图； 2.raw2yuv & mfnr算法； 3.encode yuv to jpeg

每个stage的拆分细节在Break down Instroduction部分介绍，更多关于isp hidl框架的细节介绍，请参考QS：QSS06252

2.Break down Instroduction

Stage0: touch up to submitrequest

这部分delay属于app delay需要客户分析为何点击拍照(tag: AppLaunch_dispatchPtr:Up)到下发request间隔异常

Stage1: ZSL processing

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

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

Stage2: P2ANode processing

收raw图阶段如有过某些P2 tuning模块的需求，则也会经过P2C来处理，但是不会进行RAW2YUV的操作。

属于camera delay。

Stage3: pack tuningdata to app

打包tuningdata给app，属于camera delay。

Stage4: callback meta buffer to app

打包metadata给app，属于camera delay。

Stage5: app receive raw buffer & do 3rd raw algorithm

此阶段由客户自行实现。

Stage6: send isp request for raw2yuv

app下发回灌isp request给hal层，会对tuningdata进行解析：unpackIspTuningDataFromHeap，再做raw2yuv以及MFNR算法的处理。

属于app delay，需要app分析为何收到raw后长时间没有下发回灌request？是否raw域三方算法处理过久？

Stage7: P2ANode do raw2yuv

P2ANode做raw2yuv处理 (P2A@CapPipe这个线程来做)，属于camera delay。

Stage8: MFNR & MDPNode processing

处理平台的MFNR算法（主要由MF@CapPipe这个线程来做），以及经过MDPNode去做裁剪、旋转等操作（主要由MDP@CapPipe这个线程来做），属于camera delay。

Stage9: callback yuv & tuningdata

packIspTuningDataToHeap关键词确认tuningdata的callback时间点

ISP6S可以搜索handleCallbacktoHidl关键词确认yuv callback时间点。

ISP7之后可以搜索onFrameUpdated来确认yuv callback时间点，也在packIspTuningDataToHeap 的附近位置。

属于camera delay。

Stage10: recive yuv buffer & process 3rd yuv algorithm &  send isp request for yuv2jpeg

app收到单张yuv buffer后，可以再过三方算法，完成后继续下发isp request给hal层做jpeg encode。

属于app delay，需要app分析为何收到yuv后长时间没有下发回灌request？是否yuv域三方算法处理过久？

Stage11: jpeg encode

主要由CAM@Jpeg这个线程来做，属于camera delay。

Stage12: callback jpeg to app 

调用isp hidl的接口将jpeg buffercallback给app，属于camera delay。

这里仅仅表明hal层已经将jpeg buffer callback给app，但是app真正收到jpeg的拆解，需要客户端完善。