Trigger of FRM_STRD interrupt on I.MX8MP

[btogorean]

Hi NXP Community,

I'm working with a MIPI camera that generates data at a high rate (300 FPS/1MP resolution) connected to an I.MX8MP. The problem that i'm seeing is that when other processing is happening or even when USB UVC gadget device output is used (zero copy from camera to UVC, MMAP on camera -> USRPTR on UVC) I'm starting to lose frames.

One acceptable solution for my application would be to capture 10 frames and only after those 10 frames are stored update the ISI buffer address. Now from my understanding the ISI HW changes the working output buffer at every frame_stored interrupt and FRM_STRD interrupt is generated when MIPI Frame End packet is received.

A mechanism like in I.MX8MM TRM 13.3.3.2 End Of Frame Interrupt (EOF_INT) which is counting the number o words stored and don't trigger EOF_INT if the required number of words is not received would be very helpful for me.

Now my question is triggering FRM_STRD interrupt only after 10 frames received possible on I.MX 8MP and ignoring Frame Start and Frame End on MIPI?

[cosmin_stoica]

Hello, @btogorean,

We will check internally if ISI from i.MX8MP can perform the action requested and come back with feedback.

Best regards,

Cosmin

[cosmin_stoica · Accepted solution]

Hello, @btogorean,

I got the confirmation that ISI doesn't have any control on the frame number, so unfortunately it can't generate the FRM_STRD after a number of frames.

However, I discussed this issue in the Video core team and we are not sure if this is 100% an ISI problem. From the fps point of view 300fps it is not an issue, as it can be supported due to the lower resolution. So it would be a good idea if we can know the system use case, to know the usage of DDR/CPU for example.

What I am trying to say is that ISI is driven by the MEDIAMIX alongside with ISP, LCDIF leading to NOC which drives other modules, so we are talking about other masters on the same bus. So the frame loss can come from one consumer which is not fast enough.

Best regards,

Cosmin

[btogorean]

Thank you Cosmin for confirmation,

As you say I also don't think the problem is in ISI and in some testes where captured frames were stored with a v4l2 app in a RAMFS mapped location there were no frames dropped.

Problems appear only when I use a UVC USB gadget to stream data. In the end the UVC user-space app is not fast enough to queue new buffers after dequeuing the filled ones and passing them to UVC video output device using USER_PTR method.

I just wanted to reduce the rate at which the user-space app needs to queue new buffers by queueing buffers with a size equivalent to 10 frames and offload the filling of the 10 frames to the ISI DMA.