跳转至

MI RGN DEBUG SOP

REVISION HISTORY

Revision No.
Description
 Date
1.00
  • Initial release
    		•  12/08/2023
    1.01
  • 补充因RGN导致被贴模块超时问题的分析
    		•  08/29/2024

    1. 名词解释

    • MI_RGN proc信息

      MI_RGN获取设备信息的方式，命令：cat /proc/mi_modules/mi_rgn/mi_rgn0，proc信息各字段的意义请参考MI_RGN API doc----"5. PROCFS介绍"。

    • MI_RGN echo命令

      MI_RGN用于Debug的命令，可以修改设备状态(例如关闭某个HwGwin的显示)或者获取设备中的非文本信息(例如存储OSD画布数据到指定文件中)。具体命令用法请参考MI_RGN API doc----"5. PROCFS介绍"。

    • GOP

      实现OSD功能的硬件名。

    • HwGwin

      显示OSD图像的硬件单位，一个GOP硬件中有至少一个HwGwin，GOP中的HwGwin数量代表GOP最多可以直接显示OSD数量，当一个通道上OSD的数量超过这个通道的GOP硬件拥有的HwGwin数量时，被显示的OSD需要先经过OSD拼图后才能正常显示。

    • front buffer

      仅OSD，HwGwin显示的buffer，数量不超过HwGwin的数量。front buffer的来源可以是front buffer或者拼图后的buffer。

    • back buffer

      仅OSD，用户通过API更新的OSD画布即back buffer，back buffer有1张或多张(最大张数不超过用户创建OSD handle时指定的最大画布数量)，如果OSD不参与拼图，那么它最近更新的back buffer同时也是front buffer给HwGwin显示。

    • OSD拼图

      仅OSD，通过OSD拼图算法把需要拼接的OSD内容通过BDMA搬到额外申请的front buffer上，HwGwin显示拼图后的front buffer，间接显示参与拼图的所有OSD。BDMA搬运需要时间，所以参与拼图的OSD更新默认会有延迟。如果用户希望OSD的显示没有延迟，即用户调用API结束后可以马上更新到被贴的数据流上，请使用"realtimeflip" echo命令打开MI_RGN的实时更新功能。在需要拼图的通道，MI_RGN只会允许一个OSD获取画布，只有在上一个OSD更新画布之后，下一个OSD才能成功获取到。

    2. RGN常见问题

    2.1. OSD常见问题

    2.1.1. OSD画面花

    2.1.1.1. Buffer内容有误

    • 确认问题步骤：

      EXP: Mod2 dev0 chn0 outport0这个通道attach了2个OSD，其中OSD起始位置在[0, 0]上的OSD的画面是花的。VENC输出画面如下图:

      1. 首先确认出问题的通道状态，执行指令获取MI_RGN proc信息(cat /proc/mi_modules/mi_rgn/mi_rgn0)，在该问题中我们只需要关注proc信息中的"region attr"和"chnport info"，以下是MI_RGN返回的proc信息:

        能够获知的信息：

        1. Mod 2 device 0 Channel 0 outport 0 info的"region Info"列表中只有handle为0的OSD的"PosX"和"PosY"属性都为0，可以确认出问题的OSD的handle ID是0；

        2. Mod 2 device 0 Channel 0 outport 0 info的"frontbuff Info"列表中所有front buffer的"OsdCnt"都不大于1，代表没有OSD拼图；

        3. Mod 2 device 0 Channel 0 outport 0 info的"frontbuff Info"列表中只有2个front buffer有信息，可以确认该通道占用了2个HwGwin。

      2. 使用"echo"命令保存MI_RGN buffer。

        因为出问题的OSD没有参与拼图，那么back buffer会作为front buffer直接给HwGwin显示。那么这个例子中保存back buffer或front buffer都可以确认OSD的内容。如果出问题的OSD参与了拼图，那么back buffer和front buffer都需要保存，并且要分别确认两种buffer的内容。

        保存back buffer cmd：echo dumpRgnBuf [Handle] [Path] > /proc/mi_modules/mi_rgn/mi_rgn0

        保存front buffer cmd：echo dumpFrontBuf [ModId] [DevId] [ChnID] [PortID] [bInputPort] [Path] > /proc/mi_modules/mi_rgn/mi_rgn0

        推荐使用软件7yuv 查看保存的文件。确认画面是否如预期，如果back buffer与front buffer画面一样都是花的且和被贴模块输出图像中花的现象一致，那么就可以确认问题是OSD花是back buffer内容有问题导致；如果只有front buffer是花的那么说明是OSD拼图的问题；否则不是buffer内容问题导致。

    • back buffer内容有问题的原因

      1. 用户画错

        可以在调用MI_RGN_UpdateCanvas之前保存画布的虚拟地址到文件中来检查用户画的OSD内容是否正确。

      2. 没有flush cache

        OSD更新画布，驱动会先映射画布获取虚拟地址，然后会在用户更新画布时解映射，如果映射之后和解映射之前没有对刷新缓存，HwGwin显示时用户写到缓存中的数据还没有写回到内存中，现象就是OSD花掉了(只有使用API MI_RGN_GetCanvasInfo+MI_RGN_UpdateCanvas的方式更新OSD时才使用了缓存，也只有该情况才会有该错误)。用户可以在app调用MI_RGN_GetCanvasInfo之后和MI_RGN_UpdateCanvas之前都对画布的虚拟地址做一次刷新缓存的动作。如果是缓存的原因，问题应该被修复。如果确认是该问题，请联系MI_RGN RD或者FAE确认驱动中刷新缓存的操作为何没有生效。

        刷新缓存使用MI_SYS的API MI_SYS_FlushInvCache(void *pVirtualAddress, MI_U32 u32Length)，其中u32Length等于OSD画布的"u32Stride"和高相乘。

      3. back buffer内存被踩

        可以在用户最后一次调用MI_RGN_UpdateCanvas或者MI_RGN_SetBitMap之前保存用户更新的buffer，把它和MI_RGN保存的back buffer做对比。如果不一样则说明可能存在该现象，可以使用"MIU protect"工具对RGN back buffer所在的地址范围监控。为了避免误报，请联系MI_RGN RD或者FAE确认白名单。

    • OSD拼图有问题的原因

      1. front buffer内存被踩

        可以使用"MIU protect"工具对RGN front buffer所在的地址范围监控。

        RGN front buffer正常会被BDMA和GOP_R client访问，需要把这两个client添加进白名单。如果不确定可以联系RGN RD或者FAE确认。

      2. 上一个申请front buffer所在地址的task释放buffer时没有处理好cache问题(该情况表现为CPU写踩内存)

        可以尝试在MI_RGN申请front buffer和BDMA操作front buffer之间加上"Vmap" -> "Flush cache" -> "UnVmap"的操作。确认修改后是否不存在画图的情况。

    2.1.1.2. BW问题

    • 确认问题步骤

      1. dump全局BW占用情况，发给MIU SW owner分析，BW是否超过负载。多发生在贴到realtime mode绑定通道或者DISP模块上。

      2. 降低分辨率，或者阉割场景然后确认OSD画面，如果不再花了，说明可能是场景BW紧张。

      3. 如果问题是概率出现，手动拉高BW看看是否能提高复现概率或者出问题区域是否会扩大，请联系RGN RD或者FAE提供命令。

    • 出现问题的原因

      1. 当前BW占用过高。这种情况，分析场景是否超规格。

      2. 其它IP抢占带宽太狠，具体场景需要具体分析。

      3. GOP内部BW设置的问题(这些如果怀疑这些设置请联系RGN RD或者FAE提供命令)

        burst length：设定GOP向MIU连续读取数据的长度。设定过高过低都有可能出现异常；

        dma FIFO threshold：GOP RDMA的fifo阈值，表示积累制定条request后才开始发送。

        MCM：功能有缺陷时，可能导致花图。

    2.1.1.3. 其它

    • 确认问题步骤

      1. 获取RGN proc信息(cat /proc/mi_modules/mi_rgn/mi_rgn0)

      2. dump 相关硬件的寄存器(/customer/riu_r [bank]);

        DISP: bank 0x1281,0x1282

        VENC: bank 0x1683,0x1684

        JPEG: bank 0x1235,0x1236

      3. 排查前面几个方向中获取的信息(RGN back buffer、front buffer等)一起打包发送给RGN RD或者FAE分析。

    • 出现问题的原因

      1. different format：scl/disp gop都不支持同时使用不同format的gwin。如果使用了，OSD显示会花掉。

    2.1.2 OSD不显示或者不刷新

    2.1.2.1. OSD画面未正常更新

    • 确认问题步骤：

      exp: Mod2 dev0 chn0 outport0这个通道attach了2个OSD，其中OSD起始位置在[0, 0]上的OSD的画面不显示或者不刷新。

      1. cat rgn proc信息(cat /proc/mi_modules/mi_rgn/mi_rgn0)，关注出问题的通道的"chn port info"。

        重点注意：

        确认"ChnPort Info"中"ScreenWidth"和"ScreenHeight"的值是否和对应通道的分辨率能够对应上。可能是*贴错通道了？*

        确认"region Info"和"frontbuff Info"中的"bShow"参数，如果为0，现象上来看就是该OSD不显示。

        确认"region Info"和"frontbuff Info"中的"AlphaMode"：

        如果alpha mode为"Constant alpha"且"AlphaVal"为0，现象为OSD不显示；

        如果alpha mode为"Pixel alpha"，则需要dump rgn的front buffer结合确认：

        "ARGB"的格式需要确认pixel中的alpha分量的值，如果为0，现象就是OSD不显示，其中ARGB1555格式需要结合"FgAlpha"和"BgAlpha"，如果"FgAlpha"参数为0，那么alpha分量为1的像素的真实透明度就会是0，从现象上来看就是不显示，"BgAlpha"同理；

        如果OSD格式为I2/I4/I8，像素值是索引值，实际显示时会显示调色板中对应的alpha和颜色，需要确认RGN的front buffer中的像素对应调色板的alpha分量的值。如果为0，那么现象就是OSD不显示。

      2. 关注其中的"Operate count info"。它保存了用户对每个handle的API调用次数。

        多次cat proc信息，确认API MI_RGN_SetBitMap、MI_RGN_GetCanvasInfo和MI_RGN_UpdateCanvas的次数是否有增加，如果没有增加，现象就是OSD不刷新。

        MI_RGN_GetCanvasInfo和MI_RGN_UpdateCanvas调用次数是否成对，在有OSD拼图的通道，如果某个OSD持续获取画布，那么其它OSD调用MI_RGN_GetCanvasInfo都会退出并在串口打印错误和警告。可以确认串口日志进一步确认(DualOS 需要使用指令cat /proc/dualos/log获取RTOS端的log)。现象就是OSD不刷新

      3. 确认用户传递给MI_RGN的画面，保存rgn的back buffer确认是否如预期。cmd: echo dumpRgnBuf [handle] [path] > /proc/mi_modules/mi_rgn/mi_rgn0。如果多次保存的buffer内容都和被贴模块输出图像一致，那么说明是用户更新的画面是有问题的。从现象可能是OSD不显示或者不刷新，取决于内容。

        出现问题的原因:

        用户buffer生成逻辑存在问题。

        用户没有按照正常的时序调用API。

        用户没有把正确的图像传递给MI_RGN。

    2.1.2.2. API调用的速度异常(只有OSD有拼图的情况会遇到)

    • 确认问题的步骤：

      1. 如果出现问题的通道有OSD拼图的情况，确认 MI_RGN_GetCanvasInfo和MI_RGN_UpdateCanvas的调用速度。OSD有拼图的通道，参与拼图的OSD在通道上有OSD画布被获取期间显示都不会刷新，如果上一次MI_RGN_UpdateCanvas和下一次MI_RGN_UpdateCanvas之间的时间过短，驱动不能及时下设定给硬件。现象是OSD不更新。

      2. 确认MI_RGN_SetBitMap的调用速度，情况同上。

      3. 确认MI_RGN_AttachToChn、MI_RGN_SetDisplayAttr和MI_RGN_DetachFromChn的调用速度，情况同上。

    • 出现问题的原因:

      1. 有OSD拼图时，需要通过BDMA把back buffer搬运到front buffer上，HwGwin再显示front buffer。如果用户持续快速调用相关API，导致上一次搬运操作还没有完成，就需要重新搬运，始终没有新的可以显示的front buffer来替换老的front buffer，从现象上来看就是某些OSD始终显示老的画面不刷新或者不显示。

    2.1.3. SCL贴OSD后出现"ISP FIFO FULL" log

    • 确认问题的步骤：

      1. 使用RGN echo命令echo setRgnOnOff [modid] [devid] [chnid] [portid] [bInputPort] [rgntype] [onoff] > /proc/mi_modules/mi_rgn/mi_rgn0(具体使用指南参考MI_RGN API doc)强制关闭显示SCL上贴的所有OSD。可以重新运行应用确认是否还能复现，如果不会再复现，那么可以认定该问题与OSD有关。

    • 出现问题的原因:

      1. 该问题仅会在ISP与SCL realtime绑定的情况下出现，SCL贴OSD时会打开SCL GOP硬件，会一定程度上使SCL硬件工作速度减慢，如果SCL工作速度过慢，就会回档ISP出现该问题，可能的原因如下：

        • 打开GOP时，SCL工作会等待GOP从MIU请求的数据，如果GOP访问MIU的效率存在问题，那么SCL整体速度就会被拖慢。

        • SCL GOP低功耗模式导致GOP的速度变慢。

    • 解决办法:

      1. 提高GOP的MIU优先级。

      2. 适当降低与SCL GOP同组的其它IP的MIU优先级。GOP可能抢不过其它IP。

      3. 适当拉高SCL clk，加快SCL和GOP的工作速度。

      4. 关闭GOP clk gating，请找对应的MI_RGN owner提供寄存器。

    2.2. 其它常见问题

    2.2.1. 模块贴RGN后出现pass overflow

    • 确认问题的步骤：

      1. cat rgn proc信息(cat /proc/mi_modules/mi_rgn/mi_rgn0)，关注出问题通道的"ChnPort Time Info"。这里记录了该通道Enqueue和Dequeue task在rgn内部的耗时，需要确认耗时是否过高。

      2. 可以重新运行不带RGN的应用确认是否还能复现，如果不会再复现，那么可以认定该问题与RGN有关。

    • 出现问题的原因:

      1. RGN内部流程复杂导致Enqueue和Dequeue task的耗时过高，超过帧率允许的要求。

      2. RGN内部使用的锁接口过多，致使Enqueue和Dequeue task频繁被调度超时。多见于单核的平台上。

    • 解决办法:

      1. 出现这类问题，需要联系MI_RGN owner或FAE 对sdk进行优化。