Hello all,
I'm working on Jacinto, essentially a TI8148 platform and trying to get 24-bit RGB input captured from VIN0. I have done the modifications to the Linux kernel, but now I think the problem is in VPSS-M3 and its firmware. I have the NDA signed and I have even built the firmware using hdvpss_01_00_01_37 and omx-ti81xx-src_05_02_00_38. The command I'm using is:
gst-launch-0.10 -v v4l2src always-copy=false queue-size=12 num-buffers=500 ! 'video/x-raw-yuv-strided,format=(fourcc)NV12,width=800,height=480,framerate=(fraction)60/1' ! omxbufferalloc numBuffers=12 ! gstperf ! fakesink
The problem is that VPSS-M3 effectively halts. Looking with JTAG + CCS I can see it is serving the overflow interrupt continuously in vps/hal/src/vpshal_vip.c, namely VpsHal_vipInstChkOverflowAndDisable(). First impression was that for some reason the IRQ chain there does not acknowledge the interrupt (by writing the corresponding bits to FIQ_CLEAR register). Added that myself there, recompiled, but to no avail. Then looking at the VIP registers at 0x48105500 onwards, with single stepping I noticed the bits in FIQ_STATUS do not get cleared even if I write 0 and then the luma status bit into FIQ_CLEAR. The other code paths in the source suggest that should be the case. For some reason VPSS-M3 gets so busy with the IRQ request that it is not able to serve the proxy task to host A8 and thus Linux effectively halts when it tries to communicate to M3 via SysLink. This very problem appears even if I use the firmware built by TI. So I have some questions:
1) Have I understood the logic of FIQ_STATUS/FIQ_CLEAR wrong? Or why the M3 keeps entering the IRQ handler excessively?
2) What is this overflow situation actually?
3) Some errata (sorry, cannot find it now quickly) tells that the VIP path can lock up when capturing RGB and converting to YUV inside VIP when DDR bandwidth is too low. I'm doing this RGB to YUV conversion, but while I suspect this (I'm capturing only 800x480), how would this condition manifest itself?